classify-infra-failure: substring path discards its matched error type — carry it as a new error_type projection key

[kyle-sexton]

Problem

On the substring-fallback detection path, classify-infra-failure.sh knows exactly which published error type it matched (the allowlist at lines ~71-77: authentication_error, billing_error, permission_error, …) and then discards it. The emitted projection carries api_error_status: null on that path, so an operator triaging a class=auth failure gets no discriminator at all — 401 vs 402 vs 403 prescribe three different remedies (rotate token / fix billing in Console / fix key permissions and workspace access), and the operator gets a three-way checklist instead of the specific one.

This is not 402-specific: a substring-detected 403 reproduces it. Independently verified during the #250 ratification review (2026-07-26).

Proposed fix

Carry the matched allowlist token into the structured projection as a NEW key — error_type, deliberately distinct from api_error_status, so an inferred (substring-matched) value is never conflated with an observed numeric status.

Verified safe and non-breaking before filing:

• Additive only. The projection is built at classify-infra-failure.sh:~81-89; a new key leaves class and api_error_status untouched, and class=<token> remains a bare separate term in the ::error annotation (claude-review.yml:~484), so Incident aggregator: dead-credential detection from consumer review-run annotations (scheduled, zero new secrets) #238's aggregator written against today's shape does not break.
• Log-hygiene safe by construction. The value comes from the closed published-type allowlist, never from raw model/SDK text.
• Existing suite passes. Test 20 (classify-infra-failure.test.sh:~140-144) asserts key presence plus a result/errors leak denylist; it does not pin an exact key set. The new key should get its own presence assertion.

Scope

• .github/scripts/classify-infra-failure.sh (source of truth)
• render-classify-infra-failure.cjs regeneration → both workflow materializations (claude-review.yml, claude-security-review.yml)
• classify-infra-failure.test.sh — new assertions for the key on the substring path and its absence/null on pure-status paths
• Sequencing: land before or with Incident aggregator: dead-credential detection from consumer review-run annotations (scheduled, zero new secrets) #238's implementation so the incident body can use it.

Refs

#250 (ratification review that surfaced this), #238 (consumer), #248/#249/#251 (classifier lineage).

---

Filed by an AI agent (work-items:attend-queue lane) as raw intake — untriaged.

[kyle-sexton]

This was generated by AI during triage.

Triage disposition: briefed, delegable. Reproduced the claim directly in classify-infra-failure.sh: the substring path (elif ($text | contains(...authentication_error... billing_error... permission_error...)) then "auth") matches on which allowlist token appeared but the matched token is never captured into a variable, so the class: "auth" result carries no way to distinguish 401/402/403 — and api_error_status on this path is $last.api_error_status, which per the file's own header comment "exists only on the success variant," so it is null here too. Confirmed no existing error_type key anywhere in .github/scripts/ or .github/workflows/, and no docs/out-of-scope/ rejection on record. Additive-only change, existing test suite's assertions (key presence + leak denylist, no pinned exact key set) will not break.

Security-surface note (tier signal, not a label): this script's output feeds claude-review.yml and claude-security-review.yml via render-classify-infra-failure.cjs regeneration — dispatch this at the frontier/strongest capability tier per the loop-lane convention's security-surface routing, same as any change touching those workflows' generated content.

Agent Brief

Type: Bug
Summary: The substring-fallback classification path discards which published error-type token it matched, so auth-class failures carry no 401/402/403 discriminator downstream.

Current behavior: When the numeric API status is unavailable and classification falls back to matching known error-type substrings (authentication_error, billing_error, permission_error) in the raw text, the classifier returns class: "auth" with api_error_status: null and no other field indicating which of the three types actually matched.

Desired behavior: The classifier's structured projection carries a new field, error_type, holding the matched published error-type token (authentication_error / billing_error / permission_error / etc.) on the substring-matched path, and null when classification came from a numeric status or matched nothing in the allowlist. class and api_error_status are unchanged. The value must come only from the closed, published error-type allowlist — never from raw model/SDK text — to preserve log-hygiene safety.

Key interfaces:

