341 Commits

Include renames

Author	SHA1	Message	Date
timothyandClaude Fable 5.1	fcdc381246	docs(568): the rule the branch establishes gets a record, and every row the fix moved is re-measured ... api-conventions.md now says which half of an id-list validator a sibling field may gate (existence, never the raw-count cap) and that a lost-race recovery re-asks the whole validator set rather than the fields whoever wrote the catch remembered. Those, with the bound and the field-named 422, are one convention with residuals, so they get a record -- api.top-level-id-list-validation -- and a task-signal row. The record states what #568 does NOT settle: three validators on two DTOs is a per-field constant, not the repo-wide rule #917 owns, and it says to expect #917 to replace the mechanism. graphics-elements.md: rows 35-44 re-measured against the whole ErsatzTV.Tests project on this tree, because the fix moved five of their red sets -- Validate is now also what the recovery path re-runs, so removing a validator from it reddens that handler's race test too. Rows 45-47 are new and measured the same way. The "redden more than one test" figure is recounted from the table (21 -> 24); the cross-fixture set is unchanged at five. The negative discriminator rows now carry a stated seeding rule: vary one half of the identity and hold the other at the seeded value. Varying both leaves the row rejected by the pre-#568 predicate as well, so a composite revert to it would pass every test at that site. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 21:35:15 +02:00
timothyandClaude Fable 5.1	3541683c99	docs(568): re-measure every mutation row the merged identity and the shared validator moved ... Nine rows of the mutation table in docs/graphics-elements.md name a clause that this branch's last commit moved, merged or gave new callers, and a red set is a measurement of the tree it ships in. All were re-taken against the whole ErsatzTV.Tests project (2139 tests, 6 skipped) on the code as it now stands, and four new rows added for the clauses the fix introduced. What moved and why the numbers changed: - Row 10 was the seeded-path filter alone. `Kind` now lives inside `IsOnNowNext`, so dropping the lookup's `Where` drops both halves at once and reddens four tests, not three. - Row 18 was the seeder's SQL `Kind == Text` filter and is now the `kind` conjunct of the shared predicate, so it reddens the API site too — a second cross-fixture row. - Rows 35-37 pick up the count-cap tests, since the cap rides in the validator they disarm. Rows 33, 34, 38, 39 re-measured unchanged. - Row 40's mutation text follows the API call's new two-argument shape; it reddens the new wrong-kind test as well. - Rows 41-44 are the new clauses: the raw-count cap (one clause, three call sites, which is what its red set shows), the diagnostic-id truncation, and the two lost-race catches. The two self-counted figures above the table were recounted from the table itself rather than adjusted: twenty-one multi-test rows and five cross-fixture ones (13, 18, 22, 33, 41). The deco lost-race test is renamed so no two rows cite the same test name. api-conventions.md gains the three rules the fix establishes for any write path with a top-level FK id list — bound the raw list, name the field, translate a lost check-then-write race — in the handler-hardening checklist where they belong rather than as a #568 anecdote. Refs #568 Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 21:35:15 +02:00
timothyandClaude Fable 5.1	41fd1f64de	docs(568): re-measure the rows the seeder's lookup call moved, and recount the table's own claims ... The seeder now resolves the built-in row through GetBuiltInElementId, which puts that lookup on a second call path, so every row whose clause the new call can reach was re-run against this tree: 10 and 33 unchanged, 18 reinstated (the Kind == Text filter has a red now that a wrong-kind row at the seeded path can suppress the row the lookup needs), 21 unchanged, 22 gains a third red, and 34 is new (the existence check re-derived as SQL instead of asking the lookup). Two stale measurements went with it. The "known clauses with no red" bullet for the Kind filter quoted 2121 passed against a tree that produces 2123, having been taken before the branch's last two tests existed -- the whole bullet is gone now that the clause has a red. And the per-fixture-filter trap counted thirteen multi-test rows with two spanning two fixture classes, true on origin/main and false here since the branch added rows: fifteen and three, both recounted from the table, with a note that they are. Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 21:35:15 +02:00
timothyandClaude Fable 5.1	cb11116d4f	docs(568): stable row ids in the mutation table, and the case-sensitivity sign-off the issue's wording invites ... Two review findings, both about docs the branch already rewrote. The mutation-coverage table in docs/graphics-elements.md ended up with two rows numbered 24 -- the new IsOnNowNext row was inserted after 23 without checking what followed -- while 18 was vacated when the Kind-filter row moved to the "no red" list. The section's own prose cites rows by number ("the IsOnNowNext clause (row 10)"), so a duplicate id makes a citation ambiguous. The new row becomes 33, the next unused number, and the rule that made it 24 in the first place is now written down: a row number is an identity, not a position, so a new row takes the next unused number, nothing is renumbered, and a retired clause leaves its number vacant rather than having it reused under a new meaning. Both row claims were re-measured and are unchanged; only the id moves. #568's second half is titled "builtIn discriminator is filename-only, case-sensitive, folder-agnostic", and the branch removes the first and third while deliberately keeping case sensitivity -- which reads like two thirds of a done-when box. It is not: the remedy the same box prescribes, "full seeded relative path", is exactly as case-sensitive as the filename match it replaces, so the three adjectives describe one predicate rather than name three separable demands. Read the other way the box would be unsatisfiable by its own remedy. The reason case sensitivity is kept -- a case-INsensitive test hands the built-in identity to a user element differing from the seeded path only in case -- lived only in GraphicsElementDefaults.cs, where a reader arriving from the issue title would not find it. It is now in the active record that owns the discriminator. Refs #568 Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 21:35:15 +02:00
timothyandClaude Fable 5.1	131c63f7f4	fix(568): one ordinal identity predicate for the built-in element, applied in memory at both sites ... The branch moved the `builtIn` discriminator from a bare filename to the full seeded path, but split how the two sites evaluate it: the API handler compares in memory (ordinal) while GetBuiltInElementId's new `.Where(e => e.Path == OnNowNextSeededPath)` compares in SQL. GraphicsElement.Path takes no explicit collation -- TvContext.OnModelCreating pins one only on the listed name/title columns -- so SQLite answers that case-sensitively and MySQL uses the server default, which is normally case-INsensitive. On MySQL the two discriminators could therefore disagree about the same row: AttachOnNowNextByDefault would resolve a case-variant user element as the built-in one while the API reported builtIn:false for it. Collapse both onto GraphicsElementDefaults.IsOnNowNext, ordinal, applied in memory. GetBuiltInElementId goes back to loading the Text candidates and filtering in memory (the shape it had before this branch), keeping only the `Kind` enum filter in SQL. The prose claimed more than the code did. "A filename-only comparison is case-sensitive-by-accident" appeared in four places as a defect the full-path fix removed; a full-path comparison is exactly as case-sensitive, so the clause said nothing and implied a fix that had not happened. Case sensitivity is now deliberate and stated as such -- the built-in element is the exact file the seeder wrote, at the exact path it wrote it to -- and the reason the comparison is kept out of SQL is recorded where the predicate lives. docs/decisions/records/graphics/channel-level-attachment.md said BuiltIn was "computed by comparing the row's `Path` to GraphicsElementDefaults. OnNowNextFileName", which was true of neither the pre-#568 rule (filename to filename) nor the current one; an active record resolved by key now states the current predicate in its own sentence rather than in a parenthetical. Two tests pin the ordinal rule against a loosening to OrdinalIgnoreCase, one per site. Measured: OrdinalIgnoreCase reddens exactly GetAllGraphicsElementsForApi_Should_Not_Mark_A_Case_Variant_Of_The_Seeded_Path_As_BuiltIn and Ignores_A_Case_Variant_Of_The_Seeded_Path, 2 failed / 77 passed of the 79 graphics tests. They do NOT pin provider independence -- under SQLite's BINARY collation an equivalent SQL comparison answers identically, so no test in this suite can distinguish the two. That is stated at each site rather than left for a reader to assume the tests cover it. Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 21:35:14 +02:00
timothyandClaude Fable 5.1	352305ade8	fix(568): sync docs/comments to the seeded-path builtIn discriminator, harden UpdateDecoHandler's twin FK ids ... Review round on #568 found the branch changed builtIn identity from a bare filename comparison to the full seeded path (GraphicsElementDefaults. OnNowNextSeededPath) but left several places still asserting the old rule: - docs/decisions/records/graphics/channel-level-attachment.md and on-now-next-on-by-default.md (both status: active) still described a filename-only match; corrected in place and cross-referenced. - docs/api-conventions.md §8 quoted the retired `Path.GetFileName(element.Path) == OnNowNextFileName` expression verbatim; replaced with the current OnNowNextSeededPath comparison and a note on the UpdateChannelHandler 422 hardening. - Three in-code comments (GraphicsElementDefaults.cs, GraphicsElementSeeder.cs, ChannelGraphicsDefaults.cs) still said "identity is the filename". - docs/graphics-elements.md's mutation-coverage table (row 10, row 18) named clauses that no longer exist or no longer redden any test post-#568; re-measured directly (removing the seeded-path check reddens Ignores_A_Non_Built_In_Element_With_A_Different_Filename and Ignores_A_Same_Named_Same_Kind_Element_Outside_The_Seeded_Folder; removing the Kind==Text filter alone reddens nothing, so it moves to the "known clauses with no red" list with that measurement dated). Also closed the should-fix twin: UpdateDecoHandler's graphicsElementIds and watermarkIds are top-level ReplaceDecoRequest fields in the same position as UpdateChannelRequest.graphicsElementIds (not the deep-FK-in-a-nested-list carve-out), and the reconcile in ApplyUpdateRequest blindly Added a join row for any incoming id -- the identical FK-constraint-to-500 defect #568 fixed on the channel path. Added GraphicsElementIdsMustExist/WatermarkIdsMustExist validators mirroring UpdateChannelHandler's, pinned by UpdateDecoGraphicsElementsTests (reddens when either validator alone is removed -- verified). Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 21:35:14 +02:00
timothyandClaude Fable 5.1	022a05acb2	docs(901): the third count had no in-repo source, so it becomes what both cited artifacts say ... The thesis measurement quoted three numbers side by side. Two are verbatim from the corpus — `docs/guard-inventory.md:179` "wrong NINE times", and `scripts/tests/test_image_build_delegates_the_spa_suite.py:772` "defeated seven measured ways". The third, "a lexical rule over a hook preamble **five**", was reachable only from #901's own issue body ("Five spellings, one mechanism"); nothing in the repo re-derives it, and both artifacts the record cites for #891 — `docs/decisions/records/process/hook-resolves-inputs-from-repo-root.md:64-68` and `scripts/tests/test_hook_fire_log.py:144` — count the SAME sequence as three ("Three successive lexical rules over this line each fell"). Counted as spellings it is eight or nine; five is neither basis. A number in prose that no artifact re-derives is this record's own subject matter, and "Measured 2026-08-30" invites trust rather than re-derivation. Answered by subtraction, not by new prose: - body: the third clause states what both cited artifacts state — three successive lexical rules, each defeated by the next shape. - `rule:` drops the copied numeric triple ("nine, seven and five times") for a pointer to the sequences below, so the counts live in one place (`dont-keep-a-copy-of-a-set`). - `signals:` swaps the unsourced token for the sourced one. Same class, found while checking the neighbours: "would have licensed the parser above through most of nine rounds" (`rule:` and body) counted #887's NINE DEFECTS as rounds — guard-inventory records them as nine defects across THREE cold-review rounds. Now "most of those nine defects". Body stays 58 lines; the paragraph is reflowed at the file's existing width. Refs #901 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 19:47:05 +02:00
timothyandClaude Fable 5.1	20875b0ca7	docs(901): answer round seven by SUBTRACTION — the thesis loses both absolutes, the list loses two copies ... Round seven's blocker was the record's own thesis sentence, and the fix is to delete rather than to re-argue. Six rounds each replaced a refuted absolute with a fresh one; this one states only what was measured. THE THESIS (body). Struck: "a pin cannot be defeated by a respelling of what it COMPARES" and "nothing [stays exposed] for a whole-file pin". Both are false for the record's own worked whole-file pin — measured against the guard's own primitives: _normalise_lines("const flag = '--run --reporter=x';") == _normalise_lines("const flag = '--run --reporter=x';") -> True _normalise('RUN npm ci && echo "a b"') == _normalise('RUN npm ci && echo "a b"') -> True Both pairs differ in bytes and both are respellings of what the pin compares. `PINNED_VITE_CONFIG` — the pin the record calls "pinned WHOLE" — is compared through `_normalise_lines`, so its normalisation is a second exposure axis beside the selector's. The record already refuted itself twice: `rule:` ends "A pin also declares its NORMALISATION and what the normalisation cannot see", and `mechanics:` says the whitespace collapse "including inside a QUOTED STRING" belongs to both TEXT pins. What replaces the sentence is the fail DIRECTION alone — a pin's is a false RED, a shape-matcher's a false GREEN — plus the declaration obligation the rule already carries. No new universal is written in its place. MECHANICS. "named once so the checker, the mutation proofs and the hooks cannot come to mean different strings" is deleted, not repaired: the assignment string is written out at THREE sites in `test_hook_fire_log.py` (measured by walking the AST and comparing each assembled string to `CANONICAL_SINK_ASSIGNMENT` — the constant, and the `current` local of `test_an_ENV_VAR_resolved_sink_path_is_DETECTED` and of `test_the_NEXT_env_var_to_be_invented_is_DETECTED`). The source comment making the same claim is corrected in place, and its correction is STRUCTURAL: it names the three sites and the `current in text` assertion each proof carries, and asserts no mutation outcome, because "an edit here faults loudly there" would be a `CLAIMS` entry under `testing.mutation-claims-are-executed` — wherever it is written — or it is not written. Same reason `4d5bd0dbb` removed the outcome claim from `mechanics:` rather than binding it. THE QUALIFYING-GRAMMAR LIST now exists once, in the record's `rule:`. `docs/README.md` and `docs/guard-inventory.md` state the operative test — an artifact with a grammar the predicate does not implement — and point at the record. The copies had already disagreed inside the commit that wrote them: `docs/README.md` carried five of the six members, omitting JSON5, which is the member the issue's own correction comment names as the one the narrow "shell or config TEXT" framing would have let through (`dont-keep-a-copy-of-a-set`, #869). Rider 1 drops its copy of the vite `DEFAULT_CONFIG_FILES` ordering the same way, deferring to the dated reading in the `test_image_build_delegates_the_spa_suite.py` row. Gate: `pytest scripts/tests -q` 1599 passed, 3 skipped (all pre-existing by-design skips); `decisions_validate.py` OK with the record off the >60-line list; catalog regenerated with no diff; ruff clean; `check-doc-narrative --diff origin/main` 0 warnings. Refs #901 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 18:38:20 +02:00
timothyandClaude Fable 5.1	868ab657d8	docs(901): the record was wrapped narrower than its own corpus, so 65 lines was a WRAP width, not a word count ... `798e5ee40` stopped at 65 prose lines and gave a reason: the remaining candidates for removal were the *why* behind non-obvious choices, which `docs.no-session-narrative` says to keep. That reason is sound about the WORDS and wrong about the LINE COUNT, because the two are not the same quantity. `decisions_validate.record_prose_lines` counts PHYSICAL lines, and this record was the narrowest thing in the set being measured: max body width, 222 active records: median 106; 28 at <=100, 154 at 101-120, 40 >120 this record: 100. The sibling it cites by key, process.hook-resolves-inputs-from-repo-root: 116. The 60-line ceiling was derived at #620 from that distribution, so measuring a 100-column record against it charges the record for a wrap width the corpus does not use. Re-wrapping the seven body paragraphs at 116 — the exact width of the neighbour record — takes the body from 66 physical lines to 58, and the validator now reports 58, off the over-ceiling list (50 records over -> 49, and the key no longer appears). The reflow removes NOTHING: the script asserted word count equal before and after (893) and whitespace-normalised body text byte-identical, and refused to write otherwise. What it buys is that the issue's `## Done-when` box "The record is under the 60-line advisory prose ceiling" is satisfiable as written, so `pretooluse-merge-consent.sh` is not asked to derive consent from a box ticked falsely or left standing. The advisory itself was never breached — the ceiling is a `::warning::`, the validator exits 0, and 49 of 222 records are over it inside the 2-25% CEILING_MINORITY band. Also: the file was the only one of 222 records with no final newline. Fixed in the same commit; `record_prose_lines` is `splitlines()`, so it does not move the count. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:59:16 +02:00
timothyandClaude Fable 5.1	11f92761af	docs(901): the whitespace collapse belongs to the PRIMITIVE, so it belongs to both text pins ... `mechanics:` opened with a universal — "a residual read off one of them does not transfer to the others" — and then attributed the collapse-whitespace-inside-a-string residual to `_normalise_lines` alone. It does transfer, between exactly the two pins that sentence separates: `_normalise_lines` is `_normalise` applied per line (`scripts/tests/test_image_build_delegates_the_spa_suite.py:327`), and the stage-command pin calls `_normalise` directly (lines 386/389, compared at line 586), so it cannot see a whitespace change inside a quoted shell string either. For SHELL text that is the more consequential of the two residuals, which is the opposite of what the old ordering implied. The sentence now says NEED NOT transfer, names the one that does, and puts the string-literal blindness on `_normalise` where it originates. The vite-only fact that survives is the blank-line drop, and the claim that the test STATES its residual is narrowed to the vite test, which is the only one of the two that does. The hole is dormant rather than live — no entry in `PINNED_STAGE_COMMANDS` carries a quote character — but the defect was the prose universal, which the record's own rule ("a pin also declares its NORMALISATION and what the normalisation cannot see") is what this paragraph exists to demonstrate. This is the third finding read off this one sentence: `b8dc321af` corrected its fault-message half and `4d5bd0dbb` its outcome-claim half. TWO OBLIGATIONS ARE OWED to the closing record, both blocked on #885 (open, so this branch does not touch `scripts/tests/`), and both freed together when it closes: 1. The `CLAIMS` entry in `scripts/tests/mutation_manifest.py` for the hook-preamble selector — target `.claude/hooks/decisions-guard.sh`, clause = the canonical sink assignment, replacement = that line plus the `eval` spelling, proof = a `test_hook_fire_log.py` node, outcome=GREEN with the mandatory `reach_replacement`/`reach_expect`. Until then `mechanics:` states the SELECTOR as a structural fact and makes no outcome claim (`4d5bd0dbb`). 2. The comment at `scripts/tests/test_hook_fire_log.py:153-154`, which ends "this arm's errors are refusals, never acceptances". The structural fact this record ships — the compared set is the non-comment-led lines containing the literal `ETV_HOOK_FIRE_LIB`, so a reassignment that never spells the literal is outside the selection — is an ACCEPTANCE by that arm, and the same comment block concedes the class five lines later ("so it is an acceptance hole, not only a stricter refusal"). The sentence is owed a correction; the record documents the residual beside it in the meantime. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:59:16 +02:00
timothyandClaude Fable 5.1	761a71278d	docs(901): pay for the two corrections by tightening the prose around them ... The two corrections added four prose lines to a record already one line over the 60-line advisory ceiling. Recover what can be recovered without losing substance: reflow the paragraphs, drop the padding ("and it fails silently" → ", silently"; "the count rises" → "and rises"), and cut one restatement. It lands at 65 lines, not 60. That is a deliberate stop: the remaining candidates are the *why* behind non-obvious choices — which the repo's own docs rule says to keep — and `decisions_validate` reports the constant itself as drifted from the distribution it is supposed to mark the tail of (p90=104, p95=142, 50 of 222 records over it). The validator passes. Refs #901 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:59:16 +02:00
timothyandClaude Fable 5.1	0977f04174	docs(901): the respelling-immunity thesis is bounded by the pin's REACH, and the neighbour doc declines the rule it was cited for ... Two prose overclaims in the new record, both of the shape the record itself exists to police. The thesis sentence generalised over the two worked pins and held for one. `PINNED_VITE_CONFIG` compares a whole file, so no respelling escapes it; the hook-preamble pin compares a SELECTION (`test_hook_fire_log.py:161` keeps only the lines containing the literal `ETV_HOOK_FIRE_LIB` that are not comment-led), so it must recognise a line before it can reject it — which is exactly the residual `mechanics:` documents four lines later. Bound the immunity to what a pin COMPARES and name the leftover exposure as the selector's reach. The neighbour citation claimed `docs/defect-shapes-773.md` §4 "argues the general form". §4 is a ranked table of detectors A-G — none of them this rule, and A is already assigned to `guard-derives-population-from-source` by the preceding clause. The doc's nearest class is `string-predicate churn` in the §3.6 partition, marked `no detector proposed`, and §3.7 argues the class away as a cross-cutting property (2 of 33 round-churn records). Only §4's closing meta-finding — class-level rules beat one record per instance — supports anything here, and it supports the FORM, not the content. Say that. Refs #901 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:59:16 +02:00
timothyandClaude Fable 5.1	c67b33cdcd	docs(901): a mutation OUTCOME is a manifest entry or it is not written — state the selector instead ... Round three, blocking. The record's `mechanics:` field asserted a measured mutation outcome — that appending an `eval` which composes `ETV_HOOK_FIRE_LIB` at runtime leaves `instrumentation_faults` returning `[]`, identical to the unmutated baseline — with no `CLAIMS` entry in scripts/tests/mutation_manifest.py. `testing.mutation-claims-are-executed` as amended by #881 puts a prose claim about a mutation's outcome under the executed-claim rule wherever it is written, a decision record included, and this branch's own docs/README.md row restates that. A record whose rule text requires "each defeat the matcher claims to catch is a DECLARED, executed mutation" cannot itself carry an undeclared one. scripts/tests/ is held by #885, which is open, so the entry cannot be added here. What replaces the outcome claim is the structural fact that carries the same point and needs no execution: the compared set is the lines containing the literal `ETV_HOOK_FIRE_LIB` that are not comment-led, so the pin reaches exactly the two preamble lines and a later reassignment which never spells the literal is outside the selection — whatever the checker then returns. The `CLAIMS` entry is owed once scripts/tests/ is free. Three more from the same round: - `_normalise_lines` was a universal over three pins that holds for one. The stage commands compare through `_normalise` (continuations joined, whitespace within one command collapsed); the script map is dict equality over parsed JSON and compares no text; only PINNED_VITE_CONFIG uses `_normalise_lines`. The three are now stated separately, with the note that a residual read off one does not transfer. - docs/guard-inventory.md's pointer restated the "shell or config TEXT" framing the record exists to reject. It now says what the record says: an artifact with a grammar the predicate does not implement. - Rider 1 stated vite's DEFAULT_CONFIG_FILES ordering unbound to a version. The ordering belongs to a release and expires with one, so the record cites the guard-inventory row rather than keeping a second copy, and that row now dates the reading and names the release web/package-lock.json pins. Refs #901, #891, #887, #881, #885 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:59:16 +02:00
timothyandClaude Fable 5.1	17c65005f5	docs(901): the hook pin is a pin WITHIN a selection, and the selection has a measured escape ... The record's own rule ends: a pin also declares its NORMALISATION and what the normalisation cannot see, because "pinned whole" invites a reader to assume byte equality. The `mechanics:` field did that for the image-build pin (it names `_normalise_lines` and what it drops) and not for the hook pin, which it described only as pinning two lines byte for byte. The comparison at scripts/tests/test_hook_fire_log.py:161-167 is over a SELECTED set — lines containing the literal `ETV_HOOK_FIRE_LIB` that are not comment-led — so byte-identity holds within the selection and says nothing about a writer of that variable spelled without the literal. MEASURED 2026-09-05 on this branch against `.claude/hooks/decisions-guard.sh`: appending eval "$(printf %s%s=/dev/null ETV_HOOK_FIRE _LIB)" after the canonical assignment leaves `instrumentation_faults(text, 'decisions-guard')` == `[]`, byte-identical to the unmutated baseline `[]`, while running those two lines under bash prints `final=/dev/null` — the sink is repointed and the checker is silent. A false GREEN, which is the failure direction this record exists to argue about. The residual is #891 code and is not introduced here; no code changes. What changes is that a record citing this file as one of its two worked pins now states the residual instead of implying byte equality over the file. Refs #901, #891 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:58:48 +02:00
timothyandClaude Fable 5.1	78593ace9f	docs(901): a quotation that resolves to nothing, and a universal over three pins that holds for two ... Two review findings, both the class this record is about: prose that claims more than the artifact says. The neighbour-record citation presented a paraphrase in quotation marks. `testing.guard-derives-population-from-source` line 96-97 reads "when the authoritative source is missing, the answer is to create one, never to approximate it with a predicate over text"; the record quoted it without "the answer is to" and without the second "to", so a fixed-string lookup of the quoted span found nothing anywhere under docs/ — #812's second defect, which `testing.mutation-claims-are-executed` names explicitly. The quote marks are gone rather than repaired: the source sentence spans a line break, so any single-line verbatim quotation of it would still not resolve by grep, and an open paraphrase claims only what it is. The `mechanics:` field said the image-build pins fail with a message naming the constant to update. Measured against scripts/tests/test_image_build_delegates_the_spa_suite.py: PINNED_STAGE_COMMANDS (line 589) and PINNED_VITE_CONFIG (line 798) name themselves, PINNED_PACKAGE_SCRIPTS (lines 757-763) does not — it names the FILE and prints both maps. 423bf94e7 corrected this same sentence for the hook half after verifying it and left the image-build half an unverified universal. The first replacement drafted here read "all four faults ask for the reason in the same commit", which is false a second way: the hook-preamble fault (test_hook_fire_log.py lines 162-167) asks for no reason at all, it reports got={mentions}. The shipped sentence is scoped to the three pins whose fault messages were read. Refs #901 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:58:48 +02:00
timothyandClaude Fable 5.1	4c2ceccaf7	docs(901): carry both rejected alternatives in the rule, not only in the body ... The catalog renders `rule:` alone, so a reader resolving this by topic saw the two decisions without the alternatives they rejected — which is what stops a rejected option being re-proposed on plausibility. Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:58:48 +02:00
timothyandClaude Fable 5.1	87d90f330c	docs(901): the hook-preamble fault does not name a constant — correct the mechanics claim ... The record asserted both worked pins fail with a message naming the constant to update and asking for a reason. True of `test_image_build_delegates_the_spa_suite.py`'s three pins; false of `test_hook_fire_log.py`, whose byte-identity fault reports the divergent `mentions` list and names no constant. Verified against both files rather than inferred from the neighbouring one. Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:58:48 +02:00
timothyandClaude Fable 5.1	0f4552d093	docs(901): pin the artifact whole is the DEFAULT for a predicate over a grammar it does not implement ... Two predicates over artifacts with a real grammar were each defeated by successive spellings and withdrawn in favour of pinning the artifact whole: #887's shell parse (nine defects from one mechanism, then seven more against a partial match of web/vite.config.ts) and #891's lexical rule over the hook preamble (five spellings). Both incidents carry a record; neither is resolvable by topic before round three, which is what this class-level record adds. Decides the two questions #901 left open: - DEFAULT, not remedy. A shape-matcher's failure is a false GREEN, so the defeat that would trigger a remedy policy is found by a reviewer or an incident and never by the guard: "not defeated yet" measures who has looked. Rejected: write the matcher and pin after the first defeat — it also understates its bill, since a withdrawal costs the rounds spent AND the proofs calibrated against the narrow clause. - The exception argument carries FOUR things: the grammar and its parser; the input space as a closed enumeration with the reason it is closed; the fail direction measured as a declared, executed mutation; and what it buys priced in a cost the pin charges. Rejected: a numeric "survives N spellings" bar (measures the reviewer's imagination) and a reviewer sign-off bar (depends on the signal that arrives late). Records both riders (a pin assumes it pins the artifact that still DECIDES; widening a clause turns a survived-clause canary into a tautology) and states the threshold as the moment the NEXT spelling is found by the reviewer rather than the author. docs/README.md's guard-convention task-signal row points at the record; catalog regenerated; 59 prose lines, under the 60-line advisory ceiling. fixes #901 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:58:48 +02:00
timothyandClaude Fable 5.1	61ed6a7955	test(885): exercise REGISTRY_PASSWORD at both if: levels, re-confirm the layer measurement ... Round-nine's bare-if fix table paired each secret name with only one level (job for REGISTRY_PASSWORD, step for RENOVATE_TOKEN), so the exact REGISTRY_PASSWORD-at-step-level and RENOVATE_TOKEN-at-job-level cases the finding named were never driven. All four combinations now run. The decision record's anonymous-layer-download closure read as reporting a past run without saying who ran it. Re-measured directly this session (2026-09-05, no stored credential): anonymous token -> pinned manifest's first layer -> 200/32991280 bytes, same GET with no token -> 401. Record updated to say the leg was re-confirmed, not merely "measured...since". Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:15:44 +02:00
timothyandClaude Fable 5.1	d793342f50	docs(885): a condition NAMES a secret without exporting it, and is faulted for naming it ... The `if:` clause reads the one site whose reference the evaluator resolves without materialising anything into the job environment, so a reader can reasonably ask why it faults. Both the function and the record now say: the predicate is "names a stored secret", never "exports one" — on the head-authored route the contributor picks the comparison, which makes a condition an oracle over the value, and a predicate about exposure would have to model what each site does with its reference and give up the structure-blindness that saw `toolchain-preflight`'s step `env:` when a `container:`-shaped predicate did not. Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:15:43 +02:00
timothyandClaude Fable 5.1	47a5582443	docs(885): the record names the spelling the scoping costs, and the layer leg is measured ... Two corrections to `ci.pr-route-carries-no-stored-credential`, both about claims that read as checked and were not. The `rule:` said the detector reads every spelling "only inside a `${{ }}` span", and the body enumerated `secrets: inherit` as the ONE shape left uncovered. An unwrapped `if:` is a second, and it is a shape this repo writes: both now name it, and say the value of an `if:` is read whole. `mechanics:` listed an anonymous LAYER download among two things the daemon probe did not exercise. Measured 2026-09-05 from a workstation holding no registry credential: the anonymous pull token reads the pinned manifest's first layer `sha256:179c68a720750ab4d354f6b55c0a9f551d4fd7bde93606dd0be79ba16493a39e` -> HTTP 200, 32991280 bytes, and the same GET with no token -> 401. act_runner's own pull call path is the one leg still unexercised. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:15:43 +02:00
timothyandClaude Fable 5.1	d4c00f7567	docs(885): the handover clause states its own unprobed reachability, where the rule is read ... The code banner and the test docstring say that whether act_runner on this instance resolves `workflow_call` + `secrets: inherit` was not probed, and why that is acceptable — it governs reachability today, not the guard's silence. The record stated the clause without that bound, so a reader who meets the rule through the catalog rather than through the file met a confidence claim the source deliberately does not make. Refs #885 Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:15:43 +02:00
timothyandClaude Fable 5.1	c325cd6ee4	fix(885): a handover written in the YAML grammar names no secret, so the guard reads the KEY too ... The detector was exhaustive over the `${{ }}` expression grammar and blind to `jobs.<id>.secrets: inherit` on a `uses:` job, which passes the caller's whole store to the called workflow while naming nothing. `secret_refs` reads only inside expression spans — correctly, since outside one `secrets.` is a full stop — and `inherit` is a plain scalar, so such a job was put in the derived population by `pull_request_jobs`, walked, and reported CLEAN. Measured against the predecessor: stored_secret_faults('synthetic.yml', {True: {'pull_request': None}, 'jobs': {'reused': {'uses': './.gitea/workflows/reusable.yml', 'secrets': 'inherit'}}}) -> [] ... the same job with secrets: {TOK: '${{ secrets.RENOVATE_TOKEN }}'} -> 1 fault so the miss was specific to the VALUE SHAPE, not the key. That is the failure the done-condition names — a new job joining the population unprotected without reddening anything — in a guard whose stated selling point is exhaustiveness over the grammar and no exemption list. `opaque_secret_handovers` now faults a `secrets:` key whose value is not a mapping of names, under the existing `secrets.*` whole-context sentinel, and both fault sites read through one `held_secret_names` so the workflow scope and the job subtree cannot drift on which references are forgiven. The test is on the value shape and not on the word `inherit`, for the reason the residue counter is not a match on `toJSON`: any non-mapping value hands over a set the guard cannot enumerate, a spelling act_runner grows later included. Both halves of the predecessor measurement are re-derived every run rather than left as prose: the new test asserts `secret_names(job) - INJECTED_SECRETS` — the collector verbatim as it read before this clause — empty on the same fixtures it asserts the fault on, and asserts the job is in the population. Reverting `held_secret_names` to that expression reddens that test and only that test (measured: 1 failed, 18 passed). The clause reads the DOCUMENT only and the text-versus-walk cross-check cannot cover it — there is no expression for its half to match, which is a stronger reason than the shared-blind-spot one the cross-check already discloses. Said at the definition, in the cross-check's "STRUCTURALLY CANNOT REPORT" paragraph, and in the record, rather than left to be discovered; it does not redden the cross-check either, since the clause feeds the fault collector and not `secret_name_counts`. Whether Gitea 1.27.1 / act_runner resolves `workflow_call` + `secrets: inherit` on this instance was NOT probed — that affects reachability today, not the guard's silence, and the direction is the one the spelling rows already take. No tracked workflow uses a job-level `uses:`, so nothing reddens. Refs #885 Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:15:43 +02:00
timothyandClaude Fable 5.1	fe05526ef4	fix(885): the tag rule this branch added is dated where it is asserted ... `release.main-direct-push-disabled` was edited on this branch to note the new `v*` tag protection, and picked up two of the defects the round was hunting elsewhere. Its `rule:` said the `renovate` bot "can no longer push a tag that publishes `:prod`" as settled fact, while `release.tag-protection-v-star` records that exact claim as NOT VERIFIED and `docs/ci-cd.md` was already corrected to EXPECTED, UNVERIFIED. Only the `timothy` credential exists in a working session, so neither a real release cut nor a refused bot push has been exercised; all three now agree on confidence. Its `mechanics:` still read "`GET .../tag_protections` returns `[]`" in the present tense — the one fact this branch changed, and the one site an otherwise complete sweep left behind. Read back live today the endpoint returns one rule, `v*` whitelisted to `timothy`. The clause is now past tense and bound to its probe date, with the current state named. Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:15:43 +02:00
timothyandClaude Fable 5.1	fa06da21f3	fix(885): the guard states both invariants, and the second one is executed ... The two `docs/guard-inventory.md` rows and the module docstring described `test_workflow_persist_credentials.py` as the `actions/checkout` guard only. The deferral to #909 rested on `docs/guard-inventory.md` being held by the session working #881; that issue is closed and its PR is the commit this branch is rebased onto, so the file is free and the edit belongs here under docs-update-is-part-of-done. `MUTATIONS` keys at most one declared clause mutation per guard FILE (`test_the_manifest_covers_exactly_the_MUTATION_rows` asserts `len(MUTATIONS) == len(declared)`), and the grading row's proof-ref column is compared against it, so the route invariant cannot take a second `MUTATIONS` row. It takes a `CLAIMS` entry instead — the population #881 widened this file to carry — bound to the inventory sentence that states it: deleting `build`'s `if: github.event_name != 'pull_request'` from the shipped `docker-build.yml` is applied to a sandbox copy every run and the named proof is required to redden with the collector's own wording. That grows the `CLAIMS` population from three entries to four, which invalidates the cost span `testing.mutation-claims-are-executed` measured over three. Re-taking it here produced 54.3s/149.5s, 81.6s/78.7s and 114.3s/84.2s across three A/B pairs with other builds on the host — two inverted, so the load dominates the signal. The record now says the span is a lower bound and that a re-measurement is owed on a quiet machine, rather than carrying a scaled or invented number. Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:15:43 +02:00
timothyandClaude Fable 5.1	af9c2349a7	fix(885): three claims this branch added, dated to what was actually measured ... `review-verdict.yml`'s residual list said the injected `GITEA_TOKEN` on the `pull_request` route is BOUNDED by `docker-build.yml`'s workflow-level `permissions: code: read`. That block lives in the head-supplied file on exactly that route: a PR author deletes it, and with the owner-level Actions default at `permissive` that alone yields a write-capable token. It is NARROWED for the committed file, and it stays in the residual set the paragraph exists to enumerate — which is what `release.verdict-status-check` and `test_pr_changed_files.py` already say. The same reword lands in `ci.pr-route-carries-no-stored-credential`, where the allow-list reason is now the store the token is not in rather than a bound. The "dies at image pull in 1-2s" figure was never measured on this branch — the 1-2s in `ci-toolchain-image-resolves.sh`'s header is an observation from the #772 incident, not a property of this change. The loud/silent asymmetry is what carries the argument, so the claim is now that a container job dies at image pull before it runs a step, which is true by construction. `ci.actions-credential-scoping`'s reworded `mechanics:` said "all three are now confined to the `build` job". `build` declares no `container:` at all; the buildcache write and the base-image pull are what it confines, and the `container:` pull is credential-free everywhere. `docs/ci-cd.md` asserted the `renovate` bot can no longer push a `v*` tag while `release.tag-protection-v-star` records that as NOT VERIFIED. The rule is read back live and real; what is unmeasured is Gitea honouring it against an account only the operator can test. Both docs now say expected, unverified. Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:15:43 +02:00
timothyandClaude Fable 5.1	dd836c1f46	fix(885): the swept symbol's last live-voice site in the dispatch record ... The same-subject sweep that past-tensed `ETV_STATUS_AUTH` and this record's own `rule:` field left the record BODY saying `toolchain-preflight` takes the registry credential "via `ETV_REGISTRY_AUTH`" in the present tense — a symbol this branch removes from every workflow, so the body contradicted the `rule:` field of the same record. Container-free and `runs-on: small` are still true today and stay in the present tense; only the credential clause moves to the past, matching the `rule:` field's "took the credential through `ETV_REGISTRY_AUTH`". Body-only, so the generated catalog is unchanged (regenerated to confirm). Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:15:43 +02:00
timothyandClaude Fable 5.1	23cef5c9d1	fix(885): two dependencies with opposite failure directions, and a token leg that got zero retries ... The header comment and the record's `rule:` said the registry reads and the commit-status reads "both depend on `timothy/ersatztv` and its `ersatztv-ci` package staying PUBLIC; making either private fails those jobs loudly at image pull, never silently". Wrong in both clauses for the repo half, and this branch has already been sent back twice for exactly this shape of mechanism claim. Measured 2026-09-05: the `ersatztv-ci` package is linked to no repository (every version reports `"repository": null`), so the repo's visibility does not gate the anonymous pull token at all; and the only thing it does gate — the combined-status GET — fails in the opposite direction, because `ci-detect-already-validated.sh` answers a failed `curl -sf` with `emit false; exit 0`. That job stays GREEN and the #420 cross-run skip silently stops firing. So the two dependencies are now stated apart, each with its own failure direction, in `docker-build.yml`, in the preflight's header, in the record and in the `ci-cd.md` outcome table; the preflight's own 401/403 messages stop sending an operator to the repo's visibility when it is the package's. `token_leg_done` was set once per RUN, before the attempt, so a token endpoint that could not be reached failed the preflight with no retry while an identical blip on the manifest read got three. The stated reason — "a registry genuinely refusing anonymous reads is asked once rather than once per pin" — is a per-pin argument that never covered the per-attempt axis. It is now sorted by what the endpoint SAID rather than by which leg it happened on: an answer (no token in the body, a challenge naming no realm, no challenge at all) settles the question and is asked once per run; an endpoint that could not be reached, or that answered 5xx, settled nothing and is retried on the same `ETV_CI_ATTEMPTS` budget as the manifest read, because a red here denies a merge (the consent hook reads the COMBINED status, #598) and the two legs of one read must not have opposite flake tolerances. The token-leg message now reports the attempts it actually made. Driven against the SHIPPED predecessor rather than a hand-written mutant: the three new behavioural assertions are red on it (1 token call where 3 are required, and a blip shorter than the budget failing the run), while the two that pin the property the retry must not cost pass on both. Refs #885 Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:15:43 +02:00
timothyandClaude Fable 5.1	8885fdd9d2	fix(885): the swept symbol's last live-voice site, and a caveat that is now a measurement ... `ETV_STATUS_AUTH` is gone from `test`, `migrations` and `functional-e2e`, and three same-subject sites were reworded to match. `review-verdict.yml`'s comment was the fourth and still named the symbol as a live thing; it now names the credential by what it is, and says the PR route materialises none to refuse. `docs/remote-state-inventory.md`'s row for `ci-toolchain-image-resolves.sh` listed "an unusable credential" among the shapes that fail the job — that script holds no credential any more. The row names the three refused-anonymous-read shapes the shipped script actually has instead, and re-confirms the `UNSAFE-KNOWN` grade against the anonymous script: the tag it reads is mutable either way. That is #909's first half; its other half, `docs/guard-inventory.md`, stays with the session holding that file. `ci.pr-route-carries-no-stored-credential`'s `mechanics:` carried one self-declared unmeasured claim — whether act_runner's daemon performs the credential-free `container:` pull. Measured 2026-09-05 on the runner host 192.168.1.99, which runs both act_runner containers and creates every job container on its own docker socket: a `docker pull` of the pinned tag with a scratch docker config holding only `{}` exits 0. The two things that run did not exercise — an anonymous layer download, and act_runner's own pull call path — replace the open unknown rather than being dropped, and `docs/ci-cd.md` cites both measurements. Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:15:43 +02:00
timothyandClaude Fable 5.1	383171dfa4	fix(885): a detector that knows ONE spelling is one an added job writes around ... `secrets['REGISTRY_PASSWORD']` is the same reference to the expression evaluator as `secrets.REGISTRY_PASSWORD`, and the guard shipped here could see only the dot form. Measured 2026-09-05 against the predecessor of this commit, a `pull_request`-route job whose `env:` read `"${{ secrets['REGISTRY_PASSWORD'] }}"` produced `stored_secret_faults(...) == []` AND `walk_versus_text_faults(...) == []` — the text cross-check cannot report the gap, because both of its halves resolve references through the one pattern, so a spelling it does not know is a shared blind spot they agree at zero on rather than a disagreement they name (`proof-sharing-with-subject-proves-nothing`). The file enumerated four other blind spots it has — composite actions, reusable workflows, nested directories, both directions of the comment strip — and not this one, which is what made the omission read as coverage. `secret_refs` is now the single entry point for both halves, and it matches the dot form, both index forms and a case-varied context, then counts the RESIDUE: any `secrets` token inside a `${{ }}` span that yielded no literal name is reported under the sentinel `secrets.*`. Counting the residue rather than pattern-matching `toJSON(secrets)` and a computed index is what makes it exhaustive over the grammar — a spelling nobody has written yet still faults, in the fail-closed direction. The bare word is read as the context only inside an expression, because in prose it is ordinary English; this file and four workflows discuss "secrets" in comments. `test_the_collector_sees_every_SPELLING_of_a_secret_reference` drives the six spellings through the collector and the cross-check and asserts each is invisible to the real predecessor, so reverting the widening reddens it. Whether act_runner resolves each spelling against this instance was not probed from here (that needs a live run); the direction makes that acceptable — a spelling the runner does not support costs a spurious demand on a job nobody has written, the omission cost a live write-capable credential on the head-authored route. Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:15:42 +02:00
timothyandClaude Fable 5.1	fba895852c	fix(885): the two named records state the invariant this branch actually ships, not the job-only half ... `ci.workflow-dispatch-ref-unrestricted` and `ci.actions-credential-scoping` are the two records the issue requires be updated to match, and both restated the invariant as "every job of a `pull_request`-triggered workflow that names a `secrets.*`". That was the shipped predicate when they were written and is now narrower than what the guard holds: the workflow scope outside `jobs:` is judged too, because a root `env:` or `defaults:` is materialised into every job and no job-level `if:` reaches it. A record that understates its own guard is the failure this repo grades worst — it reads as a checked description and stops the next reader looking. `ci.pr-route-carries-no-stored-credential` also names the two inventory rows that this issue made incomplete and did not edit, because both files are held by concurrent changes: `docs/remote-state-inventory.md` still lists "an unusable credential" among the shapes that fail the preflight, and `docs/guard-inventory.md` still describes `test_workflow_persist_credentials.py` as the `actions/checkout` guard alone. Neither goes red — both suites assert set equality over FILES and both files were already listed — so the carry is tracked as #909 rather than left to be discovered. Refs #885, #909 Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:15:42 +02:00
timothyandClaude Fable 5.1	b71bf4d7b2	fix(885): a name SET cannot see a second copy, so the PR-route guard judges the workflow scope and the cross-check COUNTS ... The shipped guard walked `jobs.<id>` only and leaned on a text-versus-walk cross-check to catch anything the walk could not reach. That cross-check compared per-file NAME SETS, and the two halves cancelled on the one file the invariant is about: measured 2026-09-05 at 59003d5a3, hoisting env: ETV_REGISTRY_AUTH: ${{ secrets.REGISTRY_USER }}:${{ secrets.REGISTRY_PASSWORD }} into `.gitea/workflows/docker-build.yml`'s root `env:` — which materialises into EVERY job on the head-authored PR route — left `pytest scripts/tests/test_workflow_persist_credentials.py -q` at `14 passed`, rc=0. The same hoist in `pr-checks.yml` reddened, because no job there already names those secrets. The guard could only ever see a name NO job used; a second copy of a reference `build` legitimately keeps naming changed no set. That is `dont-keep-a-copy-of-a-set` / `proof-sharing-with-subject-proves-nothing`: the proof shared its accumulator with its subject and cancelled. Two changes, because the cross-check was being asked to do the assertion's job: * the workflow scope (everything outside `jobs:`) is now judged in its own right by the same structure-blind collector — it is a second entry site on equal footing with the job subtree, not an edge case, since no job-level `if:` can take a root `env:`/`defaults:` off the route; * the cross-check walks the whole document and compares occurrence COUNTS. A duplicate at an unreachable location now reddens: probed 2026-09-05, a trailing `# ${{ secrets.REGISTRY_PASSWORD }}` on a root `env:` line reports `walk [('REGISTRY_PASSWORD', 1)] vs text [('REGISTRY_PASSWORD', 2)]` where the set version agreed. Under counting the comment strip becomes load-bearing rather than the no-op the old docstring admitted it was. Driven by a mutation on the SHIPPED `docker-build.yml`, the way the `build`-loses- its-`if:` mutation already is, plus a direct assertion on the two collectors that a duplicated reference changes the count and not the names. Witnessed red with the hoist in the tree (3 failed) and green without it (17 passed). The decision record's own claims were false in the same way and are corrected: `rule:` said "NO job ... may name a stored secret" (a root `env:` is not a job) and the prose said "a text-versus-walk cross-check reports any reference the walk cannot reach". Refs #885 Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:15:42 +02:00
timothyandClaude Fable 5.1	7355873c39	fix(885): a head-authored run may hold no stored secret, so the PR route reads the registry and the status API anonymously ... `docker-build.yml` triggers on `pull_request:`, which Gitea resolves from the PR HEAD, so that run executes contributor-authored YAML and every `secrets.*` it names is materialised into it. Six jobs held `REGISTRY_PASSWORD` that way — `toolchain-preflight`, `test`, `migrations`, `functional-e2e`, `api-docs`, `format` — two of them branch-protection required contexts. The read-only pull PAT the issue asked to cost first was REJECTED, and the measurement is the reason: this registry already issues an anonymous pull token for `timothy/ersatztv-ci` (`GET /v2/token?scope=repository:timothy/ersatztv-ci:pull` -> 200), that token reads the pinned manifest and its config blob (200/200), and the combined-status GET answers 200 unauthenticated. A read-only PAT would grant exactly what anonymity grants while adding one more credential to the store head-supplied YAML reaches. So the stronger form was implemented instead: no PR-route job names a stored secret at all. - `.gitea/workflows/docker-build.yml`: the five `container: credentials:` blocks, the `ETV_REGISTRY_AUTH` step env and the three `ETV_STATUS_AUTH` step envs are gone. `build` keeps the PAT; it is gated `if: github.event_name != 'pull_request'`. - `scripts/ci-toolchain-image-resolves.sh`: reads `realm` out of the `Www-Authenticate` challenge, exchanges it once per run for an anonymous pull token, retries with the bearer. Every refusal direction is preserved — a 401/403 after the token leg, a token endpoint yielding no token, and one that cannot be reached all `fail` rather than degrading to could-not-tell — and the message now names the cause an operator can act on (the repo or package has stopped being public). - `scripts/ci-detect-already-validated.sh`: the status GET is anonymous. No credential override is kept: the URL names one instance, that instance is public, and an unusable `":"` would draw a 401 and turn a working read into a permanent skip=false. - `scripts/tests/test_workflow_persist_credentials.py`: the invariant, derived from the git index by "every job of a `pull_request`-triggered workflow that names a `secrets.*`" — never the six-name list, and never "every `container:` job", which names five of six because `toolchain-preflight` is container-free. Witnessed red against the unfixed workflow naming all six jobs; green after. Live tag protection applied and read back: `POST /repos/timothy/ersatztv/tag_protections` `{"name_pattern": "v*", "whitelist_usernames": ["timothy"]}` -> id 1. A non-`v*` probe tag pushed and deleted proves tag pushes still work at all. The POSITIVE release-cut verification is DEFERRED to the operator's next real cut: pushing a `v*` tag publishes the `:prod` image, which is a release, not a verification step. What this does not close, stated so the records are not cited as a boundary: `REGISTRY_PASSWORD` stays in the Actions store for `build`, and head YAML can still name it, `RENOVATE_TOKEN` or `SERVERMGMT_DEPLOY_KEY`. Blast radius, not the route. New records `ci.pr-route-carries-no-stored-credential` and `release.tag-protection-v-star`; `ci.workflow-dispatch-ref-unrestricted`, `ci.actions-credential-scoping` and `release.main-direct-push-disabled` updated to match; catalog regenerated. Closes #885. Decisions-Edit: yes Proves: scripts/tests/test_workflow_persist_credentials.py::test_no_PULL_REQUEST_route_job_names_a_STORED_secret Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 15:15:42 +02:00
timothyandClaude Fable 5.1	595c819de1	fix(916): a failed substitute is an error, not a landed claim; head_sha described in both schemas; the issue's box says what the code does ... The runner-beside-the-lenses design is now what Done-when box 1 asks for (body amended). A rubric round whose runner and worktree fallback both fail returns an error before the push instead of landing a PR whose body claims a substitute reviewed it. The harness records lens count at the runner's start too (expects 0, so a re-serialised runner reddens), resets its counter per round, and has a case for the double failure. Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 13:14:09 +02:00
timothyandClaude Fable 5.1	929dff835a	fix(916): the Codex runner runs beside the lenses, only the fallback waits; head_sha described everywhere; the docs keep their thresholds ... The runner builds nothing, so serialising it only added its wait to the critical path; the worktree-isolated fallback is what must follow the lenses, and the harness case now records lens count at the FALLBACK's start alone. setTimeout in the harness is globalThis.setTimeout (the .mjs lint config has ES builtins only). head_sha carries the same description in both scripts and every fixer/implementer prompt asks for the worktree HEAD, not a PR head. The mechanics page says why the cap stays at one after the serialisation and restores the 20%/10% RAM thresholds by key; the record says "several", not "three". Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 12:43:58 +02:00
timothyandClaude Fable 5.1	4454f1adfc	docs(563): anchor the measurements to the issue, which a squash merge cannot erase ... The paragraph added a commit ago pointed at "the commit messages that ran them" as the home of the binder and `trim` mutant outcomes. A squash merge writes its own message and drops the bodies it squashes, so that pointer can go stale the moment this branch lands. The issue and its pull request survive it, and #563 is where the round-by-round measurements already are. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 09:36:56 +02:00
timothyandClaude Fable 5.1	3df98d247f	docs(563): state each binder test's mechanism instead of its mutant colour, per the amended CLAIMS rule ... `testing.mutation-claims-are-executed` was amended on main while this branch was in review (#881, merged as #914): a sentence asserting that a specific mutation reddens — or does not redden — a named test is now either a `CLAIMS` entry in `scripts/tests/mutation_manifest.py` that executes every run, or it is not written. This branch carried six such sentences and none of them can be declared: `Claim.node_id` resolves a proof to `scripts/tests/<node id>` and `run_pytest` invokes pytest, so an NUnit proof has no representation in that harness at all. Durable prose now states the mechanism each test is built on — which serializer difference, which engine branch — which a reader re-checks by reading the code rather than by trusting a remembered outcome. The record says that in one paragraph, so the limit is stated rather than papered over. The outcomes themselves are here. Re-measured 2026-09-05 on this branch's tree (the commit before this one), each mutant applied to the working tree and restored from the index between runs, tree verified clean afterwards: positive control ScriptedScheduleControllerTests Passed: 9, Failed: 0 OpenApiSerializerContractTests Passed: 4, Failed: 0 Bind<T> -> System.Text.Json with JsonSerializerDefaults.Web Failed: 2, Passed: 7 — Production_Body_Binder_Ignores_Required_Members, Production_Body_Binder_Keeps_Declared_Defaults_Over_An_Explicit_Null BodyBinderSettings = ApiJsonSettings.Create() -> new JsonSerializerSettings() Failed: 1, Passed: 8 — Production_Body_Binder_Keeps_Declared_Defaults_Over_An_Explicit_Null OpenApiSerializerContractTests RuntimeSettings -> new JsonSerializerSettings() Failed: 4, Passed: 0 — all four cases, on PascalCase keys ScriptedScheduleController AddDuration(..., request.Trim, ...) -> false Failed: 1, Passed: 8 — Committed_Script_Fixture_Produces_The_Pinned_Snapshot ScriptedScheduleController PadUntilExact(..., request.Trim, ...) -> false Failed: 1, Passed: 8 — Committed_Script_Fixture_Produces_The_Pinned_Snapshot The last one is the round-two finding closed and re-witnessed: before the fixture's pad target moved off the content boundary, that mutant left all nine green. A squash merge writes its own message, so these figures also belong in the PR description. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 09:31:42 +02:00
timothyandClaude Fable 5.1	d6e4426aa9	docs(563): retire the forward-references the supersession falsified, and trim the record to what only it says ... Two pointers still named #563 as the open reason scripted playout has no coverage. The ContentEnumeratorBuilderTests header now points at the successor record and docs/testing.md instead of the issue this branch closes. docs/decisions.md carried an orphaned fragment, "external-process pipeline remains #563's", in the residual block under ## Index -- with the pipeline now permanently outside the automated suite rather than deferred, the fragment states something false and has no recoverable subject to rewrite it around, so it goes. The record's rule gains the two things measurement settled: that ApiJsonSettings shares production's configuration and never MVC's settings object (MaxDepth 32, the two ProblemDetails converters, pinned by ApiJsonSettingsTests), and that a fixture must aim every trimming instruction between two content boundaries or that action's trim argument is witnessed by nothing. Its body loses the mutant table and the extraction paragraph, which the mechanics doc its own frontmatter points at carries verbatim; what remains is the conclusion plus the reasoning that exists nowhere else. 70 prose lines to 56, under the advisory ceiling without dropping a distinct finding. Refs #563 Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 09:25:11 +02:00
timothyandClaude Fable 5.1	c0a70d724a	test(563): witness the Newtonsoft half of the binder claim, and narrow the prose to what reddens ... The branch asserted that binding fixture bodies through ApiJsonSettings makes "a swap to a lookalike serializer" redden. Measured, only half of that was true: replacing ScriptedScheduleControllerTests' BodyBinderSettings with a plain `new JsonSerializerSettings()` -- a Newtonsoft lookalike that has lost the production configuration -- left all 8 tests green. Only the System.Text.Json swap reddened. So the production edits the branch makes for that coupling (ErsatzTV/Serialization/ApiJsonSettings.cs and the Startup rewrite) were justified in four places by a hazard no test could see. Both halves are now real. Production_Body_Binder_Keeps_Declared_Defaults_Over_An_Explicit_Null binds `{"order": null}` and posts it to AddCollection: NullValueHandling.Ignore keeps ContentCollection.Order at its declared "shuffle" and the call is a 200, where Newtonsoft's own Include default writes the null through and AddCollection's Enum.TryParse returns a 400. That is a behaviour difference a script would see, not a settings-shape assertion, so it is not a second copy of the settings list. Mutants, run 2026-09-05 over the 9-test fixture: Bind -> System.Text.Json web defaults 2 red BodyBinderSettings -> new() 1 red (was 0 before this commit) OpenApi RuntimeSettings -> new() 4 red (write side, naming strategy) What still nothing observes is Startup.ConfigureServices itself: re-inlining the AddNewtonsoftJson lambda as a hand-copy of Apply reddens no test, because a byte-equal mirror is behaviourally indistinguishable. ApiJsonSettings removes the duplicate rather than detecting its drift, and docs/testing.md, the decision record and all four docstrings now say that instead of claiming a detector. Drift confined to ReferenceLoopHandling or the StringEnumConverter is witnessed by neither suite; that is stated rather than left implied. Also files the 401 blind spot the record had described as "tracked separately" while nothing tracked it. ersatztv#913 records the chain, verified from source: the filter is registered globally, EndpointRequiresKey fail-closes every mutating verb, ScriptedScheduleController carries no [SkipApiAuthorization], and neither ScriptedPlayoutBuilder nor entrypoint.py supplies a credential. Refs ersatztv#563 and ersatztv#913. Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 09:25:11 +02:00
timothyandClaude Fable 5.1	4bd5cf9e91	docs(563): scope the required-member claim to the serializer, and name model validation as residue ... The previous commit said a body omitting a `required` member "reaches the action" in production. That overreaches what was measured: MVC adds an implicit required check for non-nullable reference types (ErsatzTV.Core.Nullable has <Nullable>enable</Nullable>, and Startup configures no ApiBehaviorOptions, so the [ApiController] automatic 400 is live), which would very likely reject that body before the action. What is measured is the SERIALIZER: Newtonsoft deserializes it to a default, System.Text.Json throws. The prose in the test, ApiJsonSettings, the record and docs/testing.md now stops there and puts MVC model validation on the uncovered-wrapper list where it belongs. Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 09:25:11 +02:00
timothyandClaude Fable 5.1	16a6e2790f	test(563): bind the fixture with the production body binder, and name the wrapper that is left ... The docstring, the decision record and docs/testing.md all claimed the replay covered everything except two hops. MVC model binding was a third: production binds /api/* bodies with Newtonsoft (Startup -> AddNewtonsoftJson -> CustomContractResolver + StringEnumConverter) while the replay deserialized with System.Text.Json. Measured on this tree: for the fixture's own bodies the two agree, but for a body omitting the `required` member "collection" they diverge -- System.Text.Json throws, Newtonsoft binds Collection = null and the action runs. So the fixture's stated purpose ("field names and casing match what the HTTP body binder accepts") was asserted by nothing, and a fixture production would bind differently could still go green. Rather than only widening the residue list, bind the way production binds. The registration moves into ErsatzTV/Serialization/ApiJsonSettings.cs, Startup applies it from there, and both OpenApiSerializerContractTests (which had its own mirror of the settings) and the scripted replay now call that same function -- one definition, no copies to drift. Production_Body_Binder_Ignores_Required_Members asserts both halves of the divergence THROUGH the replay's own Bind helper, so pointing the replayer at another serializer reddens; the fixture's own bodies cannot witness that swap. The residue is now named honestly in all four places: the binding WRAPPER (input formatter, the [ApiController] automatic 400 before an action runs) is uncovered, the serializer inside it is not. Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 09:25:11 +02:00
timothyandClaude Fable 5.1	0d2cd89782	docs(563): supersede the scripted-golden deferral with the in-process coverage rule ... The deferral record described ScriptedScheduleController as a "1:1 pass-through" to SchedulingEngine. It is not: an unparseable playback order is a 400, an unparseable filler kind SILENTLY degrades to FillerKind.None, an unknown build id is a 404, and the engine's no-progress InvalidOperationException is translated to a 400. Carrying that wording forward would have shipped a false statement, so the successor states a thin adapter with named mappings, each pinned by a test. - new record testing.scripted-engine-in-process-net (active, since 2026-09-05) - predecessor testing.scripted-playout-golden-deferred git mv'd to docs/decisions/archive/testing/ with frontmatter retargeted only; body prose byte-identical, so no Decisions-Edit trailer - docs/decisions.md Index line retargeted to the archive path plus a new dated line for the successor - catalog regenerated with scripts/build_decisions_catalog.py - docs/testing.md: the Golden-file nets paragraph now points at the new coverage instead of "tracked in ersatztv#563"; a new "Scripted playout coverage" section states what is covered where and what is deliberately not covered (Cli.Wrap launch, Kestrel + Startup middleware, ApiAuthorizationFilter), dated 2026-09-05; Timezone independence records the per-call TZ audit that decided which engine instructions the fixtures may use. Refs #563 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 09:25:11 +02:00
timothyandClaude Fable 5.1	0f8e73ab05	fix(881): the replacement clause asserted an absolute I had not measured ... The previous commit replaced "the order is load-bearing" with "and that is the whole of what the order buys". What was measured is narrower: with the relevance gate moved first, the three gates are each still witnessed refusing alone. That does not establish the order buys nothing else - the reset placement is a second candidate, unmeasured either way - so the absolute is gone from both sites and what stays is the cost reason, which is readable from the control flow. refs #881 Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 07:09:14 +02:00
timothyandClaude Fable 5.1	f34828806d	fix(881): the gate order I called load-bearing is a cost choice, measured ... `verify_claim`'s docstring and the record's `mechanics` both said the relevance gate must run LAST or the status and vacuity gates could never be witnessed failing alone. Executed at ff65e5e7c: moving the `reset_sandbox` + reach `verify_mutation` + `if not reach.ok:` block ahead of both earlier gates and changing nothing else, then running `pytest scripts/tests/test_mutation_harness.py -p no:randomly -k "GREEN_EXIT_STATUS or GREEN_VACUITY or GREEN_RELEVANCE or UNKNOWN_outcome"` gives 4 passed. Two of those four assert the reasons the LATER gates produce ("exited 1", "NOTHING PASSED"), so with the relevance gate first both earlier gates were still read and still witnessed refusing alone. It cannot hold, and the branch already said why one line away: the reach mutation injects a failing test, so it reddens in every fixture except the relevance one, which is what `_inert_claim_sandbox`'s own docstring states. What the order actually buys is cost - the relevance gate is the only one of the three that costs a second run of the proof - and that is what both sites now say. #881's own defect shape, inside the record that establishes the rule against it. Second, the record twice gave line-wrapping as the reason a sentence was paraphrased rather than quoted. The branch's own first `CLAIMS` entry quotes a sentence that spans a comment line break, embedding the `# ` continuation, and the harness resolves it exactly once - so a wrapped sentence is quotable by this very mechanism. The real reason at the calibration site is the replacement itself: that sentence is not in the tree any more, measured 2026-09-05 by a fixed-string search over `git ls-files`, which returns no file. At the second site the referent (`docs/defect-shapes-773.md` section 4) is present and quotable, so the causal clause is dropped and only the paraphrase marker stays. refs #881 Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 07:06:52 +02:00
timothyandClaude Fable 5.1	91a9fbf81a	docs(881): name the reach mutation the way the rule field names it ... The residual paragraph called it "a stronger mutation", which is a judgement about size; what the mechanism requires is a second mutation of the same clause, declared and required to redden the proof. One vocabulary across the rule field, the manifest and the body, so a reader does not have to decide whether two descriptions are the same thing. Refs #881 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 05:18:43 +02:00
timothyandClaude Fable 5.1	a956cc6b8d	fix(881): the same outcome claim, restated in the proof's own docstring ... The claim the shipped GREEN entry binds — what removing the `+++ /dev/null` arm does — was written twice: in `check-doc-narrative.py`, where the entry binds it, and again in `test_a_DELETED_doc_is_not_reported_as_added_content`'s docstring, where nothing does. That is the copy-of-an-outcome shape this rule forbids, in a site class the rule names, found while reading the proof for the residual below. The docstring now points at the manifest entry and keeps its rationale (a deletion yields no `+` lines either way), which is the half the carve-out protects. The residual paragraph is also made exact rather than general. The reach mutation proves the proof depends on the clause through the `b/` stripping every scanned header goes through, not through the `/dev/null` arm itself, so in general such a green cannot separate "no test feeds that input" from "the arm changes nothing". For this entry it can, by reading the proof: the deleted-doc test deletes a tracked file, and a deletion diff under the flags `run_diff` pins carries a `+++ /dev/null` header — probed rather than reasoned. Refs #881 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 05:05:59 +02:00
timothyandClaude Fable 5.1	a9341d8415	fix(881): a GREEN claim is only readable if its proof REACHES the clause ... Round three found the one half of the new mechanism with no relevance gate. `verify_claim`'s GREEN path read exactly two things — the run exited 0, and something PASSED — and both are satisfied by a proof that never touches the mutated file at all. Reproduced before fixing: retargeting the shipped GREEN entry's proof from `test_check_doc_narrative.py` to `test_bom_guard_detection.py` changed nothing, and the entry still reported verified. The RED direction never had this hole, because a proof that ignores the mutation stays green and is refused as "the clause is not load-bearing". So a GREEN entry now declares a `reach_replacement` and its `reach_expect`: a SECOND mutation of the SAME clause, required to REDDEN the same proof, executed through `verify_mutation` so its red is read through the diagnostic gate rather than on exit status. The shipped entry declares `path = p` — dropping the `b/` stripping every scanned diff header goes through — and the run then scans NOTHING, which is what the declared diagnostic reads. The same retarget now fails, naming the reach verdict. The gate runs LAST of the three: run first it would refuse before the status and vacuity gates were read and neither could be witnessed failing alone (#685), and the sandbox is reset between a claim's two proof runs for the reason it is reset between mutations. It has its own disarm proof, and the two synthetic claim sandboxes are now real git repositories so `reset_sandbox` has a baseline; `_lib_with` shares the baseline registry, since a copied module's own starts empty. Also from that round: - The record no longer counts the mutation-outcome claims in the pinned proposal-3 scan. A third of the same shape sits in the same result set (`test_a_verdict_BEYOND_A_SHORT_PAGE_is_still_found`), and which side of the line a sentence falls on is a judgement, so an exact count is a figure the next reader re-derives differently — the failure this record is about. - The calibration paragraph no longer restates the post-review-verdict outcome as a dated witnessing. It points at the `CLAIMS` entry that executes it, which is the form the rewritten shell comment beside it demands. - The comment in `check-doc-narrative.py` claimed a universal ("reddens no test") while one file is executed. It now names that file, so the quote binds an outcome no wider than what is checked. - Proposal 4 from the issue is dispositioned explicitly: rejected as a rule here, on the issue's own argument that an exhortation does not fire at the moment of least slack. - `docs/README.md`'s task-signal parenthetical now names the `CLAIMS` population; the file was owned by another slot when this branch started. Cost re-measured 2026-09-05, three baseline/branch pairs: the `CLAIMS` half adds 31.7-43.6%, up from the 12.7-16.6% measured before the gate existed. The old figure is retired rather than scaled — growing the population invalidates the measurement that described it. Refs #881 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 05:02:46 +02:00
timothyandClaude Fable 5.1	7dba36cd58	fix(881): my own paragraph asserted the scan found no mutation-outcome claims - it found two ... Self-review of the previous commit, on the same class it fixes. "none of them asserts a mutation outcome", written about the 58 lines the proposal-3 scan returns, is false. Two do: the mutation table at `docs/decisions/records/ffmpeg/watermark-resolution-unified.md` line 104, which names a dropped discriminator and the single test that catches it, and `web/src/screens/AutoTuneScreen.test.tsx` line 174, which says what a revert to the old flex row can redden. Both read in full at `efadbec29` rather than from the truncated grep line - the truncation is how the first pass missed them. Three kinds of sentence under one pattern is a better argument than the one the false claim was making: it is not that the pattern finds only rationale, it is that it finds rationale, state anchors and mutation-outcome claims side by side and nothing in the string tells them apart. Two smaller ones in the same commit. The new test's docstring said the gate is "the one gate the others cannot cover" and the manifest said "the one PRE-FLIGHT refusal a red proof cannot be told apart from" - both assert uniqueness among the pre-flight refusals that neither measured, and a clause occurring zero times also leaves the text identical. Narrowed to what the mutant demonstrates: no later gate stands in for it. And the fixture comment glossed `verify_claim`'s GREEN refusal in quote marks, which under this record's own proposal-2 clause reads as a quotation of the library; it is not one, so the marks are gone. refs #881 Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 04:44:29 +02:00
timothyandClaude Fable 5.1	99966f8bd7	fix(881): a control's purpose stated backwards, and an enumeration that grew past what it could carry ... Four review findings, all of the class this branch is about - prose asserting what a mechanism does, with nothing binding it to the mechanism. The record's `mechanics:` said a GREEN claim over an already-red proof "would otherwise be satisfied by the redness it is supposed to rule out". Inverted: `verify_claim`'s GREEN branch REFUSES any non-zero exit, so redness refutes a GREEN claim and can never satisfy one - which is what test_MUTATION_disarming_the_GREEN_EXIT_STATUS_gate_accepts_a_proof_that_WENT_RED asserts. The hazard the control removes is the same one it removes for the rows, and it runs in both directions: an already-red proof satisfies a RED claim with redness its mutation did not cause, and refuses a GREEN one for a reason unrelated to its mutation. Both the record and the fixture comment now say that, and both say what the control CANNOT do - its assertions are over the aggregate of every proof ref, so a single ref collecting nothing is invisible to it and is caught per-claim by the vacuity gate instead. The manifest's `why` had widened a scoped sentence into "THE OTHER GATES EACH CARRY THEIR OWN PROOF" and then enumerated them, which made the enumeration a completeness claim it could not meet: the identical-replacement refusal carried no proof at all. The review measured that at 8adf21eff - `if mutated == original:` disarmed, whole file 49 passed 1 skipped. That gate is the one a red proof cannot be told apart from: the mutant is byte-identical, so the proof runs against the original tree and an already-red one reddens exactly like a detection. Disarmed, the harness certifies it as "the named test went red under the declared mutation, with the declared diagnostic" - witnessed here on the real library, restored after. So the measurement above no longer holds, by construction: the gate now has a disarm proof, and the sentence says explicitly that naming the gates is not a claim the list is closed. Proposal 3's rejection quoted "16 lines" with no predicate - the defect the record's own body names three paragraphs later, where the population scan is pinned verbatim for exactly that reason. The figure is not reproducible from the text. Replaced by a pinned `git grep` over the same corpus at the same sha (`32 files, 58 lines`), with what reading all 58 shows: they are rationale, the class the rule carves out, and the few real state anchors among them are not separable by pattern, because the difference is whether the sentence explains or asserts. refs #881 Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 04:44:29 +02:00
timothyandClaude Fable 5.1	9e0e11030b	docs(881): the third quotation on this branch that resolves to nothing ... `docs/defect-shapes-773.md` §4's sentence was quoted verbatim-looking but with a lowered initial capital, and the source wraps it across a line at `evidence`/`behind`, so neither the written form nor the corrected one is findable by grep. Same treatment as the `post-review-verdict.sh` one: paraphrase without quote marks, keep the section reference, say why. The section reference itself was checked - the sentence is at line 351, under `## 4. Detectors`. refs #881 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 04:44:29 +02:00