You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Filed unassigned by the dev seat working #8850, which moved the code that emits these. Not a claim, and not fixed under #8850 — that card is a no-behaviour-change move, and changing or registering a wire code is a behaviour question.
Measured on origin/main @ cc5c07b80
ErrorCode is StandardErrorCode ∪ ERROR_CODE_LEDGER, and ApiErrorSchema.code parses against exactly that union (#8846 restates this). Two codes the REST layer puts on the wire are in neither half:
Control, same measurement method: UNIQUE_VIOLATION, FEEDS_DISABLED, ERR_DATASOURCE_UNAVAILABLE and PROJECT_PROVISIONING are all present in the ledger — so the absence above is a real gap, not an artifact of where I looked.
RECORD_NOT_ACCESSIBLE is the more surprising one: its own source comment argues it uses "the STANDARD catalog code rather than a bespoke one (ADR-0112: generic permission conditions take the catalog)" — and it is not in the catalog.
The second half: FIELD_VISIBILITY_UNRESOLVED has zero coverage
A repo-wide search for the literal outside dist/ returns exactly two hits:
content/docs/deployment/production-readiness.mdx:146 — where it is documented to operators as a real signal to act on.
No test asserts it anywhere in the repo, in packages/rest or outside it. So an ADR-0106 D6 tier-3 refusal — the closed answer that exists specifically so an unhealthy security service cannot auto-open a disclosure hole — is advertised in the deployment docs and pinned by nothing. Prime Directive #10's shape: a documented capability with no proof it still fires.
This is measurement, not a claim that it is broken. It may work perfectly; nothing would notice if it stopped.
Why this is standalone rather than a sub-issue of #8846
#8846 registers "the set that #8087's gate reports", and that gate lives in packages/runtime over the dispatcher domains. It does not read packages/rest's emitters, so neither code above is inside #8846's completion scope. But the remedy lands in the same ledger file under the same ruling, so it should not be started before #8846 — hence the Blocked-by rather than a parallel edit of error-code-ledger.zod.ts.
Whichever is chosen, FIELD_VISIBILITY_UNRESOLVED also needs a pin — the ADR-0112 envelope minimum, codeandstatus (503), on the tier-3 path. A registration with no test leaves half the gap open.
⚠️ Worth a sweep rather than a two-line fix: these two were found incidentally while moving unrelated code, which suggests the population is larger than two. Report the number before registering it unexamined — the same instruction #8846 carries.
Refs: #8850 (where these were noticed), #8846 / #8087 (the ledger lane and the ruling), ADR-0112, ADR-0106 D6.
Blocked-by: #8846
Filed unassigned by the dev seat working #8850, which moved the code that emits these. Not a claim, and not fixed under #8850 — that card is a no-behaviour-change move, and changing or registering a wire code is a behaviour question.
Measured on
origin/main@cc5c07b80ErrorCodeisStandardErrorCode ∪ ERROR_CODE_LEDGER, andApiErrorSchema.codeparses against exactly that union (#8846 restates this). Two codes the REST layer puts on the wire are in neither half:StandardErrorCode?ERROR_CODE_LEDGER?FIELD_VISIBILITY_UNRESOLVEDsendFieldVisibilityFault(ADR-0106 D6 tier 3),503RECORD_NOT_ACCESSIBLEmapDataError's comment-access branch (#4630),403Control, same measurement method:
UNIQUE_VIOLATION,FEEDS_DISABLED,ERR_DATASOURCE_UNAVAILABLEandPROJECT_PROVISIONINGare all present in the ledger — so the absence above is a real gap, not an artifact of where I looked.RECORD_NOT_ACCESSIBLEis the more surprising one: its own source comment argues it uses "the STANDARD catalog code rather than a bespoke one (ADR-0112: generic permission conditions take the catalog)" — and it is not in the catalog.The second half:
FIELD_VISIBILITY_UNRESOLVEDhas zero coverageA repo-wide search for the literal outside
dist/returns exactly two hits:packages/rest/src/error-response.ts— the emitter (wasrest-server.tsbefore Extract rest-server.ts's error/fault-classification prologue — it is ADR-0112's concern, not the REST server's #8850);content/docs/deployment/production-readiness.mdx:146— where it is documented to operators as a real signal to act on.No test asserts it anywhere in the repo, in
packages/restor outside it. So an ADR-0106 D6 tier-3 refusal — the closed answer that exists specifically so an unhealthy security service cannot auto-open a disclosure hole — is advertised in the deployment docs and pinned by nothing. Prime Directive #10's shape: a documented capability with no proof it still fires.This is measurement, not a claim that it is broken. It may work perfectly; nothing would notice if it stopped.
Why this is standalone rather than a sub-issue of #8846
#8846 registers "the set that #8087's gate reports", and that gate lives in
packages/runtimeover the dispatcher domains. It does not readpackages/rest's emitters, so neither code above is inside #8846's completion scope. But the remedy lands in the same ledger file under the same ruling, so it should not be started before #8846 — hence theBlocked-byrather than a parallel edit oferror-code-ledger.zod.ts.Two questions the fix has to answer, not one
RECORD_NOT_ACCESSIBLEonto the catalog's existing permission code may be the honest answer given its own comment says that was the intent — but it is a wire change and needs its own decision.FIELD_VISIBILITY_UNRESOLVEDalso needs a pin — the ADR-0112 envelope minimum,codeandstatus(503), on the tier-3 path. A registration with no test leaves half the gap open.Refs: #8850 (where these were noticed), #8846 / #8087 (the ledger lane and the ruling), ADR-0112, ADR-0106 D6.