From 4e41c73e44f19b75719741276d81f100e65e30af Mon Sep 17 00:00:00 2001 From: "russell@unturf.com" Date: Sun, 10 May 2026 19:20:10 -0400 Subject: [PATCH] =?UTF-8?q?ticket=20#000044:=20codify=20=C2=A7-status=20dr?= =?UTF-8?q?ift=20discipline=20(in-progress=20vs=20closed)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Today's audit wave (820409b + 952abc5 + 3b30126) surfaced a sibling drift class to AUTOCOUNT: ticket body §-status sections freeze at landing time while file headers update inline. 5 of 6 in-progress tickets audited had this drift. Codify the two distinct rules (in-progress: refresh in place; closed: archival) as new §10 of #000044 so future blackops shifts have a structured reference instead of having to re-derive the discipline. == New §10 — Sibling discipline — §-status section drift == Three sub-sections: §10.1 In-progress tickets — body §-status must match file header. Walk pattern when amending: (1) update header, (2) walk body §-status + refresh, (3) walk TICKETS.md index row + refresh. The header is the load-bearing surface; lagging body sections are pure drift. §10.2 Closed tickets — body §-status is archival. Do NOT rewrite when later phases land. Phase 2/2.5/B-1/B-2 of a closed ticket (e.g. #000031) go in: - The file header (consolidated) - A NEW section appended below ("Subsequent phases" / "Phase B follow-ups") Rewriting §8 of #000031 with Phase 2 content would erase the Phase 1 landing record — the design log. §10.3 The rule in one line: **In-progress §-status must match header. Closed §-status is archival and stays frozen.** Table at the top shows the 6 in-progress tickets audited today: - #000034 §7 lead stale → refreshed - #000035 §7 lead CLEAN - #000036 §7 lead + closure(c) stale → refreshed - #000037 §20 + §17.1 stale → refreshed - #000025 §11 lead stale → refreshed - #000012 §7 lead + Phase 1a tests stale → refreshed (file rename caught: test_v8_fork_score.py → test_substrate_fork_score.py per a4058a4) Rule is NOT machine-checked. The audit pattern is manual + periodic. Sweep-triggers documented: - Any in-progress → closed flip (final § refresh before freezing) - Any in-progress gains a new phase landing (refresh §) - Quarterly housekeeping pass Long-term, could become a tagged claim (an AUTOCOUNT-like metric asserting §-status text matches header text up to whitespace normalization). Deferred until the audit pattern recurs enough to justify the surface. Speculative; currently below threshold. == Numbering == References renumbered §10 → §11 (one section pushed; new §10 inserted between §9 Scope boundaries and §10 References → §11). No other content moved. == Why land this in #000044 specifically == #000044 already documents doc-drift discipline (the AUTOCOUNT mechanism). §-status drift is a parallel manifestation of the same root cause (point-in-time snapshots freezing while the load-bearing surface updates inline). Both deserve a single home. The alternative — a separate #000046 ticket for §-status drift — would split the discipline into two designs that share 99% of the rationale. == Verification == $ pytest tests/test_doc_counts.py 3 passed in 2.73s No new tags. No code change. Doc-only. --- ...t-000044-autocount-doc-drift-discipline.md | 81 ++++++++++++++++++- 1 file changed, 80 insertions(+), 1 deletion(-) diff --git a/docs/tickets/ticket-000044-autocount-doc-drift-discipline.md b/docs/tickets/ticket-000044-autocount-doc-drift-discipline.md index 6f6881b..fc90ef0 100644 --- a/docs/tickets/ticket-000044-autocount-doc-drift-discipline.md +++ b/docs/tickets/ticket-000044-autocount-doc-drift-discipline.md @@ -280,7 +280,86 @@ As of 2026-05-10 landing of `3b30126`: --- -## 10. References +## 10. Sibling discipline — §-status section drift + +AUTOCOUNT catches numeric drift. A parallel drift class showed +up in the same 2026-05-10 audit wave: prose §-status sections +inside ticket bodies (typically §7 Status or §11 Status) freeze +at landing time while file headers update inline as new phases +land. The §-section becomes a point-in-time snapshot that +diverges from the load-bearing surface fox actually refreshes. + +The 2026-05-10 audit caught this in 5 of 6 in-progress tickets: + +| Ticket | §-section | Drift caught | +|----------|----------------------|-------------------------------| +| #000034 | §7 lead | "Open · awaiting" / body said "Phase 1a landed" | +| #000035 | §7 lead | clean (no drift) | +| #000036 | §7 lead + closure(c) | "Awaits fox review" / file: "in flight with dav1d" | +| #000037 | §20 + §17.1 | "open · awaiting go/no-go" / file: Phase 0+1+2 landed | +| #000025 | §11 lead | "Open · awaiting" / file: 1a + 1b.2 + 1c + 1d + 1e landed | +| #000012 | §7 lead + Phase 1a tests | Phase 1a only / file: 1a + 1b landed; test file renamed | + +The discipline has **two different rules** depending on ticket +state: + +### 10.1 In-progress tickets + +Body §-status sections must match the file header. Refresh in +place when the file header changes. The header is the +load-bearing surface (it's what TICKETS.md index rows mirror); +body sections that lag are pure drift. + +Walk pattern when amending an in-progress ticket: + +1. Update file header status line. +2. Walk §-status body section. If it disagrees with the header, + refresh in the same commit. +3. Walk TICKETS.md index row. If it's a condensed version of + the header, refresh that too. + +### 10.2 Closed tickets + +Body §-status sections are **archival**. They record the state +at landing time and stay frozen. Do NOT rewrite a closed +ticket's §-status section when later phases land — even if the +ticket is still being amended with B-1 / B-2 follow-ups under +the same ticket number. + +Subsequent phases on a closed ticket go in: + +- The file header (consolidated across all phases) +- A NEW section appended below (e.g. "§8.b Subsequent phases" + or "Phase B follow-ups"), not by rewriting §8 + +Rewriting §8 of #000031 with Phase 2 content would erase the +Phase 1 landing record. That record is the design log; future +readers tracing how the textbook substrate evolved need to see +what landed at Phase 1 vs what was added later. + +### 10.3 The rule in one line + +**In-progress §-status must match header. Closed §-status is +archival and stays frozen.** + +This rule is NOT machine-checked. No regression test enforces +it; the audit pattern is manual + periodic. Worth a sweep when: + +- Any ticket flips from in-progress to closed (final §-section + refresh before freezing) +- Any in-progress ticket gains a new phase landing (refresh § + to match) +- Quarterly housekeeping pass on all in-progress tickets + +Long-term, this could become a tagged claim (e.g. an AUTOCOUNT +metric like `ticket-header-status-matches-section` that +asserts §-status text matches header text up to whitespace +normalization). Deferred until the audit pattern recurs enough +to justify the surface. + +--- + +## 11. References - `tests/test_doc_counts.py` — the harness module (docstring is the canonical format reference).