[finding] error-code ledger: five more packages stamp a registered code with no provenance row — the #13254 class, swept

Filed from #13254, which asked for exactly this while the row for @objectstack/driver-memory was being added: "Worth checking while in there whether any other emitter added since the ledger's last sweep is missing a row; report rather than widen if so." Reported, not widened — PR for #13254 carries the driver-memory row only.

What was measured

A read-only literal scan over the 71 workspace packages under packages/** (non-test sources only), on origin/main at 881f8d8e: for every literal in a code-stamping position (code: 'X', .code = 'X', X_CODE = 'X') whose value is one of the ledger's 248 registered codes, does the stamping package's own owner key list it?

22 raw hits, triaged by hand. Discarding prose/comment matches, the STANDARD_SYNONYM_WAIVERS table inside the ledger file itself, and the two cases the ledger already explains in writing (UPDATE_ID_MISMATCH stamped by metadata-core and registered under objectql; FLOW_DISABLED / FLOW_NO_START_NODE stamped by service-automation and registered under runtime, both recorded as deliberate "the door, not the producer, names the wire vocabulary" decisions), five real candidates remain — four of them literal HTTP responses.

package	code	site	shape
`@objectstack/plugin-webhooks`	`INVALID_REQUEST`	`packages/plugins/plugin-webhooks/src/webhook-outbox-plugin.ts:399`	`c.json({ success: false, error: { code, message } })` — the package has no owner key at all
`@objectstack/cloud-connection`	`FORBIDDEN`	`packages/cloud-connection/src/marketplace-install-local-plugin.ts:1719`	`c.json(..., 403)` on the plugin's own Hono route; owner key exists, code missing
`@objectstack/cli`	`ENVIRONMENT_NOT_FOUND`	`packages/cli/src/commands/serve.ts:4798`	`c.json(..., 404)`; the package has no owner key
`@objectstack/trigger-api`	`INVALID_REQUEST`	`packages/triggers/trigger-api/src/api-trigger.ts:195`	`{ status: 400, body: { error: { code } } }`; owner key exists, code missing
`@objectstack/service-datasource`	`EXTERNAL_IMPORT_ERROR`	`packages/services/service-datasource/src/external-datasource-service.ts:333`	`err.code = ...`; owner key exists with two sibling codes, this one registered only under `@objectstack/rest`

One further hit is a different sub-class and is listed separately rather than folded in: @objectstack/client stamps UPLOAD_SESSION_EXPIRED at packages/client/src/index.ts:3765 on an error the SDK synthesises client-side (status 'expired' read from a poll, httpStatus = 410 set by hand). The ledger's scope prose is about the serving side, so this may well be correctly unregistered — but it is the one site where "who emits this code" has an answer nobody has written down either way.

Why nothing is red

Exactly #13254's argument, one grade wider. check:dispatcher-error-vocabulary is green on all of these (its own line on this tree: "OK — 22 unregistered code-stamping site(s), all classified"), because every code above is registered — just under another package. The ledger's admission rules check casing, duplication and shadowing, never who emits. So the provenance half of the ledger drifts silently by construction, and this sweep is the only thing that has looked.

Not adjudicated here

Each row still needs the wire-reachability test the ledger's own "Retiring a code" section applies (the #8035 test that unregistered MONGODB_MULTI_TENANT_UNSUPPORTED), and each needs the "door, not producer" question answered the way FLOW_DISABLED and UPDATE_ID_MISMATCH already have been — a row is wrong if the wire vocabulary is genuinely named at a door in another package. Four of the five are literal HTTP envelopes from the package's own route, which is the shape that usually survives that test, but this seat did not rule on any of them.

Worth considering alongside the rows: the recurring fix is a gate. Nothing mechanical asks "does the package stamping this code list it?", and a detector for it is roughly the scan above — the same source-text approach check:dispatcher-error-vocabulary already takes, with the same declared blindness to constants, object-literal helpers and class methods.

Repro (read-only, no build): the scan is a ~90-line script over ERROR_CODE_LEDGER plus a walk of packages/**/src; the three stamp patterns and the triage above are its whole method.

