lockstep-publish red: dito msp command group uncovered in the docs build (streak since 2026-10-05) #24
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
Observed (2026-10-07, from run 3314's log): the scheduled
lockstep-publishjob fails at the build step, not the auth/push step:Mechanism: the publish job fetches the newest dito release at build time (this run fetched
6.1.2-rc.3), and that binary carries the newdito mspcommand group (the ditdash/msp arc, U-M1/U-R2 — PRs #304/#1058 landing this week).tools/build-docs.pyenforces that every shipped command group has narrative coverage; no ditdocs page carriescovers: dito msp→ the docs build exits 1, so the publish push never happens.Streak (UTC, started before the 2026-10-07 deepnet converge — not converge-related): runs 3223 (23:56 Oct 5), 3277/3280 (Oct 6 evening), 3308, 3314 — all
publishjobs failedUNCOVERED command groups: dito msp. Push-triggeredlockstep-driftjobs stay green (they do not run the coverage-enforced publish), which is why the red is only on the scheduled lane.Fix: add a ditdocs narrative page (or
covers:entry) for thedito mspcommand group — this belongs to the ditdash/msp arc; bundle it there per release-triage rather than shipping a one-off docs page.Attached verification debt: while the publish build fails pre-push,
FORGE_DEEPNET_TOKENis never exercised by these runs (clone/checkout use the job token; all clones succeed — no 401 anywhere in the logs). The first green publish after the coverage fix is the token's liveness proof post-2026-10-07-converge; if that push 401s, remint per the recorded recipe.Onset window: between run 3205 success (13:08 UTC Oct 5) and run 3223 failure (23:56 UTC Oct 5) — i.e. when the first dito rc carrying
dito mspbecame fetchable, not when source landed.Labels: ci, docs
Verified fixed and green — closure evidence.
The fix landed in four commits on ditdocs main:
7489311captures refresh to the shipped binaries (dito 6.1.2-rc.3 surfaces: msp, operator--list/show, user--list/show; ditc untouched at 3.5.0-rc.1, scribe 0.4.9 drift)2b6392dthe narrative page: src/dito/460-msp-declaration.md (identity chapter, order 60,covers: [dito msp])dc66baccheck-prose: degrade an unreadable CANON_DOC to the intended skip — run 3344 exposed that the CI runner crashes with PermissionError on the check-prose gate (a second, independent publish blocker masked by this one)6d07d99msp page: glossary lexemes as inline code (the first-use exemption), CI-simulated prose gate cleanVerification (run 3346, workflow_dispatch dito/6.1.2-rc.3/testing): success. Coverage green in-CI (
dito 13 groups covered, 72 covers entries verified), prose clean under the runner's canon skip, link-check OK, and the--commitpush published the testing tree to deepnet/ditdocs-testing @ df0c710 — which also exercises FORGE_DEEPNET_TOKEN end-to-end: the token is ALIVE (the failure streak never reached the push step; no 401 was ever in evidence, now confirmed by a green token-consuming push).Follow-up filed separately: the durable CI-side canon wiring (DITDOCS_CANON_DOC setting or a committed canon snapshot, the captures discipline) — see deepnet/ditdocs#25.