[objectstack-fleet]

Fixes #25120

Clause-②: no (narrowing)
Metadata-protocol: none

The /mcp HTTP bridge now reads objects from the protocol's merged view, the read REST serves. list_objects and describe_object see every object GET /api/v1/meta/object lists to the same caller. The API-exposure gate the data verbs ask refuses a package object declared apiEnabled: false, and refuses every object of a disabled package 404 OBJECT_PACKAGE_DISABLED on every verb, aggregate_records included, as REST refuses it. Nothing is copied into the metadata service: a second copy would be a second thing to keep in sync.

This round: the review of record on d19b65bf1c

The contract-tier review of record (comment 6328012432, VERDICT FAIL) found one widening. The gate read the protocol's OBJECT_PACKAGE_DISABLED refusal as "no declaration", on the premise that the data plane then refuses with that code. Five of callData's six arms reach the protocol, whose registry gate refuses it. The aggregate arm does not: it asks the engine, and the engine serves a disabled package's objects. So on d19b65bf1c, aggregate_records served a disabled package's object declared apiEnabled: false wherever the metadata service held a copy, where the copy had refused it 404 OBJECT_API_DISABLED. Contract item 6 and the changeset's "Also changed" sentence were false for that verb.

Closed here. callData's gate refuses a disabled package's object itself, with the protocol's own error, so every arm answers 404 OBJECT_PACKAGE_DISABLED. The same rows also close a hole that predates this PR (review boundary flag ③ 5): aggregate_records served a disabled package's exposed object on every kernel, before this PR and after it. Both are pinned below.

REST's answer was measured on the same kernels, through a RestServer served over each kernel's protocol. It refuses both objects 404 OBJECT_PACKAGE_DISABLED on every well-formed /data record request. It answers a body that is not a record 400 VALIDATION_FAILED first, because enforceApiAccess reads the refusal as "no declaration" and its request gate runs next. The dispatcher's /data door asks this gate early too, as the twin of enforceApiAccess. With the refusal thrown at that early ask, the door answered those three malformed bodies 404 OBJECT_PACKAGE_DISABLED, a new divergence from REST (measured on both kernel shapes, both objects). So the early ask keeps REST's reading, callData refuses, and the door now answers every request what REST answers. That is pinned too.

The defect, measured on base 4e2c42f363

buildMcpBridge answered list_objects and describe_object from the metadata service (listObjects() / getObject()). The exposure gate every runtime data door asks (refuseUnexposedDataAction in packages/runtime/src/action-execution.ts, called by callData) read the same service and treated a missing copy as "no declaration", that is, allowed. That service holds a copy of an object only where something put one there. On a kernel with an environmentId, the full boot bridge is off. That covers createStandaloneStack (os dev as env_local, os serve, os start) and the cloud single-environment runtime. So an object that a package or a plugin registers in the SchemaRegistry during the boot gets no copy.

Real kernels (ObjectKernel + MetadataPlugin + ObjectQLPlugin over better-sqlite3 :memory:). The environmentId shape uses createStandaloneStack's plugin options verbatim. The fixture package has two objects, one declared apiEnabled: false, registered through the kernel's manifest service:

shape, when the package registered	metadata.getObject	REST lists	bridge lists	describe	gated query	gated create
env_local, during the boot	absent	2	0	null	served	reached the driver
env_local, installed after the boot (source: 'marketplace')	copied	2	2	served	404	404
no environmentId, during the boot	copied	2	2	served	404	404
no environmentId, installed after the boot	copied	2	2	served	404	404

The first row is the card's live reading in miniature: a short list presented as a complete totalCount, "not found" for every package object, and query_records served. The other three rows are controls: the boot bridge and the late-manifest bridge already copy, so they were right and must stay right.

The gate half is real. The same object declared apiEnabled: false was served by query_records, and create_record got past the gate to the driver. The runtime dispatcher's /data door shares the gate, and on that shape it answered GET /data/qa_pkg_gated with 200 and POST reached the driver. RestServer refused the same object, because its gate already reads the protocol's by-name read.

The multi-tenant (environmentId kernel) path. The merged read is per environment there. The bridge resolves protocol through deps.resolveService(context, 'protocol', envId), the same scoped seam metadata and the skill read use. Each environment kernel's getMetaItems reads its own ObjectQL registry (readFlattenedMetaItems: "the SchemaRegistry is owned by THIS kernel's ObjectQL instance"). Measured: two environmentId kernels behind one host each list and gate their own package and none of the other's. That run is red with the fix ablated, because both lists come back empty.

The stdio half measures the same defect. That transport is held off by the dispatch, so this is reported and not widened. Same fixture, env_local, during the boot, driven through the real MCPServerPlugin stdio session: list_objects gave {"objects": [], "totalCount": 0}, describe_object gave Object "qa_pkg_open" not found, and query_records on the apiEnabled: false object was served (total: 0). The control without an environmentId lists, describes and refuses OBJECT_API_DISABLED.

What changed

• packages/runtime/src/domains/mcp.ts. list_objects / listObjectsDiagnosed and describe_object read getMetaItems({ type: 'object' }) through the existing McpMergedMetadataRead seam. This is the shape commit e783e16 gave the skill read. The unwrap moved into one helper (readMergedItems) shared by the skill read and the object reads, and the skill read's behaviour is unchanged. describe_object answers from the same listing, so every listed object can be described. The three outcomes are the skill read's. With no merged read on the host, the code reads the metadata service as before. When the merged read answers, it is served. When the merged read throws, the error goes to the client and nothing falls back. listObjectsDiagnosed keeps asking listDiagnosed('object') for the partial verdict.
• packages/runtime/src/action-execution.ts. The exposure gate reads the object by name through the protocol, the read RestServer's own gate makes (enforceApiAccess). It uses the execution face (getMetaItemForExecution) where the protocol has one, and getMetaItem otherwise. A host whose protocol has no by-name read keeps reading the metadata service. A merged read that throws falls back to the metadata service's copy, the source this gate read before: an outage must not widen exposure, and the caller's fail-open catch is unchanged.
  • A refusal OBJECT_PACKAGE_DISABLED is a refusal, never a read failure. readExposureDeclaration throws it (isObjectPackageDisabledRefusal), and refuseUnexposedDataAction answers it by call site (disabledPackage).
  • callData asks with 'refuse'. The protocol's own error (code, status 404, object) is thrown past the fail-open catch, on every arm, the aggregate arm included.
  • The dispatcher's /data door asks early, before its request gate, with the default 'defer'. That is "no declaration", as enforceApiAccess reads it, so a malformed body is answered by the request gate first, as on REST. A well-formed request is refused when it reaches callData.
• packages/runtime/src/domains/data-write-request-gate.test.ts, a fixture re-judged. Its dispatcher door used to model the gate's old source (a metadata fake answered from the registry). The rig's protocol cannot read without a metadata store, so with this change that door passed only through the outage fallback. The registry-backed by-name stub now lives in bootStore (stubObjectReads) and serves both doors, and the dispatcher door is given no metadata service. A gate that stopped reading the protocol reds 12 of its rows (measured on d19b65bf1c). 73 of 73 rows are green with the fix.
• .changeset/25120-mcp-package-objects.md. A patch for @objectstack/runtime, with the BREAKING banner and the ADR-0087 disposition not-required (no-migration-prescription). Both declaration lines are in the body. Its "Also changed" sentence now states the disabled-package refusal on every verb.

