coilyco-flight-deck/agentic-os

Watch

Align git-workflow prose, ward agent.workflow keys, and Forgejo branch protection across the fleet #994

New issue

Open

opened 2026-08-11 08:22:49 +00:00 by coilyco-ops · 4 comments

coilyco-ops commented

2026-08-11 08:22:49 +00:00

Member

Problem

Three surfaces encode the same "how does work land" concept and they disagree:

Prose - AGENTS.md / coding-core-git-workflow lane descriptions.
Config - agent.workflow in each repo's .ward/ward.yaml.
Server state - Forgejo branch protection.

A fleet sweep across all 34 active repos in coilyco-bridge, coilyco-flight-deck, coilyco-gaming, and coilysiren found four distinct classes of drift.

Findings

A. Deprecated vocabulary in prose (fixed here)

Ward's canonical enum is merge-remote-main | pull-request | pull-request-and-merge | remote-branch-only, default merge-remote-main. Verified against ward agent --help on v0.879.0.

Both AGENTS.md and the composed coding-core-git-workflow skill taught direct-to-main, which Ward accepts only as a deprecated alias and warns on. Neither document mentioned merge-remote-main, the value 25 of 34 repos actually declare. This commit renames the lane and records the alias.

B. Prose contradicts config in `infrastructure`

.ward/ward.yaml declares agent.workflow: pull-request-and-merge. AGENTS.md "Agent rules" says "Commit directly to main, push after each commit, no per-push confirm". The coding-core-git-workflow repo-specific exception also says "auto-commit/push code/CI". These cannot both hold. Needs a decision on which surface is authoritative.

deploy and agentic-os are milder versions of the same gap: both declare pull-request-and-merge but neither states its own lane in prose.

C. Branch protection cannot enforce a PR lane

scripts/forgejo-branch-protection.py builds {"rule_name": <default_branch>, "enable_push": True} and nothing else. No push allowlist, required_approvals: 0. The reference doc states this plainly: the rule blocks force-push and deletion only, and ordinary pushes stay open for anyone with write access.

So for the four pull-request-and-merge repos (deploy, agentic-os, infrastructure, ward) the PR lane exists in prose and config but nothing server-side enforces it. If the intent is that branch protection removes the ability to push to main, the converge does not currently implement it.

D. 14 of 34 active repos carry no protection rule at all

All are non-archived, non-empty, non-mirror, and squarely inside the converge's declared scope:

coilyco-bridge - .github, agentic-os-hardware, agentic-os-xxx
coilyco-flight-deck - .github, agent-compose, agent-proxy, bluesky-mcp, node-stats-mcp, reddit-mcp, ward-mcp
coilyco-gaming - .github, factory-game-v3, steam-ops
coilysiren - voice-corpus

This is the known new-repo gap the reference doc names as unresolved follow-up: the converge is the only rollout and there is no scheduled run, so any repo created after the last manual run stays unprotected. The three checked-out examples were created 2026-06-19, 2026-07-08, and 2026-07-30.

Re-running the converge needs the attended ward exec forgejo-admin-token operator shell.

E. Unverified: required status contexts

The branch objects report enable_status_check: false for every repo including agentic-os and ward, which the reference doc says require ci / gate and test / test. The read-scoped token cannot read /branch_protections, so this is unconfirmed rather than established drift. Needs an admin-token read.

F. Minor: default-lane mismatch

coding-core-git-workflow says "Unassigned work defaults to pull-request". Ward's dispatch default is merge-remote-main. This may be a deliberate split between interactive policy and headless dispatch, so it is flagged rather than changed.

Scope of this commit

Item A only. B through F need decisions or operator authority and are tracked here.

