AGENTS.md tells agents the merge is director-gated, which inverts the pull-request-and-merge lane and strands finished work

coilyco-ops commented

2026-08-25 23:17:36 +00:00

Owner

What

AGENTS.md in this repo carries a hand-written one-line summary of the git workflow:

Git workflow - pull-request-and-merge, declared as ward.workflow in this file's frontmatter. Agents push a branch and open a Forgejo pull request. Nothing lands straight on main, and the merge stays director-gated.

The lane authority says the opposite. agentic_os/generators/generate_git_workflow.py in agentic-os is the canonical source for this block, and it states that the agent that authored the code merges its own pull request on pull-request-and-merge. Its own docstring names this exact reading as the bug it was written to correct:

pull-request-and-merge carries the merge because the agent that authored the code merges its own pull request. Reading pull-request-and-merge as "someone else merges it later" inverts the two lanes and leaves finished work sitting unmerged.

Why it matters

An agent reading this repo's AGENTS.md stops at the open pull request and hands back. That is the stranded-work failure the lane slug was renamed to prevent, and it is invisible until someone reads the merge queue.

The sentence also claims to be "byte-identical across the five PR-lane repos (agentic-os, deploy, infrastructure, sirens-echo, ward)". It is not: agentic-os carries the generated block instead, which says the agent merges. So the claim of identity is itself stale, and the other three repos are worth checking for the same drift.

Fix

Adopt the generated git-workflow block here rather than hand-maintaining a summary of it. agentic-os ships both scripts/apply-git-workflow.py (the writer) and the check-git-workflow pre-commit hook (the drift gate), so the block stops diverging once this repo is on it. This repo has no generated-block markers in AGENTS.md today, which is why it drifted.

Check deploy, sirens-echo, and ward for the same stale sentence while landing it.

Found by

Surfaced while landing #936, whose merge decision the contradiction blocked. Sibling fleet-writer change: coilyco-flight-deck/agentic-os#1244

## What `AGENTS.md` in this repo carries a hand-written one-line summary of the git workflow: > **Git workflow** - `pull-request-and-merge`, declared as `ward.workflow` in this file's frontmatter. Agents push a branch and open a Forgejo pull request. Nothing lands straight on `main`, and the merge stays director-gated. The lane authority says the opposite. `agentic_os/generators/generate_git_workflow.py` in agentic-os is the canonical source for this block, and it states that the agent that authored the code merges its own pull request on `pull-request-and-merge`. Its own docstring names this exact reading as the bug it was written to correct: > `pull-request-and-merge` carries the merge because the agent that authored the code merges its own pull request. Reading `pull-request-and-merge` as "someone else merges it later" inverts the two lanes and leaves finished work sitting unmerged. ## Why it matters An agent reading this repo's `AGENTS.md` stops at the open pull request and hands back. That is the stranded-work failure the lane slug was renamed to prevent, and it is invisible until someone reads the merge queue. The sentence also claims to be "byte-identical across the five PR-lane repos (agentic-os, deploy, infrastructure, sirens-echo, ward)". It is not: agentic-os carries the generated block instead, which says the agent merges. So the claim of identity is itself stale, and the other three repos are worth checking for the same drift. ## Fix Adopt the generated git-workflow block here rather than hand-maintaining a summary of it. agentic-os ships both `scripts/apply-git-workflow.py` (the writer) and the `check-git-workflow` pre-commit hook (the drift gate), so the block stops diverging once this repo is on it. This repo has no generated-block markers in `AGENTS.md` today, which is why it drifted. Check `deploy`, `sirens-echo`, and `ward` for the same stale sentence while landing it. ## Found by Surfaced while landing https://forgejo.coilysiren.me/coilyco-flight-deck/infrastructure/pulls/936, whose merge decision the contradiction blocked. Sibling fleet-writer change: https://forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/pulls/1244

coilyco-ops referenced this issue

2026-08-26 02:36:07 +00:00

docs(agents): adopt the generated git-workflow block #940

coilyco-ops commented

2026-08-26 02:36:27 +00:00

Author

Owner

This repo's copy is fixed in #940. Measuring the rest changed the shape of the remainder, so leaving the numbers here rather than in the pull request alone.

The drift is fleet-wide

A dry run of agentic-os/scripts/apply-git-workflow.py across the 20 checked-out repos:

Summary: ok=1, skip=1, would-write=18

agentic-os is the only repo already current. Every other repo drifts, on both lanes, not just the four PR-lane siblings this issue named.

Why, structurally

agentic-os wires git-workflow as a local hook in its own .pre-commit-config.yaml. The managed hook set that apply-agentic-os-hooks.py writes into consumer repos does not include it. So the authoring repo is gated against this drift and no consumer repo ever has been, which is exactly why one repo stayed current and 18 did not.

Ordering constraint

Adding git-workflow to the fleet hook set first turns 18 repos red until each takes its block. So the blocks land first, per repo on its own lane, and the gate follows once the tree is clean.

There is a second cost per repo. The block is about 2.3 KB and lands in a file most repos cap at 4000 chars. This repo was already opted up to 8000 for the engineer/QA prohibition and still went 133 over, so it needed another raise. Repos sitting near their cap will each need the same, and that is a judgement call per repo rather than something the applier can make.

Scope

That rollout belongs here as ansible rather than as a hand run of the authored applier, per the authoring-vs-rollout split the applier's own docstring states. It also wants a decision from Kai first, since it is 18 pull requests across lanes plus a per-repo cap judgement, so I have not started it.

Suggest this issue stays open as the rollout tracker once the pull request above merges, rather than closing with it.

This repo's copy is fixed in https://forgejo.coilysiren.me/coilyco-flight-deck/infrastructure/pulls/940. Measuring the rest changed the shape of the remainder, so leaving the numbers here rather than in the pull request alone. ## The drift is fleet-wide A dry run of `agentic-os/scripts/apply-git-workflow.py` across the 20 checked-out repos: ``` Summary: ok=1, skip=1, would-write=18 ``` agentic-os is the only repo already current. Every other repo drifts, on both lanes, not just the four PR-lane siblings this issue named. ## Why, structurally agentic-os wires `git-workflow` as a local hook in its own `.pre-commit-config.yaml`. The managed hook set that `apply-agentic-os-hooks.py` writes into consumer repos does not include it. So the authoring repo is gated against this drift and no consumer repo ever has been, which is exactly why one repo stayed current and 18 did not. ## Ordering constraint Adding `git-workflow` to the fleet hook set first turns 18 repos red until each takes its block. So the blocks land first, per repo on its own lane, and the gate follows once the tree is clean. There is a second cost per repo. The block is about 2.3 KB and lands in a file most repos cap at 4000 chars. This repo was already opted up to 8000 for the engineer/QA prohibition and still went 133 over, so it needed another raise. Repos sitting near their cap will each need the same, and that is a judgement call per repo rather than something the applier can make. ## Scope That rollout belongs here as ansible rather than as a hand run of the authored applier, per the authoring-vs-rollout split the applier's own docstring states. It also wants a decision from Kai first, since it is 18 pull requests across lanes plus a per-repo cap judgement, so I have not started it. Suggest this issue stays open as the rollout tracker once the pull request above merges, rather than closing with it.