Story 7: Close the epic out honestly — register, docs, and what is left

[Polichinel]

Part of #421. Last story. Runs after #422–#427 have merged.

Context

The epic exists because mechanisms reported success while doing nothing. The close-out is the one place where this epic could commit the same sin: mark six entries resolved, update the counts, and leave the residue unrecorded. A register that overstates what has been fixed is exactly a fails-green artifact.

So the deliverable is not "close the concerns". It is an accurate register, which for at least two of these means narrowing rather than closing.

Work

1. Register — per concern, resolve or narrow with evidence.

Concern	Story	Expected disposition
C-337	#422	Narrow. The guard catches a frozen floor; it cannot catch a floor that is merely too low for semantics that changed quietly. That residue stays open.
C-331	#423	Resolve if the URL is off every command line and a test proves it.
C-341	#424	Resolve if the gates run off-laptop; note explicitly which gates still cannot run in CI and why (C-320 skip idiom).
#363	#425	Resolve — version/tag agreement is fully mechanical.
C-340	#426	Narrow. The hook covers mechanism 2; mechanism 1's general lesson ("read the value back") is not enforced by anything.
C-317	#427	Resolve with the observation — or, if the drill fails, register the finding and leave open. Do not resolve on the strength of the ping being sent.

Each resolution needs the evidence inline, per register convention: what was run, what was observed. "Fixed in #NNN" is not evidence.

Then: update header counts (open, per-tier, struck-through), and confirm the tier sum equals the open count. Narrative goes in reports/register_changelog.md, never the header — that split is what #405 established and test_register_changelog.py enforces.

2. Post-mortem addendum. reports/post_mortems/2026-08-03_releases_v190_to_v1110.md diagnosed the cluster; append a short section recording what was built against it and — more usefully — what the epic found that the post-mortem did not predict. Already known: the dependency-floor investigation expected frozen floors and found none, which turned a remediation into a regression guard. Expect more of these.

3. docs/guides/monitoring.md §1. The mechanism table gains whatever Stories 3, 4 and 6 add, and — the point of the section — what each still does not catch.

4. Cross-links. Any ADR whose claims the epic changed. Run scripts/validate_docs.sh and let it name them rather than guessing.

Acceptance criteria

• Every one of the six concerns dispositioned with inline evidence, not a PR reference
• Concerns narrowed where the fix is partial — at minimum C-337 and C-340
• Header counts correct; tier sum == open count; all 13 register guards pass
• Changelog carries the narrative; header carries none
• Post-mortem addendum includes at least one thing the epic found that the post-mortem got wrong
• scripts/validate_docs.sh exit 0; full suite exit 0

Validation

The register guards are themselves the validation, which is fitting — they were written for exactly this failure mode. Run the full suite, not just the register tests: the docs-citation guard catches a cross-reference to a concern that has moved sections.

Files

reports/technical_risk_register.md · reports/register_changelog.md · reports/post_mortems/2026-08-03_releases_v190_to_v1110.md · docs/guides/monitoring.md · ADRs as validate_docs.sh identifies

Dependencies

Blocked by all of #422–#427. Writing it earlier means writing predictions, and this epic is about the difference between a prediction and an observation.

[Polichinel]

Closed with epic #421. See that issue for why: the epic produced no product change, and this work is not worth its cost. Re-open on its own merits if it becomes so.