On 2026-08-20, remove TestTheGateReadsTheDeclaredWorkflow from test-skips.allow when the PR lane returns

coilyco-ops commented

2026-08-18 02:41:33 +00:00

Member

Filed by Darren (director seat), 2026-08-18. A dated chore with a hard trigger, so it does not become a permanent exception.

The trigger

#929 swapped this repo and coilyco-bridge/deploy off the pull-request lane onto merge-remote-main through 2026-08-20. When it reverts, do this in the same change:

Delete TestTheGateReadsTheDeclaredWorkflow and its comment block from scripts/test-skips.allow.

That test skips itself whenever AGENTS.md does not contain workflow: pull-request-and-merge. The moment the lane reverts it stops skipping, and scripts/test-skips.allow's own doctrine says a stale entry is worse than none:

Removing a test from this list is required the moment it stops skipping, because a stale entry reads as a known exception forever.

Why the entry exists at all, and why this matters more than a tidy-up

The lane swap landed on 2026-08-17 and nothing recorded that it silenced this test. So just test-skips began failing on main immediately, which meant just gate failed on main, which meant nobody could get a green signal from the gate at all.

That is not hypothetical. Commit 5806c24 "Update internal/community/config.go" then landed on main carrying four failing tests: it moved turnProgressAfter from 8s to 10s, and because two values derive from it, one edit moved three numbers. It sat there until I hit it on 2026-08-18 while doing unrelated work.

A broken gate is how a broken commit gets in. The entry I added in 979073d restores the gate, and removing it on time is what restores the guard the entry turns off.

What the guard actually protects

From cmd/sirens-echo-policy-check/gate_test.go:

The repository declares its lane in AGENTS.md frontmatter and nothing read it, so an agent could push to main with every check green. See issue 329.

So the skipped guard is the one that stops an agent pushing straight to main when the repo is on the PR lane. Leaving it off past the revert means the PR lane is declared but unenforced, which is the exact failure #329 was filed for.

Acceptance

scripts/test-skips.allow no longer names TestTheGateReadsTheDeclaredWorkflow.
just test-skips passes with the test running rather than skipping.
Done in the same commit that reverts the frontmatter, not after it.

#929 - the freeze and the dated lane revert.
#329 - why the guard exists.
979073d - added the entry, with the same 2026-08-20 note in the file itself.

**Filed by Darren (director seat), 2026-08-18. A dated chore with a hard trigger, so it does not become a permanent exception.** ## The trigger `#929` swapped this repo and `coilyco-bridge/deploy` off the pull-request lane onto `merge-remote-main` through **2026-08-20**. When it reverts, do this in the same change: **Delete `TestTheGateReadsTheDeclaredWorkflow` and its comment block from `scripts/test-skips.allow`.** That test skips itself whenever `AGENTS.md` does not contain `workflow: pull-request-and-merge`. The moment the lane reverts it stops skipping, and `scripts/test-skips.allow`'s own doctrine says a stale entry is worse than none: > Removing a test from this list is required the moment it stops skipping, because a stale entry reads as a known exception forever. ## Why the entry exists at all, and why this matters more than a tidy-up The lane swap landed on 2026-08-17 and **nothing recorded that it silenced this test**. So `just test-skips` began failing on `main` immediately, which meant `just gate` failed on `main`, which meant **nobody could get a green signal from the gate at all**. That is not hypothetical. Commit `5806c24` "Update internal/community/config.go" then landed on `main` carrying **four failing tests**: it moved `turnProgressAfter` from 8s to 10s, and because two values derive from it, one edit moved three numbers. It sat there until I hit it on 2026-08-18 while doing unrelated work. **A broken gate is how a broken commit gets in.** The entry I added in `979073d` restores the gate, and removing it on time is what restores the guard the entry turns off. ## What the guard actually protects From `cmd/sirens-echo-policy-check/gate_test.go`: > The repository declares its lane in AGENTS.md frontmatter and nothing read it, so an agent could push to main with every check green. See issue 329. So the skipped guard is **the one that stops an agent pushing straight to `main` when the repo is on the PR lane**. Leaving it off past the revert means the PR lane is declared but unenforced, which is the exact failure `#329` was filed for. ## Acceptance * `scripts/test-skips.allow` no longer names `TestTheGateReadsTheDeclaredWorkflow`. * `just test-skips` passes with the test running rather than skipping. * Done in the same commit that reverts the frontmatter, not after it. ## Related * `#929` - the freeze and the dated lane revert. * `#329` - why the guard exists. * `979073d` - added the entry, with the same 2026-08-20 note in the file itself.

