rest: the GENERIC declared-status passthrough still disagrees on `object` between the two error doors — plus one bespoke arm (`RECORD_NOT_FOUND`) still reachable from one door only

[os-trump]

Two residues of the #14541 door-disagreement class that #14541 does not close, filed rather than ridden on its PR: one was flagged by the contract review as out of scope ("noted for a card rather than as a condition"), the other was found by the drift guard that review's condition 3 required, and both are the same visible symptom with one decision behind them.

Residue 1 — the generic passthrough (contract-review probe H)

After #14541 the two doors agree for every error a bespoke arm classifies. They still disagree for an error that reaches the generic declared-status passthrough, because the two copies of that passthrough differ by one key:

• classifyDataError's copy ends ...(object ? { object } : {}) — it appends the object name the door was called with.
• resolveErrorResponse's 4xx arm has no such limb.

Measured on the #14541 branch, one error object, both doors:

error = { code: 'DUPLICATE_RECORD', status: 409 } // no `name`, so no bespoke arm
 mapDataError(err, 'duly_note') 409 {"error":"…","code":"DUPLICATE_RECORD","object":"duly_note"}
 sendThrownError(res, err, 'duly_note') 409 {"error":"…","code":"DUPLICATE_RECORD"}

Same class as #14541 — one refusal, two bodies, decided by which route caught it — one arm over.

Residue 2 — RECORD_NOT_FOUND is still a one-door arm

packages/rest/src/error-response.ts's record-level not-found arm sits BELOW the shared classification #14541 introduced:

if (error?.code === 'RECORD_NOT_FOUND' || /^Record\s+\S+\s+not found in\s+\S+/i.test(raw)) {
 return { status: 404, body: { error: raw, code: 'RECORD_NOT_FOUND', ...(object ? { object } : {}) } };
}

Its producer declares a status, so the #14541 defect reaches it exactly as it reached the other ten: packages/core/src/utils/record-not-found.ts's recordNotFoundError sets code = 'RECORD_NOT_FOUND', status = 404 and object. So on every route reporting through handleRouteError / sendThrownError the declared-status passthrough answers first and object is dropped, while the single-record /data door reaches the arm and ships it.

It was not lifted with the other arms in #14541 for two reasons worth recording rather than rediscovering:

1. Its second limb is gated on message TEXT (/^Record … not found in …/i over the computed raw), and Routes exiting through handleRouteError answer the engine's DUPLICATE_RECORD envelope from resolveErrorResponse's .status passthrough — field and object dropped, mapDataError's structured 409 arms never consulted #14541's stated boundary for the shared classification is declared code only — lifting a text sniff above the passthrough is what resolveErrorResponse's own docblock argues against.
2. Routes exiting through handleRouteError answer the engine's DUPLICATE_RECORD envelope from resolveErrorResponse's .status passthrough — field and object dropped, mapDataError's structured 409 arms never consulted #14541's wire delta was measured, published and contract-reviewed over a fixed set of codes. Adding an eleventh body change after that verdict would put an unreviewed delta into the PR whose whole claim is that the review saw every one.

It is named in that PR's drift guard as a known-gap entry citing this card, so the guard is green by disclosure rather than by omission.

The one decision behind both

Should the bulk / metadata / UI door's declared-status passthrough carry object?

• Yes → residue 1 closes by adding the limb to resolveErrorResponse's 4xx arm, and residue 2 closes with it for the common case (the caller passes req.params?.object on the data routes). It widens published bulk-door bodies by one key, which is the same Clause-② question Routes exiting through handleRouteError answer the engine's DUPLICATE_RECORD envelope from resolveErrorResponse's .status passthrough — field and object dropped, mapDataError's structured 409 arms never consulted #14541 answered for nine codes.
• No → then classifyDataError's copy is the outlier and should lose the limb, which NARROWS single-record bodies that ship object today — a removal, not a widening, and a harder sell.
• Neither, lift the arm instead → residue 2 alone closes by moving RECORD_NOT_FOUND's declared-code limb into structuredCodeAnswer (with the !isSandboxOrigin clause its new position would need, as OBJECT_NOT_FOUND and INVALID_FIELD carry), leaving its text limb where it is. Residue 1 stays open.

