chrislacey89/pre-merge

Pré-Fusion

Créer une PR GitHub liant le PRD et les tâches associées, puis examiner le diff complet par rapport aux principes architecturaux du projet. Produit des constats consultatifs — ne bloque pas la fusion, ne corrige pas le code automatiquement et ne crée pas de tickets.

Position d'Invocation

Il s'agit d'une compétence de pipeline primaire utilisée après vérification de l'implémentation et avant la fusion sur la branche principale, ou lors de la reprise de la PR d'un autre pour examen.

Utilisez /pre-merge lorsque la branche est prête pour la création de la PR, la revue architecturale et la réconciliation finale plan-code. Utilisez /pre-merge --pr <numéro> lorsque vous examinez une PR que vous n'avez pas créée.

Ne l'utilisez pas comme substitut à la vérification d'implémentation, à la validation QA ou à la planification de refactorisation. Elle suppose que le travail est déjà construit et prêt à être examiné.

Modes

/pre-merge s'exécute dans l'un des trois modes suivants. Les trois modes réutilisent les dimensions de revue architecturale définies dans review-checklist.md ; ils diffèrent par ce qu'ils consomment et ce qu'ils produisent.

• Mode auteur (par défaut) — invoqué sur votre propre branche sans argument --pr. La compétence crée la PR (Phase 2) et affiche les constats dans le terminal sous forme d'avis (Phase 4), puis rend la main — elle n'effectue aucun commit de correction et n'ouvre pas de deuxième passage. C'est le mode auto-invoqué par /execute Étape 6 sur le chemin HITL. Ce qu'il lit est décidé par l'état de la branche, non par un indicateur : une première revue lit la totalité de la tâche, c'est-à-dire toute la branche à moins que l'élément de travail de la tâche n'enregistre son point de départ ; une ré-exécution contre une PR qui porte déjà un timbre de monnaie de revue, dont la tête a depuis bougé, prend le delta post-timbre — les commits après le SHA timbré — comme sujet de la revue, et ne relit pas ce que la revue précédente a couvert. La Phase 1 étape 4 prend cette décision et l'affiche. Le delta est le sujet, pas la limite de ce qu'un relecteur peut lire : review-checklist.md détermine ce qu'un relecteur lit, et cela inclut l'arborescence autour du delta.
• Mode relecteur — invoqué comme /pre-merge --pr <numéro> contre une PR que vous n'avez pas créée. La compétence ignore la création de la PR (la PR existe déjà) et produit un texte de commentaire en brouillon (Phase 4) que vous devez examiner et publier, structuré selon references/comment-craft.md (porte 5P, Triple-R, Signaux de Commentaire, Échange MMG).
• Mode boucle — invoqué comme /pre-merge --loop, ou entré automatiquement lorsque /execute passe la main lors d'une exécution AFK. Exécute les Phases 1 à 4 comme le mode auteur, sauf la décision de périmètre de l'étape 4 de la Phase 1 : le mode boucle lit toujours toute la branche et ne prend jamais le delta post-timbre, puis continue dans Phase 5 : il enregistre chaque constat dans un registre durable — dans le corps de la PR, ou sur l'élément de travail, où references/state-backend.md § Où vivent les enregistrements des revues le dit — attache les preuves qui soutiennent ou réfutent chaque constat, et rend la main à l'opérateur. Les constats cessent d'être une sortie terminale dans ce mode ; ils deviennent des lignes durables avec des responsables. Le mode boucle ne corrige rien et ne fait aucun commit — l'opérateur décide de ce qui arrive à chaque constat (voir Phase 5 § Pourquoi la boucle ne corrige pas).

La condition de sortie du mode boucle est que chaque constat a un responsable — jamais que la revue est revenue vierge.