Repository navigation
fix(s3): fusionner une pile avec la méthode du projet quand son AGENTS.md en définit une #604
Description
The problem (CMO)
Agent role: MAIN dans s3
Problem Statement: L'utilisateur final veut que MAIN fusionne une pile de PR sans détour. L'étape Merge de main-closing envoie toujours une pile vers la section Land de gh-stack, c'est-à-dire gh stack merge. Mais certains projets définissent leur propre méthode de merge dans leur AGENTS.md, et leur main refuse la méthode de GitHub.
Cas d'usage :
- Un projet dont
AGENTS.mddit : rebase surorigin/main,just signoffsur la tête, puisgit push origin <branche>:main, pour quemaingarde le commit vérifié - Une règle du dépôt exige un statut
signoffsur le commit poussé et refuse un historique non linéaire - Une pile : chaque PR au-dessus de la première a pour base la branche du dessous. Pousser sa tête sur
mainne la marque pas comme mergée tant que sa base n'est pasmain
Hors champ : les projets sans méthode de merge propre, qui gardent gh stack merge, et skills, qui garde just merge.
REF: pascalandy/nicely#40 à pascalandy/nicely#50
Analogy
La consigne dit « dépose toujours ton colis au comptoir de la poste ». Mais ce colis doit être scellé et signé par le gardien de l'immeuble, et seul le gardien a le droit de le déposer.
- Ce qui devrait arriver : la consigne dit « si l'immeuble a son propre gardien, passe par lui ; sinon, va au comptoir »
- Ce qui est arrivé dans ✨ feat: extensions: discover extensions and show their help nicely#40–#50 : l'agent a dû comparer la consigne au règlement de l'immeuble, poser la question à l'utilisateur final, puis écrire lui-même le trajet. Il a aussi dû découvrir qu'il fallait changer la base de chaque PR vers
mainavant chaque push
Dans la réalité, gh stack merge aurait fait créer de nouveaux commits par GitHub, sans le statut signoff. La règle de main les aurait refusés, ou main aurait gardé des commits que personne n'avait vérifiés. Rien n'a cassé, mais la question a coûté un aller-retour avec l'utilisateur final.
Why it happened
main-closing nomme bien la commande de merge du projet pour une seule PR, mais pas pour une pile. La phrase sur les piles n'a pas d'exception pour un projet qui définit sa propre méthode.
The change (FMO)
Change one sentence in authoring/andy-devtools/s3/references/sop/main-closing.md, under step 2 Merge. It currently says:
For a stack, follow the Land section of 🧰 gh-stack, then run the project's deploy.
It would say instead:
For a stack, follow the project's own merge rules when its AGENTS.md defines them, one layer at a time from the bottom, retargeting each PR to the trunk before its push; otherwise follow the Land section of 🧰 gh-stack. Then run the project's deploy.
That's the whole fix.
How we'll know it works
- Before the change: sur pascalandy/nicely, la SOP menait à
gh stack merge. L'agent l'a remplacé à la main par la méthode deAGENTS.md - After the change: sur la même pile, la SOP mène directement à la méthode du projet. Chaque PR finit
MERGED, et chaque tête poussée porte le statutsignoff - Nothing else changes: un projet sans méthode de merge propre utilise encore
gh stack merge, et skills gardejust merge just checkpasses
👨🏻🍳 For the agent
👨🏻🍳 Details
- La règle de pascalandy/nicely : section
## Mergede sonAGENTS.md(« Rebase the branch onto origin/main, sign off its head, then push that head tomainwithgit push origin <branch>:main») - Son ruleset
signoffsurmain:required_status_checks(contextesignoff),non_fast_forwardetdeletion - Le changement de base est nécessaire parce que GitHub ne marque une PR comme mergée que lorsque sa tête arrive sur sa propre base
- Une pile peut avoir une couche à plusieurs commits, par exemple une PR de docs. Il faut vérifier que la base de la couche est le sommet de
main, et pas seulement que son parent l'est - Pièges rencontrés pendant le merge :
gh signoffrefuse une branche sans upstream quandpush.defaultvautsimple. On le contourne sans écrire dans la config avecGIT_CONFIG_COUNT=1 GIT_CONFIG_KEY_0=push.default GIT_CONFIG_VALUE_0=current. Ce point relève plutôt deretro-global - Voir aussi feat(merge): poser une pile entière en une commande, du sync au deploy #522 et fix(merge): orienter vers gh stack merge quand la PR fait encore partie d'une stack #603, qui portent sur
just mergedans skills : ce ne sont pas des doublons
by Opus-5.5 via Claude Code
Activity
🧰 skill: gh-stack: land with the project's own merge method when AGEN…
pascalandy commentedon Oct 12, 2026
Nouvelle preuve, tour s3 du 2026-10-12 sur pascalandy/nicely#54 et #56 (pile GitHub de 2 couches) : changer la base vers le tronc, comme le propose le FMO, n'a pas marché cette fois.
MERGED(sa tête poussée surmain),gh pr edit 56 --base maina échoué : « Cannot change the base branch because the pull request is part of a stack ». Plus tard,PATCH /repos/.../pulls/56avecbase=maina renvoyé la même erreur 422base_ref_deleted, puisclosed). Il a fallu recréer la branche et rouvrir la PRbase_ref_changedavant son merge. Je ne sais pas encore ce qui a changéPour la phrase du FMO : prévoir le cas où GitHub refuse de changer la base, et interdire de supprimer la branche du dessous tant qu'une PR la vise. Piste non vérifiée : avancer la branche du dessous jusqu'à la tête de la couche suivante, pour que GitHub voie cette tête sur la base de la PR.
by Opus-5.5 via Claude Code