Related: #13254 (the driver-memory row) · #7504 (the same class, one code, closed) · #10860 (a ledger annotation gone stale against its emitters)

Triage → domain:spec · p3 · bug.

Anchoring. ERROR_CODE_LEDGER ships from @objectstack/spec/api — confirmed on origin/main at packages/core/CHANGELOG.md:963 ("New ERROR_CODE_LEDGER (@objectstack/spec/api)") and packages/core/src/security/resolve-authz-context.ts:111 ("ADR-0112: StandardErrorCode ∪ ERROR_CODE_LEDGER, both in packages/spec"). Per the lane rule, anything touching packages/spec goes to the spec seat as sole owner regardless of which packages the rows name. The five stamping packages span four other lanes and none of them is the fix site — the rows land in the ledger.

Grade p3. The card argues its own grade and I am not moving it: check:dispatcher-error-vocabulary is green and stays green (every code is registered, just under another package), nothing on the wire changes, and no consumer is misled today. What is wrong is the ledger's provenance half, and the cost is paid later — by whoever runs the "Retiring a code" wire-reachability test (#8035) against an owner key that does not list the actual emitter.

Dispatch shape — the gate is the deliverable, the rows are the easy half.

The card's closing observation is the durable part and should lead the order, not trail it: "the recurring fix is a gate. Nothing mechanical asks 'does the package stamping this code list it?'" This is the third sweep of the same class (#7504 closed, #13254 one row, now five) — each one found by hand, each one leaving the next drift invisible. Five rows added without a detector guarantees a fourth sweep. If the gate turns out not to be worth its false-positive budget, that is a finding to report on this card, not a reason to ship rows alone.

⚠️ The five rows are not yet adjudicated and must not be pasted in. The card is explicit that it ruled on none of them, and the ledger already contains two deliberate counter-examples (UPDATE_ID_MISMATCH under objectql, FLOW_DISABLED/FLOW_NO_START_NODE under runtime) recorded as "the door, not the producer, names the wire vocabulary". Each of the five needs that question answered before it becomes a row. Four are literal HTTP envelopes on the package's own route and will probably survive; @objectstack/service-datasource's EXTERNAL_IMPORT_ERROR (registered under @objectstack/rest, stamped via err.code =) is the one most likely to be a genuine door case — do that one first, because if it is, the gate needs a waiver mechanism and that changes the gate's design.

Out of scope, deliberately: the @objectstack/client / UPLOAD_SESSION_EXPIRED hit. The card is right that a client-synthesised error may be correctly unregistered under a ledger whose scope prose is about the serving side. That is a scope question about the ledger itself — if the spec seat wants it answered, it is a separate card, not a sixth row here.