Contract

Every input whose answer changes, old to new:

1. list_objects (POST /api/v1/mcp) on a kernel with an environmentId, for an object a package or plugin registered during the boot. Old: omitted, with totalCount short and no partial. New: listed. The non-sys_ set equals what GET /api/v1/meta/object serves the same caller.

2. describe_object and validate_expression on such an object. Old: Object "NAME" not found. New: described (fields, label, enableFeatures).

3. query_records, get_record, aggregate_records, create_record, update_record, delete_record on such an object declared enable.apiEnabled: false. Old: served, and the writes reached the store. New: 404 OBJECT_API_DISABLED, and the store is never asked. With an apiMethods whitelist, a verb it leaves out gets 405 OBJECT_API_METHOD_NOT_ALLOWED with allowed.

4. The same declaration on every other door that asks this gate (the runtime dispatcher's /data door, the @objectstack/hono catch-all; callData under business actions and declarative endpoints). Old: served. New: the same refusals as item 3, the codes RestServer answers.

5. A disabled package's objects, where the metadata service still holds a copy. For example, a kernel without an environmentId. Old: list_objects listed them and describe_object described them, while REST listed neither. New: omitted and not found, as REST answers.

6. Each of the six MCP data verbs on an object of a disabled package, whatever the object declares. New, on every kernel shape: 404 OBJECT_PACKAGE_DISABLED, the protocol's own error, refused at the gate with the store never asked. That is the code and status RestServer answers for the same object on every /data record route. Old:

   • declared apiEnabled: false, with a metadata copy (a kernel without an environmentId; a marketplace install): 404 OBJECT_API_DISABLED on all six verbs;
   • declared apiEnabled: false, with no copy (an environmentId kernel, registered during the boot): 404 OBJECT_PACKAGE_DISABLED on the five verbs that reach the protocol, and aggregate_records served;
   • exposed, on every shape: 404 OBJECT_PACKAGE_DISABLED on the five, and aggregate_records served. This hole predates this PR: the aggregate arm never asked the protocol.

   No refusal's status moves, and aggregate_records stops serving.

7. The dispatcher's /data door on an object of a disabled package. A well-formed request: 404 OBJECT_PACKAGE_DISABLED, as REST answers. Old: the same for an exposed object; 404 OBJECT_API_DISABLED for one declared apiEnabled: false with a copy. A body that is not a record (POST /data/:object or PATCH /data/:object/:id with an array, POST /data/:object/query with { "limit": "ten" }): 400 VALIDATION_FAILED, as REST answers. Old: the same for an exposed object; 404 OBJECT_API_DISABLED for one declared apiEnabled: false with a copy. Nothing is served either way. Only which refusal comes first moves, to REST's order.

8. An object whose served definition differs from the metadata service's copy (for example, a stored environment row layered over it). Old: MCP discovery and the gate read the copy. New: they read the definition REST serves.

9. list_objects / describe_object while the metadata store cannot be read. Old: the metadata service's listing. New: the protocol's 503 SERVICE_UNAVAILABLE error envelope, which is what GET /api/v1/meta/object answers and what the skill prompt read already answers.

Unchanged: objects that already had a copy are listed and gated as before. That covers every object on a kernel without an environmentId, a marketplace install on any kernel, and a runtime-authored object. A host with no merged read keeps reading the metadata service. The gate's outage branch judges the copy, as before. packages/mcp is untouched.

Pins

packages/runtime/src/domains/mcp-package-object-discovery.test.ts, 70 cases. The pins read the bridge the real /mcp entry (HttpDispatcher.handleMcp) hands the MCP service, so list_objects renders totalCount from listObjectsDiagnosed().objects:

• For each of the four rows above: list_objects lists the package's objects, its non-sys_ set equals GET /meta/object's for the same caller, and it is not partial. describe_object answers both objects, including apiEnabled: false. Each of the six data verbs refuses the gated object with { code: 'OBJECT_API_DISABLED', status: 404 }, and no protocol data method or engine aggregate is called. Control: query_records serves the exposed object.
• A disabled package, on both kernel shapes (the copy's existence a precondition on the shape that copies):
  • its objects are neither listed nor described;
  • REST answers both objects 404 OBJECT_PACKAGE_DISABLED on each of its six well-formed /data record requests, read off a RestServer served over the same kernel's protocol;
  • the dispatcher's /data door answers each of nine requests what REST answers: the six well-formed ones and three whose body is not a record;
  • each of the six MCP data verbs refuses both objects, the one declared apiEnabled: false and the exposed one, with { code: 'OBJECT_PACKAGE_DISABLED', status: 404 }, and no protocol data method or engine aggregate is called.
• Two environments behind one host each list, describe and gate their own package and not the other's.

Red before, green after, on e471998c5, whose code and pin blobs c0fb1c715 carries unchanged (it changes only the changeset). Each leg's direction and count was predicted before running, and each landed as predicted. Mutations were landed and restored by scripts/ablation-replace.mjs (anchor 1 to 0, blob changed; restored blob equals HEAD, git diff HEAD empty), under the verify lock. The whole-file leg ran under a script with an EXIT/INT/TERM trap. It restored with git checkout HEAD and checked blob equality and an empty git diff HEAD. The runtime's own source is read by relative import, so no leg depends on a dist/ build.

leg	mutation	result
main	both source files at base abc25a353 (blobs 616639b765, 5d19bd3b7a)	38 failed, 32 passed. Failed: env_local during-boot list, describe and six verbs (8); four two-environment pins; disabled package without an environmentId: listing, door parity and twelve verb rows (14); disabled package on env_local: twelve verb rows (12)
discovery	readMergedObjects answers undefined (the metadata service read)	5 failed, 65 passed
gate	readExposureDeclaration always reads the copy	33 failed, 37 passed. Failed: env_local during-boot six verbs; two two-environment gate pins; disabled package without an environmentId: twelve verb rows and door parity; disabled package on env_local: twelve verb rows
refusal	OBJECT_PACKAGE_DISABLED read as "no declaration" again (the reading on d19b65bf1c)	24 failed, 46 passed. Failed: every disabled-package verb row on both shapes. The four aggregate_records rows answer SERVED; the other twenty reached the protocol before it refused
door twin	disabledPackage defaults to 'refuse' (the refusal thrown at every ask)	2 failed, 68 passed. Failed: door parity on both shapes, where a body that is not a record answers 404 OBJECT_PACKAGE_DISABLED and REST answers 400 VALIDATION_FAILED
fix	HEAD	70 passed; rig 73 passed

The first attempt at the gate leg was a no-op. Its replacement text already occurred twice in the file, so ablation-replace.mjs refused it and ran nothing. It was re-run with a unique replacement, and the row above is that run. The rig leg (12 failed, 61 passed) was measured on d19b65bf1c and not re-run: the rig and its healthy path are unchanged.

Local verification

On c0fb1c715, the final commit, with origin/main abc25a353 merged in and the workspace built (turbo run build --filter=!@objectstack/docs, 76 tasks, exit 0). Every heavy run went through the verify lock, and each line cites the lock's VERDICT line.

• @objectstack/runtime unit layer (vitest run --project local), every file in one run: 433 files passed; 6864 tests passed, 19 skipped, 0 failed. That is 29 more than on d19b65bf1c, the pin's 41 cases now 70. test:repo is CI's: the diff touches none of its files, and the derivation does not name it.
• pnpm --filter @objectstack/runtime typecheck: exit 0 (tsc --noEmit, and check:test-typecheck OK: 27 files, 190 errors, 68 pinned signatures held in the ledger). Both edited test files are in the tsconfig.test.json program (--listFilesOnly). A first run, before the peer @objectstack/driver-turso was built, reported TS2307 on an untouched file; that was build state, not this change.
• node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack: 68 commands, each exit code captured before any pipe, all exit 0. Two first answered 3 (PREREQUISITE NOT MET). check:dual-build-cjs-loads had no full build yet; check:type-check-debt timed out queueing for the lock behind another session's run. Both were re-run after the full build, exit 0. The 10 families declared WIDE-population were run too, all exit 0.
• --ran reconciliation: ✓ dispatch-gates --ran: 68 derived famil(ies) accounted for — 68 run, 0 NOT-MEASURED (a DERIVED zero — all 68 recorded an exit code and none of them is 3).
• pnpm lint (eslint . --no-inline-config): exit 0.
• node scripts/check-changeset-no-major.mjs --base origin/main --event PAYLOAD, with PAYLOAD a pull_request event carrying this body: exit 0. ✓ This diff introduces no major bump. and ✓ LEVEL AXIS: this PR declares clause-② no (narrowing) and metadata-protocol none .... node scripts/check-adr-0087-registration.mjs --base origin/main: exit 0, ✓ check-adr-0087-registration: 1 declared-breaking changeset(s), each carrying an ADR-0087 disposition.
• node scripts/check-closing-keyword-parity.mjs --body on this body binds #25120 alone.
• The full dogfood battery, once on this head (pnpm --filter @objectstack/dogfood test, no shard): VERDICT command-exit 0; Test Files 287 passed, 3 skipped (290); Tests 2395 passed, 18 skipped (2413); no failure.

CI on c0fb1c715: 41 check runs, 34 success and 7 skipped by design, 0 failures. The five required contexts are success: Lint & Repo Gates, TypeScript Type Check, Test Core, Build Core and Governed Surface Queue Guard.

Acceptance notes

• Card acceptance item 3 (walked on a cloud environment with a marketplace app installed): NOT MEASURED. The cloud host lives in objectstack-ai/cloud, outside this session. In this repo the shape is the environmentId kernel, pinned above with createStandaloneStack's options. On that shape, a package registered during the boot is the one that had no copy. This repo's marketplace install and rehydrate register after the boot and were already copied. Whether the cloud runtime registers HotCRM during the boot was not walked. The card's reading (18 crm_* and 8 ai_* objects missing) fits that path.
• Closed in passing: the aggregate arm never enforced OBJECT_PACKAGE_DISABLED (review boundary flag ③ 5). Before this PR, aggregate_records served a disabled package's exposed object on every kernel, because callData's aggregate arm asks the engine, never the protocol. The gate's refusal closes it. Pinned by the aggregate_records rows on the exposed object, which the refusal leg turns to SERVED.
• REST's order on a malformed body, measured, not changed. RestServer answers a body that is not a record 400 VALIDATION_FAILED on a disabled package's object, before its data plane's 404 OBJECT_PACKAGE_DISABLED, because enforceApiAccess reads that refusal as "no declaration". For an object declared apiEnabled: false it is the other way round: the exposure refusal comes first. The dispatcher's door now follows REST. Whether both doors should refuse a disabled package's object before the shape verdict is REST's question, and nothing here changes it.
• The outage fallback stays silent (review judgment 3, non-blocking). RestServer's loadObjectItem logs a warn when a thrown by-name read makes it fail open. This gate does not fail open on that throw: it judges the metadata service's copy, so REST's line ("failing open") would say something false here. ActionExecutionDeps also carries no logger. Left silent, as the old catch was.
• Finding, same defect class, not fixed here: list_actions / run_action. collectActionDeclarations reads metadata.listObjects(), and action resolution reads the same service. Measured on the same env_local during-boot fixture: an object action declared operation: 'update' with ai: { exposed: true } is in the registry, but list_actions answers [] and run_action answers Action 'mark_done' not found on object 'qa_pkg_open'. Control without an environmentId: listed and resolved. Queued as mcp: on an environmentId kernel, list_actions / run_action cannot see a package object's actions when the package registered during boot — collectActionDeclarations and action resolution read metadata.listObjects() #25139.
• Finding, the stdio half (packages/mcp/src/stdio-data-bridge.ts): the same three answers, measured above. Held off by the dispatch, queued as mcp stdio: on an environmentId kernel, a package registered during boot is invisible to list_objects / describe_object, and the stdio exposure gate serves its apiEnabled:false object (the stdio twin of #25120) #25138. Its fix should read OBJECT_PACKAGE_DISABLED as this gate now does on the arm that does not reach the protocol.
• Note: the GATED_ACTIONS docblock in packages/mcp/src/stdio-data-bridge.ts says the HTTP bridge answers listObjects / describeObject "straight off the metadata service". After this change, it reads the protocol's merged listing. The parity claim it makes (those two are not gated through callData) still holds. Only the wording is stale. It rides on mcp stdio: on an environmentId kernel, a package registered during boot is invisible to list_objects / describe_object, and the stdio exposure gate serves its apiEnabled:false object (the stdio twin of #25120) #25138.
• Note, not changed (review note 9): describe_object serves the raw fields map and reads the whole served listing per call.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/runtime, touching 13 documentable anchor(s).

14 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/data-flow.mdx (via /api/v1/meta/object (route, a path literal in a comment in buildMcpBridge))
• content/docs/api/declarative-endpoints.mdx (via callData (symbol, a top-level function))
• content/docs/api/wire-format.mdx (via /api/v1/meta/object (route, a path literal in a comment in buildMcpBridge))
• content/docs/concepts/metadata-lifecycle.mdx (via getMetaItem (literal, a string literal in ExposureDeclarationRead; a string literal in getMetaItemForExecution))
• content/docs/data-modeling/drivers.mdx (via getMetaItem (literal, a string literal in ExposureDeclarationRead; a string literal in getMetaItemForExecution))
• content/docs/deployment/environment-variables.mdx (via getMetaItem (literal, a string literal in ExposureDeclarationRead; a string literal in getMetaItemForExecution))
• content/docs/kernel/services-checklist.mdx (via getMetaItem (literal, a string literal in ExposureDeclarationRead; a string literal in getMetaItemForExecution))
• content/docs/permissions/authorization.mdx (via buildMcpBridge (symbol, a top-level function), callData (symbol, a top-level function))
• content/docs/permissions/system-context.mdx (via callData (symbol, a top-level function), refuseUnexposedDataAction (symbol, a top-level function))
• content/docs/protocol/diagram.mdx (via /api/v1/meta/object (route, a path literal in a comment in buildMcpBridge))
• content/docs/protocol/kernel/error-handling.mdx (via /api/v1/meta/object (route, a path literal in a comment in buildMcpBridge))
• content/docs/protocol/kernel/http-protocol.mdx (via callData (symbol, a top-level function), /api/v1/meta/object (route, a path literal in a comment in buildMcpBridge))
• content/docs/protocol/objectql/state-machine.mdx (via /api/v1/meta/object (route, a path literal in a comment in buildMcpBridge))
• content/docs/ui/forms.mdx (via /api/v1/meta/object (route, a path literal in a comment in buildMcpBridge))

⛔ 4 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v17/17-1.mdx (via /api/v1/meta/object (route, a path literal in a comment in buildMcpBridge))
• content/docs/releases/v17/17-5.mdx (via /api/v1/meta/object (route, a path literal in a comment in buildMcpBridge))
• content/docs/releases/v17/17-6.mdx (via /api/v1/meta/object (route, a path literal in a comment in buildMcpBridge))
• content/docs/releases/v17/17-7.mdx (via /api/v1/meta/object (route, a path literal in a comment in buildMcpBridge))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• the SDK route bridge reached 54 of 206 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 97 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• 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.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 27 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 abc25a3536e2f00cc55ee6745320cb8f7209c459 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 678e84ab87abd237a624fc971c816db82ce4b59b — the merge of head c0fb1c715f485d6f58a6eaf5ec5363db054c97c4 into base abc25a3536e2f00cc55ee6745320cb8f7209c459, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 678e84ab87abd237a624fc971c816db82ce4b59b && git checkout 678e84ab87abd237a624fc971c816db82ce4b59b
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin abc25a3536e2f00cc55ee6745320cb8f7209c459 c0fb1c715f485d6f58a6eaf5ec5363db054c97c4 && git checkout -B drift-repro abc25a3536e2f00cc55ee6745320cb8f7209c459 && git merge --no-ff c0fb1c715f485d6f58a6eaf5ec5363db054c97c4

node scripts/docs-audit/affected-docs.mjs --json abc25a3536e2f00cc55ee6745320cb8f7209c459

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs abc25a3536e2f00cc55ee6745320cb8f7209c459 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: d19b65bf1c98b3cb282ab85007fd8bb36a4680f8
Local-runs: none
Scope: packages/runtime/src/action-execution.ts, packages/runtime/src/domains/mcp.ts, packages/runtime/src/domains/data-write-request-gate.test.ts, packages/runtime/src/domains/mcp-package-object-discovery.test.ts + packages/metadata-protocol/src/protocol.ts (getMetaItems / readFlattenedMetaItems, getMetaItem / getMetaItemForExecution / readMetaItemFace, assertObjectRegistered, objectPackageDisabledError), packages/rest/src/rest-server.ts (objectItemReader, enforceApiAccess, metaListSource), packages/rest/src/meta-item-read-gate.ts (loadObjectItem), packages/runtime/src/http-dispatcher.ts (resolveService), packages/runtime/src/domains/meta.ts (the GET /meta/:type list branch, answerMetaList), packages/runtime/src/domains/data.ts (the /data door's gate calls), packages/runtime/src/api-exposure.ts (checkApiExposure), packages/objectql/src/registry.ts (getObject, isPackageDisabled, isObjectPackageDisabled), packages/objectql/src/engine.ts (aggregate), packages/mcp/src/mcp-http-tools.ts (list_objects, describe_object, validate_expression)

Inputs: card #25120 (body, claim 6322493221, report 6324844375, takeover claim 6327821572), PR #25136 (body, five-file list, net diff against main at the head above), and the 41 check-runs on that head: 34 success, 7 skipped by design, 0 failure; the five required contexts (Lint & Repo Gates, TypeScript Type Check, Test Core, Build Core, Governed Surface Queue Guard) are success. No governed surface is in the file list. The face is the changeset's and the PR body's Clause-②: no (narrowing).

① Derived judgments

1. Discovery reads the protocol's merged listing — RIGHT. readMergedItems (packages/runtime/src/domains/mcp.ts:454-471) is the one unwrap of getMetaItems, shared by the skill read and the object reads; getProtocol (:572) resolves protocol per request through the same deps.resolveService(context, name, envId) chain getMeta uses, the seam the skill read has used since commit e783e16. listObjectSummaries (:602-614) and describeObject (:661-678) answer from that listing; the dispatcher's own GET /meta/:type calls the same protocol.getMetaItems({ type }) (packages/runtime/src/domains/meta.ts:2211) and RestServer's list source does too (packages/rest/src/rest-server.ts:3578-3588), and readFlattenedMetaItems (packages/metadata-protocol/src/protocol.ts:10058 onward) reads this kernel's own registry and omits a disabled package's items by the one predicate isItemOfDisabledPackage (:553-555). So list membership equals what GET /api/v1/meta/object serves the same caller: the per-caller work answerMetaList adds (domains/meta.ts:619-656) is a field projection of each object, not a membership filter, and the new pin measures the equality in-process on every shape. sys_ objects stay filtered by the tool (packages/mcp/src/mcp-http-tools.ts:286-288, :706-708). The three outcomes are the skill read's: structural absence keeps the metadata service read; a throw travels to the client (contract item 8), the direction domains/meta.ts:2215-2230 takes for REST. listObjectsDiagnosed (mcp.ts:640-655) keeps the metadata service's listDiagnosed('object') verdict; the protocol has no diagnosed list read and getMetaItems throws rather than shorting on a store outage, so that verdict is the only completeness signal the host has — right, as the card asked. Not new, not a blocker: describeObject serves the raw fields map where REST's list projects fields per caller — exactly what the old getObject read served — and it reads the whole served listing (with _diagnostics computed per object) on every call where the served by-name face would read one object; a cost, not a contract change.

2. The gate's healthy by-name read — RIGHT. readExposureDeclaration (packages/runtime/src/action-execution.ts:336-359) asks getMetaItemForExecution, else getMetaItem, byte for byte RestServer.objectItemReader (rest-server.ts:2555-2557), and accepts the item only under its own name, the rule loadObjectItem applies (meta-item-read-gate.ts:492-497). readMetaItemFace (protocol.ts:11440-11455) shares every source, merge and the disabled-package refusal between the two faces and skips only the serving decorations; the gate reads enable and serves no byte, so the execution face is the one getMetaItemForExecution's docblock licenses. The registry resolves short names and legacy FQNs (registry.ts:4575, :5853), so an item resolved under another name is "no declaration" on this door exactly as on REST's: shared, pre-existing, not widened here. String(object) changes nothing.

3. The outage fallback keeps the old refusal set as a floor — RIGHT. Any throw but OBJECT_PACKAGE_DISABLED reads the metadata service's copy (action-execution.ts:356), the source this gate read on every input before the move, and the outer fail-open catch (:399-400) is unchanged, so no input is more exposed during an outage than it was on every request before. loadObjectItem fails open on the same throw (meta-item-read-gate.ts:501-506), so this door is at most REST's exposure then. Noted, not blocking: REST logs that fall-open; the runtime fallback is silent, as the old catch was.

4. OBJECT_PACKAGE_DISABLED read as "no declaration" — WRONG on one door, and it WIDENS. action-execution.ts:355 adopts loadObjectItem's reading (meta-item-read-gate.ts:500) on the premise the PR states in its docblock and in contract item 6: "the data plane then refuses the request with that same code". That premise holds on REST and on five of callData's six arms: findData, getData, createData, updateData and deleteData each run assertObjectRegistered (protocol.ts:14526, :15162, :15254, :15399, :15523), which throws objectPackageDisabledError for an object of a disabled package (:12921-12922, constructor :518-527). It does NOT hold on the aggregate arm: callData (action-execution.ts:674-706) takes no protocol there by design and calls engine.aggregate directly, the engine resolves the object through registry.getObject (engine.ts:21468 onward), the registry serves a disabled package's objects on purpose (registry.ts:5826-5856), and no site in packages/objectql/src/engine.ts asks isObjectPackageDisabled. Consequence, on exactly the input the review was asked to probe: a disabled package's object declared enable.apiEnabled: false, on any kernel where the metadata service holds its copy (every kernel without an environmentId, and any kernel after a marketplace install — the PR's own table rows 2 to 4, and the shape its disabled-package pin boots). Before this diff aggregate_records on it was refused 404 OBJECT_API_DISABLED from the copy; on this head readExposureDeclaration turns the protocol's refusal into undefined, checkApiExposure(undefined, 'aggregate') allows (packages/runtime/src/api-exposure.ts:119), and engine.aggregate serves grouped rows of an object the author declared off the API and the operator switched off. One refusal removed on the narrowing face; the PR's contract item 6 ("every data verb ... 404 OBJECT_PACKAGE_DISABLED, the status does not move") and the changeset's "Also changed" sentence are false for aggregate_records. The pins do not reach it: the disabled-package block (mcp-package-object-discovery.test.ts:323-354) pins listing and describe only, and no DATA_VERBS row (:220-227) runs against qa_off_gated. Fix, small and REST-parity-preserving: a refused OBJECT_PACKAGE_DISABLED is a refusal, not an outage and not an absence — rethrow it from readExposureDeclaration past refuseUnexposedDataAction's fail-open catch (:398-401; it already carries the ADR-0112 code, status and object the data door throws), so every arm answers 404 OBJECT_PACKAGE_DISABLED whether or not it reaches the protocol; then add the six DATA_VERBS rows to the disabled-package block expecting { code: 'OBJECT_PACKAGE_DISABLED', status: 404 } with the store spies never called, and re-measure the gate ablation against them. Asking the registry's isObjectPackageDisabled on the aggregate arm alone would close the same hole but leaves the gate's answer door-dependent.

5. The dispatcher's /data door and the hono catch-all narrow identically — RIGHT. domains/data.ts:237, :338, :455 ask the same gate; no /data route reaches callData('aggregate'), so judgment 4 is the /mcp aggregate_records tool (and any future callData('aggregate') caller).

6. Multi-environment host — RIGHT, parity. On a kernel-resolver host the request's own kernel answers first (http-dispatcher.ts:2576-2583), so each environment's bridge reads its own registry, pinned by the two-environment block (mcp-package-object-discovery.test.ts:356-407); on a SharedProjectPlugin host the chain is the one metadata already takes, so no environment is more exposed than its metadata read was.

7. Rig re-judge — RIGHT. stubObjectReads (data-write-request-gate.test.ts:168-181) answers getMetaItems and both by-name faces from the registry; the dispatcher door is given no metadata service (:289), so a gate that stopped reading the protocol has nothing to fall back to and reds — the shape a healthy-path rig owes.

8. Public surface — RIGHT, none moves. McpMergedMetadataRead was already exported; readMergedItems, readExposureDeclaration and ExposureDeclarationRead are module-private; packages/mcp and packages/spec are untouched; the metadata service gets no second copy, as the card required.

Verdict on the face: judgments 1 to 3 and 5 to 8 narrow or hold; judgment 4 widens one input class, so this head is not the narrowing its Clause-② line declares.

② Semver level

'@objectstack/runtime': patch with the BREAKING banner and the ADR-0087 disposition not-required (no-migration-prescription) in the changeset body; Metadata-protocol: none is right (no authorable key, accepted value or default moves — an enable.apiEnabled the author already wrote is enforced where it was not read). A non-protocol breaking change ships patch with its banner and disposition, so the level is right, and check-changeset-no-major and check-adr-0087-registration ran green inside Lint & Repo Gates on this head. Clause-②: no (narrowing) is the right arm for the intended change, but judgment 4 makes it untrue of this head until closed; the fix does not move the level (still patch, still breaking, still none).

③ Boundary flags

Report comment 6324844375: open_questions is empty — nothing to answer.

deviations, each judged:

1. The gate reads the by-name face rather than getMetaItems — right (REST parity; no per-request whole-list diagnostic pass).
2. Outage fallback to the copy, plus a fourth pin — the fallback is right as a floor (judgment 3); the fourth pin covers contract item 5 only, and item 6 is unpinned and false on aggregate_records (judgment 4).
3. Fixture re-judged — right (judgment 7).
4. origin/main merged before the PR — fine; the check-runs above are on the merged head.
5. Model-free commit trailers and the session-URL PR footer — matches AGENTS.md.
6. The ADR-0087 marker as an HTML comment in the changeset file — that is the form its gate reads; fine.

out_of_scope_findings, each answered or escalated:

1. list_actions / run_action read metadata.listObjects() (collectActionDeclarations) — same family, measured by the dev. ESCALATED: the seat files it from the report's evidence and dedupe words. Not a blocker here.
2. The stdio half (packages/mcp/src/stdio-data-bridge.ts) measures the same defect — held off by the dispatch. ESCALATED: the seat files it; its fix must not copy judgment 4's reading as it stands.
3. The GATED_ACTIONS docblock in packages/mcp now misdescribes the HTTP bridge's object read — under the same hold-off; rides on finding 2's card. Noted.
4. Card acceptance item 3 (walked on a cloud environment with a marketplace app) NOT MEASURED — the cloud host is outside this repo. The PR body says Fixes #25120, which closes the card on merge with that item unmeasured. ESCALATED: the seat decides whether the card closes on this PR or stays open for the cloud walk.
5. New, from this review: callData's aggregate arm never asks the data plane's OBJECT_PACKAGE_DISABLED gate, so aggregate_records on a disabled package's apiEnabled: true object was served before this PR and still is — pre-existing, not widened here; the seat files it, and the rethrow in judgment 4 closes it in passing.
6. Noted, not blocking: describe_object field visibility versus REST's per-caller projection (judgment 1) — pre-existing.

What a PASS on the next head needs: judgment 4 closed (the gate rethrows OBJECT_PACKAGE_DISABLED, or the aggregate arm asks the registry), the six data-verb rows pinned on the disabled package's gated object with the store spies, the gate ablation re-measured against them, and the contract item 6 claim then true on every verb.

Implemented-by: claude/issue-25120-mcp-package-objects
Reviewed-by: session_01AFrKwndmrCLtF5V9hNtrw3

VERDICT: FAIL

---

Generated by Claude Code

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: c0fb1c715f485d6f58a6eaf5ec5363db054c97c4
Local-runs: none
Scope: packages/runtime/src/action-execution.ts, packages/runtime/src/domains/mcp.ts, packages/runtime/src/domains/data-write-request-gate.test.ts, packages/runtime/src/domains/mcp-package-object-discovery.test.ts + packages/metadata-protocol/src/protocol.ts (objectPackageDisabledError, isObjectOfDisabledPackage, isItemOfDisabledPackage, readFlattenedMetaItems, readMetaItemFace, getMetaItem / getMetaItemForExecution, assertObjectRegistered, the five data methods), packages/objectql/src/engine.ts (aggregate), packages/objectql/src/registry.ts (getObject, isPackageDisabled, isObjectPackageDisabled), packages/rest/src/meta-item-read-gate.ts (loadObjectItem, createMetaListAnswer, createMetaListReadGate), packages/rest/src/rest-server.ts (objectItemReader, enforceApiAccess, metaListSource), packages/runtime/src/domains/data.ts (the three early asks, the six callData sites), packages/runtime/src/domains/meta.ts (the GET /meta/:type list branch, answerMetaList), packages/runtime/src/api-exposure.ts (checkApiExposure), packages/runtime/src/http-dispatcher.ts (resolveService, handleMcp), packages/runtime/src/endpoint-executor.ts (executeObjectOperation), packages/runtime/src/domains/actions.ts (its callData sites), packages/adapters/hono/src/index.ts (the ${prefix}/* catch-all), packages/mcp/src/mcp-http-tools.ts (list_objects, describe_object, aggregate_records), packages/spec/src/data/api-derivation.ts (DATA_ACTION_TO_API_OPERATION), packages/runtime/src/index.ts and packages/runtime/package.json (the public surface); .changeset/25120-mcp-package-objects.md for ② only

Inputs: card #25120 (body; claim 6322493221; report 6324844375; takeover claim 6327821572; rework note 6328222949; report 6329438310), PR #25136 (body, five-file list, the two PR comments including review of record 6328012432, FAIL on d19b65bf1c, and the net diff against main at the head above; origin/main has not moved under any of the five paths since merge base abc25a353), and the 48 check-runs on that head: 38 success, 9 skipped by design, 1 in_progress (a second run of "Part-of PR must not also close its card", re-triggered by the PR body edit; the first run of that job on this head is success, and it is not a required context). The five required contexts are success: Lint & Repo Gates, TypeScript Type Check, Test Core (and 1/6 to 6/6), Build Core, Governed Surface Queue Guard. No governed surface is in the file list. The face is the changeset's and the PR body's Clause-②: no (narrowing). Every line number below is read at the head sha.

① Derived judgments

1. Prior finding 1 (the aggregate arm served a disabled package's object) is CLOSED on every arm and every door — RIGHT. refuseUnexposedDataAction has exactly four non-test callers on this head: callData (packages/runtime/src/action-execution.ts:469, passing 'refuse') and the three early asks of the dispatcher's /data door (packages/runtime/src/domains/data.ts:237, :338, :455, default). callData asks the gate first (:469), before it resolves a protocol or an engine (:471 onward), so every arm — create (:482), get (:508), update (:529), delete (:586), query/find (:664), aggregate (:722, engine.aggregate at :748) — stands behind the refusal, the ObjectQL fallback arms included. readExposureDeclaration throws the protocol's refusal instead of reading it as absence (:363), and the gate's catch rethrows it under 'refuse' (:445). The protocol raises that refusal on both by-name faces (packages/metadata-protocol/src/protocol.ts:11426-11428, readMetaItemFace) through isObjectOfDisabledPackage → registry.isObjectPackageDisabled (:536-539; packages/objectql/src/registry.ts:5853-5857, the owner's package through the same resolveObjectKey getObject uses), the predicate assertObjectRegistered asks on the data plane (protocol.ts:12916; called by findData :14526, getData :15162, createData :15254, updateData :15399, deleteData :15523). The engine still asks no disabled-package predicate (zero hits in packages/objectql/src/engine.ts; aggregate at :21468 resolves through registry.getObject, which serves a disabled package's objects on purpose), so the gate is the only refusal on that arm, and it is now there. Doors: the /mcp bridge's six verbs each reach callData (packages/runtime/src/domains/mcp.ts:687, :720, :723-740 the aggregate arm, :767, :769, :771); the /data door's six branches each reach callData (data.ts:258, :273, :348, :399, :433, :460), with nothing between an early ask and its callData but the request-schema parse and the version-token read (:238-258, :339-348, :456-460); the @objectstack/hono catch-all is dispatcher.dispatch into that door (packages/adapters/hono/src/index.ts:1093-1111); a declarative object_operation endpoint reaches deps.callData (packages/runtime/src/endpoint-executor.ts:425-426); a business action's subject load and declarative update go through the callData wiring (action-execution.ts:2503, :2697; domains/actions.ts:688, :740-741; mcp.ts:843, :1041). Neither callData nor the gate is on the runtime's public index (packages/runtime/src/index.ts exports nothing from action-execution; the exports map is . alone), so no external caller can ask the gate with the default. The pins now reach the arm the prior record named: the disabled-package block runs all six DATA_VERBS (mcp-package-object-discovery.test.ts:238-245) on both objects, apiEnabled: false and exposed, on both kernel shapes, expecting { code: 'OBJECT_PACKAGE_DISABLED', status: 404 } with the five protocol data spies and the engine.aggregate spy uncalled (:481-495, spies at :248-257), and the refusal ablation (24 of 70 red, the four aggregate_records rows answering SERVED) and the gate ablation (33 of 70) are recorded in the PR body. Test Core is green on the head.

   Residual, pre-existing, not widened here: a principal with isSystem: true bypasses the gate (action-execution.ts:437) and handleMcpRequest admits one (mcp.ts:72); on that principal the aggregate arm still reaches engine.aggregate for a disabled package's object, because the engine asks no disabled-package predicate, while every other arm reaches the protocol, which refuses regardless of principal. This predates the PR (the gate always bypassed isSystem; the arm never asked the protocol) and is carried below, not a blocker. A host with no protocol slot takes the ObjectQL fallback on every arm, where no OBJECT_PACKAGE_DISABLED refusal exists anywhere, REST included: structural, unchanged.

2. The disabledPackage: 'defer' | 'refuse' parameter — the mechanism is RIGHT on this head; the default arm is the less safe spelling, flagged, non-blocking. Trace of every 'defer' taker: the three /data early asks (data.ts:237, :338, :455), each of which continues on every success path to a callData that asks with 'refuse' (:258, :348, :460); no 'defer' caller reaches a store or an engine without that later ask. Under 'defer' the swallowed refusal becomes def = undefined (action-execution.ts:446), checkApiExposure(undefined, …) allows (packages/runtime/src/api-exposure.ts:119), the request-schema gate answers a malformed body 400 VALIDATION_FAILED first, as RestServer's enforceApiAccess does because loadObjectItem reads the same refusal as "no object here" (packages/rest/src/meta-item-read-gate.ts:500), and a well-formed request is refused 404 OBJECT_PACKAGE_DISABLED at callData. Nothing is served either way; only the order of two refusals follows REST, pinned by the nine-request door-parity row on both shapes (mcp-package-object-discovery.test.ts:350-359, :371-416, :468-478) and measured by the door-twin ablation (2 of 70 red, exactly the parity rows). Judgment on the default: 'defer' as the default means a future caller that asks this gate and then reaches an engine or driver without callData would silently serve a disabled package's object — the very shape the prior record failed; route-and-surface ownership rule 2 (explicit composition over default magic) names the trap, since a reader checks who passes the option and misses who relies on the default. The safer spelling is default 'refuse' with the three /data early asks opting into 'defer' explicitly, the comment there naming REST's order as the reason. Flipping it is an edit to domains/data.ts, which this dispatch held outside the file surface, and on this head the only default-takers are those three asks, each followed by callData, so the default's whole effect is the malformed-body order the ablation isolates. Carried to ③ as a prescription for the next touch, not a reason to withhold the verdict.

3. The outage fallback never widens — RIGHT. readExposureDeclaration (action-execution.ts:344-372): a protocol without a by-name read reads the copy (:358); any throw other than the refusal reads the copy (:364), the metadata service's getObject, the source this gate read on every request before the move; a throwing copy read reaches the outer catch and falls open (:446), the pre-move answer. So during an outage the gate's answer on every input equals its pre-move answer, and it cannot allow what the pre-move gate refused. Against REST: loadObjectItem fails open at once on the same throw and logs (meta-item-read-gate.ts:501-507); this gate judges the copy first, a floor REST lacks, and logs nothing. Correction to the dev's reasoning, non-blocking and carried: on the no-copy shape — an environmentId kernel with a boot-registered package, the card's own shape — the fallback IS a silent fail-open indistinguishable from health, so REST's "failing open" line is false only where a copy exists; assertObjectRegistered already uses a one-shot console.warn for an analogous process-constant condition (protocol.ts:12882-12888), so "no logger in ActionExecutionDeps" is not the whole answer.

4. Discovery lists only what REST lists to the same caller — RIGHT. Three readers, one read: the bridge's readMergedObjects → readMergedItems → protocol.getMetaItems({ type: 'object' }) (mcp.ts:454-471, :599-600), the dispatcher's GET /meta/:type (packages/runtime/src/domains/meta.ts:2211), and RestServer's list source (packages/rest/src/rest-server.ts:3578-3588); readFlattenedMetaItems omits a disabled package's items by the one predicate isItemOfDisabledPackage (protocol.ts:10615-10617). REST's per-caller work on an object list is projection, never membership: the list gate's object arm maps filterObjectListViewsForUser over the items and drops none (meta-item-read-gate.ts:1903-1917), and the ADR-0106 mask projects fields (:3492); the api served-set face, the app id filter and the view object filter apply to other types (:3403 onward). The MCP tool filters sys_ (packages/mcp/src/mcp-http-tools.ts:286-288, :706-708) and takes no ?preview=draft, both narrower than REST, fine. describe_object answers from the same listing (mcp.ts:661-667), so every listed object is describable and a disabled package's object is "not found" on both, the control pinned at :620 and :446-455 of the test. listObjectsDiagnosed keeps listDiagnosed('object') for the partial verdict (mcp.ts:640-655), as the card asked. Per-environment: getProtocol resolves per request on the same seam getMeta uses (mcp.ts:572-573), and resolveService asks the request's own kernel first (packages/runtime/src/http-dispatcher.ts:2572-2583), pinned by the two-environment block (test:498-549). Noted, pre-existing, unchanged: describe_object serves the raw fields map from the served face, without the per-caller list-view prune or field mask REST applies to a list, exactly what the old getObject read served; and the served face decorates every object per call where a by-name read would decorate one — a cost, not a contract change.

5. The /data door's order — RIGHT, parity. Judged in 2: the early ask keeps enforceApiAccess's reading, callData refuses, every one of the nine measured requests answers what REST answers on both shapes, and the status of no refusal moves.

6. Rig re-judge — RIGHT, unchanged since d19b65bf1c. stubObjectReads answers getMetaItems and both by-name faces from the registry (data-write-request-gate.test.ts:243-257); the dispatcher door is given no metadata service (:291-294), so a gate that stopped reading the protocol has nothing to fall back to and reds, the shape a healthy-path rig owes; 73 of 73 green on the head.

7. Public surface — RIGHT, none moves. The new trailing optional parameter sits on a function the runtime's index does not export; readMergedItems, readExposureDeclaration, ExposureDeclarationRead and isObjectPackageDisabledRefusal are module-private; McpMergedMetadataRead was already exported from a domains/ module the index does not re-export; packages/mcp, packages/rest, packages/spec are untouched; the metadata service gets no second copy, as the card required.

Verdict on the face: every change narrows or holds; the one widening the prior record found is closed on every arm and every door; no public surface moves. This head is the narrowing its Clause-② line declares.

② Semver level

'@objectstack/runtime': patch, with the BREAKING banner and the ADR-0087 disposition not-required (no-migration-prescription) in the changeset body, and both declaration lines, Clause-②: no (narrowing) and Metadata-protocol: none, in the changeset and the PR body. Right: no authorable key, accepted value or default moves (an enable.apiEnabled the author already wrote is enforced where it was not read, and a package switch the operator already threw is honoured on one more arm); a non-protocol breaking change ships patch with its banner and disposition; the only published package the diff moves is @objectstack/runtime; check-changeset-no-major and check-adr-0087-registration ran green inside Lint & Repo Gates on this head. The changeset's "Also changed" sentence now states the disabled-package refusal on every verb and the /data door's malformed-body order, and both are true of this head (judgments 1 and 2). The Clause-②: no (narrowing) line is now true of the head.

③ Boundary flags

Report 6329438310: open_questions is empty — nothing to answer.

deviations, each judged:

1. origin/main merged (abc25a353) — fine; the check-runs above are on the merged head, and main has not moved under the five paths since.
2. Fix shape, 'defer' / 'refuse' with default 'defer' — mechanism right (judgment 2); the default's shape flagged there and prescribed below.
3. Pins beyond the dispatch's minimum — right (judgment 1).
4. PR body not written by the dev — the seat applied pr_body_replacement; the current body carries the "This round" section, both declaration lines and the session-URL footer. Fine.
5. Outage fallback left silent — accepted as non-blocking, with the correction in judgment 3.
6. pnpm lint run though CI-owned — fine.
7. A stray /unit.pid in the dev container — outside the repository tree and the diff; nothing to judge here; the seat deletes it.
8. Model-free commit trailers — matches AGENTS.md.
9. Rig ablation not re-run — accepted: the rig file is byte-identical to its d19b65bf1c state and 73 of 73 green on the head.

out_of_scope_findings, each answered or escalated:

1. REST's own order on a disabled package's object (a malformed body answered 400 before the data plane's 404) — noted, not filed; agreed: nothing is served either way, and the order is REST's question, not this card's.
2. list_actions / run_action read metadata.listObjects() — carried by mcp: on an environmentId kernel, list_actions / run_action cannot see a package object's actions when the package registered during boot — collectActionDeclarations and action resolution read metadata.listObjects() #25139, as the rework note records.
3. The stdio half and the stale GATED_ACTIONS docblock — carried by mcp stdio: on an environmentId kernel, a package registered during boot is invisible to list_objects / describe_object, and the stdio exposure gate serves its apiEnabled:false object (the stdio twin of #25120) #25138. For that card: its gate must refuse OBJECT_PACKAGE_DISABLED itself on any arm that does not reach the protocol, as callData's gate now does, and it should note the system-principal residual in judgment 1.

Prior record ③ 4, card acceptance item 3 (the cloud walk): the seat ruled in rework note 6328222949 to keep Fixes #25120, with the walk recorded NOT MEASURED in the PR body and sent to the maintainer in the round report. The PR body carries it under Acceptance notes. Already escalated; this record adds nothing but the note that the card closes on merge with that item unmeasured, by the seat's own ruling.

New from this review, non-blocking, to carry:

1. Default 'refuse', explicit 'defer': when domains/data.ts is next in a file surface, flip the default and have its three early asks opt out by name (judgment 2). Until then the default's reach is the three asks, each followed by callData.
2. System-principal aggregate_records on a disabled package's object (judgment 1 residual) — pre-existing; the engine asks no disabled-package predicate on aggregate; a carrier is mcp stdio: on an environmentId kernel, a package registered during boot is invisible to list_objects / describe_object, and the stdio exposure gate serves its apiEnabled:false object (the stdio twin of #25120) #25138's note or an engine-side card.
3. The silent outage fall-open on the no-copy shape (judgment 3) — a one-shot console.warn the way assertObjectRegistered warns would make a persistent outage distinguishable from health on exactly the card's shape.
4. The in_progress check-run is a re-trigger of a non-required job whose first run on this head is success; nothing to wait for.

What a merge needs beyond this record: the five required contexts are already success; the PR is a draft, so the owning seat readies it and arms the queue per Multi-agent discipline §7 after confirming the re-triggered job has settled.

Implemented-by: claude/issue-25120-mcp-package-objects
Reviewed-by: session_01AFrKwndmrCLtF5V9hNtrw3

VERDICT: PASS

---

Generated by Claude Code

[objectstack-fleet]

席位核对 · ACCEPT

domain:cli seat 2 (#22648) · os-bill · session session_01AFrKwndmrCLtF5V9hNtrw3 · 2026-10-22T00:29Z · head c0fb1c715f485d6f58a6eaf5ec5363db054c97c4 · takeover claim on #25120 → report 6329438310 (patch round) → review of record 6329661857 (CONTRACT_REVIEW_TIER, PASS; it closes the FAIL record 6328012432 on d19b65bf1c).

Check	Reading
Shape	Draft, base main. First line Fixes #25120; Clause-②: no (narrowing) and Metadata-protocol: none line-initial in the body and the changeset. One changeset, @objectstack/runtime: patch, BREAKING banner, one ADR-0087 marker (not-required). 5 files, +815 / −62. check-governed-merges.mjs --pr 25136: 0 of 5 paths governed, 877 lines ≤ 3000.
Premise, measured	The record's finding 1 is closed: refuseUnexposedDataAction has four non-test callers on the head (git grep at the head sha): callData with 'refuse' (action-execution.ts:469) and the dispatcher /data door's three early asks (domains/data.ts:237, :338, :455), each followed by callData. Matches the record.
Gates	Check-runs on the head: 38 success, 9 skipped by design, 1 in_progress at this reading (the non-required "Part-of PR must not also close its card", re-triggered by the body edit; its first run on this head is success). The five required contexts are success. Local: 68/68 derived families exit 0, the 10 WIDE families exit 0, pnpm lint exit 0, the dogfood battery 287/287 files on the head.
Changeset prose, read sentence by sentence against the diff	"Every data verb on /mcp, and every well-formed request on the dispatcher's /data door, now refuses a disabled package's object 404 OBJECT_PACKAGE_DISABLED at the exposure gate" — true (action-execution.ts:445, :469). "On that door, as on REST, a body that is not a record is still answered 400 VALIDATION_FAILED first" — true (domains/data.ts early asks take the default 'defer'). "If the merged by-name read fails, the gate judges the metadata service's copy" — true (:358). The "Before" and "What to do" bullets match the pins.
Accepted deviations	disabledPackage: 'defer' | 'refuse' with REST's order kept on the /data door (measured door parity, pinned and ablated); the outage fallback left silent; pins widened beyond the dispatch (all six verbs, both objects, both kernel shapes); pnpm lint run though CI-owned. The PR body was applied by the seat from the report's replacement text (the dev may not patch it).
Out of scope, where it goes	list_actions / run_action → #25139. The stdio half and the stale GATED_ACTIONS docblock → #25138 (pointer 6328231985). The record's non-blocking notes, for the next touch of those files, held in the seat post: (2) spell the default 'refuse' with the three /data early asks opting out; (3) a one-shot warn on the no-copy outage fallback; (5) an isSystem principal still bypasses the gate, so aggregate_records serves it a disabled package's object (pre-existing; the engine asks no disabled-package predicate). Card acceptance item 3 (the cloud walk) stays NOT MEASURED with Fixes #25120, per this seat's rework ruling 6328222949. A stray /unit.pid the dev wrote at the container root is outside the repo and outside the PR.
Landing	Not governed ⇒ ordinary queue landing: pr_ready + automerge_enable through the relay once every check on this head reads success or a by-design skip. #25138 and #25139 are serial after this lands.

---

Generated by Claude Code

[hotlong]

Stuck check on the accepted head, which is why this has not landed. Reading at 2026-10-22T07:05Z, cloud-repo session e0b4f569-ce94-4c75-ae7d-e8a0eff93760. The maintainer asked that session to look after the MCP cards. ⛔ Not a claim.

• On head c0fb1c715f: 38 success, 9 skipped, and 1 in_progress. That one is "Part-of PR must not also close its card": workflow run 39698491835 (Part-of Closing-Keyword Guard, pull_request), job 119561637168. It started 2026-10-22T00:14:32Z and its run has not updated since 00:14:33Z, so it has been stuck for about 6h50m.
• The ## 席位核对 landing line is "once every check on this head reads success or a by-design skip", so this run blocks the landing.
• POST …/actions/runs/39698491835/cancel answered 409 and the run stays in_progress. That session has no permission to force-cancel. The run needs force-cancel, or a fresh pull_request event (for example a no-op body edit) to start a new guard run, before pr_ready + automerge_enable.

#25138 and #25139 are serial behind this PR.

[objectstack-fleet]

Landing on the maintainer's word · domain:cli seat 2 · os-bill · session session_01AFrKwndmrCLtF5V9hNtrw3 · 2026-10-22T08:44Z · head c0fb1c715f485d6f58a6eaf5ec5363db054c97c4.

• The one check not green on this head: "Part-of PR must not also close its card", job 119561637168 (run 39698491835), shown in_progress since 2026-10-22T00:14Z. Its step record reads every step completed · success by 2026-10-22T00:14Z, the check step itself ("A PR body may not close the card it is only part of") included, and "Complete job" success; the job's completion never reached the check-run, which is a platform-side lost status, not a running job. The same check's first run on this head (job 119536792067) is success. It is not a required context.
• The maintainer's word, verbatim, in this seat's session chat: 「落地」 (after the seat laid out the reading above and the two options: cancel and re-run it, or land with it).
• Landing: pr_ready + automerge_enable through the relay in this stroke, on the ACCEPT 6329683726 and the review of record 6329661857 (CONTRACT_REVIEW_TIER, PASS on this head). The five required contexts are success.

---

Generated by Claude Code