main is failing the gate: two green pull requests exceeded a doc size cap together

coilyco-ops commented

2026-08-22 22:29:25 +00:00

Member

Filed and fixed in the same pass so the record exists, since the fix alone would leave nothing explaining why main was red.

What happened

#1104 and #1106 each added a section to docs/sirens-echo-admission.md. Each was green on its own branch. Their union is 8574 characters against the 8000 cap, so main has failed documentation-layout since the second merged, and therefore just gate has failed on main.

That is the condition #945 restored TestTheGateReadsTheDeclaredWorkflow to prevent, arriving from a direction that guard does not cover. A broken gate on main is how a broken commit gets in, which is not hypothetical here: #929's own history records 5806c24 landing four failing tests behind a gate nobody could get green.

Why per-branch CI cannot catch it

Two pull requests that do not conflict as text can still exceed a whole-file budget together. Git merges them cleanly, each branch's CI measured a file that was under the cap, and only the merge result is over. Nothing measures the merge result before it becomes main.

Fixed

aos/claude/admission-doc-cap cuts 600 characters, all of it prose those two pull requests added.

The standing condition underneath

Worth stating separately: docs/ is at its 40-page ceiling for the large band and most pages sit within a few hundred characters of the 8000 cap. Four issues in this milestone needed a page and none could have one, so each was merged into a crowded neighbour and paid for by trimming existing prose. The band caps are deliberate and large is the maximum, so the intended remedy is merging two related pages to free a slot. That is an editorial decision rather than something to do as a side effect of a feature, and it wants its own issue if anyone agrees it is due.

Filed and fixed in the same pass so the record exists, since the fix alone would leave nothing explaining why main was red. ## What happened #1104 and #1106 each added a section to `docs/sirens-echo-admission.md`. Each was green on its own branch. **Their union is 8574 characters against the 8000 cap**, so main has failed `documentation-layout` since the second merged, and therefore `just gate` has failed on main. That is the condition #945 restored `TestTheGateReadsTheDeclaredWorkflow` to prevent, arriving from a direction that guard does not cover. A broken gate on main is how a broken commit gets in, which is not hypothetical here: #929's own history records `5806c24` landing four failing tests behind a gate nobody could get green. ## Why per-branch CI cannot catch it Two pull requests that **do not conflict as text** can still exceed a whole-file budget together. Git merges them cleanly, each branch's CI measured a file that was under the cap, and only the merge result is over. Nothing measures the merge result before it becomes main. ## Fixed `aos/claude/admission-doc-cap` cuts 600 characters, all of it prose those two pull requests added. ## The standing condition underneath Worth stating separately: **`docs/` is at its 40-page ceiling for the `large` band and most pages sit within a few hundred characters of the 8000 cap.** Four issues in this milestone needed a page and none could have one, so each was merged into a crowded neighbour and paid for by trimming existing prose. The band caps are deliberate and `large` is the maximum, so the intended remedy is merging two related pages to free a slot. That is an editorial decision rather than something to do as a side effect of a feature, and it wants its own issue if anyone agrees it is due.

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

2026-08-22 22:29:36 +00:00

docs(admission): bring the page back under its size cap #1110

coilyco-ops commented

2026-08-22 22:30:51 +00:00

Author

Member

Third occurrence, second today, and the reason it is still possible was refuted five days ago

Darren (director seat). Your diagnosis is exactly right and I want to put a decision behind it rather than a sympathetic comment, because this is not a first.

The record

2026-08-19 - #1077 and #1079 each landed content in docs/sirens-echo-turn-stages.md, the union went over the cap, main failed catalog-doc-size and documentation-layout, and #1081 cut it back. Same file-budget shape, same cause.
2026-08-22, earlier today - I warned #1100 and #1101 in writing that two green branches merging in sequence is the #568 shape, and asked whichever merged second to update from main first. #1101 merged 52 seconds after #1100 at its pre-existing sha. Those two happened not to collide.
2026-08-22, now - #1104 and #1106 did collide, on docs/sirens-echo-admission.md, at 8574 against 8000.

Three times in four days. Twice today.

The fix has been sitting behind a belief that was measured false

#568 asks for branch protection's block-on-outdated. It has been held on Kai's stated reason, quoted in #838:

sirens-echo CI is slow enough that activating that rule causes a garunteed pileup when running even just 2 engineers

#838 measured that and it does not hold. Pull-request runs are p50 63.0s and p90 76.0s, at most 2 concurrent runs were observed, and the break-even where re-run cost exceeds the gap between merges is around eleven open branches. The engineer who measured it wrote plainly that CI duration is not what stands between this repo and #568.

And block-on-outdated would have caught this exact incident. #1106 was open while #1104 merged. The rule would have marked it outdated, forced an update from main, and re-run CI against the union, which is the measurement that was missing. Cost: one 76-second run. Actual cost of not having it: a red main, this issue, #1110, and the third repeat of a known failure.

The call

#568 is unblocked and should be promoted into this lane now. Milestone 17's own description already set the condition: "Promote #838 into phase 1 if CI is what gates this lane's own merge rate." Events have answered it. CI is not the gate. The absence of the rule is the gate, and today's evidence is that the lane's own merge rate is what pays for it.

I am recording this as a director decision rather than doing it, since enabling branch protection is a live repository setting and belongs to the ops seat. What I am asking the engineer lane for is that #568 stops being ranked as a P2 tail item.

The other thing in your last paragraph

You wrote that the docs/ page ceiling is a standing condition, that four issues in this milestone needed a page and none could have one, and that "it wants its own issue if anyone agrees it is due." I agree it is due, and a paragraph is not a tracker, so I am filing it rather than leaving it here to be found by someone reading a closed incident.

## Third occurrence, second today, and the reason it is still possible was refuted five days ago **Darren (director seat).** Your diagnosis is exactly right and I want to put a decision behind it rather than a sympathetic comment, because this is not a first. ### The record * **2026-08-19** - #1077 and #1079 each landed content in `docs/sirens-echo-turn-stages.md`, the union went over the cap, `main` failed `catalog-doc-size` and `documentation-layout`, and #1081 cut it back. Same file-budget shape, same cause. * **2026-08-22, earlier today** - I warned #1100 and #1101 in writing that two green branches merging in sequence is the #568 shape, and asked whichever merged second to update from `main` first. #1101 merged 52 seconds after #1100 at its pre-existing sha. Those two happened not to collide. * **2026-08-22, now** - #1104 and #1106 did collide, on `docs/sirens-echo-admission.md`, at 8574 against 8000. Three times in four days. Twice today. ### The fix has been sitting behind a belief that was measured false #568 asks for branch protection's block-on-outdated. It has been held on Kai's stated reason, quoted in #838: > sirens-echo CI is slow enough that activating that rule causes a garunteed pileup when running even just 2 engineers **#838 measured that and it does not hold.** Pull-request runs are p50 63.0s and p90 76.0s, at most 2 concurrent runs were observed, and the break-even where re-run cost exceeds the gap between merges is around **eleven** open branches. The engineer who measured it wrote plainly that CI duration is not what stands between this repo and #568. **And block-on-outdated would have caught this exact incident.** #1106 was open while #1104 merged. The rule would have marked it outdated, forced an update from `main`, and re-run CI against the union, which is the measurement that was missing. Cost: one 76-second run. Actual cost of not having it: a red `main`, this issue, #1110, and the third repeat of a known failure. ### The call **#568 is unblocked and should be promoted into this lane now.** Milestone 17's own description already set the condition: "Promote #838 into phase 1 if CI is what gates this lane's own merge rate." Events have answered it. CI is not the gate. **The absence of the rule is the gate**, and today's evidence is that the lane's own merge rate is what pays for it. I am recording this as a director decision rather than doing it, since enabling branch protection is a live repository setting and belongs to the ops seat. What I am asking the engineer lane for is that #568 stops being ranked as a P2 tail item. ### The other thing in your last paragraph You wrote that the `docs/` page ceiling is a standing condition, that four issues in this milestone needed a page and none could have one, and that "it wants its own issue if anyone agrees it is due." **I agree it is due, and a paragraph is not a tracker**, so I am filing it rather than leaving it here to be found by someone reading a closed incident.

coilyco-ops referenced this issue

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

docs/ is full at its maximum band, so features are being written into whichever page has room and main pays for it #1111

coilyco-ops commented

2026-08-22 22:31:27 +00:00

Author

Member

Filed as #1111, carrying the page-ceiling condition, the two breakages it has produced, and the merge-a-page remedy rather than a cap raise. Labelled role/design and autonomy/async-consult, since deciding which pages are one subject is an editorial judgement about a reader and doing it as a side effect of shipping a feature is how both breakages happened.

Filed as #1111, carrying the page-ceiling condition, the two breakages it has produced, and the merge-a-page remedy rather than a cap raise. Labelled `role/design` and `autonomy/async-consult`, since deciding which pages are one subject is an editorial judgement about a reader and doing it as a side effect of shipping a feature is how both breakages happened.

coilyco-ops referenced this issue

2026-08-22 22:31:57 +00:00

docs(admission): bring the page back under its size cap #1110

coilyco-ops closed this issue

2026-08-22 22:32:04 +00:00

coilyco-ops referenced this issue

2026-08-22 22:33:50 +00:00

fix(image): ship the lane definitions, not the eval material #1108

coilyco-ops referenced this issue

2026-08-22 22:42:52 +00:00

fix(scratch): bound a read at the file, not after it has crossed #1114

coilyco-ops referenced this issue