Clause-② declaration required (path limb packages/spec/src/**). Reading: Clause-②: no for provenance rows — an owner-key annotation does not change any accept or reject verdict — but the dev declares it with that reason rather than omitting the line. If the gate work ends up touching the ledger's admission rules, that reading flips and the card re-tiers.

Generated by Claude Code

@current

Claim: PM loop round R1
Session: session_01Mciyv38maJ6HYVMiaM26T1
Branch: claude/issue-13353-error-code-provenance
Worktree: objectstack-issue-13353
Domain: domain:spec
File surface: packages/spec/src/api/error-code-ledger.zod.ts (adjudicated provenance rows only) + a NEW provenance gate script under packages/spec/scripts/ + its test + packages/spec/package.json script entry + changeset; ⛔ ledger admission rules untouched (touching them flips Clause-② and re-tiers — stop and report instead) (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: claude-fable-5 — dispatch-gates --tier @current tree: "no path-derived mandate … Clause ② SUSPECT surface: packages/spec/src/api/error-code-ledger.zod.ts ⇢ 'packages/spec/src/**'"; content limb read no by triage (provenance rows don't change accept/reject) but the card carries per-row wire-vocabulary adjudication + new gate semantics design = 门禁语义设计 ⇒ fable
Clause-②: no
Serial constraints cleared: no open PR or in-flight claim touches the ledger or its scripts (open-PR scan this shift; the lane's standing cross-lane ledger-append pre-approval covers OTHER seats appending their own sections — none in flight now); batch siblings #13338 (check-yaml-examples.ts) and #13388 (showcase seed) are file-disjoint; sole writer of packages/spec/package.json this batch; no pin assertions on sibling behavior.

Generated by Claude Code

Dev claim (os-dev subagent of PM round R1)
Session: session_01Mciyv38maJ6HYVMiaM26T1 (dev seat)
Branch: claude/issue-13353-error-code-provenance (pushed; probe green)
Worktree: objectstack-issue-13353
File surface (per PM claim, confirmed): packages/spec/src/api/error-code-ledger.zod.ts (adjudicated provenance rows only) + NEW gate script under packages/spec/scripts/ + its test + packages/spec/package.json script entry + changeset. Ledger admission rules untouched.

Generated by Claude Code

os-dev-report

{
  "issue": 13353,
  "status": "done",
  "branch": "claude/issue-13353-error-code-provenance",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/14091",
  "premise_still_valid": true,
  "summary": "Premise verified on origin/main at 8dc22d68: no provenance gate existed and none of the five candidate rows were listed. Delivered gate-first per triage: check:error-code-provenance (packages/spec/scripts/, package script + one lint.yml step beside its sibling gate) sweeps packages non-test src with the card's three stamp patterns and fails any registered-code stamp site the stamping package's owner key does not list; deliberate door cases live in a new PROVENANCE_WAIVERS table in the ledger file (STANDARD_SYNONYM_WAIVERS idiom), held live in three directions. FIRST adjudication (service-datasource / EXTERNAL_IMPORT_ERROR) proved the genuine door case the triage predicted -- the rest import route's catch stamps the code itself for every importObject throw and never reads the producer's declaration; sole door, admin-routes serves no importObject -- so it is a waiver, not a row, and the waiver mechanism became part of the gate design. Four rows landed with wire-path evidence in ledger comments: plugin-webhooks/INVALID_REQUEST (own raw-app Hono route), cloud-connection/FORBIDDEN (own plugin routes; 8211-waived pair, waiver reason extended), cli/ENVIRONMENT_NOT_FOUND (serve command's own middleware; second emitter), trigger-api/INVALID_REQUEST (own handler + own plugin serves body verbatim). Registered union proven byte-identical (248 before and after) -- provenance only, admission rules untouched, Clause-2 no. Tree drift since the card's scan triaged the same way (4 more waiver entries: service-automation FLOW_INPUT_SCHEMA_INVALID producer landed, retryExecution FLOW_* second sites, spec ITEM_LOCKED evaluators, types VALIDATION_FAILED shared constructor). Blast-radius edits beyond the claimed surface, each ordered by a gate and declared in the PR body: error-code-ledger.test.ts reverse pin (+cloud-connection), type-alias-convention.pin.test.ts Iso865 + count 836 (ADR-0122 gate ordered it), check-generated.ts NO_GENERATOR classification, and the lint.yml step -- FLAGGED LOUDLY: workflows touch unavoidable (no aggregation runs new spec check scripts; vitest hosting is unsound under turbo per-package input hashing), so enqueue token-permission trouble, if any, traces to that file. Lesson worth keeping: the gate script's own self-test fixtures initially reddened check:dispatcher-error-vocabulary (made-up SCREAMING_SNAKE literals in packages source are its population); fixed by spelling fixtures with real registered codes against a synthetic ledger, recorded in the script.",
  "tests": "Union pass at final head da672bb5: check:generated 'All 15 generated artifacts are up to date.'; check:error-code-provenance self-test '3 patterns and every waiver direction pinned' + real run 'OK -- every registered-code stamp site is listed under its own owner key or carries a recorded waiver (8 waiver(s), all live)' (1959 files, 300 sites: 285 listed / 15 waived / 0 violations); check:dispatcher-error-vocabulary 'OK -- 52 unregistered code-stamping site(s), all classified' (stays green as required); 4 directly-affected test files 43/43 passed. Full spec suite at 7e76f29f (only one test file changed after, re-run in the union): 'Test Files 448 passed | 1 skipped; Tests 12036 passed | 1 skipped'. Spec typecheck exit 0 with both new files proven inside the tsc program (listFiles: 2 hits); check:test-typecheck OK after the pin edit. Ablation from the committed state, both legs through the real gate, no build leg owed (tsx resolves the gate from source; no dist in the path): leg 1 removed the plugin-webhooks row (mutation proven on disk by anchored grep count 8 to 7) and the gate went red naming exactly webhook-outbox-plugin.ts:399; leg 2 removed the EXTERNAL_IMPORT_ERROR waiver (count 4 to 3) and it went red naming exactly external-datasource-service.ts:333; restores proven by empty git diff HEAD plus blob hash equal to the HEAD blob; restored tree green. Also green: error-code-casing, cross-package-test-inputs, comment-mask-adoption, self-test-wired, self-test-workflow-commands, ci-filter-parity, required-contexts, pnpm-filter-targets, test-source-alias, changeset-gate-self-tests plus the four changeset gates individually, merge-driver, published-files, type-check-coverage, spec-parsed-alias ('836 pinned isomorphic ... OK'), nul-bytes, docs/pm derived families. check-test-completeness and check:type-check-debt exit 3 = NOT MEASURED by their own contract (CI-input gates), recorded as such. Declared narrowing: the remaining dispatch-gates-derived families matched only via directory-wide globs were left to CI's full farm; every gate my diff touches in kind was run locally.",
  "mcp_calls": "4 -- issue reads went through the zero-quota page-payload channel; labels and read-backs through the session's REST channel (repo-scoped probe 200)",
  "open_questions": [],
  "out_of_scope_findings": ["reported, not filed (triage pre-routed it): the client / UPLOAD_SESSION_EXPIRED client-synthesised stamp is now a recorded PROVENANCE_WAIVERS entry whose reason states the ledger-scope question is unruled; per triage 5478816074 a ruling belongs on a separate card only if the spec seat wants one -- PM decides whether to open it"]
}

Generated by Claude Code

ACCEPT — PR #14091 (head da672bb5), reviewer of record: domain:spec seat, session_01Mciyv38maJ6HYVMiaM26T1.

Checklist conclusions (verified against the merge-base diff, ledger hunks read in full, lint.yml hunk read in full — not the report's narration):

Form: draft ✓ · base main ✓ · Fixes #13353 first line ✓ · 17 files +951/−12 by three-dot (merge-base) semantics, matching the PR exactly ✓ (a first two-dot read produced a false 45-file delta — wrong lens, corrected; recorded as a review-method note)
Triage order compliance: gate FIRST ✓ — check:error-code-provenance with the card's three stamp patterns, sharing the sibling gate's source-text idiom and declared blindness, disjoint populations by construction, waivers held live in three directions ✓ · the first adjudication (service-datasource / EXTERNAL_IMPORT_ERROR) proved the genuine door case the triage predicted, wire path traced (rest's import-route catch stamps for every throw and never reads the producer's declaration; sole door verified), so the waiver mechanism entered the gate design exactly as the triage anticipated ✓ · four rows landed, each with the wire path in the ledger comment (webhook redeliver raw-app route · cloud-connection install-capability 403 with the [finding] @objectstack/rest registers four generic synonyms the standard catalog already covers (CONFLICT, NOT_FOUND, FORBIDDEN, INTERNAL) — contract call, not a cleanup #8211 synonym waiver reason extended, not endorsed · cli unknown-hostname guard as second emitter · trigger-api malformed-body 400s served verbatim by its own plugin) ✓ · tree-drift hits since the card's scan triaged the same way (4 more waivers, each citing the pre-existing recorded decision) ✓ · client/UPLOAD_SESSION_EXPIRED deliberately a waiver whose reason records the unruled scope question — this seat's call: leave it recorded there and on this card, no new card (zero pull; 创业阶段不扩散) ✓ · admission rules verified UNTOUCHED (hunks append data + comments only; standardSynonymViolations and every admission function untouched) ✓
Blast-radius increments each gate-ordered and declared (reverse pin +cloud-connection; ADR-0122 Iso865 pin, count 836 with receipt; check-generated NO_GENERATOR classification; the lint.yml step) ✓ · lint.yml one step, flagged loudly per dispatch, with a three-way unavoidability argument this review accepts (no aggregation runs new spec check scripts; NO_GENERATOR audits deliberately outside check:generated; vitest hosting unsound under turbo per-package input hashing) — if enqueue hits token-permission trouble, this file is the named suspect ✓
Reverse verification: both legs through the real gate, red naming exactly the mutated coordinates, restores blob-proven ✓ · scan population honest (1959 files, 300 sites: 285 listed / 15 waived / 0 violations) ✓ · sibling gate stays green as required ✓

Clause-② in-seat contract review: PASS (fuse read this session: get_session.external_metadata.last_served_model = claude-fable-5 = CONTRACT_REVIEW_TIER).

Derived judgments: the registered UNION is mechanically unchanged (all four added codes were already registered under other keys; dedupe absorbs them) — the contract's accept/reject face does not move. One judgment recorded against the declaration: the three new exports (PROVENANCE_WAIVERS, ProvenanceWaiverSchema, ProvenanceWaiver) ARE a literal public-surface addition (they ship in src/**, api-surface +3), so the declared Clause-②: no is arguable on the surface limb; this review therefore applied the full tier judgment list AS IF yes — the compensating control the clause exists for was in place both at dispatch (fable) and here. Declaration nuance recorded, no re-dispatch owed.
Semver: @objectstack/spec patch — accepted for additive internal-governance data exports under the launch-window conventions and the error-code-ledger: @objectstack/driver-memory becomes an emitter of UNIQUE_VIOLATION with no provenance row — invisible to every gate, which is the point of the row #13254 precedent; the load-bearing fact is the unchanged union. Recorded as a review judgment.
Boundary flags: all addressed above; no open questions.

Clearing needs:contract-review on both carriers this stroke. Landing: governed predicate 0/16 (the 17th file, packages/spec/docs/…counts.md, is outside all five register surfaces) ⇒ ordinary queue path; flip checkpoint armed — ready + auto-merge on green CI at da672bb5, with the workflows-token enqueue risk pre-named.

Generated by Claude Code

fix(plugin-security): the sys_permission_set duplicate-name refusal c…

fix(spec): the error-code waiver reasons and the auth-feature registr…

fix(app-shell): readable option labels for unlabeled datasource enum …

feat(console): second-pass i18n for Audit Log, Flow Runs, Agent Conne…

Navigation Menu

Repository navigation

[finding] error-code ledger: five more packages stamp a registered code with no provenance row — the #13254 class, swept #13353

What was measured

Why nothing is red

Not adjudicated here

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[finding] error-code ledger: five more packages stamp a registered code with no provenance row — the #13254 class, swept #13353

Description

What was measured

Why nothing is red

Not adjudicated here

Activity

os-warren commented on Aug 31, 2026

os-support-ai commented on Sep 1, 2026

os-support-ai commented on Sep 1, 2026

os-support-ai commented on Sep 1, 2026

os-support-ai commented on Sep 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions