fix(catalog): stop shipping catalog-doc-size as a second live check #1218
No reviewers
Labels
No labels
burndown-2026-06
autonomy
async-consult
autonomy
epic
autonomy
headless
autonomy
live-collab
coherence-core
priority
P0
priority
P1
priority
P2
priority
P3
priority
P4
qa-fixture
role/ai
role/creator
role/design
role/director
role/engineer
role/exec
role/human
role/ops
role/qa
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
coilyco-flight-deck/agentic-os!1218
Loading…
Reference in a new issue
No description provided.
Delete branch "ops/393-retire-doc-size-alias"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
From
coilysiren/inbox#393. 16 of 18 fleet repos run one check twice, and none of them chose that.catalog-doc-sizeis declared here as a compatibility alias fordocumentation-layout. Same check, so naming both runs it twice and prints every failure twice. The cause was entirely upstream:apply-agentic-os-hooks.pyinserted both into every managed block it wroteaudit-pre-commit-coverage.pyderives its expected set from this file, so it actively demanded the redundant hookWhy manual rather than deleted
The alias moves to
stages: [manual]. A consumer still naming it resolves and skips, rather than failing.That ordering is not fussiness. Retiring an id outright is exactly what broke
deployandsteam-ops: they namedcatalog-block-presentafteragentic-os#1142removed it, so any recent rev failed resolution outright. Staging it manual gets the behaviour change now and leaves the id retirable later, once no consumer names it.The audit's expected set already excludes manual-only hooks, so it stops demanding the hook in the same change: 22 expected drops to 21.
Also removes it from
DEFAULT_HOOK_IDSso future rollouts stop inserting it, and fromlore's opt-out, which named a hook the rollout no longer emits.What this does not do
It reaches a repo only when that repo next bumps its pin. Repos sitting on
aos-precommit-v0.18.0keep double-running until then, which is the pin-drift problem rather than this one.Removing the now-inert line from consumer configs is cosmetic and should ride along with each repo's bump rather than becoming fifteen pull requests of its own.
pre-commit run --all-filesexits 0, and the audit no longer listscatalog-doc-sizeas expected.Verified after the merge. Sound, and the compatibility reasoning is the part worth keeping.
Manual staging is the right instrument. A consumer still naming the id resolves and skips rather than failing resolution, which is exactly the failure
agentic-os#1142caused fordeployandsteam-opsby removingcatalog-block-presentoutright. Citing that as the reason not to delete, rather than deleting and hoping, is the difference between a retirement and a breakage.Removing the three upstream sources of the duplication in the same change is what makes it stick: the header example,
DEFAULT_HOOK_IDS, and the audit's expected set. Leaving any one of them would have re-inserted the hook on the next rollout. The audit going 22 to 21 is the check that it actually stopped demanding it.Saying plainly that this reaches a repo only when that repo bumps its pin, and that repos on
aos-precommit-v0.18.0keep double-running until then, is the honest version. That is the pin-drift finding frominbox#393rather than this change's to fix.Worth naming, because the contrast is useful
This is the second change tonight driven by
coilysiren/inbox#393, and the two took opposite approaches to the same question.manual, compatibility preserved, upstream sources removed so it cannot come back, and the limits stated.em-dash-checkwas deleted outright across three repos, taking enforcement of a fleet voice rule from 2 of 19 repos to 0, while#393item 3 asks to promote it into the catalog and delete the local copies - the deletion half without the promotion.The reasoning quality here is exactly what #1210 was missing, and it is the same engineer on the same source issue within the hour. Which suggests #1210 was a misread of a recommendation rather than a considered reversal of it, and that is the more encouraging reading.
That decision is still Kai's and still open on
inbox#393. This PR is a good argument that the promote-and-retire shape is available and works.No findings.