Repository navigation
docs(register): reconcile after v1.0.2 — resolve 6, recalibrate 3, name K8 - #98
Merged
Merged
Conversation
…me K8
A falsification audit of "we are done here; nothing up or downstream is blocked
by anything in this repo" found no hard falsification — seven probes against the
published wheel and the real views-models tree all held, including the two
riskiest (our views-frames<2 pin is byte-identical to what pipeline-core,
views-evaluation and views-datafactory all declare; all 29 shipped configs pass
the newly-tightened gate). But the adequacy probe found the register misreporting
its own state, twice by this epic's own hand.
Resolved, each verified rather than argued:
- C-14 asserted an outbound block on views-models. False, and stale for some
time: their readiness contract was rewritten to expect point models to omit
n_posterior_samples, and their suite passes 291/0. A register entry claiming a
block that does not exist is the one kind of staleness that can stop someone
else's work for no reason.
- C-38 declared itself RESOLVED in its own body while filed under Open Concerns.
- C-42's stated discharge condition ("stays open until merged and released") was
met by 2b3d3b4 and v1.0.2.
- C-03 and C-05 describe positional df.index.names[0]/[1] extraction that no
longer exists anywhere in the package — grep returns nothing; resolve_level and
_index_arrays validate at the boundary instead.
- C-27 was withdrawn in July but sat under Open Concerns with its status encoded
in the Tier cell.
Recalibrated: C-11 2->3 (its own note establishes no ensemble lists a baseline
constituent, so it did not belong beside C-13/C-39), C-12 3->4, C-41 3->4. Tier 3
held 65% of open entries, which is what a default bucket looks like.
C-41's Trigger field still asserted "the import raises ModuleNotFoundError:
scipy" — falsified earlier today (scipy arrives via views-evaluation) and
corrected only in a note. The field is the line people read; it is rewritten.
K6 renamed to name the decision rather than the artifact: "cross-references are
prose, not assertions". Nothing checks that a path cited by a doc, ADR or
register entry still exists, which is why the same rename invalidated eight ADRs
and two register Location fields.
K8 added — "guards authored by the guarded" (C-44, C-50, C-52). This epic
demonstrated it three times in one day: the C-10 forwarding guard silently
disarmed by a config-key rename, CORE_GENOME deletions surviving all 277 tests,
and conformance fixtures pinned to the same literal as the code they guard.
Header schema simplified: Open + Resolved = Total, no separate Withdrawn row. The
separate row was how C-27 could be counted correctly while filed incorrectly.
Four guards added (tests/test_falsification_done_claim.py), written red and now
green: no open entry may declare itself resolved, carry a met discharge
condition, or be C-14; and the header must match the sections. They cannot judge
whether an entry is true — only whether the register contradicts itself.
Not addressed here, and needing register-risk rather than review-rr: the register
has no entry about forecast correctness. Every open concern is plumbing. For a
conflict-forecasting package that is a blind spot, not a clean bill of health.
Refs #85.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PoczAeeAcC81UVMGMSiAvS
…check `/review-diff` on this branch caught two of the four guards added in the previous commit doing nothing: `test_c14_does_not_claim_a_downstream_block_that_no_longer _exists` asserted "C-14 not in open ids", and the discharge-condition test asserted one exact phrase inside C-42. Both could only fail if those specific entries returned, which they will not. That is the K8 pattern this branch adds to the register — a guard written by the author of the thing guarded, encoding the author's model of failure — committed four hours after I flagged the identical defect as finding 13 of the #94 review. The two are replaced by one general guard: no entry under Open Concerns may carry a self-declared terminal marker (RESOLVED, DISCHARGED, WITHDRAWN). That subsumes both the C-38 case (body said RESOLVED while filed open) and the C-27 case (withdrawn in July, status hidden in the Tier cell) without naming either. Mutation-tested rather than assumed: injecting each of the three markers into an open entry fails the guard, and mutating the declared open count fails the header guard. A first attempt at this verification silently applied no mutations at all (`str.replace(old, new, '1')` — count passed as a string) and reported three false "caught" results; that run is discarded, not reported. What the guards deliberately do not attempt is deciding whether an entry's claim is still true of the world. C-14 was caught by running views-models' suite, not by a test, and pretending otherwise would be a third tombstone. Also preserves C-14's original trigger verbatim in its resolution — the wrong claim is that entry's whole value, and the compressed resolution format would otherwise delete it. Refs #85, #98. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PoczAeeAcC81UVMGMSiAvS
… survivors ship-it Step 5.5 ran /falsify guard in a clean-context subagent over the two guards added in 63ef2e1. It applied 18 mutations to the register: 13 survived, and the verdict on both guards was WEAK. This is the hardened version, with every survivor re-run and now caught. The single most damning survivor: the marker list was incomplete against the register's own text. It matched **RESOLVED/**DISCHARGED/**WITHDRAWN while the register already retires entries with **SUPERSEDED (C-17, cluster K7). An entry retired the way C-17 was actually retired was invisible to the guard written to catch retired entries. Every other survivor attacked the parser rather than the vocabulary, so the fix is structural: - section split is line-anchored ^## , not text.index on a bare substring, which a cross-reference inside an entry could truncate - duplicate section headings are rejected outright (the last mutation still surviving after the first round of hardening) - duplicate entry ids are rejected instead of dict-collapsing, which silently kept only the second - headings that look like entries but do not parse (### C-09 —, ### D-10:) now fail loudly instead of being merged into a neighbour or the discarded preamble - fenced code blocks are stripped, so a documentation example is neither counted as an entry nor breaks the count - entries outside both concern sections, and entries in both, are caught - the header regex asymmetry is gone (one row used \s+, the other a hard-coded single space, so realigning the table raised AttributeError instead of reporting a count problem) New guard: Tier cells must be a bare 1-4. This closes the hole structurally rather than lexically — status hidden in an unbolded Tier cell survived the audit, and the marker guard only ever caught C-27's version because it happened to be bolded and capitalised. That guard also fixes a defect in this branch, found by a claim-mode falsify pass on "this branch is ready for a PR": I had criticised C-27 for encoding status in the Tier cell during triage, then written exactly that into C-11, C-12 and C-41 three commits later. The cells are bare integers again and the rationale moved to status notes. Cluster K1 also listed the now-resolved C-05 as live; corrected. Two survivors are kept deliberately and documented in the module docstring: title-case "Resolved" in prose (matching it would fire on legitimate open-entry text like "Moves to Resolved when #92 publishes"), and status prose in the section preamble (which is where per-entry status legitimately lives today). Mutations verified individually, not reasoned about: SUPERSEDED, unbolded RESOLVED, duplicate heading, code-fence phantom with the header inflated to match, Tier-cell status, dash heading, stray D-entry, orphan section, resolved entry refiled as open, entry in both sections, boundary hijack. Register restored byte-identical after each. Refs #85, #98. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PoczAeeAcC81UVMGMSiAvS
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Register curation following
/falsify,/review-rr triageand/review-rr strategic. No source changes — the register, its conventions, and four new guards.Why
A falsification audit of "we are done here; nothing up or downstream is blocked by anything in this repo" returned CONTESTED: 0 hard, 3 soft. Seven probes against the published 1.0.2 wheel and the real views-models tree held — including the two riskiest, our
views-frames<2pin (byte-identical to pipeline-core, views-evaluation and views-datafactory) and all 29 shipped configs against the newly-tightened gate.What did not hold was the register's account of itself, and two of the three were introduced by this epic.
Resolved — 6, each verified
n_posterior_samples2b3d3b4, v1.0.2)index.names[0]/[1]extraction they describe returns no grep hits;resolve_levelvalidates at the boundary26 → 21 open, and five of seventeen T3 entries gone.
Recalibrated
C-11 2→3 (its own note: no ensemble lists a baseline constituent), C-12 3→4, C-41 3→4. T3 held 65% of open entries — a default bucket, not a judgement.
C-41's Trigger field still asserted
ModuleNotFoundError: scipy— falsified earlier today and corrected only in a trailing note. Rewritten.Clusters
Guards
tests/test_falsification_done_claim.py— four assertions over the register, written red, now green. They catch self-contradiction, not untruth: C-14 was caught because it declared a block while filed as open, not because a test knew views-models had moved on.299 passed, 1 xfailed · ruff clean ·
validate_docs.shgreen.Noted, not fixed
The register has no entry about forecast correctness — every open concern is plumbing. For a conflict-forecasting package that is a blind spot.
review-rrmay not add risks; that needsregister-risk.🤖 Generated with Claude Code
https://claude.ai/code/session_01PoczAeeAcC81UVMGMSiAvS