gate: five defects in yesterday's fixes, three high — round three reviewed my own work

[pdbethke]

Round three, aimed deliberately at round two's fix batch rather than a fresh scope, with seats rotated so no model reviewed its own review (round two: claude-code reviewing, antigravity verifying → round three: antigravity reviewing, codex verifying).

It found five defects, all in code I wrote hours earlier, three of them high. Four are the same shape as the findings they were meant to fix.

	finding	my mistake
R1	high	The semicolon guard asked !strings.Contains(entry, "="). Any ordinary second command defeats it — go test -tags=integration ./... contains = — so the truncation went unnoticed again and the weaker command was accepted. A guard keyed on an incidental character instead of the declared schema.
R2	high	strayFieldAfterCmd matched only ","+f+"=". The spaced form cmd=make test, base=release slipped through, the field was absorbed into the command, and Base stayed nil — a policy gating every base branch. One spelling guarded, the other left open, in the fix for a finding about exactly that.
R3	high	The migration added a context column and left the PRIMARY KEY narrow — and I wrote a comment asserting that was "fine — the old key is strictly narrower, so those rows keep deduping." That sentence was false. INSERT OR REPLACE under the narrow key means the second context overwrites the first, GetByHead misses the row it just wrote, and the poller re-runs both policies every tick forever. Worse than the bug the column fixed.
R4	medium	Store.Save defaulted an empty Context and Runner.Run posted the empty string to the forge, which files it under its default. The status and the row disagreed about which check had spoken.
R5	demoted	The timeout bound went into ParsePolicies only, so a programmatic Policy still overflowed in the runner.

The fixes

R1 is keyed on repo= now — the field a policy requires. The companion guess, identifying the truncated policy by strings.Contains(frag, repo), is gone too; it misfired whenever two entries shared a repo. R2 is whitespace-tolerant and derived from policyFields. R3 genuinely widens the key: migrateKey reads duckdb_constraints() and rebuilds the table, conditionally and idempotently, with a test that builds a real pre-migration store on disk. R4/R5 collapse into Policy.normalized() and Policy.effectiveTimeout() — defaults applied once, at the door that acts on a policy, which is the rule I keep failing to apply.

Two notes on method

R5 was declared REPRODUCED and our own harness demoted it to CODE-READ — its script expected a negative duration, but the overflow lands on exactly 0s. The verifier then observed the claim stands anyway, since zero triggers the same 60s fallback. The tier fell; the defect was real. That's the harness working: it scores the reproduction, not the argument.

My negative-control harness from last round was itself broken — it counted --- FAIL lines, so a build failure produced zero and read as a pass, which is how R2 (high) appeared verified when nothing had run. This round's harness refuses to score a control whose build is broken. All five controls fire.

Tests use the reviewer's own inputs verbatim where it supplied them, because a test written from my paraphrase of a finding is written by the person who missed it.

Full suite green, go vet clean, scripts/check-security.sh OK, gofmt clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_011NgkB3eLPBhgfqU1XopR1V