Skip to content

fix(s3): fusionner une pile avec la méthode du projet quand son AGENTS.md en définit une #604

Closed

Description

@pascalandy

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.md dit : rebase sur origin/main, just signoff sur la tête, puis git push origin <branche>:main, pour que main garde le commit vérifié
  • Une règle du dépôt exige un statut signoff sur 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 main ne la marque pas comme mergée tant que sa base n'est pas main

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 main avant 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

  1. Before the change: sur pascalandy/nicely, la SOP menait à gh stack merge. L'agent l'a remplacé à la main par la méthode de AGENTS.md
  2. 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 statut signoff
  3. Nothing else changes: un projet sans méthode de merge propre utilise encore gh stack merge, et skills garde just merge
  4. just check passes

👨🏻‍🍳 For the agent

👨🏻‍🍳 Details
  • La règle de pascalandy/nicely : section ## Merge de son AGENTS.md (« Rebase the branch onto origin/main, sign off its head, then push that head to main with git push origin <branch>:main »)
  • Son ruleset signoff sur main : required_status_checks (contexte signoff), non_fast_forward et deletion
  • 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 signoff refuse une branche sans upstream quand push.default vaut simple. On le contourne sans écrire dans la config avec GIT_CONFIG_COUNT=1 GIT_CONFIG_KEY_0=push.default GIT_CONFIG_VALUE_0=current. Ce point relève plutôt de retro-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 merge dans skills : ce ne sont pas des doublons

by Opus-5.5 via Claude Code

Activity

  1. added
    1-needs-triageScope, approach, or direction needs evaluation
    2-type:postmortemFinding from a postmortem or retrospective; route to work after triage
    2-type:bugExisting behavior is broken
    4-epic:memberBelongs to an epic identified by the parent relationship
    1-ready-for-agentValidated work, sufficiently specified for an autonomous agent
    3-pty:p2Normal planned work; default when no priority is established
    and removed
    1-needs-triageScope, approach, or direction needs evaluation
    2-type:postmortemFinding from a postmortem or retrospective; route to work after triage
    on Oct 12, 2026
  2. pascalandy commented on Oct 12, 2026

    @pascalandy
    OwnerAuthor

    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.

    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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    1-ready-for-agentValidated work, sufficiently specified for an autonomous agent2-type:bugExisting behavior is broken3-pty:p2Normal planned work; default when no priority is established4-epic:memberBelongs to an epic identified by the parent relationship

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions