One file keeps a decision from one run to the next, and never tells its assessors

Critique asks again about a finding you already said yes to, when its questions should go to what’s new. One hand-written file, read at synthesis once Assessment B has returned, holds that answer and never reaches an assessor.

Lab · Impeccable · critique · Proposal: one hand-written decisions.md beside ignore.md · Issue #1263 on GitHub →

Try it

Two critiques, one decisionthe About page, 10-21 then 10-22

Problem todayProposed fix the issue’s guidanceBaseline works todaySide effect a wrong pairing

Listed, not asked

Run 1 is the real 10-21 critique of the About page, run 2 the real 10-22 one. Answer “fix that” on the faded “from” number, which the issue uses, ignore another, then run critique 2 and read the two columns.

BaselineRun 1 · Priority Issues
    Your answer to each finding. Fix that copies a short anchor into decisions.md; Ignore puts it in ignore.md.
    Baselineignore.md
    Accepted, stop reporting it. Silences a finding for good.
    Proposed fixdecisions.md
    Written by hand (here, the button stands in for your hand). Critique never edits it. Today this file does not exist, so the answer stays in the chat.
    BaselineControl: an unrelated edit
    one-file pagean unrelated lineuntouched
    The issue’s synthetic check, replayed here: edit one line unrelated to every finding. Use the switch in the bar, then switch it back.
    BaselineWhat the snapshot can hold
    critique-storage latest treats the edited file as stale and writes closed: true; reverting does not reopen it. No decision lives there.
    ProblemToday: nothing records the decision
    Proposed fixThe pending file, read at synthesis
    01

    The problem

    Where an answer to a finding goes today. Two have a place; a decision to fix has none, so the next run asks again.

    02

    What the proposal does

    One file beside ignore.md, hand-edited and shared the same way. It changes labels only: never a score, a priority, or whether a finding is reported.

    Proposed fixWho reads which file, stage by stage
    Stageignore.mddecisions.md
    Setupreadnot read
    Assessment Ain the briefnever in the brief
    Assessment Bin the briefnever in the brief
    Synthesis, once B has returneddrops matches silentlyread: labels matches “decided”
    The way detector output already waits for Assessment A. This holds on native and sequential runs too, so the guarantee of PR #153 stands: no assessor sees a prior-run input of this kind.
    Proposed fixThe file: one decision per line
    fix: faded "from" number fails contrast (me, 2026-10-22: after the figure refactor)
    fix: rule:tight-leading value:1.0
    • A design-review line quotes a short anchor copied from the finding; the parent judges whether a finding is the same defect in the same place.
    • A detector line matches by rule and value (and occurrence), never line number.
    • A matched finding is labeled decided, reported as usual with its fix: line quoted, and not asked about. It still counts toward the three-issue question gate.
    • If ignore.md and fix: both match, ignore.md wins; Run Notes name the hidden fix: line.
    • Run Notes list fix: lines that matched nothing. You delete them; nothing is stored.
    No new command, and no change to close, latest or trend. Only you edit the file.
    03

    Does matching work?

    Measured on real critique snapshots: 8 findings that recur in the next run of the same target (2 projects) and 5 that don’t (2 projects); 3 projects in all.

    BaselineRecurring findings matched, of 8
    Text of the fix: lineMatched
    My own words0 of 8
    Finding title, copied (titles are reworded every run)0 of 8
    Short anchor, copied5 of 8
    Short anchor, judged by a model8 of 8
    The first three rows are substring checks. Free-phrase matching fails; a short anchor copied from the finding works only partly, so the proposal asks the parent to judge it.
    Side effectJudged by a model: Sonnet and Haiku, 3 runs each
    43 lines, 9 snapshots, 3 projectsSonnetHaiku
    The 8 recurring findings, matched24 / 2424 / 24
    Lines with no match, paired with a finding that shares a word or topic (75 judgments each)9 (12%)7 (9.3%)
    Lines whose finding the next run says is fixed or dead, matched to that retraction row0 / 242 / 24
    Lines whose answer differed between the 3 runs3 of 435 of 43
    About 1 in 8 lines with no match was wrongly paired. Sonnet’s 9 are the same 3 lines on every run, so repeating the call will not average them out.
    Side effectA wrong pairing, as it looked
    The linefix: The key lies on day 8
    Paired withDay 8’s only drawn signal fires backwards: the lit read spoke renders 2.5px vs the unlit 3px
    Where6 of 6 runs, both models; the two share only “day 8”
    A wrong “decided” label is possible, so the matched fix: line is quoted beside each finding. A miss is today’s behavior; a false match drops one question, with the finding and the quoted line still on screen.
    Probe notes method and the measurements behind the issue

    The demo’s run 1 and run 2 are the About page’s real critiques of 10-21 and 10-22 in the author’s michaelevan-site snapshots. Finding titles are copied as written, without their “(new)” and “(open since …)” tags. The simulation is a simplification: it asks one question per finding in priority order, four at most (the skill allows 2 to 4), and it takes the pairing from the labelled probe set rather than running a model.

    Run 1 finding (10-21)Same defect in 10-22Basis
    The narrow-screen fallback is broken at the top and in the workThe narrow-screen fallback is still broken at the top, and the work’s foot now collidesThe 10-22 title says it is open since 10-19. Not one of the probe’s labelled lines.
    The résumé rail lost its paper, and the pencil strip smears the text under itThe résumé rail has no paper and its pencil strip covers the sticky role blockProbe line: Sonnet and Haiku both matched it on 3 of 3 runs.
    The site name blinks out on first paintNot reported in 10-22Probe line with no match: both models answered none on 3 of 3 runs.
    The PDF downloads under the old namePDF still /resume/michael-kelly-resume.pdf (a Minor line)Probe line: both models matched it on 3 of 3 runs.
    The new Figure’s faded “from” number fails contrastThe Figure’s faded “from” number still fails contrastProbe line: both models matched it on 3 of 3 runs.

    Left out of the demo: the 10-21 finding “The first role’s column is taller than the window”, whose label in the probe set is ambiguous.

    Matching test: the author’s own snapshots, consecutive runs of the same target, each fix: text checked against the whole of the next snapshot as a case-insensitive substring. Disclosed bias: the jot and anchor texts were written after seeing both runs, which favours hits; every next run here had prior-run input, which keeps wording stable. Isolated runs will likely do worse, so these rates are upper bounds on recall. Anchors made one false match (a value hit a row retracting the old finding); a bare element name made another.

    Judgment probe: claude -p with Sonnet and Haiku, no tools, each snapshot’s full finding list and all its fix: lines in one prompt, labelled by a Sonnet worker, not the author; 11 of 43 lines are marked ambiguous. The no-match figures above forgive the 8 ambiguous lines among the 25 with no match (9 and 7); counted strictly against the primary labels they are 19 and 13. The detector side (rule and value matching) was not tested.

    Untested: the proposal inside a real critique.md; how a different phrasing of the same anchor fares.

    Investigation, probe and demo prepared with AI assistance (Claude Code) under the author’s direction.