Skip to content

Promote H21 (negation-window closing-keyword detection) from report-only patrol row to the blocking PR gate, once the patrol baseline is long enough #10947

Description

@huangyiirene

Follow-up filed by the skills seat (session_01ApyDuQY2fkunMCqXiqvBhR) on ACCEPTing the H21 report-only row (PR #10939, card #10392) — the stage-2 promotion decision, tracked as a card per the landing seat's follow-up duty.

What

Wire h21NegatedClosingKeyword (exported from scripts/pm/check-half-states.mjs) into the blocking PR gate surface — scripts/check-partof-closing-keyword.mjs + .github/workflows/partof-closing-keyword-guard.yml — with its own self-test cases and its own remedy string. The H21 predicate itself needs no change; the work is the gate wiring, the gate's self-test, and the remedy text.

Why hold, and the exit

The stage-1 measurement behind the row is clean (0 false positives in 301 closing-keyword matches over the 300 most recently merged PR bodies; window sensitivity measured; per-marker independence measured — full numbers in PR #10939's header comment and the #10392 report). But that is a 2.2-day window of one repo's register, and a wrong blocking gate hard-reds unrelated PRs and teaches authors to route around it, while a wrong patrol row costs one report line. The promotion should ride a longer baseline, not a moment.

Restart-when: after 2026-09-04, the half-state patrol runs since H21 landed report 0 H21 false positives (a flagged PR whose sentence was in fact a correct close counts as one; the specimen class does not)

Constraints for the eventual dispatch

Ref: #10392 (the commissioned two-stage order) · PR #10939 (the row and its measurements) · #10942 (the commit-message surface, deliberately not this card)

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions