172 Commits

Include renames

Author	SHA1	Message	Date
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	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	b8f60bdec4	fix(774): rescue the disjointness invariant the deletion silently took with it ... Cold review of the deletion caught what the deletion itself missed: the withdrawn parity test carried a SECOND, separable invariant. `test_no_word_is_both_positive_and_negative` had nothing to do with parsing shell — it prevented a verdict token belonging to both vocabularies, which matters because `check-review-verdict.sh` sets `is_pos` and `is_neg` from two INDEPENDENT `grep -iqE` calls. Deleting the file took it along, undisclosed. That is `process.enumerate-workaround-behaviors-before-deleting`, and I did not enumerate. Rescued BEHAVIOURALLY, which is why it survives where its parent could not: it EXECUTES the real classifier rather than reading its source, so no shell construction can fool it. The word list is a literal, and per `testing.guard-derives-population-from-source` that is legitimate here — the property is PER-MEMBER ("each of these classifies as exactly one thing"), not a completeness claim, so a word missing from the list is untested rather than concealed. It is explicitly NOT a claim that these are the only words the scripts accept; proving that still needs #788. THE MUTATION RUN CORRECTED THE DOCSTRING, which had been written first — the wrong order, and the third time this session that running a mutation contradicted something already asserted. Adding `mergeable` to NEG_RE left the test GREEN. Reading check-review-verdict.sh:212 explains it: `if [ "$is_pos" = 1 ]; then head_pos=1; else head_neg=1; fi` means `is_pos` wins, so that edit has NO observable effect — NEG_RE is shadowed by POS_RE for any overlapping word. The real direction is the reverse: adding `blocked` to POS_RE makes `BLOCKED` classify `positive`, and the test goes red naming it. Both mutations are now recorded in the docstring as measured, with which one is caught and why the other has nothing to catch. Also closed from the same review: issue #788's BODY still described the parity test as the live interim measure with an unticked "delete it" box, while only a later comment recorded the withdrawal. The body now carries a status banner, strikes the superseded line and ticks the box — fixed on the issue, since a stale first bookkeeping surface is the same defect class this branch fixed in post-review-verdict.sh. ruff clean, pyright clean, decisions-validate OK, 579 script-tests pass. (--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:18:51 +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	49fe17336b	fix(774): scope the scan to the case block — fixing the INPUT, not adding a fifth epicycle ... Round five. The confirmation review closed Q1 (the unquoted-value escape is gone) and found two things left: the file still described every loose match as a case ARM, and `_ANY_CASE_ARM` could false-RED on a `<word>) state=` inside a heredoc, a compact comment or an unrelated case statement. Both had one cause, and it was not the regex. Both patterns read the WHOLE FILE when their subject is a single `case` block. No amount of widening or narrowing fixes a wrong input — that is the treadmill this file's own docstring told the next session not to get on, and round five would have been the first step of it. The scan now reads only between `case "$verdict" in` and its `esac`. That removes the entire false-positive class at once, and it makes the "every case arm" language TRUE rather than nearly true — the overclaim and the false red were the same defect described from two sides. If the block cannot be located the helper REFUSES: falling back to the whole file would silently restore the false reds, and returning empty would make every assertion vacuous. Also from the same review: comparison is now a MULTISET rather than a set, so two arms sharing a label cannot let an unparsed occurrence hide behind a parsed twin — the same rule as testing.enumerating-guard-identity-not-position. And the failure message no longer offers two causes that scoping has since eliminated. Proven both directions: a heredoc containing `SHIP-IT) state=success ;;` leaves the suite green; the same line inside the case block reddens it. The limits list is updated, and records the removed class deliberately — it shows which fixes are worth making. What remains are same-line-shape misses, which really are regex-bound; the false-positive family was an input-scope bug wearing a regex costume. ruff clean, pyright clean, 580 script-tests pass. (Committed with --no-verify: the pre-commit hook exceeded the tool timeout on the previous commit; decisions-validate and the full suite were run explicitly above.) Refs #774 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-13 22:58:22 +02:00
timothyandClaude Opus 5	f89da6a197	fix(774): strip comments before the loose scan — the widening could false-RED a correct tree ... Self-audit of the round-four fix, before its confirmation review returned. Making `_ANY_CASE_ARM` permissive by construction closed the miss and opened the opposite failure: `#FOO) state=bar` — a comment with no space after the hash — satisfies the loose pattern and not the strict one, so it would be reported as an unparsed case arm on a completely correct tree. That direction matters as much as the miss did. A guard that reddens a correct tree gets deleted, and then catches nothing at all — which costs more than the construction the widening was for. Comments are now stripped before both scans, the same treatment the hook wiring check already needed for the same reason. Narrow: `# FOO) state=bar` with a space never matched, and the real file contains no such line today. Fixed anyway, because "narrow" is how each of the previous four rounds started. Proven three ways: a comment mentioning a hypothetical arm leaves the suite green; a real unquoted `SHIP-IT) state=success ;;` arm still reddens; clean tree green. ruff clean, pyright clean, 580 script-tests pass. Refs #774 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-13 22:52:54 +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	0c5938dd60	fix(774): the wiring check counted a MENTION, reproducing inside the fix the defect it closed ... Self-audit before re-review, and it found one. `wired_hook_files()` was added to stop hook EXISTENCE standing in for hook WIRING — but it substring-matched the filename against the whole husky text, and `.husky/pre-commit:7` reads # CI where a base ref exists). Fail-open shim — see .claude/hooks/decisions-guard.sh. one line above the real invocation. Delete line 8, keep line 7, and the hook still reads as wired. That is mention-for-invocation, which is the exact substitution the function exists to prevent, one line inside the fix for it. Comment lines are now stripped from the husky hooks first; settings.json needs no stripping because JSON has no comments. Proven both ways: with the invocation removed and the comment left, the guard names decisions-guard.sh as unwired; clean tree stays green. Also verified rather than assumed, since a fix round is where adjacent defects live: - a stale SELF-referencing proof ref is still caught (the self-reference escape hatch skips only the PROOF-row classification check, not the def-existence check); - a reworded summary is LOUD, not vacuous — an unparsed summary fails with a message saying so, rather than silently checking nothing. ruff clean, pyright clean (0 errors) on the three new files. Deliberately NOT ruff-format-ed: the pre-existing scripts/tests corpus is not formatted either, so reformatting only these three would diverge them from every sibling and bake in a format derived from an un-versioned config on one machine — which is the divergence #780 exists to settle. 580 script-tests pass. Refs #774 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-13 22:26:25 +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	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	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	20b117dabf	fix(751): round-5 findings — a rationale that was itself vacuous, and a third regex round ... Fifth cold review: MERGEABLE, no Blocker, no High. Four Low findings, none behavioural. Fixing all four rather than accepting them, because two are the exact class this issue exists to retire: text that reads as a checked reason and is not. A VACUOUS RATIONALE, on the branch about vacuous rationales. The comment on the history stub's `page` guard said it sits ahead of the read-counting modes "so the page-2 probe cannot shift 'raced row appears on read N'", by analogy with the combined endpoint. Measured: moving that guard AFTER the counter modes reddens NOTHING, because no history mode that counts reads ever issues a page-2 request — `raced=1` on page 1 short-circuits the probe. The real reason is the other half: page 2 must terminate for modes that describe page 1 only, and dropping just that `print("[]")` reddens `test_a_PRE_EXISTING_human_row_does_NOT_trigger_a_repair`. Comment now says which half is load-bearing and which was wrong. (The COMBINED endpoint's guard genuinely is counter-related — moving it reddens three mid-run-race tests.) THE FALSE REPAIR IS STICKY, and the previous commit undersold it as "a stall a reviewer can clear". It writes `$REPAIR_DESC`, which the classification refuses to grant an exemption over and re-writes as a fixed point on every later run — so a spurious repair removes that head's exemption PERMANENTLY, not for one run, and only a human verdict clears it. Still the right direction against a forged green over a rejection, but it is a per-sha loss of the exemption, and that is the argument for real paging (#763) rather than living with this. Said in the comment now. CORRECTING THE PREVIOUS COMMIT MESSAGE, which over-generalised: "uncertainty resolves to a stall … never to leaving green" is true of the page-2 probe and NOT of the enclosing path. An unreadable page 1, or a non-numeric high-water mark, still leaves the exemption `success` standing unverified. The workflow's own comments state that correctly; the message did not. THIRD ROUND ON ONE REGEX, which is the documented budget for a string-matching predicate. Assertion C started as `\w+\s*\(\)\s*\{`, gained `function\s+\w+` when review found `function mk {` slipped it, and STILL missed the union form `function mk() {` — the natural next spelling once the previous one is caught. Now `^\s*(function\s+)?\w+\s*(\(\s*\))?\s*\{`, verified against all seven spellings. THE COMPLETENESS COUNT, restored properly. Relaxing `len(bodies) >= 3` to `assert bodies` fixed a false red but threw away the only check that the walk reached ALL run-bearing steps: `max(len) > 5000` proves it reached the classifier and nothing about the short ones, so a helper that silently stopped yielding them would pass an unscanned delimiter. Now counted against the job's own step list, read directly rather than through the helper under test — which catches a helper reading the wrong key or dropping steps, while still tolerating a step being legitimately added or removed. Verification: 460 green. Three mutations, each as intended — the union spelling `function mk() {` (red, previously passed), a walk that drops the short steps (red, the property the count guard restores), and a legitimate step deletion (PASSES, confirming the false red it replaced stays fixed). Twenty-nine mutations across six rounds. Refs: #751 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-10 21:08:10 +02: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
timothyandClaude Opus 5	2bdb6c44e4	fix(751): a stray expression delimiter in a COMMENT killed the verdict gate ... `review-verdict.yml`'s classify step stopped executing on 2026-08-03 and the job reported `success` anyway, so `review-verdict/h10` — the branch-protection-required status — was posted by nothing but a human hand for three days, and both exemption classes (Renovate-manifest, docs-only) silently stopped working. The cause is one token in prose. The #706 note explaining why a concurrency group does not work here quoted a `concurrency:` snippet containing a PR-number expression as an ILLUSTRATION, inside a shell comment. A shell comment is not inert there: the runner scans the whole `run:` scalar for the expression opener before bash sees it, and one occurrence makes it rewrite the ENTIRE body into a single `format(...)` call. That rewrite is all-or-nothing, so a payload that does not parse — `pr number` does not — fails the interpolation of the whole scalar, and the runner then DROPS THE STEP AND CONCLUDES THE JOB GREEN. The prose documenting a fix disabled the fix. `git blame`/`git log -S` put the line in 8f6d4f443 (2026-08-03), which dates the outage precisely rather than "present in run 1832, not bisected further back". Three changes, deliberately different in kind: * The prose no longer writes the delimiters. It names the expression instead. * The classifier writes a start marker and a new `if: always()` step FAILS THE JOB when it is missing. This is the half that generalises: the delimiter was one bug in one comment, but a dropped step concluding `success` is what made it cost three days behind a green tick. It asserts execution STARTED, never completed — the classifier has several legitimate `exit 0` abstention paths. * Two static guards in scripts/tests/test_pr_changed_files.py: no expression delimiter in ANY `run:` body of the gate file (absolute, because a dropped step here is a dead merge gate and its bodies are ~700 lines of prose), and repo-wide, every expression payload must name a real context or function (permissive, because other workflows interpolate into `run:` legitimately). The second catches the class — a payload that cannot evaluate, wherever it appears. Note every pre-existing workflow-shape test reads `_code_lines()`, which strips comments. That is correct for what it was for, but it encodes the assumption this bug falsifies: inside a `run:` scalar a comment CAN change behaviour. The new strict test reads the raw scalar for that reason and must never adopt `_code_lines`. Blast radius, audited: PR #739 (docs-only) merged 2026-08-05 with ZERO commit statuses on its head, and got in only because admin force-merge was still enabled. #743 disabled that on 2026-08-06, so the workaround that absorbed this bug is gone — the next docs-only or Renovate-manifest PR would be permanently stuck. The two Renovate PRs in the window escaped by timing, merging minutes before the bad commit. Non-exempt PRs were unaffected throughout: humans posted their verdicts by hand. Verification: all six mutations red, restored tree green — reintroducing the exact defect (strict + general tests), deleting the guard step, deleting only the marker write, weakening `if: always()`, turning the guard's `exit 1` into `exit 0`, and putting a delimiter in the guard's own body. 129 passed on the fixed tree. Still to establish, and NOT claimed here: that the runner executes a LATER step after dropping an earlier one. The #751 evidence cannot say — the classifier was the job's last step, so there was never a subsequent step to observe. A scratch-base probe with a negative control answers it next; if the runner drops the rest of the steps too, this guard is inert and the body has to move into `scripts/`. Refs #751 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-10 19:22:50 +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	b91707b707	fix(719): exempt tag-only pushes from the H11 branch-freshness check ... H11 (.claude/hooks/prepush-rebase-check.sh) refuses to push a branch that is behind origin/main. It fired on tag-only pushes too, breaking every release cut: docs/ci-cd.md's "Cutting a release" flow lands a release-notes commit via PR and then tags that merge commit, so the local branch is always one commit behind origin/main at tag time. A tag push cannot revert anyone's merged work, which is the failure H11 exists to prevent, so skip the freshness check when every ref being pushed is under refs/tags/. .husky/pre-push previously consumed pre-push's stdin ref lines and forwarded them only to prepush-donewhen.sh; prepush-rebase-check.sh got none. Forward the captured $_prepush_refs to it too, or the new logic is dead. Guard against the vacuous-truth case explicitly required by #719: "all pushed refs are tags" is trivially true over zero ref lines (manual run, forgotten forwarding), which would silently disable H11 for every push. Require at least one parsed ref line before granting the exemption. Adds scripts/tests/test_prepush_rebase_check_tag_exemption.py using real local git repos (bare origin + a work tree pushed one commit behind it) to exercise git fetch/merge-base/rev-list against a genuinely-moved origin: tag-only allowed, branch-only still blocked, mixed branch+tag still blocked, and zero ref lines still blocked (the vacuous-truth guard). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 23:33:10 +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	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
timothyandClaude Opus 5	0ff9671393	fix(688): pin the minority band's constants and inclusivity; two prose corrections ... Review round 7. Its adjudication of the round-6 dispute went the branch's way — measured at `f394d6ce`, the sha the record actually cites, the #620-era distribution is n=167, min 2, median 26, p90 52. Round 6 had measured `fefd11dff` (p90 57), a different tree. The number stays as written. BLOCKING FINDING: the 2%/25% constants and their inclusive boundaries were not pinned at all. Mutating 0.02 -> 0.03, 0.25 -> 0.30, or either `<=` to `<` passed all eight calibration tests. Those are not free parameters — they ARE the documented CI-red thresholds, so a silent shift would quietly falsify the 38/718 figures in docs.corpus-size-signal and docs/ci-cd.md (a strict cap reds after 37 long additions, a strict floor after 717 short ones). test_the_minority_band_BOUNDARIES_are_exactly_where_documented pins all four. It uses 100-record fixtures so k over the ceiling IS k%, and both 2/100 and 25/100 are exactly representable and compare equal to the constants — true boundary cases, not near-misses. Verified by mutation: all four now fail it. PROSE - corpus-size-signal said what stays blocking is "what routine growth cannot break", immediately before explaining that 38 routine additions break it. Now "what no SINGLE ordinary addition can break", which is what is actually true. - docs/ci-cd.md said the fine claim is "never asserted"; it is never asserted AGAINST THE LIVE CORPUS, and IS asserted on synthetic distributions the tests own. Corrected — the distinction is the whole design. Correction to an earlier commit message in this branch (9d2b30dc3, already pushed, so recorded here rather than rewritten): it said the cross-check was clean on "all 183 real records". 183 is the active keyed-record count; the cross-check scans the record WINGS — 195 files at that commit, 190 of them carrying frontmatter. The check was clean; the figure named the wrong population. Verification: 432 scripts/tests pass; ruff at baseline parity (47); validator exits 0 with no drift notice; corpus at p90=60, 18/183, calibrated; new record still 60 lines. Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-04 22:52:03 +02:00
timothyandClaude Opus 5	2ff52d4236	fix(688): make the n oracle dynamic; correct a tense that asserted false history ... Review round 6: one MERGEABLE with non-blocking prose, one NOT-MERGEABLE with a real test defect. Both addressed. THE n PIN DID NOT PIN ANYTHING. `assert n == 10` was checked against a fixture holding exactly ten records, so a mutation returning a constant 10 for EVERY input satisfied it — while changing the live denominator from 183 to 10, which is precisely the production defect the test was added to close. A single hardcoded count cannot tell "counts the input" from "returns this number". Now a dynamic oracle at two distinct cardinalities; verified the constant-n mutation fails it. "MOVED p90 by 21 lines" asserted a history I had not measured. 21 is TODAY's gap (60 -> 81). The actual #672 event was smaller — at that tree p90 was 60 with the next value 83, so the 62-line record moved p90 to 62 and reddened CI with a 2-line move. The capability claim is what matters and is true at both refs; the past tense was not. Changed to "can move" in the two places that asserted it, which also makes all four sites agree with docs/ci-cd.md and the validator docstring, both of which already said "could". A REVIEW FINDING I REJECTED, having measured it. Round 6 called "p90 52" wrong for the #620-era distribution, measuring 57. That measurement is at `fefd11dff`; the record cites `f394d6ce`, and at THAT sha p90 is exactly 52 (n=167, min 2, median 26). The number is correct as written and is unchanged. Recording the disagreement rather than silently keeping it: the reviewer measured a different tree than the one the claim names. Also corrected in this branch's own commit message trail: `b24c51ab5` said origin/main has three 59-line records; it has four 59s and two 60s (HEAD: four and three). The claim that survives, and the only one the code and docs now make, is that NOTHING sits between 61 and 80 at either ref — verified independently at both. Cosmetics from the same round: a dangling modifier in ceiling_calibration's docstring, a test_decisions_lib assertion message that said "field(s) differ" when faults can now also be rejections, and a sentence in corpus-size-signal that named the replacement test without saying what it asserts. Verification: 431 scripts/tests pass; ruff at baseline parity (47); 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 22:35:00 +02:00
timothyandClaude Opus 5	b24c51ab51	fix(688): stop enumerating multiplicities, pin n and the keyless filter, de-couple the vacuity floors ... Review round 5. One reviewer returned MERGEABLE with prose findings; the other found four more, two of them real test gaps. Both are addressed here. THE MULTIPLICITIES WERE WRONG AGAIN — fourth commit running. The "measured" sequence 59, 59, 60, 60 -> 81 is measured nowhere: origin/main has 59, 59, 59, 60, 60 and HEAD has four 59s and three 60s. I had even tagged it `(measured)` in a canonical decision record. So this stops enumerating them. All four sites now state only the load-bearing, stable fact: the lengths climb to the ceiling and then jump STRAIGHT to 81 with nothing in between, so one record moves p90 by 21 lines. The multiplicities change with every record added; the gap is the point. This is the same "fix the boundary, not the site" move the tests got three rounds ago, applied to prose that had failed four times. TEST GAPS - Deleting the over-tight test removed the only pin on CeilingCalibration.n: a mutation returning n=1 passed all 19 relevant tests while printing a wrong denominator in the drift notice. Pinned. - The `if r.key` filter was load-bearing in production and unpinned: main() passes the UNFILTERED list (194 entries, 11 keyless, one a 106-line "Records formerly in this file" scaffolding block), while every test handed the function a pre-filtered list — oracle and production agreed only by accident. Pinned. - The --record-ceiling 0 arm's claim that it "cannot go vacuous for any non-empty corpus" was FALSE: an empty record body is validator-valid and record_prose_lines returns 0, so a corpus of empty-bodied records has no offender at 0. Now -1, which makes the claim true. - The three `len(recs) > 100` vacuity floors were themselves growth-coupled — 83 legitimate retirements would red them even with the ceiling still calibrated, which is the #688 class in the guard rather than the assertion. Lowered to >20 where a floor is meaningful, and to plain non-empty on the derived-ceiling test, whose derivations need nothing more. - test_main_FEEDS_the_crosscheck now compares against `set(record_wing_files())` instead of a hardcoded basename, killing the same mutation with zero corpus dependence. PROSE - "ordinary growth cannot cross it — NOT immune" contradicted itself in four places. Now: no SINGLE ordinary addition can cross it; this is measured headroom, not immunity. - "trimming or archiving 15" blurred two different denominators. Trimming leaves 3/183 = 1.64%; archiving leaves 3/168 = 1.79% because the denominator moves too. Both verified, both under the floor, now stated separately. Verification: 431 scripts/tests pass; ruff at baseline parity (47 — a 121-char docstring line briefly took it to 48 and is rewrapped); validator exits 0 with no drift notice; corpus at p90=60, 18/183, calibrated; record still 60 lines. Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-04 22:11:25 +02:00
timothyandClaude Opus 5	c56dfdd539	fix(688): delete the last over-tight test, pin the crosscheck's INPUT, fix 4 prose defects ... Review round 4, both reviewers. Both report the code path SOUND and the #688 coupling class analytically gone (rows proved, not merely observed green); one caught 28 of 30 mutations. What blocked was one over-tight test, two unpinned mutations, and prose — including two defects the PREVIOUS commit introduced while claiming to fix numbers. TESTS - Deleted test_adding_ordinary_records_cannot_RED_the_blocking_property. It appended two long records to the LIVE corpus and asserted flags_minority on the RESULT, so it crossed the cap two records before production does (56/221 vs 54/219) — a test named "cannot RED the blocking property" being a tighter tripwire than the property. Fourth instance of the #688 defect in this change. Deleted rather than tuned: both its jobs are already covered off live data (the synthetic v4/v5 contrast, and the deliberate live guard at the production threshold). - test_main_FEEDS_the_crosscheck_the_REAL_wing_files closes a mutation hole found by review: replacing `pyyaml_frontmatter_faults(record_wing_files())` with `...([])` in main() left the ENTIRE suite green. Both existing wiring tests monkeypatch the function, so they pinned that its RETURN reaches errs, never that its ARGUMENT is the corpus — the '#609 marker that printed OK while doing nothing' defect one level up, which is the exact thing the new record indicts. Verified: the mutation now fails this test. - test_main_actually_REPORTS_... went vacuous whenever the ceiling legitimately goes green (`False is False` passes with the whole warning branch deleted). Added an arm at --record-ceiling 0, which no non-empty corpus can make vacuous. - Pinned two surviving mutations: ceiling_calibration's n_over boundary (it recomputes the count, so oversized_records' exclusivity test does not cover it — `>` vs `>=` differs by the 3 records sitting exactly on the ceiling) and p95's quantile (the 95/5 fixture cannot tell 0.95 from 0.99). PROSE — two of these were introduced by the previous commit, whose stated job was fixing numbers. That is the pattern worth naming, not the individual typos. - "so ONE new record could move p90 lines" — the previous commit deleted the magnitude and left the sentence ungrammatical. Now "by 21 lines". - It also introduced a THIRD variant of the sequence it was correcting ("60, 60, 60") and missed a FOURTH site in ci-cd.md still saying "twenty lines". All four sites now read the measured 59, 59, 60, 60 -> 81, and 21 lines. - 59- and 60-line records were described as "above the ceiling"; they are at or below it. - "routine growth cannot cross it" overstated the bound: it is deliberately less sensitive, not immune. Reworded, and the THIRD and tightest arm is now documented wherever the other two appear: consolidating 15 of the 18 offenders drops below the 2% floor (verified: 3/183 = 1.64%). That is in real tension with test_oversized_records_can_go_green and is stated as accepted — at 3/183 the constant genuinely is mis-calibrated — with the remedy named: a consolidation PR that large should re-derive the ceiling in the same change. - Corrected a docstring that called the 999-ceiling failure "silently deleting the assertion"; it would go red, not silent. Verification: 430 scripts/tests pass; ruff at baseline parity (47); validator exits 0 with no drift notice; corpus at p90=60, 18/183, calibrated. The two new claims were measured, not assumed: the empty-list mutation fails the new test, and 15 consolidations reaches 1.64%. Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-04 21:47:24 +02:00
timothyandClaude Opus 5	0db56c3ebd	fix(688): remove the last live-corpus tripwires and three fabricated/wrong numbers ... Review round 3, both reviewers, NOT-MERGEABLE. Nothing needed rework — the code path was found sound and mutation-sensitive (a 17-mutation battery caught every mutation with the semantically correct test). What was left were tripwires and prose. TRIPWIRES - `assert need > 20` was the tightest live-corpus assertion left in the blocking job: it reds after 16 over-ceiling additions, while `flags_minority` — the property #688 exists to protect — survives to 36. An arbitrary threshold on a live order statistic is the ratchet wearing a different hat. Removed; the measured headroom lives in prose, where being out of date costs a doc fix rather than someone else's red build. This also removes an unbounded `while` loop that HUNG the suite rather than failing it when the ratio could not reach the cap. - test_main_reports_ceiling_drift hardcoded ceiling 999, which is not guaranteed above p95: ten valid 1000-line records make 999 calibrated and silently delete the test's only assertion. Now derived as max+1, off the tail by definition. - test_main_actually_REPORTS_the_ceiling_and_the_trend required >=1 over-ceiling record. The ceiling is ALLOWED to go green (test_oversized_records_can_go_green says so), so that would red the blocking job the day someone consolidates the last offender — punishing exactly the work the warning asks for. Restated as an IFF. - test_no_budget_flag_means_no_retirement_warning asserted no bare "RETIRED" in stderr; a legitimate stale record whose TITLE contains the word reds it. Matched precisely now. - Added the >100-record vacuity guard its siblings carry to the derived-ceiling test. NUMBERS — all three were mine, and two are the failure mode this repo calls worse than no note at all (a confident claim that was never measured): - "the lengths above the ceiling ran 60, 61, 62, 63 then jumped to 81" is FABRICATED. No record of 61, 62 or 63 lines exists at origin/main, at the #672 sha, or at the #706 sha. Measured, the sequence is 59, 59, 60, 60 then 81 — a 21-line jump, so the conclusion was if anything understated. Corrected in all three places it was repeated, including the canonical v4 row of docs.corpus-size-signal. - The crosscheck record called `decisions-guard` a REQUIRED check — introduced by the previous commit in the sentence rewritten to fix an overclaim. Verified against Gitea branch protection: `main` requires exactly `Build & test (.NET)`, `EF migration integrity` and `review-verdict/h10`. NEITHER script-tests NOR decisions-guard is required; the record now says so. - docs.corpus-size-signal said 37 additions "to reach" the cap two paragraphs above 38 "below the cap" — a same-document numeric inconsistency of exactly the class this change set out to remove. Both now state 38 to BREACH, noting 37 lands on 0.25 and passes. - Also: the old bound's accepted range is 39..229 (not 43..229 — 43 is the NEW bound's lower edge); "95% over the ceiling" was 100%; `oversized_records` said the #620 distribution began at 0 lines where the record itself says 2. Verification: 428 scripts/tests pass; ruff at baseline parity (47); validator exits 0 with no drift notice; corpus at p90=60, 18/183 over the ceiling, record trimmed to 60 lines so main ships calibrated. Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-04 21:26:52 +02:00
timothyandClaude Opus 5	b3a8826281	fix(688): stop asserting live-corpus order statistics anywhere in the suite ... Review round 2 (both reviewers, independently) found the round-1 fix incomplete: the live-corpus coupling survived in two more tests. This is the THIRD instance of one defect class in this change, so the fix is to remove the coupling rather than patch another site. BLOCKER — test_adding_ordinary_records still asserted live order statistics. The `if before.marks_tail:` guard made the PRECONDITION conditional but left the CONCLUSION (`assert not after.marks_tail`) an assertion about the live p90. Verified: appending 16 ordinary 30-line records — nothing long, nothing unusual — makes both sides true and fires it, reddening the blocking job for an unrelated author. Exactly what #688 exists to abolish. The v4-vs-v5 contrast moved to test_v4_would_have_reddened_where_v5_holds, built on a distribution the test OWNS, reproducing the shape that matters (a sparse gap just above the ceiling). The real-corpus test now asserts only the robust claims: the additions were counted, v5 holds, and the measured headroom. Same treatment for the "bad ceiling" teeth test, which hard-coded that 200/229/230 stay rejected on the live corpus — three new 200+ line records flip it. Teeth now demonstrated synthetically; the only live-corpus assertion left is that today's ceiling is accepted, which needs 38 over-ceiling or 718 short additions to break. The IFF drift test could lose its quiet branch: one 61-line record makes BOTH the 60 and 999 ceilings drift, at which point an UNCONDITIONAL notice would pass. Both ceilings are now DERIVED — p90 itself (always calibrated, since p90 <= p90 <= p95) and max+1 (always off the tail) — so each branch is guaranteed by construction, and the test asserts it exercised both. Added the missing regression test for the typed-mapping-key TypeError: removing `key=str` now fails a test instead of only a manual probe. Corrected against measurement: the v5 row of the record's own version table still stated the REJECTED first-draft bound (`0 < f < 1/3`) — the canonical artefact contradicting both the code and its own next paragraph; accepted range is 43..180, not "roughly 45..150"; breaching the cap takes 38 additions, not 37 (37 lands exactly on 0.25, which passes under `<=`); "5x headroom below the floor" was inverted; ci-cd.md said four versions "all ratcheted" when v1 was vacuous and v2 accepted an absurd ceiling; and the crosscheck record overstated protection — script-tests is NOT a required check, so "no broken record has reached main" is procedural, not structural. Evidence the coupling is actually gone: mid-fix the corpus sat at marks_tail=False (an edit pushed this branch's own record to 61 lines, moving p90) and the suite stayed fully green. Under the old assertions that state reddened CI. The record is trimmed back to 60 so main ships calibrated and no drift notice nags. Verification: 428 scripts/tests pass; ruff at baseline parity (47); validator exits 0 with no drift notice; corpus at p90=60, 18/183 over the ceiling. Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-04 21:02:01 +02:00
timothyandClaude Opus 5	80818aa294	fix(674,688): address independent review — restore the coarse bound's teeth ... Two independent cold reviews (one cross-family) agreed on the top two findings. 1. The #688 fix was defeated by its own complement test. test_main_is_QUIET_about_ drift asserted the drift notice was ABSENT while running main() over the LIVE corpus — whose failure condition is bit-for-bit v4's assertion, in the same blocking job, three functions down. p90 sat exactly on 60, so one over-ceiling record would have reddened it. Replaced with an IFF test that uses ceiling_calibration as its oracle, so it asserts the WIRING rather than the corpus's current state, plus a guard that at least one branch fires. 2. The coarse bound was nearly unfalsifiable. `0 < fraction_over < 1/3` accepted EVERY ceiling from 39 to 229 on the real corpus — including the ceiling of 200 my own docstring offered as the case it catches, because one 230-line record keeps the count nonzero. That claim was simply false and is corrected. The floor is now a FRACTION (2%) and the cap 25%, which rejects 200/229/230 and 20, and accepts roughly 45..150. Headroom measured, not estimated: 37 consecutive over-ceiling additions, against ONE record to break v4. 3. yaml.safe_load raises a bare ValueError, not a YAMLError, on a well-shaped but impossible date (stale-after: 2026-06-31), which escaped as a traceback and killed the validator on any machine with PyYAML. The except is now deliberately broad, with a test. 4. PyYAML returns TYPED mapping keys, so a stray `1: x` made sorted(set|set) raise TypeError. Sorted with key=str. 5. The headroom prose was arithmetically wrong (~42/~40 where the real values are 63/64; each addition moves numerator AND denominator) and the record counts were stale. Corrected against measurement. 6. test_adding_ordinary_records passed identically with its two additions removed. It now asserts the additions were counted, and that they break the v4 property while leaving v5 satisfied — guarded by `if`, never asserted, since whether v4 currently holds is a fact about the live distribution and asserting it would rebuild the ratchet. Also recorded honestly in docs.frontmatter-pyyaml-crosscheck: decisions-guard installs no PyYAML, so in CI the cross-check always skips and script-tests already caught both hazards — the CI delta is close to zero and the real fix is the local loop plus the tool/suite agreement. And the new record was trimmed 64 -> 58 prose lines: at 64 it moved p90 to 64 by itself, i.e. this PR would have reddened the old blocking job. That is now cited in the test as the live demonstration. Verification: 426 scripts/tests pass; ruff at baseline parity (47); validator exits 0; corpus back to p90=60, 18/183 over the ceiling, marks_tail and flags_minority both true. Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-04 20:37:27 +02:00
timothyandClaude Opus 5	9d2b30dc3b	fix(674,688): cross-check frontmatter against PyYAML; split the ceiling calibration claim ... Two defects in scripts/decisions_validate.py, fixed together because they share the validator and its pytest suite. #674 — the validator reported OK on frontmatter PyYAML rejects. The hand-rolled reader is deliberately dependency-free (decisions-guard and the Husky hooks install nothing), so it cannot see a bare apostrophe closing a single-quoted scalar. Hit twice in one session by two independent agents. `pyyaml_frontmatter_faults()` now cross-checks the parse against PyYAML whenever PyYAML is importable, and is SKIPPED with a ::notice:: when it is not — the read path stays dependency-free. The two known hazards fail differently and the fix covers both: the apostrophe makes PyYAML reject the document, while an unquoted ` #` parses fine and silently TRUNCATES the value. So the check compares parsed results key by key rather than try/except-ing the load, which is also what makes it generalize past the two known characters. PyYAML wrote these files, so on disagreement it is authoritative and the file is the defect. The comparison has one implementation, called by the validator and by the existing test_decisions_lib agreement test, so the tool and the suite cannot drift. #688 — test_real_corpus_ceiling_sits_at_the_TAIL_BOUNDARY asserted p90 <= 60 <= p95 in the BLOCKING script-tests job. p90 sat exactly on the ceiling and the distribution above it is sparse, so one ordinary record moved p90 by twenty lines and reddened CI for whoever wrote it; it reproduced twice live (#672, #706) and both times the only in-scope remedy was trimming the new record to fit the constant. v5 splits the claim by robustness instead of hunting for a better single assertion. The blocking test now asserts only the coarse, non-ratcheting property (the ceiling flags a nonempty proper minority, 0 < fraction_over < 1/3); the fine tail-boundary claim is measured every run and REPORTED as a ::notice::, on the same reasoning stale_records already uses — a constant going out of date is the passage of corpus growth, not a defect in the commit under test. The fine property is still asserted, against synthetic distributions the test owns. The ceiling stays 60. Verification: 424 scripts/tests pass; ruff at baseline parity (47 before and after); the cross-check is clean on all 183 real records; a positive control pins that record_wing_faults alone still reports both hazard files as clean, so the new red cannot pass for the wrong reason; and a test demonstrates that appending #672's 62-line and #687's 107-line records to the real corpus does not red the blocking property. Docs: new record docs.frontmatter-pyyaml-crosscheck, docs.corpus-size-signal updated for the v5 split, catalog regenerated, docs/ci-cd.md updated for both. fixes #674 fixes #688 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-04 20:15:16 +02:00
timothy	fe3d29276a	fix(706): count a raced SENTINEL, not only a raced human verdict ... Round-5 cold review: the post-write check counted only human `Review-verdict:` rows above the high-water mark, which is not sufficient under the run overlap this branch measured. Sequence, all inside that regime, runs A and B on the same exempt-classified sha: the human BLOCKED lands BELOW A's mark (so A cannot see it), B masks it with an exemption `success`, and only afterwards writes the sentinel. A then finds nothing human above its mark, does not repair, and posts its own `success` on top of the sentinel. The human rejection is permanently green and every later run re-derives it — the repair race failing toward SUCCESS, while the record states it fails toward `pending`. The filter now counts two row shapes above the mark: a human verdict (non-null creator, `Review-verdict:` description) OR a machine sentinel (null creator, description exactly $REPAIR_DESC). A then repairs and both runs converge on the fixed point. It cannot false-fire: a pre-existing sentinel would have been seen at the FIRST read and forced the pending path, and this block only runs after a `success`, so a sentinel above the mark can only have been written mid-flight by another run. Mutation-verified on both halves independently — dropping the sentinel alternation reddens the new test; dropping the human half reddens the original race-2 test — so neither can be removed without a test noticing. Refs #706	2026-08-03 22:22:09 +02:00
timothy	a8bbd74a64	fix(706): never replace a sentinel with a non-sentinel ... Round-4 cold review: the mid-run sentinel guard tested `state = success`, which is one branch too narrow. A run can reach the POST on `state=pending` carrying the GENERIC description — most realistically after a transient enumeration failure (`complete != yes`) — and such a run passed the success-only guard, passed the fence, and overwrote the sentinel with ordinary text. The next run then saw no sentinel, re-derived, and posted `success`: the same buried human rejection as the round-2 defect, reached in two steps instead of one. The guard now compares the DESCRIPTION rather than the state: if [ "$ex_repair" = yes ] && [ "$desc" != "$REPAIR_DESC" ] "Never replace a sentinel with a non-sentinel." This is strictly more general and exactly as precise, because the carry-forward branch guarantees that a sentinel seen at the FIRST read already sets `desc` to the sentinel — so the guard cannot fire on the ordinary repaired-head path and the fixed point stays intact. It also makes the code match the decision record, which already stated the general property ("a run whose last-moment re-read finds a sentinel it did not see at its FIRST read ABSTAINS instead of posting") while the code implemented only the success case. Of the two, the code was the one that had to move. Mutation-verified on both clauses independently: reverting to the success-only condition reddens the new pending-path test; dropping the description check reddens the fixed-point test and the sentinel-from-the-start control. Refs #706	2026-08-03 22:13:36 +02:00
timothy	5077408528	fix(706): abstain when a repair sentinel appears mid-run ... Round-3 cold review: `ex_repair` was recomputed by the last-moment re-read but never consulted after it, so the POST wrote the `$state` frozen at classification time. A stale overlapping run therefore posted its `success` straight over a sentinel another run had just written — burying a human rejection with no repair (the human row sits below the stale run's own high-water mark) and no log entry. This is the one path in the design that failed toward SUCCESS rather than `pending`, so it was not covered by the recorded residual, and it is reachable through exactly the run overlap this branch measured live (probe PR #722: the older run finished 20s after the newer one started). The guard is exact rather than conservative: a sentinel present at the FIRST read forces `state=pending`, so `success` together with `ex_repair=yes` at re-read time can only mean the sentinel arrived mid-run. Abstaining is then strictly correct and, unlike the retarget fence, needs no successor run — the sentinel row is already `pending` and already carries the re-post instruction. Mutation-verified three ways: removing the guard reddens the new mid-run test while its positive control stays green; making it unconditional on `ex_repair` reddens the fixed-point test and the positive control, proving the condition is precisely scoped and not merely present. Also strengthens the mark-ordering test to pin the status-history FETCH as well as its initialisation, closing the refactor evasion review flagged; sliding the fetch past the re-read now reddens it. Refs #706	2026-08-03 22:06:42 +02:00
timothy	63040296f4	fix(706): make the repair sentinel a fixed point, not a two-event delay ... Round-2 cold review found the round-1 sentinel self-clobbering: the branch refused the exemption but fell through to the shared else, which posts the GENERIC "Awaiting review verdict" description — erasing the very marker the refusal depends on. The next run saw an ordinary machine `pending`, re-derived it, and posted `success`, burying the human rejection two events after the repair instead of one. The single-hop test passed throughout, and the positive control asserting that an ordinary machine `pending` DOES re-derive was itself the proof of the second hop. Durability is a fixed point, and only a chain can assert a fixed point, so the new test runs the job twice and feeds run N's own posted description in as run N+1's existing status. Keyed on `ex_repair` alone rather than on the exempt path: the fact recorded is "a human verdict was lost on this sha", a property of the sha rather than of this run's classification. Verified by mutation — restoring the defect turns the chained test RED while the single-hop test stays GREEN, which is exactly why the chain was needed. Refs #706	2026-08-03 21:58:06 +02:00
timothy	8f6d4f4432	fix(706,707,711): fence the review-verdict write on the timeline retarget count ... Three related defects in the `review-verdict/h10` gate, all surfaced by the cross-family review of PR #705. #706 race 1 — a stale run could overwrite a fresher verdict, permanently. The race was reproduced live rather than reasoned about (Gitea 1.25.4): with every other workflow stripped, probe PR #722 showed run 7520 (`opened`) finishing 20s AFTER run 7521 (`synchronize`) started. `pull_request_target` runs for one PR genuinely overlap, older finishing last. The issue proposed serializing with a non-cancelling concurrency group. That is REFUTED by measurement: with the group active, runs 7528/7529 still overlapped and 7528 ended 36s after 7529 began. A first probe appeared to show the group working — a negative control with no `concurrency:` key at all showed the same cancellations, revealing Gitea auto-cancels superseded `push` runs on its own and the probe had measured that, not the group. The auto-cancel does not extend to `pull_request_target`. The fix leaves the runs unserialized and instead makes an overtaken run decline to write: count `change_target_branch` events on the PR timeline at start and again just before the POST, and post nothing if the count moved. The COUNT is the key because the branch NAME is ABA-vulnerable (`main -> S -> main` reads `main` at both ends — how #698 route 1 forged its exemption). Abstaining is a handoff, not a stall: every retarget fires `edited`, so the event that makes a run abstain has already queued its successor. `updated_at` was rejected as the key precisely because it moves for comments/labels, which queue nothing. #706 race 2 — a human BLOCKED landing in the unclosable window between the pre-POST re-read and the POST was silently turned green. After an exemption `success` the job now re-reads the per-POST history and repairs its own status to `pending` if a human verdict appeared above a high-water mark taken just before the write. The repair is `pending`, never a copy of the human's state. The id comparison is load-bearing: a presence test would fire forever on a base-mismatched verdict and deadlock that PR's exemption. #707 — `pr-changed-files.sh` bound `.base.ref` and `.head.sha` across the enumeration but never `.base.sha`, so an ordinary advance of `main` mid-paging could drop a code path from an offset-paged diff and leave a complete-looking docs-only list. Now bound from the JSON already fetched (no new round trips). #711 — `.codex/` added to PROTECTED. It mirrors `.claude/hooks/` byte for byte, including the merge-consent hook, so the "a PR that can weaken the gate cannot exempt itself" rule had an incomplete path list. Latent today (untracked), live the moment anyone tracks it. Residuals are stated, not implied: a retarget inside the final round-trip, and the repair being itself a read-then-write. Gitea's status API has no compare-and-set, so neither reaches zero; both now fail toward `pending`. Tests: 398 pass in scripts/tests. Each new guard was mutation-checked — the fence's motion comparison, the untrusted-count gate, the repair POST and the id high-water mark were each neutered in turn and the intended test went red while its positive control stayed green. fixes #706 fixes #707 fixes #711 Decisions-Edit: yes	2026-08-03 21:41:16 +02:00
timothyandClaude Opus 5	fe00e0d71f	fix(698): compare the recorded base exactly, never parse it out ... Review round 5 returned BLOCKED with one High, and it needed no forgery and no #697 — just a branch name. `main)evil` IS A VALID GIT BRANCH NAME (`git check-ref-format --branch 'main)evil'` succeeds). A genuine human verdict earned while head H targeted it is written `(base: main)evil)`. Truncating at the first `)` yields exactly `main`, which matches a PR that has since been retargeted onto `main`, so the verdict is inherited over a completely different diff. I had asserted the opposite in a code comment one commit earlier — that a `)` in a branch name "mismatches — safe direction". That was generalised from `feat/foo)bar`, which does mismatch, and is false for EVERY branch whose name starts with the target base. Two attempts at extracting this value have now been defeated (`##` last-marker by an appended marker, `#` first-marker by this), so the lesson is the shape, not the off-by-one: do not parse a value out of user- or attacker-influenced text when you can compare against the exact expected literal instead. The description must now END with the literal `(base: <this PR's base>)` AND contain exactly ONE marker — the marker count kills the append trick without having to decide which occurrence is authoritative. Pure shell (`${#}` arithmetic), no truncation to abuse. Verified across all six shapes, including a PR that legitimately targets `main)evil` (accepted) and `(base: )` (rejected). Absent markers remain accepted, since verdicts predating #632 carry none. Mutation-verified: restoring the truncating parse reddens only the new paren test, while the appended-marker, matching-base and legacy tests stay green. 385 tests pass. Note for the record: pytest has never executed inside the review sandbox in any of the five rounds, so the suite has only ever been run here. Refs: #698 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 20:51:57 +02:00
timothyandClaude Opus 5	ef92b46dd2	fix(698): parse the recorded base at its FIRST occurrence, not its last ... Self-found while writing the round-5 review brief, by asking what an attacker who can influence the status description (#697) could do to the parse I had just added. `${ex_desc##*"(base: "}` is greedy, so it reads the LAST occurrence. A description of `Review-verdict: MERGEABLE @ abc1234 (base: probe/scratch) (base: main)` therefore parsed as `main`, matched the PR's base, and the verdict was inherited — reopening the exact hole the base check was added to close, one commit earlier. Measured both forms before choosing: first-match yields `probe/scratch`, mismatches, and fails closed. Two adjacent cases confirmed to fail in the safe direction: a `)` inside a branch name truncates the value (mismatch), and an empty `(base: )` is present-but-different (mismatch), so neither is waved through by the legacy-absent-base allowance. Tests for both, and the appended-base test is mutation-verified: restoring `##` reddens it. 384 tests pass. Refs: #698 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 22:11:08 +02:00
timothyandClaude Opus 5	e7bae06385	fix(698): review round 5 — a human verdict formed against ANOTHER base is no longer inherited ... Round-4 cross-family review returned BLOCKED with a single Medium; the three round-3 items were confirmed actually fixed. THE SHA-BINDING WAS ESCAPABLE THROUGH THE HUMAN PATH, not the exemption path. The short-circuit identified a human verdict by creator + `Review-verdict:` prefix and then exited before looking at the base. So: earn a GENUINE `success` on head H while it targets a scratch base with a benign diff, then retarget H onto `main`, where its diff carries unreviewed code. Creator real, prefix real, status inherited — a green required check over code nobody reviewed. `post-review-verdict.sh` has recorded the reviewed base in the description since #632; this gate simply never read it. The merge-consent hook did compare it, but that is advisory and covers only its own path: a merge through the Gitea UI or API sees nothing but the status. The gate now rejects a verdict whose recorded base differs from the PR's. An ABSENT base is deliberately NOT a mismatch — verdicts predating #632 carry none, and re-deriving over one would un-approve a genuinely reviewed head. Only present-and-different is rejected, which is exactly the escape. Tests: the mismatch case, plus two positive controls (matching base still short-circuits; a legacy no-base verdict still short-circuits) so the check cannot pass by blanket rejection. Mutation-verified: removing the check reddens only the mismatch test. Also from round 4: sharpened the docstring of test_the_classify_step_runs_without_SHELL_ERRORS. It catches guards that die NOISILY; it is not a general liveness check, since a clean mutation like hardcoding n_protected=0 emits nothing. The branch-discriminator test is the actual liveness guard. Claiming otherwise would have made a cheap net look like a strong one. And fixed a dangling decision key I had just introduced: the base-in-description convention belongs to `release.verdict-status-check`, not the `ci.verdict-records-base` I invented — the breadcrumb hazard our own retrieval rules warn about. 382 tests pass. Refs: #698 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 21:44:44 +02:00
timothyandClaude Opus 5	d4c600149d	fix(698): review round 4 — the PROTECTED guard was DEAD; define before use, fail closed, fix prescriptive docs ... Round-3 cross-family review returned BLOCKED with 3 Mediums. The first was serious and self-inflicted. THE PROTECTED GUARD WAS A NO-OP. Round 3's `count_matching` / `count_not_matching` helpers were defined AFTER the classification chain that calls them, so `count_matching` was `command not found` on every run, `$( )` yielded an empty string, `[ "" -gt 0 ]` errored, and the `elif` was simply skipped — the protected-path check never executed at all. Confirmed by direct execution before fixing. Three "protected path" tests stayed GREEN throughout, because a protected path is also not a manifest and not docs-only, so the job still reached `pending` down a different route. Asserting the STATE could not distinguish a working guard from a dead one. The mutation battery missed it too: I had mutated the predicates, not their reachability. Fixed three ways: * helpers are defined immediately after `gh()`, before any use; * the three counts are evaluated ONCE at TOP LEVEL and validated numeric, because `exit 1` inside `$( )` leaves only the subshell and, with the substitution sitting in a conditional, `set -e` never fires either — so a grep error had been silently reading as "no match". A non-numeric result now aborts with nothing posted, and an absent required check blocks the merge; * the helpers return a non-numeric sentinel instead of trying to `exit`. Verified: an invalid regex now exits 2 and posts NOTHING (previously it classified and posted). Renaming the helper at its definition turns six tests red. TESTS, aimed at the failure mode rather than the symptom: * assert the DISCRIMINATOR (the job's `Decision:` reason line), not the outcome — when several branches yield the same verdict, the verdict cannot tell you which ran. A first draft of this test asserted the status description and failed against a WORKING guard, because for `pending` the description is constant; * a cheap stderr sweep for `command not found` / `integer expression expected` / `unbound variable` across four representative PR shapes. Each of those makes an `if` condition merely false while the job exits 0 and posts a plausible status, so this catches a whole family of silently-skipped guards. DOCS. The record and ci-cd.md still PRESCRIBED the here-string that round 3 removed — following them would have reintroduced the temp-storage failure. Both now prescribe counting, define-before-use, top-level evaluation and numeric validation. The workflow's measurement paragraph still said the npm manifests "are included" three lines above the note saying they are excluded; corrected. 379 tests pass. Refs: #698 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 21:13:56 +02:00
timothyandClaude Opus 5	d8bd1dcba9	fix(698): review round 3 — count instead of matching, re-read before the POST, fix stale docs ... Round-2 cross-family review returned BLOCKED: 2 High + 3 Medium. HIGH — here-strings traded one fail-open for another. `grep -q… <<< "$data"` fixes the SIGPIPE inversion, but bash materialises a large here-string via temporary storage, so it fails when temp space is full or unwritable — and since these sit inside `if`/`!`, that failure flips the predicate exactly as SIGPIPE did. It did NOT reproduce on my bash 3.2, DID on the reviewer's Linux bash 5.x, and CI is Linux; the disagreement is itself the argument for a construct that cannot fail either way. Path predicates now COUNT with `grep -c`, which drains stdin (no early exit, no SIGPIPE) over an ordinary pipe (no temp file), and grep's status is read honestly: exit 1 means "zero matches", a legitimate answer, while >1 is a real error that FAILS THE JOB rather than silently reading as "no match". `set -e` does not catch these on its own — they sit in command substitution inside a conditional. Verified correct under 171KB input AND an unwritable TMPDIR. The description test became a `case` prefix match, removing another pipeline from a security predicate. New record `ci.grep-q-pipefail-inversion` covers the whole class. HIGH — a human verdict landing mid-run was still overwritten, and the code claimed otherwise. The job read statuses once, classified over several round-trips, then posted: a reviewer posting BLOCKED in between had it replaced by an exemption `success`, turning an explicit rejection into a merge. Added a re-read immediately before the POST which refuses to write over a human verdict found then. The heading no longer says "never overwrite" — it cannot promise that, since there is no compare-and-set on Gitea's status API. Remainder tracked as #706. MEDIUM — documentation was stale in three places, all mine. The record's frontmatter `rule:` still listed the npm manifests (I fixed the body and forgot the frontmatter, so the canonical rule AND the generated catalog were wrong); docs/ci-cd.md still said `edited` was absent from `types:`, contradicting a section I had just updated; and the workflow header still implied the `edited` re-run settles the ABA race. All corrected to say detection, not atomicity. TESTS. 373 pass. New: a mid-run human verdict via a status stub that returns nothing on the first read and BLOCKED on the re-read, and large-input regression tests for the ADVISORY hook, which had none — the copy with less authority is the one that quietly keeps a bug (#649's whole point). Mutation-verified: reverting the hook predicate, the workflow predicates, or the pre-POST re-read turns exactly the intended tests red while every positive control stays green. Refs: #698 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 20:53:36 +02:00
timothyandClaude Opus 5	bafb487eaa	fix(698): review round 2 — close a PRE-EXISTING SIGPIPE inversion, narrow the bot allow-list, correct two overclaims ... Cross-family adversarial review returned BLOCKED with 3 Blockers + 2 Highs. Two were verified independently before acting on them. BLOCKER 1 (pre-existing on main, not introduced here). `producer | grep -q…` inverts under `set -o pipefail`: grep exits at its first match, the producer takes SIGPIPE and exits 141 once the list exceeds the pipe buffer, so a MATCH is reported as a FAILED pipeline. Reproduced at 1901 paths / ~171KB, inside the enumerator's 2000-file cap: * `A.cs` + 1900 docs paths -> docs_only=yes, status 141 (a C# PR exempted) * `.gitea/…` + 1900 docs -> the PROTECTED guard MISSES entirely The second reaches a green required status on a PR rewriting the gate, with no retarget, no bot account and no forged status. This construct shipped with the original docs-only check (review-verdict.yml:257 on main), so it was live. Fixed in both the enforced gate and the advisory hook by using here-strings, which have no writer to signal. New record `ci.grep-q-pipefail-inversion`. BLOCKER 2 (mine). `web/package.json` / `web/package-lock.json` are removed from BOT_MANIFESTS. renovate.json enables only nuget/github-actions/dockerfile, so npm is unmanaged here and the entry bought nothing — while package.json `scripts` are EXECUTED by CI (npm ci, npm run build). It widened an exemption onto a code-execution path for no benefit. BLOCKER 3 + HIGH (documentation was wrong, code unchanged). The claim that `edited` made the retarget residual "non-durable" is retracted: runs are not serialized, so a stale run can post `success` after the reclassifying run posts `pending`. The ABA transition is narrowed and observable, NOT closed. Likewise the provenance check asks "posted by a user credential", not "posted by a reviewer" — ETV_STATUS_AUTH is basic auth, so a #697 forgery gets a non-null creator AND an attacker-chosen description and is preserved as human. Both now stated at full strength. TESTS. 4 large-input cases crossing the pipe buffer, each paired with a large-input POSITIVE control so "large lists now fail closed" (a deadlock) cannot pass as a fix. Verified by mutation: reverting the here-strings turns all three negatives red while the control stays green. Two of my own weak tests fixed — the "base advances" case called head_moves_to(SHA) with the already-current sha (a duplicate positive control, now a structural assertion that the comparator is .base.ref and never .base.sha), and the arity test counted five arguments without checking the fifth was the base. The whole class was invisible because every previous test used a handful of short paths: a guard whose behaviour depends on a buffer threshold needs a test that crosses it. Refs: #698 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 20:35:29 +02:00
timothyandClaude Opus 5	f523fc535d	fix(698): bind the base, constrain the bot exemption by content, re-derive unattributable successes ... The `review-verdict/h10` exemption path decided from mutable or unattributed PR state, and a machine-written `success` was never revalidated. Three routes, one root cause, so one change. Route 1 (reproduced live as probe PR #703, closed unmerged): `/pulls/{n}/files` diffs against the PR's LIVE base, so retargeting moves the answer without moving the head sha. A PR opened into `main` and retargeted mid-run enumerated docs-only and was granted `h10=success` while its diff against `main` carried a C# file; retargeting back reclassified nothing. `scripts/pr-changed-files.sh` now takes the expected base branch as a REQUIRED 5th argument (optional would be a silent opt-out) and checks it before and after paging; the workflow passes it from the `pull_request_target` payload, which a retarget cannot rewrite, and `edited` is in `types:` so a retarget reclassifies. A pinned two-sha diff would close route 1 outright but Gitea 1.25.4 cannot serve one: `compare/{base}...{head}` returns no `files`, and a `--depth=1` fetch of the two shas has no merge base. Measured, not assumed. The residual window is stated in the code and the record rather than papered over. Route 2: `pull_request.user.login` is the PR's immutable CREATOR while its head is not, so pushing code onto an open Renovate branch kept the exemption. The bot exemption now also requires EVERY path to be a dependency manifest — a set measured across all 11 Renovate PRs this repo has had, not guessed. Route 3: the never-overwrite short-circuit exited on ANY `success`, so a forgery obtained once was inherited forever. It now fires only for a status positively identified as a human verdict (non-null `.creator.login` AND a `Review-verdict:` description — measured: user-posted statuses carry a creator, Actions-posted ones carry null). Written in the positive direction so an unrecognised shape is re-derived rather than trusted. The two exemptions are composed, not chained: as an `elif` chain a Renovate docs-only PR lost the docs-only exemption. Caught before commit and pinned by a test. Tests: 17 new cases in scripts/tests/test_pr_changed_files.py, each verified by mutating the clause it covers (8 mutations, 8 kills). Both records trimmed under the 60-line prose ceiling so the corpus tail-boundary check stays calibrated. Does NOT close the class: anyone who can POST a status directly can still impersonate a verdict — that is #697, deliberately left open. Refs: #698 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 19:52:00 +02:00
timothy	20b7171fba	fix(672): review round 2 -- correct a stale rule: field, document the self-test gap ... Re-review of the fix commits returned MERGEABLE (nine trigger mutations all caught, every prior finding verified against independent sources) with four low-severity findings. All four are addressed here. F1: `release.verdict-status-check`'s `rule:` frontmatter still said "A `pull_request` workflow auto-passes the two exempt classes". Round 1 past-tensed that record's BODY and left its `rule:` stale -- which is the exact failure mode the previous commit cites as the reason to put limitations in `rule:` in the first place. The catalog row mirrors this field verbatim and it mirrors again per-`key:` into MemPalace, so a stale `rule:` propagates further than a stale paragraph. F2: same record, "is what makes the rollout self-hosting" -> past tense. It described #630 and now reads as a live property. F3, the one that matters operationally: base resolution cuts BOTH ways. A change to `review-verdict.yml` is no longer exercised by its own PR -- the PR runs the version already on `main` -- so an edit goes live only ON MERGE, repo-wide, having never run. A broken edit merges green and then breaks the gate for every subsequent PR, and the PR that would repair it is gated by the same broken workflow. The recipe for verifying one safely (scratch base + throwaway PR + probe-named context) now lives in docs/ci-cd.md, which is where an operator looks, rather than in the record. F4: the sibling-workflow guard globbed `*.yml`, so a workflow added as `.yaml` would be silently unscanned. Latent today, which is when it is cheap. The record lost its meta-justification paragraph to the 60-line prose ceiling. Fifth trim this session; the operational recipe moving to ci-cd.md is better placement anyway, but it was forced rather than chosen. ersatztv#688. Refs: #672 Decisions-Edit: yes	2026-07-28 23:03:15 +02:00
timothy	35a8ea8aef	fix(672): review round 1 -- pin the trigger set exactly, sweep the stale claims ... Cold review found the first cut of the test satisfiable by a still-vulnerable config, and two prose claims that outran the evidence. The test asserted "pull_request_target present, pull_request absent". Adding `workflow_dispatch:` or `push:` ALONGSIDE it kept that green, and both are ref-resolved with secrets, so either one restores an equivalent self-supplied-definition path. Enumerating those two would have the same hole one trigger later, so the assertion now pins the whole set: exactly {pull_request_target}, nothing else. Verified by mutation -- adding `workflow_dispatch` now reds. Adds the guard that would have caught the residual below rather than only the instance: no workflow OTHER than review-verdict.yml may reference `review-verdict/h10` in executable lines. Scoped honestly in its docstring as a drift guard, not a security boundary -- a workflow can still write the status through an indirection a text scan cannot see. `release.verdict-status-check` item 4 still asserted, in the present tense, that a PR editing review-verdict.yml is judged by its own edited copy. That is now false for this workflow, and it is the record a reader resolving the gate from the catalog actually lands on. Past-tensed, with the surviving residual named. The probe count said three. There were four; the omitted one is the only one with a negative result, which is what turns an honest partial into an overclaim. Corrected in both the record and ci-cd.md, along with what was NOT measured (`reopened`/`ready_for_review` firing under the new trigger). Also records two operational consequences a maintainer will otherwise hit cold: retargeting a PR onto `main` leaves it statusless until its next push (`edited` is not in `types:`), and the required contexts carry a literal `(pull_request)` suffix, so repeating this fix on docker-build.yml would rename them and deadlock merges unless branch protection is edited in the same operation. Trimmed the record back under the 60-line prose ceiling -- for the second time this session, which is ersatztv#688 reproducing, not a defect here. Refs: #672 Refs: #697 Decisions-Edit: yes	2026-07-28 21:49:22 +02:00
timothy	cf907f0988	fix(672): trigger the verdict gate on pull_request_target scoped to main ... `review-verdict.yml` writes `review-verdict/h10`, the status branch protection requires on `main`. It triggered on `pull_request`, and Gitea resolves a `pull_request` workflow DEFINITION from the PR's own head commit — so a PR editing this file ran its own rewritten copy and could post `h10=success` for itself. `PROTECTED` did not help (the rewrite defines it too), and neither did branch protection, which requires the context rather than an author and carries `required_approvals: 0`. The #649 base-ref checkout binds the SCRIPTS this job runs to the base. It cannot bind the job definition. Only the trigger can. Measured on this instance (Gitea 1.25.4) with three throwaway scratch PRs rather than inferred from GitHub, since the premise is a claim about someone else's software: A. A PR rewriting the workflow posted its own probe context and the real `review-verdict/h10` was never written — the base definition never ran. B. Under `pull_request_target` the identical rewrite was ignored: the BASE definition ran and posted `h10=pending`, on `opened` and `synchronize` alike, with `secrets` still available. C. With `branches: [main]`, a PR into a non-main base produced no run and no status at all. The probes only ever posted probe-named contexts, never a forged `h10`. `branches: [main]` is half the fix, not a refinement: base resolution means the BASE branch supplies the definition, so without it the rewrite simply moves to an attacker-pushed base — and a status forged there is inherited by any later real PR with the same head sha (#663). `pull_request_target` is safe here only because this job never checks out or executes head-supplied code; the base-ref checkout is what makes the trigger usable, so the two are one decision. Rejected `required_approvals: 1` as the cheaper fix: Gitea forbids approving your own PR and this is effectively a single-maintainer repo, so it would deadlock every PR rather than gate the dangerous ones. Three mutations confirm the new test discriminates rather than merely passing: reverting to `pull_request`, dropping the `branches` filter, and re-adding `pull_request` alongside the safe trigger each go red with a distinct message. It parses the YAML instead of substring-matching because `pull_request` is a prefix of `pull_request_target`. Refs: #672 Decisions-Edit: yes	2026-07-28 21:28:38 +02:00