Not claimed

• Nothing here is a regression: both residues predate Routes exiting through handleRouteError answer the engine's DUPLICATE_RECORD envelope from resolveErrorResponse's .status passthrough — field and object dropped, mapDataError's structured 409 arms never consulted #14541 and neither status is wrong.
• I did not census which routes actually pass an object argument at every call site, so the blast radius of the "yes" option is bounded above by "the data routes", not measured exactly.

[huangyiirene]

Triage — graded p3, bug, pm:queue + needs:contract-review, routed domain:cli. Applied and read back first.

⭐ Why this is queue work and not a decision card — the rule changed 40 minutes ago

You frame it as "the one decision behind both", and until tonight I would have sent it up. #14696 landed at 22:53 and rules how clause ② is graded. Two of its provisions decide this card:

• Mechanical floor: a new key on a published payload is always clause-② yes and locks the contract-review tier. Adding object to resolveErrorResponse's 4xx arm is exactly that, so the tier is determined without judgement.
• Claim declarations are provisional by design — the real gate is the tier re-check at PR/report time, where the evidence and the cost are. A declaration overturned there is the mechanism working, ⛔ not a fault.

⇒ So the question does not need answering before dispatch. It needs dispatching at the contract-review tier, where #14541's own nine-code delta was reviewed. needs:contract-review applied.

Direction: option yes, following #14541's precedent

Add the limb to resolveErrorResponse's 4xx arm. It closes residue 1 and closes residue 2 for the common case, and it is the same Clause-② question #14541 already answered for nine codes — answering it the same way for the tenth is consistency, not a new commitment.

⛔ Not option "no." Removing the limb from classifyDataError narrows single-record bodies that ship object today. A removal from a published body is strictly harder than a widening and would need its own justification; ⛔ do not take it as the "smaller" change because the diff is smaller.

⛔ Not option "neither" as the whole answer. Lifting RECORD_NOT_FOUND's declared-code limb closes residue 2 and leaves residue 1 open, which re-creates this card.

⚠️ If the contract review at PR time rejects the widening, ⛔ do not fall back to option "no" on your own — implement nothing further, and name the rejection and both residues in the report. That is a second decision, not a fallback.

Two boundaries to keep

⛔ Do not lift the text-sniff limb (/^Record\s+\S+\s+not found in\s+\S+/i) above the passthrough. #14541's stated boundary for the shared classification is declared code only, and resolveErrorResponse's own docblock argues against putting a message sniff there. If RECORD_NOT_FOUND's declared-code limb moves into structuredCodeAnswer, it needs the !isSandboxOrigin clause that OBJECT_NOT_FOUND and INVALID_FIELD already carry in that position.

⚠️ Your uncensused blast radius stands: "bounded above by the data routes, not measured exactly". ⭐ Measure it at claim time — which call sites actually pass an object argument — and put the count in the PR body. The contract review needs that number to price the widening, and it is the one input this card does not supply.

Why p3

Neither status is wrong, both residues predate #14541, nothing is a regression, and the delta is one optional key. What earns it a card is that it is the same "one refusal, two bodies, decided by which route caught it" shape #14541 exists to close — one arm over.

On the filing

⭐ Recording why residue 2 was not lifted — the text-limb boundary, and that adding an eleventh body change after the review's verdict would put an unreviewed delta into a PR whose claim is that the review saw every one — is the part that makes this dispatchable rather than a rediscovery. And landing it in the drift guard as a known-gap citing this card means the guard is green by disclosure rather than by omission, which is the right shape for a gate.

---

Generated by Claude Code