lockstep-publish red: dito msp command group uncovered in the docs build (streak since 2026-10-05) #24

Closed
opened 2026-10-07 16:59:20 +00:00 by jsutter · 1 comment
Owner

Observed (2026-10-07, from run 3314's log): the scheduled lockstep-publish job fails at the build step, not the auth/push step:

error: python3 tools/build-docs.py --channel testing exited 1:
coverage: UNCOVERED command groups (add `covers:` to a narrative page):
  - dito msp

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 new dito msp command group (the ditdash/msp arc, U-M1/U-R2 — PRs #304/#1058 landing this week). tools/build-docs.py enforces that every shipped command group has narrative coverage; no ditdocs page carries covers: 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 publish jobs failed UNCOVERED command groups: dito msp. Push-triggered lockstep-drift jobs 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 the dito msp command 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_TOKEN is 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 msp became fetchable, not when source landed.
Labels: ci, docs

**Observed (2026-10-07, from run 3314's log):** the scheduled `lockstep-publish` job fails at the build step, not the auth/push step: ``` error: python3 tools/build-docs.py --channel testing exited 1: coverage: UNCOVERED command groups (add `covers:` to a narrative page): - dito msp ``` **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 new `dito msp` command group (the ditdash/msp arc, U-M1/U-R2 — PRs #304/#1058 landing this week). `tools/build-docs.py` enforces that every shipped command group has narrative coverage; no ditdocs page carries `covers: 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 `publish` jobs failed `UNCOVERED command groups: dito msp`. Push-triggered `lockstep-drift` jobs 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 the `dito msp` command 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_TOKEN` is 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 msp` became fetchable, not when source landed. Labels: ci, docs
Author
Owner

Verified fixed and green — closure evidence.

The fix landed in four commits on ditdocs main:

  • 7489311 captures 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)
  • 2b6392d the narrative page: src/dito/460-msp-declaration.md (identity chapter, order 60, covers: [dito msp])
  • dc66bac check-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)
  • 6d07d99 msp page: glossary lexemes as inline code (the first-use exemption), CI-simulated prose gate clean

Verification (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 --commit push 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.

**Verified fixed and green — closure evidence.** The fix landed in four commits on ditdocs main: - `7489311` captures 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) - `2b6392d` the narrative page: src/dito/460-msp-declaration.md (identity chapter, order 60, `covers: [dito msp]`) - `dc66bac` check-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) - `6d07d99` msp page: glossary lexemes as inline code (the first-use exemption), CI-simulated prose gate clean **Verification (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 `--commit` push 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.
Sign in to join this conversation.
No labels
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
deepnet/ditdocs#24
No description provided.