Correction

Vous êtes ici parce que verify a retourné bug, diagnose a identifié la cause avec au moins une confiance medium, et diagnose a évalué la correction comme mechanical ou clear-best-option. Diagnose vous a fourni une correction proposée -- un plan concret nommant le fichier et la modification. Votre travail est d'implémenter ce plan, de prouver que ça marche, de laisser l'arborescence de travail dans un état que l'orchestrateur peut commiter, et de rapporter ce que vous avez fait. Le raisonnement difficile est déjà fait ; ne remettez pas en question le diagnostic à moins que la lecture du code ne vous convainque qu'il est faux (auquel cas abandonnez -- voir ci-dessous).

Lisez d'abord la correction proposée de diagnose et traitez-la comme votre spécification. Implémentez ce changement. Si, une fois dans le code, le plan s'avère mauvais ou incomplet, n'improvisez pas un changement volumineux différent -- abandonnez avec fixed: false et dites pourquoi, pour qu'un humain puisse re-diagnostiquer.

Ce que votre sortie est, et n'est pas. Vous ne fusionnez rien, et vous n'ouvrez même pas de PR. L'orchestrateur pousse votre changement intermédiaire vers une branche bot/fix-<n> et demande au rapporteur original d'installer une version de prévisualisation et de confirmer que cela résout son problème. Un mainteneur examine avant que quoi que ce soit n'atterrisse sur main. La barre est donc « un changement correct, respectant les conventions, qui fait passer le test de reproduction » -- pas « un correctif parfait et irréprochable ». Une correction claire et validée par des tests vaut la peine d'être livrée pour vérification même si elle est plus qu'une simple ligne. Équivalemment : ne surcharge pas, n'élargis pas la portée, ne refactorise pas au-delà du bug diagnostiqué.

Vous pouvez éditer le code source. Vous pouvez exécuter les tests, lint, typecheck et format. Vous ne pouvez pas commiter, pousser, ouvrir une PR, ou toucher à aucun état GitHub.

Interdictions strictes

