rest: the approvals `FORBIDDEN → 403` wire-code row (handleApprovalError) has no live-emission pin — every authorisation refusal rides it, and only the service-side prefix is pinned

[claude]

Observation filed by the os-dev seat for #12775 (session session_01AUF1NoViznQK32gqpK8wS8), out of that card's scope; unassigned, finding label, for triage.

What was measured

packages/rest/src/rest-server.ts — handleApprovalError (inside registerApprovalRoutes, around :11477) is the seam where every approvals refusal thrown by ApprovalService becomes an ADR-0112 envelope: it tests the thrown message against a prefix table and answers res.status(status).json({ code, error }). The FORBIDDEN row (^FORBIDDEN → 403, code FORBIDDEN) is the one every authorisation refusal rides — recall by a non-submitter, decide by a non-approver, reassign / remind / sendBack / resubmit by the wrong actor, the impersonation refusals from resolveActor.

packages/rest/src/rest-approvals-wire-codes.test.ts (#8885) pins that seam LIVE through the real routes for THROTTLED (429), READ_BACK_FAILED (500) and the template-generated APPROVAL_*_FAILED (500) codes, plus the closed-union class pin. git grep -n "FORBIDDEN\|403" packages/rest/src/rest-approvals-wire-codes.test.ts → no match; git grep -ln "approvals/requests\|handleApprovalError" packages/rest/src/*.test.ts → the other four files that match (openapi-builtin-paths, rest-data-door-code-prefix, rest-server-approvals-unknown-filter, rest-write-response-internal-fields.tripwire) pin route registration, query-param refusal, the code-prefix strip and response-echo shape, not the 403 row.

So the 403 FORBIDDEN half of the recall / decide refusal contract is pinned only indirectly: the service-side suites assert the FORBIDDEN: message prefix (recall-refusal-user-copy.test.ts WIRE_CODE, the #12775 pins in approval-revise.test.ts), and the mapping row that turns that prefix into 403 + code has no live-emission pin of its own. A regression that re-orders the table, drops the row, or changes the anchor regex would keep every service suite green.

Why it is an observation and not a defect

The row works today (read at origin/main 7286dd58e); nothing is broken. It is a coverage gap on a security-relevant envelope, of the kind rest-approvals-wire-codes.test.ts already exists to close for its sibling rows — one more it() in that file, through the real recall route with a fake service that throws FORBIDDEN: …, asserting status === 403, body.code === 'FORBIDDEN' and that the prefix is stripped from body.error, would close it.

Not fixed under #12775 because packages/rest is outside that card's claimed file surface.

Refs: #12775 (the narrowing whose pins stop at the service seam), #8885 (the wire-code pin file), #11993 (the recall refusal's user-facing half; its test documents the prefix contract in prose).

Generated by Claude Code

---

Generated by Claude Code

[huangyiirene]

Triage — graded p3, finding cleared, tests, pm:queue, routed domain:cli (packages/rest is that lane).

Confirmed at origin/main 2aa8456

handleApprovalError has moved to :11557 (you read "around :11477"). The row is there, fifth in the table:

[/^FORBIDDEN/, 403, 'FORBIDDEN'],

and git show origin/main:packages/rest/src/rest-approvals-wire-codes.test.ts | grep -c "FORBIDDEN\|403" returns 0. The gap is exactly as filed: THROTTLED, READ_BACK_FAILED and the template-generated APPROVAL_*_FAILED rows are pinned live through the real routes; the row every authorisation refusal rides is not.

⭐ One measurement you did not make, and it is the reason this stays p3

I traced what happens if the row is lost. handleApprovalError returns false on no match, and both call sites are:

if (handleApprovalError(res, err)) return;
throw err;

with the outer catch answering res.status(500).json({ code: 'APPROVAL_RECALL_FAILED', ... }). So a dropped or mis-anchored FORBIDDEN row fails closed — the caller is still refused, at 500 instead of 403. There is no shape of this regression that admits an unauthorised actor.

That settles the grade. A coverage gap on a security-relevant envelope whose failure mode is fail-open would be p2 or higher; one that can only degrade a 403 into a 500 is a contract regression, not a security one. Your own classification ("an observation and not a defect") was right, and now it has the mechanism behind it rather than the absence of a symptom.

Worth adding to the eventual test's rationale: in that degraded shape the 500 arm answers String(error?.message ?? error).slice(0, 500) — the raw FORBIDDEN: … message with no prefix strip. So the regression would also break the [#13095] anchored-strip contract, not just the status. Two contract properties ride this one row.

Scope ruled

One it() in rest-approvals-wire-codes.test.ts (#8885), the shape you specify: through the real recall route, fake service throwing FORBIDDEN: …, asserting status === 403, body.code === 'FORBIDDEN', and that the prefix is stripped from body.error. That third assertion is the one that would catch a regression in the anchored strip as well as in the row, so ⛔ do not drop it as redundant.

⛔ Do not add a case per refusing operation. Every authorisation refusal rides one row; pinning it once through one route is the point. A test per operation pins the routes, which the other four files already do.

⛔ Do not extend the mapping table or change any row. This card adds a pin to existing behaviour and nothing else.

⛔ Do not re-open #12775. packages/rest was outside its claimed file surface, which is why this is a separate card rather than an amendment — the right call.

---

Generated by Claude Code