3629 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
timothyandClaude Opus 5	c710db4a1d	fix(751): review round — the twin null-shape, a governance self-exemption, and four over-claims ... Two independent cold reviews (a cross-family GPT-5.6 pass and an isolated Opus pass). Neither found a path to a green `review-verdict/h10` on an unreviewed head. Both found real defects BESIDE the fix, which is the failure mode this file keeps producing. THE TWIN, and the reason not to trust "I fixed the two I could see". `GET /commits/{sha}/status` returns `statuses: null` — not `[]` — for a head with no statuses yet: `{"state":"pending","total_count":0,"statuses":null}`, measured on PR #739's head. `read_existing_verdict` gated on `.statuses | type == "array"` and took its `exit 1` path, posting NOTHING. Fail-closed, but the user-visible outcome is the one this issue is about: an exempt PR with no status and, since #743, no bypass. Its double printed `{"statuses": []}` at all three no-verdict sites, so that branch was unreachable in the suite — the same unfaithful-double story as the timeline, one function over. `null` is accepted only when `total_count` is 0, so a body that merely lost its array is still refused and an existing verdict is still protected. Swept `scripts/pr-changed-files.sh` too: `pulls/{n}/files` returns `[]`, unaffected. The generalisable rule is that a nil Go slice serialises to `null`, so every list-shaped field on this API is suspect and only a per-endpoint measurement settles it. A GOVERNANCE SELF-EXEMPTION, reachable again precisely because this change works. `DOCS_ONLY` matched `CLAUDE.md` and `AGENTS.md` — the documents that DEFINE the completion protocol, the merge-consent convention and the H10 rule. Driving the real classify body with a lone `CLAUDE.md` change produced `review-verdict/h10=success`. Protecting `.claude/` while the file specifying what it enforces stayed exemptible is the same self-exemption the header rules out, one directory over. Both added to PROTECTED; `README.md` deliberately not (ordinary prose, no enforcement). FOUR OVER-CLAIMS, corrected rather than defended: * The repo-wide expression test does NOT catch "any payload that cannot evaluate". It checks the HEAD TOKEN of each dotted path. `${{ github.ref == }}` and `${{ …head.sha + }}` pass; so does a renamed output, since tokens after the first are skipped by design. Claim corrected in the docstring, `docs/ci-cd.md` and the record. The test is kept permissive on purpose: a red here blocks every merge. * The strict test's anti-vacuity half banned expressions ANYWHERE outside `with:`/`env:`, so the standard `if: ${{ always() }}` spelling and even a delimiter in an inert top-level comment went red — a guard more dangerous than its target. Replaced with the honest property: the YAML walk saw every `run:` body it declares. * The `if:` assertion demanded the bare `always()` exactly; now normalised, since the wrapped form is identical to the runner. * `exit 1` was matched anywhere in the guard body, so an unreachable `if false; then exit 1; fi` satisfied it while the real branch said `exit 0`. Now required INSIDE the missing-marker branch — and the new behavioural test settles it properly by EXECUTING the guard body both ways. * The record asserted a repo-wide obligation to guard consequential steps. It is not repo-wide: `docker-build.yml`'s `test`/`migrations` are also required contexts and a dropped step there is fail-OPEN (green having done no work), strictly worse than here. Scoped to this file and tracked as #756 rather than asserted as done. Also: comments in both files still said it was unestablished whether a later step runs after a drop — runs 1863/1866 established it, so they now record the measurement; a cited test name that never existed; `kind` leaked to global scope; a mangled comment wrap; and an already-false "one event on page 1". Hardening of my own: `null` now counts as exhaustion only from page 2 ON. Every real PR's first page carries events (4, 2, 9, 5, 10 across #752/#753/#749/#739/#717), so a terminator on page 1 means no page was ever read, and certifying "no retarget" from a response we cannot explain is the one thing the fence exists to refuse. Narrows rather than closes it: a wrong `null` on page 3 still reads as exhaustion. Verification: 137 in this file / 452 total green; ELEVEN mutations each red — reintroducing the defect, deleting the guard, deleting the marker write, removing `if: always()`, `exit 1`→`exit 0`, a delimiter in the guard body, the fence gate (20 red), the TWIN gate (70 red), dropping the governance paths, accepting a null first page, and diverging the marker path between the two steps. Refs: #751 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-06 21:35:56 +02:00
timothyandClaude Opus 5	6b743be988	fix(751): the fence never trusted its count — a page past the end is null, not [] ... The scratch-base probe found a SECOND, independent reason `review-verdict/h10` was never posted automatically. Fixing the dropped step alone would NOT have restored the exemptions. `count_retargets` pages `/issues/{n}/timeline` and trusts its count only on a validated empty page, gated on `type == "array"`. But a page past the end of that endpoint is the JSON value `null` — measured at Gitea 1.27.1 on PR #752, four bytes — so the real terminator read as UNREADABLE. The walk never reached a validated empty page, `rt_ok` was never `yes` for ANY pull request, and the fence therefore withheld EVERY exemption `success`. Renovate and docs-only PRs got no status at all: the same user-visible outcome as the dropped step, by a completely unrelated route. The instance is not consistent between endpoints — `/issues/{n}/comments` returns `[]` when empty — so both shapes terminate the walk now, and the regression test is parameterised over both. The type is read as a VALUE (`case` over `jq -r 'type'`) rather than through `jq -e`, whose exit-status semantics already bit this workflow at jq 1.6 (#647). TWO REASONS THIS LOOKED DELIBERATE RATHER THAN BROKEN, both worth generalising: * It had never run. This fence shipped in 8f6d4f443 — the same commit whose prose comment stopped the classify step executing at all. Merging a guard and first executing it are different events, and only the second tells you anything. * The test double asserted the wrong shape while claiming to be measured. Its comment read "Real shapes, measured on this instance and deliberately mirrored" and it printed `[]` past the end, so the `array`-only gate was never exercised by the suite either. Correcting the double and restoring the old gate turns 18 TESTS RED — every one of them had been green for the wrong reason. A fidelity claim in a double is an assertion and it decays like any other. The new test asserts the POSTED STATUS, not the log: on the real probe run the log said `Decision: state=success` and the job still posted nothing, so the decision and the write are separate events and only the write is what a merge reads. Also here, both found while editing this code: * `ci.verdict-write-retarget-fence` stated this as a narrow residual ("a timeline over the 20-page cap can never be exempted") when the behaviour was universal. Corrected in place rather than left as a checked-looking claim that talks the next reader out of verifying. * The workflow cited `ci.paged-endpoint-completeness`, a key that has never existed as a record anywhere. Repointed at the record that actually owns this walk. Marker hardening from the probe: `RUNNER_TEMP` is `/tmp` on this runner, not a private per-job directory, so the start marker is now keyed on the run id and attempt. The lane starts a container per job today, which makes a fixed name fresh in practice, but that is a property of the lane and a stale marker would make the guard PASS on a run whose step was dropped — the exact silent pass it exists to remove. Verification: 446 passed; M7 (revert only the type gate, keep the corrected double) → 18 red. Probe evidence in the issue. Refs: #751 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-06 20:44:59 +02:00
timothyandClaude Opus 5	17355c61b0	fix(751): a stray expression delimiter in a COMMENT killed the verdict gate ... `review-verdict.yml`'s classify step stopped executing on 2026-08-03 and the job reported `success` anyway, so `review-verdict/h10` — the branch-protection-required status — was posted by nothing but a human hand for three days, and both exemption classes (Renovate-manifest, docs-only) silently stopped working. The cause is one token in prose. The #706 note explaining why a concurrency group does not work here quoted a `concurrency:` snippet containing a PR-number expression as an ILLUSTRATION, inside a shell comment. A shell comment is not inert there: the runner scans the whole `run:` scalar for the expression opener before bash sees it, and one occurrence makes it rewrite the ENTIRE body into a single `format(...)` call. That rewrite is all-or-nothing, so a payload that does not parse — `pr number` does not — fails the interpolation of the whole scalar, and the runner then DROPS THE STEP AND CONCLUDES THE JOB GREEN. The prose documenting a fix disabled the fix. `git blame`/`git log -S` put the line in 8f6d4f443 (2026-08-03), which dates the outage precisely rather than "present in run 1832, not bisected further back". Three changes, deliberately different in kind: * The prose no longer writes the delimiters. It names the expression instead. * The classifier writes a start marker and a new `if: always()` step FAILS THE JOB when it is missing. This is the half that generalises: the delimiter was one bug in one comment, but a dropped step concluding `success` is what made it cost three days behind a green tick. It asserts execution STARTED, never completed — the classifier has several legitimate `exit 0` abstention paths. * Two static guards in scripts/tests/test_pr_changed_files.py: no expression delimiter in ANY `run:` body of the gate file (absolute, because a dropped step here is a dead merge gate and its bodies are ~700 lines of prose), and repo-wide, every expression payload must name a real context or function (permissive, because other workflows interpolate into `run:` legitimately). The second catches the class — a payload that cannot evaluate, wherever it appears. Note every pre-existing workflow-shape test reads `_code_lines()`, which strips comments. That is correct for what it was for, but it encodes the assumption this bug falsifies: inside a `run:` scalar a comment CAN change behaviour. The new strict test reads the raw scalar for that reason and must never adopt `_code_lines`. Blast radius, audited: PR #739 (docs-only) merged 2026-08-05 with ZERO commit statuses on its head, and got in only because admin force-merge was still enabled. #743 disabled that on 2026-08-06, so the workaround that absorbed this bug is gone — the next docs-only or Renovate-manifest PR would be permanently stuck. The two Renovate PRs in the window escaped by timing, merging minutes before the bad commit. Non-exempt PRs were unaffected throughout: humans posted their verdicts by hand. Verification: all six mutations red, restored tree green — reintroducing the exact defect (strict + general tests), deleting the guard step, deleting only the marker write, weakening `if: always()`, turning the guard's `exit 1` into `exit 0`, and putting a delimiter in the guard's own body. 129 passed on the fixed tree. Still to establish, and NOT claimed here: that the runner executes a LATER step after dropping an earlier one. The #751 evidence cannot say — the classifier was the job's last step, so there was never a subsequent step to observe. A scratch-base probe with a negative control answers it next; if the runner drops the rest of the steps too, this guard is inert and the body has to move into `scripts/`. Refs #751 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-06 20:25:26 +02:00
timothy	3aed43c6de	fix(743): make review-verdict/h10 unskippable — disable direct push to main + admin force-merge; fix(719) tag-only push (#749)	2026-08-05 22:58:16 +00:00
timothyandClaude Opus 5	f822e4737c	docs(743): label the second attested claim, close the survivor list, state the rule in CLAUDE.md ... Round 3 returned MERGEABLE with three LOW documentation findings. Batched before posting the verdict, since a new sha voids both the CI run and the verdict. - `ci-cd.md` labelled the unprobed half of the `enable_push` bullet but stated the `block_admin_merge_override` counterfactual flatly one bullet below — the same measured-vs-attested flattening round 2 fixed, one site over. Now labelled, with why it was not probed (verifying it means merging an unreviewed PR). - `release.verdict-status-check` said "what survives is the forgery list above". That record's job is enumerating survivors, so an unqualified "what survives is X" reads as exhaustive — and it omitted the admin residual, which is a SKIP route rather than a forgery one. Added. - `CLAUDE.md` never learned the rule. It is the always-read surface, and it still framed a direct `git push origin main` as a live path while describing a docs-only *push* exemption for a push the server now refuses. My corpus sweep covered `docs/` and missed the file that carries the docs-update rule. Note on what remains unverified rather than closed: neither direction of `block_admin_merge_override` was measured, and whether Gitea treats an ABSENT required context as blocking (versus satisfied) is asserted by our docs but not proven — the combined status on this PR reads `success` with `review-verdict/h10` absent. Both belong to #747's re-verification sweep. Verification: 441/441 script tests; decisions-validate OK. refs #743 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-06 00:35:41 +02:00
timothyandClaude Opus 5	6af65ba5c5	fix(743): re-tense the third stale site, and pin the two surviving mutants ... Round 2 of review. One blocking finding, and it is the same defect class as round 1's: a present-tense claim that this PR falsified. `release.verdict-status-check` — the record ABOUT the h10 status check — still said "direct pushes to `main` are server-side permitted, so the gate can be skipped without forging anything". A reader resolving that key from the catalog would conclude the control does not exist. Round 1 corrected `ci-cd.md` and `ci.actions-credential-scoping` and I stopped at the two sites I had edited, instead of sweeping the corpus by SUBJECT. Swept properly this time (`server-side permitted`, `bypassable`, `without forging`, `push whitelist`, `enable_push`): this was the only remaining stale site. Test gaps the reviewer found by mutation testing, now closed. Both mutants SURVIVED the suite as shipped — the round-1 fixes were correct but unpinned: - dropping `|| [ -n "${_h11_local_ref:-}" ]` → an unterminated final line is dropped. Two directions, and the dangerous one is not the obvious one: a dropped *branch* line leaves only tag refs and grants the exemption to a push containing a branch. Both pinned. - dropping `[ -t 0 ] ||` → the hook hangs forever on an interactive run. Pinned with a real pty and an explicit timeout, so a regression fails cleanly rather than hanging a CI job. Verified the mutant is killed by exactly that test (and that it dies via the timeout, 32s). Also from review, non-blocking: - `ci-cd.md:951` cited `enable_push: false` alone as what closed #743 — the precise thing the new record says never to do, since the force-merge route also skipped the gate with no forgery. Now cites both fields. - `ci-cd.md` flattened measured and source-attested into one 403: only the contents API was probed; the web editor/upload/apply-patch paths share the predicate but were not. Separated. - `format-as-you-touch-rebase` still said "the documented sequence" and "always" for the release-cut behind-ness. `docs/ci-cd.md` documents the tag step, not the release-notes-PR flow, and the frequency is attested by one observed cut. Attributed to #719 instead. - Documented the operator recovery path. `block_admin_merge_override: true` removes the `force_merge` escape that used to unstick a wrongly-red required context — that escape WAS the bypass, so it is gone by design, and the recovery (fix the status; last resort PATCH the field, merge, set it back) needed to be written down rather than left implicit in a residual. Verification: 441/441 script tests; decisions-validate OK; PyYAML parses all 193 records; both mutants confirmed killed and the hook restored byte-identical. fixes #719 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-06 00:10:45 +02:00
timothyandClaude Opus 5	6d80343320	fix(743): close the admin force-merge bypass; the push half alone was not enough ... Independent review found the record repeated on the merge path exactly the mistake it had just diagnosed on the push path. The push argument was: a whitelist naming `timothy` closes nothing, because `timothy` is the identity every credential already holds. The merge path had the identical shape and went unchecked — `block_admin_merge_override` defaults to `false`, so `CanBypassBranchProtection` returns true for a repo admin and `POST /pulls/{n}/merge` with `force_merge: true` merges straight past a missing or red `review-verdict/h10`. One API call, no forgery, no PATCH — cheaper than the push route this change had just removed. So `enable_push: false` alone did NOT make the gate load-bearing, which is what the record's headline sentence claimed. `main` now carries both fields; they are one control and neither is citable alone. An admin-shaped control that exempts the only admin exempts everybody. Other review findings addressed: - H11's owning record (`release.format-as-you-touch-rebase`) now documents the #719 tag-only carve-out. It is a narrowing of an existing convention, so it amends that record rather than adding a new one — including the two details that are easy to regress (the .husky/pre-push forwarding, without which the exemption is dead code the unit tests still pass over; and the at-least-one- ref guard against vacuous exemption). - The record now states which write surfaces were enumerated and how each was established — contents-API refusal is MEASURED here (403 `user cannot commit to repo`), apply-patch/revert/cherry-pick are source-attested only. The admin force-merge bypass is likewise marked source-attested, not probed: probing it means merging an unreviewed PR. - prepush-rebase-check.sh: process a final ref line with no trailing newline (previously dropped, which silently reinstated the #719 block), and skip the stdin read on a TTY so an interactive run does not hang. - Corrected a citation the review caught: docs/ci-cd.md documents the tag step, not a release-notes-PR flow. Cite #719 for the observed flow instead. Also fixed a frontmatter break this round introduced: a `: ` inside the unquoted `rule:` scalar. PyYAML rejected it while the dependency-free reader accepted it, so only `scripts/tests` caught it. Verification: 438/438 script tests pass; decisions-validate OK; PyYAML parses all three touched records. refs #743 #719 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 23:52:28 +02:00
timothyandClaude Opus 5	b91707b707	fix(719): exempt tag-only pushes from the H11 branch-freshness check ... H11 (.claude/hooks/prepush-rebase-check.sh) refuses to push a branch that is behind origin/main. It fired on tag-only pushes too, breaking every release cut: docs/ci-cd.md's "Cutting a release" flow lands a release-notes commit via PR and then tags that merge commit, so the local branch is always one commit behind origin/main at tag time. A tag push cannot revert anyone's merged work, which is the failure H11 exists to prevent, so skip the freshness check when every ref being pushed is under refs/tags/. .husky/pre-push previously consumed pre-push's stdin ref lines and forwarded them only to prepush-donewhen.sh; prepush-rebase-check.sh got none. Forward the captured $_prepush_refs to it too, or the new logic is dead. Guard against the vacuous-truth case explicitly required by #719: "all pushed refs are tags" is trivially true over zero ref lines (manual run, forgotten forwarding), which would silently disable H11 for every push. Require at least one parsed ref line before granting the exemption. Adds scripts/tests/test_prepush_rebase_check_tag_exemption.py using real local git repos (bare origin + a work tree pushed one commit behind it) to exercise git fetch/merge-base/rev-list against a genuinely-moved origin: tag-only allowed, branch-only still blocked, mixed branch+tag still blocked, and zero ref lines still blocked (the vacuous-truth guard). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 23:33:10 +02:00
timothyandClaude Opus 5	691a7acc77	fix(743): disable direct pushes to main so review-verdict/h10 is on the only path to main ... Gitea evaluates `status_check_contexts` when it MERGES a PR. A direct `git push origin HEAD:main` never consults them, so the whole h10 gate was skippable with no forgery — strictly cheaper than every route enumerated in #697. `main` now carries `enable_push: false`. Measured on this instance (Gitea 1.27.1) against a throwaway `probe-743-*` rule rather than against `main`: enable_push: false -> push by timothy (site admin) REFUSED, pre-receive hook declined enable_push_whitelist + ["timothy"] -> identical push SUCCEEDED That second line is why this is a DISABLE and not a whitelist: #743 offered the two as interchangeable, but the only write accounts here are `timothy` (site admin) and `renovate`, and every credential in the threat model — agent sessions, PATs, the injected GITEA_TOKEN — acts as `timothy`. A whitelist naming `timothy` would have ticked the box and closed nothing. Then demonstrated on `main` itself, per the issue's Done-when: a direct push was refused, and a tag-only push from the same worktree succeeded (tags are governed by `tag_protections`, which is empty). The release cut is unaffected. What this closes: the write-only credential routes — the injected GITEA_TOKEN, RENOVATE_TOKEN, any non-admin collaborator PAT. What it does NOT close: an admin credential can PATCH the protection off, push, and restore it. Recorded as an accepted residual rather than implied to be covered. Also corrects two claims the probe contradicted, and one that the mid-session Gitea upgrade (1.25.4 -> 1.27.1) invalidated: - ci-cd.md and ci.actions-credential-scoping both said "a push whitelist would close more of this class than the 1.26 upgrade". The whitelist form closes nothing here; corrected in place. - ci.actions-credential-scoping's rule said "do NOT add a `permissions:` key while this instance is below Gitea 1.26.0". That precondition no longer holds at 1.27.1, so the directive now misleads. Corrected — while noting the consequence is still UNVERIFIED: `/api/v1/settings/actions` 404s at 1.27.1, so whether `permissions:` binds here was not probed. The upgrade alone is not evidence the constraint works. - That record's 1.25.4 measurements are now dated, not current. Flagged as such rather than silently re-pinned to a version they were never taken on. #743's fourth box (docker-build.yml `persist-credentials: false`) is decided in the record and deliberately not done here: two of its checkout steps run `git fetch ... || true` feeding the changed-file skip logic, so a credential regression would be silent rather than loud. Drop the `|| true` masking first. fixes #743 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 23:31:45 +02:00
timothy	08e95f9ec1	fix(697): scope CI's registry credential so head-resolved workflows cannot forge review-verdict/h10 (#745) ... Closes the credential half of #697. `REGISTRY_PASSWORD` was the admin account's basic auth, handed to head-resolved PR code by docker-build.yml; it is now a PAT scoped `write:package` + `read:repository`. Verified on Gitea 1.25.4: registry push SUCCEEDED, status GET 200, status POST REFUSED 403 (required=[write:repository]). Does NOT close the class. Surviving routes, all recorded: RENOVATE_TOKEN (#742), the injected GITEA_TOKEN (server-management#714), a collaborator's own token, the `v*` tag push, and — making all of them unnecessary — direct pushes to `main`, which are server-side permitted (#743). ci-image.yml's trigger filter was attempted, reverted, and split out as #744. Three cold adversarial review rounds: BLOCKED, BLOCKED, BLOCKED, then MERGEABLE. fixes #697	2026-08-05 19:56:52 +00:00
timothyandClaude Opus 5	b91939e5c4	fix(697): correct the overclaims three adversarial review rounds found ... Round 1 BLOCKED (1 Blocker, 4 High, 3 Medium, 2 Low); round 2 BLOCKED on the fix (1 Blocker, 2 High, 4 Medium, 2 Low); round 3 BLOCKED on one Medium. Every finding re-verified against the live instance before acting. ROUND 2 — the blocker was self-inflicted and the local gate could not see it. Adding `branches: [main]` to ci-image.yml re-points `ci-image-pin`'s `expected` at the editing commit, staling all five `container:` pins and failing that BLOCKING job — for a change altering zero bytes of the toolchain image. Reproduced: expected=ed9dd6254 vs pins=32747a0. Reverted here (the commit was amended, so no commit on the branch touches that path) and filed as #744. That edit had also FALSIFIED its own justification: branch publishing IS load-bearing — docs/ci-cd.md documents the rebase-recovery flow as "let ci-image.yml publish :<short sha>, then bump the pin", which is how you satisfy ci-image-pin from inside a PR. Reverting also keeps three trigger descriptions true (ci-cd.md:1043, the recovery flow, pr-checks.yml's escape-hatch comment). Also fixed: - gate-trigger-base-resolved.md was the file round 1's fix did not touch, and still said "no workflow route retains human provenance" — false, since a PR-added workflow can reference RENOVATE_TOKEN. Its `rule:` also kept the race framing, and `rule:` is what the catalog and MemPalace mirror. - `mechanics:` claimed "independent review confirmed no CI consumption breaks". It confirmed no such thing. Round 3 then caught the REPLACEMENT sentence making the same class of error: only the `container:` pull is exercised by a PR, because `build` carries `if: github.event_name != 'pull_request'` and cache-to/cache-from live only there. Those and the base-image pull first run on the post-merge push to main — a wrong inference reddens main, not the PR. - A fourth surviving route was unnamed: docker-build.yml publishes :prod from a `v*` tag push and a tag may point at any commit (tag protections are empty). "three surviving routes" became "at least these" — a count reads as complete. - Unmarked inferences, a "three later sections" that undercounted four, a dangling "the two items below", and a #744 rationale that stated the pin toll without its documented remedy. Local gate: 432 script tests pass; `decisions_validate.py --base origin/main --head HEAD` and `build_decisions_catalog.py --check` both exit 0; ci-image-pin recomputed by hand and matching the pinned commit. The record is 62 prose lines against a 60-line ceiling that is a `::warning::` by design (#520) — the blocking constraint is the 2-25% minority band, currently 10.8%. Refs #697, #742, #743, #744. Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 21:23:43 +02:00
timothyandClaude Opus 5	e298bb291e	fix(697): scope CI's registry credential so head-resolved workflows cannot forge review-verdict/h10 ... `REGISTRY_USER`/`REGISTRY_PASSWORD` were the ADMIN account's basic auth, and `docker-build.yml` triggers on `pull_request` — head-resolved — so a PR's own code was handed instance-admin credentials. Basic auth carries no scope, so the same secret that pushes an image administers every repo on the instance and can POST `review-verdict/h10`, the required context that makes merge-consent derived rather than assertable. Refs #697. Fixed at the credential, not the triggers: patching triggers enumerates instances of "a ref-resolved workflow obtains status-capable credentials", and adding a new workflow file is itself a route. `REGISTRY_PASSWORD` is now a PAT scoped `write:package` + `read:repository`. Verified on Gitea 1.25.4, not inferred: - registry push of a probe tag SUCCEEDED (cleaned up, confirmed 404) - GET /commits/{sha}/status SUCCEEDED (what ci-detect-already-validated.sh does) - POST /statuses/{sha} REFUSED, HTTP 403: required=[write:repository], token scope=write:package,read:repository Scope of what this closes, stated without overclaim. It closes the instance-wide admin escalation and that credential's durable forgery route — durable because a status POSTed with a USER credential carries a real `creator` and is inherited as a human verdict, while an Actions job's carries `creator: null` and is re-derived. It does NOT close the class. Three things survive it: - `RENOVATE_TOKEN` is a `write:repository` PAT of a real bot account in the SAME secret store, so it also posts with non-null `creator`. It cannot be scoped down (Renovate needs repo write), and secrets are a per-repo store that any PR-added workflow can reference. Closing this needs the provenance check tightened to an allow-list of approved reviewers. - Every job still receives a write-capable `GITEA_TOKEN`. `permissions:` YAML is a no-op before Gitea 1.26.0 and no `app.ini` lever exists at any version; only >=1.26 with the Actions default set to Restricted binds it. Tracked in server-management#714. - Branch protection binds the context NAME, not its issuer, so any write-scoped personal token forges the status with genuine human provenance. Unfixable in-repo. `h10` is a process guard, not a security boundary against push access. Auditing the secret STORE rather than the workflow set also surfaced `SERVERMGMT_DEPLOY_KEY`, still present though the `bump-prod-compose` job that used it was removed in 1b5efd7b9 — an SSH deploy key to another repo, obtainable by any PR-added workflow, with no remaining benefit. Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 20:34:34 +02:00
timothy	d7647b6104	fix(685): AddItemsDialog resolves by search instead of windowing the whole media-library type (#741)	2026-08-05 18:01:59 +00:00
timothy	7be42654fe	fix(685): suppress both empty-states on error; name the addable-kind derivation ... Round-4 verification returned MERGEABLE with no new defects and no BLOCKER/HIGH/MEDIUM. These are its remaining LOW and nits. - "No results — try a search above." asserts a search that COMPLETED and found nothing, so it was false beside a failed request. Both empty-state messages are now suppressed on error and the role="alert" banner is the whole message, as that test's comment already claimed. Pinned positively and negatively so a refactor cannot satisfy the assertion by rendering nothing at all. - The (typeof ADDABLE_TYPE_LIST)[number] derivation is now the named AddableKind, spelled once instead of twice: a third ingress into the searched kinds is most likely to be written by copying one of the existing two, and the "one list, all ingresses" property should be visible at a glance rather than reassembled. - The §3b lesson cited two measured test counts, which go stale against the very suite they describe — a count taken before the helper had unit tests no longer holds now that it does. Scoped the observation to the sha it was measured on and replaced the counts with the invariant they were evidence for: every gate needs at least one test that reddens when that gate ALONE is removed. - Documented why the error banner stays conditionally mounted while the hint's live region does not: role="alert" is the one live-region role screen readers reliably announce on insertion, so the two are correct for opposite reasons. The review flagged the divergence as unexplained, not as wrong. refs #740	2026-08-05 19:40:07 +02:00
timothy	d7725c274c	fix(685): close the second ingress; stop the error path claiming a short query ... Verification round returned MERGEABLE with all three blocking findings resolved by measurement. These are its four remaining items. - DEFAULT_SEARCH_KINDS was the SECOND ingress into the searched kinds and was not derived, so the previous commit's "enforced by the type system" claim held for one of two paths. A non-addable kind there typechecked clean and would have overstated the hint with every one of its rows dropped — the exact defect the derivation exists to prevent. Now derived; verified by mutation that adding 'Collection' to it is a compile error. - The error path fell into the min-query guidance branch, so a valid 2-character query that got a 500 told the user to type at least 2 characters. That branch conflated "nothing searched yet" with "the last search failed". Newly introduced by the previous commit's error-path reset; now gated on !error and pinned by a test. - The aria-live region was mounted conditionally, creating the region and its text in one commit — which most screen readers do not announce. It is now mounted unconditionally with the condition inside. - The §3b lesson mis-stated where the duplicate gate lived: it was inside runSearch, the genuine single sink, NOT at one of the callers — so the rule as written ("put the gate in the single sink, not at each caller") described the revision that was rejected. Reworded to the actual lesson: the gate's home is the shared helper, and "it's the single sink" is not evidence it is the only guard. That misreading is why #685 got this wrong twice. Declined again, with reasons: the NaN pageSize edge (faithful to the sibling helper), the clamp test's unpinned lower bound (same), and the registry's disclosed same-identity substitution gap. refs #740	2026-08-05 19:20:26 +02:00
timothy	b6bf94f129	fix(685): test the helper's bound; delete the masking duplicate gate ... Independent review round 2 returned BLOCKED on two findings, both correct. - The helper's bound was dead code to the suite. searchLibraryBrowseItems had zero tests, so deleting its clamp OR its gate left the whole suite green — while the registry note claimed a caller "cannot skip the bound". That is the previous round's finding relocated, not removed. It now has the three tests its sibling searchLibraryPickerOptions already had (clamp, gate, compile), plus one pinning the full-row return that is its reason to exist. - The screen kept a second copy of the min-query check, and the two masked each other: the 1-character boundary test passed with EITHER gate alone, so it pinned nothing. The screen's copy is deleted; the helper is the sole gate. Measured before/after: with the duplicate present, removing the helper's gate left that test green; with it gone, the same removal reddens it. - §3b contradicted itself two lines apart — the parent still said "there is no truncation, so there is no truncation hint" above a sub-bullet mandating one. Reworded so a hint is permitted, required only where bulk selection makes the count actionable. Same correction to the 'search-bounded' definition. - A failed search left results/totalMatches stale, rendering a confident "Showing 75 of 60000 matches" beside the error banner. The catch clears them. - Results now carry a `Results for "<query>"` heading and the guidance is keyed to the settled query, not the live input, so rows are never shown without saying which search produced them. `selected` persists across queries (correct for a multi-select picker); the Add button's count keeps it discoverable. - The hint sums pre-filter totalCount against post-filter rows, which is only correct because every filterable kind is addable. MediaKindFilter is now derived from ADDABLE_TYPE_LIST, making that a compile error rather than prose. - aria-live on the hint; the #740 doc caveat no longer overstates the typeahead rule as a mandate this screen violates. Declined: the NaN pageSize edge (copied faithfully from the sibling helper) and the registry's same-identity substitution gap (already disclosed in that file). refs #740	2026-08-05 19:08:13 +02:00
timothy	4be3f247d8	fix(685): move the picker bound into the helper; surface the per-kind cap ... Independent review round 2. Verdict was MERGEABLE with no blockers; this takes the two recommended fixes plus the structural one it listed as a follow-up. - The bound was caller discipline, not code: getLibraryBrowseItems does not clamp pageSize, so the bound was only the constant this one call site chose to pass, and §3b is explicit that a bound a caller can exceed is not a bound. New searchLibraryBrowseItems in libraryBrowse.ts owns the min-query gate, the pageSize clamp and the titleContainsQuery compile, returning full LibraryBrowseItem rows plus totalCount (searchLibraryPickerOptions' {id,name} shape loses the mediaType that toAddItemsRequest needs). runSearch keeps one early return, for the spinner only, and no longer re-implements the gate. - The min-query guidance was keyed to the LIVE input, so backspacing below the gate after a search wiped the rendered rows and their checkmarks while `selected` and the Add button still counted them. Keyed to results.length too. - "Nothing left to hint at" was false: each kind is still capped at LIBRARY_PICKER_RESULTS and totalCount was never read. This is a bulk multi-select add, so the cap is surfaced — per-kind totalCounts are summed and rendered as "Showing N of M matches" once it exceeds the rendered rows. The registry note and the §3b bullet are corrected to stop claiming otherwise. - Gate boundary tested at 1 character (§3b: inclusive endpoints, or a > for >= slip passes the whole suite). - The guard test's deviation loop iterates an empty list now, so it gains one bidirectional assertion that is non-vacuous: the set carrying an `issue` field must equal the set classified 'deviation'. - The §3b bullet no longer reads as a conformance certificate: AddItemsDialog still lacks the seqRef and useIsMountedRef guards §3b mandates. That defect is PRE-EXISTING, not introduced here, and is tracked in #740. refs #740	2026-08-05 18:46:43 +02:00
timothy	28ce8c4dfe	fix(685): gate AddItemsDialog on a real query instead of windowing the whole type ... AddItemsDialog.runSearch was reachable with an empty query two ways — a blank form submit, and a kind-chip click, which called it immediately — and getLibraryBrowseItems omits a falsy `query`, so each path degraded into an unfiltered browse of the whole media-library type (first 50 rows, per kind) presented as the answer with nothing surfacing the truncation. All ten ADDABLE_TYPE_LIST entries are spa-conventions §3b Class B media-library types. The dialog is multi-select, so §3b's SearchPicker (single-select) does not fit; it takes §3b's constraints instead: - no request below LIBRARY_PICKER_MIN_QUERY, enforced in runSearch — the single sink both entry paths route through, not duplicated per caller - typed text compiled with titleContainsQuery rather than forwarded raw (a second latent §3b violation here: the search index's default field does not match bare title words) - each kind bounded to LIBRARY_PICKER_RESULTS - merged.slice(0, 50) removed — it silently dropped up to 100 of 150 fetched rows even for a real query Tests assert zero requests below the gate on both paths, exactly one bounded request per kind above it (20k-row fixture), the compiled+escaped query, and that no fetched row is dropped. Each was verified to fail with its mechanism removed. The pageSize registry entry moves from `deviation` to `search-bounded`. That leaves zero deviation entries, so the anti-vacuity assertion guarding that list is deleted deliberately, per its own instruction. Done-when box 4 (collection-family truncation hint) has no subject: this screen offers no collection-family type. fixes #685	2026-08-05 18:46:43 +02:00
timothyandClaude Opus 5	e46e2cfe68	docs(skill): Dispatcharr EPG refresh ssh'd to the wrong host ... The refresh_epg_data command targeted 192.168.1.99, but Dispatcharr moved to jazz (192.168.1.29) in #634 — it would fail with 'No such container'. refs server-management#692 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 18:35:38 +02:00
timothy	3a6174c953	Merge pull request 'docs(release): record the v26.14.0 release notes' (#739) from release/v26.14.0-notes into main ... Reviewed-on: #739 v26.14.0	2026-08-05 06:13:22 +00:00
timothy	5fa672e2e5	docs(release): record the v26.14.0 release notes ... Adds the v26.14.0 row to the release table. This is the commit the v26.14.0 tag will be pushed onto, matching how v26.13.0 was cut (#716). Contents since v26.13.0: the #726 bitmap-subtitle -readrate starvation fix (headline), the #674/#688 decisions-validator PyYAML cross-check, the #706/#707/#711 review-verdict raced-sentinel fix, and two Renovate bumps. Replaces the branch behind PR #738, which never received a pull_request CI run across six trigger attempts (two pushes, a force-push after rebase, a close/reopen, a body edit, and a spaced push on an idle queue). A workflow_dispatch run did complete green but writes no commit statuses, so it cannot satisfy the required checks. Opening a fresh PR produces an `opened` event rather than a synchronize, which is a different path. No [skip ci] token -- this branch's merge commit is the v26.14.0 tag target.	2026-08-05 00:44:00 +02:00
timothy	a2b3a56d93	Merge pull request 'fix(674,688): cross-check decision frontmatter against PyYAML; split the ceiling calibration claim' (#725) from fix/674-688-decisions-validator into main	2026-08-04 21:43:10 +00:00
timothy	772277e255	Merge pull request 'fix(726): let a lagging realtime input catch up so a sparse bitmap-subtitle stream can't pin it below realtime' (#737) from fix/726-readrate-catchup into main	2026-08-04 21:24:11 +00:00
timothyandClaude Opus 5	efc34a3481	fix(688): pin p95's inclusivity; drop a stale ratio and hedge the gap width ... Round 7's second reviewer returned MERGEABLE on the previous head after re-measuring every figure and running a 48-mutant battery — and reported ZERO wrong or unverified numbers, which ends this branch's five-commit streak of them. It also independently confirmed the round-6 adjudication: at `f394d6ce`, the sha the record cites, the #620-era distribution really is n=167, min 2, median 26, p90 52, next value 83. All five figures correct as written. This commit clears its four non-blocking items. - `marks_tail`'s UPPER inclusivity was the last meaningful surviving mutant: `ceiling <= p95` mutated to `<` survived the whole suite. Notice-only rather than blocking, but an unpinned boundary is how a documented claim quietly stops being true — the same defect the previous commit fixed for the coarse band. Both ends now pinned; verified the mutant fails. - "the largest by ~1.6x" was TRUE at `f394d6ce` (230/147 = 1.56) and is stale today (230/198 = 1.16). Unlike the consolidation table two paragraphs down, that sentence was never scoped to a sha — so rather than re-pin a number that will rot again, it now just says "the longest", which stays true however the tail moves. - The validator docstring asserted the 60->81 gap flatly; a 70-line record existed as recently as `8f6d4f443^`, so the gap's WIDTH is more volatile than that implied. Hedged to say it is the shape as measured today, not a constant. Nothing asserts it either way. - Rewrapped a mid-sentence line break left by the previous commit. Three surviving mutants are accepted and left: the crosscheck's not-a-mapping branch is unreachable from any fixture, the None -> "" normalisation only matters for an explicit YAML null no record has, and `_frontmatter_block` returning "" instead of None is a downstream no-op. Verification: 432 scripts/tests pass; ruff at baseline parity (47, and `ruff format --check` at parity 9/9); validator exits 0 with no drift notice; corpus at p90=60, 18/183, calibrated. Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-04 23:07:15 +02:00
timothyandClaude Opus 5	57ad5efb3f	fix(726): quote the decision record's rule: so PyYAML doesn't truncate it ... `PR Gates / Script tests (pytest)` went red on test_frontmatter_reader_matches_pyyaml_on_every_real_record. The rule: value was an unquoted YAML plain scalar containing " #350's exclusion", and an unquoted " #" starts a YAML comment -- PyYAML truncated the whole rule at "(mirroring", so the catalog row and the mirrored MemPalace drawer carried half a sentence. The hand-rolled frontmatter reader used by scripts/decisions_validate.py does NOT tokenize comments, so it read the full line and reported OK; only the script-tests job, which cross-checks the two parsers against every real record, can see this class of defect. That is exactly what it exists for. Fixed by single-quoting the scalar (doubling the internal apostrophe in "image''s") and dropping the possessive from "#350's exclusion" so the token is plain "#350". Verified both ways: PyYAML now returns the full sentence ending "...race ahead.", and reverting the quoting reproduces the red, so the fix is what makes the test pass rather than the test being insensitive. Follow-up commit rather than an amend -- 56afa4652 is already pushed. Refs #726 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-04 22:59:10 +02:00
timothyandClaude Opus 5	0ff9671393	fix(688): pin the minority band's constants and inclusivity; two prose corrections ... Review round 7. Its adjudication of the round-6 dispute went the branch's way — measured at `f394d6ce`, the sha the record actually cites, the #620-era distribution is n=167, min 2, median 26, p90 52. Round 6 had measured `fefd11dff` (p90 57), a different tree. The number stays as written. BLOCKING FINDING: the 2%/25% constants and their inclusive boundaries were not pinned at all. Mutating 0.02 -> 0.03, 0.25 -> 0.30, or either `<=` to `<` passed all eight calibration tests. Those are not free parameters — they ARE the documented CI-red thresholds, so a silent shift would quietly falsify the 38/718 figures in docs.corpus-size-signal and docs/ci-cd.md (a strict cap reds after 37 long additions, a strict floor after 717 short ones). test_the_minority_band_BOUNDARIES_are_exactly_where_documented pins all four. It uses 100-record fixtures so k over the ceiling IS k%, and both 2/100 and 25/100 are exactly representable and compare equal to the constants — true boundary cases, not near-misses. Verified by mutation: all four now fail it. PROSE - corpus-size-signal said what stays blocking is "what routine growth cannot break", immediately before explaining that 38 routine additions break it. Now "what no SINGLE ordinary addition can break", which is what is actually true. - docs/ci-cd.md said the fine claim is "never asserted"; it is never asserted AGAINST THE LIVE CORPUS, and IS asserted on synthetic distributions the tests own. Corrected — the distinction is the whole design. Correction to an earlier commit message in this branch (9d2b30dc3, already pushed, so recorded here rather than rewritten): it said the cross-check was clean on "all 183 real records". 183 is the active keyed-record count; the cross-check scans the record WINGS — 195 files at that commit, 190 of them carrying frontmatter. The check was clean; the figure named the wrong population. Verification: 432 scripts/tests pass; ruff at baseline parity (47); validator exits 0 with no drift notice; corpus at p90=60, 18/183, calibrated; new record still 60 lines. Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-04 22:52:03 +02:00
timothyandClaude Opus 5	56afa4652d	fix(726): let a lagging realtime input catch up so a sparse stream can't pin it ... -readrate throttles an INPUT and paces it off whichever of its streams is furthest behind. An embedded bitmap subtitle (PGS/DVD) is read through the same -i as the video -- SubtitleInputFile carries the video's path and ComplexFilter resolves it to a stream specifier on that input, so CommandGenerator never emits a second -i for it. Being sparse, that subtitle stream falls further behind every second and drags video throughput down with it: measured 0.53x realtime against the 1.0x a live client consumes at, which drains the client buffer until it stalls. FFmpeg names the culprit itself at -loglevel warning: [sist#0:3/dvd_subtitle] Resumed reading at pts 10.400 with rate 6.000 after a lag of 0.922s (then 1.24, 1.56, ... 3.80) Add -readrate_catchup (6.0) to realtime video/audio inputs, capability-gated through FFmpegKnownOption.HasOption exactly as -readrate_initial_burst is, so a binary without it silently keeps today's behavior instead of failing to start. The option first shipped in ffmpeg 8.0, which is NEWER than 7.1 -- hence runtime detection rather than a version assumption. Still images and concat inputs are excluded, mirroring #350. Measured on prod (QSV, -threads 1, dvd_subtitle -> overlay), 45s steady-state window after a 6s settle, replaying the captured production command line: baseline 1.05 0.533x (x3 runs) + catchup 2.0 0.711x + catchup 6.0 1.067x (x2 runs) + catchup 20.0 1.067x no subtitle overlay 1.067x (control) Baseline reproduces the reported 0.53x and the control the reported 1.07x, so the harness is validated on both sides. Reproduces on software libx264 too (0.533x -> 1.067x), as expected for an input-pacing option. Raising the base -readrate is not an alternative and was measured: 2.0 -> 0.62x, 3.0 -> 0.80x, 4.0 -> 0.80x, 6.0 -> 0.89x -- it asymptotes below realtime because the rate ceiling was never the binding constraint. On #529 (readrate was incidentally bounding QSV hardware-frame allocation): the 20.0-vs-6.0 row is why 6.0 was chosen, NOT evidence about allocation -- it is a steady-state throughput number, not a count of frames in flight. Nor is the bound safe because read rate is allocation-irrelevant: #529 measured that it is not (at extra_hw_frames=0, 1.05 without a burst exits 0 while 1.05+burst hits ENOMEM). Read rate changes how fast frames enter the graph, not how deep its queues are, and #529's failure only appeared with NO pool headroom. The 64-frame floor now guarantees headroom, so the load-bearing measurement is row 5 of that truth table -- no -readrate at all with 64 frames -> 14 segments, exit 0 -- and a 6x ceiling is strictly less aggressive than no throttle. Reinforcing it, -readrate_initial_burst 8 has read flat out at the start of every playout item since #350, so an unbounded read here is not new. A 240s QSV soak at QsvExtraHardwareFrames=64 across 60 segment boundaries corroborates: 1.043x sustained, zero "Cannot allocate memory" / "Could not open encoder", RSS 166MB vs 156MB at baseline -- corroborates rather than demonstrates, since it stayed largely caught up. Catchup does NOT subsume the #350 burst; measured time-to-first-segment: -readrate alone 3.71s, +burst 0.72s, +catchup alone 3.65s, both 0.67s. They fix orthogonal metrics. The regression test is built on a BITMAP subtitle deliberately -- a text subtitle is fetched by the libass filter outside the demuxer, so the same assertions would pass vacuously while the bug is fully present. It asserts on the "[0:0][0:2]overlay" label, which is the mechanism: subtitle stream 2 resolving onto the video's input. Every new test was mutation-checked, each producing exactly its own expected red. Fixes #726 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-04 22:50:09 +02:00
timothyandClaude Opus 5	2ff52d4236	fix(688): make the n oracle dynamic; correct a tense that asserted false history ... Review round 6: one MERGEABLE with non-blocking prose, one NOT-MERGEABLE with a real test defect. Both addressed. THE n PIN DID NOT PIN ANYTHING. `assert n == 10` was checked against a fixture holding exactly ten records, so a mutation returning a constant 10 for EVERY input satisfied it — while changing the live denominator from 183 to 10, which is precisely the production defect the test was added to close. A single hardcoded count cannot tell "counts the input" from "returns this number". Now a dynamic oracle at two distinct cardinalities; verified the constant-n mutation fails it. "MOVED p90 by 21 lines" asserted a history I had not measured. 21 is TODAY's gap (60 -> 81). The actual #672 event was smaller — at that tree p90 was 60 with the next value 83, so the 62-line record moved p90 to 62 and reddened CI with a 2-line move. The capability claim is what matters and is true at both refs; the past tense was not. Changed to "can move" in the two places that asserted it, which also makes all four sites agree with docs/ci-cd.md and the validator docstring, both of which already said "could". A REVIEW FINDING I REJECTED, having measured it. Round 6 called "p90 52" wrong for the #620-era distribution, measuring 57. That measurement is at `fefd11dff`; the record cites `f394d6ce`, and at THAT sha p90 is exactly 52 (n=167, min 2, median 26). The number is correct as written and is unchanged. Recording the disagreement rather than silently keeping it: the reviewer measured a different tree than the one the claim names. Also corrected in this branch's own commit message trail: `b24c51ab5` said origin/main has three 59-line records; it has four 59s and two 60s (HEAD: four and three). The claim that survives, and the only one the code and docs now make, is that NOTHING sits between 61 and 80 at either ref — verified independently at both. Cosmetics from the same round: a dangling modifier in ceiling_calibration's docstring, a test_decisions_lib assertion message that said "field(s) differ" when faults can now also be rejections, and a sentence in corpus-size-signal that named the replacement test without saying what it asserts. Verification: 431 scripts/tests pass; ruff at baseline parity (47); validator exits 0 with no drift notice; corpus at p90=60, 18/183, calibrated. Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-04 22:35:00 +02:00
timothyandClaude Opus 5	b24c51ab51	fix(688): stop enumerating multiplicities, pin n and the keyless filter, de-couple the vacuity floors ... Review round 5. One reviewer returned MERGEABLE with prose findings; the other found four more, two of them real test gaps. Both are addressed here. THE MULTIPLICITIES WERE WRONG AGAIN — fourth commit running. The "measured" sequence 59, 59, 60, 60 -> 81 is measured nowhere: origin/main has 59, 59, 59, 60, 60 and HEAD has four 59s and three 60s. I had even tagged it `(measured)` in a canonical decision record. So this stops enumerating them. All four sites now state only the load-bearing, stable fact: the lengths climb to the ceiling and then jump STRAIGHT to 81 with nothing in between, so one record moves p90 by 21 lines. The multiplicities change with every record added; the gap is the point. This is the same "fix the boundary, not the site" move the tests got three rounds ago, applied to prose that had failed four times. TEST GAPS - Deleting the over-tight test removed the only pin on CeilingCalibration.n: a mutation returning n=1 passed all 19 relevant tests while printing a wrong denominator in the drift notice. Pinned. - The `if r.key` filter was load-bearing in production and unpinned: main() passes the UNFILTERED list (194 entries, 11 keyless, one a 106-line "Records formerly in this file" scaffolding block), while every test handed the function a pre-filtered list — oracle and production agreed only by accident. Pinned. - The --record-ceiling 0 arm's claim that it "cannot go vacuous for any non-empty corpus" was FALSE: an empty record body is validator-valid and record_prose_lines returns 0, so a corpus of empty-bodied records has no offender at 0. Now -1, which makes the claim true. - The three `len(recs) > 100` vacuity floors were themselves growth-coupled — 83 legitimate retirements would red them even with the ceiling still calibrated, which is the #688 class in the guard rather than the assertion. Lowered to >20 where a floor is meaningful, and to plain non-empty on the derived-ceiling test, whose derivations need nothing more. - test_main_FEEDS_the_crosscheck now compares against `set(record_wing_files())` instead of a hardcoded basename, killing the same mutation with zero corpus dependence. PROSE - "ordinary growth cannot cross it — NOT immune" contradicted itself in four places. Now: no SINGLE ordinary addition can cross it; this is measured headroom, not immunity. - "trimming or archiving 15" blurred two different denominators. Trimming leaves 3/183 = 1.64%; archiving leaves 3/168 = 1.79% because the denominator moves too. Both verified, both under the floor, now stated separately. Verification: 431 scripts/tests pass; ruff at baseline parity (47 — a 121-char docstring line briefly took it to 48 and is rewrapped); validator exits 0 with no drift notice; corpus at p90=60, 18/183, calibrated; record still 60 lines. Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-04 22:11:25 +02:00
timothyandClaude Opus 5	c56dfdd539	fix(688): delete the last over-tight test, pin the crosscheck's INPUT, fix 4 prose defects ... Review round 4, both reviewers. Both report the code path SOUND and the #688 coupling class analytically gone (rows proved, not merely observed green); one caught 28 of 30 mutations. What blocked was one over-tight test, two unpinned mutations, and prose — including two defects the PREVIOUS commit introduced while claiming to fix numbers. TESTS - Deleted test_adding_ordinary_records_cannot_RED_the_blocking_property. It appended two long records to the LIVE corpus and asserted flags_minority on the RESULT, so it crossed the cap two records before production does (56/221 vs 54/219) — a test named "cannot RED the blocking property" being a tighter tripwire than the property. Fourth instance of the #688 defect in this change. Deleted rather than tuned: both its jobs are already covered off live data (the synthetic v4/v5 contrast, and the deliberate live guard at the production threshold). - test_main_FEEDS_the_crosscheck_the_REAL_wing_files closes a mutation hole found by review: replacing `pyyaml_frontmatter_faults(record_wing_files())` with `...([])` in main() left the ENTIRE suite green. Both existing wiring tests monkeypatch the function, so they pinned that its RETURN reaches errs, never that its ARGUMENT is the corpus — the '#609 marker that printed OK while doing nothing' defect one level up, which is the exact thing the new record indicts. Verified: the mutation now fails this test. - test_main_actually_REPORTS_... went vacuous whenever the ceiling legitimately goes green (`False is False` passes with the whole warning branch deleted). Added an arm at --record-ceiling 0, which no non-empty corpus can make vacuous. - Pinned two surviving mutations: ceiling_calibration's n_over boundary (it recomputes the count, so oversized_records' exclusivity test does not cover it — `>` vs `>=` differs by the 3 records sitting exactly on the ceiling) and p95's quantile (the 95/5 fixture cannot tell 0.95 from 0.99). PROSE — two of these were introduced by the previous commit, whose stated job was fixing numbers. That is the pattern worth naming, not the individual typos. - "so ONE new record could move p90 lines" — the previous commit deleted the magnitude and left the sentence ungrammatical. Now "by 21 lines". - It also introduced a THIRD variant of the sequence it was correcting ("60, 60, 60") and missed a FOURTH site in ci-cd.md still saying "twenty lines". All four sites now read the measured 59, 59, 60, 60 -> 81, and 21 lines. - 59- and 60-line records were described as "above the ceiling"; they are at or below it. - "routine growth cannot cross it" overstated the bound: it is deliberately less sensitive, not immune. Reworded, and the THIRD and tightest arm is now documented wherever the other two appear: consolidating 15 of the 18 offenders drops below the 2% floor (verified: 3/183 = 1.64%). That is in real tension with test_oversized_records_can_go_green and is stated as accepted — at 3/183 the constant genuinely is mis-calibrated — with the remedy named: a consolidation PR that large should re-derive the ceiling in the same change. - Corrected a docstring that called the 999-ceiling failure "silently deleting the assertion"; it would go red, not silent. Verification: 430 scripts/tests pass; ruff at baseline parity (47); validator exits 0 with no drift notice; corpus at p90=60, 18/183, calibrated. The two new claims were measured, not assumed: the empty-list mutation fails the new test, and 15 consolidations reaches 1.64%. Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-04 21:47:24 +02:00
timothyandClaude Opus 5	0db56c3ebd	fix(688): remove the last live-corpus tripwires and three fabricated/wrong numbers ... Review round 3, both reviewers, NOT-MERGEABLE. Nothing needed rework — the code path was found sound and mutation-sensitive (a 17-mutation battery caught every mutation with the semantically correct test). What was left were tripwires and prose. TRIPWIRES - `assert need > 20` was the tightest live-corpus assertion left in the blocking job: it reds after 16 over-ceiling additions, while `flags_minority` — the property #688 exists to protect — survives to 36. An arbitrary threshold on a live order statistic is the ratchet wearing a different hat. Removed; the measured headroom lives in prose, where being out of date costs a doc fix rather than someone else's red build. This also removes an unbounded `while` loop that HUNG the suite rather than failing it when the ratio could not reach the cap. - test_main_reports_ceiling_drift hardcoded ceiling 999, which is not guaranteed above p95: ten valid 1000-line records make 999 calibrated and silently delete the test's only assertion. Now derived as max+1, off the tail by definition. - test_main_actually_REPORTS_the_ceiling_and_the_trend required >=1 over-ceiling record. The ceiling is ALLOWED to go green (test_oversized_records_can_go_green says so), so that would red the blocking job the day someone consolidates the last offender — punishing exactly the work the warning asks for. Restated as an IFF. - test_no_budget_flag_means_no_retirement_warning asserted no bare "RETIRED" in stderr; a legitimate stale record whose TITLE contains the word reds it. Matched precisely now. - Added the >100-record vacuity guard its siblings carry to the derived-ceiling test. NUMBERS — all three were mine, and two are the failure mode this repo calls worse than no note at all (a confident claim that was never measured): - "the lengths above the ceiling ran 60, 61, 62, 63 then jumped to 81" is FABRICATED. No record of 61, 62 or 63 lines exists at origin/main, at the #672 sha, or at the #706 sha. Measured, the sequence is 59, 59, 60, 60 then 81 — a 21-line jump, so the conclusion was if anything understated. Corrected in all three places it was repeated, including the canonical v4 row of docs.corpus-size-signal. - The crosscheck record called `decisions-guard` a REQUIRED check — introduced by the previous commit in the sentence rewritten to fix an overclaim. Verified against Gitea branch protection: `main` requires exactly `Build & test (.NET)`, `EF migration integrity` and `review-verdict/h10`. NEITHER script-tests NOR decisions-guard is required; the record now says so. - docs.corpus-size-signal said 37 additions "to reach" the cap two paragraphs above 38 "below the cap" — a same-document numeric inconsistency of exactly the class this change set out to remove. Both now state 38 to BREACH, noting 37 lands on 0.25 and passes. - Also: the old bound's accepted range is 39..229 (not 43..229 — 43 is the NEW bound's lower edge); "95% over the ceiling" was 100%; `oversized_records` said the #620 distribution began at 0 lines where the record itself says 2. Verification: 428 scripts/tests pass; ruff at baseline parity (47); validator exits 0 with no drift notice; corpus at p90=60, 18/183 over the ceiling, record trimmed to 60 lines so main ships calibrated. Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-04 21:26:52 +02:00
timothyandClaude Opus 5	b3a8826281	fix(688): stop asserting live-corpus order statistics anywhere in the suite ... Review round 2 (both reviewers, independently) found the round-1 fix incomplete: the live-corpus coupling survived in two more tests. This is the THIRD instance of one defect class in this change, so the fix is to remove the coupling rather than patch another site. BLOCKER — test_adding_ordinary_records still asserted live order statistics. The `if before.marks_tail:` guard made the PRECONDITION conditional but left the CONCLUSION (`assert not after.marks_tail`) an assertion about the live p90. Verified: appending 16 ordinary 30-line records — nothing long, nothing unusual — makes both sides true and fires it, reddening the blocking job for an unrelated author. Exactly what #688 exists to abolish. The v4-vs-v5 contrast moved to test_v4_would_have_reddened_where_v5_holds, built on a distribution the test OWNS, reproducing the shape that matters (a sparse gap just above the ceiling). The real-corpus test now asserts only the robust claims: the additions were counted, v5 holds, and the measured headroom. Same treatment for the "bad ceiling" teeth test, which hard-coded that 200/229/230 stay rejected on the live corpus — three new 200+ line records flip it. Teeth now demonstrated synthetically; the only live-corpus assertion left is that today's ceiling is accepted, which needs 38 over-ceiling or 718 short additions to break. The IFF drift test could lose its quiet branch: one 61-line record makes BOTH the 60 and 999 ceilings drift, at which point an UNCONDITIONAL notice would pass. Both ceilings are now DERIVED — p90 itself (always calibrated, since p90 <= p90 <= p95) and max+1 (always off the tail) — so each branch is guaranteed by construction, and the test asserts it exercised both. Added the missing regression test for the typed-mapping-key TypeError: removing `key=str` now fails a test instead of only a manual probe. Corrected against measurement: the v5 row of the record's own version table still stated the REJECTED first-draft bound (`0 < f < 1/3`) — the canonical artefact contradicting both the code and its own next paragraph; accepted range is 43..180, not "roughly 45..150"; breaching the cap takes 38 additions, not 37 (37 lands exactly on 0.25, which passes under `<=`); "5x headroom below the floor" was inverted; ci-cd.md said four versions "all ratcheted" when v1 was vacuous and v2 accepted an absurd ceiling; and the crosscheck record overstated protection — script-tests is NOT a required check, so "no broken record has reached main" is procedural, not structural. Evidence the coupling is actually gone: mid-fix the corpus sat at marks_tail=False (an edit pushed this branch's own record to 61 lines, moving p90) and the suite stayed fully green. Under the old assertions that state reddened CI. The record is trimmed back to 60 so main ships calibrated and no drift notice nags. Verification: 428 scripts/tests pass; ruff at baseline parity (47); validator exits 0 with no drift notice; corpus at p90=60, 18/183 over the ceiling. Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-04 21:02:01 +02:00
timothyandClaude Opus 5	80818aa294	fix(674,688): address independent review — restore the coarse bound's teeth ... Two independent cold reviews (one cross-family) agreed on the top two findings. 1. The #688 fix was defeated by its own complement test. test_main_is_QUIET_about_ drift asserted the drift notice was ABSENT while running main() over the LIVE corpus — whose failure condition is bit-for-bit v4's assertion, in the same blocking job, three functions down. p90 sat exactly on 60, so one over-ceiling record would have reddened it. Replaced with an IFF test that uses ceiling_calibration as its oracle, so it asserts the WIRING rather than the corpus's current state, plus a guard that at least one branch fires. 2. The coarse bound was nearly unfalsifiable. `0 < fraction_over < 1/3` accepted EVERY ceiling from 39 to 229 on the real corpus — including the ceiling of 200 my own docstring offered as the case it catches, because one 230-line record keeps the count nonzero. That claim was simply false and is corrected. The floor is now a FRACTION (2%) and the cap 25%, which rejects 200/229/230 and 20, and accepts roughly 45..150. Headroom measured, not estimated: 37 consecutive over-ceiling additions, against ONE record to break v4. 3. yaml.safe_load raises a bare ValueError, not a YAMLError, on a well-shaped but impossible date (stale-after: 2026-06-31), which escaped as a traceback and killed the validator on any machine with PyYAML. The except is now deliberately broad, with a test. 4. PyYAML returns TYPED mapping keys, so a stray `1: x` made sorted(set|set) raise TypeError. Sorted with key=str. 5. The headroom prose was arithmetically wrong (~42/~40 where the real values are 63/64; each addition moves numerator AND denominator) and the record counts were stale. Corrected against measurement. 6. test_adding_ordinary_records passed identically with its two additions removed. It now asserts the additions were counted, and that they break the v4 property while leaving v5 satisfied — guarded by `if`, never asserted, since whether v4 currently holds is a fact about the live distribution and asserting it would rebuild the ratchet. Also recorded honestly in docs.frontmatter-pyyaml-crosscheck: decisions-guard installs no PyYAML, so in CI the cross-check always skips and script-tests already caught both hazards — the CI delta is close to zero and the real fix is the local loop plus the tool/suite agreement. And the new record was trimmed 64 -> 58 prose lines: at 64 it moved p90 to 64 by itself, i.e. this PR would have reddened the old blocking job. That is now cited in the test as the live demonstration. Verification: 426 scripts/tests pass; ruff at baseline parity (47); validator exits 0; corpus back to p90=60, 18/183 over the ceiling, marks_tail and flags_minority both true. Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-04 20:37:27 +02:00
timothyandClaude Opus 5	9d2b30dc3b	fix(674,688): cross-check frontmatter against PyYAML; split the ceiling calibration claim ... Two defects in scripts/decisions_validate.py, fixed together because they share the validator and its pytest suite. #674 — the validator reported OK on frontmatter PyYAML rejects. The hand-rolled reader is deliberately dependency-free (decisions-guard and the Husky hooks install nothing), so it cannot see a bare apostrophe closing a single-quoted scalar. Hit twice in one session by two independent agents. `pyyaml_frontmatter_faults()` now cross-checks the parse against PyYAML whenever PyYAML is importable, and is SKIPPED with a ::notice:: when it is not — the read path stays dependency-free. The two known hazards fail differently and the fix covers both: the apostrophe makes PyYAML reject the document, while an unquoted ` #` parses fine and silently TRUNCATES the value. So the check compares parsed results key by key rather than try/except-ing the load, which is also what makes it generalize past the two known characters. PyYAML wrote these files, so on disagreement it is authoritative and the file is the defect. The comparison has one implementation, called by the validator and by the existing test_decisions_lib agreement test, so the tool and the suite cannot drift. #688 — test_real_corpus_ceiling_sits_at_the_TAIL_BOUNDARY asserted p90 <= 60 <= p95 in the BLOCKING script-tests job. p90 sat exactly on the ceiling and the distribution above it is sparse, so one ordinary record moved p90 by twenty lines and reddened CI for whoever wrote it; it reproduced twice live (#672, #706) and both times the only in-scope remedy was trimming the new record to fit the constant. v5 splits the claim by robustness instead of hunting for a better single assertion. The blocking test now asserts only the coarse, non-ratcheting property (the ceiling flags a nonempty proper minority, 0 < fraction_over < 1/3); the fine tail-boundary claim is measured every run and REPORTED as a ::notice::, on the same reasoning stale_records already uses — a constant going out of date is the passage of corpus growth, not a defect in the commit under test. The fine property is still asserted, against synthetic distributions the test owns. The ceiling stays 60. Verification: 424 scripts/tests pass; ruff at baseline parity (47 before and after); the cross-check is clean on all 183 real records; a positive control pins that record_wing_faults alone still reports both hazard files as clean, so the new red cannot pass for the wrong reason; and a test demonstrates that appending #672's 62-line and #687's 107-line records to the real corpus does not red the blocking property. Docs: new record docs.frontmatter-pyyaml-crosscheck, docs.corpus-size-signal updated for the v5 split, catalog regenerated, docs/ci-cd.md updated for both. fixes #674 fixes #688 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-04 20:15:16 +02:00
timothy	aa79ec59c9	Merge pull request 'fix(706,707,711): fence the review-verdict write on the timeline retarget count' (#723) from fix/706-verdict-status-serialization into main	2026-08-03 21:01:12 +00:00
timothy	fe3d29276a	fix(706): count a raced SENTINEL, not only a raced human verdict ... Round-5 cold review: the post-write check counted only human `Review-verdict:` rows above the high-water mark, which is not sufficient under the run overlap this branch measured. Sequence, all inside that regime, runs A and B on the same exempt-classified sha: the human BLOCKED lands BELOW A's mark (so A cannot see it), B masks it with an exemption `success`, and only afterwards writes the sentinel. A then finds nothing human above its mark, does not repair, and posts its own `success` on top of the sentinel. The human rejection is permanently green and every later run re-derives it — the repair race failing toward SUCCESS, while the record states it fails toward `pending`. The filter now counts two row shapes above the mark: a human verdict (non-null creator, `Review-verdict:` description) OR a machine sentinel (null creator, description exactly $REPAIR_DESC). A then repairs and both runs converge on the fixed point. It cannot false-fire: a pre-existing sentinel would have been seen at the FIRST read and forced the pending path, and this block only runs after a `success`, so a sentinel above the mark can only have been written mid-flight by another run. Mutation-verified on both halves independently — dropping the sentinel alternation reddens the new test; dropping the human half reddens the original race-2 test — so neither can be removed without a test noticing. Refs #706	2026-08-03 22:22:09 +02:00
timothy	a8bbd74a64	fix(706): never replace a sentinel with a non-sentinel ... Round-4 cold review: the mid-run sentinel guard tested `state = success`, which is one branch too narrow. A run can reach the POST on `state=pending` carrying the GENERIC description — most realistically after a transient enumeration failure (`complete != yes`) — and such a run passed the success-only guard, passed the fence, and overwrote the sentinel with ordinary text. The next run then saw no sentinel, re-derived, and posted `success`: the same buried human rejection as the round-2 defect, reached in two steps instead of one. The guard now compares the DESCRIPTION rather than the state: if [ "$ex_repair" = yes ] && [ "$desc" != "$REPAIR_DESC" ] "Never replace a sentinel with a non-sentinel." This is strictly more general and exactly as precise, because the carry-forward branch guarantees that a sentinel seen at the FIRST read already sets `desc` to the sentinel — so the guard cannot fire on the ordinary repaired-head path and the fixed point stays intact. It also makes the code match the decision record, which already stated the general property ("a run whose last-moment re-read finds a sentinel it did not see at its FIRST read ABSTAINS instead of posting") while the code implemented only the success case. Of the two, the code was the one that had to move. Mutation-verified on both clauses independently: reverting to the success-only condition reddens the new pending-path test; dropping the description check reddens the fixed-point test and the sentinel-from-the-start control. Refs #706	2026-08-03 22:13:36 +02:00
timothy	5077408528	fix(706): abstain when a repair sentinel appears mid-run ... Round-3 cold review: `ex_repair` was recomputed by the last-moment re-read but never consulted after it, so the POST wrote the `$state` frozen at classification time. A stale overlapping run therefore posted its `success` straight over a sentinel another run had just written — burying a human rejection with no repair (the human row sits below the stale run's own high-water mark) and no log entry. This is the one path in the design that failed toward SUCCESS rather than `pending`, so it was not covered by the recorded residual, and it is reachable through exactly the run overlap this branch measured live (probe PR #722: the older run finished 20s after the newer one started). The guard is exact rather than conservative: a sentinel present at the FIRST read forces `state=pending`, so `success` together with `ex_repair=yes` at re-read time can only mean the sentinel arrived mid-run. Abstaining is then strictly correct and, unlike the retarget fence, needs no successor run — the sentinel row is already `pending` and already carries the re-post instruction. Mutation-verified three ways: removing the guard reddens the new mid-run test while its positive control stays green; making it unconditional on `ex_repair` reddens the fixed-point test and the positive control, proving the condition is precisely scoped and not merely present. Also strengthens the mark-ordering test to pin the status-history FETCH as well as its initialisation, closing the refactor evasion review flagged; sliding the fetch past the re-read now reddens it. Refs #706	2026-08-03 22:06:42 +02:00
timothy	63040296f4	fix(706): make the repair sentinel a fixed point, not a two-event delay ... Round-2 cold review found the round-1 sentinel self-clobbering: the branch refused the exemption but fell through to the shared else, which posts the GENERIC "Awaiting review verdict" description — erasing the very marker the refusal depends on. The next run saw an ordinary machine `pending`, re-derived it, and posted `success`, burying the human rejection two events after the repair instead of one. The single-hop test passed throughout, and the positive control asserting that an ordinary machine `pending` DOES re-derive was itself the proof of the second hop. Durability is a fixed point, and only a chain can assert a fixed point, so the new test runs the job twice and feeds run N's own posted description in as run N+1's existing status. Keyed on `ex_repair` alone rather than on the exempt path: the fact recorded is "a human verdict was lost on this sha", a property of the sha rather than of this run's classification. Verified by mutation — restoring the defect turns the chained test RED while the single-hop test stays GREEN, which is exactly why the chain was needed. Refs #706	2026-08-03 21:58:06 +02:00
timothy	8f6d4f4432	fix(706,707,711): fence the review-verdict write on the timeline retarget count ... Three related defects in the `review-verdict/h10` gate, all surfaced by the cross-family review of PR #705. #706 race 1 — a stale run could overwrite a fresher verdict, permanently. The race was reproduced live rather than reasoned about (Gitea 1.25.4): with every other workflow stripped, probe PR #722 showed run 7520 (`opened`) finishing 20s AFTER run 7521 (`synchronize`) started. `pull_request_target` runs for one PR genuinely overlap, older finishing last. The issue proposed serializing with a non-cancelling concurrency group. That is REFUTED by measurement: with the group active, runs 7528/7529 still overlapped and 7528 ended 36s after 7529 began. A first probe appeared to show the group working — a negative control with no `concurrency:` key at all showed the same cancellations, revealing Gitea auto-cancels superseded `push` runs on its own and the probe had measured that, not the group. The auto-cancel does not extend to `pull_request_target`. The fix leaves the runs unserialized and instead makes an overtaken run decline to write: count `change_target_branch` events on the PR timeline at start and again just before the POST, and post nothing if the count moved. The COUNT is the key because the branch NAME is ABA-vulnerable (`main -> S -> main` reads `main` at both ends — how #698 route 1 forged its exemption). Abstaining is a handoff, not a stall: every retarget fires `edited`, so the event that makes a run abstain has already queued its successor. `updated_at` was rejected as the key precisely because it moves for comments/labels, which queue nothing. #706 race 2 — a human BLOCKED landing in the unclosable window between the pre-POST re-read and the POST was silently turned green. After an exemption `success` the job now re-reads the per-POST history and repairs its own status to `pending` if a human verdict appeared above a high-water mark taken just before the write. The repair is `pending`, never a copy of the human's state. The id comparison is load-bearing: a presence test would fire forever on a base-mismatched verdict and deadlock that PR's exemption. #707 — `pr-changed-files.sh` bound `.base.ref` and `.head.sha` across the enumeration but never `.base.sha`, so an ordinary advance of `main` mid-paging could drop a code path from an offset-paged diff and leave a complete-looking docs-only list. Now bound from the JSON already fetched (no new round trips). #711 — `.codex/` added to PROTECTED. It mirrors `.claude/hooks/` byte for byte, including the merge-consent hook, so the "a PR that can weaken the gate cannot exempt itself" rule had an incomplete path list. Latent today (untracked), live the moment anyone tracks it. Residuals are stated, not implied: a retarget inside the final round-trip, and the repair being itself a read-then-write. Gitea's status API has no compare-and-set, so neither reaches zero; both now fail toward `pending`. Tests: 398 pass in scripts/tests. Each new guard was mutation-checked — the fence's motion comparison, the untrusted-count gate, the repair POST and the id high-water mark were each neutered in turn and the intended test went red while its positive control stayed green. fixes #706 fixes #707 fixes #711 Decisions-Edit: yes	2026-08-03 21:41:16 +02:00
timothy	7cd71327b0	Merge pull request 'chore(deps): update dependency cliwrap to 3.10.4' (#717) from renovate/cliwrap-3.x into main ... Reviewed-on: #717	2026-08-03 19:28:23 +00:00
timothy	53e6be8390	Merge branch 'main' into renovate/cliwrap-3.x	2026-08-03 18:50:54 +00:00
timothy	b99812eb8b	Merge pull request 'chore(deps): update dependency jetbrains.resharper.globaltools to 2025.3.5' (#718) from renovate/jetbrains.resharper.globaltools-2025.x into main ... Reviewed-on: #718	2026-08-03 18:50:39 +00:00
timothy	03662dcdfd	Merge branch 'main' into renovate/cliwrap-3.x	2026-08-03 18:13:53 +00:00
timothy	aaa4e869b8	Merge branch 'main' into renovate/jetbrains.resharper.globaltools-2025.x	2026-08-03 18:12:59 +00:00
timothy	9dc360c9fa	Merge pull request 'docs(release): record the v26.13.0 release notes' (#716) from release/v26.13.0 into main v26.13.0	2026-08-03 17:02:23 +00:00
renovate	95f36d1c45	chore(deps): update dependency jetbrains.resharper.globaltools to 2025.3.5	2026-08-03 17:02:21 +00:00
renovate	ff8b0bf984	chore(deps): update dependency cliwrap to 3.10.4	2026-08-03 17:02:11 +00:00
TimothyandClaude Opus 5	016a05ced8	docs(release): record the v26.13.0 release notes ... 73 PRs merged since v26.12.0. Adds the release-table row in docs/ci-cd.md covering the RuleBuilder maturation, the On Now/Next overlay, searchable library pickers, the watermark/QSV correctness fixes, and the H10 review-verdict gate hardening. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-02 20:40:58 +02:00
timothy	9928be805f	Merge pull request 'chore(deps): batch three Renovate patch bumps (supersedes #679, #680, #681)' (#714) from chore/renovate-batch-2026-07-30 into main	2026-07-30 21:31:32 +00:00