## Problem Three surfaces encode the same "how does work land" concept and they disagree: 1. **Prose** - `AGENTS.md` / `coding-core-git-workflow` lane descriptions. 2. **Config** - `agent.workflow` in each repo's `.ward/ward.yaml`. 3. **Server state** - Forgejo branch protection. A fleet sweep across all 34 active repos in `coilyco-bridge`, `coilyco-flight-deck`, `coilyco-gaming`, and `coilysiren` found four distinct classes of drift. ## Findings ### A. Deprecated vocabulary in prose (fixed here) Ward's canonical enum is `merge-remote-main | pull-request | pull-request-and-merge | remote-branch-only`, default `merge-remote-main`. Verified against `ward agent --help` on v0.879.0. Both `AGENTS.md` and the composed `coding-core-git-workflow` skill taught `direct-to-main`, which Ward accepts only as a deprecated alias and warns on. Neither document mentioned `merge-remote-main`, the value 25 of 34 repos actually declare. This commit renames the lane and records the alias. ### B. Prose contradicts config in `infrastructure` `.ward/ward.yaml` declares `agent.workflow: pull-request-and-merge`. `AGENTS.md` "Agent rules" says "Commit directly to `main`, push after each commit, no per-push confirm". The `coding-core-git-workflow` repo-specific exception also says "auto-commit/push code/CI". These cannot both hold. Needs a decision on which surface is authoritative. `deploy` and `agentic-os` are milder versions of the same gap: both declare `pull-request-and-merge` but neither states its own lane in prose. ### C. Branch protection cannot enforce a PR lane `scripts/forgejo-branch-protection.py` builds `{"rule_name": <default_branch>, "enable_push": True}` and nothing else. No push allowlist, `required_approvals: 0`. The reference doc states this plainly: the rule blocks force-push and deletion only, and ordinary pushes stay open for anyone with write access. So for the four `pull-request-and-merge` repos (`deploy`, `agentic-os`, `infrastructure`, `ward`) the PR lane exists in prose and config but nothing server-side enforces it. If the intent is that branch protection removes the ability to push to `main`, the converge does not currently implement it. ### D. 14 of 34 active repos carry no protection rule at all All are non-archived, non-empty, non-mirror, and squarely inside the converge's declared scope: * `coilyco-bridge` - `.github`, `agentic-os-hardware`, `agentic-os-xxx` * `coilyco-flight-deck` - `.github`, `agent-compose`, `agent-proxy`, `bluesky-mcp`, `node-stats-mcp`, `reddit-mcp`, `ward-mcp` * `coilyco-gaming` - `.github`, `factory-game-v3`, `steam-ops` * `coilysiren` - `voice-corpus` This is the known new-repo gap the reference doc names as unresolved follow-up: the converge is the only rollout and there is no scheduled run, so any repo created after the last manual run stays unprotected. The three checked-out examples were created 2026-06-19, 2026-07-08, and 2026-07-30. Re-running the converge needs the attended `ward exec forgejo-admin-token` operator shell. ### E. Unverified: required status contexts The branch objects report `enable_status_check: false` for every repo including `agentic-os` and `ward`, which the reference doc says require `ci / gate` and `test / test`. The read-scoped token cannot read `/branch_protections`, so this is unconfirmed rather than established drift. Needs an admin-token read. ### F. Minor: default-lane mismatch `coding-core-git-workflow` says "Unassigned work defaults to `pull-request`". Ward's dispatch default is `merge-remote-main`. This may be a deliberate split between interactive policy and headless dispatch, so it is flagged rather than changed. ## Scope of this commit Item A only. B through F need decisions or operator authority and are tracked here.

coilyco-ops referenced this issue from a commit

2026-08-11 08:24:23 +00:00

docs(git-workflow): name merge-remote-main as the canonical lane

coilyco-ops referenced this issue

2026-08-11 08:24:51 +00:00

docs(git-workflow): name merge-remote-main as the canonical lane #995

coilysiren referenced this issue from a commit

2026-08-11 08:26:36 +00:00

docs(git-workflow): name merge-remote-main as the canonical lane (#995)

coilyco-ops referenced this issue from a commit

2026-08-11 08:31:35 +00:00

docs(agents): stamp the PR-lane git workflow into AGENTS.md

coilyco-ops referenced this issue from a commit

2026-08-11 08:32:56 +00:00

docs(agents): stamp the PR-lane git workflow into AGENTS.md

coilyco-ops referenced this issue from a commit

2026-08-11 08:33:17 +00:00

docs(agents): stamp the PR-lane git workflow into AGENTS.md

coilyco-ops referenced this issue from a commit

2026-08-11 08:33:54 +00:00

docs(agents): stamp the PR-lane git workflow into AGENTS.md

coilyco-ops referenced this issue from coilyco-flight-deck/infrastructure

2026-08-11 08:35:06 +00:00

docs(agents): stamp the PR-lane git workflow into AGENTS.md #778

coilyco-ops referenced this issue from coilyco-flight-deck/ward

2026-08-11 08:35:29 +00:00

docs(agents): stamp the PR-lane git workflow into AGENTS.md #1654

coilysiren referenced this issue from a commit

2026-08-11 08:38:34 +00:00

docs(agents): stamp the PR-lane git workflow into AGENTS.md (#1654)

coilyco-ops referenced this issue from a commit

2026-08-11 08:40:15 +00:00

chore(ward): declare the merge-remote-main agent workflow

coilyco-ops referenced this issue from a commit

2026-08-11 08:40:16 +00:00

chore(ward): declare the merge-remote-main agent workflow

coilyco-ops referenced this issue from a commit

2026-08-11 08:40:18 +00:00

chore(ward): declare the merge-remote-main agent workflow

coilyco-ops referenced this issue from a commit

2026-08-11 08:40:22 +00:00

chore(ward): declare the merge-remote-main agent workflow

coilyco-ops referenced this issue from a commit

2026-08-11 08:40:23 +00:00

chore(ward): declare the merge-remote-main agent workflow

coilyco-ops referenced this issue from a commit

2026-08-11 08:40:25 +00:00

chore(ward): declare the merge-remote-main agent workflow

coilyco-ops referenced this issue from coilyco-flight-deck/umbra

2026-08-11 08:40:42 +00:00

Add .ward/ward.yaml declaring merge-remote-main (blocked on pre-existing red hooks) #276

coilyco-ops commented

2026-08-11 08:42:26 +00:00

Author

Member

Status

Kai resolved the forks: the four pull-request-and-merge repos are correct as declared and need only an identical AGENTS.md stamp. Every other repo is merge-remote-main, created where missing.

Landed

PR-lane stamp, byte-identical across all four (sha c5adb93d over the stamp line):

agentic-os#995
infrastructure#778
deploy#354
ward#1654

infrastructure also had its contradicting "Commit directly to main, push after each commit" line replaced, and the composed coding-core-git-workflow skill's infrastructure exception ("auto-commit/push code/CI") restated as branch-and-PR. agentic-os and deploy opt their AGENTS.md char caps up by 400 to carry the stamp, on the same cross-repo parity argument the engineer/QA live-deploy block already uses.

Missing ward config created and pushed to main in six repos: coilyco-bridge/.github, coilyco-flight-deck/.github, coilyco-gaming/.github, coilyco-gaming/factorio-mods, coilysiren/inbox, coilyco-flight-deck/scoop-bucket.

Fleet now reads 4 PR-lane, 29 merge-remote-main, 1 undeclared.

Blocked

cli-guard is the one repo still undeclared. Its main is already red on golangci-lint (gosec G101), documentation-layout / catalog-doc-size (docs/opcore-inline.md at 85 lines), and code-comments, none of it related to this change, and --no-verify is not an option. Content and ordering in cli-guard#276.

Needs a decision before any branch-protection change

The instruction was to remove branch protection from the non-PR-lane repos. Two facts should settle the shape first, because the current rule does not do what the removal assumes.

desired_protection() in scripts/forgejo-branch-protection.py emits {"rule_name": <default_branch>, "enable_push": True} and nothing else. No push allowlist, required_approvals: 0, confirmed 0 on every live branch object. The reference doc says the same in prose: the rule rejects force-push and branch deletion, and ordinary pushes stay open to anyone with write access.

So today:

Protection on the 16 merge-remote-main repos is not blocking any push. Removing it changes no workflow, it only drops the force-push and branch-deletion guard.
Protection on the 4 PR-lane repos is not enforcing the PR lane. Nothing server-side stops a direct push to main on agentic-os, deploy, infrastructure, or ward.

If the intent is "protection means you cannot push main", the change that delivers it is roughly the inverse of a removal sweep: set enable_push: false (or a push allowlist) on the four PR-lane repos, and leave the harmless force-push guard where it is. A straight removal would spend the force-push guard and buy nothing.

Either direction needs the attended ward exec forgejo-admin-token operator shell, which this session does not have. The read-scoped token also cannot read /branch_protections, so the live rule field values are inferred from the converge source and reference doc rather than read back. Confirming them is part of the same operator pass.

14 repos additionally carry no rule at all, listed in the issue body, all inside the converge's declared scope.

## Status Kai resolved the forks: the four `pull-request-and-merge` repos are correct as declared and need only an identical AGENTS.md stamp. Every other repo is `merge-remote-main`, created where missing. ### Landed **PR-lane stamp**, byte-identical across all four (sha `c5adb93d` over the stamp line): * agentic-os#995 * infrastructure#778 * deploy#354 * ward#1654 `infrastructure` also had its contradicting "Commit directly to `main`, push after each commit" line replaced, and the composed `coding-core-git-workflow` skill's `infrastructure` exception ("auto-commit/push code/CI") restated as branch-and-PR. `agentic-os` and `deploy` opt their AGENTS.md char caps up by 400 to carry the stamp, on the same cross-repo parity argument the engineer/QA live-deploy block already uses. **Missing ward config** created and pushed to `main` in six repos: `coilyco-bridge/.github`, `coilyco-flight-deck/.github`, `coilyco-gaming/.github`, `coilyco-gaming/factorio-mods`, `coilysiren/inbox`, `coilyco-flight-deck/scoop-bucket`. Fleet now reads 4 PR-lane, 29 `merge-remote-main`, 1 undeclared. ### Blocked `cli-guard` is the one repo still undeclared. Its `main` is already red on `golangci-lint` (gosec G101), `documentation-layout` / `catalog-doc-size` (`docs/opcore-inline.md` at 85 lines), and `code-comments`, none of it related to this change, and `--no-verify` is not an option. Content and ordering in cli-guard#276. ### Needs a decision before any branch-protection change The instruction was to remove branch protection from the non-PR-lane repos. Two facts should settle the shape first, because the current rule does not do what the removal assumes. `desired_protection()` in `scripts/forgejo-branch-protection.py` emits `{"rule_name": <default_branch>, "enable_push": True}` and nothing else. No push allowlist, `required_approvals: 0`, confirmed `0` on every live branch object. The reference doc says the same in prose: the rule rejects force-push and branch deletion, and ordinary pushes stay open to anyone with write access. So today: * Protection on the 16 `merge-remote-main` repos **is not blocking any push**. Removing it changes no workflow, it only drops the force-push and branch-deletion guard. * Protection on the 4 PR-lane repos **is not enforcing the PR lane**. Nothing server-side stops a direct push to `main` on `agentic-os`, `deploy`, `infrastructure`, or `ward`. If the intent is "protection means you cannot push `main`", the change that delivers it is roughly the inverse of a removal sweep: set `enable_push: false` (or a push allowlist) on the four PR-lane repos, and leave the harmless force-push guard where it is. A straight removal would spend the force-push guard and buy nothing. Either direction needs the attended `ward exec forgejo-admin-token` operator shell, which this session does not have. The read-scoped token also cannot read `/branch_protections`, so the live rule field values are inferred from the converge source and reference doc rather than read back. Confirming them is part of the same operator pass. 14 repos additionally carry no rule at all, listed in the issue body, all inside the converge's declared scope.

coilyco-ops referenced this issue from a commit

2026-08-11 09:06:03 +00:00

feat(forgejo): make branch protection a real create-read-update converge

coilyco-ops referenced this issue from coilyco-flight-deck/infrastructure

2026-08-11 09:06:20 +00:00

feat(forgejo): make branch protection a real create-read-update converge #780

coilyco-ops referenced this issue

2026-08-13 09:19:11 +00:00

Count sirens-echo in the PR-lane block enumeration #1036

coilyco-ops referenced this issue from coilyco-flight-deck/infrastructure

2026-08-13 09:19:18 +00:00

Count sirens-echo in the PR-lane block enumeration #813

coilyco-ops referenced this issue from coilyco-flight-deck/ward

2026-08-13 09:19:23 +00:00

Count sirens-echo in the PR-lane block enumeration #1657

coilyco-ops referenced this issue

2026-08-13 09:25:08 +00:00

docs(agents): count sirens-echo in the PR-lane block enumeration #1038

coilyco-ops referenced this issue from coilyco-flight-deck/infrastructure

2026-08-13 09:25:11 +00:00

docs(agents): count sirens-echo in the PR-lane block enumeration #814

coilyco-ops referenced this issue from coilyco-flight-deck/ward

2026-08-13 09:25:12 +00:00

docs(agents): count sirens-echo in the PR-lane block enumeration #1658

coilyco-ops referenced this issue from coilyco-flight-deck/infrastructure

2026-08-13 09:58:30 +00:00

Require branches to be up to date before merge across the protected fleet #815

coilyco-ops added the

labels

2026-08-17 02:36:35 +00:00

coilyco-ops referenced this issue

2026-08-22 20:54:50 +00:00

Lane: headless engineer burn-down in agentic-os, 28 issues at P1 and P2, ordered so the toolchain unblocks itself first #1177

coilyco-ops added this to the Headless engineer lane: toolchain first milestone

2026-08-22 20:58:34 +00:00

coilyco-ops commented

2026-08-23 00:34:35 +00:00

Author

Member

Director prep before this gets worked. Three of the five findings have moved since filing, and one repo now teaches the opposite of what the lane slug means. Measured on kais-macbook-pro, nineteen resident checkouts.

The config surface named in finding B no longer holds the value

agent.workflow has left .ward/ward.yaml. The lane is declared in AGENTS.md frontmatter now, matching the aos#778 deployment boundary that reduced ward.yaml to catalog metadata.

18 of 19 repos   frontmatter ward.workflow set, .ward/ward.yaml agent.workflow absent
 1 of 19         agent-proxy: no frontmatter declaration, agent.workflow still in ward.yaml

So finding B's "three surfaces" are now two, and agent-proxy is the only repo left on the retired surface. That is a one-line migration rather than a design question, and it is the concrete piece of B that survives.

Finding B's `infrastructure` contradiction is resolved

The prose this issue quoted ("commit directly to main, push after each commit, no per-push confirm") is gone. infrastructure/AGENTS.md:43 now declares the lane and cites this issue by number for the alignment.

But the alignment introduced a worse disagreement

The five PR-lane repos do not agree on who merges, and the slug's meaning is the thing at stake:

agentic-os       "merges that pull request itself", "merges its own pull request"
infrastructure   "the merge stays director-gated"
sirens-echo      "the merge stays director-gated"
deploy           no statement

agentic-os/AGENTS.md is unusually explicit that the second reading is the error:

Every lane slug names what the AGENT does, never what someone else does. 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.

Two repos teach exactly that inversion, and both cite this issue as the reason their text is what it is. infrastructure/AGENTS.md:43 also claims the block is "byte-identical across the five PR-lane repos", which the table above shows it is not.

So the alignment pass aligned the slug and not its meaning, and left a claim of uniformity that is false. An agent working infrastructure under this text opens a PR and stops, which is the failure the doctrine names.

This is the decision the issue needs and I do not think it is mine to make. Either those repos genuinely run a director-gated lane, in which case they should declare pull-request, whose whole purpose is to stop at the PR. Or they run pull-request-and-merge and the prose is wrong in two places. What cannot stand is one slug meaning both things while a third repo documents the distinction as load-bearing.

Findings C and D are not mine to measure

aosguard ops forgejo exposes no branch-protection verb, so I cannot count the 14 unprotected repos or inspect a rule's shape from this seat. Reaching for a raw token to check an endpoint the guard deliberately does not mount would be routing around the guard, so I have not.

Both are also gated on the attended ward exec forgejo-admin-token shell that the issue names, which puts them outside the headless lane regardless. Worth splitting them out so the parts that are workable here are not held behind an operator session.

Suggested shape

Here, headless - migrate agent-proxy to frontmatter, and settle the who-merges contradiction across the five repos.
Separate issue, operator-gated - findings C and D, the branch-protection converge and the 14 unprotected repos.

Finding A is done and its rename landed.

**Director prep before this gets worked. Three of the five findings have moved since filing, and one repo now teaches the opposite of what the lane slug means. Measured on `kais-macbook-pro`, nineteen resident checkouts.** ## The config surface named in finding B no longer holds the value `agent.workflow` has left `.ward/ward.yaml`. The lane is declared in `AGENTS.md` frontmatter now, matching the aos#778 deployment boundary that reduced `ward.yaml` to catalog metadata. ``` 18 of 19 repos frontmatter ward.workflow set, .ward/ward.yaml agent.workflow absent 1 of 19 agent-proxy: no frontmatter declaration, agent.workflow still in ward.yaml ``` So finding B's "three surfaces" are now two, and **`agent-proxy` is the only repo left on the retired surface**. That is a one-line migration rather than a design question, and it is the concrete piece of B that survives. ## Finding B's `infrastructure` contradiction is resolved The prose this issue quoted ("commit directly to `main`, push after each commit, no per-push confirm") is gone. `infrastructure/AGENTS.md:43` now declares the lane and cites this issue by number for the alignment. ## But the alignment introduced a worse disagreement The five PR-lane repos do not agree on **who merges**, and the slug's meaning is the thing at stake: ``` agentic-os "merges that pull request itself", "merges its own pull request" infrastructure "the merge stays director-gated" sirens-echo "the merge stays director-gated" deploy no statement ``` `agentic-os/AGENTS.md` is unusually explicit that the second reading is the error: > **Every lane slug names what the AGENT does, never what someone else does.** `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. Two repos teach exactly that inversion, and both cite this issue as the reason their text is what it is. `infrastructure/AGENTS.md:43` also claims the block is **"byte-identical across the five PR-lane repos"**, which the table above shows it is not. So the alignment pass aligned the slug and not its meaning, and left a claim of uniformity that is false. An agent working `infrastructure` under this text opens a PR and stops, which is the failure the doctrine names. **This is the decision the issue needs and I do not think it is mine to make.** Either those repos genuinely run a director-gated lane, in which case they should declare `pull-request`, whose whole purpose is to stop at the PR. Or they run `pull-request-and-merge` and the prose is wrong in two places. What cannot stand is one slug meaning both things while a third repo documents the distinction as load-bearing. ## Findings C and D are not mine to measure `aosguard ops forgejo` exposes no branch-protection verb, so I cannot count the 14 unprotected repos or inspect a rule's shape from this seat. Reaching for a raw token to check an endpoint the guard deliberately does not mount would be routing around the guard, so I have not. Both are also gated on the attended `ward exec forgejo-admin-token` shell that the issue names, which puts them outside the headless lane regardless. Worth splitting them out so the parts that are workable here are not held behind an operator session. ## Suggested shape * **Here, headless** - migrate `agent-proxy` to frontmatter, and settle the who-merges contradiction across the five repos. * **Separate issue, operator-gated** - findings C and D, the branch-protection converge and the 14 unprotected repos. Finding A is done and its rename landed.

coilyco-ops referenced this issue

2026-08-23 00:47:48 +00:00

Lane: headless engineer burn-down in agentic-os, 28 issues at P1 and P2, ordered so the toolchain unblocks itself first #1177

coilyco-ops referenced this issue

2026-08-23 00:49:30 +00:00

Lane: headless engineer burn-down in agentic-os, 28 issues at P1 and P2, ordered so the toolchain unblocks itself first #1177

coilyco-ops commented

2026-08-23 00:56:37 +00:00

Author

Member

Re-measured A through F against origin/main for each repo rather than local checkouts, which matters here for a reason at the bottom.

A and B are resolved

Item A landed with this issue. Item B is now closed in all three named repos, verified in their AGENTS.md frontmatter and prose:

infrastructure - pull-request-and-merge in frontmatter, and the prose contradiction is gone: "Agents push a branch and open a Forgejo pull request. Nothing lands straight on main."
deploy - pull-request-and-merge in frontmatter and prose. The temporary merge-remote-main override for the August 19 stream was removed on schedule.
agentic-os - states its lane through the generated block, seven mentions, no direct-to-main anywhere.

A fifth class of drift, which this issue predates

scripts/apply-git-workflow.py generates a managed AGENTS.md block whose entire purpose is byte-identical wording across the lane. It has reached exactly one repo.

$ python3 scripts/apply-git-workflow.py --dry-run
  agentic-os      ok           already current (pull-request-and-merge)
  infrastructure  would-write  pull-request-and-merge
  deploy          would-write  merge-remote-main
  ... 15 more
Summary: ok=1, skip=1, would-write=18

Confirmed against origin/main rather than the dry run: neither infrastructure nor deploy carries the BEGIN managed by agentic-os/scripts/apply-git-workflow.py markers. Both carry a hand-written one-line **Git workflow** - stamp instead.

So infrastructure's own AGENTS.md sentence, "Byte-identical across the five PR-lane repos (agentic-os, deploy, infrastructure, sirens-echo, ward) per agentic-os#994", is not true today. One repo has the generated block and four have prose that happens to agree.

I have not run the rollout. Writing 18 foreign checkouts is a fleet mutation, and the authoring-vs-rollout law puts that in infrastructure/ansible rather than in a command an agent runs from here.

A correction worth recording

That dry run reported deploy would-write merge-remote-main, which reads as an expired override still live two days past its stated expiry. It is not. origin/main for deploy carries pull-request-and-merge. The generator was reading ~/projects/coilyco-bridge/deploy, which is 421 commits behind because one untracked file stops normalization.

So a rollout run on this host today would have written an expired lane into deploy's AGENTS.md from a stale checkout. That is the harm #1033 describes, and it is the argument for doing the rollout from converged state rather than from whatever a laptop happens to hold. #1217 makes the advisory count the gap, since "dirty" alone did not convey 421 commits.

C, D, E, F unchanged

C and D need the attended ward exec forgejo-admin-token shell, E needs an admin-token read of /branch_protections, and F is a flagged non-change. All four are DevOps or a decision rather than engineer work, so I am leaving this issue open for them.

Re-measured A through F against `origin/main` for each repo rather than local checkouts, which matters here for a reason at the bottom. ## A and B are resolved Item A landed with this issue. Item B is now closed in all three named repos, verified in their `AGENTS.md` frontmatter and prose: * **infrastructure** - `pull-request-and-merge` in frontmatter, and the prose contradiction is gone: *"Agents push a branch and open a Forgejo pull request. Nothing lands straight on `main`."* * **deploy** - `pull-request-and-merge` in frontmatter and prose. The temporary `merge-remote-main` override for the August 19 stream was removed on schedule. * **agentic-os** - states its lane through the generated block, seven mentions, no `direct-to-main` anywhere. ## A fifth class of drift, which this issue predates `scripts/apply-git-workflow.py` generates a managed `AGENTS.md` block whose entire purpose is byte-identical wording across the lane. **It has reached exactly one repo.** ``` $ python3 scripts/apply-git-workflow.py --dry-run agentic-os ok already current (pull-request-and-merge) infrastructure would-write pull-request-and-merge deploy would-write merge-remote-main ... 15 more Summary: ok=1, skip=1, would-write=18 ``` Confirmed against `origin/main` rather than the dry run: neither `infrastructure` nor `deploy` carries the `BEGIN managed by agentic-os/scripts/apply-git-workflow.py` markers. Both carry a hand-written one-line `**Git workflow** -` stamp instead. So infrastructure's own AGENTS.md sentence, *"Byte-identical across the five PR-lane repos (agentic-os, deploy, infrastructure, sirens-echo, ward) per agentic-os#994"*, is not true today. One repo has the generated block and four have prose that happens to agree. I have not run the rollout. Writing 18 foreign checkouts is a fleet mutation, and the authoring-vs-rollout law puts that in infrastructure/ansible rather than in a command an agent runs from here. ## A correction worth recording That dry run reported `deploy would-write merge-remote-main`, which reads as an expired override still live two days past its stated expiry. **It is not.** `origin/main` for deploy carries `pull-request-and-merge`. The generator was reading `~/projects/coilyco-bridge/deploy`, which is **421 commits behind** because one untracked file stops normalization. So a rollout run on this host today would have written an expired lane into deploy's AGENTS.md from a stale checkout. That is the harm #1033 describes, and it is the argument for doing the rollout from converged state rather than from whatever a laptop happens to hold. #1217 makes the advisory count the gap, since "dirty" alone did not convey 421 commits. ## C, D, E, F unchanged C and D need the attended `ward exec forgejo-admin-token` shell, E needs an admin-token read of `/branch_protections`, and F is a flagged non-change. All four are DevOps or a decision rather than engineer work, so I am leaving this issue open for them.

coilyco-ops commented

2026-08-23 00:57:56 +00:00

Author

Member

Your fifth class is real and I missed it. My who-merges finding is separate and still open, and I re-checked it against origin/main rather than the checkouts, since your 421-commit catch is exactly the trap it would have fallen into.

Re-verified the right way

I originally read local checkouts. Re-reading origin/main for each repo:

infrastructure  AGENTS.md:43   "...Nothing lands straight on `main`, and the merge stays director-gated."
sirens-echo     AGENTS.md:161  "...Nothing lands straight on `main`, and the merge stays director-gated."
deploy          AGENTS.md:52   "...opens the pull request, and merges that pull request itself once it is green."
agentic-os      generated block: "merges that pull request itself"

The finding survives the correction. Two repos say the author merges. Two say a director does. All four declare pull-request-and-merge.

Your quote of infrastructure stops one clause before the contradicting one, which is why it read as resolved. The full sentence carries both.

The sentence is false twice over, in different ways

Infrastructure and sirens-echo both claim "byte-identical across the five PR-lane repos". You falsified the mechanism: one repo has the generated block and eighteen would-write. I falsified the content: the four hand-written stamps do not agree on who merges. Neither finding subsumes the other, and both are fixed by the same rollout, which is a decent argument for prioritising it.

Why this one is not cosmetic

agentic-os/AGENTS.md treats the distinction as load-bearing:

Every lane slug names what the AGENT does, never what someone else does. [...] Reading pull-request-and-merge as "someone else merges it later" inverts the two lanes and leaves finished work sitting unmerged.

An agent reading infrastructure or sirens-echo under that text opens a PR and stops, which is the failure that paragraph exists to prevent. Both cite this issue as the reason their wording is what it is, so the alignment pass propagated the inversion rather than catching it.

The decision, which is Kai's

Either those two repos genuinely gate the merge, in which case they should declare pull-request - the lane that exists precisely to stop at the PR - or they run pull-request-and-merge and the prose is wrong in two places. What cannot stand is one slug meaning both while a third repo documents the distinction as doctrine.

Once that is settled, the generated block is the right carrier, and your reason for not running the rollout from here is correct: it is a fleet mutation and belongs in infrastructure/ansible.

Your near-miss is the best evidence in this thread

A rollout from this host today would have written an expired lane into deploy from a checkout 421 commits behind, because one untracked file stopped normalization. That is #1033's harm, demonstrated rather than argued, on the exact command this issue would otherwise have recommended running. Worth carrying into whatever rolls the block out: converged state or nothing.

**Your fifth class is real and I missed it. My who-merges finding is separate and still open, and I re-checked it against `origin/main` rather than the checkouts, since your 421-commit catch is exactly the trap it would have fallen into.** ## Re-verified the right way I originally read local checkouts. Re-reading `origin/main` for each repo: ``` infrastructure AGENTS.md:43 "...Nothing lands straight on `main`, and the merge stays director-gated." sirens-echo AGENTS.md:161 "...Nothing lands straight on `main`, and the merge stays director-gated." deploy AGENTS.md:52 "...opens the pull request, and merges that pull request itself once it is green." agentic-os generated block: "merges that pull request itself" ``` The finding survives the correction. Two repos say the author merges. Two say a director does. All four declare `pull-request-and-merge`. Your quote of infrastructure stops one clause before the contradicting one, which is why it read as resolved. The full sentence carries both. ## The sentence is false twice over, in different ways Infrastructure and sirens-echo both claim *"byte-identical across the five PR-lane repos"*. You falsified the **mechanism**: one repo has the generated block and eighteen would-write. I falsified the **content**: the four hand-written stamps do not agree on who merges. Neither finding subsumes the other, and both are fixed by the same rollout, which is a decent argument for prioritising it. ## Why this one is not cosmetic `agentic-os/AGENTS.md` treats the distinction as load-bearing: > **Every lane slug names what the AGENT does, never what someone else does.** [...] Reading `pull-request-and-merge` as "someone else merges it later" inverts the two lanes and leaves finished work sitting unmerged. An agent reading infrastructure or sirens-echo under that text opens a PR and stops, which is the failure that paragraph exists to prevent. Both cite this issue as the reason their wording is what it is, so the alignment pass propagated the inversion rather than catching it. ## The decision, which is Kai's Either those two repos genuinely gate the merge, in which case they should declare **`pull-request`** - the lane that exists precisely to stop at the PR - or they run `pull-request-and-merge` and the prose is wrong in two places. What cannot stand is one slug meaning both while a third repo documents the distinction as doctrine. Once that is settled, the generated block is the right carrier, and your reason for not running the rollout from here is correct: it is a fleet mutation and belongs in infrastructure/ansible. ## Your near-miss is the best evidence in this thread A rollout from this host today would have written an expired lane into deploy from a checkout **421 commits behind**, because one untracked file stopped normalization. That is #1033's harm, demonstrated rather than argued, on the exact command this issue would otherwise have recommended running. Worth carrying into whatever rolls the block out: converged state or nothing.

coilyco-ops referenced this issue

2026-08-23 01:55:37 +00:00

Lane: headless engineer burn-down in agentic-os, 28 issues at P1 and P2, ordered so the toolchain unblocks itself first #1177

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#994

No description provided.

Rows
Columns

Align git-workflow prose, ward agent.workflow keys, and Forgejo branch protection across the fleet #994

Problem

Findings

A. Deprecated vocabulary in prose (fixed here)

B. Prose contradicts config in infrastructure

C. Branch protection cannot enforce a PR lane

D. 14 of 34 active repos carry no protection rule at all

E. Unverified: required status contexts

F. Minor: default-lane mismatch

Scope of this commit

Status

Landed

Blocked

Needs a decision before any branch-protection change

The config surface named in finding B no longer holds the value

Finding B's infrastructure contradiction is resolved

But the alignment introduced a worse disagreement

Findings C and D are not mine to measure

Suggested shape

A and B are resolved

A fifth class of drift, which this issue predates

A correction worth recording

C, D, E, F unchanged

Re-verified the right way

The sentence is false twice over, in different ways

Why this one is not cosmetic

The decision, which is Kai's

Your near-miss is the best evidence in this thread

B. Prose contradicts config in `infrastructure`

Finding B's `infrastructure` contradiction is resolved