The git-workflow managed block never reached the other four PR-lane repos, and two of them still invert the lane #1235

Open
opened 2026-08-25 16:50:46 +00:00 by coilyco-ops · 1 comment
Owner

scripts/apply-git-workflow.py renders the git-workflow section as a marked managed block, and this repo carries it at AGENTS.md:78. The other four PR-lane repos never received it, and three still carry pre-sweep hand-written prose. Two of those invert the lane.

What each repo actually says today

  • agentic-os - managed block, correct. <!-- BEGIN managed by agentic-os/scripts/apply-git-workflow.py -->
  • infrastructure - AGENTS.md:43, hand-written: "Agents push a branch and open a Forgejo pull request. Nothing lands straight on main, and the merge stays director-gated."
  • sirens-echo - AGENTS.md:161, the same inverted sentence, plus "Ward honors it only after ward#1661"
  • deploy - AGENTS.md:52, hand-written but correct in substance: the agent "merges that pull request itself once it is green". Still unmanaged, so it drifts on the next revision
  • ward - not verified, no checkout to hand

Each of the three hand-written lines claims to be "byte-identical across the five PR-lane repos ... per agentic-os#994". They are not byte-identical to each other, and none is byte-identical to the managed block.

Why it costs something

This repo's own doctrine says the failure mode outright: "Reading pull-request-and-merge as 'someone else merges it later' inverts the two lanes and leaves finished work sitting unmerged", and docs/features-agents.md records that two drafts already inverted it.

It bit an agent today. Working infrastructure#929 on the pull-request-and-merge lane, the global rule said merge your own PR once green and infrastructure/AGENTS.md:43 said director-gated. The agent stopped on a green, mergeable pull request holding a live-incident fix and had to ask the human which source governed. That is exactly the stall the sweep exists to remove, and it happened during an active outage.

What resolves it

Fan the managed block into infrastructure, deploy, sirens-echo, and ward, replacing each hand-written section, and keep the repo-specific tail (deploy's expired override note, sirens-echo's Ward caveat) outside the markers so a re-render does not eat it.

Per the authoring-vs-rollout split the generator stays here and the fan-out is the rollout. If that rollout belongs in infrastructure/ansible rather than a hand-run pass, say so on this issue and it moves.

Acceptance

  • all five PR-lane repos carry the marked managed block
  • no repo's AGENTS.md contains "director-gated" describing this lane
  • re-running scripts/apply-git-workflow.py against each is a no-op
  • the "byte-identical across the five PR-lane repos" claim is true when read literally
`scripts/apply-git-workflow.py` renders the git-workflow section as a marked managed block, and this repo carries it at `AGENTS.md:78`. The other four PR-lane repos never received it, and three still carry pre-sweep hand-written prose. Two of those invert the lane. ## What each repo actually says today * **agentic-os** - managed block, correct. `<!-- BEGIN managed by agentic-os/scripts/apply-git-workflow.py -->` * **infrastructure** - `AGENTS.md:43`, hand-written: "Agents push a branch and open a Forgejo pull request. Nothing lands straight on `main`, and **the merge stays director-gated**." * **sirens-echo** - `AGENTS.md:161`, the same inverted sentence, plus "Ward honors it only after ward#1661" * **deploy** - `AGENTS.md:52`, hand-written but correct in substance: the agent "merges that pull request itself once it is green". Still unmanaged, so it drifts on the next revision * **ward** - not verified, no checkout to hand Each of the three hand-written lines claims to be "byte-identical across the five PR-lane repos ... per agentic-os#994". They are not byte-identical to each other, and none is byte-identical to the managed block. ## Why it costs something This repo's own doctrine says the failure mode outright: "Reading `pull-request-and-merge` as 'someone else merges it later' inverts the two lanes and leaves finished work sitting unmerged", and `docs/features-agents.md` records that two drafts already inverted it. It bit an agent today. Working infrastructure#929 on the `pull-request-and-merge` lane, the global rule said merge your own PR once green and `infrastructure/AGENTS.md:43` said director-gated. The agent stopped on a green, mergeable pull request holding a live-incident fix and had to ask the human which source governed. That is exactly the stall the sweep exists to remove, and it happened during an active outage. ## What resolves it Fan the managed block into infrastructure, deploy, sirens-echo, and ward, replacing each hand-written section, and keep the repo-specific tail (deploy's expired override note, sirens-echo's Ward caveat) outside the markers so a re-render does not eat it. Per the authoring-vs-rollout split the generator stays here and the fan-out is the rollout. If that rollout belongs in infrastructure/ansible rather than a hand-run pass, say so on this issue and it moves. ## Acceptance * all five PR-lane repos carry the marked managed block * no repo's AGENTS.md contains "director-gated" describing this lane * re-running `scripts/apply-git-workflow.py` against each is a no-op * the "byte-identical across the five PR-lane repos" claim is true when read literally
Author
Owner

Sequencing note: coilysiren/inbox#430 owns a gap in the block's content that should land before this fan-out, so the copy that reaches four repos is the complete one.

The block states its merge rules with no execution-mode axis. "NEVER merge on pull-request ... the director merge lane carries a pull-request from there" reads correctly for a goal-mode, Ward-bound, or otherwise unattended run, where the gate genuinely is someone else later. In a directly steered interactive session the same gate resolves better as a structured question to the human in the same turn. The block never says so, so an agent reading it interactively has to guess between stopping and asking.

Fanning out prose that is still missing that distinction just distributes the ambiguity to four more repos.

The mechanical inventory in this issue stands unchanged and is still the rollout half.

Sequencing note: `coilysiren/inbox#430` owns a gap in the block's content that should land **before** this fan-out, so the copy that reaches four repos is the complete one. The block states its merge rules with no execution-mode axis. "NEVER merge on `pull-request` ... the director merge lane carries a `pull-request` from there" reads correctly for a goal-mode, Ward-bound, or otherwise unattended run, where the gate genuinely is someone else later. In a directly steered interactive session the same gate resolves better as a structured question to the human in the same turn. The block never says so, so an agent reading it interactively has to guess between stopping and asking. Fanning out prose that is still missing that distinction just distributes the ambiguity to four more repos. The mechanical inventory in this issue stands unchanged and is still the rollout half.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
coilyco-flight-deck/agentic-os#1235
No description provided.