• The classifier's structured JSON projection (today: subtype, is_error, num_turns, duration_ms, total_cost_usd, api_error_status, class) gains one new key: error_type.
• The ::error annotation's class=<token> term is unaffected — error_type is a projection-only addition, not part of that annotation string.
• Both generated workflow materializations (produced by the render/codegen step from this script) must reflect the regenerated output — regenerate, don't hand-edit the generated files.

Acceptance criteria:

• A substring-matched authentication_error / billing_error / permission_error failure produces error_type set to the exact matched token in the projection.
• A numeric-status-classified failure (401/402/403/429/5xx) produces error_type: null (the discriminator comes from api_error_status there, not from this new field).
• A failure matching none of the allowlisted types produces error_type: null.
• The existing test suite continues to pass unmodified in its current assertions; a new assertion covers error_type presence/value on the substring path and its null-ness elsewhere.
• Both generated workflow files reflect the regenerated script output (regeneration step run, not hand-edited).

Out of scope:

• Changing class or api_error_status semantics or values.
• Populating error_type from anything other than the closed published allowlist (no raw text/log passthrough).
• Incident aggregator: dead-credential detection from consumer review-run annotations (scheduled, zero new secrets) #238's consumer-side use of this field (tracked separately; sequencing note only — this item should land before or alongside it).

[kyle-sexton]

First-drain C3 ratification request (work-loop admission gate, fail-closed).

