Repository navigation
fix(guard): #3400 landmine regex requires a colon CLOSE_RE doesn't require - #3499
alfredodeza wants to merge 3 commits into
Conversation
…quire The independent review of #3497 (evidence/pr-review/3497) found that NOCLOSE_LANDMINE_RE mandated a literal ':' while CLOSE_RE treats it as optional (':?'). A colon-less body like "no-fix #123 tracked elsewhere" therefore matched CLOSE_RE (a real closing reference, per the guard's own logic) but not the landmine regex meant to catch exactly that shape -- the #3400 bug class in a spelling one edit away from the one already fixed. Made the colon optional in NOCLOSE_LANDMINE_RE to match CLOSE_RE exactly. Self-test: 19 -> 20 cases, new row proves the colon-less form is caught. Also updated APR-RELEASE-001's R-2 predicate row, which still documented the retired `no-close:` marker as sanctioned -- the spec #3497 was implementing without updating the authority it cites. keep-open: #3477, #3090 -- unrelated to GPU/CPU Qwen3 support; this is a guard-correctness follow-up only.
|
§13.11 rung 1 — quorum shadow verdict Shadow mode: this records a verdict and merges nothing. A refusal |
|
Triage from the release babysit session (aprender-ba), so this does not sit red silently while the 0.68.2 train runs: The red is CODE, not env.
Two things to know when fixing it: (1) the body guard reads the frozen Auto-merge is already armed on 672ea4c; once |
|
Update: the §11.1 predicate was the reach-too-far, not this PR. #3536 (PMAT-3535) merged at 20:04Z: the spec now names only the release spec ( |
|
Correction to my note above — for this PR a body line is still required. The re-run on 4921df8 (job 105959120528, with the fixed guard from #3536) still fails §11.1 because this branch edits Fix: add one line to the PR body, e.g. then push (an empty commit is enough; the guard reads the frozen event payload). Everything else on the run is green and auto-merge is armed, so it merges on its own after that. Sorry for the false "no body change needed". |
|
Disarmed by the aprender cop (2026-09-20 23:50Z) under tonight's review-gate ruling: every PR needs a committed AD-04 quorum receipt ( |
noahgift
added
the
needs-owner
|
closed by operator 1-day PR rule; reopen/rebase to resume. No live owner session, red CI on the current head, not carried by main or any open integration PR. Linked issue: no issue link in the body; follow-up to #3497 / #3400 (landmine regex colon). Linked issues are not touched by this close. Branch is NOT deleted: |
…se spec, not every design spec — three maintainer PRs were red for a delta that did not exist; the predicate gets its self-test (Refs PMAT-3535) (paiml#3536) * §11.1 + check_pr_ont_delta: the docs/specifications sink is the release spec, not every design spec; the predicate gets its self-test (Refs PMAT-3535) Measured 2026-09-19 (aprender-ba): paiml#3499, paiml#3420 and paiml#3424 — a guard-regex fix and two design specs — RED on guard-tree with `FAIL no ont-delta: line`, each touching one file under docs/specifications/ and nothing else §11.1 names. The guard was FAITHFUL to the sentence, which named `docs/specifications/**` whole as a prose sink. A design spec is the finding's home, not a sink a sweep writes into; the sink under that directory is the train's own spec, where sweep findings are recorded. Spec and guard move together: §11.1 names `docs/specifications/APR-RELEASE-001-*.md` and says a `*-MASTER.md` design spec is not a sweep; ONT_SWEEP_SINKS follows (the file, not the directory). The predicate half had no self-test (all 15 rows fed check_body_text). predicate_self_test — aprender-ba's leg, 10 rows: crate source, a contract, ci.yml are not sweeps; night.yml, README, CLAUDE, the registry, a derived baseline, the release spec are — chains into --self-test. The falsifying row "a DESIGN spec is not a sweep" is want=1 and goes RED (want=1 got=0) with the directory-wide sink restored, so the leg discriminates. --self-test 15 + 10 passed; bashrs lint 0 errors. Pmat-Ticket: PMAT-3535 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * §11.1 and the guard name the same bytes; the design-spec row is named as the criterion names it (Refs PMAT-3535) Quorum round 1, lane 1: the spec said APR-RELEASE-001-*.md while ONT_SWEEP_SINKS said the exact file — 'verbatim' means the same string in both; and the row name carried a suffix the criterion did not. Criteria rewritten from the diff. Pmat-Ticket: PMAT-3535 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * check_pr_ont_delta: say in predicate_row that sweep_reason takes a FILE of paths (Refs PMAT-3535) Quorum round 2, lane 3 (flash) claimed, "measured", that predicate_row hands sweep_reason the temp path itself so six rows fail with got=1. It does not: sweep_reason reads the changed paths OUT of the file it is given (`while IFS= read -r f … done < "$changed"`), which is the shape main() hands it from --changed; predicate_row writes one path into a temp file and passes the file. Measured on this head, `bash scripts/check_pr_ont_delta.sh --self-test`: self-test 15 passed, 0 failed; predicate self-test 10 passed, 0 failed — and with the directory-wide sink restored exactly one row (a DESIGN spec is not a sweep) goes want=1 got=0. The claim was a misread of the function's contract; the comment now states that contract where the misread happened, so the next reader does not need to trace it. Pmat-Ticket: PMAT-3535 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * audit: quorum-PMAT-3535 round 3 AGREED 3/3 on ad99389 (Refs PMAT-3535) Round 1: two exactness findings (the row name, the sink spelled the same in spec and guard), both taken. Round 2: one lane misread sweep_reason's file argument; refuted by the measured self-test and the contract stated in a comment. Pmat-Ticket: PMAT-3535 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Noah Gift <noah@paiml.com> Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
Follow-up to #3497. Found by that PR's own independent review
(
evidence/pr-review/3497/), finding 1:NOCLOSE_LANDMINE_RErequired aliteral colon while
CLOSE_REtreats the colon as optional (:?), so acolon-less body bypassed the new check entirely and read as a valid
closing reference instead of the landmine it actually was — the same bug
class in a spelling one edit away from the one #3497 fixed.
What changed
scripts/check_pr_closes_issue.sh: made the colon optional inNOCLOSE_LANDMINE_RE, matchingCLOSE_REexactly. Self-test 19 → 20cases; the new row is a body reading a hyphenated keyword, a space, then
the issue reference with no colon between them — it now fails as intended.
docs/specifications/APR-RELEASE-001-train-and-build-kaizen.md: the R-2predicate row still documented the retired negating marker as sanctioned.
Updated to name the replacement and the reason.
Verification
And the exact shape the review found, confirmed caught:
keep-open: #3477, #3090 — unrelated; guard-correctness follow-up only, not
GPU/CPU Qwen3 work.
🤖 Generated with Claude Code
ont-delta: none — this PR changes
scripts/check_pr_closes_issue.sh(the CLOSE_RE colon defect, #3400) and the APR-RELEASE-001 prose describing it; it adds, removes or reshapes no ontology entity, shape, reason or resolution. (Line added by the aprender cop 2026-09-20 socheck_pr_ont_delta.shreads the PR;gh pr update-branchre-fires the guard on the new event payload.)