[objectstack-fleet]

Clause-②: no (narrowing) — under the isolated and group tenancy postures, importing a remote table as an object (POST /api/v1/datasources/:name/external/tables/:remote/import, and the MCP import_object tool) and refreshing a federated datasource's cached catalog (POST /api/v1/datasources/:name/external/refresh-catalog) are writes to the environment's metadata catalog, and they are the platform operator's, as every other write to that catalog is.
Metadata-protocol: none
Skills-docs: none — no skills/** text teaches any of the three doors or who may call them (0 hits for the import route, the refresh route, refreshCatalog and import_object under skills/; datasource itself is named there, the positive control); the rule is stated in the docs this diff updates (content/docs/deployment/tenancy-modes.mdx, content/docs/data-modeling/odata-datasources.mdx).

维护者速读

• 改了什么：三道写入门——REST 远程表导入路由、MCP import_object 工具、REST 外部目录刷新路由——在 isolated / group 租户姿态下，与元数据保存门问同一个“围墙目录写入”裁决。
• 为什么改：导入把一个对象存进环境共享的元数据目录，目录刷新把数据源的 external_catalog 快照存进同一个目录；围墙姿态下这个目录只归平台运营方（与引擎自身）写，所以这三道门与保存门读同一条裁决。
• 风险与回滚：围墙姿态下，平台运营方以下的调用方导入或刷新目录改为 403 PERMISSION_DENIED，什么都不读取、不保存；租户服务已注册却答不出时回 503；single 与未注册租户服务的部署不变；回滚即还原本 PR，已导入的对象与已存的快照不受影响。
• 先看：packages/rest/src/external-datasource-routes.ts（refuseFederationRequest 的 catalogWrite 段，导入与刷新两条路由共用）、packages/runtime/src/domains/mcp.ts（federationService 的 catalogWrite 段）、packages/qa/dogfood/test/external-import-walled-catalog-refusal.dogfood.test.ts。
• 两分钟验证：pnpm --filter @objectstack/dogfood exec vitest run test/external-import-walled-catalog-refusal.dogfood.test.ts，预期 9 个用例全部通过（围墙下三道门拒绝、运营方可导入与刷新、single 下照常导入与刷新）。
• 需要你做的：无，席位落地。

What changes

• The rule. Under isolated and group every organization shares the environment's metadata catalog, and a write to it is admitted only for the platform operator and for the engine's own writes (ADR-0131 D3, D12 items 7–8, D11). Three doors of the federation family write that catalog: the import of a remote table as an object, at the REST route and at the MCP import_object tool, saves an object; the catalog refresh at the REST route saves the datasource's external_catalog snapshot. Each of them now asks the walled-catalog verdict the metadata save door asks (walledCatalogWriteVerdict, @objectstack/metadata-core) for the type it writes, after the federation family's capability rule and before the federation service is looked up.
• The answer. A refused call answers 403 PERMISSION_DENIED with the verdict's sentence for the type written, which is the sentence the metadata save door answers, naming the posture. Nothing is introspected and nothing is saved. A tenancy service that is registered and cannot answer refuses the call 503 SERVICE_UNAVAILABLE, never a permit.
• Unchanged. The platform operator imports and refreshes under a wall as before. Under single, and on a deployment with no tenancy service, every caller holding both federation capabilities imports and refreshes as before. Listing remote tables, drafting an object and validating are unchanged, and the federation capability rule answers first, as before.
• Docs. deployment/tenancy-modes lists the import and the catalog refresh among the walled writes; data-modeling/odata-datasources states who imports and refreshes under a wall; row 55b of the system-context census names the doors, with its register regenerated. The walledCatalogWriteVerdict doc comment and its ADR anchor name the three doors among the doors that ask it.

Tests

• packages/rest/src/external-datasource-routes-auth-guard.test.ts: for the import route and for the catalog refresh route alike, under group and isolated an administrator holding both federation capabilities is refused 403 PERMISSION_DENIED before the service is looked up; the sentence equals the verdict's sentence for the type the route writes (object, external_catalog); the capability rule still answers first; listing is still served; the platform operator and the single / no-tenancy controls are served; a failing tenancy service answers 503 SERVICE_UNAVAILABLE.
• packages/runtime/src/domains/mcp-federation-bridge.test.ts: the same rule, refusals and controls at the MCP import_object bridge.
• packages/rest/src/rest-write-route-hook-refusal-sentence.ledger.test.ts: the ledger's context registers no tenancy service, as on a deployment that is not walled, so its import rows still reach the federation service the ledger reads.
• packages/qa/dogfood/test/external-import-walled-catalog-refusal.dogfood.test.ts: a booted showcase under group with the federation service and the MCP server mounted. An organization administrator holding both capabilities is refused at the REST import door and at the catalog refresh with the save door's status and sentence for the type written, and at import_object (a real OAuth agent token granted metadata:write and actions:execute) with the same code and sentence; nothing is saved or stored. Controls: the platform operator imports at both import doors and refreshes the catalog under the same wall; under single the same kind of administrator does each as before.

Acceptance notes

• Where the rule sits: at the doors, not in the shared save path. The save path below the doors (saveMetaItem behind importObject, the catalog persistence behind refreshCatalog) receives the item, not the caller's rung or whether the caller is the engine, so judging there would mean threading the caller into the federation service contract. The doors are where caller admission already lives in this family (the capability rule runs there), so the walled verdict runs beside it and refuses before any landing is resolved or any remote schema is read. On the REST side the two write routes share the one guard (refuseFederationRequest), each naming the type it writes.
• The code. The status and the sentence are the save door's. The code is PERMISSION_DENIED, the standard-catalog member this family already answers for a 403; the REST /meta door answers its grandfathered synonym (STANDARD_SYNONYM_WAIVERS, ADR-0112 D3), which keeps a wire value and is not endorsed for new code.
• Breaking, patch. An accept-set narrowing under a walled posture only; no key of any schema moves and nothing stored changes, so both packages take a patch with a BREAKING banner (ADR-0087 marker not-required (no-migration-prescription)). The changeset names all three doors.

Verification

All readings below are at head b5648f2fb463a1d4c70e8198d98fe3093711c5a4, after origin/main was merged in (merge commit, no conflicts; main had moved rest, runtime and service-datasource), the closure rebuilt (pnpm --filter '@objectstack/dogfood^...' build) and every build and test run under the shared verify lock.

Pins at the head

• external-datasource-routes-auth-guard.test.ts: Tests 27 passed (27).
• mcp-federation-bridge.test.ts: Tests 17 passed (17).
• external-import-walled-catalog-refusal.dogfood.test.ts: Tests 9 passed (9).

Ablations

Each through scripts/ablation-replace.mjs (anchor hit once, blob changed, restored blob-equal to HEAD with git diff HEAD empty), on the committed tree. Where the dogfood pin was read, the package was rebuilt and scripts/ablation-dist-preflight.mjs proved the mutation in dist/ first; after each restore the package was rebuilt and the preflight proved dist/ back at the head with the tree clean.

subject	ablation	unit reading	dogfood reading
the shared REST refusal (import and refresh)	the walled refusal made unreachable	6 failed | 21 passed (27): group, isolated and the verdict sentence, for the import and for the refresh	3 failed | 6 passed (9): the REST import, the MCP import (its sentence is compared with the REST door's) and the refresh refusal pins
the MCP refusal	the same, in federationService	3 failed | 14 passed (17): group, isolated, verdict sentence	1 failed | 8 passed (9): the MCP refusal pin
the REST outage arm	an unreadable posture read as no posture	2 failed | 25 passed (27): the import and the refresh 503 pins	not read (no 503 pin there)
the MCP outage arm	the same, at the MCP posture read	1 failed | 16 passed (17): the 503 pin	not read
the catalog refresh's wiring	the refresh route stops naming the type it writes	4 failed | 23 passed (27): the refresh's group, isolated, verdict-sentence and 503 pins; every import pin green	1 failed | 8 passed (9): the refresh refusal pin; every import pin and every control green

After the last restore: git status --porcelain empty and git diff HEAD empty.

Package tests and typecheck

Under the verify lock at the head:

• pnpm --filter @objectstack/rest test: Test Files 391 passed (391), Tests 7409 passed | 332 skipped.
• pnpm --filter @objectstack/runtime test: Test Files 547 passed (547), Tests 8762 passed | 19 skipped.
• pnpm --filter @objectstack/metadata-core test: Test Files 23 passed (23), Tests 911 passed.
• pnpm --filter @objectstack/service-datasource test (the service behind all three doors, not in this diff): Test Files 72 passed (72), Tests 1239 passed.
• typecheck for rest, runtime, metadata-core, service-datasource and dogfood: exit 0, 0 error TS lines each.

Derived gates

node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack (no paths) at b5648f2fb4: 99 commands, each run as printed with stdin from /dev/null and its exit code recorded. --ran: 99 derived, 99 run, 0 NOT-MEASURED, 0 UNRUN. Two first answered exit 3 (check:skill-examples and check:dual-build-cjs-loads, prerequisite packages outside this diff unbuilt) and were re-run after building those packages: exit 0. Every recorded exit is 0.

pnpm --filter @objectstack/spec check:generated after the merge (main moved packages/spec): all 14 generated artifacts up to date.

Full dogfood battery at the head

b5648f2fb463a1d4c70e8198d98fe3093711c5a4, the closure built at that head, then under the lock pnpm --filter @objectstack/dogfood test with no shard and no path:

• os-verify-lock: VERDICT command-exit 0
• Test Files 424 passed | 3 skipped (427)
• Tests 3541 passed | 41 skipped (3582)
• no failures; git status --porcelain empty after the run

This body was rewritten for head b5648f2fb4 in session session_01L9qibvynRbCtMndW8EHNGc, after the catalog refresh joined the two import doors.

[github-actions]

📓 Docs Drift Check

This PR changes 3 package(s): @objectstack/metadata-core, @objectstack/rest, @objectstack/runtime, touching 6 documentable anchor(s). ⚠️ 1 changed file(s) yielded no anchor (packages/metadata-core/src/meta-write-capability.ts), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

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

• content/docs/permissions/authorization.mdx (via buildMcpBridge (symbol, a top-level function))
• content/docs/permissions/system-context.mdx (via federationService (symbol, a top-level function), registerExternalDatasourceRoutes (symbol, a top-level function), external_catalog (literal, a string literal in a comment in registerExternalDatasourceRoutes; a string literal in registerExternalDatasourceRoutes))
• content/docs/protocol/kernel/index.mdx (via resolveExecutionContext (symbol, a field of interface ExternalDatasourceRoutesOptions))

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

• content/docs/releases/v17/17-6.mdx (via external_catalog (literal, a string literal in a comment in registerExternalDatasourceRoutes; a string literal in registerExternalDatasourceRoutes))

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

• 1 changed file(s) yielded no anchor (packages/metadata-core/src/meta-write-capability.ts) — pages documenting those are invisible to this run
• 1 anchor(s) matched too much of the corpus to be a work list: PERMISSION_DENIED (literal, 51 pages)
• the SDK route bridge reached 63 of 221 client-bound route-ledger rows — the other 158 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 158: 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; 103 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 — 39 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 9b24f3ca8734b5e0ea77cc3cb282c3f8f55a862b → packageMentionDocs.

Which tree this was computed on

This run read content/docs from f3f09692589e7fab8bcb646468ec256e1468b365 — the merge of head b5648f2fb463a1d4c70e8198d98fe3093711c5a4 into base 9b24f3ca8734b5e0ea77cc3cb282c3f8f55a862b, 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 f3f09692589e7fab8bcb646468ec256e1468b365 && git checkout f3f09692589e7fab8bcb646468ec256e1468b365
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 9b24f3ca8734b5e0ea77cc3cb282c3f8f55a862b b5648f2fb463a1d4c70e8198d98fe3093711c5a4 && git checkout -B drift-repro 9b24f3ca8734b5e0ea77cc3cb282c3f8f55a862b && git merge --no-ff b5648f2fb463a1d4c70e8198d98fe3093711c5a4

node scripts/docs-audit/affected-docs.mjs --json 9b24f3ca8734b5e0ea77cc3cb282c3f8f55a862b

⚠️ 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 9b24f3ca8734b5e0ea77cc3cb282c3f8f55a862b → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

security#1 · os-tesla · session_01L9qibvynRbCtMndW8EHNGc

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: b5648f2fb463a1d4c70e8198d98fe3093711c5a4
Local-runs: none
Scope: packages/rest/src/external-datasource-routes.ts, packages/runtime/src/domains/mcp.ts, packages/metadata-core/src/meta-write-capability.ts, scripts/adr-anchors/packages__metadata-core__src__meta-write-capability.ts.json, packages/rest/src/external-datasource-routes-auth-guard.test.ts, packages/rest/src/rest-write-route-hook-refusal-sentence.ledger.test.ts, packages/runtime/src/domains/mcp-federation-bridge.test.ts, packages/qa/dogfood/test/external-import-walled-catalog-refusal.dogfood.test.ts + packages/core/src/security/admission-tenancy-posture.ts, packages/core/src/security/api-key.ts (effectiveTenancyPosture), packages/core/src/security/assemble-execution-context.ts, packages/core/src/security/authz-store-unavailable.ts, packages/rest/src/rest-server.ts (walledCatalogRefusal, resolveAnonymousFormTenancy, resolvePackageRouteExecutionContext), packages/rest/src/direct-mount-composition.ts, packages/rest/src/rest-api-plugin.ts, packages/runtime/src/domains/activation-gate.ts (readEffectiveTenancyPosture), packages/runtime/src/domains/meta.ts, packages/mcp/src/mcp-http-tools.ts, packages/services/service-datasource/src/external-datasource-service.ts, packages/services/service-datasource/src/plugin.ts, packages/spec/src/kernel/metadata-plugin.zod.ts, docs/adr/0131-total-organization-ownership-no-null-organization-id.md (D3, D11, D12 items 7–8)

Face: narrowing. record-recognisers --paths on the PR's twelve paths decides no face from the paths themselves (no governed path, no published schema) and defers to the changeset's Clause-②: line, which carries the (narrowing) arm; so the floor is every path outside the prose faces (.changeset/** and content/docs/** are not reviewed), listed first above, and the cited code after the +. Net diff read at the merge base 9b24f3ca8734b5e0ea77cc3cb282c3f8f55a862b with origin/main.

Check-runs on the head: 54, all completed, none queued. The ten required contexts: Lint & Repo Gates success, TypeScript Type Check success, Test Core success, Build Core success, Governed Surface Queue Guard success, Test UI success, Live E2E UI success; Lint UI, Type Check UI and Build & E2E UI completed as skipped (the path filter, no ui/ path in the diff). Also Dogfood Regression Gate success and Check Changeset success. The one PR comment is the advisory Docs Drift Check (see ③).

The rule reviewed against, verbatim from the seat post: "under the walled tenancy postures, importing a remote table as an object and refreshing a datasource's external catalog are catalog writes reserved to the platform operator, at REST and MCP." Governing text read: ADR-0131 D3 (the catalog is environment-level; under group / isolated tenant admins cannot create or edit catalog items), D11 (postures differ only in enforcement), D12 items 7–8 (one environment, one catalog; plants assign, plants do not define), and walledCatalogWriteVerdict on main (admits isSystem and the PLATFORM_ADMIN rung; inert for an absent or non-walling posture; judges every type alike).

① Derived judgments

• Accept set, REST POST …/external/tables/:remote/import: narrowed, right. refuseFederationRequest now takes a catalogWrite name; the import route names 'object', and after the family's capability rule the guard asks walledCatalogWriteVerdict with the posture in force, authz.isSystem and authz.posture. Under group / isolated a caller below the operator rung is refused 403 PERMISSION_DENIED with the verdict's own sentence, before the external-datasource lookup. This is the rule, and the type named is the type the service saves (persistObject in service-datasource/src/plugin.ts saves an object through the metadata door's own save).
• Accept set, REST POST …/external/refresh-catalog: narrowed, right. Names 'external_catalog', the type persistCatalog registers (service.register('external_catalog', …)); external_catalog is a registered metadata type (metadata-plugin.zod.ts, allowRuntimeCreate: true), so the snapshot is a catalog item and the rule reaches it.
• Accept set, MCP import_object: narrowed, right. federationService takes the same catalogWrite name; the bridge's importObject passes 'object'; the verdict reads ec.isSystem and ec.posture off the dispatcher's execution context, the same two fields the dispatcher's /meta save door reads (meta.ts). list_remote_tables passes no name and is not asked: it writes nothing. Right.
• Public surface, @objectstack/rest: one additive optional field. ExternalDatasourceRoutesOptions.resolveExecutionContext's resolved shape gains posture?: unknown. It is an input the registrar reads, optional, and the carrier of the narrowing above, not a capability handed to anyone; a host that passes none gets the verdict's refusal under a wall (the operator rung is the only thing that admits). Named here because it is the one exported-type change in the diff; it does not make the Clause-② spelling widening.
• Public surface, @objectstack/metadata-core: none. Only the doc comment on walledCatalogWriteVerdict and the module header change; no new exported member, no signature change. The ADR anchor's invariant text is updated to name the three doors in the same sentence that names the others.
• Public surface, @objectstack/runtime: none. federationService is module-private; buildMcpBridge's shape is unchanged.
• Unchanged, right: the three read routes (GET …/tables, POST …/tables/:remote/draft, POST …/validate) still answer on the capability rule alone; single and a deployment with no tenancy service admit as before (the verdict returns allowed for an absent or non-walling posture, and the ledger test's stand-in now reports tenancy as not registered, so the import rows of that ledger still reach the service they read); the platform operator and isSystem are admitted under a wall.

② Semver level

• Changeset: @objectstack/rest patch, @objectstack/runtime patch, with the BREAKING banner, Clause-②: no (narrowing), Metadata-protocol: none and exactly one ADR-0087 marker (not-required (no-migration-prescription)), the body stating that no key moves and nothing stored changes. The PR body carries the same two declaration lines. That matches what the diff publishes: an accept-set narrowing under a walled posture, no schema change, no stored change; a non-protocol narrowing ships patch with its banner, as the Post-Task Checklist spells it.
• Clause-②: no (narrowing) is the correct spelling. The only exported-type change is the optional posture field named in ①, an input the narrowing needs, not a widening of any accept set or capability; nothing is removed or renamed, so no FROM → TO migration is owed.
• @objectstack/metadata-core takes no changeset: its change is a doc comment and the anchor, no behaviour. Acceptable; Check Changeset is green on it.

③ Boundary flags

• Acceptance note, "the rule sits at the doors, not in the shared save path": answered, accepted. At the head, importObject is called by exactly two in-repo callers, the REST import route and the runtime MCP bridge (mcp.ts), and refreshCatalog by exactly one, the REST refresh route; the @objectstack/client method is a wire caller of that route. Both MCP transports reach the tool through registerFederationTools over the bridge buildMcpBridge builds (the HTTP dispatcher's buildMcpBridge and the domain's own), so there is one federationService behind import_object. The door-level rule is therefore complete for every caller that exists; the service contract still carries no caller, so a future door must ask the verdict itself. The verdict's doc comment and the ADR anchor now name the three doors, which is where the next author reads the list. No further action.
• Acceptance note, the PERMISSION_DENIED code against the /meta door's grandfathered synonym: answered. The family already answers PERMISSION_DENIED for a 403, the code is a standard member, and the sentence is the verdict's own (the tests compare it byte-for-byte with walledCatalogWriteVerdict's message for the type written). Right.
• Acceptance note, "breaking, patch": answered in ②.
• Docs Drift Check (advisory comment on the PR): flags content/docs/permissions/authorization.mdx (via buildMcpBridge) and content/docs/protocol/kernel/index.mdx (via the resolveExecutionContext field) as naming touched symbols, and content/docs/releases/v17/17-6.mdx as read-only. Prose, outside the reviewed faces; the lane may re-read the two pages. Not blocking.
• Author: objectstack-fleet[bot] is the relay; the body's signature names this seat's session and the branch, which Implemented-by: records.
• A sibling-family question is with the owner seat. It concerns a door outside the rule under review (not the import, not the refresh, not this family), and it does not bear on this verdict; detail goes to the seat, not here.

④ Design judgment

• packages/rest/src/external-datasource-routes.ts — holds. Ordering: authGate (ADR-0069) → anonymous floor → federation capability rule → walled verdict → service lookup. The verdict is asked after the capability rule, as the /meta save door asks it after metaSaveVerdict, and before any landing or remote schema is read; a refused caller learns the capability name or the posture, never whether the datasource or the service exists. The posture is read per request off the registrar's own ctx kernel, the kernel externalService() resolves from, so the posture judged and the service that writes come from one kernel. The async leg goes through classifyAdmissionTenancyPosture, which answers undefined only for the registry's branded not-registered rejection and raises AuthzStoreUnavailableError for every other fault; the guard then answers that error's own 503 SERVICE_UNAVAILABLE, never a permit. Only a route that names catalogWrite pays the posture read, so the read routes keep answering under a tenancy outage. The operator is admitted by authz.posture === 'PLATFORM_ADMIN', and the resolver the registrar receives is RestServer.resolvePackageRouteExecutionContext, which is resolveExecCtx, the producer the /meta doors read; the envelope it assembles carries the ADR-0095 rung (assemble-execution-context.ts). isSystem is never set from the wire by that resolver. Tried to break it: no other route in this family saves a catalog item; the draft route answers a definition without saving it; the service's only writes are persistObject (behind importObject) and persistCatalog (behind refreshCatalog).
  • should-fix (parity, low): tenancyPostureInForce's synchronous leg, taken only on a host whose ctx exposes no getKernel().getServiceAsync, wraps ctx.getService('tenancy') in a bare catch that returns undefined, so a synchronous fault that is not "not registered" is read as no posture. The /meta save door's resolveAnonymousFormTenancy classifies the same fault (isServiceNotRegisteredError → undefined, otherwise AuthzStoreUnavailableError), and so does classifyAdmissionTenancyPosture on the async leg. The production kernel takes the async leg (the booted dogfood pins prove it), and the stdio MCP door in @objectstack/mcp made the same documented choice for this leg, so this is a parity gap on a host shape no production composition uses, not a hole in the rule. Classify the synchronous fault with isServiceNotRegisteredError as the save door does.
• packages/runtime/src/domains/mcp.ts — holds. federationService asks the capability rule first (unchanged), then, when catalogWrite is named, reads the posture through readEffectiveTenancyPosture, the one read every walled door of the dispatcher uses (meta.ts, packages.ts, automation.ts, permission-set-clone.ts): resolveServiceOrLoud answers undefined for no tenancy service and the read raises AuthzStoreUnavailableError for a service that cannot answer, which the bridge surfaces as 503 SERVICE_UNAVAILABLE. The verdict reads ec.isSystem and ec.posture, the same fields meta.ts reads at its save door. So the MCP door reads the same verdict, the same posture source as the dispatcher's save door and the same caller fields as REST; the refusal carries the verdict's sentence with PERMISSION_DENIED / 403, which the tool surface already maps. The listing stays a pure capability decision and the pair is listed where a call can pass it. Nothing else in the bridge writes a catalog item.
• packages/metadata-core/src/meta-write-capability.ts — holds. Doc comment only: the roster of doors that ask the verdict now names the three doors beside the others, and the module header matches. No behaviour moves; the predicate still judges every type alike and no door pre-filters on the type.
  • should-fix (cosmetic, low): WRITTEN_SUBJECT has no row for external_catalog, so the refusal at the refresh door reads "Creating, changing or deleting a 'external_catalog' metadata item requires the platform operator…". The sentence is correct and is the one the save door would answer for that type, so the pin holds; a subject row such as "a datasource's cached catalog" would read as the other subjects do. Not a rule change.
• scripts/adr-anchors/packages__metadata-core__src__meta-write-capability.ts.json — holds. The invariant sentence names the three doors in the roster of doors that ask the one predicate; check:adr-anchors is inside the green Lint & Repo Gates.
• packages/rest/src/external-datasource-routes-auth-guard.test.ts — pins the rule. For the import and the refresh alike: group and isolated refuse an administrator holding both federation capabilities with 403 PERMISSION_DENIED before the service lookup (the lookup list is asserted); the message equals the verdict's message for the type written; the capability rule still answers first (a READ-only caller is told the capability, not the posture); the listing is still served under a wall; the operator control, the single and no-tenancy controls, and the 503 outage arm. The mount is the real registrar over a resolver that states the rung, which is what the verdict reads.
• packages/runtime/src/domains/mcp-federation-bridge.test.ts — pins the rule at the bridge with the same cases (refusal under both postures before the lookup, verdict-sentence equality, listing served, operator control, single and no-tenancy controls, 503 on a failing tenancy service). The existing fixtures gain resolveServiceOrLoud answering undefined, the no-tenancy composition, so their pre-existing pins keep meaning what they meant.
• packages/rest/src/rest-write-route-hook-refusal-sentence.ledger.test.ts — right. The ledger's stand-in context now reports tenancy as not registered instead of rejecting, so the ledger's import rows still reach the federation service whose refusal sentence they read; a rejecting stand-in would otherwise have read as an outage.
• packages/qa/dogfood/test/external-import-walled-catalog-refusal.dogfood.test.ts — pins the rule on a booted stack. Under group (guarded: the tenancy service answers group, not degraded, and the administrator's rung is not PLATFORM_ADMIN): REST import, MCP import_object (a real agent token) and REST refresh are refused with the save door's status and sentence and nothing is saved or stored; the operator imports at both doors and refreshes under the same wall. Under single the same administrator imports at both doors and refreshes as before. The two must-hold behaviours the rule needs (refusal below the operator; the operator admitted) are both pinned end to end.

No must-fix. Two should-fixes, named above.

Implemented-by: claude/sec-hardening-r7
Reviewed-by: session_01L9qibvynRbCtMndW8EHNGc

VERDICT: PASS

---

Generated by Claude Code

[objectstack-fleet]

security#1 · os-tesla · session_01L9qibvynRbCtMndW8EHNGc

席位核对

ACCEPT · 2026-11-06T07:27Z · head b5648f2fb463a1d4c70e8198d98fe3093711c5a4

• Contract review: PASS at this head, CONTRACT_REVIEW_TIER, record 6679608454 (isolated reviewer; face narrowing, scope = all 8 non-prose paths + 14 cited files; Clause-②: no (narrowing) judged the right spelling). No must-fix. Two should-fixes, both accepted as deviations for this landing and carried on the security#1 seat post as follow-ups: (1) the synchronous posture-read leg of the REST import/refresh doors reads any service fault as "no posture" where the metadata save door classifies "not registered" only (production kernels take the async leg); (2) the refresh refusal sentence names the written type without a subject row in metadata-core. The sibling-family item the record names is with this seat.
• Checks: 54 check-runs on this head, 40 success, 14 skipped, 0 failure, none pending; Lint & Repo Gates and TypeScript Type Check success. mergeable_state clean.
• Gates (dev, at this head): five one-shot ablations (the shared refusal at REST and MCP, the outage arm at REST and MCP, the refresh door's wiring) each turned its pins red, with the tree clean after restore; package suites rest 391 files, runtime 547, metadata-core 23, service-datasource 72, all green; typecheck of 5 packages exit 0; dispatch-gates --commands 99 derived, 99 run, 0 NOT-MEASURED, 0 UNRUN; full dogfood battery ((narrowing) arm) pinned to this head: 424 files passed, 3 skipped, 0 failures.
• Prose faces read against the diff: the changeset sentences "each of those doors asks the walled-catalog verdict the metadata save door asks … after the federation capability rule and before the federation service is looked up", "A refused call answers 403 PERMISSION_DENIED … A tenancy service that is registered and cannot answer refuses the call 503 SERVICE_UNAVAILABLE" and "Under single, and on a deployment with no tenancy service, every caller holding both federation capabilities imports and refreshes as before" match refuseFederationRequest in packages/rest/src/external-datasource-routes.ts and federationService in packages/runtime/src/domains/mcp.ts at this head. The three docs pages state the same rule; rule level only; no release-owned page edited.
• Shape: draft, base main, no closing keyword (no card); title and body name all three doors (body rewritten by this seat from the dev's prepared text); Clause-②: no (narrowing), Metadata-protocol: none, Skills-docs: none — … on the body; changeset @objectstack/rest + @objectstack/runtime patch with the BREAKING banner and the ADR-0087 marker; metadata-core changes a doc comment and its anchor only.
• Governed: check-governed-merges.mjs --branch origin/claude/sec-hardening-r7: 0 of 12 paths governed; 952 changed lines ≤ 3000 ⇒ Tier S, ordinary queue landing.
• Provenance: first two doors by the previous security#1 holder's dev (session_01L6bhgVfjk2i8T2D4RmxsKg), third door folded in by that dev; main merge, ablations, battery and body by this seat's dev; this session dispatched the reviewer.
• Landing authority: the maintainer's standing order to this account's seats, verbatim: 「按 pm-dispatch 审过的pr你可以自主落地」. Next: relay pr_ready + automerge_enable once the maintainer confirms in the seat thread (this session's auto mode refused the landing stroke on fix(core)!: an API key authenticates only as an owner who exists #30783).

---

Generated by Claude Code