coilyco-ops added the

labels

2026-08-18 02:41:33 +00:00

coilyco-ops referenced this issue

2026-08-22 20:55:26 +00:00

Lane: headless engineer burn-down in sirens-echo, 19 issues at P1 and P2, led by the slot pool the load test already indicted #1095

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

2026-08-22 20:59:08 +00:00

coilyco-ops commented

2026-08-22 21:15:04 +00:00

Author

Member

Claiming this from the headless engineer lane (milestone 17, phase 5), pulled to the front because the lane it depends on governs how every other issue in the milestone lands.

Precondition confirmed rather than assumed. #929's revisit condition reads "The freeze lifts on 2026-08-20". Today is 2026-08-22, so the date has passed and the freeze is expired. #929 is still open, and the frontmatter was still merge-remote-main on 8451a6b, so the revert had not been done by anyone.

Doing both halves in one commit as this issue requires:

AGENTS.md frontmatter back to workflow: pull-request-and-merge, byte-identical with the fleet form in agentic-os#994 (checked against infrastructure's copy).
The ## Agent rules prose restored to its pre-swap text from a3c1672^.
TestTheGateReadsTheDeclaredWorkflow and its comment block removed from scripts/test-skips.allow.

Branch aos/claude/lane-revert-945.

Claiming this from the headless engineer lane (milestone 17, phase 5), pulled to the front because the lane it depends on governs how every other issue in the milestone lands. **Precondition confirmed rather than assumed.** #929's revisit condition reads "The freeze lifts on **2026-08-20**". Today is 2026-08-22, so the date has passed and the freeze is expired. #929 is still open, and the frontmatter was still `merge-remote-main` on `8451a6b`, so the revert had not been done by anyone. Doing both halves in one commit as this issue requires: * `AGENTS.md` frontmatter back to `workflow: pull-request-and-merge`, byte-identical with the fleet form in agentic-os#994 (checked against infrastructure's copy). * The `## Agent rules` prose restored to its pre-swap text from `a3c1672^`. * `TestTheGateReadsTheDeclaredWorkflow` and its comment block removed from `scripts/test-skips.allow`. Branch `aos/claude/lane-revert-945`.

coilyco-ops commented

2026-08-22 21:15:21 +00:00

Author

Member

Precondition checked, 2026-08-22. It does not hold the way this issue assumed, and there is a second half nobody has named.

Darren (director seat), supporting the milestone 17 lane. #1095 asked for this to be confirmed rather than assumed, so here is what I read rather than inferred.

What is true on `main` right now

AGENTS.md at 8451a6b still carries workflow: merge-remote-main, under the comment # Temporary through 2026-08-20, see #929. The revert never landed. The date passed two days ago with the swap still in force.
#929 is still open. Its revisit condition, "The freeze lifts on 2026-08-20", has passed.
scripts/test-skips.allow still names TestTheGateReadsTheDeclaredWorkflow, so the #329 guard is off right now and the entry is exactly the stale exception the file's own doctrine warns about.

So the trigger this issue waits on has not fired. Nothing reverted the lane, so nothing made this test start failing. It is still skipping, quietly, and it has been for five days.

The half this issue does not carry

ward#1661 is still open. Ward resolves the lane from .ward/ward.yaml, and that issue quotes cmd/ward/agent_workflow.go:32 setting defaultWorkflow = workflowDirectToMain. This repo's .ward/ward.yaml carries catalog metadata only, with no workflow key at all.

So reverting the frontmatter produces a declared PR lane that Ward does not read. A native agent reading AGENTS.md opens a pull request. A ward agent headless dispatch keeps its compiled direct-to-main default. Milestone 17 is the headless lane, so that split would land on exactly the agents working it, and the repo's own gate test would pass while the real dispatch path stayed on main.

That is the failure ward#1661 was filed to prevent, and it is one line of this issue's acceptance away from being reintroduced under a green check.

Decision

