151 Commits

Include renames

Author	SHA1	Message	Date
timothy	dafa56452c	test(807): make "threaded through every branch" a checked property ... `_resolve` returns three sets and the third has to reach every composition site. That was a claim in a docstring; each site is a separate opportunity to forget, and forgetting is silent — no error, just a smaller population. Ten sites enumerated and asserted: top level, `allOf` arm, `if`, `then`, `else`, `dependentSchemas`, `oneOf` arm, `anyOf` arm, `items`, `prefixItems`. All ten currently thread it. Witnessed load-bearing by dropping the threading at three of them — `allOf` reddens 1 case, `oneOf`/`anyOf` 2, `items` 2. The value is not today's ten passes; it is that a NEW composition keyword has one visible place to be added to, instead of the omission being spread across the resolver where nothing would report it. 956 passed 2 skipped, ruff check 0, ruff format 0.	2026-08-23 01:36:32 +02:00
timothy	424ffb573b	fix(807): remove the collision class instead of asserting it away ... Round 7 reviewed the assertion added two commits ago and found it covered 1 of the 5 nodes where the collision fires — the four it missed being the ones that matter, since they are where the walk actually qualifies a name. I had already widened it to walk the whole tree, but the reviewer's recommendation is better than either version and is taken here: restructure so there is nothing to assert. A nested inline object lives in its OWN namespace. The defect was qualifying its members as `parent.child` BEFORE subtracting `required`, which merges the two namespaces and lets a literal `a.b` member mask a nested `a` -> `b` one. Now `_optional_of` subtracts inside each namespace and qualifies only the survivors, so the sets are never mixed. No separator to defend, no assumption to assert, and `NESTED_SEPARATOR` and its whole-tree checker are gone. Verified at all five sites — top level of a named schema, one level down, inside an `allOf` arm, under `items`, and inside an inline request body — every one now surfaces (`a.b`, `outer.a.b`, `a.b`, `a.b`, `a.b`); four were masked before. The reviewer flagged a trap in this fix and it is real: keeping a 2-tuple compatibility shim (`return properties | nested, required`) re-creates the mask at the merge boundary while the suite stays green. So `_resolve` returns three sets and every caller changed. There is now a case that reddens exactly that shim. Residual, stated rather than hidden: a literal `a.b` and a nested `a` -> `b` that are BOTH optional conflate into one reported string. That is a diagnostic ambiguity, not a miss — the schema still enters the population and still forces a disposition. Also from round 7: `prefixItems` was the one keyword whose `required` handling no case pinned (its only case carried none), so discarding it stayed green; it has a case now. And the assumptions docstring is back to describing two assertions rather than three, which the separator removal resolved on its own. REBASED onto ad31a0285 (#825). That change edits the same guard-inventory summary line this branch does, and the merged truth is neither side's number: 38 guards / 20 proof files / 16 with a mutation proof. Resolved by reading it off `test_the_summary_counts_match_the_table` rather than by picking a side. One local trap worth recording: a stale `scripts/**/__pycache__` made pytest report this commit's new case failing while the source could not produce that result — `_optional_of` returned the right value when called directly. Clearing the cache resolved it. I nearly "fixed" correct code on the strength of a red. 946 passed 2 skipped on the new base, ruff check 0, ruff format 0, typecheck 0, eslint 0, 1200/1200 web, build 0, catalog clean, doc-narrative 0 new.	2026-08-23 01:36:32 +02:00
timothy	161c788a70	fix(807): the collision check did not walk the tree it was checking ... Third round of the same shape in three consecutive commits, and the cleanest statement of it yet. The assertion added one commit ago — no property name may contain the separator — iterated only the top-level `properties` of each named component schema. The resolver it protects walks the WHOLE tree. So the two disagreed exactly where it matters: a dotted name on a nested inline object, or inside an inline request body, was undetected, and those are precisely the places the resolver qualifies a name and can therefore collide. A guard for a hole, with the same hole. `_property_names_containing_the_separator` now recurses over the parsed document the way `_schema_refs` does. Witnessed across five shapes — top-level on a named schema, a nested inline object, an `allOf` arm, under `items`, and inside an inline request body — all detected; the middle three were not, before. The transferable rule, which this issue has now paid for three times in a row: a check must walk the SAME tree as the thing it checks. Not a similar tree, not the obvious subset — the same one. Each of these three defects was introduced by the commit fixing the previous one, so the pattern is not carelessness about the subject, it is that a fix written to close one shape gets tested against that shape only. 908 passed 2 skipped, ruff check 0, ruff format 0.	2026-08-23 01:36:32 +02:00
timothy	021f3a4bb9	fix(807): the dotted path I just added could MASK a nested member ... Self-attack on the previous commit's new code, in the function every round has found defective — including, twice now, in the block that fixed the last defect. Qualifying a nested inline object's members as `parent.child` assumes no property name contains a dot. JSON permits one. Measured: a schema with a literal `a.b` member alongside a nested `a` -> `b` collides, and when the literal is `required` the nested optional member is MASKED — it vanishes from the population entirely. Silent-miss direction again, introduced by the fix for a silent miss. Zero dotted property names in the document today, which is exactly the reasoning that has been wrong five times on this issue, so the assumption is asserted rather than relied on. The separator is a named constant, the assumptions test now carries a third clause, and the failure message says what to change instead of only reporting that a fact moved. Witnessed: planting a schema with an `a.b` member fires it. 908 passed 2 skipped, ruff format 0.	2026-08-23 01:36:32 +02:00
timothy	4d7fd26a3e	fix(807): then/else are ALTERNATIVES — stop unioning their required ... Round 6 returned BLOCKED on a polarity error I committed in the block that fixed the previous polarity error. `then` and `else` were in the conjunctive list with `allOf`, so their `required` unioned. They are MUTUALLY EXCLUSIVE: a member required only under `then` is omittable whenever `if` does not match. The guard reported it as required — the silent-miss direction, which is the one this file exists to catch. Twelve lines below the defect the same function warns, about `oneOf`, that getting exactly this backwards "is not a detail". The comment made it worse, not better: it asserted the semantics had been considered, which is what stops the next reader checking. Its reasoning was right for properties (union them — a client may send them) and silently inverted for `required`. `if`, `then`, `else` and `dependentSchemas` now share one loop with one rule: collect properties, discard `required`. They discard for three different reasons — a branch selector, a branch that may not be taken, a trigger key that may be absent — but the rule is identical, so one loop beats three arguments. Why fix a keyword the emitter has never produced: this head added `prefixItems` and `dependentSchemas` handling on the stated grounds that "it does not appear in today's document" has been wrong repeatedly here. That standard cannot apply to three keywords and not the fourth — and a wrongly-handled keyword is worse than an unhandled one, because it ships a comment claiming it was thought about. The real lesson is narrower than "handle more keywords": for EVERY keyword whose `required` is unioned or discarded, ship a case that puts a `required` under it. None of the 27 cases did, which is why both this and the unpinned `if` discard were invisible. Three such cases added. Also closes the last blind spot with a mechanism behind it: an inline object under `properties`. The generator recurses into it and emits `"b"?:`, so it is genuinely droppable; the resolver returned nothing. Now reported with a DOTTED path, so `logo.contentType` cannot be mistaken for a top-level `contentType` in a MISSING diagnostic. `patternProperties` is correctly unhandled (no fixed members, like `additionalProperties`) and now has a case saying so rather than being silently absent. The docstring now names the resolver's exact reach instead of gesturing at it, and the `$ref` skip in the inline walk is marked as belt-and-braces rather than reading as protective — deleting it changes no result. Population unchanged at 9, set equality holds. 33 resolver cases, 908 passed 2 skipped, ruff 0/0, typecheck 0, eslint 0, 1200/1200 web, build 0, catalog clean.	2026-08-23 01:36:32 +02:00
timothy	4ce590662a	docs(807): record what happens on a cyclic schema, measured both ways ... The resolver has no cycle guard and that is deliberate, but the reasoning was nowhere, so the next reader would either add a redundant guard or wonder. Measured 2026-08-23: - `_properties_and_required` raises `RecursionError` on a dict that contains itself by object identity. That input cannot come from `json.load` — JSON has no back-references — and the failure is a loud red rather than a silent wrong answer, so it needs no defence. - The cycle a real document CAN express is a mutual `$ref`. `_request_reachable` handles it: A -> B -> A resolves to {A, B} and terminates, because of its `seen` set. This resolver never follows `$ref` at all, which is what makes the first case the only one available. Stated where the recursion is, since "why is there no cycle guard here" is answerable only by knowing both halves.	2026-08-23 01:36:32 +02:00
timothy	aa24e57343	fix(807): the last unannotated item builder, and three more resolver blind spots ... Self-attack ahead of round 6, on the two things every round has found defective: the newest hand-written code, and the completeness of an enumeration. CONSTRUCTION SITES, enumerated rather than sampled. 15 wrappers now take `Complete<>`; walking each one's nested item type to its builder leaves exactly one unannotated — `DecosScreen.breakToRequest` / `toReplaceRequest`, feeding the `Complete<>`-annotated `replaceDeco`. Round 5 called this non-blocking because a declared return type is already a contextual position, so the phantom direction fires there. True, but the MISSING direction does not: a new optional member on `DecoBreakContentRequest` would have been droppable. Both annotated. RESOLVER, probed with constructed schemas rather than read. Three more shapes it could not see, all silent misses: items in the 3.0 TUPLE form (a list) -> nothing prefixItems (the 2020-12 spelling) -> nothing dependentSchemas -> nothing `isinstance(items, dict)` skipped the list form silently. All three are handled now; `dependentSchemas` gets the `if` treatment — properties collected because a client may send them, conditional `required` discarded because it binds only when the trigger key is present. Two shapes probed and confirmed already CORRECT, pinned so they stay that way: `additionalProperties` contributes no members (it describes values under arbitrary keys, not named members), and `not` cannot make a member required. `else` was already handled; it now has a case of its own rather than riding on `then`'s. Seven new parametrised cases, 27 in the file. Population unchanged at 9 with set equality — every one of these is a latent hole, not a live miss, which is the point: "it does not appear in today's document" is the reasoning that has been wrong five times on this issue. 902 passed 2 skipped (up from 895), ruff format 0, typecheck 0, eslint 0, 1200/1200 web, build 0.	2026-08-23 01:36:32 +02:00
timothy	d194091536	fix(807): close the phantom gap at two sites, pin every resolver branch, stop ... claiming coverage in prose Round 5 returned BLOCKED. Its blocker was a durable coverage claim the tree contradicted, and its other findings were the same class one layer down. F1, the blocker. The record said `Complete<T>` "is applied … at each construction site, which is what keeps the phantom direction alive." This PR annotated `replacePathReplacements` and `replaceRemoteLibraryPreferences` at the wrapper but left their construction sites as bare generic `.map` callbacks — the exact shape spa-conventions §4b rule 2 says is unchecked. Injecting `phantomFieldZZZ` into both literals typechecked CLEAN. Both sites are annotated now and both reject the phantom with TS2353. F2. Five mutations of the composition resolver left the whole file GREEN: dropping `anyOf` entirely, making the alternatives loop non-recursive, taking only the first arm's properties, ignoring top-level `required` when alternatives are present, and dropping `items` descent. Three of those are silent-miss direction — a droppable member the guard reports nothing about. The six existing cases pinned the `allOf` path and the `oneOf` intersection and nothing else, so the previous commit's "witnessed" claim covered one branch of five. All five now redden; fourteen parametrised cases instead of six. F3. "A new optional member anywhere in the request graph fails this test" was false in three constructed shapes. Two are now handled — an inline body that is an ARRAY of objects, and properties under `if`/`then` — and the third was a real collision: `_inline_body_members` keyed on verb+path with no media type, so a second `[Consumes]` on one action made the later body silently overwrite the earlier. Keyed by media type now. The universal is replaced in both copies by the actual boundary. `if` is treated as a condition, not a constraint: its properties are collected (a client may send them) and its `required` is discarded, because that `required` selects a branch rather than obliging anyone to send anything. F4/F5. The record characterised the annotated wrappers as "the ones reachable from a droppable schema, plus the six builders" — five fall outside both. And `oneOf` and `anyOf` were concatenated into one alternatives list, which intersects `required` ACROSS the two keywords; they are conjunctive with each other, so each intersects within itself and the results union. Safe-direction but wrong, and untested. The prose change is the one that matters. Five rounds, five blockers, every one a hand-written claim about a population. So the record no longer asserts present coverage at all: it states the RULE, says plainly that nothing enforces the second half (#820), and tells the reader to read the code rather than a summary. A set phrased in words rots exactly like a count — deleting the counts in an earlier commit while leaving the worded set was treating the symptom. 895 passed 2 skipped (up from 887), ruff format 0, ruff check 0, typecheck 0, eslint 0, 1200/1200 web, build 0, catalog clean.	2026-08-23 01:36:31 +02:00
timothy	3758cb9112	test(807): pin that the component walk and the inline walk COMPOSE ... `_properties_and_required` does not resolve `$ref`, so an `allOf` arm that is a `$ref` contributes nothing to the inline key. I flagged that as a suspected hole and it is not one: the referenced schema is a named component, so `_request_reachable` seeds on it (`_schema_refs` finds a `$ref` anywhere, arms included) and `_optional_members` walks it, and its optional members surface under their own key. Verified by construction — a probe schema behind a `$ref` arm reports `['probeOptional']` under `RefArmProbeSchema` while the sibling inline arm reports `['probeInline']`. Pinned as a test rather than left as a comment for two reasons. Resolving refs in this resolver as well is the obvious "fix" and would report the same member under two keys, which is worse than either. And a reader checking only one of the two walks would reasonably conclude the case is uncovered and go build that fix. 887 passed, 2 skipped. ruff format 0.	2026-08-23 01:36:31 +02:00
timothy	9445330cb6	fix(807): resolve schema composition recursively, and by its actual semantics ... Self-attack on the inline-body walk added one commit ago, before round 5 reported. Probing it with constructed schemas rather than reading it found two defects, and the second is the more serious: nested allOf inside allOf -> reported NO properties (one-level handling) oneOf, x required in ONE arm -> reported x as REQUIRED The second is backwards, not merely incomplete. `allOf` arms all apply, so their `required` sets union. `oneOf`/`anyOf` arms are ALTERNATIVES, so a member is genuinely required only when EVERY arm requires it — the sets intersect. Unioning them marks a member required because one arm requires it, which hides the arm that lets a client omit it. That is exactly the drop this guard exists to catch, so the resolver was capable of concealing its own subject matter. `_properties_and_required` now recurses and distinguishes conjunction from disjunction, and `_optional_members` uses it too, so named component schemas and inline bodies resolve composition identically instead of the named path silently keeping the old flat behaviour. Effect on today's document: none. Population stays 9, set equality holds. The document exercises exactly one composition shape (a two-arm `allOf` in the artwork upload body), which is precisely why every other branch was unexercised prose — a resolver whose correctness rested on a case the corpus does not contain. So the six probe cases are now parametrised tests, pinned against constructed schemas rather than against today's API. Witnessed: reverting the allOf recursion reddens the nested case. 886 passed, 2 skipped (up from 880), ruff format 0, ruff check 0, catalog clean.	2026-08-23 01:36:31 +02:00
timothy	5371b664e0	fix(807): cover inline request bodies; drop three unverifiable counts ... Round 4 returned BLOCKED. Its blocker is R2's failure mode repeated: a boundary drawn by hand, stated as a universal, missing a case already present in the document. The guard's docstring claimed "a new optional member ANYWHERE in the request graph" fails the test. It did not. `_optional_members` iterates `components.schemas` and `_request_reachable` seeds from `$ref`s, so a request body declared INLINE is invisible in both directions — and `POST /api/v1/artwork/uploads` declares one, whose `file` and `target` sit outside any `required` array and had no disposition. Planting a third optional member into that body left the guard GREEN. Rather than narrow the claim, `_inline_body_members` now walks inline bodies and keys them `"<VERB> <path> (inline body)"` — there is no schema name to use, which is precisely why the component walk could not see them. Composition arms are unioned, because this body splits its properties across `allOf` and would otherwise report none. The population goes 8 -> 9 and the uploads endpoint acquires a TRIGGER disposition. The planted-member proof now plants into the inline body too: deleting the inline branch reddens two tests, where before the branch could have been deleted wholesale with everything green — the same gap `oneOf` was in one round ago. Live impact of the hole was nil (`artwork.ts` builds that body as hand-rolled FormData, no generated type, create-not-replace), which is why it is worth fixing rather than shrugging at: it was invisible, not harmless. `createFFmpegProfile` was dispositioned COVERED while its wrapper was unannotated, contradicting the vocabulary's own words and spa-conventions §4b rule 1. Annotated; coverage no longer rests on the single `Draft` alias. Three hand-written counts removed rather than corrected. "The eleven schemas the six named builders target" is unverifiable — no natural cut reproduces eleven. "The ten construction sites" has no derived definition of a construction site and was already wrong once on this branch. And the record offered `rg 'Complete<' web/src/api` as a reproduction for "most wrappers do not carry it" — a command that counts the helper and its own test file and cannot produce the claim. A command that does not reproduce is worse than none: it reads as checked. NITs: inventory row moved into alphabetical position; the manifest `why` now says the rename fires BOTH directions, since `expect` names only the MISSING half; two over-120-char comment lines wrapped. Filed #822 for the `test_hook_fire_log` race surfaced while running the suite — its oracle is the shared production hook-fire directory, so any concurrent session reddens it with a message that blames the suite. Verification: ruff format 0, ruff check 0, 880 passed 2 skipped, typecheck 0, eslint 0, 1200/1200 web tests, build 0, catalog clean, doc-narrative 0 new. refs #822 Decisions-Edit: yes	2026-08-23 01:36:31 +02:00
timothy	c31c3cc556	fix(807): ruff format, and re-pin case 4 to a member that discriminates ... Round 3 returned BLOCKED on a CI-red I would have shipped. BLOCKER — `ruff format --check` reds on the new guard file. Two implicitly concatenated strings fit in 120 chars when joined. `ruff check` was green, which is why this survived; the format step is a separate gate and the merge gate reads COMBINED status, so an advisory-looking red still blocks. The real defect is that ruff was absent from my local gate for six commits while I was reporting "verification: ..." lines that read as complete. Both ruff steps are now run, in the CI's own `git ls-files` form under `bash -c` (zsh has no `mapfile`). FALSE NEGATIVE, third of its kind on this branch — the guard's own comment said "No real request type here can discriminate today, because none has an optional member". That was false when written, and this PR's own derived guard lists eight schemas that contradict it. It also cost the proof its most valuable case. Case 4 is re-pinned from `ReplaceDecoTemplateRequest.name` (already REQUIRED, so it errored with or without `Complete<T>`) to `MultiCollectionItemRequest.weight`, which is genuinely optional and is the exact field whose loss was live before #807. Measured: case 4 now reddens under ALL THREE weakenings including the realistic `{ [K in keyof T]: T[K] }`, where before it reddened only under `Partial<T>`. The table is updated to what was measured, and the file now says that the set of schemas with optional members is DERIVED and must not be restated in prose — three hand-written versions of that list have now been wrong. STALE AFTER THE VERB WIDENING — the MISSING diagnostic still told the reader "reachable from a POST/PUT/PATCH body" one commit after the walk started seeding from every verb, so it could name a DELETE-reached schema while misdescribing where it came from; `expect` matched the tail of the message, so no test caught it. Same sentence fixed in the decision record. `oneOf` COVERAGE WAS CLAIMED, NOT HELD — `_schema_refs` has a dict branch and a list branch, and only the dict one was exercised: deleting list descent (making all 23 `oneOf` refs invisible) left the file GREEN. The planted fixture now goes in through a `oneOf` list, and deleting that branch reddens it. Also: deterministic host selection in the mutation test (set iteration over strings varies per process, so the proof's depth varied run to run); the `#/components/` bucket regex no longer assumes alphabetic bucket names; the hand-maintained "thirteen of thirty-three wrappers" count is replaced by its reproduction command; the record now reconciles its own pin-vs-floor argument against this guard's floors; 141 -> 142; generator path corrected to `web/scripts/`. Verification: ruff format 0, ruff check 0, 880 passed 2 skipped, typecheck 0, eslint 0, 1200/1200 web tests, build 0, catalog clean, doc-narrative 0 new (9 pre-existing warnings, none in files this branch touches). Decisions-Edit: yes	2026-08-23 01:36:31 +02:00
timothy	f878831e8f	test(807): assert the two document properties the walk silently depends on ... `testing.guard-derives-population-from-source`: when a guard's scope mirrors an authoritative source, the mirror needs its own check or it goes stale silently. `_request_reachable` mirrors two properties of the OpenAPI document, both true today and guaranteed by nothing: 1. Request bodies are declared inline on the operation. If ASP.NET emits a `components.requestBodies` bucket and operations `$ref` into it, the seed walk finds no `#/components/schemas/` name at all and every schema behind that shared body drops out of the population — silently, with the guard still green. 2. Every `$ref` points into `#/components/schemas/`. `_schema_refs` matches that prefix, so a ref into any other bucket is invisible to it. Both are now asserted, with a failure message that says what to fix rather than just that a fact changed. Neither was asserted anywhere else, so a change in the emitter would have shrunk this guard's reach without failing anything — the "complete within a scope that has silently gone stale" case. 880 passed, 2 skipped.	2026-08-23 01:36:31 +02:00
timothy	eff4bdfa22	test(807): state what the anti-vacuity floors do NOT catch ... Probed the new guard against a partially-broken derivation rather than only the total-failure case the floors were written for: deleting the transitive step from `_request_reachable`, so only schemas named directly on a request body resolve. Both floors stay satisfied and `test_the_derivation_reached_a_real_population` stays GREEN. What reddens is the planted-member test — its plant is reached through a nested `$ref` exactly so that it can — and the disposition test, since the nested rows vanish and report as PHANTOM. So the floors are the crude backstop against a parse that reached nothing at all, and the planted-member test is what actually holds the walk honest. Recorded in the docstring, because a floor described as anti-vacuity reads as coverage it does not have, and the next reader deciding which of these to keep working should know which one is load-bearing.	2026-08-23 01:36:31 +02:00
timothy	35e5d42ad2	fix(807): drop the verb allow-list from the derivation ... Self-review of the new guard, before round 3 reported: `_request_reachable` seeded its walk from POST/PUT/PATCH request bodies only. That reads as obviously right and already had a counterexample in the document — `DELETE /api/v1/media-items` carries a request body. A DELETE body probably cannot cause a full-replace drop. "Probably" is what produced both of this issue's earlier misses, and a verb allow-list is another hand-drawn edge on a population that has now been drawn wrongly twice. Every operation carrying a request body now seeds the walk, so anything it surfaces must acquire a stated disposition rather than being argued away in advance. Effect measured: reachable schemas 141 -> 142, droppable set unchanged at 8, set equality against the registry still holds. So this buys no new rows today; it removes a place to be wrong later. Also states in the docstring why the walk is transitive and why `_schema_refs` recurses over every dict value and list element rather than naming composition keywords — `oneOf` appears 23 times in the document today, and naming keywords is the same frozen-filter mistake one level down. 879 passed, 2 skipped.	2026-08-23 01:36:31 +02:00
timothy	685926a0d0	fix(807): derive the coverage boundary instead of writing it down a third time ... Round 2 returned BLOCKED. The enumeration added in the previous commit was itself incomplete: it omitted `ArtworkContentTypeModel`, which carries three members outside its `required` array and is reachable from the full-replace `PUT /channels/{id}` via `UpdateChannelRequest.logo`. It was sorted out on its name — `...Model` reads as a response model — which is the same failure the enumeration was written to eliminate one level up, and it closed with a false universal negative ("the remaining schemas ... are never request bodies") sixty lines below this document's own warning against exactly that. Two misses from one mechanism, so the mechanism goes rather than the list getting a third patch. `scripts/tests/test_optional_request_members.py` derives the population every run from `ErsatzTV/wwwroot/openapi/v1.json`: every schema with a property outside `required` that is TRANSITIVELY reachable from a POST/PUT/PATCH request body, asserted set-equal in both directions against a registry of per-schema dispositions. Transitivity is load-bearing — `MultiCollectionItemRequest` and `ArtworkContentTypeModel` are both nested, so a top-level-only check would have reproduced both misses. Population derived, dispositions hand-written as the reviewed SCOPE, per testing.guard-derives-population-from-source. Witnessed red: removing the `ArtworkContentTypeModel` disposition reports it as MISSING with its three members. That mutation is DECLARED in `mutation_manifest.py` and re-applied every suite, so the row grades MUTATION rather than resting on this message. Renaming the key rather than deleting the entry keeps the module importable, so the red is the MISSING direction and not an ImportError reddening for the wrong reason. ArtworkContentTypeModel's real disposition is COMPUTED, not COVERED: the three members are get-only properties derived from `Path` and are never deserialized, so omitting them drops nothing — and `Complete<T>` must NOT be applied there, because it would force a caller to fabricate server-computed values in an outbound request. That caveat is now in spa-conventions §4b, where a reader following "annotate each construction site" would otherwise have produced a wrong payload. Also reconciles the contradiction round 2 found between the wrapper-boundary rationale and the snapshot: 13 of ~33 full-replace PUT wrappers carry `Complete<>` today. The rest are stated as still contingent — the difference from before is that the contingency is now MONITORED by the derived test rather than assumed. L5 the phantom denominator is ten sites, not nine (five accepted, three of those without a spread or a local). N6 fixture field placed alphabetically. N7 the record's three-act framing trimmed to the current statement plus the rejected one, so a cold reader does not have to work out which is live. Verification: 879 passed 2 skipped in scripts/tests (up from 874), typecheck 0, eslint 0, 1200/1200 web tests, web build 0, catalog check clean, doc-narrative 0. Decisions-Edit: yes	2026-08-23 01:36:31 +02:00
timothy	8c72a5de9e	docs(772): correct the twins of two claims this branch already fixed ... Both remaining review findings were the same shape as the one before them, and it is the shape this repo keeps recording: a claim corrected in one place, its copy left standing somewhere else in the tree. * `docs/ci-cd.md` said "gates nothing" in the small-lane paragraph while the section 1441 lines below said the opposite. A red preflight lands in the PR's combined status, which the merge gate reads (#598) — what it does not do is SKIP the jobs it diagnoses, and that is now the sentence in both places. * Two docstrings in the preflight's test file still described the disarmed script as warning and exiting 0. Built the mutant and ran it: it emits an error and exits 1. The exit code separates nothing now that an unverifiable answer fails too — the DIAGNOSTIC is what the mutation destroys, which is what `mutation_manifest.py` already said and the prose next to it contradicted. Nits from the same pass: the admin-cron URL is quoted (`?` globs in zsh, the operator's shell); the retry assertion's message quoted a threshold it does not use; the arm table omitted the malformed-credential shape the code and tests both have; `buildx inspect` no longer `--bootstrap`s a builder just to read its name, and an empty capture no longer produces a noisy `buildx use ""`. Swept the tree for the shape rather than the two reported lines: the surviving "exits 0" and "could-not-tell" hits are other subsystems, or the concept named as a concept. refs #772	2026-08-23 00:23:44 +02:00
timothy	30640bb780	fix(772,792): close the fix-round review — the doc still described the semantics the fix reversed ... The re-review's one HIGH was mine and was the obvious one to miss: the previous commit changed the preflight so an unverifiable answer FAILS, and left a `docs/ci-cd.md` paragraph two screens away still saying "anything else is reported as could-not-tell". That paragraph is the one an operator reads when the job goes red, and it would have talked them into reinstating the defect. Replaced with the full arm table, including the two rows the first draft got wrong and why. * "gates nothing" was false in the way this repo has recorded before (#598): the merge-consent hook reads the COMBINED status, so a red preflight blocks the merge like any other red job. It does not SKIP the jobs it diagnoses; that is the accurate claim, in ci-cd.md and in the remote-state row. * The production retry defaults were evaluated by nothing — every test overrode both knobs. A test now drops the overrides and measures three attempts and a real pause, so editing the default to 1/0 (which would falsify the "a blip does not redden a PR" argument) goes red. * `journalctl -u gitea | grep ExecuteCleanupRules` is not a reproduction: that identifier reaches the log only through slow-query warnings, so an empty grep on a healthy host reads as "the rule never ran" — the inverse. Replaced with the admin cron API, which answers deterministically. * The recovery recipe's `docker buildx use default` needs the containerd image store to `--push` (both named hosts have it, checked today) and mutated the operator's builder selection without restoring it. * The stub's comment claimed both halves of real curl's transport failure mattered; only the exit status is observable, because `|| resp=""` discards what curl printed. * The empty-half credential refusal echoed the username; it needs no value at all. The 401/403 arm aborts the remaining pins while 404 continues — deliberate, now stated. * `curl -u "$VAR"` puts a credential in argv, and this job runs container-free on a shared host. NOT fixed here: it is the shape all five `scripts/` callers already use, so fixing one site leaves the class and splits the codebase. Filed as #821 and named at the site. refs #772 refs #792	2026-08-22 23:48:20 +02:00
timothy	0cf355e494	fix(772,792): address both cold reviews — an unverified pin is no longer a green job ... Two independent reviewers (one cross-family) converged on the same defect, and it was the important one: the preflight WARNED and exited 0 on every answer that was not 200 or 404, so a missing `curl`, a moved registry or a DNS change would have left it green forever — "the check could not run" presenting as "the pin is fine", in a script whose own header disclaimed exactly that. Unknown answers are now retried (3x, 5s) and then FAIL, with wording kept distinct from the deleted case because the two send an operator to different places. Also from the reviews: * An absent secret does not arrive as an unset variable. `${{ secrets.X }}:${{ secrets.Y }}` interpolates to ":", a perfectly non-empty and perfectly useless credential, and the tests covered only the unset shape. Both halves are now required, and the parametrised test drives the production shape. * HTTP 200 is not a manifest. A proxy or a login page answers 200 too, so the body is fetched and matched for `schemaVersion` (a shell `case`, so no jq dependency and no pipeline that can inject). * The curl stub ignored `-u` and answered 200 regardless, so deleting the real `-u` would have left the suite green while the live registry rejected every request. It now 401s an unauthenticated read, as the registry does. * The mutation's declared diagnostic changed with the script: now that unknown fails too, the exit code no longer separates "deleted" from "could not check", so the proof turns on the message and `expect` says so. * docs/ci-cd.md: `scan` is no longer the only `docker-build.yml` job on the small lane, so the tag-push exclusivity claim and the lane membership were both false. Fixed. * "Immutable" was overstated: `ci-image.yml` tags `rev-parse --short HEAD`, so a dispatch or a weekly no-cache run at the same HEAD republishes that tag from a rebuilt image. Stated, along with what the rebuild recovery does NOT restore (mutable bases and apt, so equivalent rather than bit-identical). * The recovery recipe left you in a worktree checked out at the pin commit — where the verify script does not exist, and where the workflow carries the pre-bump pin. It now keeps `$repo`, returns, and removes the worktree. It also needed BuildKit's `http = true` caveat: the container driver does not inherit the daemon's insecure-registries. * The root cause carries its evidentiary limit and its reproduction commands, and says what to conclude if a pin vanishes after server-management#842 lands (refuted, not re-applied). * The `ci.required-job-step-execution-markers` carve-out named one container-free job; there are two now, and the membership is what rots. * The decision record's `''` YAML escapes leaked into rendered prose; "status, no comment -> ask" is qualified (a prior positive verdict for the SAME head still satisfies condition (c)); "exits 1" is "exits non-zero" (usage exits 2, jq its own status, signals 128+n). refs #772 refs #792 Decisions-Edit: yes	2026-08-22 23:25:26 +02:00
timothy	5ba442c11c	fix(772,792): name the missing toolchain image, and stop a refusal leaving a verdict comment ... #772 — the pinned CI toolchain image can be deleted out from under us, and when it was (2026-08-11..13) all five `container:` jobs died at image pull, both required contexts included, with the cause buried in each job's log. Root cause is registry-side and is now established rather than guessed: an owner-level Gitea package cleanup rule (keep_count 15, remove_days 1, remove_pattern `.*`, keep_pattern no 7-hex sha can match) deletes a sha tag once 15 newer versions exist, and `ExecuteCleanupRules` ran nightly through the window. The `ersatztv` package carries the same rule's fingerprint exactly — every sha tag older than the 15-slot window is gone, every keep_pattern tag back to 26.3.1 survives. Version deletes leave no audit row, so the specific run cannot be replayed; that limit is stated where the claim is made. The durable fix belongs to the registry's repo: server-management#842. What lands here is what a consumer of someone else's registry can do: * `toolchain-preflight`, a container-free job (a job consuming the image could not run to report it missing) resolving every pin against the registry and failing with a message that names the tag and the recovery. Not a `needs:` of the jobs it diagnoses — gating five jobs behind a checkout and one curl taxes every green run to speed up a rare red one, and they already fail fast. * Only HTTP 404 means gone. Everything else is could-not-tell, and rejected credentials fail rather than pass as unknown — "the check could not run" must never present as "the pin is fine". * A recovery path that does not need CI: rebuild the SAME tag from the commit it names and push it. The push half was verified against this registry on 2026-08-22 with a throwaway package (created, resolved 200, deleted). #792 — the reported defect was the exit code, and re-measuring says that premise is false: every no-status path already exits 1, and eight refusal modes now assert it against the real predecessor, where they pass. The observed 0 came from the invocation, not the script. What WAS broken is the half-state the issue describes second: the comment was written before the status, so every refusal left `Review-verdict: MERGEABLE @ <head>` on a PR with no gating status behind it. The two writes are now ordered status-then-comment, which makes the only reachable half-state the safe one — a status with no comment leaves the merge hook's condition (c) with nothing to classify, which is an `ask`. The refusals themselves are untouched. Ordering rather than compensating deletion: an orphaned-comment cleanup needs a Gitea call, and these refusals are usually caused by Gitea being unreachable. Proof for the ordering is the split against origin/main's script: the 8 orphan/ordering tests go red there, the 8 exit-code tests stay green. fixes #772 fixes #792 Refs: server-management#842 Decisions-Edit: yes	2026-08-22 22:52:56 +02:00
timothy	29d7a06e65	fix(806): guard populations over FILES derive from the git index, not a filesystem walk (#818) ... `testing.guard-derives-population-from-source` (#774) was silent on the commonest population in our own guards — files in a directory — and every one answered with a filesystem walk. A walk is not authoritative: it reports build output, generated shims and editor droppings, and differs per machine. #778 measured the cost by getting the same population wrong three times in one PR. CONVERTED (a completeness claim over tracked files): `test_guard_inventory.py`, `test_hook_fire_log.py`, `test_ci_image_pin_population.py` (which also gained `*.yaml`), `test_remote_state_inventory.py` (folded onto the shared derivation), and `test_pr_changed_files.py` (not on the issue's list — found by sweeping the whole repo). ASSESSED AND RECORDED, not silently skipped: `_repo_copy` takes its file list from the index for hermeticity though it makes no completeness claim; `test_ci_dropped_step_guard.py` has no filesystem population at all; the decisions corpus is recorded as unexamined rather than cleared; and the SPA page-size guard is deferred to #819 with its obstacle documented. This is not "replace every glob". `scripts/tests/tracked_files.py` is the single derivation. `test_guard_populations_derive_from_git.py` proves it in two measured complements: exhaustive removal catches a hardcoded `.exists()` admit and memoisation; the call log catches an append-only source that yields nothing on this machine — #778's shape — which removal cannot see because it has nothing to remove. Twelve rounds of independent cold review, alternating model families in isolated worktrees. The production derivations were confirmed sound every round; every blocking finding after the first was in the proofs or in prose claims about them. Counts over growing populations were removed rather than corrected, after three drifted. fixes #806 Co-authored-by: Timothy <timothy@noreply.gitea.tblindustries.be>	2026-08-22 16:07:58 +00:00
timothyandClaude Opus 5	3b386649bf	feat(790): execute every MUTATION grade instead of asserting it (#815) ... Every `MUTATION` row of `docs/guard-inventory.md` now carries a DECLARED clause mutation that is applied to an isolated copy of the repository on every suite run, with the row's own named test required to go red carrying a declared diagnostic. Manifest and MUTATION rows are compared for set equality both directions; the other 22 guards each carry a stated reason, compared the same way. Measured rather than assumed: 12 of 13 guards admit a single-clause mutation; `instrumentation_faults` does not, and that entry carries the surviving finer mutation, re-run every suite. Nine cold cross-family review rounds. Rounds 1, 2, 7 and 8 each found real mechanism defects — two mutations that measured nothing, an incomplete git-environment sanitisation, a reset that restored its own mutant, and a proof of that fix which was not itself isolated. All fixed and witnessed red. fixes #790 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Timothy <timothy@noreply.gitea.tblindustries.be>	2026-08-22 13:12:15 +00:00
timothy	eb5c74b4b2	fix(780): reconcile the ruff gate with #784, merged in parallel (#814) ... #780 and #784 were green separately and red together: the gate landed on a base that predated scripts/check-doc-narrative.py, so nothing ever ran ruff over it. - RUF100 x2 on `# noqa: BLE001` — BLE is not in this repo's select, so those directives suppress nothing. Enabling BLE instead was measured and rejected: 6 further sites in decisions_validate.py, whose broad catches are deliberate. The non-enabled code is dropped; S110 and both comments stay. - scripts/tests/test_check_doc_narrative.py was not ruff-formatted. Verified with the shipped invocation: 35 files, all checks passed, all formatted; suite 807 passed / 2 skipped. refs #780, refs #784 Co-authored-by: Timothy <timothy@noreply.gitea.tblindustries.be>	2026-08-22 09:34:03 +00:00
timothy	d4c72697f2	feat(780): commit a ruff config and enforce it in CI (#813) ... Python lint here was a property of the operator's laptop: the global instructions say to run ruff, no workflow ran it, and with no committed config ruff fell back to whichever ~/.config/ruff/ruff.toml the machine happened to have. - ruff.toml at the root, pinned ruff==0.12.11 in the script-tests job. - Both lint steps pass an EXPLICIT population from `git ls-files` with `--no-force-exclude`, never `ruff check .` — an `exclude` empties a discovery-based run into a GREEN one (top level empties both commands, [lint] empties check, [format] empties format --check), and `ruff check .` over zero files exits 0 with only a stderr warning. Guarded by an empty-population arm. - Tree clean: 74 findings at 706674272, 57 fixed in code, 17 per-site noqa with reasons inline. S105 deliberately per-site, not a directory blanket. RUF100 selected so a suppression that suppresses nothing is itself a finding. - pyright stays ungated; reasoning in the record. Both steps witnessed red on the runner against the shipped bodies: run 2173 job 9176 (ruff check) and run 2170 job 9163 (ruff format --check). Docs: new record ci.python-lint-ruff-config-committed, ci.script-tests-job cross-ref, docs/ci-cd.md (also correcting a stale ~190-tests/~10s figure to the measured 773 tests / ~4.5 min), docs/defect-shapes-773.md §5.2 resolved. fixes #780 Co-authored-by: Timothy <timothy@noreply.gitea.tblindustries.be>	2026-08-22 00:33:18 +00:00
timothy	6a4265d81d	feat(784): a doc records the end state — generalize the no-session-narrative rule (#811) ... Co-authored-by: Timothy <timothy@noreply.gitea.tblindustries.be>	2026-08-22 00:23:22 +00:00
timothyandClaude Opus 5	706674272c	test(785): mutation proofs for the three unproven ranked guards (#810) ... Closes the remaining three entries on #785's ranked list with clause-level mutation proofs, each witnessed red against the real subject in place: * the `pretooluse-worktree-guard.sh` + `posttooluse-worktree-marker.sh` PAIR — four clauses, including the cross-file seam (a clause in the marker hook, asserted against the guard's decision) that could not exist while the halves were tested apart; * `.husky/pre-push:11`'s `unset GIT_DIR GIT_WORK_TREE GIT_INDEX_FILE` — git exports `GIT_DIR` to `pre-push` only from a worktree, which `process.shared-tree-readonly` makes the mandated way to work here, so the guarded case is the normal one; * `scripts/build_decisions_catalog.py --check` — including the `__main__` wiring, which can print "is stale" on stderr and still exit 0. Nine ways the catalog guard can stop gating are detected, judged by executing the step's whole `run` script rather than by matching lines out of it. Two channels are undecidable outside the runner and are stated as uncovered rather than guessed at. Inventory regraded to 12 MUTATION / 6 BEHAVIOUR-ONLY / 16 NONE, with a stated reason for every remaining NONE row, verified member-for-member against the derived set. Five cold review rounds; findings closed include production-hook-fire-log corruption, a tautological assertion, a guard asserting on its helper rather than on the effect, and two false greens in the workflow extractor. Follow-up: #809. fixes #785 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Timothy <timothy@noreply.gitea.tblindustries.be>	2026-08-21 20:10:01 +00:00
timothyandClaude Opus 5	7347a08979	fix(778): the 200-not-an-array arm had the same lying reason, one branch earlier ... Local review returned MERGEABLE — no Blocker, High or Medium, both sentinels verified pinned by mutation, no regressions. Its one Low is taken rather than deferred, because it is a one-line fix and because deferring it would leave exactly the shape this PR exists to document. A 200 whose body is NOT an array never reaches the classifier: the array gate diverts it, `bp_code` stays 200, and the generic ask then reported "HTTP '200' — Gitea unreachable, or these credentials lack the repo-admin scope" about a read that plainly succeeded. That is the identical defect the previous commit fixed for the throw-inside-the-classifier arm, one branch earlier — fixed where it was noticed, left in its twin. The previous commit's message even generalised the pattern ("a sentinel that doubles as an HTTP code makes a decision state a cause that did not happen") while covering only one of the two arms it applies to. The test is now parametrised over all three shapes that reach an unusable 200 — UNPARSEABLE-RULES, GARBAGE, EMPTY — and reverting the new sentinel reddens the two that the first fix missed. Also finishes the de-indent the previous commit claimed: that comment block went from 19 leading spaces to 6 while its siblings use 2, so the claim was true of the direction and not of the result. 729 tests green. refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 22:50:23 +02:00
timothyandClaude Opus 5	3f0af38509	fix(778): pin the nomatch sentinel — it shipped unpinned, exactly like the guard before it ... Local review of the previous commit returned BLOCKED. Both findings taken; nothing pushed to CI while this was iterating. MEDIUM — the `nomatch` fix was entirely unpinned. Reverting both sites to `bp_code=404` left the suite 33/33 green, because no fixture ever emitted an HTTP 404 on the LIST read: the codes exercised were 000, 403, 500 and 200, and the old `NOT-FOUND` mode had been repurposed to return 200 with `[]`. So the defect that commit describes could be reintroduced silently — in a PR whose subject is unfalsifiable guards, one round after being blocked for precisely that shape. There is now a `LIST-404` fixture and a test; reverting the sentinel reddens two tests. The same class, one arm over and found while fixing it: a 200 whose `branch_name` is a number makes the classifier throw (`//` fires only on null/false), and that was mapped to `bp_code=000`, reporting "HTTP '000' — Gitea unreachable" about a read that plainly succeeded. It gets its own `unreadable-rules` sentinel and message, with a fixture and a test — reverting it reddens. The pattern across both: a sentinel that doubles as an HTTP code makes a decision state a cause that did not happen. The decision was safe each time; only the reason lied. MEDIUM — four comments still described 404-as-a-finding as live, contradicting the hook comment added in the same commit. The worst said a 404 means "this branch is entirely unprotected" in a test whose fixture now returns 200 with `[]`, which would have talked the next reader into re-adding the deny. Renamed that mode `EMPTY-LIST` so it says what it is. Also: the hook quoted a reason string it no longer emits; a stray over-indented line survived the de-indent; `bp_called` was write-only after its reader was removed. 727 tests green. refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 22:09:16 +02:00
timothyandClaude Opus 5	7d81f85b38	fix(778): make the by-name pin falsifiable — it was filtering on the property it asserted ... Confirmation pass returned BLOCKED, and its lead finding is the one worth having. The test forbidding the by-name lookup recorded URLs from INSIDE the `endswith("/branch_protections")` branch, so the only URLs it could ever record were ones that already satisfied the assertion. A by-name request was invisible to the very test written to forbid it. Cold review proved it by reintroducing the lookup in the hook: the suite stayed 33/33 green. That is the filter-on-the-asserted-property defect this PR's sibling record exists to describe, committed inside the guard against it — and the commit message had called the twin "pinned so it cannot come back". The recorder now sees every branch-protection URL whatever its shape. Re-verified by the same mutation: reintroducing a by-name call reddens exactly the two tests that forbid it. Also from that pass: - an HTTP 404 on the LIST read reached the "the full rule list was read and none matches" deny — a claim about a read that never happened. Gitea answers 404 for a repo that is absent or invisible to the credential, so the classifier's own verdict is now the sentinel `nomatch` and HTTP failures reach the ask; - two comment blocks still described the deleted by-name endpoint as live, one of them asserting the classifier "is never reached at all"; - the decision record still documented `branch_protections/{base}` and its 404 semantics as the mechanism, in the record this PR authored — now rewritten to the list endpoint, with why reading the LIST is the load-bearing choice; - seven assertions on a string the hook no longer emits, and three test names/docstrings describing the removed 404 flow; - an unused fixture helper, and 79 lines left over-indented by the removed nesting. 724 tests green. refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 21:29:09 +02:00
timothyandClaude Opus 5	f3863c3720	fix(778): delete the by-name lookup — the precedence check was guarding the dead path ... Final review returned MERGEABLE with no Blocker and no High. Its one Medium is taken, and it is my own recurring trap for the third time in this PR: fix one path, then check its TWIN. The hook looked a rule up by NAME first and enumerated the rule list only on a 404. But `branch_protections/{name}` is an exact DB lookup — `GetProtectedBranchRuleByName` — which performs no matching and knows nothing about precedence. A 200 from it means "a rule with this NAME exists and lists this context", never "this context is required on this branch". So the precedence argument added last round guarded the 404 path while the 200 path granted without it — and since this repo's rule IS named `main`, the by-name lookup always returns 200. The hardened code was dead and the unhardened code was live. Given a rule `main` requiring review-verdict/h10 and a rule `m*` with better Priority that does not, Gitea applies `m*`; the by-name hit on `main` saw h10 and granted anyway. Fixed by DELETING the twin rather than documenting it: one fetch of the full list, one classifier, one argument, no second path to keep in step. Two things fall out for free — the ref no longer reaches a URL segment, so the percent-encoding hazard is removed by construction rather than escaped (its test is replaced by one asserting no ref reaches the URL at all), and every case the classifier already covered now applies to the live path instead of an unreachable one. Verified against the live Gitea: the classifier returns `exact` -> rule `main` -> enable_status_check=true, h10 present. A new test pins that the precedence check runs even when an exactly-named rule exists, and asserts the by-name endpoint is never requested, so the split cannot come back silently. The grant string now states what was actually established — read from the full rule list, matched with Gitea's own plain-vs-glob split, refusing wherever precedence or folding is not derivable — rather than the stronger "confirmed required" it claimed while consulting a single named rule. 724 tests green. refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 21:07:09 +02:00
timothyandClaude Opus 5	c7bea972d6	fix(778): close the last three residuals — ambiguous exact rules, non-ASCII folds, one unpinned test ... Confirmation review returned MERGEABLE at 356cddbb5, having independently re-executed every claim (the "2 -> 6 dead-classifier" figure exact, the "20 tests" trap figure exactly reproducible, the arm reorder pinned, live branch protection confirming the dated claim). Its three residuals are taken here. M1 — the backslash test hit the undecidable arm but asserted only `"ask" in reason`, which a CRASHED classifier also satisfies. Its two siblings got `"could govern it"` one commit earlier and this one did not. Under the dead-classifier mutation it was the single green test of that arm; now red. L1 — with two plain rules differing only in case, `first` picked LIST order while Gitea picks by Priority. Given `MAIN` requiring review-verdict/h10 and `main` not, the hook could inspect the rule that requires it and auto-grant on a base where Gitea enforces the other — the same defect as the arm order, one level down. Two fold-equal rules are now undecidable. L2 — the same standard, applied where I had waived it. The backslash paragraph rejects "nearly unreachable" as a standard for the arm that issues a DENY, and two paragraphs up the ASCII-only fold was accepted on exactly those grounds: rule `ünstable` and base `Ünstable` fold equal under Gitea's EqualFold and not under `ascii_downcase`, landing on `none` -> deny with a false stated cause. A non-ASCII rule name or base is now undecidable rather than fold-compared. The non-ASCII test is `explode | any(. > 127)`, not a `\uXXXX` regex: the first attempt was a character-class regex whose backslashes are ambiguous through a single-quoted shell string into jq, and a standalone probe showed it classifying plain `main` as non-ASCII. Codepoints have no escaping layer to get wrong. Both new arms are mutation-proven individually; an earlier attempt at those proofs used perl substitutions that silently matched nothing and reported green, which is why they were redone in python with an explicit assert on the target. refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 20:23:32 +02:00
timothyandClaude Opus 5	356cddbb59	fix(778): pin the arm order, and correct a wrong explanation I had just written ... Two self-found defects while pre-empting the confirmation round's own questions. THE REORDER WAS UNPINNED. Swapping the classifier arms back to exact-first left all 29 tests green, so the previous commit's central change was invisible to the suite — an unproven change shipping under a green run. The missing fixture is the one that distinguishes the orders: a list holding BOTH an exactly-named rule that requires `review-verdict/h10` AND a glob rule that could also govern the base and does not. Exact-first inspects the rule that requires h10 and auto-grants; undecidable-first asks. Now mutation-proven in both directions. I HAD MISDIAGNOSED THE TRAP, and asserted the wrong cause in a comment. A three-line repro disproves "an EXIT trap suppresses output" — it does not. The real mechanism is that this file already owns its EXIT trap: `scripts/hook-fire-log.sh` installs `trap 'etv_hook_fire_end "$?"' EXIT` (#776), and in capture mode that handler is what REPLAYS the decision JSON to stdout. A second `trap ... EXIT` silently replaces it, so the decision is captured and never emitted. The trap slot is a single shared resource and the sourced library claimed it first. That second one is the shape this whole PR is about, committed against my own work: an explanation that fits the symptom, is written down as fact, and is wrong. It would have told the next person the construct is unusable rather than that the slot is taken. refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 19:54:47 +02:00
timothyandClaude Opus 5	d8ff6fa229	fix(778): ask before trusting an exact rule, and make the tests tell classified from crashed ... Ninth cold review: MERGEABLE, no Blocker, no High. Its three Mediums taken anyway, because each was a one-line fix retiring the last "asserted rather than verified" surface in the file whose whole subject is that shape. M1 (backslash missing from the metacharacter class) was already closed in cd1b28637 — found independently while stress-testing the superset claim, in the window the reviewer was working against the previous head. M2 — the `exact` arm was not decidable. Gitea picks the governing rule with GetFirstMatched over a list sorted by Priority and THEN by plain-name-ness, so a glob rule with a better Priority outranks an exactly-named one. Preferring `exact` would inspect a rule Gitea might not be applying: if the exact rule requires `review-verdict/h10` and a higher-priority glob rule does not, the gate auto-grants on a base where the check is not enforced. `undecidable` is now evaluated FIRST, which makes the classifier sound without knowing the precedence rules at all — the only claim this code is entitled to make about somebody else's resolver. M3 — four tests could not distinguish "classified correctly" from "classifier crashed", because a dead classifier lands on the generic could-not-read ask and they asserted only `"ask" in reason`. Measured with the reviewer's method rather than argued: injecting `error(...)` at the head of the jq program left 2 of them red; the strengthened assertions leave 6. The glob arms now pin the text unique to the undecidable ask, and the decidable arms assert the rule was HONOURED rather than referred to a human. Also: the module docstring still described a three-arm contract after this change added a fourth; the inventory row still summarised the old two-way behaviour; the ASCII-only case fold is now stated as a deliberate under-match rather than as parity with EqualFold; the live-config claim is dated; and one jq call rejoined the file's `|| true` discipline. A `trap ... EXIT` for temp-file cleanup was tried and REVERTED: it suppressed the hook's decision output entirely and took 20 tests red. A gate that prints nothing is the one outcome it must never produce, so the tidier construct loses to the one that works, with the reason recorded where the next person will try it. refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 19:47:06 +02:00
timothyandClaude Opus 5	cd1b286378	fix(778): backslash is a metacharacter too, or the none arm's proof does not hold ... Self-found while stress-testing the superset claim I introduced one commit earlier — the crux the new classifier's safety rests on. `none` authorises a DENY on the stated grounds that nothing can possibly govern this base, so its premise must hold unconditionally, not usually. The superset was "literal prefix + .* + literal suffix", which is sound for every glob dialect EXCEPT one case: gobwas/glob reads `\{` as a LITERAL brace, so a rule `a\{b` governs the base `a{b`, while a superset treating `\` as an ordinary character builds `a\.*b`, misses, and denies a base that is in fact protected. Verified before and after: with `\` outside the metacharacter class the classifier answered `none` for that pair; with it inside, `undecidable` -> ask. 18 adversarial rule/base pairs (brace alternation, negated and ranged classes, `**`, leading and trailing metacharacters, unicode, empty alternation) all answer `undecidable`, never `none`, so no dialect-matching case falls through the deny arm. Git ref rules make this nearly unreachable — a branch name may not contain `*`, `?`, `[` or `\` — but `{` IS legal in one, and "nearly unreachable" is not the standard for the arm that issues a deny. Checked with `git check-ref-format` rather than assumed. refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 18:59:36 +02:00
timothyandClaude Opus 5	456042ee51	fix(778): stop claiming parity with Gitea's glob matcher — classify, or ask ... Eighth cold review: no Blocker, no High. Three Medium, two Low, one Nit. MEDIUM — the substantive one. The glob fallback asserted it matched rules "the same way Gitea applies them", and it does not. Gitea compiles a rule name with gobwas/glob and a `/` separator: its `*` does NOT cross a slash, `?`/`[…]`/`{a,b}` are wildcards, and a plain name is folded case-insensitively. Mine used `.*` for `*` and escaped the rest. The divergence has a false-OPEN direction — `release/*` does not govern `release/26/hotfix` in Gitea, but `release/.*` matched it here, which would auto-grant a scheduled merge on a base where the check is not required. That is #622's hole, reached through the block written to close it, via exactly the failure this PR records: a claim about an external system asserted rather than verified. Reimplementing somebody else's glob dialect would be a second copy of a parser, which this repo has already withdrawn a change for. So the classification is three-way and each arm is safe WITHOUT knowing the dialect: an exact non-glob name folded case-insensitively is decidable; a glob rule that could govern the base is UNDECIDABLE and asks; and "could" is tested with a provable superset of any glob dialect — literal prefix, `.*`, literal suffix — so if even that cannot match, no dialect can. Over-matching would grant on unestablished protection; under-matching would deny with a false cause. Asking is the only answer honest in both directions, and it is rare: this repo's rule is the plain name `main`. MEDIUM — a count that was wrong the moment it was written ("46 of the 69 rows are N/A"; it is 44). It was added by the same commit that demoted two rows. That is the FOURTH stale number in this change, in the deliverable whose own record argues against hand-maintained counts. Removed rather than corrected, with the reason stated. MEDIUM — `migration-smoke.sh` still said "Same shape" as `security-scan.sh`, whose note had just been rewritten to the opposite conclusion, so the backreference had silently inverted. It is the same pull-then-run over a mutable tag and deserves the grade MORE, not less: `security-scan.sh` boots a throwaway container and authorizes nothing, while this gates a production stack recreation. Regraded. LOW/NIT: an `end <= start` guard that `str.index(…, start)` makes unreachable by construction is replaced with the reachable failure it was describing; a docstring still named a fixture from an earlier draft; a reflowed `#707.` was line-initial. Two mutations were ineffective on the first attempt — one left the `decide ask` continuation in place, the other had no test covering case-folding. Both redone; each arm now reddens a named test. Decisions-Edit: yes refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 18:52:18 +02:00
timothyandClaude Opus 5	7db4101b24	fix(778): the escape emitted TWO backslashes, turning a false-open into a false DENY ... Seventh cold review. One High, one Medium, three Low, seven Nit — all in the two newest commits, which is where every round of this PR has found its defects. HIGH, and it is my own fix from the previous commit. In jq source `"\\\\"` decodes to TWO backslashes, so escaping produced `\\.` — "a literal backslash, then any character" — instead of an escaped dot. Every rule name containing a metacharacter became UNMATCHABLE, and a rule named `a[b` crashed jq outright (swallowed by `|| true`). Verified: `release/26.*` no longer matched base `release/26.4`, so the fallback found nothing and hard-DENIED with the stated cause "has NO branch protection at all" — converting a false-open into a false deny, which the block's own comment calls the worse outcome. One character: `"\\" + .c`. Correct across 14 rule/base pairs. WHY MY TEST MISSED IT, which is the transferable part: it asserted only the NEGATIVE direction (`mai.` must not match `main`). A rule matched literally and a rule made unmatchable both fail to match the wrong base, so the assertion passed for the wrong reason. Only a rule that SHOULD match separates them, and there was no positive control. There is now — plus a char-class case — and both go red against the over-escaped version. That also needed a base containing a dot: a rule cannot carry a metacharacter and still match `main`, so the first attempt at the positive control was unsatisfiable by construction. MEDIUM — four live claims that the population "derives from the filesystem", left standing by the commit that replaced that mechanism: the guard's own docstring 45 lines above a comment shouting the opposite, the inventory heading 21 lines under "Every git-tracked file", the docs/README entry, and — worst — the record's `mechanics:` frontmatter, which is the copy the catalog and MemPalace mirror, so discovery would have returned the superseded lesson. All corrected. LOW/NIT: the URL-encoding test grepped the source for `@uri` (it now asserts the URL actually requested, and reddens when the encoding is removed); the hoist comment said "every path below" without noting the docs-only enumeration above it (bounded — that path is a passthrough to a human prompt, never a grant); a now-unreachable guard is annotated rather than left reading as live; `issue-qualification-audit.sh` was `N/A` while `select-queue.sh` was `UNSAFE-KNOWN` on the same argument, and `security-scan.sh` claimed "one step" for a pull-then-run over a mutable tag — both regraded; the `PINNED` definition now says what separates its second shape from an `N/A` "one step" row (the identifier's immutability, not the step count); the section parser raises a message naming both required headings instead of a bare ValueError; and the record's body is rewrapped. Decisions-Edit: yes refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 18:21:04 +02:00
timothyandClaude Opus 5	01de6cbd8b	fix(778): * is the only wildcard — a rule name's regex metacharacters were live ... Found by attacking my own glob fallback from the previous commit before the reviewer got to it, which is the round where this PR's defects have landed every time. The 404 fallback matched a branch-protection rule by substituting `*` into a raw regex, leaving every other metacharacter active. Verified directly: a rule named `main.x` matched the base `mainax`, and `a+b` matched `aab`. The direction is the one that matters — a spurious match to some OTHER rule that happens to require `review-verdict/h10` reports this base as protected when nothing governs it, so a consent gate answers yes on evidence about a different branch. Each literal segment is now escaped before the pattern is assembled, so the wildcard survives and nothing else does. Verified across 11 rule/base pairs: metacharacters are literal, `*` still spans, exact and non-matches unaffected. The regression test needed two goes to stop being vacuous, both times for the same reason the rest of this PR keeps hitting: the stub never 404'd for the new mode, so the run denied earlier via the by-name lookup and never reached the fallback at all. It now goes red against the unescaped predecessor. refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 18:01:42 +02:00
timothyandClaude Opus 5	4261f76dd2	fix(778): derive the population from git, not the disk — the guard was red on every dev checkout ... Sixth cold review (a different reviewer, in-repo, worktree-isolated after the cross-family runs wedged twice on their sandbox). One High, one Medium, two Low, two Nit. All fixed. HIGH, and it is the third time this population has been wrong. `rglob` is recursive, so it also enumerated `.husky/_/` — 17 husky shims generated by `npm ci` via web/package.json's `prepare`, gitignored and untracked. The guard therefore derived 76 files against a 59-row table and was RED on every checkout that has run `npm ci`, while staying GREEN in CI, whose `script-tests` job checks out and pip-installs but never runs `npm ci`. A guard that fails everywhere except where it runs is the fastest possible route to "that test is always broken, ignore it" — on the artifact whose entire thesis is population correctness. Reproduced, then fixed at the source rather than with a fourth traversal patch: the population now comes from `git ls-files`. The index is authoritative, identical for CI and every checkout, and excludes untracked build output by construction instead of by an exclusion list someone must maintain. That is what this PR's own record says to do; the first three attempts each derived from whatever happened to be on disk. Three tests go red against the rglob predecessor. MEDIUM — twin-missed, in the fix from the previous round. Round 4 re-read the base before the branch-protection lookup, inside the scheduled branch only, leaving the #632 retarget DETECTION still reading the top-of-hook snapshot. The reviewer demonstrated it with this PR's own fixture: scheduled+retarget denied while immediate+retarget AUTO-GRANTED. The re-read is now hoisted above every base-dependent consumer, so one read serves both paths, and the duplicate is gone. Note for the record: the hoist is the load-bearing part — once `live_base` is fresh, #632's own comparison catches the retarget too, so the explicit deny only bites when no verdict records a base. The tests are scoped to exactly that case, because as first written they passed under mutation. LOW — a 404 from `branch_protections/<ref>` does not prove the branch is unprotected. Gitea keys that endpoint on the RULE name, so a base covered by a glob rule 404s while being fully protected, and an unencoded ref containing `/` (`release/26.4`) 404s because the path is malformed. Both produced a hard deny stating a specific, false cause — and a deny blocks outright rather than prompting. The ref is percent-encoded, and a 404 now consults the rule list before denying; an unreadable list asks. LOW/NIT — the scope prose attached the extension restriction to `scripts/` alone while the guard applied it everywhere (a `.py` hook would have joined the described scope and acquired no row); `.yaml` workflows are now in scope too. The `PINNED` definition required re-validation, which two legitimately-pinned rows do not do because their check and use are one step over an immutable event-payload sha. Row ordering restored. And once more, the recurring one: adding a scope TABLE to the doc made three prose rows parse as inventory sites — the parser reading its own documentation as data, the same defect as the UNSAFE-KNOWN check that once parsed the paragraph defining UNSAFE-KNOWN. Row parsing is now bounded to the inventory section explicitly. refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 17:53:25 +02:00
timothyandClaude Opus 5	f1e9cce4ae	fix(778): round 4 — the guard was checking a stale base, which is the defect it enforces against ... Fifth cold review: no Blockers, no Highs. 1 Medium, 1 Low, both fixed here. It also confirmed the #803 deferral is sound and re-verified every count (59 files, 69 rows, 3 PINNED; guards 34/5/15, proofs 8/6/20). MEDIUM — and it is the one worth the round. The branch-protection lookup used `$base_ref` from the PR snapshot taken at the TOP of the hook, and everything between is round trips (the file enumeration alone can be forty pages). A PERSISTENT retarget in that gap needs no ABA and no force-push: the lookup names the OLD base, confirms `review-verdict/h10` on a branch the PR no longer targets, and grants a scheduled merge onto one that may require nothing. The guard written to enforce "checking a stale identifier is not checking" was doing exactly that. The base is now re-read and compared immediately before the lookup; a move denies and names both branches. Mutation-proven. LOW — my caveat erred in the rare direction, understating a clause instead of overstating it. The scalar-row test's docstring called the whole `.statuses` member validation defence-in-depth because the #632 block masks it. That block validates `.context` and `.description` but NOT `.status`, so an object row with a numeric status passes it and does reach the new validator — where without the clause it becomes `vstate=7` and is reported as "the verdict is '7'" rather than as an unreadable payload. The caveat is now scoped to the payload rather than the clause, and the reachable case has its own test, also mutation-proven. The inventory row now conditions the guarantee on BOTH of its preconditions — the PR still targeting that base (fixed here) and the protection still standing (cannot be closed here, and said so). refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-16 15:31:49 +02:00
timothyandClaude Opus 5	8e02b9961d	fix(778): round 3 — fix the overclaim I left in the code, and defer the pre-existing ones to #803 ... Fourth cold review: no Blockers, 2 High / 2 Medium / 2 Low. It independently re-derived the population (59 files, 59 sites, 69 rows, 3 PINNED) and verified every numeric and factual claim in the diff, including the corrected confinement rationale. THE ONE THAT STINGS. The grant reason string still said a commit pushed before Gitea merges "will clear it and block the merge" — the exact sentence the new decision record quotes as THE overclaim this issue exists to remove. I documented it in three files and left it in the code a human actually reads. It now states the guarantee and its condition: the required check was confirmed rather than assumed, and it holds while that branch protection stands. FIXED HERE (all in files this PR already touches): - enable_status_check is validated as a BOOLEAN. `"true"` is not `true`, and comparing the string to `true` produced a confident deny from a payload never understood — the tri-state collapsing to two, the same defect as the contexts shape one line down. - `.statuses` members are validated, not just the array (see the honest caveat below). - the docs-reminder N/A rationale said "the job cannot fail and never reaches the combined status", which is false — any job's status joins the combined state. The true, narrower reason is that its fetch and diff are failure-swallowed, so the remote read can only change the warning's wording. - docs/README names the scripts/tests exclusion in BOTH statements. A VACUOUS TEST, CAUGHT BY ITS OWN MUTATION PROOF. The regression case for the `.statuses` member validation stays GREEN against the predecessor: the #632 base-retarget block runs first and already validates every member it consumes, so it catches the payload before the scheduled branch is reached. The two guards overlap — duplicate guards masking each other, again — which makes that finding LATENT, not live, and my added clause defence-in-depth rather than a fix. The test now asserts the observable contract (a decision is always emitted) and says plainly that it is not a mutation proof of the newer clause. Shipping it as one would have been the exact grade inflation round 2 rejected. DEFERRED to #803, with the reason stated rather than implied: a head-ABA (force-push H1 -> H2 -> H1 during pagination) defeats pr-changed-files.sh, and three OLDER contracts still assert more than the new inventory rows do. That residual predates #778 and lives in #707's mechanism; correcting another active decision record inside a PR already at four review rounds is how a scoped change stops being reviewable. The inventory rows are accurate today and now point at #803. refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-16 14:15:24 +02:00
timothyandClaude Opus 5	25048d9ea4	fix(778): round 3 — the fence covers BASE aliasing only, and stop citing a moving count ... Third cold review: no Blockers, 1 High / 5 Medium / 1 Low / 1 Nit. All accepted. It independently re-derived the 59-file population and matched it against `find`, so the traversal that was wrong in rounds 1 and 2 is now verified rather than argued. HIGH — the ABA claim was too broad. `ci.verdict-write-retarget-fence` counts `change_target_branch` events, so it fences the BASE axis and nothing else. A force-push H1 -> H2 -> H1 during pagination leaves the final `.head.sha` comparison equal while the middle pages were enumerated against H2, and no counter moves. Two rows implied the fence covered that; both now state the head residual as real and unfenced, with what closing it would take. Also: the record still said the scheduled-merge residual was "closed one layer down" by the branch protection an admin may have removed — the circular sentence that was rewritten in the inventory last round and left standing in its twin. The hook header still called an immediate merge "sound". Both now describe the bounded window. `docs-reminder` was over-demoted by grouping it with `decisions-guard`: it cannot fail its job, so it authorizes nothing and is N/A, while `decisions-guard` reaches the combined status. Split, per this file's own rule that differing classifications get separate rows. Over-demotion is a defect too — it makes the column noise. The scope heading and the docs/README entry now name the `scripts/tests/` exclusion explicitly, so nobody adds a remote-reading test executable expecting a red guard that stays green, and a wrong limit cross-reference is corrected. The exclusion's justification was also factually false — it claimed the only network calls were to PATH stubs, but test_hook_fire_log.py starts a real http.server on 127.0.0.1 and drives it with real curl. The exclusion stands on confinement, not on absence, and now says so. COUNTS. "4 of 68 PINNED" was wrong (3), and rewriting it as "3 of 68" went stale in the same commit when splitting a row moved the denominator to 69 — three stale figures in three rounds, in the record warning against exactly this. The exact denominator is gone: three rows survive as PINNED out of roughly seventy, and the load-bearing claim is "almost nothing is pinned", not an integer. A hand-maintained count is a second copy of the table; guard-inventory.md gives its counts an equality check because they ARE the point, and a rationale record should not pretend to. refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-16 13:58:40 +02:00
timothyandClaude Opus 5	84b4c11188	fix(778): round 2 — recursive population, and grade down five more overclaims ... Second cold review: no Blockers, 4 High / 1 Medium / 2 Low. All accepted. POPULATION, WRONG A SECOND TIME. Round 1 removed a content filter that had omitted `git fetch`. Round 2 found the replacement traversal used non-recursive `Path.glob`, so four nested files were still outside it — including scripts/scripted-schedules/entrypoint.py, which calls get_context() against a live ErsatzTV server and then drives define_content/reset_playout/build_playout off the result. Now rglob, with scripts/tests/ as the single stated DIRECTORY-level exclusion (a scope choice, reviewable in one line; not a predicate over content). Population 55 -> 59, rows 63 -> 68. The generalisation is in the record, because the deliverable made the same mistake twice: the scope may be hand-written, but anything narrowing the POPULATION has to be executed and its output compared against the filesystem — the members it drops are invisible by construction. That is the #774 rule turned on the artifact meant to enforce it. FIVE MORE OVERCLAIMS GRADED DOWN. Both merge-consent head/base rows (the hook returns `allow` and a separate call merges, so the window is small, not absent — "no async window" was simply false); the release smoke pull and the ci-image verify (the concurrency group is PER-REF, so a branch build and a tag build of one commit can publish the same :<short-sha>); and the workflow base-fetch rows, which are not advisory — the merge hook reads the COMBINED status, so any red context blocks the auto-grant. Also fixed a stale cross-reference where the enumeration row still said it "inherits that row's pins" from a row graded down in the same commit. Four PINNED rows survive out of 68. That ratio is the honest finding. CIRCULAR JUSTIFICATION REMOVED. The scheduled-merge row said its residual was "closed one layer down" by the very branch protection an admin may have removed. It is not closed, it is BOUNDED by a trust assumption, and the row now says so. Low: jq's `//` fires on `false` as well as null, so `status_check_contexts: false` was defaulted to [] and produced a confident deny from a shape never understood — absent and null are now defaulted explicitly, everything else is "unknown". And the title sentence claimed "every executable in this repo" while the guard covers four directories; both it and the docs/README entry now say what is actually enforced. refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-16 13:44:10 +02:00
timothyandClaude Opus 5	a0849eec58	fix(778): address the cold review — drop the population filter, grade down three overclaims ... Independent cross-family review (Codex, cold brief, read-only worktree) returned BLOCKED with 9 findings. All 9 accepted; #5 partially, keeping one row PINNED with its justification stated. POPULATION (the finding that mattered most). The derivation filtered the scope by an outbound-network token list and argued that was a scope choice rather than a population filter. It omitted `git fetch` — this repo's most common remote read — so prepush-rebase-check.sh, which fetches origin/main and derives a PUSH DECISION, was structurally invisible to a guard claiming to cover "every executable that reads live remote state", along with three others. The defence offered was that over-inclusion is the safe direction; the filter also under-included. The content filter is gone: the population is now all 55 files in the scoped directories, and a file that reads no remote state carries an explicit N/A row. OVERCLAIMS, graded down. Three rows asserted more than the code does: - the scheduled-merge path was PINNED while the hook's own comment concedes the branch-protection read pins nothing → UNSAFE-KNOWN, "preflight, not a pin"; - pr-changed-files.sh was PINNED and claimed "any movement fails", but before-and-after equality is ABA-vulnerable (main → scratch → main) → UNSAFE-KNOWN, pointing at the caller-side event-count fence that does close it; - the CI toolchain image was PINNED on a mutable TAG, against this file's own definition naming a digest → UNSAFE-KNOWN. The release smoke pull stays PINNED: it pulls the tag the same concurrency-serialized job just pushed. The guard-inventory MUTATION regrade is reverted to BEHAVIOUR-ONLY (8/6/20). The review is right on species: the test feeds the real script an input the clause rejects, which this table explicitly defines as behaviour-only and has already regraded three rows for. A manually-executed disarm does not change what the test is. TWO REAL FAIL-OPENS FIXED: - jq `index()` on a STRING is substring search, so a status_check_contexts arriving as "prefix-review-verdict/h10-suffix" answered yes and would auto-grant. Membership is now exact equality over a value first proven to be an array of strings. - post-review-verdict.sh guarded both re-read comparisons with `[ -n "$x" ] &&`, so a 2xx body that merely omitted .head.sha or .base.ref made the check a no-op and the status was posted having confirmed nothing. That second fix carries a lesson worth the line: the obvious mutation (disarm the new `-z` arm) stays GREEN, because the unconditional `!=` also rejects empty — the two overlap, exactly the duplicate-guards-mask-each-other shape. The proof is taken against the REAL predecessor with the `-n` conjunct restored, which goes red showing returncode=0 and a status written. Also: 404 is now separated from 403/transport (an unprotected branch is the strongest form of the finding; `curl -sf` collapses both to an empty string), and the positive control asserts the decision is `allow` and that the endpoint was actually reached, rather than the absence of one phrase. refs #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-16 13:20:42 +02:00
timothyandClaude Opus 5	fe578c5864	feat(778): name the check-and-use race, and verify the protection the merge gate rests on ... #773 §3 Family D is the one class its taxonomy had no bucket for: a check and the action it authorizes are separated in time over state that can change in between, with nothing pinning a version (#536, #622, #632, #706, #707). The repo had already solved this twice without noticing it was one problem — a compare-exchange claim in-process (ffmpeg.work-ahead-slot-atomic) and RFC 7232 If-Match across /api/v1 (concurrency.ifmatch-rfc7232) — and then solved it a third time from scratch for the tooling at #706/#707. Hence a class-level record rather than a fourth per-instance one. What the enumeration actually found, which none of the five records predicted: the merge-consent hook's scheduled-auto-merge path is safe only because `review-verdict/h10` is a REQUIRED status check on main. That is branch-protection CONFIG, it lives outside this repo, nothing compared the two, and the hook asserted it in a comment AND in the grant reason a human reads. Switch the context off and every word of that sentence is false while the hook keeps printing it and keeps auto-granting. The hook now reads the branch protection and treats it as three outcomes: present proceeds, unreadable asks, absent denies. Two defects were caught by the new checks themselves rather than by review: - the population test found .gitea/workflows/dependency-scan.yml absent from the first draft of the inventory (a sixth workflow the recon slice never listed); - self-review found the guard denying with a confident wrong reason when jq errors one level down on a malformed contexts member, so the word is now matched exhaustively rather than compared against "yes". Same swallow that survived the first fix in the #632 base-change guard. Detector D has no plausible linter, so the detector is detector A applied to an enumerated inventory: docs/remote-state-inventory.md classifies every in-scope executable, and scripts/tests/test_remote_state_inventory.py derives the population from the filesystem and asserts set equality both ways. Deferred with reasons stated in the inventory: select-queue.sh (advisory, authorizes no write), ci-detect-already-validated.sh (skip elides re-validation only, the image still builds), review-verdict.yml's status POST (Gitea offers no conditional write; already fenced by #706's retarget counter). Mutation proofs witnessed for both new guards, clause-level, not whole-file. fixes #778 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-16 12:57:04 +02:00
timothyandClaude Opus 5	15d2439915	feat(794): witness a fix's test failing BEFORE the fix, and check the claim in CI (#801) ... Mechanises the defect that took #776 and #793 six review rounds each: a fix's test written to confirm the fix, not to discriminate against its absence. testing.guard-ships-with-mutation-proof generalised from guards to fixes. prove-fix.sh runs the selector at the commit (control, must be GREEN) and again in a separate fresh worktree with the non-test files reverted (must be RED = pytest exit 1 exactly; 2/3/4/5/143 are refused, and --continue-on-collection-errors keeps add-a-file fixes provable). pytest's status comes from a marker written only after it returns, because ( cd X && pytest ); rc=$? returns the SUBSHELL's status. Opt-in by a Proves: trailer; CI checks every commit that carries one and says out loud when a PR has none. THE TOOL REJECTED ITS OWN AUTHOR. Three commits on the branch claimed Proves: scripts/tests/test_prove_fix.py; the job returned UNPROVEN for all three, because reverting the script restored a working earlier version the suite also passed. Two had been "verified" against hand-written mutants that did not match the code that actually shipped. The tests were rewritten until both go RED against 587edbecc — whose script emits "red without it (pytest exit 2)", a witnessed false PROVEN. This branch deliberately carries no Proves: trailer: the only one that would pass does so because reverting deletes prove-fix.sh, an add-file smoke check rather than a proof of its logic. The logic proof is a clause-level mutation that re-runs the unchanged refusal test against a mutant and witnesses it red (graded MUTATION). fixes #794 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Timothy <timothy@noreply.gitea.tblindustries.be>	2026-08-16 10:24:59 +00:00
timothy	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
timothy	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
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