• Classification: C3 scoped, bug-fix-shaped — touches .github/scripts/** (executable surface, never mechanical per this repo's CLAUDE.md) plus a codegen regeneration into claude-review.yml / claude-security-review.yml (security-surface tier for whoever dispatches it).
• first_drain_complete is not set and this item carries no recorded dispatch ratification, so the gate queues it instead of dispatching.
• Intended dispatch on ratification: implement the Agent Brief posted above — add the error_type projection key on the substring-classification path, additive only, with a new test assertion; regenerate both workflow materializations rather than hand-editing them.

To ratify: reply on this comment per /work-items:attend-queue's ratification flow, then remove the needs-human label — the item returns to the autonomous frontier and dispatches on a later cycle.

This comment was written by an AI agent (work-items:work-loop lane).

[kyle-sexton]

This was generated by AI during the work-loop lane's second-opinion pass.

Correction to the ratification request above. An independent fresh-context verifier (no visibility into the analysis that produced the request) confirmed the technical claim, the additive/non-breaking analysis, and the regeneration-into-both-workflows scope — but challenged the shape: this reads as feature-shaped, not bug-fix-shaped. The classifier's own header documents today's projection as the intended contract (class-parity with the status mapping); nothing here is behaving contrary to spec. Every artifact of the item — the title, the fix section, the Agent Brief, and the "so the incident body can use it" sequencing note — describes capability addition for a not-yet-built consumer (#238), not a correction to broken behavior.

Consequence: under this vocabulary, feature-shaped C3 has no autonomous-dispatch path regardless of ratification. The "ratify → returns to the frontier → dispatches on a later cycle" premise in the request above does not hold if the shape is feature. This is a judgment call the verifier itself called close, not a slam-dunk — recording both readings for the operator to settle:

• Bug-fix-shaped (original framing): the operator triaging a class=auth failure gets a three-way checklist instead of one remedy — a degraded/incorrect operator experience, closer to a defect.
• Feature-shaped (verifier's reading): the classifier does exactly what its own spec says; this adds a new discriminator the spec never promised, feeding a feature (Incident aggregator: dead-credential detection from consumer review-run annotations (scheduled, zero new secrets) #238) that doesn't exist yet.

Recommend the operator's classification decision record the shape explicitly (C3 (bug-fix-shaped) or C3 (feature-shaped)) rather than defaulting to the request's original framing — the two shapes route to different dispositions in this repo's admission gate.

This comment was written by an AI agent (work-items:work-loop lane).

[kyle-sexton]

This comment was written by an AI agent (work-items:attend-queue lane), on the operator's behalf.

Ratification decision recorded. Operator reviewed the verifier's correction above and accepted it.

Work-class: C3 (feature-shaped)

Consequence: feature-shaped C3 has no autonomous-dispatch path under this repo's admission gate — this item stays needs-human (no role-label flip). Human implementation follows the Agent Brief posted earlier in this thread.

[kyle-sexton]

Automated triage claim from an AI agent (triage lane).

[kyle-sexton]

Automated gate-audit from an AI agent (autonomous triage lane, instance MELO-LAP-001-triage-20260729T123842Z). Machine-generated; verify before acting.

Gate upheld — and this issue's execution plan is stale

This item carries kind=ratify-c3, asking that it be admitted as C3 so the autonomous worker lane can run it. Audited by a three-seat panel (an Opus reviewer, an OpenAI Codex reviewer via the alternate-vendor path, and this coordinator's own read), with prior rationale withheld. Verdict: the gate stands, and the issue needs a rewrite before anyone — human or agent — picks it up.

Every file this issue names has been deleted

The "Scope" section targets three paths. None exist on main:

Path named in this issue	Status
.github/scripts/classify-infra-failure.sh	gone
.github/scripts/classify-infra-failure.test.sh	gone
.github/scripts/render-classify-infra-failure.cjs	gone

They were retired in a7c7145 — "refactor(workflows): repoint the review lanes at the claude-lane composites (PR-A2)" (#276), committed 2026-07-26T20:57 -0400. The last triage comment here (2026-07-27T01:54Z) landed after that refactor and did not catch it.

The live equivalents are .github/actions/claude-lane-outcome/classify.cjs, classify.test.cjs, and action.yml. So the underlying defect is real and still unfixed — the substring path still recognizes the published types but projects only the coarse class, discarding the discriminator — but the route described here no longer exists. The codegen-renderer approach in "Scope" was deliberately retired, not merely moved.

Why C3 ratification is declined

Re-derived against the current code, the change is C4 structural/cross-cutting, and it trips three of the exclusions that bar autonomous admission outright:

• Security-surface — YES. The projection feeds a public Actions annotation and a public PR comment. Public-log hygiene is load-bearing here (CLAUDE.md:44). The issue's "safe by construction" argument is a sound design requirement for the new key, but it is not yet an implemented guarantee, and raw errors[] text enters the matcher today.
• Dependency-pin — YES. Both consuming workflows reference the composite by pinned SHA, so end-to-end adoption requires a self-pin bump. This repo routes pin bumps to human absorption (CLAUDE.md:46, "Pin everything by SHA" — enforced repo-wide).
• Cross-cutting — YES. Delivery spans a shared composite, its test corpus, and two SHA-pinned consumers, in a mandatory two-stage landing (land the composite, then repin).

Hard-to-reverse: no. Reserved product/priority call: no — the field semantics are genuinely settled.

RECOMMENDED — rewrite the scope against the composite, keep it human-gated

Retarget this issue at .github/actions/claude-lane-outcome/: carry the matched literal from the closed seven-token allowlist into a new error_type key, set on the substring path only and null on numeric-status and unmatched paths; leave class precedence, api_error_status, and the bare class=<token> annotation term untouched; extend the existing canary/denylist test rather than pinning an exact key set. Then land the composite first and repin both consumers to the merged SHA as a separate reviewed step. Keep needs-human: the pin bump and the public-log surface both require operator absorption regardless of how well-specified the code change is.

Alternative — split it. Carve the pure classify.cjs + test change into its own item (still security-reviewed, but a single-file, revertible unit) and track the two-stage repin as a dependent follow-up. This unblocks the schema work sooner at the cost of one more tracked item. Worth choosing if #238 is waiting on the error_type key, since #238 consumes exactly that.

Note for the consumer

#238's acceptance criteria depend on this key. Its own blocked-by reference should point at whatever this issue becomes after the rewrite.

No labels were changed by this audit. The panel did not reach the confident consensus required to flip a gate, and on the exclusion tests it did not come close.

[kyle-sexton]

Automated triage lane: claim released.

[kyle-sexton]

Claiming for implementation (Wave 4): additive error_type projection on the substring path in .github/actions/claude-lane-outcome/classify.cjs (paths in the original issue body were retired). Composite-only PR; consumer re-pins are a follow-up in-session, not a new issue.