source-control:babysit-prs: babysit-readiness-gate.sh classification-token matching is case-sensitive, silently under-counts natural-language dispositions

[kyle-sexton]

Lane: babysit, observed on #592.

babysit-readiness-gate.sh matches classification tokens with grep -wE 'VALID|INCORRECT|UNCERTAIN' (case-sensitive, exact-case only). A worker's classification-table reply that writes a natural-language disposition like "Valid (defer)" instead of the mandated all-caps VALID scores as unclassified — the gate then reports BLOCKED reason=under-decomposed even though the finding genuinely was classified, just not in the exact casing the regex expects.

This compounds with the already-tracked #465 (over-counting) in the opposite direction: #465 makes BLOCKED verdicts too pessimistic by inflating the finding count; this makes them too pessimistic by deflating the classified count when a reply's wording drifts even slightly from the mandated token casing.

Category: bug. Expected: either case-insensitive matching (grep -wiE ...), or the gate's own error output should name the exact token casing it expects when a classification-shaped reply doesn't match, so an operator/worker can immediately see why a reply "didn't count."

Work-class: C3 (bug-fix-shaped) — attended triage 2026-07-23, operator-ratified. 🤖

[kyle-sexton]

This was generated by AI during triage.

Triage (umbrella-fold) — same defect class as #534 (shared authorship/finding/approval classifier umbrella): hand-rolled per-call-site classification-token matching (babysit-readiness-gate.sh's exact-case grep -wE) failing on real-world variance in reply wording. A shared classifier with golden fixtures (#534's proposed fix) would catch this by construction. Folding rather than routing standalone per the umbrella-fold rule.

Blocked by #534's decision. Not routed to needs-human individually.

[kyle-sexton]

Tracking note from the #634 merge digest (control tower): PR #634 ships the shared classifier without a disposition for this issue — finding-side severity matching remains case-sensitive (BLOCKING_SEVERITY_RE = \b(?:CRITICAL|IMPORTANT)\b in babysit_classify.py, deliberately so per its comment: lowercase "critical"/"important" are ordinary review prose).

Direction correction after code verification (an earlier version of this note said fail-closed — wrong): a bot emitting lowercase structured severity labels would have its finding NOT counted by count_findings, so the gate could report READINESS_OK past a live finding — fail-open. Exposure is narrow in practice: the case-insensitive BLOCKING_TEXT_RE (p0/p1/p2, "must fix", "changes requested", …) still catches most real formats, and both current reviewers (Claude review: uppercase CRITICAL/IMPORTANT; Codex: P1/P2 badges) match today. The rationale is documented at the regex but is load-bearing for gate-off.

Issue stays open on its own merits; babysit_classify.py is now the single place to fix it.

[kyle-sexton]

This was generated by AI on operator direction.

Superseded — this item was already ratified and should not have been queued.

The earlier first-drain ratification request on this issue was raised in error. The admission gate dispatches a C3 bug-fix-shaped item when it carries either its own recorded ratification or a completed first drain — and this issue already carried recorded ratification in its body from attended triage on 2026-07-23. The drain cycle applied the blanket first-drain rule without first reading bodies for an existing ratification, so it queued an item that was already admitted.

Restored to the autonomous frontier: agent-ready re-applied, needs-human removed. No human action is required, and this issue no longer appears in the attended queue's ratify view.