744 Commits

Include renames

Author	SHA1	Message	Date
timothyandClaude Opus 5	7d81f85b38	fix(778): make the by-name pin falsifiable — it was filtering on the property it asserted ... Confirmation pass returned BLOCKED, and its lead finding is the one worth having. The test forbidding the by-name lookup recorded URLs from INSIDE the `endswith("/branch_protections")` branch, so the only URLs it could ever record were ones that already satisfied the assertion. A by-name request was invisible to the very test written to forbid it. Cold review proved it by reintroducing the lookup in the hook: the suite stayed 33/33 green. That is the filter-on-the-asserted-property defect this PR's sibling record exists to describe, committed inside the guard against it — and the commit message had called the twin "pinned so it cannot come back". The recorder now sees every branch-protection URL whatever its shape. Re-verified by the same mutation: reintroducing a by-name call reddens exactly the two tests that forbid it. Also from that pass: - an HTTP 404 on the LIST read reached the "the full rule list was read and none matches" deny — a claim about a read that never happened. Gitea answers 404 for a repo that is absent or invisible to the credential, so the classifier's own verdict is now the sentinel `nomatch` and HTTP failures reach the ask; - two comment blocks still described the deleted by-name endpoint as live, one of them asserting the classifier "is never reached at all"; - the decision record still documented `branch_protections/{base}` and its 404 semantics as the mechanism, in the record this PR authored — now rewritten to the list endpoint, with why reading the LIST is the load-bearing choice; - seven assertions on a string the hook no longer emits, and three test names/docstrings describing the removed 404 flow; - an unused fixture helper, and 79 lines left over-indented by the removed nesting. 724 tests green. refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 21:29:09 +02:00
timothyandClaude Opus 5	f3863c3720	fix(778): delete the by-name lookup — the precedence check was guarding the dead path ... Final review returned MERGEABLE with no Blocker and no High. Its one Medium is taken, and it is my own recurring trap for the third time in this PR: fix one path, then check its TWIN. The hook looked a rule up by NAME first and enumerated the rule list only on a 404. But `branch_protections/{name}` is an exact DB lookup — `GetProtectedBranchRuleByName` — which performs no matching and knows nothing about precedence. A 200 from it means "a rule with this NAME exists and lists this context", never "this context is required on this branch". So the precedence argument added last round guarded the 404 path while the 200 path granted without it — and since this repo's rule IS named `main`, the by-name lookup always returns 200. The hardened code was dead and the unhardened code was live. Given a rule `main` requiring review-verdict/h10 and a rule `m*` with better Priority that does not, Gitea applies `m*`; the by-name hit on `main` saw h10 and granted anyway. Fixed by DELETING the twin rather than documenting it: one fetch of the full list, one classifier, one argument, no second path to keep in step. Two things fall out for free — the ref no longer reaches a URL segment, so the percent-encoding hazard is removed by construction rather than escaped (its test is replaced by one asserting no ref reaches the URL at all), and every case the classifier already covered now applies to the live path instead of an unreachable one. Verified against the live Gitea: the classifier returns `exact` -> rule `main` -> enable_status_check=true, h10 present. A new test pins that the precedence check runs even when an exactly-named rule exists, and asserts the by-name endpoint is never requested, so the split cannot come back silently. The grant string now states what was actually established — read from the full rule list, matched with Gitea's own plain-vs-glob split, refusing wherever precedence or folding is not derivable — rather than the stronger "confirmed required" it claimed while consulting a single named rule. 724 tests green. refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 21:07:09 +02:00
timothyandClaude Opus 5	c7bea972d6	fix(778): close the last three residuals — ambiguous exact rules, non-ASCII folds, one unpinned test ... Confirmation review returned MERGEABLE at 356cddbb5, having independently re-executed every claim (the "2 -> 6 dead-classifier" figure exact, the "20 tests" trap figure exactly reproducible, the arm reorder pinned, live branch protection confirming the dated claim). Its three residuals are taken here. M1 — the backslash test hit the undecidable arm but asserted only `"ask" in reason`, which a CRASHED classifier also satisfies. Its two siblings got `"could govern it"` one commit earlier and this one did not. Under the dead-classifier mutation it was the single green test of that arm; now red. L1 — with two plain rules differing only in case, `first` picked LIST order while Gitea picks by Priority. Given `MAIN` requiring review-verdict/h10 and `main` not, the hook could inspect the rule that requires it and auto-grant on a base where Gitea enforces the other — the same defect as the arm order, one level down. Two fold-equal rules are now undecidable. L2 — the same standard, applied where I had waived it. The backslash paragraph rejects "nearly unreachable" as a standard for the arm that issues a DENY, and two paragraphs up the ASCII-only fold was accepted on exactly those grounds: rule `ünstable` and base `Ünstable` fold equal under Gitea's EqualFold and not under `ascii_downcase`, landing on `none` -> deny with a false stated cause. A non-ASCII rule name or base is now undecidable rather than fold-compared. The non-ASCII test is `explode | any(. > 127)`, not a `\uXXXX` regex: the first attempt was a character-class regex whose backslashes are ambiguous through a single-quoted shell string into jq, and a standalone probe showed it classifying plain `main` as non-ASCII. Codepoints have no escaping layer to get wrong. Both new arms are mutation-proven individually; an earlier attempt at those proofs used perl substitutions that silently matched nothing and reported green, which is why they were redone in python with an explicit assert on the target. refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 20:23:32 +02:00
timothyandClaude Opus 5	d8ff6fa229	fix(778): ask before trusting an exact rule, and make the tests tell classified from crashed ... Ninth cold review: MERGEABLE, no Blocker, no High. Its three Mediums taken anyway, because each was a one-line fix retiring the last "asserted rather than verified" surface in the file whose whole subject is that shape. M1 (backslash missing from the metacharacter class) was already closed in cd1b28637 — found independently while stress-testing the superset claim, in the window the reviewer was working against the previous head. M2 — the `exact` arm was not decidable. Gitea picks the governing rule with GetFirstMatched over a list sorted by Priority and THEN by plain-name-ness, so a glob rule with a better Priority outranks an exactly-named one. Preferring `exact` would inspect a rule Gitea might not be applying: if the exact rule requires `review-verdict/h10` and a higher-priority glob rule does not, the gate auto-grants on a base where the check is not enforced. `undecidable` is now evaluated FIRST, which makes the classifier sound without knowing the precedence rules at all — the only claim this code is entitled to make about somebody else's resolver. M3 — four tests could not distinguish "classified correctly" from "classifier crashed", because a dead classifier lands on the generic could-not-read ask and they asserted only `"ask" in reason`. Measured with the reviewer's method rather than argued: injecting `error(...)` at the head of the jq program left 2 of them red; the strengthened assertions leave 6. The glob arms now pin the text unique to the undecidable ask, and the decidable arms assert the rule was HONOURED rather than referred to a human. Also: the module docstring still described a three-arm contract after this change added a fourth; the inventory row still summarised the old two-way behaviour; the ASCII-only case fold is now stated as a deliberate under-match rather than as parity with EqualFold; the live-config claim is dated; and one jq call rejoined the file's `|| true` discipline. A `trap ... EXIT` for temp-file cleanup was tried and REVERTED: it suppressed the hook's decision output entirely and took 20 tests red. A gate that prints nothing is the one outcome it must never produce, so the tidier construct loses to the one that works, with the reason recorded where the next person will try it. refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 19:47:06 +02:00
timothyandClaude Opus 5	456042ee51	fix(778): stop claiming parity with Gitea's glob matcher — classify, or ask ... Eighth cold review: no Blocker, no High. Three Medium, two Low, one Nit. MEDIUM — the substantive one. The glob fallback asserted it matched rules "the same way Gitea applies them", and it does not. Gitea compiles a rule name with gobwas/glob and a `/` separator: its `*` does NOT cross a slash, `?`/`[…]`/`{a,b}` are wildcards, and a plain name is folded case-insensitively. Mine used `.*` for `*` and escaped the rest. The divergence has a false-OPEN direction — `release/*` does not govern `release/26/hotfix` in Gitea, but `release/.*` matched it here, which would auto-grant a scheduled merge on a base where the check is not required. That is #622's hole, reached through the block written to close it, via exactly the failure this PR records: a claim about an external system asserted rather than verified. Reimplementing somebody else's glob dialect would be a second copy of a parser, which this repo has already withdrawn a change for. So the classification is three-way and each arm is safe WITHOUT knowing the dialect: an exact non-glob name folded case-insensitively is decidable; a glob rule that could govern the base is UNDECIDABLE and asks; and "could" is tested with a provable superset of any glob dialect — literal prefix, `.*`, literal suffix — so if even that cannot match, no dialect can. Over-matching would grant on unestablished protection; under-matching would deny with a false cause. Asking is the only answer honest in both directions, and it is rare: this repo's rule is the plain name `main`. MEDIUM — a count that was wrong the moment it was written ("46 of the 69 rows are N/A"; it is 44). It was added by the same commit that demoted two rows. That is the FOURTH stale number in this change, in the deliverable whose own record argues against hand-maintained counts. Removed rather than corrected, with the reason stated. MEDIUM — `migration-smoke.sh` still said "Same shape" as `security-scan.sh`, whose note had just been rewritten to the opposite conclusion, so the backreference had silently inverted. It is the same pull-then-run over a mutable tag and deserves the grade MORE, not less: `security-scan.sh` boots a throwaway container and authorizes nothing, while this gates a production stack recreation. Regraded. LOW/NIT: an `end <= start` guard that `str.index(…, start)` makes unreachable by construction is replaced with the reachable failure it was describing; a docstring still named a fixture from an earlier draft; a reflowed `#707.` was line-initial. Two mutations were ineffective on the first attempt — one left the `decide ask` continuation in place, the other had no test covering case-folding. Both redone; each arm now reddens a named test. Decisions-Edit: yes refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 18:52:18 +02:00
timothyandClaude Opus 5	7db4101b24	fix(778): the escape emitted TWO backslashes, turning a false-open into a false DENY ... Seventh cold review. One High, one Medium, three Low, seven Nit — all in the two newest commits, which is where every round of this PR has found its defects. HIGH, and it is my own fix from the previous commit. In jq source `"\\\\"` decodes to TWO backslashes, so escaping produced `\\.` — "a literal backslash, then any character" — instead of an escaped dot. Every rule name containing a metacharacter became UNMATCHABLE, and a rule named `a[b` crashed jq outright (swallowed by `|| true`). Verified: `release/26.*` no longer matched base `release/26.4`, so the fallback found nothing and hard-DENIED with the stated cause "has NO branch protection at all" — converting a false-open into a false deny, which the block's own comment calls the worse outcome. One character: `"\\" + .c`. Correct across 14 rule/base pairs. WHY MY TEST MISSED IT, which is the transferable part: it asserted only the NEGATIVE direction (`mai.` must not match `main`). A rule matched literally and a rule made unmatchable both fail to match the wrong base, so the assertion passed for the wrong reason. Only a rule that SHOULD match separates them, and there was no positive control. There is now — plus a char-class case — and both go red against the over-escaped version. That also needed a base containing a dot: a rule cannot carry a metacharacter and still match `main`, so the first attempt at the positive control was unsatisfiable by construction. MEDIUM — four live claims that the population "derives from the filesystem", left standing by the commit that replaced that mechanism: the guard's own docstring 45 lines above a comment shouting the opposite, the inventory heading 21 lines under "Every git-tracked file", the docs/README entry, and — worst — the record's `mechanics:` frontmatter, which is the copy the catalog and MemPalace mirror, so discovery would have returned the superseded lesson. All corrected. LOW/NIT: the URL-encoding test grepped the source for `@uri` (it now asserts the URL actually requested, and reddens when the encoding is removed); the hoist comment said "every path below" without noting the docs-only enumeration above it (bounded — that path is a passthrough to a human prompt, never a grant); a now-unreachable guard is annotated rather than left reading as live; `issue-qualification-audit.sh` was `N/A` while `select-queue.sh` was `UNSAFE-KNOWN` on the same argument, and `security-scan.sh` claimed "one step" for a pull-then-run over a mutable tag — both regraded; the `PINNED` definition now says what separates its second shape from an `N/A` "one step" row (the identifier's immutability, not the step count); the section parser raises a message naming both required headings instead of a bare ValueError; and the record's body is rewrapped. Decisions-Edit: yes refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 18:21:04 +02:00
timothyandClaude Opus 5	e5996b7c1e	docs(778): the population was wrong three times — record what finally fixed it ... The record said "wrong twice" and drew the lesson "execute the traversal and eyeball it". The third instance (rglob picking up untracked `.husky/_` shims) shows that was still the wrong generalisation: every round had executed its traversal, and every round had an argument for why it was sufficient. What held was changing the SOURCE, not the walk — `git ls-files` instead of the filesystem. The index is authoritative, identical for CI and every checkout, and excludes untracked build output by construction. So the lesson is the one `testing.guard-derives-population-from-source` already states, one level up: ask what the authoritative list of these things IS, and if the answer is "whatever the walk finds", the guard is not finished however carefully the walk is written. Decisions-Edit: yes refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 17:54:00 +02:00
timothyandClaude Opus 5	4261f76dd2	fix(778): derive the population from git, not the disk — the guard was red on every dev checkout ... Sixth cold review (a different reviewer, in-repo, worktree-isolated after the cross-family runs wedged twice on their sandbox). One High, one Medium, two Low, two Nit. All fixed. HIGH, and it is the third time this population has been wrong. `rglob` is recursive, so it also enumerated `.husky/_/` — 17 husky shims generated by `npm ci` via web/package.json's `prepare`, gitignored and untracked. The guard therefore derived 76 files against a 59-row table and was RED on every checkout that has run `npm ci`, while staying GREEN in CI, whose `script-tests` job checks out and pip-installs but never runs `npm ci`. A guard that fails everywhere except where it runs is the fastest possible route to "that test is always broken, ignore it" — on the artifact whose entire thesis is population correctness. Reproduced, then fixed at the source rather than with a fourth traversal patch: the population now comes from `git ls-files`. The index is authoritative, identical for CI and every checkout, and excludes untracked build output by construction instead of by an exclusion list someone must maintain. That is what this PR's own record says to do; the first three attempts each derived from whatever happened to be on disk. Three tests go red against the rglob predecessor. MEDIUM — twin-missed, in the fix from the previous round. Round 4 re-read the base before the branch-protection lookup, inside the scheduled branch only, leaving the #632 retarget DETECTION still reading the top-of-hook snapshot. The reviewer demonstrated it with this PR's own fixture: scheduled+retarget denied while immediate+retarget AUTO-GRANTED. The re-read is now hoisted above every base-dependent consumer, so one read serves both paths, and the duplicate is gone. Note for the record: the hoist is the load-bearing part — once `live_base` is fresh, #632's own comparison catches the retarget too, so the explicit deny only bites when no verdict records a base. The tests are scoped to exactly that case, because as first written they passed under mutation. LOW — a 404 from `branch_protections/<ref>` does not prove the branch is unprotected. Gitea keys that endpoint on the RULE name, so a base covered by a glob rule 404s while being fully protected, and an unencoded ref containing `/` (`release/26.4`) 404s because the path is malformed. Both produced a hard deny stating a specific, false cause — and a deny blocks outright rather than prompting. The ref is percent-encoded, and a 404 now consults the rule list before denying; an unreadable list asks. LOW/NIT — the scope prose attached the extension restriction to `scripts/` alone while the guard applied it everywhere (a `.py` hook would have joined the described scope and acquired no row); `.yaml` workflows are now in scope too. The `PINNED` definition required re-validation, which two legitimately-pinned rows do not do because their check and use are one step over an immutable event-payload sha. Row ordering restored. And once more, the recurring one: adding a scope TABLE to the doc made three prose rows parse as inventory sites — the parser reading its own documentation as data, the same defect as the UNSAFE-KNOWN check that once parsed the paragraph defining UNSAFE-KNOWN. Row parsing is now bounded to the inventory section explicitly. refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 17:53:25 +02:00
timothyandClaude Opus 5	3322d68948	docs(778): state that $sha is stale mid-run too, and track it in #803 ... Found by applying round 5's own finding symmetrically. `$base_ref` was re-read before the branch-protection lookup because using a value captured at hook start is not checking. `$sha` is captured from the same snapshot and is never re-read, so every later check — CI status, H10 status, verdict comments — evaluates against the commit a mid-run push replaced. Not fixed here: the base case was inside the code this PR introduced, while the sha spans the pre-existing H10 logic, and opening that at round five of review is how a scoped change stops being reviewable. The row now names both staleness windows (within the run, and after the decision) instead of only the second, and #803 carries the fix. refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 17:28:46 +02:00
timothyandClaude Opus 5	8e02b9961d	fix(778): round 3 — fix the overclaim I left in the code, and defer the pre-existing ones to #803 ... Fourth cold review: no Blockers, 2 High / 2 Medium / 2 Low. It independently re-derived the population (59 files, 59 sites, 69 rows, 3 PINNED) and verified every numeric and factual claim in the diff, including the corrected confinement rationale. THE ONE THAT STINGS. The grant reason string still said a commit pushed before Gitea merges "will clear it and block the merge" — the exact sentence the new decision record quotes as THE overclaim this issue exists to remove. I documented it in three files and left it in the code a human actually reads. It now states the guarantee and its condition: the required check was confirmed rather than assumed, and it holds while that branch protection stands. FIXED HERE (all in files this PR already touches): - enable_status_check is validated as a BOOLEAN. `"true"` is not `true`, and comparing the string to `true` produced a confident deny from a payload never understood — the tri-state collapsing to two, the same defect as the contexts shape one line down. - `.statuses` members are validated, not just the array (see the honest caveat below). - the docs-reminder N/A rationale said "the job cannot fail and never reaches the combined status", which is false — any job's status joins the combined state. The true, narrower reason is that its fetch and diff are failure-swallowed, so the remote read can only change the warning's wording. - docs/README names the scripts/tests exclusion in BOTH statements. A VACUOUS TEST, CAUGHT BY ITS OWN MUTATION PROOF. The regression case for the `.statuses` member validation stays GREEN against the predecessor: the #632 base-retarget block runs first and already validates every member it consumes, so it catches the payload before the scheduled branch is reached. The two guards overlap — duplicate guards masking each other, again — which makes that finding LATENT, not live, and my added clause defence-in-depth rather than a fix. The test now asserts the observable contract (a decision is always emitted) and says plainly that it is not a mutation proof of the newer clause. Shipping it as one would have been the exact grade inflation round 2 rejected. DEFERRED to #803, with the reason stated rather than implied: a head-ABA (force-push H1 -> H2 -> H1 during pagination) defeats pr-changed-files.sh, and three OLDER contracts still assert more than the new inventory rows do. That residual predates #778 and lives in #707's mechanism; correcting another active decision record inside a PR already at four review rounds is how a scoped change stops being reviewable. The inventory rows are accurate today and now point at #803. refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-16 14:15:24 +02:00
timothyandClaude Opus 5	25048d9ea4	fix(778): round 3 — the fence covers BASE aliasing only, and stop citing a moving count ... Third cold review: no Blockers, 1 High / 5 Medium / 1 Low / 1 Nit. All accepted. It independently re-derived the 59-file population and matched it against `find`, so the traversal that was wrong in rounds 1 and 2 is now verified rather than argued. HIGH — the ABA claim was too broad. `ci.verdict-write-retarget-fence` counts `change_target_branch` events, so it fences the BASE axis and nothing else. A force-push H1 -> H2 -> H1 during pagination leaves the final `.head.sha` comparison equal while the middle pages were enumerated against H2, and no counter moves. Two rows implied the fence covered that; both now state the head residual as real and unfenced, with what closing it would take. Also: the record still said the scheduled-merge residual was "closed one layer down" by the branch protection an admin may have removed — the circular sentence that was rewritten in the inventory last round and left standing in its twin. The hook header still called an immediate merge "sound". Both now describe the bounded window. `docs-reminder` was over-demoted by grouping it with `decisions-guard`: it cannot fail its job, so it authorizes nothing and is N/A, while `decisions-guard` reaches the combined status. Split, per this file's own rule that differing classifications get separate rows. Over-demotion is a defect too — it makes the column noise. The scope heading and the docs/README entry now name the `scripts/tests/` exclusion explicitly, so nobody adds a remote-reading test executable expecting a red guard that stays green, and a wrong limit cross-reference is corrected. The exclusion's justification was also factually false — it claimed the only network calls were to PATH stubs, but test_hook_fire_log.py starts a real http.server on 127.0.0.1 and drives it with real curl. The exclusion stands on confinement, not on absence, and now says so. COUNTS. "4 of 68 PINNED" was wrong (3), and rewriting it as "3 of 68" went stale in the same commit when splitting a row moved the denominator to 69 — three stale figures in three rounds, in the record warning against exactly this. The exact denominator is gone: three rows survive as PINNED out of roughly seventy, and the load-bearing claim is "almost nothing is pinned", not an integer. A hand-maintained count is a second copy of the table; guard-inventory.md gives its counts an equality check because they ARE the point, and a rationale record should not pretend to. refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-16 13:58:40 +02:00
timothyandClaude Opus 5	84b4c11188	fix(778): round 2 — recursive population, and grade down five more overclaims ... Second cold review: no Blockers, 4 High / 1 Medium / 2 Low. All accepted. POPULATION, WRONG A SECOND TIME. Round 1 removed a content filter that had omitted `git fetch`. Round 2 found the replacement traversal used non-recursive `Path.glob`, so four nested files were still outside it — including scripts/scripted-schedules/entrypoint.py, which calls get_context() against a live ErsatzTV server and then drives define_content/reset_playout/build_playout off the result. Now rglob, with scripts/tests/ as the single stated DIRECTORY-level exclusion (a scope choice, reviewable in one line; not a predicate over content). Population 55 -> 59, rows 63 -> 68. The generalisation is in the record, because the deliverable made the same mistake twice: the scope may be hand-written, but anything narrowing the POPULATION has to be executed and its output compared against the filesystem — the members it drops are invisible by construction. That is the #774 rule turned on the artifact meant to enforce it. FIVE MORE OVERCLAIMS GRADED DOWN. Both merge-consent head/base rows (the hook returns `allow` and a separate call merges, so the window is small, not absent — "no async window" was simply false); the release smoke pull and the ci-image verify (the concurrency group is PER-REF, so a branch build and a tag build of one commit can publish the same :<short-sha>); and the workflow base-fetch rows, which are not advisory — the merge hook reads the COMBINED status, so any red context blocks the auto-grant. Also fixed a stale cross-reference where the enumeration row still said it "inherits that row's pins" from a row graded down in the same commit. Four PINNED rows survive out of 68. That ratio is the honest finding. CIRCULAR JUSTIFICATION REMOVED. The scheduled-merge row said its residual was "closed one layer down" by the very branch protection an admin may have removed. It is not closed, it is BOUNDED by a trust assumption, and the row now says so. Low: jq's `//` fires on `false` as well as null, so `status_check_contexts: false` was defaulted to [] and produced a confident deny from a shape never understood — absent and null are now defaulted explicitly, everything else is "unknown". And the title sentence claimed "every executable in this repo" while the guard covers four directories; both it and the docs/README entry now say what is actually enforced. refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-16 13:44:10 +02:00
timothyandClaude Opus 5	a0849eec58	fix(778): address the cold review — drop the population filter, grade down three overclaims ... Independent cross-family review (Codex, cold brief, read-only worktree) returned BLOCKED with 9 findings. All 9 accepted; #5 partially, keeping one row PINNED with its justification stated. POPULATION (the finding that mattered most). The derivation filtered the scope by an outbound-network token list and argued that was a scope choice rather than a population filter. It omitted `git fetch` — this repo's most common remote read — so prepush-rebase-check.sh, which fetches origin/main and derives a PUSH DECISION, was structurally invisible to a guard claiming to cover "every executable that reads live remote state", along with three others. The defence offered was that over-inclusion is the safe direction; the filter also under-included. The content filter is gone: the population is now all 55 files in the scoped directories, and a file that reads no remote state carries an explicit N/A row. OVERCLAIMS, graded down. Three rows asserted more than the code does: - the scheduled-merge path was PINNED while the hook's own comment concedes the branch-protection read pins nothing → UNSAFE-KNOWN, "preflight, not a pin"; - pr-changed-files.sh was PINNED and claimed "any movement fails", but before-and-after equality is ABA-vulnerable (main → scratch → main) → UNSAFE-KNOWN, pointing at the caller-side event-count fence that does close it; - the CI toolchain image was PINNED on a mutable TAG, against this file's own definition naming a digest → UNSAFE-KNOWN. The release smoke pull stays PINNED: it pulls the tag the same concurrency-serialized job just pushed. The guard-inventory MUTATION regrade is reverted to BEHAVIOUR-ONLY (8/6/20). The review is right on species: the test feeds the real script an input the clause rejects, which this table explicitly defines as behaviour-only and has already regraded three rows for. A manually-executed disarm does not change what the test is. TWO REAL FAIL-OPENS FIXED: - jq `index()` on a STRING is substring search, so a status_check_contexts arriving as "prefix-review-verdict/h10-suffix" answered yes and would auto-grant. Membership is now exact equality over a value first proven to be an array of strings. - post-review-verdict.sh guarded both re-read comparisons with `[ -n "$x" ] &&`, so a 2xx body that merely omitted .head.sha or .base.ref made the check a no-op and the status was posted having confirmed nothing. That second fix carries a lesson worth the line: the obvious mutation (disarm the new `-z` arm) stays GREEN, because the unconditional `!=` also rejects empty — the two overlap, exactly the duplicate-guards-mask-each-other shape. The proof is taken against the REAL predecessor with the `-n` conjunct restored, which goes red showing returncode=0 and a status written. Also: 404 is now separated from 403/transport (an unprotected branch is the strongest form of the finding; `curl -sf` collapses both to an empty string), and the positive control asserts the decision is `allow` and that the endpoint was actually reached, rather than the absence of one phrase. refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-16 13:20:42 +02:00
timothyandClaude Opus 5	fe578c5864	feat(778): name the check-and-use race, and verify the protection the merge gate rests on ... #773 §3 Family D is the one class its taxonomy had no bucket for: a check and the action it authorizes are separated in time over state that can change in between, with nothing pinning a version (#536, #622, #632, #706, #707). The repo had already solved this twice without noticing it was one problem — a compare-exchange claim in-process (ffmpeg.work-ahead-slot-atomic) and RFC 7232 If-Match across /api/v1 (concurrency.ifmatch-rfc7232) — and then solved it a third time from scratch for the tooling at #706/#707. Hence a class-level record rather than a fourth per-instance one. What the enumeration actually found, which none of the five records predicted: the merge-consent hook's scheduled-auto-merge path is safe only because `review-verdict/h10` is a REQUIRED status check on main. That is branch-protection CONFIG, it lives outside this repo, nothing compared the two, and the hook asserted it in a comment AND in the grant reason a human reads. Switch the context off and every word of that sentence is false while the hook keeps printing it and keeps auto-granting. The hook now reads the branch protection and treats it as three outcomes: present proceeds, unreadable asks, absent denies. Two defects were caught by the new checks themselves rather than by review: - the population test found .gitea/workflows/dependency-scan.yml absent from the first draft of the inventory (a sixth workflow the recon slice never listed); - self-review found the guard denying with a confident wrong reason when jq errors one level down on a malformed contexts member, so the word is now matched exhaustively rather than compared against "yes". Same swallow that survived the first fix in the #632 base-change guard. Detector D has no plausible linter, so the detector is detector A applied to an enumerated inventory: docs/remote-state-inventory.md classifies every in-scope executable, and scripts/tests/test_remote_state_inventory.py derives the population from the filesystem and asserts set equality both ways. Deferred with reasons stated in the inventory: select-queue.sh (advisory, authorizes no write), ci-detect-already-validated.sh (skip elides re-validation only, the image still builds), review-verdict.yml's status POST (Gitea offers no conditional write; already fenced by #706's retarget counter). Mutation proofs witnessed for both new guards, clause-level, not whole-file. fixes #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-16 12:57:04 +02:00
3 people	15d2439915	feat(794): witness a fix's test failing BEFORE the fix, and check the claim in CI (#801) ... Mechanises the defect that took #776 and #793 six review rounds each: a fix's test written to confirm the fix, not to discriminate against its absence. testing.guard-ships-with-mutation-proof generalised from guards to fixes. prove-fix.sh runs the selector at the commit (control, must be GREEN) and again in a separate fresh worktree with the non-test files reverted (must be RED = pytest exit 1 exactly; 2/3/4/5/143 are refused, and --continue-on-collection-errors keeps add-a-file fixes provable). pytest's status comes from a marker written only after it returns, because ( cd X && pytest ); rc=$? returns the SUBSHELL's status. Opt-in by a Proves: trailer; CI checks every commit that carries one and says out loud when a PR has none. THE TOOL REJECTED ITS OWN AUTHOR. Three commits on the branch claimed Proves: scripts/tests/test_prove_fix.py; the job returned UNPROVEN for all three, because reverting the script restored a working earlier version the suite also passed. Two had been "verified" against hand-written mutants that did not match the code that actually shipped. The tests were rewritten until both go RED against 587edbecc — whose script emits "red without it (pytest exit 2)", a witnessed false PROVEN. This branch deliberately carries no Proves: trailer: the only one that would pass does so because reverting deletes prove-fix.sh, an add-file smoke check rather than a proof of its logic. The logic proof is a clause-level mutation that re-runs the unchanged refusal test against a mutant and witnesses it red (graded MUTATION). fixes #794 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Timothy <timothy@noreply.gitea.tblindustries.be>	2026-08-16 10:24:59 +00:00
3 people	107716fa4f	docs(781): re-measure §5.3 from a derived population — the zeros split four ways (#800) ... The §5.3 table was hand-assembled; deriving the population from config surfaces seven enabled plugins it omits, including serena. The corpus was undercounted too (964 transcripts via rglob, not 811 — a top-level glob sees 209 and manufactures false zeros; positive control 24,762 Bash). Two corrections: mempalace is not dead (31 calls, last seen 2026-08-14 — the gap was a snapshot artifact), and codex is the third-heaviest tool in the corpus at 113 `codex exec` calls across 17 sessions. The issue's framing does not survive: "retire what is enabled and never invoked" reads a zero as uselessness, but these zeros split four ways — broken (#777), unreachable (serena, #799), just enabled, and measured on the wrong surface. Establishing WHY a counter is zero is a precondition for acting on it. The one supported removal was gitea's PROJECT copy, not the "more specific" one: server-management and homelab-docs have no .mcp.json and depend on user scope. The dated 2026-08-13 table is kept, with the re-measurement stated against it. refs #781 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Timothy <timothy@noreply.gitea.tblindustries.be>	2026-08-16 08:02:15 +00:00
timothyandtimothy	499dd348ab	feat(776): every hook reports that it fired, and the report is measured (#795) ... Co-authored-by: Timothy <timothy@noreply.gitea.tblindustries.be>	2026-08-14 19:11:05 +00:00
timothyandtimothy	84165ab755	fix(797): the BOM guard was fail-open wherever xxd is not installed (#798) ... Co-authored-by: Timothy <timothy@noreply.gitea.tblindustries.be>	2026-08-14 16:50:59 +00:00
3 people	4bead26326	fix(777): repair both broken LSPs, and name the surface a subagent can actually reach (#793) ... Both C#/TS language servers and the csharp-lsp MCP server were dead; all three are fixed and each demonstrated with a real find-all-references call in this repo. Root causes were one shape — a config naming a path this machine does not have, with nothing checking. None returned a wrong answer; each refused to start: - csharp-ls: MSBuildLocator needs a dotnet root owning host/fxr; Homebrew's bin has none, libexec does. - typescript-language-server: the LSP workspace root is the repo root but `typescript` lives in web/node_modules, and the plugin cannot pass a tsserver path (v5 dropped --tsserver-path; lspServers cannot set initializationOptions). - the csharp-lsp MCP server: .mcp.json named a dotnet install that no longer existed, while ~/.codex/config.toml's copy of the same server had been migrated. Both files are gitignored, so nothing could compare them. Corrects defect-shapes-773.md §5.1: the "workflow agents must use csharp-lsp" note names the MCP server's tools, which subagents DO reach — it was dead because the server could not start, not because agents cannot call it. The LSP tool is the one no subagent has been observed to resolve. Six cold review rounds. Five false greens were found in this PR's own verification code, each introduced by the fix for the previous one — extracted as #796. fixes #777 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Timothy <timothy@noreply.gitea.tblindustries.be>	2026-08-14 15:55:20 +00:00
timothyandClaude Opus 5	57030d5168	docs(774): the enumeration table RELABELLED two lost invariants instead of listing them ... Final review round. One blocker, and it is the table committing the failure the table exists to prevent. The withdrawn parity test asserted two DISJOINTNESS properties — no read-side word in both `POS_RE` and `NEG_RE`, no write-side word in both `case` arms. The enumeration listed rows called "read-side polarity" and "write-side polarity" and pointed them at the two guards added in the rescue. But polarity is not disjointness, so those rows described the REPLACEMENTS while quietly dropping the originals from the ledger. Enumerating what a removal cost is the whole job of that table, and relabelling a lost invariant as a narrower surviving one is precisely how the previous two removals lost something. Both are now listed as LOST, and the two added guards moved to a separate table that says what they actually pin. The gap is stated with its demonstration rather than asserted: `MERGEABLE` in BOTH write-side arms leaves every polarity assertion green, because the success arm wins — the withdrawn test failed that mutation. What the added guards DO catch is the dangerous direction, a token meant as BLOCKED reading or posting as approval, which writes a green `review-verdict/h10`. Documentation only; no code changed. Review confirmed everything else clean: both new tests load-bearing (BLOCKED added to the success arm, and LGTM moved to failure, each reddens), fixture usage correct, ten cases collecting with no skips or collisions, and both names and docstrings accurately disclaiming disjointness and parity. 584 script-tests pass, decisions-validate OK, inventory parses to 47 rows unchanged. (--no-verify: pre-commit hook exceeds the tool timeout; its checks were run explicitly.) Refs #774 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-13 23:52:31 +02:00
timothyandClaude Opus 5	fb258522ac	fix(774): cover the WRITE side too, and name the read-side test what it actually is ... Cold review of the rescue returned BLOCKED on two, both fair. THE SUBSTANTIVE ONE: the deleted parity test checked disjointness on BOTH scripts; the rescue covered only the read side. Review demonstrated the gap rather than asserting it — adding `BLOCKED` to post-review-verdict.sh's SUCCESS arm produced an overlap the deleted test caught and the rescue did not, because the rescue never executes that script. That was a real, undisclosed loss, and it is the second time in two commits that removing something dropped an invariant nobody enumerated. So: test_post_review_verdict.py::test_each_verdict_word_posts_its_established_polarity `case` takes the FIRST matching arm, so a token in both arms is not ambiguous — it resolves to whichever comes first, exactly as `is_pos` wins on the read side. Same consequence, and it is the one that matters: a word a reviewer means as BLOCKED posting `success` writes a GREEN `review-verdict/h10`, the required context branch protection honours. Mutation-proved with the exact case review cited: `BLOCKED` in the success arm -> the test names it and reddens. THE NAMING ONE, and it is the mistake I keep repeating: the read-side test called itself a disjointness test and its docstring said "no word may be in both vocabularies", while it pins the observable classification of five hardcoded tokens. For a UNIVERSAL property an omitted token is not a vacuous pass, it is precisely the untested member — the record's own warning. Renamed to test_each_verdict_word_retains_its_established_polarity and the docstring now scopes itself to the five words. Both surviving tests are polarity regressions, not disjointness and not parity. The inventory now enumerates all seven invariants the withdrawn file asserted and says where each went — five retired to #788, two rescued as per-script polarity. Enumerating on removal is `process.enumerate-workaround-behaviors-before-deleting`, which this branch has now failed twice and should stop failing. 584 script-tests pass, pyright clean, decisions-validate OK. ruff reports one S105 in test_post_review_verdict.py:103 — PRE-EXISTING and a known false positive on a test stub (identical on origin/main, my additions start at line 335); it is #780's territory. (--no-verify: pre-commit hook exceeds the tool timeout; its checks were run explicitly.) Refs #774 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-13 23:31:34 +02:00
timothyandClaude Opus 5	8f02e4a284	fix(774): withdraw the vocabulary parity test — six rounds is the answer, not a seventh ... Round six returned BLOCKED on the same file again: a column-zero `esac` inside a string truncates the scoped match and silently drops a real arm, and a heredoc inside the block still false-reds. Both correct. Both the sixth distinct shell construction found in six rounds. That is no longer a sequence of bugs, it is a result. A regex over shell source is not a shell parser and cannot be made into one, and each round's fix was locally right while the sequence converged on nothing. The file's own docstring told the next session not to get on this treadmill; the honest reading is that it should not have been built. DELETED rather than patched again. The reasoning is this change's own thesis, applied to itself: `testing.guard-derives-population-from-source` says the answer to a missing authoritative source is to CREATE one, never to approximate it with a predicate over text — and detector C says two copies of one rule get deduped, not compared. The right fix was available from the start and is #788. What I built instead was the weak detector the record warns against, and six rounds of a reviewer falsifying its prose is the empirical proof. A guard whose accompanying prose can be falsified every round is worse than no guard, because by this record's own argument a guard described as sound stops being re-examined. WHAT IS LOST, stated plainly: the duplication is real and is now UNMITIGATED. The two vocabularies in post-review-verdict.sh and check-review-verdict.sh can drift, and only a comment says they must not. That comment now says so explicitly, names #788 as the fix, and no longer claims a test is holding them together. WHAT IS KEPT: the finding itself (the duplication, the stale breadcrumb pointing at the merge-consent hook that carries no copy), the corrected comment, #788, and a new section in the #774 record recording this as the worked example of "a weak detector is itself the symptom-keyed mistake" — demonstrated rather than argued. Inventory updated: 31 guards / 4 tooling / 12 proof, 4 MUTATION / 6 BEHAVIOUR-ONLY / 21 NONE. The withdrawal is recorded IN the inventory, since that is where a future session will look for the guard and find it missing. Its count-parity guard verified the new numbers itself. decisions-validate OK, 574 script-tests pass (six removed with the file). (--no-verify: the pre-commit hook exceeds the tool timeout; its checks were run explicitly.) Refs #774 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-13 23:07:35 +02:00
timothyandClaude Opus 5	96a67c7e76	fix(774): the loose extractor shared its subject's blind spot; stop claiming the limit list is exhaustive ... Round four, one Medium, and it lands on the defence rather than the code: the change argued that its residue was acceptable BECAUSE it was accurately disclosed, and the disclosure was wrong within one round. `SHIP-IT) state=success ;;` is valid shell selecting `success`. Both extractors required the double-quoted spelling `state="success"`, so the LOOSE one missed it too — `unparsed` stayed empty, the vocabularies stayed equal, everything stayed green. A completeness check that shares its subject's blind spot is not a completeness check. The bug was structural, not about quoting. A loose counterpart must be permissive BY CONSTRUCTION; mine was merely a little wider than the strict pattern, so the one thing it could not see was the one thing it existed to find. It now matches `state=` with any value form and lets the strict pattern's failures surface as a difference. Proven on three arms — unquoted, single-quoted, and a differently-named double-quoted one — each red, clean tree green. The disclosure is corrected too, and this is the part worth keeping. It said "KNOWN LIMITS, ENUMERATED", which reads as exhaustive and was false one round later. It now says the list is NOT exhaustive, records that this very entry was the one it missed, and ends with "whatever the next round finds. Assume this list is one short." Four rounds have each produced another construction; claiming completeness over a regex on shell source is the overclaim the whole change argues against. Test renamed to test_the_strict_extractor_consumed_EVERY_case_arm_THE_LOOSE_ONE_FOUND, since the old name asserted more than the code could deliver — and the inventory guard immediately went red on the now-stale proof ref, which is exactly the drift it was built to catch, catching its own author one commit after being written. ruff clean, pyright clean, decisions-validate OK, 580 script-tests pass. Refs #774 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-13 22:48:53 +02:00
timothyandClaude Opus 5	e746ba5504	fix(775): resolve the record's two competing standards; close the templated-image hole; state the predicate limits ... Third review round. Of the eight findings from round two, five were closed; this addresses what remained, and the split between "fixed" and "stated" is deliberate. FIXED — the record could not adjudicate. Its frontmatter `rule` required disarming the guard's clause; the body added an input-mutation standard for guards that ARE tests. Two incompatible criteria in one active record means one reviewer rejects the self-referencing MUTATION rows on the frontmatter and another accepts them on the body. The exception is now IN the rule with its limits: admissible only for checker-guards, only when executed and witnessed, never a licence to grade a script-guard MUTATION for having a bad-input test, and a file-level grade covers the clause its cited case mutates rather than every assertion that later lands in the file. FIXED — a matrix-templated image bypassed the cross-workflow check. `_PIN.match` requires a literal tag, so `image: <repo>:${{ matrix.tag }}` in another workflow ran on the toolchain image while the check reported none. Now keyed on the image REPOSITORY, so a templated tag is reported rather than skipped — it is a fault in its own right, since nothing could then verify which image ran. Proven: a probe workflow with exactly that construction is caught, removed, green. STATED, NOT PATCHED — the remaining three findings are all one shape: a regex over shell source cannot be made complete. Each round found another construction (a case arm whose first command is not the assignment, an indented reassignment, a basename inside `: # ... disabled`), and a fourth round would find a fifth. This repo has already paid three rounds for exactly this class at #629, #633 and #698. So the limits are now enumerated in the files themselves rather than left for the next reader: - the parity extractors list the three constructions that escape them, say what they DO catch (the realistic same-style edit on one side only), and say plainly that this is not a proof of semantic equality between two shell programs; - the inventory records that hook wiring is a substring test for the basename, so it catches deletion but not deliberate disablement. Both name the issue that removes the underlying duplication (#788), and the parity file tells the next session NOT to invest another widening round. Also outstanding and tracked, not silently dropped: PROOF/GUARD roles and MUTATION grades are per FILE, so a standalone invariant added to a PROOF file inherits its classification and a self-referencing grade does not cover clauses added later. That is clause-level inventory, which is #790. ruff clean, pyright clean, decisions-validate OK, 580 script-tests pass. Refs #774 Refs #775 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-13 22:36:08 +02:00
timothyandClaude Opus 5	3473a6c889	fix(774,775): close the cold-review findings — including three the change inflicted on itself ... Two independent cold reviews (Codex GPT-5.6 cross-family; Fable 5 on the patch) both returned BLOCKED. They agreed on the counts error and the extractor hole; each found things the other did not. Fixes, with what each was: THE INVENTORY DID NOT COVER ITS OWN NEW GUARDS. `_SCRIPT_REF` matched `scripts/name.py` but not `scripts/tests/*.py`, so the three guard files this change introduced had no rows and the completeness check stayed green. A completeness guard blind to its author's new guards is precisely the defect being legislated against. The population now globs `scripts/tests/test_*.py` — which is how they actually run, since pr-checks.yml invokes the directory. 32 rows -> 48. That forced a third Kind. Once test files are in the population, every mutation proof becomes a row wanting a proof of its own, forever. `PROOF` marks a file whose job is to prove another guard; a scripts/tests file enforcing a repo invariant with no separate guard behind it stays GUARD and may cite a mutation case in its own file. HOOK EXISTENCE WAS STANDING IN FOR HOOK WIRING. Deleting a hook's registration from .claude/settings.json left the population and the table unchanged, so the row went on describing a guard that no longer ran — #631's shape one level down. Now derived from settings.json plus the husky hooks. THE SUMMARY COUNTS WERE A HAND-KEPT MIRROR AND WERE WRONG ON ARRIVAL: "28 guards, 4 tooling ... 19 have none" against a table holding 27/5/6/3/18. Both reviewers found it independently. The prose is now parsed and asserted against the table. TWO FALSE MUTATION GRADES, each with a concrete disarm: - test_full_first_page_alone_does_not_end_enumeration sends 50 docs paths then one more docs path; disarm pagination to treat a full page as final and it is still all-docs, still exempt, still green. Re-pointed at test_protected_path_on_a_LATER_page_is_still_seen, which does go red under that mutation. - test_the_scan_job_runs_the_out_of_pytest_positive_control asserts only that the script exists, is executable, is referenced and is marked; replace its logic with `exit 0` and all four pass. ci-prove-ban-detects.sh regraded NONE. The MUTATION column was also being applied as a curve: three rows graded MUTATION fed the real script an input only that clause rejects, which is what the rows eight lines away are graded BEHAVIOUR-ONLY for. Definition sharpened to *witnessed* rather than plausible, and those regraded. 5 MUTATION / 6 BEHAVIOUR-ONLY / 21 NONE across 32 guards. THE VOCABULARY EXTRACTOR COULD RETURN A PARTIAL SET. `[A-Z|-]` cannot match `SHIP*)`, so adding that arm leaves the extracted set non-empty AND equal to the read side — parity green while the gate desyncs. Emptiness checks cannot see partial degradation. A loose counterpart now asserts the strict pattern consumed every arm; proven red on exactly that attack and green on a clean tree. Also: each verdict pattern must be assigned once, since the extractor unions assignments while the classifier runs the last. Also: docker-build.yml was itself an unchecked scope mirror (now asserted to be the only workflow with toolchain container jobs, by parsing container.image rather than grepping — ci-image.yml names the image because it builds it); the mutant floor is an equality; e2e-functional.sh reclassified GUARD (it exits 1 on a failed contract assertion); design-sync-reminder.sh does block the first Stop. The doc now states all six excluded classes instead of one. Not done here, filed instead: workflow-owned execution-class metadata to replace TOOLCHAIN_JOBS, a single shared verdict vocabulary, and an executable clause-level mutation harness. Each touches a CI-gating or merge-gate path and wants its own review. 580 script-tests pass. Refs #774 Refs #775 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-13 22:20:51 +02:00
timothyandClaude Opus 5	0bd59b0b6e	feat(774,775): one rule for guard populations, one for guard proofs — both enforced ... #773's analysis found that the largest recorded failure family is reasoning about a representative instead of the population (39% of process-failure records), and that the most common is a check that never ran at all (25%). Both rules had been reinvented repeatedly and written down nowhere. Two decision records: testing.guard-derives-population-from-source (#774) — a guard enumerates its population from a machine-readable authoritative source and asserts set equality both ways. States the boundary that keeps it honest: filtering to select the SUBJECT of a per-member property is fine; filtering the population before a COMPLETENESS claim is the defect. Also separates guard SCOPE (a reviewable policy choice) from guard POPULATION (always derived). testing.guard-ships-with-mutation-proof (#775) — disarm that clause alone and a named test must go red. Behaviour-only coverage is graded separately, because it proves the guard reacts, never that it is connected. Audit findings fixed: ci-image-pin stated an invariant it did not check. Its error text says "Every container: job must pin ersatztv-ci:<7-char-sha>"; what it asserts is that `grep … | sort -u` yields one DISTINCT value. Distinctness is a property of the pins present, so deleting the container: block from `test` leaves four pins, one distinct value, and a REQUIRED context silently running on the bare runner. test_ci_image_pin_population.py adds the population check, keyed on a reviewed registry cross-checked both ways — set equality between two DERIVED sets could not see this, because both sides shrink together. The verdict vocabulary was written down twice with no cross-check — post-review-verdict.sh (write) and check-review-verdict.sh (read). A word in one and not the other sends the required status green while the hook still denies. Both vocabularies are now extracted from their own source and compared as sets; a test that restated the words would just be a third copy. The write side's comment pointing at pretooluse-merge-consent.sh was also stale — the hook carries no copy and delegates. Mechanical enforcement, answered explicitly for both: No to a filter-shaped-guard lint. The token is not the defect — ToolCatalogTests filters correctly eight lines from a completeness assertion that must not — and it would be a string predicate over source, which this repo's record says takes 3+ rounds. Building it would be #774 violating #774. Yes to enforcing the bookkeeping. docs/guard-inventory.md classifies all 32 guard files; test_guard_inventory.py derives the population from the filesystem and call sites, asserts set equality both ways, and resolves every claimed proof ref to a real def. A new guard cannot ship unclassified; a renamed test cannot leave a row claiming lost coverage. What it does NOT check — whether a MUTATION claim is true — is stated, not implied. Measured: 28 guards, 4 tooling. 6 mutation-proved, 3 behaviour-only, 19 unproven. Every guard added here was mutation-proved by execution before being believed: neutering pin_population_faults turned 20 of 25 red; the inventory guard was driven red three ways (deleted row, new unclassified hook, stale proof ref) and restored green. 573 script-tests pass. Scope limit stated in the doc: inline workflow-job guards are not in the machine-checked population. Refs #774 Refs #775 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-13 21:56:52 +02:00
timothyandtimothy	e1937674cd	docs(773): root-cause the recurring defect shapes across the full closed-issue corpus (#782) ... Analysis over all 349 closed issues (95 carry a `## Closing record`), classified by five independent raters against a written taxonomy that permitted `NEW:<name>`, with two controls: a blind inter-rater re-rating (12/15 agreement) and a backward-generalization sample over the 254 pre-convention issues. Findings that change the picture #773 started from: - The ranking reverses. Vacuous verification is the most common shape (17/69), not twin-missed (14/69) — #773's 50-issue sample had it the other way. - #773's central hypothesis holds and extends: twin-missed, vacuous-by-sampling and symptom-keyed guards are one error (reasoning about a representative instead of a population), 27/69 (39%), one detector — already reinvented six times in this repo under six names. - The shapes predate the closing-record convention (#1, #215, #232, #403, #473), so they are not an artifact of recent guard-building. That confound was tested and refuted, not assumed away. - A class the taxonomy missed entirely: check-and-use races over mutable state (#536, #622, #632, #706, #707). - Overclaim drops to 4% as a primary cause — a modifier, not a class. Round-churn likewise: 33 of 69 records narrate >=3 review rounds, spread across every family, only 2 in the class named after it. Part 2, measured rather than assumed: csharp-lsp cannot initialize and typescript-lsp cannot resolve typescript, the LSP tool has 0 calls across 811 transcripts, ruff/pyright are enforced nowhere despite the global instruction, no hook scripts are dead — but PreToolUse/PostToolUse execution leaves no durable trace, so we cannot tell whether our own guards fire. Names the classes where no mechanical detector is plausible rather than inventing weak ones, and strikes one proposed tool (shellcheck) after testing showed it does not catch the case it was proposed for. Provenance, kept here rather than in the document because a reader never saw the earlier drafts: six cold review rounds, worktree-isolated. Rounds 2-5 each found a real defect in the text written to fix the round before — two fabricated quotes, a Family A/C double-count, a miscited precedent (#711 argues FOR the enumeration it was cited as rejecting), a false floor-rounding claim, and a round-count built by pattern-matching that undercounted by half. Every one landed in new prose, never in the text under review, which is the document's own thesis operating on its author and the reason the final pass was whole-file rather than delta-scoped. Spawns #774-#781 and #784, tracked in the "Defect-shape hardening" milestone. fixes #773 Co-authored-by: Timothy <timothy@noreply.gitea.tblindustries.be>	2026-08-13 19:16:50 +00:00
timothyandtimothy	cfdab63a3a	fix(767): gate the release path on the delimiter ban with a prerequisite job (#770) ... The delimiter ban protecting `build`'s `Smoke + IPTV E2E` was enforced only by a pytest in `script-tests` — `on: pull_request`, not a required context — so nothing re-checked it on a `v*` tag push, which is exactly when the candidate image is published. A `scan` job now runs the ban test and `build` lists it in `needs:`, so a red `scan` skips `build` and no image is built. Measured both directions without cutting a release: run 1928 (poisoned Smoke) → scan failed, `Build & push` skipped; run 1929 (control) → scan green, build ran. The gate rests on three different KINDS of check, because each single kind was defeated in review: the ban test; an execution probe against a poisoned copy with all three `env:` tiers layered; and `scripts/ci-prove-ban-detects.sh`, which is not a test — it poisons the real checkout and vouches only for the ban test's `build` parametrisation failing. Eight review rounds; rounds 1-5 each found a real defect in the previous fix. Refs: #767 Decisions-Edit: yes Co-authored-by: Timothy <timothy@noreply.gitea.tblindustries.be>	2026-08-13 18:04:52 +00:00
timothyandtimothy	f9f8f65cee	docs(720): name all three Komodo stacks and the label-based resolution rule (#769) ... A live Komodo stack literally named `ersatztv` owns the TEST channel, not prod. `DeployStack ersatztv` succeeds, looks healthy, and promotes nothing — silent and plausible. Extends the existing callout with all three stack names and the resolution rule: identify the prod stack by the container's `com.docker.compose.project.config_files` label, not by stack name. Container labels re-verified live on jazz 2026-08-11; the verification date is scoped to what was actually re-measured, after review flagged the stamp as covering unchecked values. The server-management half (the `komodo` skill still uses the dead `media-servers` as its worked deploy target) cannot land in this repo and is tracked as server-management#743. #720's box 2 was re-scoped to that hand-off rather than ticked as though the skill were fixed. fixes #720 Co-authored-by: Timothy <timothy@noreply.gitea.tblindustries.be>	2026-08-11 19:26:07 +00:00
timothyandtimothy	884ac8a7e9	fix(756): extend the dropped-step guard to docker-build.yml's required jobs, where a drop is fail-OPEN (#768) ... A `run:` body the runner declines to interpolate is dropped, and the job still concludes `success` (#751). #751 fixed that in review-verdict.yml, where the failure is fail-CLOSED. This closes the two places where it is fail-OPEN: `Build & test (.NET)` and `EF migration integrity (SQLite + MySql)` are the other two required contexts on `main`, so a dropped step there sends a required check green having done no work. Per-STEP markers, not per-job as proposed: a marker on the first step only proves the job began, while the drop that costs something is `Test`, `Build` or a migration replay. The trailing guard carries no `if:` — with a dozen steps, `always()` would announce a false "these steps never executed" on every ordinary red build; the default `success()` is correct because guard-skipped implies job-red. Plus a ban on the raw `${{` opener in `test`, `migrations` and `build`, which makes the class unreachable rather than merely caught. `build` is included because its Smoke step runs AFTER the image is pushed. Measured live on the build lane in both directions: probe #765 (drop caught, sole failure in the job) and #766 (a failing continue-on-error step does not skip the guard). 510 tests, 30 mutations killed across two harnesses, five cold review rounds across two model families. Residual tracked as #767: the `build` ban is review-time only, not fail-closed on the release path. fixes #756 Co-authored-by: Timothy <timothy@noreply.gitea.tblindustries.be>	2026-08-10 23:35:08 +00:00
timothyandClaude Opus 5	e133c11fde	fix(751): rebase onto #760, close the fail-OPEN twin, and retire four claims that had rotted ... Fourth cold review round: no Blocker, no new path to a green `review-verdict/h10` on an unreviewed head, and it independently re-measured 14 claims in the diff. It also caught that this branch was about to revert someone else's work, and found the one remaining place where the nil-slice/clamp lesson had not been applied. REBASED ONTO 9881d1ff8 (#760), which landed while this was in review. The tell was the one CLAUDE.md documents: `git diff origin/main HEAD` showed deletions I never made — `docs/decisions/records/mcp/tool-schema-openapi-parity.md` and edits to `docs/mcp.md`. Pushing would have reverted them. The generated catalog was regenerated rather than trusted to the rebase, and verified to carry BOTH records. THE FAIL-OPEN TWIN, one function further on than the last round reached. `/statuses/{sha}?limit=100` is read twice — for the high-water mark and for the post-write race check — and neither pages, while `limit` clamps to 50. So "no raced row on page 1" does not establish "no race": a human `BLOCKED` landing in the write window can sit on a page the job never reads, leaving a forged green over a rejection. This is the ONE path in the design whose failure direction is toward SUCCESS. Measured rather than argued: a probe head reached 33 rows after ~5 runs against a cap of 50, and the ordering is only coarsely newest-first (`33,32,31,30,28,29,27,…`), so a few CI reruns reach it and the row's position cannot be relied on — which this workflow's own comment already disclaimed. That comment ALSO claimed order-independence flatly; false once the page clamps, so it now says what actually holds and what saves us. The mitigation is conservative rather than complete: if page 1 shows no race, page 2 is read, and any rows there — or an unreadable page 2 — count as "assume raced" and repair to `pending`. Uncertainty resolves to a stall a reviewer can clear, never to leaving green. Real paging of both reads, including the high-water mark, is #763. A THIRD empty shape turned up while modelling it: `/statuses/{sha}` past the end returns `[]`, where `/commits/{sha}/status` returns `{"statuses": null}` and the timeline returns bare `null`. Three endpoints, three shapes, one server. The code tolerates both here because guessing per endpoint has now been wrong twice. MY OWN COVERAGE GAP, found by mutation rather than by reading: inverting the unreadable-history-page-2 branch reddened NOTHING. Now tested both ways. Same class as the two untested refuse branches the review flagged, which are also covered now. FOUR CLAIMS RETIRED, all of the shape this issue is about — text that reads as checked and is not: * "18 tests fail" for the corrected-double mutation is 21 now, because rounds 3-4 added three fence-dependent tests. Broke a number while documenting broken numbers. Both citations now give the range and lead with the invariant. * "measured: 4, 2, 9, 5, 10" first-page timeline events are 7, 5, 9, 6, 10 today. Timelines grow; the figures are gone and the invariant stated instead — a PR is created by a push, and a push is an event, so page 1 is never empty. * The strict test's docstring said "RAW TEXT" while the test reads parsed `run:` scalars, with a dead `raw =` assignment left behind (a new ruff F841). * `len(bodies) >= 3` had zero slack: deleting the optional jq-preflight step reddened it with a message asserting the classifier had not been examined, which was untrue. The length assertion already carries the property, so the count only needs to be non-empty. Also: dead `_workflow_expression_fields_text` removed; assertion C's regex now catches `function foo {` as well as `foo() {`; the page-2 refusal says a human verdict clears it. Verification: 460 green. Five more mutations as intended — deleting the history page-2 check (red), accepting an unreadable one (red, after the coverage gap was closed), accepting a garbage page 2 in read_existing_verdict (red), hiding the marker write behind `function mk {` (red), and the earlier twenty-one still hold. Live re-probe on this body follows. Refs: #751 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-10 19:42:58 +02:00
timothyandClaude Opus 5	951dae26a9	fix(751): the truncation guard I added was DEAD CODE — the page cap is 50, not 100 ... Third review round, cut short by a transport hang after ~11h, but it had already found the thing that mattered: the guard added last round could never fire. `read_existing_verdict` asks for `limit=100` and refused when the page came back with 100 rows. This instance caps `limit` at the server-wide `MAX_RESPONSE_ITEMS`, MEASURED AT 50 — `/issues?limit=100` returns 50 items. A response can therefore never carry 100 rows, so the comparison was unreachable and the hole it was written for was still open. The sting is that the repo already knew. `scripts/pr-changed-files.sh`, two test files and `ci.script-tests-job` all document that Gitea caps `limit` at `MAX_RESPONSE_ITEMS` (50 in the PR #619 measurement). The review found it by grepping this codebase, not upstream. Writing a guard against a constant the repo had already measured as wrong is the same failure as the unfaithful test double two rounds ago: a number believed rather than checked. So this is now the THIRD guard for one hole, and the first two were both no-ops: 1. `.statuses | length` vs `.total_count` — `total_count` is the count for the PAGE RETURNED, not the commit (`?limit=1` on a 6-context head gives `len=1, total_count=1`). Equal by construction. 2. "refuse when the page is full at 100" — dead code, as above. 3. Ask the server. Completeness is needed ONLY to justify "no verdict exists on this head", so when the row is absent from page 1 the job reads PAGE 2, and refuses if it carries anything. Cap-independent: no reconfiguration re-breaks it, and nothing is hardcoded that a measurement could contradict. Measured to make sure page 2 is real rather than assumed: `?limit=3&page=2` on 3aed43c6 returns three further rows, and `page=9` returns the same `statuses: null` terminator the timeline uses. The probe is skipped when the row IS on page 1, because there is nothing to learn — the combined endpoint returns the latest status per CONTEXT, so a context cannot recur on a later page. TEST-DOUBLE FIDELITY, again the fiddly part. The stub now honours `page`, and that guard had to go BEFORE the read-counting modes: `appears-on-read:N` counts how many times the job has LOOKED at the status, and the completeness probe is part of the same look, not a further one. Letting it increment those counters shifted "the verdict appears on read N" by one and broke three mid-run-race tests — a false red that would have been easy to "fix" by adjusting the expected counts, which would have quietly destroyed what those three tests measure. Verification: 455 green. Four more mutations, each as intended — deleting the probe (red), accepting a non-empty page 2 (red), refusing even on an EMPTY page 2 (red, the deadlock control), and reverting the twin `statuses: null` gate (48 red). Twenty-one mutations across four rounds. Refs: #751 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-10 19:22:50 +02:00
timothyandClaude Opus 5	46ec532745	fix(751): re-review round — a truncation hole, and the tests that closed findings needed closing ... Cross-family re-review of the previous fix commit. It did NOT pass, and it was right not to: the round that fixed the reviewers' findings introduced two of its own, both in the tests written to close them. That is this file's recurring shape, and it is the reason the fix commit gets re-reviewed rather than the initial diff only. TRUNCATION (High). `read_existing_verdict` asks for 100 statuses and never checked whether the page was full. If a head ever carried more contexts than that, an existing `review-verdict/h10` could fall off page 1, the job would conclude no verdict exists, and it could post an exemption `success` over a human `failure` — the worst thing this gate can do. Six contexts exist today, so this guards a future shape, not a live bug. BUT THE PROPOSED GUARD WAS A NO-OP, and measuring is what showed it. The review asked for `.statuses | length` compared against `.total_count`. On this instance `total_count` is the count for the PAGE RETURNED, not for the commit: on 3aed43c6 (6 contexts), `?limit=1` gives `len=1, total_count=1` and `?limit=3` gives `len=3, total_count=3`. The two are equal by construction, so that check would have read as a completeness proof while proving nothing — and it would have been the second guard in this file to look like a check and not be one. What IS observable is a page at the requested limit, which means "maybe more", so that is now treated as unreadable: post nothing, leave the required check absent. The stub mirrors the per-page `total_count` deliberately, so the new test cannot pass for the wrong reason either. THE TESTS THAT CLOSED THE LAST ROUND'S FINDINGS: * The behavioural guard test — added to answer "a bare `exit 1` substring is satisfiable by dead code" — extracted the two marker lines BY TEXT and ran them alone. That passes even if the write is moved into a function nobody calls: the extractor finds the text, runs it at top level, the marker appears, and the test reports the guard proven while production writes no marker. It now executes the classify body's real PREFIX down to and including the write, which reproduces the production control flow instead of a reconstruction of it. Mutation: move the write into an uncalled function -> RED (it previously passed). * The anti-vacuity check — added to replace an over-broad assertion — hand-counted `run:` keys with a regex that only matched an indented `run:` starting `|` or `>`. It false-redded legal spellings (`- run: |`, a single-line `run: echo ok`) and could count a `run: |` sitting inside a heredoc. Hand-parsing YAML to validate a YAML parse is the wrong shape: it adds a second, worse parser whose every disagreement is a false alarm, and a red here blocks all merges. Now asserted on CONTENT — the walk reached >=3 bodies and one over 5000 chars. FALSE RED, THIRD INSTANCE IN THIS FILE. The repo-wide expression test scanned raw file text, so a delimiter in an inert top-level YAML comment redded the repo even though the runner never evaluates it. It now scans PARSED scalars: PyYAML drops YAML comments, while a `run:` body is itself a scalar and keeps its SHELL comments — which is exactly the distinction that matters, since inside a `run:` scalar a comment is not inert. Verified in both directions: an inert top-level comment passes, the same payload in a run-body comment still reds. Also: the `total_count` zero check now requires the JSON TYPE to be number — `jq -r` renders `0` and `"0"` identically, so a text compare accepted a corrupted `"total_count": "0"` as "no statuses". Verification: 455 green. Six further mutations, each landing as intended — the uncalled function (red), an inert YAML comment (PASSES, no false red), the same payload in a run-body comment (red), accepting a full status page (red), comparing total_count as text (red), and breaking the YAML walk's job key (red). Seventeen mutations across the three rounds. Re-probe of both live controls follows on this body; the previous probe evidence was taken before this commit and no longer describes what would merge. Refs: #751 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-10 19:22:50 +02:00
timothyandClaude Opus 5	edd8d3d9c9	fix(751): review round — the twin null-shape, a governance self-exemption, and four over-claims ... Two independent cold reviews (a cross-family GPT-5.6 pass and an isolated Opus pass). Neither found a path to a green `review-verdict/h10` on an unreviewed head. Both found real defects BESIDE the fix, which is the failure mode this file keeps producing. THE TWIN, and the reason not to trust "I fixed the two I could see". `GET /commits/{sha}/status` returns `statuses: null` — not `[]` — for a head with no statuses yet: `{"state":"pending","total_count":0,"statuses":null}`, measured on PR #739's head. `read_existing_verdict` gated on `.statuses | type == "array"` and took its `exit 1` path, posting NOTHING. Fail-closed, but the user-visible outcome is the one this issue is about: an exempt PR with no status and, since #743, no bypass. Its double printed `{"statuses": []}` at all three no-verdict sites, so that branch was unreachable in the suite — the same unfaithful-double story as the timeline, one function over. `null` is accepted only when `total_count` is 0, so a body that merely lost its array is still refused and an existing verdict is still protected. Swept `scripts/pr-changed-files.sh` too: `pulls/{n}/files` returns `[]`, unaffected. The generalisable rule is that a nil Go slice serialises to `null`, so every list-shaped field on this API is suspect and only a per-endpoint measurement settles it. A GOVERNANCE SELF-EXEMPTION, reachable again precisely because this change works. `DOCS_ONLY` matched `CLAUDE.md` and `AGENTS.md` — the documents that DEFINE the completion protocol, the merge-consent convention and the H10 rule. Driving the real classify body with a lone `CLAUDE.md` change produced `review-verdict/h10=success`. Protecting `.claude/` while the file specifying what it enforces stayed exemptible is the same self-exemption the header rules out, one directory over. Both added to PROTECTED; `README.md` deliberately not (ordinary prose, no enforcement). FOUR OVER-CLAIMS, corrected rather than defended: * The repo-wide expression test does NOT catch "any payload that cannot evaluate". It checks the HEAD TOKEN of each dotted path. `${{ github.ref == }}` and `${{ …head.sha + }}` pass; so does a renamed output, since tokens after the first are skipped by design. Claim corrected in the docstring, `docs/ci-cd.md` and the record. The test is kept permissive on purpose: a red here blocks every merge. * The strict test's anti-vacuity half banned expressions ANYWHERE outside `with:`/`env:`, so the standard `if: ${{ always() }}` spelling and even a delimiter in an inert top-level comment went red — a guard more dangerous than its target. Replaced with the honest property: the YAML walk saw every `run:` body it declares. * The `if:` assertion demanded the bare `always()` exactly; now normalised, since the wrapped form is identical to the runner. * `exit 1` was matched anywhere in the guard body, so an unreachable `if false; then exit 1; fi` satisfied it while the real branch said `exit 0`. Now required INSIDE the missing-marker branch — and the new behavioural test settles it properly by EXECUTING the guard body both ways. * The record asserted a repo-wide obligation to guard consequential steps. It is not repo-wide: `docker-build.yml`'s `test`/`migrations` are also required contexts and a dropped step there is fail-OPEN (green having done no work), strictly worse than here. Scoped to this file and tracked as #756 rather than asserted as done. Also: comments in both files still said it was unestablished whether a later step runs after a drop — runs 1863/1866 established it, so they now record the measurement; a cited test name that never existed; `kind` leaked to global scope; a mangled comment wrap; and an already-false "one event on page 1". Hardening of my own: `null` now counts as exhaustion only from page 2 ON. Every real PR's first page carries events (4, 2, 9, 5, 10 across #752/#753/#749/#739/#717), so a terminator on page 1 means no page was ever read, and certifying "no retarget" from a response we cannot explain is the one thing the fence exists to refuse. Narrows rather than closes it: a wrong `null` on page 3 still reads as exhaustion. Verification: 137 in this file / 452 total green; ELEVEN mutations each red — reintroducing the defect, deleting the guard, deleting the marker write, removing `if: always()`, `exit 1`→`exit 0`, a delimiter in the guard body, the fence gate (20 red), the TWIN gate (70 red), dropping the governance paths, accepting a null first page, and diverging the marker path between the two steps. Refs: #751 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-10 19:22:50 +02:00
timothyandClaude Opus 5	40b3747434	fix(751): the fence never trusted its count — a page past the end is null, not [] ... The scratch-base probe found a SECOND, independent reason `review-verdict/h10` was never posted automatically. Fixing the dropped step alone would NOT have restored the exemptions. `count_retargets` pages `/issues/{n}/timeline` and trusts its count only on a validated empty page, gated on `type == "array"`. But a page past the end of that endpoint is the JSON value `null` — measured at Gitea 1.27.1 on PR #752, four bytes — so the real terminator read as UNREADABLE. The walk never reached a validated empty page, `rt_ok` was never `yes` for ANY pull request, and the fence therefore withheld EVERY exemption `success`. Renovate and docs-only PRs got no status at all: the same user-visible outcome as the dropped step, by a completely unrelated route. The instance is not consistent between endpoints — `/issues/{n}/comments` returns `[]` when empty — so both shapes terminate the walk now, and the regression test is parameterised over both. The type is read as a VALUE (`case` over `jq -r 'type'`) rather than through `jq -e`, whose exit-status semantics already bit this workflow at jq 1.6 (#647). TWO REASONS THIS LOOKED DELIBERATE RATHER THAN BROKEN, both worth generalising: * It had never run. This fence shipped in 8f6d4f443 — the same commit whose prose comment stopped the classify step executing at all. Merging a guard and first executing it are different events, and only the second tells you anything. * The test double asserted the wrong shape while claiming to be measured. Its comment read "Real shapes, measured on this instance and deliberately mirrored" and it printed `[]` past the end, so the `array`-only gate was never exercised by the suite either. Correcting the double and restoring the old gate turns 18 TESTS RED — every one of them had been green for the wrong reason. A fidelity claim in a double is an assertion and it decays like any other. The new test asserts the POSTED STATUS, not the log: on the real probe run the log said `Decision: state=success` and the job still posted nothing, so the decision and the write are separate events and only the write is what a merge reads. Also here, both found while editing this code: * `ci.verdict-write-retarget-fence` stated this as a narrow residual ("a timeline over the 20-page cap can never be exempted") when the behaviour was universal. Corrected in place rather than left as a checked-looking claim that talks the next reader out of verifying. * The workflow cited `ci.paged-endpoint-completeness`, a key that has never existed as a record anywhere. Repointed at the record that actually owns this walk. Marker hardening from the probe: `RUNNER_TEMP` is `/tmp` on this runner, not a private per-job directory, so the start marker is now keyed on the run id and attempt. The lane starts a container per job today, which makes a fixed name fresh in practice, but that is a property of the lane and a stale marker would make the guard PASS on a run whose step was dropped — the exact silent pass it exists to remove. Verification: 446 passed; M7 (revert only the type gate, keep the corrected double) → 18 red. Probe evidence in the issue. Refs: #751 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-10 19:22:50 +02:00
timothyandtimothy	9881d1ff81	fix(754,757): declare graphicsElementIds + padToNearestMinute, and pin every MCP tool to its OpenAPI contract (#760) ... Co-authored-by: Timothy <timothy@noreply.gitea.tblindustries.be>	2026-08-06 20:42:37 +00:00
timothyandClaude Opus 5	f822e4737c	docs(743): label the second attested claim, close the survivor list, state the rule in CLAUDE.md ... Round 3 returned MERGEABLE with three LOW documentation findings. Batched before posting the verdict, since a new sha voids both the CI run and the verdict. - `ci-cd.md` labelled the unprobed half of the `enable_push` bullet but stated the `block_admin_merge_override` counterfactual flatly one bullet below — the same measured-vs-attested flattening round 2 fixed, one site over. Now labelled, with why it was not probed (verifying it means merging an unreviewed PR). - `release.verdict-status-check` said "what survives is the forgery list above". That record's job is enumerating survivors, so an unqualified "what survives is X" reads as exhaustive — and it omitted the admin residual, which is a SKIP route rather than a forgery one. Added. - `CLAUDE.md` never learned the rule. It is the always-read surface, and it still framed a direct `git push origin main` as a live path while describing a docs-only *push* exemption for a push the server now refuses. My corpus sweep covered `docs/` and missed the file that carries the docs-update rule. Note on what remains unverified rather than closed: neither direction of `block_admin_merge_override` was measured, and whether Gitea treats an ABSENT required context as blocking (versus satisfied) is asserted by our docs but not proven — the combined status on this PR reads `success` with `review-verdict/h10` absent. Both belong to #747's re-verification sweep. Verification: 441/441 script tests; decisions-validate OK. refs #743 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-06 00:35:41 +02:00
timothyandClaude Opus 5	6af65ba5c5	fix(743): re-tense the third stale site, and pin the two surviving mutants ... Round 2 of review. One blocking finding, and it is the same defect class as round 1's: a present-tense claim that this PR falsified. `release.verdict-status-check` — the record ABOUT the h10 status check — still said "direct pushes to `main` are server-side permitted, so the gate can be skipped without forging anything". A reader resolving that key from the catalog would conclude the control does not exist. Round 1 corrected `ci-cd.md` and `ci.actions-credential-scoping` and I stopped at the two sites I had edited, instead of sweeping the corpus by SUBJECT. Swept properly this time (`server-side permitted`, `bypassable`, `without forging`, `push whitelist`, `enable_push`): this was the only remaining stale site. Test gaps the reviewer found by mutation testing, now closed. Both mutants SURVIVED the suite as shipped — the round-1 fixes were correct but unpinned: - dropping `|| [ -n "${_h11_local_ref:-}" ]` → an unterminated final line is dropped. Two directions, and the dangerous one is not the obvious one: a dropped *branch* line leaves only tag refs and grants the exemption to a push containing a branch. Both pinned. - dropping `[ -t 0 ] ||` → the hook hangs forever on an interactive run. Pinned with a real pty and an explicit timeout, so a regression fails cleanly rather than hanging a CI job. Verified the mutant is killed by exactly that test (and that it dies via the timeout, 32s). Also from review, non-blocking: - `ci-cd.md:951` cited `enable_push: false` alone as what closed #743 — the precise thing the new record says never to do, since the force-merge route also skipped the gate with no forgery. Now cites both fields. - `ci-cd.md` flattened measured and source-attested into one 403: only the contents API was probed; the web editor/upload/apply-patch paths share the predicate but were not. Separated. - `format-as-you-touch-rebase` still said "the documented sequence" and "always" for the release-cut behind-ness. `docs/ci-cd.md` documents the tag step, not the release-notes-PR flow, and the frequency is attested by one observed cut. Attributed to #719 instead. - Documented the operator recovery path. `block_admin_merge_override: true` removes the `force_merge` escape that used to unstick a wrongly-red required context — that escape WAS the bypass, so it is gone by design, and the recovery (fix the status; last resort PATCH the field, merge, set it back) needed to be written down rather than left implicit in a residual. Verification: 441/441 script tests; decisions-validate OK; PyYAML parses all 193 records; both mutants confirmed killed and the hook restored byte-identical. fixes #719 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-06 00:10:45 +02:00
timothyandClaude Opus 5	6d80343320	fix(743): close the admin force-merge bypass; the push half alone was not enough ... Independent review found the record repeated on the merge path exactly the mistake it had just diagnosed on the push path. The push argument was: a whitelist naming `timothy` closes nothing, because `timothy` is the identity every credential already holds. The merge path had the identical shape and went unchecked — `block_admin_merge_override` defaults to `false`, so `CanBypassBranchProtection` returns true for a repo admin and `POST /pulls/{n}/merge` with `force_merge: true` merges straight past a missing or red `review-verdict/h10`. One API call, no forgery, no PATCH — cheaper than the push route this change had just removed. So `enable_push: false` alone did NOT make the gate load-bearing, which is what the record's headline sentence claimed. `main` now carries both fields; they are one control and neither is citable alone. An admin-shaped control that exempts the only admin exempts everybody. Other review findings addressed: - H11's owning record (`release.format-as-you-touch-rebase`) now documents the #719 tag-only carve-out. It is a narrowing of an existing convention, so it amends that record rather than adding a new one — including the two details that are easy to regress (the .husky/pre-push forwarding, without which the exemption is dead code the unit tests still pass over; and the at-least-one- ref guard against vacuous exemption). - The record now states which write surfaces were enumerated and how each was established — contents-API refusal is MEASURED here (403 `user cannot commit to repo`), apply-patch/revert/cherry-pick are source-attested only. The admin force-merge bypass is likewise marked source-attested, not probed: probing it means merging an unreviewed PR. - prepush-rebase-check.sh: process a final ref line with no trailing newline (previously dropped, which silently reinstated the #719 block), and skip the stdin read on a TTY so an interactive run does not hang. - Corrected a citation the review caught: docs/ci-cd.md documents the tag step, not a release-notes-PR flow. Cite #719 for the observed flow instead. Also fixed a frontmatter break this round introduced: a `: ` inside the unquoted `rule:` scalar. PyYAML rejected it while the dependency-free reader accepted it, so only `scripts/tests` caught it. Verification: 438/438 script tests pass; decisions-validate OK; PyYAML parses all three touched records. refs #743 #719 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 23:52:28 +02:00
timothyandClaude Opus 5	691a7acc77	fix(743): disable direct pushes to main so review-verdict/h10 is on the only path to main ... Gitea evaluates `status_check_contexts` when it MERGES a PR. A direct `git push origin HEAD:main` never consults them, so the whole h10 gate was skippable with no forgery — strictly cheaper than every route enumerated in #697. `main` now carries `enable_push: false`. Measured on this instance (Gitea 1.27.1) against a throwaway `probe-743-*` rule rather than against `main`: enable_push: false -> push by timothy (site admin) REFUSED, pre-receive hook declined enable_push_whitelist + ["timothy"] -> identical push SUCCEEDED That second line is why this is a DISABLE and not a whitelist: #743 offered the two as interchangeable, but the only write accounts here are `timothy` (site admin) and `renovate`, and every credential in the threat model — agent sessions, PATs, the injected GITEA_TOKEN — acts as `timothy`. A whitelist naming `timothy` would have ticked the box and closed nothing. Then demonstrated on `main` itself, per the issue's Done-when: a direct push was refused, and a tag-only push from the same worktree succeeded (tags are governed by `tag_protections`, which is empty). The release cut is unaffected. What this closes: the write-only credential routes — the injected GITEA_TOKEN, RENOVATE_TOKEN, any non-admin collaborator PAT. What it does NOT close: an admin credential can PATCH the protection off, push, and restore it. Recorded as an accepted residual rather than implied to be covered. Also corrects two claims the probe contradicted, and one that the mid-session Gitea upgrade (1.25.4 -> 1.27.1) invalidated: - ci-cd.md and ci.actions-credential-scoping both said "a push whitelist would close more of this class than the 1.26 upgrade". The whitelist form closes nothing here; corrected in place. - ci.actions-credential-scoping's rule said "do NOT add a `permissions:` key while this instance is below Gitea 1.26.0". That precondition no longer holds at 1.27.1, so the directive now misleads. Corrected — while noting the consequence is still UNVERIFIED: `/api/v1/settings/actions` 404s at 1.27.1, so whether `permissions:` binds here was not probed. The upgrade alone is not evidence the constraint works. - That record's 1.25.4 measurements are now dated, not current. Flagged as such rather than silently re-pinned to a version they were never taken on. #743's fourth box (docker-build.yml `persist-credentials: false`) is decided in the record and deliberately not done here: two of its checkout steps run `git fetch ... || true` feeding the changed-file skip logic, so a credential regression would be silent rather than loud. Drop the `|| true` masking first. fixes #743 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 23:31:45 +02:00
timothyandClaude Opus 5	b91939e5c4	fix(697): correct the overclaims three adversarial review rounds found ... Round 1 BLOCKED (1 Blocker, 4 High, 3 Medium, 2 Low); round 2 BLOCKED on the fix (1 Blocker, 2 High, 4 Medium, 2 Low); round 3 BLOCKED on one Medium. Every finding re-verified against the live instance before acting. ROUND 2 — the blocker was self-inflicted and the local gate could not see it. Adding `branches: [main]` to ci-image.yml re-points `ci-image-pin`'s `expected` at the editing commit, staling all five `container:` pins and failing that BLOCKING job — for a change altering zero bytes of the toolchain image. Reproduced: expected=ed9dd6254 vs pins=32747a0. Reverted here (the commit was amended, so no commit on the branch touches that path) and filed as #744. That edit had also FALSIFIED its own justification: branch publishing IS load-bearing — docs/ci-cd.md documents the rebase-recovery flow as "let ci-image.yml publish :<short sha>, then bump the pin", which is how you satisfy ci-image-pin from inside a PR. Reverting also keeps three trigger descriptions true (ci-cd.md:1043, the recovery flow, pr-checks.yml's escape-hatch comment). Also fixed: - gate-trigger-base-resolved.md was the file round 1's fix did not touch, and still said "no workflow route retains human provenance" — false, since a PR-added workflow can reference RENOVATE_TOKEN. Its `rule:` also kept the race framing, and `rule:` is what the catalog and MemPalace mirror. - `mechanics:` claimed "independent review confirmed no CI consumption breaks". It confirmed no such thing. Round 3 then caught the REPLACEMENT sentence making the same class of error: only the `container:` pull is exercised by a PR, because `build` carries `if: github.event_name != 'pull_request'` and cache-to/cache-from live only there. Those and the base-image pull first run on the post-merge push to main — a wrong inference reddens main, not the PR. - A fourth surviving route was unnamed: docker-build.yml publishes :prod from a `v*` tag push and a tag may point at any commit (tag protections are empty). "three surviving routes" became "at least these" — a count reads as complete. - Unmarked inferences, a "three later sections" that undercounted four, a dangling "the two items below", and a #744 rationale that stated the pin toll without its documented remedy. Local gate: 432 script tests pass; `decisions_validate.py --base origin/main --head HEAD` and `build_decisions_catalog.py --check` both exit 0; ci-image-pin recomputed by hand and matching the pinned commit. The record is 62 prose lines against a 60-line ceiling that is a `::warning::` by design (#520) — the blocking constraint is the 2-25% minority band, currently 10.8%. Refs #697, #742, #743, #744. Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 21:23:43 +02:00
timothyandClaude Opus 5	e298bb291e	fix(697): scope CI's registry credential so head-resolved workflows cannot forge review-verdict/h10 ... `REGISTRY_USER`/`REGISTRY_PASSWORD` were the ADMIN account's basic auth, and `docker-build.yml` triggers on `pull_request` — head-resolved — so a PR's own code was handed instance-admin credentials. Basic auth carries no scope, so the same secret that pushes an image administers every repo on the instance and can POST `review-verdict/h10`, the required context that makes merge-consent derived rather than assertable. Refs #697. Fixed at the credential, not the triggers: patching triggers enumerates instances of "a ref-resolved workflow obtains status-capable credentials", and adding a new workflow file is itself a route. `REGISTRY_PASSWORD` is now a PAT scoped `write:package` + `read:repository`. Verified on Gitea 1.25.4, not inferred: - registry push of a probe tag SUCCEEDED (cleaned up, confirmed 404) - GET /commits/{sha}/status SUCCEEDED (what ci-detect-already-validated.sh does) - POST /statuses/{sha} REFUSED, HTTP 403: required=[write:repository], token scope=write:package,read:repository Scope of what this closes, stated without overclaim. It closes the instance-wide admin escalation and that credential's durable forgery route — durable because a status POSTed with a USER credential carries a real `creator` and is inherited as a human verdict, while an Actions job's carries `creator: null` and is re-derived. It does NOT close the class. Three things survive it: - `RENOVATE_TOKEN` is a `write:repository` PAT of a real bot account in the SAME secret store, so it also posts with non-null `creator`. It cannot be scoped down (Renovate needs repo write), and secrets are a per-repo store that any PR-added workflow can reference. Closing this needs the provenance check tightened to an allow-list of approved reviewers. - Every job still receives a write-capable `GITEA_TOKEN`. `permissions:` YAML is a no-op before Gitea 1.26.0 and no `app.ini` lever exists at any version; only >=1.26 with the Actions default set to Restricted binds it. Tracked in server-management#714. - Branch protection binds the context NAME, not its issuer, so any write-scoped personal token forges the status with genuine human provenance. Unfixable in-repo. `h10` is a process guard, not a security boundary against push access. Auditing the secret STORE rather than the workflow set also surfaced `SERVERMGMT_DEPLOY_KEY`, still present though the `bump-prod-compose` job that used it was removed in 1b5efd7b9 — an SSH deploy key to another repo, obtainable by any PR-added workflow, with no remaining benefit. Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 20:34:34 +02:00
timothy	7be42654fe	fix(685): suppress both empty-states on error; name the addable-kind derivation ... Round-4 verification returned MERGEABLE with no new defects and no BLOCKER/HIGH/MEDIUM. These are its remaining LOW and nits. - "No results — try a search above." asserts a search that COMPLETED and found nothing, so it was false beside a failed request. Both empty-state messages are now suppressed on error and the role="alert" banner is the whole message, as that test's comment already claimed. Pinned positively and negatively so a refactor cannot satisfy the assertion by rendering nothing at all. - The (typeof ADDABLE_TYPE_LIST)[number] derivation is now the named AddableKind, spelled once instead of twice: a third ingress into the searched kinds is most likely to be written by copying one of the existing two, and the "one list, all ingresses" property should be visible at a glance rather than reassembled. - The §3b lesson cited two measured test counts, which go stale against the very suite they describe — a count taken before the helper had unit tests no longer holds now that it does. Scoped the observation to the sha it was measured on and replaced the counts with the invariant they were evidence for: every gate needs at least one test that reddens when that gate ALONE is removed. - Documented why the error banner stays conditionally mounted while the hint's live region does not: role="alert" is the one live-region role screen readers reliably announce on insertion, so the two are correct for opposite reasons. The review flagged the divergence as unexplained, not as wrong. refs #740	2026-08-05 19:40:07 +02:00
timothy	d7725c274c	fix(685): close the second ingress; stop the error path claiming a short query ... Verification round returned MERGEABLE with all three blocking findings resolved by measurement. These are its four remaining items. - DEFAULT_SEARCH_KINDS was the SECOND ingress into the searched kinds and was not derived, so the previous commit's "enforced by the type system" claim held for one of two paths. A non-addable kind there typechecked clean and would have overstated the hint with every one of its rows dropped — the exact defect the derivation exists to prevent. Now derived; verified by mutation that adding 'Collection' to it is a compile error. - The error path fell into the min-query guidance branch, so a valid 2-character query that got a 500 told the user to type at least 2 characters. That branch conflated "nothing searched yet" with "the last search failed". Newly introduced by the previous commit's error-path reset; now gated on !error and pinned by a test. - The aria-live region was mounted conditionally, creating the region and its text in one commit — which most screen readers do not announce. It is now mounted unconditionally with the condition inside. - The §3b lesson mis-stated where the duplicate gate lived: it was inside runSearch, the genuine single sink, NOT at one of the callers — so the rule as written ("put the gate in the single sink, not at each caller") described the revision that was rejected. Reworded to the actual lesson: the gate's home is the shared helper, and "it's the single sink" is not evidence it is the only guard. That misreading is why #685 got this wrong twice. Declined again, with reasons: the NaN pageSize edge (faithful to the sibling helper), the clamp test's unpinned lower bound (same), and the registry's disclosed same-identity substitution gap. refs #740	2026-08-05 19:20:26 +02:00
timothy	b6bf94f129	fix(685): test the helper's bound; delete the masking duplicate gate ... Independent review round 2 returned BLOCKED on two findings, both correct. - The helper's bound was dead code to the suite. searchLibraryBrowseItems had zero tests, so deleting its clamp OR its gate left the whole suite green — while the registry note claimed a caller "cannot skip the bound". That is the previous round's finding relocated, not removed. It now has the three tests its sibling searchLibraryPickerOptions already had (clamp, gate, compile), plus one pinning the full-row return that is its reason to exist. - The screen kept a second copy of the min-query check, and the two masked each other: the 1-character boundary test passed with EITHER gate alone, so it pinned nothing. The screen's copy is deleted; the helper is the sole gate. Measured before/after: with the duplicate present, removing the helper's gate left that test green; with it gone, the same removal reddens it. - §3b contradicted itself two lines apart — the parent still said "there is no truncation, so there is no truncation hint" above a sub-bullet mandating one. Reworded so a hint is permitted, required only where bulk selection makes the count actionable. Same correction to the 'search-bounded' definition. - A failed search left results/totalMatches stale, rendering a confident "Showing 75 of 60000 matches" beside the error banner. The catch clears them. - Results now carry a `Results for "<query>"` heading and the guidance is keyed to the settled query, not the live input, so rows are never shown without saying which search produced them. `selected` persists across queries (correct for a multi-select picker); the Add button's count keeps it discoverable. - The hint sums pre-filter totalCount against post-filter rows, which is only correct because every filterable kind is addable. MediaKindFilter is now derived from ADDABLE_TYPE_LIST, making that a compile error rather than prose. - aria-live on the hint; the #740 doc caveat no longer overstates the typeahead rule as a mandate this screen violates. Declined: the NaN pageSize edge (copied faithfully from the sibling helper) and the registry's same-identity substitution gap (already disclosed in that file). refs #740	2026-08-05 19:08:13 +02:00
timothy	4be3f247d8	fix(685): move the picker bound into the helper; surface the per-kind cap ... Independent review round 2. Verdict was MERGEABLE with no blockers; this takes the two recommended fixes plus the structural one it listed as a follow-up. - The bound was caller discipline, not code: getLibraryBrowseItems does not clamp pageSize, so the bound was only the constant this one call site chose to pass, and §3b is explicit that a bound a caller can exceed is not a bound. New searchLibraryBrowseItems in libraryBrowse.ts owns the min-query gate, the pageSize clamp and the titleContainsQuery compile, returning full LibraryBrowseItem rows plus totalCount (searchLibraryPickerOptions' {id,name} shape loses the mediaType that toAddItemsRequest needs). runSearch keeps one early return, for the spinner only, and no longer re-implements the gate. - The min-query guidance was keyed to the LIVE input, so backspacing below the gate after a search wiped the rendered rows and their checkmarks while `selected` and the Add button still counted them. Keyed to results.length too. - "Nothing left to hint at" was false: each kind is still capped at LIBRARY_PICKER_RESULTS and totalCount was never read. This is a bulk multi-select add, so the cap is surfaced — per-kind totalCounts are summed and rendered as "Showing N of M matches" once it exceeds the rendered rows. The registry note and the §3b bullet are corrected to stop claiming otherwise. - Gate boundary tested at 1 character (§3b: inclusive endpoints, or a > for >= slip passes the whole suite). - The guard test's deviation loop iterates an empty list now, so it gains one bidirectional assertion that is non-vacuous: the set carrying an `issue` field must equal the set classified 'deviation'. - The §3b bullet no longer reads as a conformance certificate: AddItemsDialog still lacks the seqRef and useIsMountedRef guards §3b mandates. That defect is PRE-EXISTING, not introduced here, and is tracked in #740. refs #740	2026-08-05 18:46:43 +02:00
timothy	28ce8c4dfe	fix(685): gate AddItemsDialog on a real query instead of windowing the whole type ... AddItemsDialog.runSearch was reachable with an empty query two ways — a blank form submit, and a kind-chip click, which called it immediately — and getLibraryBrowseItems omits a falsy `query`, so each path degraded into an unfiltered browse of the whole media-library type (first 50 rows, per kind) presented as the answer with nothing surfacing the truncation. All ten ADDABLE_TYPE_LIST entries are spa-conventions §3b Class B media-library types. The dialog is multi-select, so §3b's SearchPicker (single-select) does not fit; it takes §3b's constraints instead: - no request below LIBRARY_PICKER_MIN_QUERY, enforced in runSearch — the single sink both entry paths route through, not duplicated per caller - typed text compiled with titleContainsQuery rather than forwarded raw (a second latent §3b violation here: the search index's default field does not match bare title words) - each kind bounded to LIBRARY_PICKER_RESULTS - merged.slice(0, 50) removed — it silently dropped up to 100 of 150 fetched rows even for a real query Tests assert zero requests below the gate on both paths, exactly one bounded request per kind above it (20k-row fixture), the compiled+escaped query, and that no fetched row is dropped. Each was verified to fail with its mechanism removed. The pageSize registry entry moves from `deviation` to `search-bounded`. That leaves zero deviation entries, so the anti-vacuity assertion guarding that list is deleted deliberately, per its own instruction. Done-when box 4 (collection-family truncation hint) has no subject: this screen offers no collection-family type. fixes #685	2026-08-05 18:46:43 +02:00
timothy	5fa672e2e5	docs(release): record the v26.14.0 release notes ... Adds the v26.14.0 row to the release table. This is the commit the v26.14.0 tag will be pushed onto, matching how v26.13.0 was cut (#716). Contents since v26.13.0: the #726 bitmap-subtitle -readrate starvation fix (headline), the #674/#688 decisions-validator PyYAML cross-check, the #706/#707/#711 review-verdict raced-sentinel fix, and two Renovate bumps. Replaces the branch behind PR #738, which never received a pull_request CI run across six trigger attempts (two pushes, a force-push after rebase, a close/reopen, a body edit, and a spaced push on an idle queue). A workflow_dispatch run did complete green but writes no commit statuses, so it cannot satisfy the required checks. Opening a fresh PR produces an `opened` event rather than a synchronize, which is a different path. No [skip ci] token -- this branch's merge commit is the v26.14.0 tag target.	2026-08-05 00:44:00 +02:00
timothy	a2b3a56d93	Merge pull request 'fix(674,688): cross-check decision frontmatter against PyYAML; split the ceiling calibration claim' (#725) from fix/674-688-decisions-validator into main	2026-08-04 21:43:10 +00:00
timothyandClaude Opus 5	efc34a3481	fix(688): pin p95's inclusivity; drop a stale ratio and hedge the gap width ... Round 7's second reviewer returned MERGEABLE on the previous head after re-measuring every figure and running a 48-mutant battery — and reported ZERO wrong or unverified numbers, which ends this branch's five-commit streak of them. It also independently confirmed the round-6 adjudication: at `f394d6ce`, the sha the record cites, the #620-era distribution really is n=167, min 2, median 26, p90 52, next value 83. All five figures correct as written. This commit clears its four non-blocking items. - `marks_tail`'s UPPER inclusivity was the last meaningful surviving mutant: `ceiling <= p95` mutated to `<` survived the whole suite. Notice-only rather than blocking, but an unpinned boundary is how a documented claim quietly stops being true — the same defect the previous commit fixed for the coarse band. Both ends now pinned; verified the mutant fails. - "the largest by ~1.6x" was TRUE at `f394d6ce` (230/147 = 1.56) and is stale today (230/198 = 1.16). Unlike the consolidation table two paragraphs down, that sentence was never scoped to a sha — so rather than re-pin a number that will rot again, it now just says "the longest", which stays true however the tail moves. - The validator docstring asserted the 60->81 gap flatly; a 70-line record existed as recently as `8f6d4f443^`, so the gap's WIDTH is more volatile than that implied. Hedged to say it is the shape as measured today, not a constant. Nothing asserts it either way. - Rewrapped a mid-sentence line break left by the previous commit. Three surviving mutants are accepted and left: the crosscheck's not-a-mapping branch is unreachable from any fixture, the None -> "" normalisation only matters for an explicit YAML null no record has, and `_frontmatter_block` returning "" instead of None is a downstream no-op. Verification: 432 scripts/tests pass; ruff at baseline parity (47, and `ruff format --check` at parity 9/9); validator exits 0 with no drift notice; corpus at p90=60, 18/183, calibrated. Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-04 23:07:15 +02:00