fix(rest): the batch door reaches the engine slot through wiredEngineOrLoud, so a wired-and-failing engine answers 503 on every wiring

[os-support-ai]

Fixes #18559

Clause-②: no

objectQLProvider's THIRD consumer — POST /api/v1/batch — now reaches the data-engine seam through wiredEngineOrLoud, the same helper its two sibling consumers already use. A wired-and-failing engine answers 503 SERVICE_UNAVAILABLE instead of the 500 INTERNAL_ERROR the handler's generic outer catch used to produce.

The card's reading REPRODUCES — and narrows

Driven at the real door on a real RestServer over a real ObjectKernel (⛔ not inferred from the card's prose, ⛔ not from a unit double), the 500 is there. But it is reachable on ONE of the two wirings only, and the card's 503/503/500 table silently mixes wirings:

wiring, engine wired and FAILING	before	after
single-kernel — the composition the open core boots	503 SERVICE_UNAVAILABLE	503 — unchanged
multi-kernel — a kernelManager is wired	500 INTERNAL_ERROR	503 SERVICE_UNAVAILABLE

On the single-kernel wiring computeExecCtx resolves the engine through its OWN wiredEngineOrLoud branch and raises before the batch handler's engine line runs, so this door already answered 503. The 500 was reachable only where that gate's KERNEL branch absorbs by design (wiredEngineOrLoud's RESIDUE note) and hands the engine question down. This is the same narrowing PR #17077 had to make for the sibling /meta/object/:name/state/:field door, and for the same structural reason.

⇒ the repair does not choose a new wire answer for this door. It removes a wiring-dependent divergence, leaving the answer this door already gave on the composition the open core boots. §2b of the census test measures both wirings side by side so that sentence is a reading rather than an argument.

Why this is NOT a re-collapse, and NOT a regression

The two facts always differed on the wire (500 against the 501 an absent engine gets), so the decidable test #14251 tightened — "NO consumer re-collapses a rejection into the undefined path" — was already satisfied at this consumer. What was wrong is that they differed through a catch-all that knows nothing about this seam. The adjacent 501 NOT_IMPLEMENTED arm tests !ql || typeof ql.transaction !== 'function', which a rejection never reaches.

The pin: fails before, passes after — both readings

packages/rest/src/objectql-slot-consumer-census.test.ts recorded the 500 explicitly as "RECORDED here, not ruled". That is the pin that moved, and the ablation is shown in the PR thread: with the test file at this branch and packages/rest/src/rest-server.ts reverted to the merge base, the new assertions FAIL; restored, they pass. ⛔ No test was skipped, disabled or quarantined.

Three things are pinned UNCHANGED, because they are what says no accept set moved:

• both ABSENCE shapes still answer 501 NOT_IMPLEMENTED, on BOTH wirings — no provider wired at all, and a provider that RESOLVES undefined (the seam contract declaring absence rather than failing);
• the fault MESSAGE is still withheld — Internal server error, INTERNAL_ERROR_MESSAGE, asserted plus a negative assertion that the driver's own sentence never reaches the wire;
• a non-async provider that throws SYNCHRONOUSLY reaches the same answer as one that rejects ([finding] at a RestServer provider seam a SYNCHRONOUS throw loses the whole execution context while an async rejection is absorbed — same fault, two different wire answers #13280).

Controls, including the one that came back dark

• §1's window predicate is controlled on BOTH axes: it must read 0 for emailServiceProvider + wiredEngineOrLoud and still FIRE (1) for emailServiceProvider + seamOrUndefined, the helper that slot really uses. Without the second half "3 of 3" is the only sentence the instrument can produce.
• ⚠️ A dark control, declared rather than hidden. On the MULTI-KERNEL wiring a batch request carrying a real operation continues past the engine line into resolveProtocol/loadObjectItems, which the harness's auth-only kernel cannot serve — measured, a HEALTHY engine answers 500 INTERNAL_ERROR there too. A 500 read on that wiring with a real op is therefore ambiguous between "the seam answered" and "the harness ran out of kernel". The healthy control uses { operations: [] }, which returns inside the door after the engine line and before the protocol is touched, so the engine fact is the only variable. §2b adds the control the multi-kernel harness cannot give: on the single-kernel wiring a healthy engine SERVES the same real operation with 200.

The /actions precedent does NOT transfer — measured, not assumed

PR #18760 (card #18540) was handed over as the precedent for this family. It is a different defect on a different axis, in a different package:

• [finding] a NON-sandboxed crash at /api/v1/actions ships its native error message verbatim, where the /data door sanitises the identical crash #18540 is a MESSAGE leak: "the status is already right here; what leaks is the sentence." Its remedy withheld prose. Here the message is ALREADY withheld — INTERNAL_ERROR_MESSAGE is on the wire today — and what moves is the STATUS.
• Its mechanism (classifyDataError, looksLikeInternalErrorLeak, errorFromThrown, UNCLASSIFIED_FAULT, deps.error) lives in packages/runtime/src/domains/actions.ts. None of it is on this door's path: POST /api/v1/batch is packages/rest/src/rest-server.ts reaching the wire through handleRouteError → resolveErrorResponse.
• The errorFromThrown branch that must survive (an error declaring its own HTTP status is served with it) is untouched here: nothing in this diff is in that file, and the branded AuthzStoreUnavailableError this repair raises IS an error declaring its own status — it is served with it, which is exactly how the 503 reaches the wire.

The precedent that DOES transfer is #15405 / PR #17077 — same slot, same file, same helper, the sibling consumer — which the card itself names as the pattern to copy.

Clause ② — declared no, from this diff

Clause-②: no above is derived from the delivered diff, not inherited:

• No new error code. SERVICE_UNAVAILABLE is an existing StandardErrorCode, already in packages/spec/src/api/error-code-ledger.zod.ts mapped to 503, and already emitted by the sibling door for this same fact. AGENTS.md and the PM protocol are explicit that a NEW code is always yes; this is not one.
• No new export, no new payload key, no new envelope. The 503 wears the same flat { error, code } shape the 500 wore.
• Nothing that was refused becomes served, and nothing that was served becomes refused: both sides are faults, and both absence shapes are pinned unchanged.
• It is a pull-back to a DECLARED contract — wiredEngineOrLoud's own table and AUTHZ_STORE_UNAVAILABLE_STATUS = 503. The PM protocol states that pulling back to an already-declared contract does not touch clause ②: 「条款②只指已发布契约面,拉回已声明契约不触它」.
• The arm slot is deliberately EMPTY. Neither (widening) nor (narrowing) is truthful here: no accept set widens, and nothing that was accepted is now rejected. no (widening) is malformed by construction, and a fabricated (narrowing) would carry a false BREAKING declaration against a patch changeset.

This is the same declaration PR #17077 landed and its acceptance confirmed for the identical move at the sibling consumer (404 → 503 on a published route), on the same three grounds.

⚠️ Declared conflict, stated rather than quietly resolved. The dispatch fence for this card said that if the remedy moves a status code it should ship as minor with a BREAKING banner and an ADR-0087 disposition. Measured against AGENTS.md's own arms, that spelling has no truthful form here: minor + BREAKING is what a declared (narrowing) owes, and this diff narrows nothing. The changeset is patch per AGENTS.md: "A bug fix in a released package takes a patch changeset — never none, and ⛔ never skip-changeset". @objectstack/rest publishes (files: ["dist", "README.md", "CHANGELOG.md"], not private), and the changed door is in the published bundle — so skip-changeset is refused on a measurement, not on the file's look.

⚠️ The one thing this PR does not carry: a maintainer's word on THIS card

Stated plainly because it is the half a reviewer should decide, and this PR is a draft for exactly that reason.

The card reserves a per-consumer wire ruling: "A public door changing its wire answer is the per-consumer wire ruling #14251 reserves … and the ruling half is nobody's to assume." For the sibling card #15405 that ruling was obtained explicitly — it sat at pm:awaiting-maintainer until the maintainer's batch move, quoted verbatim on that thread with the criterion 「恢复一条既有修复的不变量,属具名不升级类,⛔ 无产品语义分叉」. No equivalent maintainer act exists on #18559: triage moved it straight to pm:queue.

What this delivery offers in its place is a reading the card's filer did not have, and it is why the work was written rather than handed back: this door already answers 503 for this fact on the composition the open core boots. That reframes the remedy from "pick a wire answer for a public door" to "remove a divergence between two compositions of one server". If a reviewer weighs it the other way, the revert is one commit and the PR is a draft.

⛔ Not widened into the undeclared-5xx band at /meta or /mcp — that is #5667's recorded decision with #12281 as the card for the declared limb, and reversing a recorded decision is a decision, not an execution.

Acceptance notes

• noted, not filed: on the MULTI-KERNEL wiring, a batch request whose ops survive the engine probe answers 500 INTERNAL_ERROR when the resolved kernel carries no metadata protocol, because resolveProtocol/loadObjectItems fault under the generic outer catch. Observed only in this file's harness (an ObjectKernel with auth and nothing else), which is not a supported deployment shape — a real multi-kernel host registers the protocol. ⛔ Not a reproducible defect against a supported wiring, so it is not one of the three filing classes; recorded because it is what makes a naive 500-based control on that wiring ambiguous, and the next reader of this harness will meet it. Successor who would touch this file: whoever extends objectql-slot-consumer-census.test.ts for a FOURTH consumer.
• noted, not filed: the batch handler calls this.resolveExecCtx(environmentId, req) without the .catch(rethrowAuthzStoreUnavailable) that many sibling call sites in rest-server.ts carry. Measured, it needs none: computeExecCtx re-raises the branded outage from its own catch and this handler's outer catch serves it with its declared status — which is how the single-kernel 503 above reaches the wire. Observation, not a defect, and ⛔ not touched here.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

⚠️ 1 changed file(s) yielded no anchor (packages/rest/src/rest-server.ts), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files. Nothing else in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 1 changed package(s)).

What this run could not see

• 1 changed file(s) yielded no anchor (packages/rest/src/rest-server.ts) — pages documenting those are invisible to this run
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 15 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 627382b9ded6d1dcca6cf6501c0bca80c465af52 → packageMentionDocs.