Director merge gates on `pull-request-and-merge`, which is the author-merges lane #1677

Closed

opened 2026-08-20 08:49:13 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-08-20 08:49:13 +00:00

Owner

The declared semantics

A lane slug names what the author agent does.

merge-remote-main - the author commits and pushes straight to main.
pull-request-and-merge - the author opens a pull request and merges it itself once green. The fully autonomous lane. The PR is the record and the CI gate, not a wait state.
pull-request - the author opens the pull request and stops. This is where the director merge lane picks it up.
remote-branch-only - the author pushes a branch and stops.

What ward does today

cmd/ward/agent_director_merge.go gates the director merge on the opposite slug:

merge scans open pull requests in scope and merges only the ones the ward issue thread marks as director-merge authorized: the linked issue ended with WARD-WORKFLOW: merge-ready ..., the final comment says workflow: pull-request-and-merge ... pull-request still needs a human.

And cmd/ward/agent.go:492:

For pull-request-and-merge workflows, opening the PR is not a stopping point. ... The director owns the merge after the worker handoff.

So ward routes pull-request-and-merge to the director and leaves pull-request for a human, which is the inverse of both bullets above.

Why it may have diverged

Under the sealed worker boundary the worker cannot merge, so the director merging on the author's behalf is a reasonable implementation of "the author merges". If that is the intent, the naming still misleads every agent reading the slug outside a ward container, which is most of them today. docs/agent-workflow.md describes pull-request-and-merge as "publish a reviewed, merge-ready PR for the director merge lane", carrying the same reading.

Asked of ward

Confirm which direction is authoritative.
If the author-merges reading wins, move the director merge gate to pull-request and update docs/agent-workflow.md plus the agent.go workflow tail text.
If the sealed-worker reading wins, say so in docs/agent-workflow.md explicitly - that the director merges as the author on that lane - so the slug stops reading as a handoff to someone else.

Either way the fleet needs one answer, because the generated block in agentic-os#1150 will assert it in every repo.

agentic-os#1150 - the loss vector that prompted the stamp.
agentic-os#1157 - the PR carrying the generator and the block.
ward#1661 - where ward reads the lane from. Unrelated to merge authority, but the same declaration.

Ward's director merge lane and the fleet's declared lane semantics currently point in opposite directions. Raising it here because agentic-os#1150 is about to stamp the semantics into every repo's `AGENTS.md`, and a fleet-wide doctrine block that contradicts running code is worse than either alone. ## The declared semantics A lane slug names what the **author agent** does. - `merge-remote-main` - the author commits and pushes straight to `main`. - `pull-request-and-merge` - the author opens a pull request and **merges it itself** once green. The fully autonomous lane. The PR is the record and the CI gate, not a wait state. - `pull-request` - the author opens the pull request and **stops**. This is where the director merge lane picks it up. - `remote-branch-only` - the author pushes a branch and stops. ## What ward does today `cmd/ward/agent_director_merge.go` gates the director merge on the opposite slug: > merge scans open pull requests in scope and merges only the ones the ward issue thread marks as director-merge authorized: the linked issue ended with `WARD-WORKFLOW: merge-ready` ..., the final comment says `workflow: pull-request-and-merge` ... **pull-request still needs a human.** And `cmd/ward/agent.go:492`: > For `pull-request-and-merge` workflows, opening the PR is not a stopping point. ... **The director owns the merge after the worker handoff.** So ward routes `pull-request-and-merge` to the director and leaves `pull-request` for a human, which is the inverse of both bullets above. ## Why it may have diverged Under the sealed worker boundary the worker cannot merge, so the director merging on the author's behalf is a reasonable *implementation* of "the author merges". If that is the intent, the naming still misleads every agent reading the slug outside a ward container, which is most of them today. `docs/agent-workflow.md` describes `pull-request-and-merge` as "publish a reviewed, merge-ready PR for the director merge lane", carrying the same reading. ## Asked of ward 1. Confirm which direction is authoritative. 2. If the author-merges reading wins, move the director merge gate to `pull-request` and update `docs/agent-workflow.md` plus the `agent.go` workflow tail text. 3. If the sealed-worker reading wins, say so in `docs/agent-workflow.md` explicitly - that the director merges *as* the author on that lane - so the slug stops reading as a handoff to someone else. Either way the fleet needs one answer, because the generated block in agentic-os#1150 will assert it in every repo. ## Related - agentic-os#1150 - the loss vector that prompted the stamp. - agentic-os#1157 - the PR carrying the generator and the block. - ward#1661 - where ward reads the lane from. Unrelated to merge authority, but the same declaration.