Reproduire : API / CLI / Migration / Build

Le problème que vous reproduisez n'a pas besoin de navigateur. Il se trouve dans un handler, la CLI, le serveur MCP, une migration, le registre de schéma, ou le pipeline de build. Votre objectif est une reproduction locale déterministe que le bot peut décrire dans un commentaire, idéalement sous forme d'un test vitest échouant qui devient la fixture de régression une fois le bug corrigé.

Interdictions strictes

• Pas de git commit, pas de git push, pas de création de branche qui persiste au-delà du workflow.
• Pas d'écritures sur GitHub (pas de gh issue comment, gh pr ..., gh issue edit).
• Pas de curl vers des hosts externes arbitraires. Uniquement des processus locaux.
• Ne touchez à aucun problème autre que celui en cours d'investigation.
• Pas de pnpm publish ou npm publish.

Procédure

1. Relisez le corps de l'issue. Extrayez les commandes exactes, chemins de fichiers, noms de packages et stack traces. La reproduction que vous écrivez doit correspondre aux mots de l'utilisateur, pas à une paraphrase. Si le corps fait un lien vers un repo ou un gist, récupérez-le (lecture seule) avant de décider de l'approche.
2. Identifiez le package. Utilisez area plus les chemins de fichiers dans le corps de l'issue. Les bugs CLI vivent dans packages/core/src/cli/. Les handlers REST dans packages/core/src/api/handlers/. Les migrations dans packages/core/src/database/migrations/. Les outils de build typiquement dans packages/*/tsdown.config.ts ou le pnpm-workspace.yaml à la racine. MCP dans packages/core/src/mcp/. Si plusieurs packages sont plausibles, cherchez avec grep avant de deviner.
3. Installez si nécessaire. Si node_modules semble obsolète ou manquant, exécutez pnpm install. Sinon, passez -- les installations sont lentes et le runner a généralement déjà les dépendances.
4. Construisez uniquement ce dont vous avez besoin. La plupart des reproductions peuvent cibler directement la source via vitest. Ne lancez pnpm --filter <package> build que si le bug est dans la sortie compilée ou dans la génération de types cross-package.
5. Choisissez une approche. Par ordre de préférence :
   • Test vitest échouant dans le répertoire tests/ du package affecté. Utilisez setupTestDatabase() / setupForDialect() depuis tests/utils/test-db.ts pour tout ce qui touche la base de données. Reflétez la structure source (packages/core/src/api/handlers/foo.ts -> packages/core/tests/integration/api/handlers/foo.test.ts). Nommez le test pour l'issue : it("reproduces #<numéro>: <description courte>", ...). Lancez-le avec pnpm --filter <package> test <chemin> et confirmez qu'il échoue pour la raison rapportée par l'utilisateur, non pour une erreur de setup sans rapport.
   • Script de repro sous /tmp/repro-<numéroIssue>/ quand un test vitest aurait besoin de trop d'échafaudage (par ex. besoin d'un binaire CLI construit, besoin de lancer des processus enfants dans un ordre spécifique). Limitez-le à un seul fichier si possible. Capturez stdout, stderr et code de sortie.
   • Commande pnpm exec emdash ... quand le bug est une seule invocation CLI et l'échec est évident dans la sortie.
6. Capturez des preuves. Pour chaque tentative, enregistrez la commande exacte, les stdout/stderr pertinents (trimez à la tranche significative -- ne versez pas des milliers de lignes), et le code de sortie.
7. Confirmez que le mode d'échec correspond. Une reproduction qui plante pour une raison différente de celle rapportée par l'utilisateur n'en est pas une. Si vous ne pouvez déclencher qu'un échec adjacent, dites-le en notes et baissez votre confiance dans le résultat.

Quand ignorer

Marquez skipped: true et expliquez en notes quand l'un des éléments suivants s'applique. Ne perdez pas de minutes de runner à contourner cela.

• Le bug nécessite un fichier d'export WordPress spécifique, un dataset client, ou un autre artefact que l'utilisateur n'a pas joint.
• Le bug ne se manifeste que sur un Cloudflare Worker déployé -- démarrages à froid, cohérence finale, erreurs D1 transitoires, expulsion d'isolate Worker. Le wrangler dev local n'en reproduit pas fidèlement ces cas.
• Le bug nécessite Postgres à l'échelle production (tailles de table, épuisement du pool de connexions, choix du planner). Une poignée de lignes dans pg ne feront pas remonter le même plan.
• Le bug nécessite un vrai Cloudflare Access, les credentials R2, le routage AI Gateway, ou d'autres bindings que le runner n'a pas.
• Le bug dépend du timing d'une manière non fiablement reproductible d'une exécution à l'autre (heisenbug). Notez le symptôme, laissez-le pour un humain.

Sortie

Retournez :

• Si vous avez reproduit le bug.
• Si vous avez ignoré (avec raison si oui).
• L'approche que vous avez utilisée : failing-test, repro-script, pnpm-command, ou none.
• Notes : un court paragraphe avec la ou les commandes exactes, la sortie d'échec, et tout contexte dont l'étape de diagnostic aura besoin. Incluez le chemin du fichier de test si vous en avez écrit un.
• Une liste de screenshots vide. Cette skill ne produit pas de screenshots.

Si vous avez écrit un test échouant, laissez-le en place. Ne le stagez et ne le committez pas. L'étape de fix peut le reprendre ; si aucune fix ne s'exécute, l'orchestrateur décide ce qu'il faut faire avec l'arborescence.