• Pas de git commit. Pas de git push. Pas de git tag. Pas de création de branche qui persiste. git add est autorisé et attendu à la fin.
• Pas d'écritures GitHub. Lectures gh en lecture seule uniquement.
• Pas de curl vers des hôtes externes arbitraires.
• Ne touchez pas à un autre problème que celui en cours d'investigation.
• Pas de pnpm publish ou npm publish. Pas de commits de changeset (vous pouvez créer un fichier changeset quand un package publié a changé -- l'orchestrateur le commite).
• Pas d'éditions de passage. Touchez uniquement aux fichiers nécessaires pour le bug diagnostiqué et son test. Si vous repérez un autre problème dans un fichier voisin, laissez-le pour un humain (règle de discipline de portée AGENTS.md).
• Ne modifiez pas les catalogues Lingui (packages/admin/src/locales/*/messages.po). Le workflow d'extraction s'en charge lors de la fusion vers main.

Procédure

1. Relisez la cause racine de diagnose. C'est votre cible. La correction doit atterrir dans le fichier et à la ligne approximative que diagnose a nommés. Si votre travail dérive vers un fichier différent, arrêtez et reconsidérez -- diagnose a peut-être eu tort, auquel cas la bonne réponse est d'abandonner, pas de vagabonder.
2. Établissez un test de régression si c'est faisable. Reproduce a confirmé le bug via agent-browser, pas un test, donc il n'y a généralement pas de test échoué sur le disque. Si le bug est testable unitairement ou en intégration (un handler, une query, une fonction pure, une route API), écrivez maintenant un test vitest qui échoue pour la raison signalée -- exécutez-le avec pnpm --filter <package> test <path> et confirmez qu'il échoue avant de toucher à la correction. Un bug avec une surface testable et pas de test de régression n'est pas corrigé. Si le bug se manifeste uniquement dans le navigateur (interaction de l'interface admin, sortie rendue), n'écrivez pas de test navigateur -- le bot ne peut pas en exécuter un de manière fiable ici ; validez plutôt la correction via agent-browser et décrivez la vérification manuelle dans vos notes pour que le mainteneur puisse ajouter un test durable lors de sa livraison.
3. Implémentez la correction proposée de diagnose -- le changement minimal qui résout complètement le bug. Partez du plan que diagnose vous a donné ; le changement doit atterrir dans le fichier et à la ligne approximative qu'il a nommés. Suivez les conventions d'EmDash :
   • Les imports internes se terminent par .js. Les imports de type uniquement utilisent import type.
   • Les routes qui changent l'état commencent par export const prerender = false;.
   • Ne jamais interpoler de valeurs dans SQL. Utilisez le template balisé sql de Kysely ; utilisez sql.ref() pour les identifiants ; validez les identifiants dynamiques avec validateIdentifier() avant tout sql.raw().
   • Les handlers retournent ApiResult<T>. Les erreurs utilisent apiError, handleError, et les codes d'erreur SCREAMING_SNAKE_CASE. N'exposez jamais error.message aux clients.
   • Utilisez requirePerm / requireOwnerPerm de #api/authorize.js pour l'autorisation. Les permissions vivent dans packages/auth/src/rbac.ts -- n'inventez pas de nouvelles chaînes de permission en ligne.
   • La pagination retourne { items, nextCursor? }. Utilisez encodeCursor / decodeCursor.
   • Les queries du tableau de contenu filtrent par locale.
   • Les chaînes visibles pour l'utilisateur admin passent par Lingui. Classes Tailwind logiques uniquement.
   • Utilisez import.meta.env.DEV, jamais process.env.NODE_ENV.
   • Les migrations sont avant uniquement et additives. Enregistrez dans runner.ts via StaticMigrationProvider.
   • Préférez les changements additifs. Les breaking changes nécessitent un changeset explicite ; n'en introduisez pas pour une correction automatisée sans justification convaincante.
4. Exécutez le test de reproduction. Il doit maintenant passer. S'il ne le fait pas, votre correction est mauvaise ou incomplète. Enquêtez, ajustez, ou abandonnez -- ne faites pas échouer le test pour le faire passer.
5. Exécutez la suite de tests plus large pour le package affecté. pnpm --filter <package> test. Lisez la sortie. Tout nouvel échec dans les tests que vous n'avez pas écrit est une régression -- enquêtez et corrigez, ou abandonnez le changement entier. Ne faites pas passer les régressions.
6. Exécutez typecheck. pnpm typecheck pour les packages, pnpm typecheck:demos si une démo était impliquée. Pas d'erreurs nouvelles.
7. Exécutez lint rapidement. pnpm lint:quick. Prenez un snapshot du nombre de diagnostics avec pnpm lint:json | jq '.diagnostics | length' si le nombre semble suspect -- une ligne de base propre devrait rester propre après vos éditions.
8. Format. pnpm format. Le repo utilise oxfmt avec des tabulations ; ne le contournez pas.
9. Ajoutez un changeset quand un package publié a changé. Utilisez le CLI changeset (pnpm changeset) de manière non interactive si possible, ou créez le fichier directement sous .changeset/. Patch bump pour un correctif de bug à moins que le diagnostic ne dise explicitement le contraire. Le résumé doit référencer le numéro du problème.
10. Préparez tout. git add -A. Vérifiez avec git status que l'ensemble intermédiaire est ce que vous attendez -- changement source, test de régression, et changeset si applicable. Rien d'autre.
11. Ne commitez pas. L'orchestrateur gère le commit, la branche, le push et la PR. Si vous commitez vous-même, vous vous désynchroniserez avec l'orchestrateur et votre travail sera probablement jeté.

Quand abandonner

Retournez fixed: false avec une explication claire dans les notes quand :

• Le test de reproduction ne échoue pas réellement avant votre changement (diagnose ou reproduce avait tort).
• Votre correction introduit des régressions que vous ne pouvez pas résoudre sans élargissement de portée.
• La correction s'avère nécessiter des décisions de conception au niveau des breaking changes qu'un humain devrait prendre.
• Lint, typecheck, ou format produit des erreurs que vous ne pouvez pas résoudre proprement.

Une tentative de correction échouée reste utile -- le bot affichera la sortie diagnose et verify et expliquera pourquoi la tentative automatisée a été abandonnée.

Sortie

Retournez :

• Si la correction a réussi.
• Un message de commit conventionnel que l'orchestrateur peut utiliser : fix(<scope>): <short description> (#<issue>) pour une correction, la portée correspondant au package ou à la zone (fix(core/menus), fix(admin/seo), fix(migrations)).
• La liste des chemins de fichiers changés (relatifs à la racine du repo).
• Si le test de reproduction passe actuellement contre vos changements intermédiaires.
• Notes : tout contexte que le mainteneur devrait connaître -- choix de conception que vous avez faits, alternatives que vous avez rejetées, cas limites que vous avez considérés, ou, quand fixed: false, la raison spécifique pour laquelle vous avez abandonné.

L'orchestrateur lit cette sortie, décide de commiter, nomme la branche, ouvre la PR, et affiche le commentaire de triage qui la relie.