fix(674,688): cross-check decision frontmatter against PyYAML; split the ceiling calibration claim #725

Merged

timothy merged 9 commits from fix/674-688-decisions-validator into main 2026-08-04 23:43:10 +02:00

Conversation 1 Commits 9 Files Changed 7

+847 -55

timothy commented 2026-08-04 20:38:12 +02:00

Owner

Copy Link

Copy Source

Fixes two defects in scripts/decisions_validate.py, taken together because they share the validator and its pytest suite.

#674 — the validator reported OK on frontmatter PyYAML rejects

The frontmatter 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 (#578, #651).

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 hazards fail differently, and covering only one would have missed half:

input	dependency-free reader	PyYAML
rule: 'SQLite's LOWER()'	SQLite's LOWER()	rejects — apostrophe closes the scalar
rule: use --flag #2	use --flag #2	use --flag — silently truncated

So it 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. One implementation, called by the validator and by the pre-existing test_decisions_lib agreement test, so the tool and the suite cannot drift.

Stated plainly in the record: decisions-guard has no PyYAML so the cross-check always skips in CI, and script-tests already went red on both hazards. The CI delta is close to zero; what this fixes is the local loop #674 actually described, plus the tool/suite disagreement.

#688 — the ceiling calibration test reddened CI for unrelated authors

p90 <= 60 <= p95 was asserted against the live corpus 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. Reproduced twice live (#672, #706); 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:

• blocking — only the coarse, non-ratcheting property: the ceiling flags a meaningful minority (0.02 <= fraction_over <= 0.25). Measured headroom: 37 consecutive over-ceiling additions, against one to break v4.
• reported, never asserted — the fine tail-boundary claim, now a ::notice:: from main(), on the same reasoning stale_records already uses in that file. It is still asserted, against synthetic distributions the tests own.

The ceiling stays 60. The honest cost is recorded: nothing now forces a re-derivation.

Review

Two independent cold reviews (one cross-family via Codex) agreed on the top two findings; both are fixed in the second commit:

1. The complement test assert "drifted" not in err over the live corpus was v4's assertion relocated, in the same blocking job. Now an IFF test using ceiling_calibration as its oracle.
2. 0 < fraction_over < 1/3 accepted every ceiling from 39 to 229 on the real corpus — including the 200 my own docstring claimed it caught, since one 230-line record keeps the count nonzero. That claim was false; the floor is now a fraction.
3. yaml.safe_load raises a bare ValueError (not YAMLError) on stale-after: 2026-06-31, escaping as a traceback. The except is now broad, with a test.
4. Typed mapping keys (1: x) made sorted(set | set) raise TypeError. Sorted with key=str.
5. Headroom prose was arithmetically wrong (~42/~40 vs the real 63/64) and counts were stale.
6. test_adding_ordinary_records passed identically with its additions removed; it now asserts they were counted and that they break v4 while leaving v5 satisfied.

Notably the new record at its original 64 prose lines moved p90 to 64 by itself — this PR would have reddened the old blocking job. It is trimmed to 58 and that fact is cited in the test as the live demonstration.

Verification

• 426 scripts/tests pass; ruff at baseline parity (47 before and after — pre-existing, ruff format non-conformance is also pre-existing on main for these files, so no reformat)
• validator exits 0; cross-check clean on all 183 real records (no false positives)
• positive control pins that record_wing_faults alone still reports both hazard files clean, so the new red cannot pass for the wrong reason
• corpus back to p90=60, 18/183 over the ceiling

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

Fixes two defects in `scripts/decisions_validate.py`, taken together because they share the validator and its pytest suite. ## #674 — the validator reported OK on frontmatter PyYAML rejects The frontmatter 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** (#578, #651). `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 hazards fail *differently*, and covering only one would have missed half: | input | dependency-free reader | PyYAML | |---|---|---| | `rule: 'SQLite's LOWER()'` | `SQLite's LOWER()` | **rejects** — apostrophe closes the scalar | | `rule: use --flag #2` | `use --flag #2` | `use --flag` — **silently truncated** | So it 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. One implementation, called by the validator and by the pre-existing `test_decisions_lib` agreement test, so the tool and the suite cannot drift. **Stated plainly in the record:** `decisions-guard` has no PyYAML so the cross-check always skips in CI, and `script-tests` already went red on both hazards. The CI delta is close to zero; what this fixes is the local loop #674 actually described, plus the tool/suite disagreement. ## #688 — the ceiling calibration test reddened CI for unrelated authors `p90 <= 60 <= p95` was asserted against the **live corpus** 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. Reproduced twice live (#672, #706); 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: - **blocking** — only the coarse, non-ratcheting property: the ceiling flags a meaningful minority (`0.02 <= fraction_over <= 0.25`). Measured headroom: **37** consecutive over-ceiling additions, against **one** to break v4. - **reported, never asserted** — the fine tail-boundary claim, now a `::notice::` from `main()`, on the same reasoning `stale_records` already uses in that file. It is still asserted, against synthetic distributions the tests own. The ceiling stays **60**. The honest cost is recorded: nothing now *forces* a re-derivation. ## Review Two independent cold reviews (one cross-family via Codex) agreed on the top two findings; both are fixed in the second commit: 1. The complement test `assert "drifted" not in err` over the live corpus **was v4's assertion relocated**, in the same blocking job. Now an IFF test using `ceiling_calibration` as its oracle. 2. `0 < fraction_over < 1/3` accepted **every ceiling from 39 to 229** on the real corpus — including the 200 my own docstring claimed it caught, since one 230-line record keeps the count nonzero. That claim was false; the floor is now a fraction. 3. `yaml.safe_load` raises a bare `ValueError` (not `YAMLError`) on `stale-after: 2026-06-31`, escaping as a traceback. The except is now broad, with a test. 4. Typed mapping keys (`1: x`) made `sorted(set | set)` raise `TypeError`. Sorted with `key=str`. 5. Headroom prose was arithmetically wrong (~42/~40 vs the real 63/64) and counts were stale. 6. `test_adding_ordinary_records` passed identically with its additions removed; it now asserts they were counted and that they break v4 while leaving v5 satisfied. Notably the new record at its original 64 prose lines moved p90 to 64 by itself — **this PR would have reddened the old blocking job**. It is trimmed to 58 and that fact is cited in the test as the live demonstration. ## Verification - 426 `scripts/tests` pass; `ruff` at baseline parity (47 before and after — pre-existing, `ruff format` non-conformance is also pre-existing on `main` for these files, so no reformat) - validator exits 0; cross-check clean on all 183 real records (no false positives) - positive control pins that `record_wing_faults` alone still reports both hazard files clean, so the new red cannot pass for the wrong reason - corpus back to p90=60, 18/183 over the ceiling ## 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

timothy added 2 commits 2026-08-04 20:38:13 +02:00

fix(674,688): cross-check frontmatter against PyYAML; split the ceiling calibration claim ... 9d2b30dc3b

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>

fix(674,688): address independent review — restore the coarse bound's teeth ... 80818aa294

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>

timothy referenced this pull request 2026-08-04 23:00:33 +02:00

fix(726): let a lagging realtime input catch up so a sparse bitmap-subtitle stream can't pin it below realtime #737

timothy added 7 commits 2026-08-04 23:18:38 +02:00

fix(688): stop asserting live-corpus order statistics anywhere in the suite ... b3a8826281

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>

fix(688): remove the last live-corpus tripwires and three fabricated/wrong numbers ... 0db56c3ebd

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>

fix(688): delete the last over-tight test, pin the crosscheck's INPUT, fix 4 prose defects ... c56dfdd539

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>

fix(688): stop enumerating multiplicities, pin n and the keyless filter, de-couple the vacuity floors ... b24c51ab51

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>

fix(688): make the n oracle dynamic; correct a tense that asserted false history ... 2ff52d4236

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>

fix(688): pin the minority band's constants and inclusivity; two prose corrections ... 0ff9671393

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>

fix(688): pin p95's inclusivity; drop a stale ratio and hedge the gap width ... efc34a3481

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>

timothy referenced this pull request 2026-08-04 23:24:57 +02:00

Embedded BITMAP subtitle (PGS/DVD) burn-in + `-readrate` halves transcode to 0.53x realtime — Live TV buffering #726

timothy commented 2026-08-04 23:42:35 +02:00

Author

Owner

Copy Link

Copy Source

Review-verdict: MERGEABLE @ efc34a3

Rounds 1-8, two model families, cold review-only briefs. Rounds 1-7 each found real defects (five surviving live-corpus couplings, a coarse bound accepting ceilings 39..229, an unpinned crosscheck input, unpinned band constants). Round 8 both families: no correctness findings, 8/8 targeted mutants killed, zero survivors. 432 scripts/tests green, ruff at baseline parity 47, validator exits 0.

Review-verdict: MERGEABLE @ efc34a3 Rounds 1-8, two model families, cold review-only briefs. Rounds 1-7 each found real defects (five surviving live-corpus couplings, a coarse bound accepting ceilings 39..229, an unpinned crosscheck input, unpinned band constants). Round 8 both families: no correctness findings, 8/8 targeted mutants killed, zero survivors. 432 scripts/tests green, ruff at baseline parity 47, validator exits 0.

timothy merged commit a2b3a56d93 into main 2026-08-04 23:43:10 +02:00

timothy deleted branch fix/674-688-decisions-validator 2026-08-04 23:43:11 +02:00

timothy referenced this issue from a commit 2026-08-04 23:43:12 +02:00

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

timothy referenced this pull request 2026-08-04 23:44:08 +02:00

`decisions_validate.py` stays green on frontmatter PyYAML rejects — an apostrophe in a single-quoted scalar (hit twice in one session) #674

timothy referenced this pull request 2026-08-04 23:45:23 +02:00

`decisions_validate` ceiling calibration test is one line from red — any record ≥61 prose lines fails `script-tests` #688

timothy referenced this issue from a commit 2026-08-04 23:50:21 +02:00

docs(release): fold #674/#688 into the v26.14.0 notes after rebasing on main

timothy referenced this pull request 2026-08-04 23:51:11 +02:00

docs(release): record the v26.14.0 release notes #738

timothy referenced this pull request 2026-08-05 00:02:48 +02:00

docs(release): record the v26.14.0 release notes #738

timothy referenced this pull request 2026-08-05 00:44:27 +02:00

docs(release): record the v26.14.0 release notes #739

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

ad-hoc

One-off / ad-hoc work not tracked by a dedicated issue

api

REST API / HTTP endpoints

bug

Something isn't working

ci-cd

Build, test, deploy pipeline

content

Channel content / schedules / playlists

dependencies

Dependency updates (Renovate)

enhancement

New feature or improvement

frontend

ChicoryTV React SPA frontend

in-progress

Claimed by an active session — do not pick up

jellyfin

Jellyfin tuner / IPTV integration

parked

Excluded from automatic queue pickup; work only when explicitly selected

priority: high

priority: low

priority: medium

review

Adversarial review finding

security

Security / vulnerability fix

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

renovate timothy (Timothy)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: timothy/ersatztv#725