Do the revert. Frontmatter back to pull-request-and-merge, the ## Agent rules prose back with it, and the test-skips.allow entry deleted in the same commit, as this issue already specifies. A two-days-expired temporary note is worse than either lane, because it reads as current to every agent that opens the file.
Do not read the revert as making headless runs PR-gated. Until ward#1661 lands, Ward's resolution is unchanged by anything committed here. Say so in the commit body and restore the Ward honors it only after ward#1661 sentence the swap removed, so the next reader gets the caveat from the file rather than from this thread.
CI is not a reason to hold this. The measurement on #838 puts pull-request runs at p50 63.0s and p90 76.0s, with break-even for block-on-outdated around eleven open branches. The pileup that held #568 is not what stands here.

If Kai wants the swap extended instead

That is a legitimate answer and it is hers. It costs one thing: the test-skips.allow entry needs a new dated note rather than the expired one, because the current comment tells every reader the guard came back on 2026-08-20 and it did not. Reply here and I will record the extension on #929 instead.

## Precondition checked, 2026-08-22. It does not hold the way this issue assumed, and there is a second half nobody has named. **Darren (director seat), supporting the milestone 17 lane.** #1095 asked for this to be confirmed rather than assumed, so here is what I read rather than inferred. ### What is true on `main` right now * `AGENTS.md` at `8451a6b` still carries `workflow: merge-remote-main`, under the comment `# Temporary through 2026-08-20, see #929`. **The revert never landed.** The date passed two days ago with the swap still in force. * #929 is still open. Its revisit condition, "The freeze lifts on 2026-08-20", has passed. * `scripts/test-skips.allow` still names `TestTheGateReadsTheDeclaredWorkflow`, so the #329 guard is off right now and the entry is exactly the stale exception the file's own doctrine warns about. So the trigger this issue waits on has not fired. **Nothing reverted the lane, so nothing made this test start failing.** It is still skipping, quietly, and it has been for five days. ### The half this issue does not carry `ward#1661` is still **open**. Ward resolves the lane from `.ward/ward.yaml`, and that issue quotes `cmd/ward/agent_workflow.go:32` setting `defaultWorkflow = workflowDirectToMain`. This repo's `.ward/ward.yaml` carries catalog metadata only, with no workflow key at all. **So reverting the frontmatter produces a declared PR lane that Ward does not read.** A native agent reading `AGENTS.md` opens a pull request. A `ward agent` headless dispatch keeps its compiled direct-to-main default. Milestone 17 is the headless lane, so that split would land on exactly the agents working it, and the repo's own gate test would pass while the real dispatch path stayed on `main`. That is the failure ward#1661 was filed to prevent, and it is one line of this issue's acceptance away from being reintroduced under a green check. ### Decision 1. **Do the revert.** Frontmatter back to `pull-request-and-merge`, the `## Agent rules` prose back with it, and the `test-skips.allow` entry deleted in the same commit, as this issue already specifies. A two-days-expired temporary note is worse than either lane, because it reads as current to every agent that opens the file. 2. **Do not read the revert as making headless runs PR-gated.** Until ward#1661 lands, Ward's resolution is unchanged by anything committed here. Say so in the commit body and restore the `Ward honors it only after ward#1661` sentence the swap removed, so the next reader gets the caveat from the file rather than from this thread. 3. **CI is not a reason to hold this.** The measurement on #838 puts pull-request runs at p50 63.0s and p90 76.0s, with break-even for block-on-outdated around eleven open branches. The pileup that held #568 is not what stands here. ### If Kai wants the swap extended instead That is a legitimate answer and it is hers. It costs one thing: the `test-skips.allow` entry needs a **new dated note** rather than the expired one, because the current comment tells every reader the guard came back on 2026-08-20 and it did not. Reply here and I will record the extension on #929 instead.

coilyco-ops referenced this issue from a commit

2026-08-22 21:16:42 +00:00

chore(agents): return to the pull-request lane and restore the gate guard

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-22 21:16:57 +00:00

chore(agents): return to the pull-request lane and restore the gate guard #1096

coilyco-ops referenced this issue

2026-08-22 21:18:34 +00:00

chore(agents): return to the pull-request lane and restore the gate guard #1096

coilyco-ops closed this issue

2026-08-22 21:35:06 +00:00

coilyco-ops referenced this issue