874 Commits

Include renames

Author	SHA1	Message	Date
timothyandClaude Fable 5.1	b1d5fbefcb	fix(916): cross-family state is per round, and the orchestrator reads cross_family before a verdict ... A substitute that failed in round one said nothing about the tree that lands after round two, yet the flag was sticky and doomed the run; the xfamily string was never reset either, so clearing the stickiness alone would have let a stale "substitute ALSO failed" sentence into the PR body. Both reset at the top of review(). The harness runner is round-aware (ran per round, its own counter reset) and a two-round case pins the fix; restoring the sticky flag reddens it in both scripts. Step 4 of the mechanics page tells the referee to read cross_family, not only error, before posting on a rubric-class PR. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 13:48:15 +02:00
timothyandClaude Fable 5.1	595c819de1	fix(916): a failed substitute is an error, not a landed claim; head_sha described in both schemas; the issue's box says what the code does ... The runner-beside-the-lenses design is now what Done-when box 1 asks for (body amended). A rubric round whose runner and worktree fallback both fail returns an error before the push instead of landing a PR whose body claims a substitute reviewed it. The harness records lens count at the runner's start too (expects 0, so a re-serialised runner reddens), resets its counter per round, and has a case for the double failure. Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 13:14:09 +02:00
timothyandClaude Fable 5.1	929dff835a	fix(916): the Codex runner runs beside the lenses, only the fallback waits; head_sha described everywhere; the docs keep their thresholds ... The runner builds nothing, so serialising it only added its wait to the critical path; the worktree-isolated fallback is what must follow the lenses, and the harness case now records lens count at the FALLBACK's start alone. setTimeout in the harness is globalThis.setTimeout (the .mjs lint config has ES builtins only). head_sha carries the same description in both scripts and every fixer/implementer prompt asks for the worktree HEAD, not a PR head. The mechanics page says why the cap stays at one after the serialisation and restores the 20%/10% RAM thresholds by key; the record says "several", not "three". Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 12:43:58 +02:00
timothyandClaude Fable 5.1	f7a0da4051	fix(916): the cross-family review step follows the lenses instead of running beside them, and fix commits are a sha range ... One .NET slot's review round ran two worktree-isolated reviewers at once — the correctness lens and, on a rubric change, the Codex fallback — and took swap from 6.8 GB to 10.8 GB in three minutes on the 16 GB host; three slots reached load 82. review() now awaits the lenses, then the Codex runner, then its fallback. The finisher's fix attribution is the sha range the fixer's report head advances (head_sha is required on every report), replacing a line-set difference over free text that listed all eleven #563 commits as fixes. The harness gains a case that records how many lenses were still in flight when the cross-family agents started (must be zero); moving the fallback back into the parallel batch reddens it in both scripts. The mechanics page and the standing prompt state the measured cap: one .NET-building slot at a time. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 12:07:17 +02:00
timothyandClaude Fable 5.1	4454f1adfc	docs(563): anchor the measurements to the issue, which a squash merge cannot erase ... The paragraph added a commit ago pointed at "the commit messages that ran them" as the home of the binder and `trim` mutant outcomes. A squash merge writes its own message and drops the bodies it squashes, so that pointer can go stale the moment this branch lands. The issue and its pull request survive it, and #563 is where the round-by-round measurements already are. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 09:36:56 +02:00
timothyandClaude Fable 5.1	3df98d247f	docs(563): state each binder test's mechanism instead of its mutant colour, per the amended CLAIMS rule ... `testing.mutation-claims-are-executed` was amended on main while this branch was in review (#881, merged as #914): a sentence asserting that a specific mutation reddens — or does not redden — a named test is now either a `CLAIMS` entry in `scripts/tests/mutation_manifest.py` that executes every run, or it is not written. This branch carried six such sentences and none of them can be declared: `Claim.node_id` resolves a proof to `scripts/tests/<node id>` and `run_pytest` invokes pytest, so an NUnit proof has no representation in that harness at all. Durable prose now states the mechanism each test is built on — which serializer difference, which engine branch — which a reader re-checks by reading the code rather than by trusting a remembered outcome. The record says that in one paragraph, so the limit is stated rather than papered over. The outcomes themselves are here. Re-measured 2026-09-05 on this branch's tree (the commit before this one), each mutant applied to the working tree and restored from the index between runs, tree verified clean afterwards: positive control ScriptedScheduleControllerTests Passed: 9, Failed: 0 OpenApiSerializerContractTests Passed: 4, Failed: 0 Bind<T> -> System.Text.Json with JsonSerializerDefaults.Web Failed: 2, Passed: 7 — Production_Body_Binder_Ignores_Required_Members, Production_Body_Binder_Keeps_Declared_Defaults_Over_An_Explicit_Null BodyBinderSettings = ApiJsonSettings.Create() -> new JsonSerializerSettings() Failed: 1, Passed: 8 — Production_Body_Binder_Keeps_Declared_Defaults_Over_An_Explicit_Null OpenApiSerializerContractTests RuntimeSettings -> new JsonSerializerSettings() Failed: 4, Passed: 0 — all four cases, on PascalCase keys ScriptedScheduleController AddDuration(..., request.Trim, ...) -> false Failed: 1, Passed: 8 — Committed_Script_Fixture_Produces_The_Pinned_Snapshot ScriptedScheduleController PadUntilExact(..., request.Trim, ...) -> false Failed: 1, Passed: 8 — Committed_Script_Fixture_Produces_The_Pinned_Snapshot The last one is the round-two finding closed and re-witnessed: before the fixture's pad target moved off the content boundary, that mutant left all nine green. A squash merge writes its own message, so these figures also belong in the PR description. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 09:31:42 +02:00
timothyandClaude Fable 5.1	d6e4426aa9	docs(563): retire the forward-references the supersession falsified, and trim the record to what only it says ... Two pointers still named #563 as the open reason scripted playout has no coverage. The ContentEnumeratorBuilderTests header now points at the successor record and docs/testing.md instead of the issue this branch closes. docs/decisions.md carried an orphaned fragment, "external-process pipeline remains #563's", in the residual block under ## Index -- with the pipeline now permanently outside the automated suite rather than deferred, the fragment states something false and has no recoverable subject to rewrite it around, so it goes. The record's rule gains the two things measurement settled: that ApiJsonSettings shares production's configuration and never MVC's settings object (MaxDepth 32, the two ProblemDetails converters, pinned by ApiJsonSettingsTests), and that a fixture must aim every trimming instruction between two content boundaries or that action's trim argument is witnessed by nothing. Its body loses the mutant table and the extraction paragraph, which the mechanics doc its own frontmatter points at carries verbatim; what remains is the conclusion plus the reasoning that exists nowhere else. 70 prose lines to 56, under the advisory ceiling without dropping a distinct finding. Refs #563 Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 09:25:11 +02:00
timothyandClaude Fable 5.1	053982180d	test(563): witness the trim flag on both trimming actions, and stop the binder claiming parity with MVC's ... The fixture's pad_until_exact targeted 10:00, which the 15- and 30-minute items reached exactly, so the engine's trim branch never ran and mutating `engine.PadUntilExact(..., request.Trim, ...)` to `false` left every controller test green -- measured on the pre-change fixture, `Passed! - Failed: 0, Passed: 9`. The target moves to 09:55, off every content boundary: Movie 01 is now trimmed from 30 minutes to 25, the snapshot is re-pinned around it, and the same mutant fails Committed_Script_Fixture_Produces_The_Pinned_Snapshot while the sibling add_duration mutant still does. The trimmed span and OutPoint are asserted directly rather than resting on the snapshot alone, and the fixture and the snapshot comment both record that landing a trimming instruction on a content boundary is what silences its trim flag. ApiJsonSettings.Create() was documented as a standalone serializer configured the way MVC's is, which measurement refutes: Apply runs against a bare JsonSerializerSettings rather than the one MvcNewtonsoftJsonOptions pre-configures, so MaxDepth stays at Newtonsoft's 64 instead of MVC's 32 and ProblemDetailsConverter and ValidationProblemDetailsConverter are absent (MissingMemberHandling, TypeNameHandling and DateParseHandling do match). Neither gap can reach a scripted request body -- two levels of nesting, never a ProblemDetails -- so this was overstated prose, not a broken test. Restating the delta everywhere parity was claimed would leave four copies to rot, so ApiJsonSettingsTests pins it in both directions and the prose points at the pin. Also clears the three nullable warnings the replayer helpers introduced (CS8600/CS8604 on the action string, CS8603 on Bind<T>) and corrects the ExpectedSnapshot comment, whose last column is built from MediaItemId rather than looked up from the seeded title. Refs #563 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 09:25:11 +02:00
timothyandClaude Fable 5.1	c0a70d724a	test(563): witness the Newtonsoft half of the binder claim, and narrow the prose to what reddens ... The branch asserted that binding fixture bodies through ApiJsonSettings makes "a swap to a lookalike serializer" redden. Measured, only half of that was true: replacing ScriptedScheduleControllerTests' BodyBinderSettings with a plain `new JsonSerializerSettings()` -- a Newtonsoft lookalike that has lost the production configuration -- left all 8 tests green. Only the System.Text.Json swap reddened. So the production edits the branch makes for that coupling (ErsatzTV/Serialization/ApiJsonSettings.cs and the Startup rewrite) were justified in four places by a hazard no test could see. Both halves are now real. Production_Body_Binder_Keeps_Declared_Defaults_Over_An_Explicit_Null binds `{"order": null}` and posts it to AddCollection: NullValueHandling.Ignore keeps ContentCollection.Order at its declared "shuffle" and the call is a 200, where Newtonsoft's own Include default writes the null through and AddCollection's Enum.TryParse returns a 400. That is a behaviour difference a script would see, not a settings-shape assertion, so it is not a second copy of the settings list. Mutants, run 2026-09-05 over the 9-test fixture: Bind -> System.Text.Json web defaults 2 red BodyBinderSettings -> new() 1 red (was 0 before this commit) OpenApi RuntimeSettings -> new() 4 red (write side, naming strategy) What still nothing observes is Startup.ConfigureServices itself: re-inlining the AddNewtonsoftJson lambda as a hand-copy of Apply reddens no test, because a byte-equal mirror is behaviourally indistinguishable. ApiJsonSettings removes the duplicate rather than detecting its drift, and docs/testing.md, the decision record and all four docstrings now say that instead of claiming a detector. Drift confined to ReferenceLoopHandling or the StringEnumConverter is witnessed by neither suite; that is stated rather than left implied. Also files the 401 blind spot the record had described as "tracked separately" while nothing tracked it. ersatztv#913 records the chain, verified from source: the filter is registered globally, EndpointRequiresKey fail-closes every mutating verb, ScriptedScheduleController carries no [SkipApiAuthorization], and neither ScriptedPlayoutBuilder nor entrypoint.py supplies a credential. Refs ersatztv#563 and ersatztv#913. Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 09:25:11 +02:00
timothyandClaude Fable 5.1	4bd5cf9e91	docs(563): scope the required-member claim to the serializer, and name model validation as residue ... The previous commit said a body omitting a `required` member "reaches the action" in production. That overreaches what was measured: MVC adds an implicit required check for non-nullable reference types (ErsatzTV.Core.Nullable has <Nullable>enable</Nullable>, and Startup configures no ApiBehaviorOptions, so the [ApiController] automatic 400 is live), which would very likely reject that body before the action. What is measured is the SERIALIZER: Newtonsoft deserializes it to a default, System.Text.Json throws. The prose in the test, ApiJsonSettings, the record and docs/testing.md now stops there and puts MVC model validation on the uncovered-wrapper list where it belongs. Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 09:25:11 +02:00
timothyandClaude Fable 5.1	16a6e2790f	test(563): bind the fixture with the production body binder, and name the wrapper that is left ... The docstring, the decision record and docs/testing.md all claimed the replay covered everything except two hops. MVC model binding was a third: production binds /api/* bodies with Newtonsoft (Startup -> AddNewtonsoftJson -> CustomContractResolver + StringEnumConverter) while the replay deserialized with System.Text.Json. Measured on this tree: for the fixture's own bodies the two agree, but for a body omitting the `required` member "collection" they diverge -- System.Text.Json throws, Newtonsoft binds Collection = null and the action runs. So the fixture's stated purpose ("field names and casing match what the HTTP body binder accepts") was asserted by nothing, and a fixture production would bind differently could still go green. Rather than only widening the residue list, bind the way production binds. The registration moves into ErsatzTV/Serialization/ApiJsonSettings.cs, Startup applies it from there, and both OpenApiSerializerContractTests (which had its own mirror of the settings) and the scripted replay now call that same function -- one definition, no copies to drift. Production_Body_Binder_Ignores_Required_Members asserts both halves of the divergence THROUGH the replay's own Bind helper, so pointing the replayer at another serializer reddens; the fixture's own bodies cannot witness that swap. The residue is now named honestly in all four places: the binding WRAPPER (input formatter, the [ApiController] automatic 400 before an action runs) is uncovered, the serializer inside it is not. Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 09:25:11 +02:00
timothyandClaude Fable 5.1	0d2cd89782	docs(563): supersede the scripted-golden deferral with the in-process coverage rule ... The deferral record described ScriptedScheduleController as a "1:1 pass-through" to SchedulingEngine. It is not: an unparseable playback order is a 400, an unparseable filler kind SILENTLY degrades to FillerKind.None, an unknown build id is a 404, and the engine's no-progress InvalidOperationException is translated to a 400. Carrying that wording forward would have shipped a false statement, so the successor states a thin adapter with named mappings, each pinned by a test. - new record testing.scripted-engine-in-process-net (active, since 2026-09-05) - predecessor testing.scripted-playout-golden-deferred git mv'd to docs/decisions/archive/testing/ with frontmatter retargeted only; body prose byte-identical, so no Decisions-Edit trailer - docs/decisions.md Index line retargeted to the archive path plus a new dated line for the successor - catalog regenerated with scripts/build_decisions_catalog.py - docs/testing.md: the Golden-file nets paragraph now points at the new coverage instead of "tracked in ersatztv#563"; a new "Scripted playout coverage" section states what is covered where and what is deliberately not covered (Cli.Wrap launch, Kestrel + Startup middleware, ApiAuthorizationFilter), dated 2026-09-05; Timezone independence records the per-call TZ audit that decided which engine instructions the fixtures may use. Refs #563 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 09:25:11 +02:00
timothyandClaude Fable 5.1	0f8e73ab05	fix(881): the replacement clause asserted an absolute I had not measured ... The previous commit replaced "the order is load-bearing" with "and that is the whole of what the order buys". What was measured is narrower: with the relevance gate moved first, the three gates are each still witnessed refusing alone. That does not establish the order buys nothing else - the reset placement is a second candidate, unmeasured either way - so the absolute is gone from both sites and what stays is the cost reason, which is readable from the control flow. refs #881 Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 07:09:14 +02:00
timothyandClaude Fable 5.1	f34828806d	fix(881): the gate order I called load-bearing is a cost choice, measured ... `verify_claim`'s docstring and the record's `mechanics` both said the relevance gate must run LAST or the status and vacuity gates could never be witnessed failing alone. Executed at ff65e5e7c: moving the `reset_sandbox` + reach `verify_mutation` + `if not reach.ok:` block ahead of both earlier gates and changing nothing else, then running `pytest scripts/tests/test_mutation_harness.py -p no:randomly -k "GREEN_EXIT_STATUS or GREEN_VACUITY or GREEN_RELEVANCE or UNKNOWN_outcome"` gives 4 passed. Two of those four assert the reasons the LATER gates produce ("exited 1", "NOTHING PASSED"), so with the relevance gate first both earlier gates were still read and still witnessed refusing alone. It cannot hold, and the branch already said why one line away: the reach mutation injects a failing test, so it reddens in every fixture except the relevance one, which is what `_inert_claim_sandbox`'s own docstring states. What the order actually buys is cost - the relevance gate is the only one of the three that costs a second run of the proof - and that is what both sites now say. #881's own defect shape, inside the record that establishes the rule against it. Second, the record twice gave line-wrapping as the reason a sentence was paraphrased rather than quoted. The branch's own first `CLAIMS` entry quotes a sentence that spans a comment line break, embedding the `# ` continuation, and the harness resolves it exactly once - so a wrapped sentence is quotable by this very mechanism. The real reason at the calibration site is the replacement itself: that sentence is not in the tree any more, measured 2026-09-05 by a fixed-string search over `git ls-files`, which returns no file. At the second site the referent (`docs/defect-shapes-773.md` section 4) is present and quotable, so the causal clause is dropped and only the paraphrase marker stays. refs #881 Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 07:06:52 +02:00
timothyandClaude Fable 5.1	91a9fbf81a	docs(881): name the reach mutation the way the rule field names it ... The residual paragraph called it "a stronger mutation", which is a judgement about size; what the mechanism requires is a second mutation of the same clause, declared and required to redden the proof. One vocabulary across the rule field, the manifest and the body, so a reader does not have to decide whether two descriptions are the same thing. Refs #881 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 05:18:43 +02:00
timothyandClaude Fable 5.1	a956cc6b8d	fix(881): the same outcome claim, restated in the proof's own docstring ... The claim the shipped GREEN entry binds — what removing the `+++ /dev/null` arm does — was written twice: in `check-doc-narrative.py`, where the entry binds it, and again in `test_a_DELETED_doc_is_not_reported_as_added_content`'s docstring, where nothing does. That is the copy-of-an-outcome shape this rule forbids, in a site class the rule names, found while reading the proof for the residual below. The docstring now points at the manifest entry and keeps its rationale (a deletion yields no `+` lines either way), which is the half the carve-out protects. The residual paragraph is also made exact rather than general. The reach mutation proves the proof depends on the clause through the `b/` stripping every scanned header goes through, not through the `/dev/null` arm itself, so in general such a green cannot separate "no test feeds that input" from "the arm changes nothing". For this entry it can, by reading the proof: the deleted-doc test deletes a tracked file, and a deletion diff under the flags `run_diff` pins carries a `+++ /dev/null` header — probed rather than reasoned. Refs #881 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 05:05:59 +02:00
timothyandClaude Fable 5.1	a9341d8415	fix(881): a GREEN claim is only readable if its proof REACHES the clause ... Round three found the one half of the new mechanism with no relevance gate. `verify_claim`'s GREEN path read exactly two things — the run exited 0, and something PASSED — and both are satisfied by a proof that never touches the mutated file at all. Reproduced before fixing: retargeting the shipped GREEN entry's proof from `test_check_doc_narrative.py` to `test_bom_guard_detection.py` changed nothing, and the entry still reported verified. The RED direction never had this hole, because a proof that ignores the mutation stays green and is refused as "the clause is not load-bearing". So a GREEN entry now declares a `reach_replacement` and its `reach_expect`: a SECOND mutation of the SAME clause, required to REDDEN the same proof, executed through `verify_mutation` so its red is read through the diagnostic gate rather than on exit status. The shipped entry declares `path = p` — dropping the `b/` stripping every scanned diff header goes through — and the run then scans NOTHING, which is what the declared diagnostic reads. The same retarget now fails, naming the reach verdict. The gate runs LAST of the three: run first it would refuse before the status and vacuity gates were read and neither could be witnessed failing alone (#685), and the sandbox is reset between a claim's two proof runs for the reason it is reset between mutations. It has its own disarm proof, and the two synthetic claim sandboxes are now real git repositories so `reset_sandbox` has a baseline; `_lib_with` shares the baseline registry, since a copied module's own starts empty. Also from that round: - The record no longer counts the mutation-outcome claims in the pinned proposal-3 scan. A third of the same shape sits in the same result set (`test_a_verdict_BEYOND_A_SHORT_PAGE_is_still_found`), and which side of the line a sentence falls on is a judgement, so an exact count is a figure the next reader re-derives differently — the failure this record is about. - The calibration paragraph no longer restates the post-review-verdict outcome as a dated witnessing. It points at the `CLAIMS` entry that executes it, which is the form the rewritten shell comment beside it demands. - The comment in `check-doc-narrative.py` claimed a universal ("reddens no test") while one file is executed. It now names that file, so the quote binds an outcome no wider than what is checked. - Proposal 4 from the issue is dispositioned explicitly: rejected as a rule here, on the issue's own argument that an exhortation does not fire at the moment of least slack. - `docs/README.md`'s task-signal parenthetical now names the `CLAIMS` population; the file was owned by another slot when this branch started. Cost re-measured 2026-09-05, three baseline/branch pairs: the `CLAIMS` half adds 31.7-43.6%, up from the 12.7-16.6% measured before the gate existed. The old figure is retired rather than scaled — growing the population invalidates the measurement that described it. Refs #881 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 05:02:46 +02:00
timothyandClaude Fable 5.1	7dba36cd58	fix(881): my own paragraph asserted the scan found no mutation-outcome claims - it found two ... Self-review of the previous commit, on the same class it fixes. "none of them asserts a mutation outcome", written about the 58 lines the proposal-3 scan returns, is false. Two do: the mutation table at `docs/decisions/records/ffmpeg/watermark-resolution-unified.md` line 104, which names a dropped discriminator and the single test that catches it, and `web/src/screens/AutoTuneScreen.test.tsx` line 174, which says what a revert to the old flex row can redden. Both read in full at `efadbec29` rather than from the truncated grep line - the truncation is how the first pass missed them. Three kinds of sentence under one pattern is a better argument than the one the false claim was making: it is not that the pattern finds only rationale, it is that it finds rationale, state anchors and mutation-outcome claims side by side and nothing in the string tells them apart. Two smaller ones in the same commit. The new test's docstring said the gate is "the one gate the others cannot cover" and the manifest said "the one PRE-FLIGHT refusal a red proof cannot be told apart from" - both assert uniqueness among the pre-flight refusals that neither measured, and a clause occurring zero times also leaves the text identical. Narrowed to what the mutant demonstrates: no later gate stands in for it. And the fixture comment glossed `verify_claim`'s GREEN refusal in quote marks, which under this record's own proposal-2 clause reads as a quotation of the library; it is not one, so the marks are gone. refs #881 Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 04:44:29 +02:00
timothyandClaude Fable 5.1	99966f8bd7	fix(881): a control's purpose stated backwards, and an enumeration that grew past what it could carry ... Four review findings, all of the class this branch is about - prose asserting what a mechanism does, with nothing binding it to the mechanism. The record's `mechanics:` said a GREEN claim over an already-red proof "would otherwise be satisfied by the redness it is supposed to rule out". Inverted: `verify_claim`'s GREEN branch REFUSES any non-zero exit, so redness refutes a GREEN claim and can never satisfy one - which is what test_MUTATION_disarming_the_GREEN_EXIT_STATUS_gate_accepts_a_proof_that_WENT_RED asserts. The hazard the control removes is the same one it removes for the rows, and it runs in both directions: an already-red proof satisfies a RED claim with redness its mutation did not cause, and refuses a GREEN one for a reason unrelated to its mutation. Both the record and the fixture comment now say that, and both say what the control CANNOT do - its assertions are over the aggregate of every proof ref, so a single ref collecting nothing is invisible to it and is caught per-claim by the vacuity gate instead. The manifest's `why` had widened a scoped sentence into "THE OTHER GATES EACH CARRY THEIR OWN PROOF" and then enumerated them, which made the enumeration a completeness claim it could not meet: the identical-replacement refusal carried no proof at all. The review measured that at 8adf21eff - `if mutated == original:` disarmed, whole file 49 passed 1 skipped. That gate is the one a red proof cannot be told apart from: the mutant is byte-identical, so the proof runs against the original tree and an already-red one reddens exactly like a detection. Disarmed, the harness certifies it as "the named test went red under the declared mutation, with the declared diagnostic" - witnessed here on the real library, restored after. So the measurement above no longer holds, by construction: the gate now has a disarm proof, and the sentence says explicitly that naming the gates is not a claim the list is closed. Proposal 3's rejection quoted "16 lines" with no predicate - the defect the record's own body names three paragraphs later, where the population scan is pinned verbatim for exactly that reason. The figure is not reproducible from the text. Replaced by a pinned `git grep` over the same corpus at the same sha (`32 files, 58 lines`), with what reading all 58 shows: they are rationale, the class the rule carves out, and the few real state anchors among them are not separable by pattern, because the difference is whether the sentence explains or asserts. refs #881 Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 04:44:29 +02:00
timothyandClaude Fable 5.1	9e0e11030b	docs(881): the third quotation on this branch that resolves to nothing ... `docs/defect-shapes-773.md` §4's sentence was quoted verbatim-looking but with a lowered initial capital, and the source wraps it across a line at `evidence`/`behind`, so neither the written form nor the corrected one is findable by grep. Same treatment as the `post-review-verdict.sh` one: paraphrase without quote marks, keep the section reference, say why. The section reference itself was checked - the sentence is at line 351, under `## 4. Detectors`. refs #881 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 04:44:29 +02:00
timothyandClaude Fable 5.1	80cd0a9ee9	docs(881): a quotation that resolves nowhere, and a paragraph contradicting the one above it ... Two more in the same class, both in prose this branch wrote. The calibration paragraph quoted `post-review-verdict.sh` as asserting "the absent-entry check catches every case on its own". That string occurs in no file: the comment wraps it across a line break at `catches`/`every`, so `git grep` for it finds exactly one hit - the record asserting it. That is ersatztv#812's second defect reproduced inside the record written to end it. Paraphrased without quote marks and pinned to lines 316-317 at `efadbec29`, which is what this record's own proposal-2 clause prescribes for a quotation that cannot be checked. The closing paragraph called the scan's hits "the remaining population" and "a backlog", three paragraphs after establishing that both figures are CANDIDATE counts and that reading them as a backlog of real claims overstates them. The closing text now says what is actually known: a place to look, with nobody having established how many are claims. refs #881 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 04:44:29 +02:00
timothyandClaude Fable 5.1	443df1391b	docs(881): drop a figure anchored to the branch HEAD - the anchor moves ... The sentence explaining why the scan pins a sha quoted a second figure for `HEAD`, which is exactly the anchor-to-a-moving-state shape this record settles: correct on this branch, wrong the moment anything else lands. The reason it was supporting is checkable without a number - the paragraph's own prose, the pinned command included, matches the pattern. The first draft of that replacement said "twice over". Three lines of the paragraph match, so the count is dropped rather than corrected; a count of matching lines in a paragraph nobody will re-measure is the same defect one size smaller. refs #881 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 04:44:29 +02:00
timothyandClaude Fable 5.1	1b5dd80681	fix(881): regenerate the catalog the previous commit's rule edit staled ... The generated catalog embeds each record's `rule`, so rewording the quote-scope clause in 38bdf7bd0 left `docs/decisions/README.md` behind the record. Nine tests red on it - the four `build_catalog_check_path` reformat cases, its stale-catalog CLI proof, two `decisions_validate` main() cases, and the two mutation-harness entries whose positive control runs that validator. refs #881 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 04:44:29 +02:00
timothyandClaude Fable 5.1	11e4d74256	fix(881): three more claims in my own fix, and a cost band that rounded outward ... Self-review over the fix commit, on the same predicate the record states. The cost band said 13-17% over measurements spanning 12.7% to 16.6% - a band that ROUNDS is still a band the data does not support at its lower edge. It now states 12.7-16.6%, which is the span itself, with the per-pair figures beside it. The quote-scope rule was stated as an OUTCOME claim ("free to be rewritten under a green harness", "with the entry still reporting the red as verified") in the record's `rule`, in the manifest preamble and beside the entry. That is a mutation-outcome claim about the harness with no `CLAIMS` entry behind it - manufactured by the sentence that introduces the rule against it. All three now state the STRUCTURE, which is what a reader can check by looking: the assertion and the test it names are outside the binding. The manifest preamble said "three of the entries below assert that a mutation is NOT noticed". `CLAIMS` holds three entries and exactly ONE is GREEN; the three the `Claim` docstring names are CORPUS sites, not entries. Corrected to one, and "the most common shape prose actually takes" - a frequency nothing measured - dropped rather than quantified. Two claims in the new record prose were themselves overstated. The 69-line green narrowing was described as the negative direction rather than as candidates for it: sampling the hits shows `green` in this corpus is as often a CI job's colour as a mutation's outcome, so both figures are now labelled CANDIDATE counts. And the "the number moves under the commit that records it" sentence now carries the figure that shows it - the same command with `HEAD` in place of the sha prints `107 files, 344 lines`, measured on the committed tree. refs #881 Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 04:44:29 +02:00
timothyandClaude Fable 5.1	3489254c8b	fix(881): re-derive the population from a PINNED scan, and bind the claim quote to the outcome it asserts ... Four review findings, every one the defect class this record is about: a prose assertion with nothing binding it to what it asserts. THE DERIVED POPULATION WAS NOT REPRODUCIBLE. "128 lines across 65 files" and "47 of the 128 carry the NEGATIVE direction" cannot be reached from the predicate the record described, while the record told the reader to re-run it there. A review swept ~40 readings of that description at efadbec29 and none returns either number. The scan is now pinned VERBATIM as the command that produced it, and the figures are what that command prints at efadbec29 on 2026-09-05: 104 files, 311 lines - candidates 39 files, 69 lines - the same command with the outcome half narrowed to `green`, i.e. the negative direction Both were re-run by extracting the fenced command from the committed file and executing it, so the text and the numbers cannot have diverged. This supersedes the 47/128 figures quoted in 05992bec7's message. CLAIMS[0]'s QUOTE BOUND THE WRONG HALF. It stopped at the comma after the mutation, leaving "so `test_a_readback_whose_statuses_array_is_NULL_is_refused` reddens" outside the binding - the words that make the sentence a claim. The harness counts occurrences of the quote alone, so the outcome could be rewritten, or the test renamed in the prose, with the entry still reporting the red as verified. The quote now spans both halves, and the scope rule is stated in the record's `rule` and in the manifest beside the entries, where the next one is written. "BOTH WERE CORRECTED IN THE SAME CHANGE" WAS FALSE. Only the shell comment was: the Python test has asserted the shape diagnostic since 5d955000f (#889), and this branch does not touch it. What this change adds beside the rewritten comment is the binding. THE COST BAND CONTRADICTED ITS OWN MEASUREMENTS. `mechanics` said 13-15% over three pairs spanning 12.7%, 16.6% and 14.4%. It now states 13-17% and the per-pair figures, since the record tells the reader to carry the percentage forward rather than the seconds. refs #881 Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 04:44:29 +02:00
timothyandClaude Fable 5.1	4008f4b574	fix(881): exempt the claim binding from the index-population registry, and fix three prose claims in the change itself ... `test_mutation_harness.py` now imports the shared index derivation, which `test_every_index_derived_module_is_registered` requires be registered or exempt. It is exempt: its population is `CLAIMS`, and it consults the index only per member, to answer whether a declared `site` is a path git tracks. The exemption list's own docstring counted its entries, so that count and its review date move with it. Three claims written by this change were falsified by this change, which is the shape it exists to catch: - the binding test's docstring said membership comes from the index "not from `Path.is_file`", while the same test now asserts existence with `is_file`; - the record quoted the manifest docstring this change rewrites — an anchor to a state the commit moves, which the record itself rejects. It now anchors to `efadbec29`; - the `Claim` docstring quoted three files without naming them. They are named. refs #881 Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 04:44:29 +02:00
timothyandClaude Fable 5.1	1fc24e8cf6	fix(881): a mutation-outcome claim is executed wherever it is written, bound to the sentence that makes it ... `testing.mutation-claims-are-executed` was the right rule scoped to its first site: `mutation_manifest.py` declared itself "one per `MUTATION`-graded row of `docs/guard-inventory.md`", so the same claim written in a code comment, a test docstring or a decision record was outside it by construction. That is where all four of ersatztv#812's consecutive review-round defects lived. Extend the rule in place rather than adding a sibling record: a sibling would recreate the exact shape (a rule per site class, with the next site class outside both) that #773, #784 and #743 each are. The subject is unchanged; only the population widens. Mechanism: `CLAIMS` in `scripts/tests/mutation_manifest.py`, keyed on the PROSE. Each entry carries the tracked `site` and the verbatim `quote`, checked every run, so a reworded sentence reports as a retarget instead of drifting from the entry that justifies it — this is proposal 2 (a quotation of another file is a claim about that file) adopted where the referent is declared. Each entry also declares RED or GREEN and is executed in the existing sandbox. GREEN is new: 47 of the 128 candidate lines the corpus grep returns at efadbec29 assert that a mutation is NOT noticed, and no `MUTATION` row can express that, so the rule was unsatisfiable for them. The green direction is read by two separate clauses (exited 0, and something actually passed) so neither can mask the other, and each carries its own disarm proof. Proposal 3 (never anchor prose to a state your own commit moves) is rejected as a DETECTOR and kept as a phrasing rule: measured 2026-09-04, the only plausible pattern set for it matched 16 lines across the scanned corpus and every one was legitimate rationale prose. The seed set falsified a shipped claim on its first run: `post-review-verdict.sh` asserted that disarming its array-TYPE read-back test left the suite green. It does not — jq refuses to iterate a `null` `.statuses` and the script dies with the parse message, reddening `test_a_readback_whose_statuses_array_is_NULL_is_refused`. Comment corrected, entry graded RED. fixes #881 Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 04:44:28 +02:00
timothyandClaude Fable 5.1	4a56d54283	fix(911): a should-fix finding sends the round back, a failed-lens round is an error, and a harness executes the loop (#912) ... fixes #911 Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 02:43:44 +00:00
timothyandClaude Fable 5.1	14e075174b	fix(911): in a resume, the existing PR's stale head is the expected state until the push, not a finding ... Three consecutive #554 resume rounds graded "PR #910's head is still the first commit" as blocking; the push deliberately follows the loop. The reviewer brief now says so when args.pr is set. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 03:06:02 +02:00
timothyandClaude Fable 5.1	692affca97	fix(911): a round with no reviews is an error, the history binds each fix to the round it answered, and a harness executes the loop ... A round in which every lens returned null read as a clean pass and would now have been quoted verbatim into the PR body; it is an error before the push, in the review loop and in the post-rebase round, which also gains the same blocking-or-should-fix filter; a fixer that dies or stops (no done) is an error too, the same test the implementer already gets. The history entry now carries the fix that answered that round and only the commits that fix added (a line-set difference against the previous branch log — a fixer that reformats or rebases mid-loop defeats it, which is why the finisher is told to read git show, not the list). An empty fix-commit set is described as "answered without a new commit" when a fix round ran, and as "round one was clean" only when none did. web/scripts/orchestration-workflow-loop.test.mjs compiles the committed script bodies with stubbed agent/parallel and pins eleven paths per script (22 tests). Measured: reverting the loop condition to blocking-only reddens six cases per script (every case that needs a should-fix round to reach the fixer); deleting any of the three zero-lens guards, the fixer guard or its done half, or the empty-fix sentence branch reddens its own case, in both scripts. web/vite.config.ts is untouched: it is pinned whole by test_image_build_delegates_the_spa_suite.py, comments included. Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 02:50:23 +02:00
timothyandClaude Fable 5.1	350509f8bb	docs(554): the opt-in's unreachability is about started, not about mount order ... "its button renders only before the player has ever mounted" is loose: a channel switch to a forced channel re-renders the button after a player has mounted for the previous channel. The load-bearing fact is the one the code comment states — the button renders only while `started` is false, and the only thing that un-starts the panel is the channel reset that clears the flag in the same batch. Refs #554 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 02:45:42 +02:00
timothyandClaude Fable 5.1	f119bfcb29	docs(554): the opt-in is a third path back to starting, and the invariant must say so ... The hint's single-guard invariant was stated as "every path back to `starting` clears the flag itself", enumerating Retry and a channel change. `onOptIn` is a third such path and clears nothing, so the sentence was false as written — in the code comment, in the Retry test's comment, and in docs/spa-conventions.md §5b. Adding a clear to `onOptIn` would be dead code no test could distinguish, which is the exact shape this branch removed from `onPlaying`. The omission is correct for a reason none of the three places stated: the opt-in button renders only while `started` is false, `started` only goes false in the render-phase reset that clears the flag two lines later, and no player exists to set the flag while `started` is false. State that exception, and pin the reachability premise it rests on with a test that fails if the opt-in button outlives the mounted player. Refs #554 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 02:42:39 +02:00
timothyandClaude Fable 5.1	4e042fb7de	fix(554): the hint's cause must be measured, and muting is the consumer's call ... Round one measured three defects in the first commit. onAutoplayBlocked fired on ANY rejected video.play(), so the panel could say "autoplay was blocked" when it was not. A play() interrupted by teardown rejects with AbortError — which is exactly what the panel's own Retry produces while the MANIFEST_PARSED play() is still pending — and because the element was muted, a genuine NotAllowedError is the rare case, so the realistic firings were the mislabelled ones. Report only a DOMException named NotAllowedError, on both the MSE and native paths. `muted` was applied to the shared player unconditionally, which silently muted the playback-troubleshooting screen — the tool whose job includes verifying the audio side of an FFmpeg profile, and which the legacy Blazor player never muted. Make it an opt-in `muted` prop defaulting to false; the channel preview passes it, troubleshooting does not, and a test on each side pins its own value. The two clauses hiding the hint once playback starts masked each other: removing either alone left the panel suite green. Every path back to 'starting' (Retry, a channel change) already clears the flag itself, so the clear in onPlaying could never be the load-bearing guard — drop it and let the `state === 'starting'` render guard be the single pinned one. Also cover the native-HLS (Safari) branch, which no test had ever executed: its play() kick, its playing/error wiring, and both autoplay rejection names. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 01:46:37 +02:00
timothyandClaude Fable 5.1	ade14a7521	fix(911): a should-fix finding sends the round back, and the finisher reports the recorded review history ... The fixer brief already said "fix every blocking and should-fix one"; the loop condition alone disagreed, so a merge-worded round with real defects skipped the fixer and the finisher attested to fixes it never saw (#554 / PR #910). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 01:41:00 +02:00
timothyandClaude Fable 5.1	02e1c583e9	fix(554): mute the preview player so autoplay is never blocked ... HlsPlayer's manifest GET can block until segments exist (unbounded maxTimeToFirstByteMs), so MANIFEST_PARSED can arrive past the browser's transient user-activation window and video.play() gets rejected as blocked autoplay — the channel preview panel then sat at "starting" over a black frame with no hint the operator just needed to press play. Render the <video> element muted (browsers permit autoplay of muted media without user activation) so the common case starts on its own, and add an optional onAutoplayBlocked callback for the residual case (stricter policy/extension) that the channel preview panel wires to a "press play" hint shown only while still starting. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 01:12:39 +02:00
timothyandClaude Fable 5.1	e1d211cd1b	test(830): pin which ARM the call site reaches, not only that the hook has one ... Review measured M6: swapping `reportFailure(...)` for `onAddFailed(...)` in `AddItemsDialog`'s catch left all 490 tests across the 42 `src/screens` files green. Under that mutant a failure that lands while the dialog is STILL OPEN renders into `ManualItemsView`'s screen banner, which sits behind the dialog's `createPortal` panel with `aria-modal="true"` — covered for sighted users, hidden from AT, and the surface the user is actually looking at stays blank. That is the exact shape the decision record calls "its own defect", and the whole gap was the call-site wiring: the hook's inline branch is pinned at unit level in `hooks.test.tsx`, but a unit test of the hook cannot see which arm a consumer reaches. Adds the integration assertion: fail the POST with the dialog still up, assert the message is inside `[role="dialog"]` and appears exactly once in the tree. Re-executed the mutation with it in place — 1 failed / 490 passed, and the red is this test alone. Records the new pin as mechanics (5) on `spa.dismissible-write-failure-reporting` and the general form in `spa-conventions.md` §3c, so the next site wired to the hook pins both arms at its call site rather than inheriting the hook's unit coverage. Refs #830 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 00:23:09 +02:00
timothyandClaude Opus 5	e4c346e649	test(830): pin the ORDINARY close too — the negative test did not cover it ... Round 6 verdict was MERGEABLE with two follow-ups; both are one-liners on lines this branch just touched, so they are in rather than deferred. L11. I believed the suite covered "a normal add still closes the dialog". Review MEASURED that it did not: deleting the `onClose()` call entirely -- so a successful add leaves the picker open forever -- kept the whole suite green, 1277/1277. The new #830 test only pins the NEGATIVE direction (do not close when unmounted), so a future edit dropping the call, believing the guard had made it dead, would have shipped silently. The Song add test now asserts the dialog closes; with that line, the same deletion reddens. Both directions of the report/dismiss split are pinned. Worth naming the shape: I asserted coverage from plausibility rather than from a mutation, in the same PR whose whole subject is claims that were written down before they were measured. N12. The guards test's "exactly ONE post-await write to state THIS component owns" is still true, but it now reads as a census of `mountedRef` reads, and `submit` has two -- the success path's guarded `onClose()` is the other, which that failure-path test never reaches. Added the clause so nobody derives the guard population from that number. 1277 tests green, tsc/eslint/build clean, pytest 1228 passed, validator OK, catalog no drift. The two red CI contexts on the previous head are runner flakes, not this branch: both failed inside `Post Checkout` with `Cannot find module '/var/run/act/actions/<hash>/dist/index.js'`, their logs are timestamped 19:18 (before that head existed), this branch touches no CI or docker/ci file, and both contexts were green on its earlier heads. refs #830, #877 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XE2tF2aUasK2hWPmBRsrMY	2026-09-05 00:23:09 +02:00
timothyandClaude Opus 5	86e9ad41a6	fix(830): gate onClose at the exemplar — the convention contradicted its own reference ... Round 5 found that §3c and the `rule:` field now instruct readers to gate the DISMISS request, while `AddItemsDialog` -- the one site this record names as "the shape fixed here" -- called `onClose()` unguarded, with a comment arguing that was correct. So a reader following the convention wrote the gate and a reader copying the reference implementation did not. The defect is pre-existing; the CONTRADICTION is mine, introduced when round 3 withdrew H1's code but kept the convention it produced. I checked the docs against the withdrawn addTo code and did not re-check them against the exemplar that stayed. Measured at this site: submit, Escape mid-request, reopen the picker to retry, first POST returns 204 -> the stale instance's `onClose()` (`() => setPickerOpen(false)`) closes the dialog the user just reopened, discarding the selection they rebuilt. Identical mechanism to the addTo clobber. Unlike the addTo layer, the one-line gate IS sufficient here, and that difference is the point: `AddItemsDialog`'s parent has no competing closer (`onAdded` is `load`, which never touches `pickerOpen`), whereas `AddToMenu.handleAdded` closes its dialog itself. That is now stated in the record as the concrete reason one half shipped and the other went to #877. - `onAdded()` stays unguarded -- it REPORTS, and the parent's list reload must survive dismissal - `onClose()` is guarded -- it REQUESTS A DISMISSAL, and after dismissal it aims at whatever the user opened next - comment rewritten to say which is which and why, instead of defending both as "belong to the still-mounted PARENT" Pinned, and nothing pinned it before: "a late SUCCESS does not close the dialog the user reopened after dismissing (#830)". It carries an anti-vacuity check that the late response was actually processed -- `onAdded` is `load`, so a second GET of the items endpoint must have happened -- because otherwise "the dialog is still open" holds trivially. Executed: deleting the `if (mountedRef.current)` around `onClose()` reddens it alone. Also rewrapped five record body lines left ragged by earlier splices. 1277 tests green, tsc/eslint/build clean, pytest 1228 passed, validator OK, catalog no drift. refs #830, #877 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XE2tF2aUasK2hWPmBRsrMY	2026-09-05 00:23:09 +02:00
timothyandClaude Opus 5	4b12125f4d	docs(830): drop a coverage claim this record's own mechanics field contradicts ... Round 4 found one clause left, and it is a good example of the thing this record is about. The one-consumer paragraph said `hooks.test.tsx` "is the ONLY thing pinning the diverted branch". Measured at the previous head, disarming `reportRef.current(message)` reddens THREE tests -- both hooks.test.tsx divert tests AND the CollectionsScreen integration test -- which is exactly what the `mechanics:` field of the same record says 58 lines earlier. So the record asserted a coverage fact and then contradicted itself. The concrete harm is not the inconsistency: a future session pruning tests reads "hooks.test.tsx is the only pin", concludes the CollectionsScreen #830 test is redundant, and deletes the only end-to-end pin of the whole path -- the one that actually drives Escape-dismissal through the real dialog. Clause dropped; the argument the paragraph needed (the hook's shape earns its own unit tests) survives without it. The clause originated in the reviewer's round-3 wording and I transcribed it without checking it against a field I had written myself two rounds earlier. Worth recording: a review finding is not exempt from verification just because it came from the reviewer. Also: - the `AddToMenu` clobber sentence now splits what was MEASURED (a late success closes a reopened dialog) from what was READ (both parents call `clearSelection()` unconditionally, so the wipe follows). On a record whose subject is over-attributing measurements, that distinction has to hold in its own prose. - §3c now carries the same "nothing diverts to those screens today" disclaimer the record's limit (2) has, so the two artifacts say the same thing - rewrapped one 141-char comment line left ragged by the previous round's splice Docs only, plus one comment rewrap. 1276 tests green, tsc/eslint/build/validator/catalog clean. refs #830, #877 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XE2tF2aUasK2hWPmBRsrMY	2026-09-05 00:23:09 +02:00
timothyandClaude Opus 5	626cbfbf9d	docs(830): three sentences survived the revert of the code they described ... Round 3 verified the withdrawal itself is clean -- the eight reverted files are byte-identical to origin/main, no orphans, and the mutation gives the stated three reds -- but found docs still asserting the withdrawn change shipped. That is the stale-comment failure in its usual form: after a retraction, the retracted WORDING has to be swept, not just the code. - `hooks.ts` said "#830 removed that gate", flatly false at this head, in the hook's own doc comment right above the export -- the first thing a maintainer reads. It also carried round 2's framing ("both halves of the outcome") as the hook's purpose, when what ships carries only the failure half. Rewritten to the present tense of the shipped tree. - The `rule:` field still said the surviving surface "differs per screen", naming MediaBrowseScreen and SearchScreen as wired. They wire nothing. This one matters beyond an ordinary sentence: `rule:` is the canonical summary, it is what the catalog row shows, and it is what gets mirrored per-key into MemPalace -- so it is the version a future session retrieves WITHOUT opening the file. Now: exactly one wired screen, the Toast pair named as a CANDIDATE. - The "two limits" bullet described a failure being diverted to those same screens and announced politely. Nothing can divert there -- they receive no reporting callback. Restated as the limit the second surface will have when it is wired. - `onFailed` in a hooks.ts comment was a dangling identifier; the real prop is `onAddFailed`. Also added the caveat the reviewer asked for rather than leaving it to be discovered: this is a shared hook with exactly ONE consumer. It earns that shape (directly unit-tested, and those tests are the only thing pinning the diverted branch; prescribed by §3c; #877 queued as a second consumer) -- but #877 may land a shared reporting SURFACE instead of a per-site prop, in which case the second consumer never arrives. Accepted risk, now written down. Docs only. No code change, 1276 tests still green, tsc/eslint/validator/catalog clean. refs #830, #877 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XE2tF2aUasK2hWPmBRsrMY	2026-09-05 00:23:09 +02:00
timothyandClaude Opus 5	de9432ff49	fix(830): withdraw the media/addTo extension — two rounds, two defects, one coupled gate ... Round 2 of adversarial review found that my round-1 fix introduced an adjacent defect, and it is the same mechanism both times: `onAdded?.()` and `onClose()` sat behind ONE unmount gate in the four `media/addTo/` dialogs, and those two callbacks do not mean the same thing. - Gate both (origin/main): a write that SUCCEEDS after dismissal reports nothing. Measured on `AddToCollectionDialog` -- `onAdded` called 0 times after dismissal. That was round 1's finding. - Un-gate both (my round-1 fix): a late success closes a dialog the user REOPENED to retry, and on SearchScreen/MediaBrowseScreen `clearSelection()` wipes a multi-select they rebuilt. Measured against the real `AddToMenu`. That was round 2's finding, and I introduced it. - Gate only `onClose`: still wrong on its own, because `AddToMenu.handleAdded` nulls the dialog itself. Needs three coupled edits across five files -- plus a genuine product question nobody has answered: should `clearSelection()` fire for a write the user walked away from? That is a design change, not a bug fix, and #830 never asked for it -- the issue is about `AddItemsDialog`. Two defects from one mechanism in two rounds is the signal to stop widening, so the `media/addTo/` extension is REVERTED here and moves to #877 with every measurement attached (#877 comment). What ships is the thing the issue asked for, proved: - `useDismissSafeError` + `AddItemsDialog` + `CollectionsScreen` wiring - the witnessed red is unchanged: disarming `reportRef.current(message)` reddens the integration test on `Unable to find an element with the text: Request failed with status 500` Docs now describe what is actually true rather than what I hoped: - the record says ONE A1 site is fixed and explains why the other four were withdrawn, keeping the wrong first claim visible because "one site read, four assumed" is the lesson - §3c splits the rule the round-2 defect came from: report the OUTCOME unguarded, gate the DISMISS request separately -- the earlier text lumped `onClose` in with `onAdded` and would have propagated the clobber to the next screen that adopted it - §5c no longer tells authors to wire an `onFailed` that the addTo layer does not have; it says the layer has no failure channel at all and points at #877 - the reporting prop is REQUIRED where the host has a surface (`AddItemsDialog.onAddFailed`), which is what the docs now say instead of calling it optional - `mechanics:` no longer implies the shared clause reddens one test; it reddens three, so re-running the mutation should expect three refs #830, #877 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XE2tF2aUasK2hWPmBRsrMY	2026-09-05 00:23:09 +02:00
timothyandClaude Opus 5	f61764d051	fix(830): report SUCCESS past dismissal too — the review measured my claim false ... Adversarial review (cold, worktree-isolated) blocked the first commit on its central prose claim, correctly. I wrote "at every one of these sites SUCCESS already outlives dismissal" into three durable artifacts -- the decision record, spa-conventions §3c and the hooks.ts header -- after reading ONE site. `AddItemsDialog` does report success past dismissal and says so in a comment; I generalised from it. The review probed the other four instead and MEASURED `onAdded` called 0 times after dismissal: all four `media/addTo/` dialogs gated `onAdded?.()`/`onSaved?.()` behind their own `activeRef`, exactly like the failure path. So after the first commit those four were still asymmetric, just inverted: dismiss-then-fail loud, dismiss-then-succeed silent -- and additionally leaving the caller's selection state stale, because SearchScreen's `onAddedToSelectionTarget` never ran to clear it. The record's own advice ("add the failure counterpart") followed literally would have reproduced it. Fixes, each proved by execution: - the `activeRef` gate above `onAdded?.()`/`onSaved?.()` is removed in all four dialogs; those two statements belong to the still-mounted PARENT, which is the reasoning AddItemsDialog already had - `AddToCollectionDialog.test.tsx` covers the media/addTo half in BOTH directions. It had NO coverage before: reverting `reportFailure` to `setInlineError` in all four left the whole suite green. Restoring the success gate reddens the SUCCESS test alone; disarming `reportRef.current(message)` reddens the FAILURE test alone - the three prose sites now say what was measured, and the record keeps the wrong first version visible, because "one site read, four assumed, written down before measuring" is the finding Also from the review: - hooks.ts said "React 18"; package.json pins 19.2.7. Now "React 18+" - the "nothing better to do" comment overclaimed: diversion reaches ONE level, so Back out of a collection mid-add still drops the message. Stated, with where it would be fixed - recorded two limits rather than leaving them to be rediscovered: useIsMountedRef clears in a PASSIVE effect cleanup, leaving a narrow window where the message renders inline into a detached tree (useLayoutEffect would close it, but that hook is shared by every async caller -- #877, not a bug fix); and Toast is role="status" with one last-writer-wins slot, so it is not equivalent to CollectionsScreen's role="alert" - §5c now cross-links §3c, since that is the section a screen author reads before wiring AddToMenu - the sweep count is 67 caller-owned + ConfirmDialog's own internal <Dialog> Three other media/addTo dialogs remain unpinned; they are identical in shape to the covered one, which is a reason to expect the same behaviour, not evidence of it. Said so in the record. refs #830, #877 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XE2tF2aUasK2hWPmBRsrMY	2026-09-05 00:23:08 +02:00
timothyandClaude Opus 5	9ba397e1dd	fix(830): a write failure reports to a surface that outlives the dialog that started it ... `AddItemsDialog.submit` POSTed to `/api/v1/collections/{id}/items` and reported failure into a banner rendered from its OWN state. The dialog is dismissible mid-request through three paths that never consult `adding` -- Escape and a backdrop click (both `useOverlayBehavior`) and the header close button -- and the caller remounts it on `key={`add-${pickerOpen}`}`, so dismissal genuinely unmounts it. Select 12 items, Add, press Escape, the request fails: nothing surfaces, the list reloads unchanged, and the user believes 12 items were added. drop deliberate rather than accidental. A deliberate drop is still a user who is told nothing. The asymmetry is the finding: SUCCESS already outlived dismissal everywhere here, because it is reported through a parent callback (`onAdded`/`onDone`, which the screens turn into a `Toast`). Only failure died with the surface. So this is not a new notification system -- it routes failure through the channel success already uses. `AddToMenu` had `onDone` and no counterpart at all. `useDismissSafeError` (`web/src/hooks.ts`) renders the message INLINE while the surface is mounted -- the better surface, since it keeps the user's selections and context -- and diverts to a caller-supplied `onFailed` once it is gone. The surviving surface belongs to the parent and differs per screen (a `role="alert"` banner on CollectionsScreen, `notice`+`Toast` on MediaBrowse/Search), so it is a prop contract rather than a rendering decision. Gating dismissal on the busy flag was considered and rejected: it traps the user behind an in-flight request with no cancel path, and would not cancel the write anyway. Applied to the A1 shape -- where the surface owns the error state and is really unmounted: AddItemsDialog plus the four `web/src/media/addTo/` dialogs, whose failures previously could not reach the screen Toast that already showed their successes. Proofs, executed rather than described: - deleting `reportRef.current(message)` alone reddens the new CollectionsScreen test on `Unable to find an element with the text: Request failed with status 500` - `hooks.test.tsx` pins both branches directly, plus that the report goes through the LATEST callback rather than the one captured on first render - `CollectionsScreen.guards.test.tsx`'s is-mounted read count moves 2 -> 1 because the catch's guard migrated into the hook (its `...actual` module mock cannot see the hook's internal `useIsMountedRef()`); removing the surviving `finally` guard takes it to 0 and reddens, so the anti-masking property that count was added for is intact Scope is stated rather than implied. A sweep of all 68 Dialog/ConfirmDialog/SlideOver call sites found three shapes; only A1 is fixed here. A2 -- error state that survives but whose render site is gated by the same condition dismissal clears, mostly delete-confirm flows -- is left open in #877 because its right answer is probably a shared surface, not twenty prop threads. fixes #830 refs #877, #740, #685 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XE2tF2aUasK2hWPmBRsrMY	2026-09-05 00:23:08 +02:00
timothyandClaude Fable 5.1	a0203f2863	fix(907): round two — a guard denial means a foreign worktree, required keys under every branch, a gated post-rebase round ... The marker-overwrite instruction asserted an antecedent no agent can verify and, since same-session worktrees carry no marker, could only fire in another session's worktree; the scripts now stop and report. `ran` and `patch_changed` move into required keys of their own schemas so a missing field cannot read as a successful cross-family review or an unchanged patch. A blocking finding in the post-rebase round now returns an error like every other failure path. Each reviewer lens gets its own E2E port; the gate text travels with the reviewer brief. The standing prompt no longer contradicts the substitution the scripts perform; the record names patch-id, the mechanism the scripts use. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-04 23:25:49 +02:00
timothyandClaude Fable 5.1	63256afd96	fix(907): answer the cold review — drop the E2E lock, scope force-with-lease in a record, referee ticks the boxes ... The mkdir lock around scripts/e2e-local.sh serialised the launch, not the run (the launcher returns with the server up), and its stale-holder path double- acquired in 4 of 91 measured races; the launcher's documented conflict is its per-worktree wwwroot, so slots now run on their own port and the lock is gone with its inventory row. process.orchestrated-session records the two scopings the harness needed: a rebase pushed with --force-with-lease as the one sanctioned rewrite, and the referee as the only agent that ticks Done-when boxes. Scripts: required-arg guard, per-issue claim probe, reviewer fetch recipe, codex fallback to a cold review-only agent with the substitution stated in the PR body, rebase before the review loop with a patch-id check at the push, non-interactive squash recipe, Land phase. README bullets re-parented; kickoff bullet keyed. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-04 23:07:59 +02:00
timothyandClaude Fable 5.1	a380129700	feat(907): orchestrated sessions — mechanics page, standing prompt, pick/build/resume workflows, E2E gate ... The single-issue kickoff stays as it is; this adds the layer that runs several of those under one referee. docs/handoffs/orchestration.md owns roles and sizing, one worktree per issue under ~/orca/workspaces/ersatztv/, the landing order with the review loop inside the worktree before the single push, and the merge through the consent hook. Three Workflow scripts encode it: a picker over scripts/select-queue.sh with two refuters, an issue-build pipeline (claim, recon, implement, gate, cold review with a cross-family runner for the rubric's risk classes, fix loop, finisher), and a resume pipeline for a paused branch. scripts/e2e-gate.sh serialises live-E2E across worktrees because e2e-local.sh refuses concurrent runs. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-04 22:27:42 +02:00
timothyandClaude Fable 5.1	a7d91bf15a	fix(876): sweep session narrative out of hooks, workflows, scripts, tests and code comments; grow the detector to the process corpus ... `docs.no-session-narrative` reaches every durable artifact, but its detector scanned only `docs/**/*.md` and root markdown, and nothing had ever swept the rest. The issue named four sites from one grep and called them a floor. Deriving the population instead — a whitespace-joined sweep over every tracked file outside the detector, for the detector's own phrasings plus the attribution and review-round class #812 found — gave 453 sites in 108 files at `fb5592971`, and a second pass for phrasings the first list missed (hyphenated `round-N`, "an earlier version", "the reviewer proved") added residuals in the same files. Every site was classified with #812's three dispositions (CUT / SEVER / KEEP with its sub-kind) under the who-benefits test; the per-site manifests are on the PR. The rejected designs, tested-and-rejected fixtures, measurements and traps stay; the attribution of who found them and the round in which they were found go. The detector's population grows to `.claude/`, `.gitea/`, `.husky/` and `scripts/` regardless of extension, minus the detector and its own test (whose fixtures ARE the phrasings) and minus `scripts/tests/fixtures/` (test data, including decision-record copies — the same reasoning as the records' own exemption, and what keeps the record's depth measurement true), and `--all` lists tracked REGULAR files only — a symlink's content is its target and a gitlink has none. The #812 argument for leaving `docs/superpowers/**` in the population runs the other way here: `--diff` sees only ADDED lines, and 287 of the 453 sites were under 30 days old — this corpus is where narrative is being added, so the advisory nudge has reach. Density agrees: 56 line-mode hits over the 113 regular files the predicate admits, against 9 over 66 docs files before #812. `web/` and C# stay out on the same measurement (3 of 74 PATTERNS-matching sites, ~4,600 files). The predicate did not grow: PATTERNS matched 74 of 453 sites, and widening the word list to the attribution class is the treadmill the withdrawn parity test ran on. The population oracle is restated over segments with the new arms, the synthetic cross product gains the process heads and non-markdown extensions, a fixture witnesses that a tracked symlink is neither scanned nor counted, a `.py.bak` axis separates a by-name exemption from a `startswith` over the same tuple, and eight mutants (drop the process arm, drop the by-name exemption, exempt by `startswith`, drop or add a prefix, drop the fixtures exemption, list only markdown, drop the symlink filter, test the mode per row instead of per path) each redden it. A pre-existing silent drop in `--diff` goes with it: git tab-terminates a `+++` filename that contains a space, and the kept tab made `is_scanned_path` refuse the file with no notice — fixed, with a positive control and its own mutant. Code is unchanged by construction, measured per file type against `origin/main`: Python modules are AST-equal with docstrings stripped, except `#` lines inside the embedded fixture programs (string literals) of three test modules; workflows differ only in `#` lines inside `run:` block scalars; shell, C#, TypeScript and jq are equal with comment lines stripped. The stated exceptions: the detector and its test, 26 vitest titles that carried review-round or severity labels or a reviewer attribution (call sites whose title changed — every changed title line walked back to its `it(` / `it.each(...)(` anchor, so a `' + '` concatenation counts once), two registry note strings and the mutation manifest's prose fields. scripts/tests: 1565 passed. Web: lint, typecheck, 1319 tests green. Closes #876. Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PEcBoFw7ctrf3Nb7R7x7wk	2026-09-03 20:51:39 +02:00
3 people	fb55929711	fix(869,893): re-establish the 1.25.4-dated CI claims on 1.27.1, and settle the page_statuses asymmetry from source (#905) ... Finishes the 1.25.4-dated CI claim sweep #747 deliberately left incomplete (#869), and answers #893 from the Gitea v1.27.1 source instead of inferring it from a header. Docs and comments only - zero non-comment changes in scripts/ and .gitea/. Population derived with `git ls-files`, not from the issue's item list: 17 files, 43 occurrences of `1.25.4`, against the 4 items #869 named. Re-established on 1.27.1: the `creator`-attribution claim the H10 allow-list rests on (4 merged heads, both endpoints); the scope enum (no `status` scope); the `reqRepoWriter(unit.TypeCode)` gate; the `write:package` 403 (live probe with a read control 200 and a write control 201, throwaway repo, artifacts deleted); the absence of any REST cancel route (from source, which a 404 alone cannot establish); and `pull_request`/`pull_request_target` definition resolution. #893: `/statuses/{sha}` does NOT drop rows after pagination. `getCommitStatuses` appends unconditionally and its only filter is a SQL WHERE in the same query as the LIMIT/OFFSET, so an empty page really is the end, `page_statuses` terminating on its first empty page is safe, and the asymmetry with `count_pr_mutations` is correct - recorded with its reason and a date so it is not tidied away. Corrected rather than re-dated: the `--depth=1` no-merge-base claim was filed against the wrong axis (a git property, re-probed on git 2.55.0), and `enable_bypass_allowlist` postdating 1.25.4 had an issue body as its only provenance. Five cold review rounds plus a cross-family Codex pass. They caught a wrong MECHANISM for `creator: null` (it is `CreatorID == -2`, not `== 0`), an evidence count that straddled the upgrade, and a reason for not re-probing MCP `cancel_run` that was invented - all fixed, final verdict CLEAN. fixes #869 fixes #893 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Whe75djeAEuZpdNk6KU7No Co-authored-by: Timothy <timothy@noreply.gitea.tblindustries.be>	2026-09-02 20:20:43 +00:00
3 people	8fd9eae0bf	fix(891): a sourced path is code, so every hook resolves it from its own tree (#903) ... Every hook under `.claude/hooks/` assigned `ETV_HOOK_FIRE_LIB` from `${CLAUDE_PROJECT_DIR:-<self>}` and then `. `-SOURCED it. Sourcing is execution, so a file of that name in an env-designated tree ran as code inside the hook before stdin was read and before it could decide anything. Measured on the merge gate before #858 fixed that one hook: a decoy tree's copy printed an `allow` and exited 0. Reachable without an attacker, because husky is a different launcher: `.husky/pre-push` invokes `./.claude/hooks/…` relative to the PUSHED tree, independent of the variable, so a push from one worktree while the environment names another sources the other tree's code into a gate. Sweeps the remaining twelve hooks together (population derived from `git ls-files`), reconciles the second resolution inside `scripts/hook-fire-log.sh` itself, and requires the root to OWN the sink (`-ef`, not `-e`). The static guard pins the preamble BYTE-FOR-BYTE — a withdrawal, after a lexical rule was defeated by five successive shapes. Also pins two arms of the checker that were unsubsumed AND unpinned: the begin call's presence and its missing stdout-mode token. `…_LOSES_its_instrumentation_…` looked like their proof and was not — it asserts only that the fault list is non-empty, and a stripped hook trips four arms, so deleting either left the suite green. fixes #891 refs #858, #859, #776 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UYNbVwgVszv6Pum7ZuGd75 Co-authored-by: Timothy <timothy@noreply.gitea.tblindustries.be>	2026-08-30 21:41:19 +00:00
timothy	dd0f75f1b6	fix(855): two glob dialects cannot be canonicalised into one, so model one shape and refuse the rest (#902) ... `ci-image.yml`'s `on.push.paths` decides which pushes to `main` publish a toolchain image; `ci-image-pin`'s `git log` pathspec decides what the pin must name. #744 removed the shared self-reference that kept them in step, leaving the agreement carried by three prose comments, and divergence is silent and green in the dangerous direction. The guard derives both lists from the workflow documents and compares them for set equality in both directions. The comparison is deliberately narrow: it accepts a publish entry spelled exactly `<dir>/**` against a pathspec entry spelled exactly `<dir>`, segments restricted to `[A-Za-z0-9._-]`, and raises on every other spelling rather than deciding what that spelling would have selected. That narrowness is the substance. Measured against Gitea 1.27.1's own in-tree compiler (`modules/actions/workflowpattern` -> `modules/glob.CompileWorkflow`) and real git: a bare `docker/ci` in `paths:` compiles to an anchored `^docker/ci` and selects none of the directory's contents while the git pathspec `docker/ci` selects all of them; `<file>/**` matches nothing while the pathspec `<file>` tracks the file; a leading `/` is literal to Gitea while git refuses it outright. A canonicaliser mapping the two dialects onto one string form was built twice and defeated twice, each repair surfacing another spelling, so it was deleted rather than extended per `testing.verification-code-needs-its-own-proof`. The guard also asserts from the git index that each named path really is a directory, since `<file>/**` and the pathspec `<file>` spell the same string; takes the pathspec from the `git log` assignment rather than any `git log` in the job; refuses a `<<` token on a code line (a herestring excluded) and a second bare `--`; and treats an absent and an empty `paths:` alike, because Gitea's `Skip` returns false on an empty sequence, so `paths: []` filters nothing and every push publishes. The docstring states the boundaries rather than implying coverage: the guard compares the pathspec the pin job writes and does not establish that the staleness comparison consumes it, and a descendant whose path below `<dir>` contains a newline is matched by the git pathspec but not by the publish pattern. Verified by nine independent cold-review rounds, none of which found a false green; the last fuzzed 27,720 publish/pathspec pairs against a port of the deployed compiler and real `git ls-files`. fixes #855	2026-08-30 19:25:23 +00:00