ticket #000044: codify §-status drift discipline (in-progress vs closed)
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 pera4058a4) 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.
This commit is contained in:
parent
820409bf4f
commit
4e41c73e44
1 changed files with 80 additions and 1 deletions
|
|
@ -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).
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue