fix(metadata-protocol)!: refuse publishing a hierarchy-scope grant when no hierarchy resolver is mounted; explain names the absent resolver (#26188) - #26305

📓 Docs Drift Check

This PR changes 3 package(s): @objectstack/metadata-protocol, @objectstack/plugin-security, @objectstack/spec, touching 25 documentable anchor(s). ⚠️ 2 changed file(s) yielded no anchor (packages/spec/api-surface/security.json, packages/spec/export-origins/security.json), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

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

• content/docs/concepts/metadata-lifecycle.mdx (via ObjectStackProtocolImplementation (symbol, a top-level class))
• content/docs/kernel/runtime-services/sharing-service.mdx (via own_and_reports (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability), unit_and_below (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability))
• content/docs/permissions/access-recipes.mdx (via own_and_reports (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability), readScope (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability), unit_and_below (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability), writeScope (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability))
• content/docs/permissions/administrator-guide.mdx (via unit_and_below (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability))
• content/docs/permissions/attachments-access.mdx (via unit_and_below (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability))
• content/docs/permissions/capabilities.mdx (via own_and_reports (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability), unit_and_below (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability))
• content/docs/permissions/index.mdx (via own_and_reports (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability), readScope (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability), unit_and_below (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability), writeScope (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability))
• content/docs/permissions/permission-sets.mdx (via own_and_reports (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability), readScope (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability), unit_and_below (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability), writeScope (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability))
• content/docs/permissions/permissions-matrix.mdx (via own_and_reports (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability), readScope (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability), unit_and_below (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability), writeScope (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability))
• content/docs/permissions/positions.mdx (via own_and_reports (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability), readScope (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability), unit_and_below (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability), writeScope (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability))
• content/docs/permissions/rls.mdx (via readScope (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability))
• content/docs/permissions/sharing-rules.mdx (via own_and_reports (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability), readScope (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability), unit_and_below (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability))
• content/docs/permissions/system-context.mdx (via explainAccessForCaller (symbol, a top-level function))
• content/docs/protocol/kernel/plugin-spec.mdx (via resolveWritePackageScope (literal, a string literal in assertRuntimeAuthoringRules))

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

• content/docs/releases/v15.mdx (via unit_and_below (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability))
• content/docs/releases/v16.mdx (via ObjectStackProtocolImplementation (symbol, a top-level class))
• content/docs/releases/v17/17-0.mdx (via ObjectStackProtocolImplementation (symbol, a top-level class))
• content/docs/releases/v17/17-5.mdx (via readScope (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability), writeScope (literal, a string literal in findHierarchyScopeGrants; a string literal in validateHierarchyScopeCapability))

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.

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin f7c7a36c0b6ac2173a74543c1ef614f7984c722c && git checkout f7c7a36c0b6ac2173a74543c1ef614f7984c722c
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 69aa630b9fd6ef20f76cbac9ed4d9b9efa69c804 1267e3cb2b5cec5d538fd5da7401a68bd0adde78 && git checkout -B drift-repro 69aa630b9fd6ef20f76cbac9ed4d9b9efa69c804 && git merge --no-ff 1267e3cb2b5cec5d538fd5da7401a68bd0adde78

node scripts/docs-audit/affected-docs.mjs --json 69aa630b9fd6ef20f76cbac9ed4d9b9efa69c804

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

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 1267e3cb2b5cec5d538fd5da7401a68bd0adde78
Local-runs: none
Scope: packages/spec/src/security/permission.zod.ts, packages/spec/src/stack.zod.ts, packages/spec/api-surface/security.json, packages/spec/export-origins/security.json, packages/spec/src/security/permission.test.ts, packages/metadata-protocol/src/runtime-authoring-gate.ts, packages/metadata-protocol/src/protocol-authoring-gate.ts, packages/metadata-protocol/src/protocol.ts, packages/metadata-protocol/src/runtime-authoring-gate.hierarchy-scope.test.ts, packages/metadata-protocol/src/protocol.runtime-authoring-gate.test.ts, packages/plugins/plugin-security/src/explain-engine.ts, packages/plugins/plugin-security/src/security-plugin-explain-access.ts, packages/plugins/plugin-security/src/explain-engine.test.ts, packages/plugins/plugin-security/src/explain-read-verdict-inputs.test.ts, packages/qa/dogfood/test/showcase-scope-depth-fallback.dogfood.test.ts + packages/metadata-protocol/src/plugin.ts, packages/core/src/kernel.ts, packages/core/src/kernel-base.ts, packages/core/src/lite-kernel.ts, packages/core/src/plugin-loader.ts, packages/plugins/plugin-sharing/src/sharing-plugin.ts, packages/plugins/plugin-sharing/src/sharing-service.ts, packages/spec/src/contracts/sharing-service.ts, packages/spec/src/api/error-code-ledger.zod.ts, packages/spec/src/api/protocol.zod.ts, packages/spec/src/stack-refusal-envelopes.test.ts, packages/plugins/plugin-security/src/index.ts, packages/qa/dogfood/test/showcase-scope-depth.dogfood.test.ts, packages/qa/dogfood/test/showcase-scope-depth-write.dogfood.test.ts, packages/qa/dogfood/test/federated-phantom-share-grant.dogfood.test.ts, packages/qa/dogfood/test/admin-platform-admin-standing.dogfood.test.ts, examples/app-showcase/src/security/permission-sets.ts, scripts/pm/clause2-line.mjs, scripts/check-changeset-no-major.mjs, scripts/check-adr-0087-registration.mjs, .changeset/26188-hierarchy-scope-without-resolver.md (prose face)

Read on the net diff origin/main...origin/pr-26305 (merge base 617f27eb), 16 files, 555+/36-. Inputs: card #26188 and all three comments, ruling 6416233738 and item reading 6415971852 on #26059, os-dev-report 6426008287, PR body and file list, the head's 41 check-runs.

① Derived judgments

Public-surface changes the diff implies, each judged.

1. @objectstack/spec/security gains the export findHierarchyScopeGrants(permissionSets: unknown). Pure, tolerant of any input, no Zod schema touched; api-surface/security.json and export-origins/security.json each gain exactly the one matching row. The claim allowed one spec export of the existing helper; this is it. Right. The stack-refusal-envelopes.test.ts pin is a verbatim fragment (uses readScope='unit_and_below', a HIERARCHY scope), not the whole sentence, so byte-identity of defineStack's text is a reading, not a pin: compared line for line, the old inline loop and the new ${g.finding}. + the two unchanged tail fragments produce the same string (same array guard, same objects guard, same key order, same HIER set, String(ps?.name ?? '?') equals the template's coercion). Byte-identical; right. findHierarchyScopeGrants is a sound single source: one list, one sentence, both doors append their own remedy.
2. @objectstack/plugin-security: ExplainEngineDeps (a public type export, index.ts:88) gains the optional member hierarchyResolverMounted, an optional function returning boolean. Absent reads as before. Right, and correctly declared as a widening.
3. @objectstack/metadata-protocol: two new exports from runtime-authoring-gate.ts (HIERARCHY_SCOPE_CAPABILITY_REQUIRED, HIERARCHY_SCOPE_RESOLVER_SERVICE) and findHierarchyScopeCapabilityGaps; evaluateRuntimeAuthoringGate gains the optional hierarchyResolverMounted argument; AuthoringGateHost gains the same member. All additive. Right. One note: the service name is spelled a fourth time as a string literal (the sharing plugin, the explain wiring and spec/contracts/sharing-service.ts prose each spell 'hierarchy-scope-resolver' by hand); the new constant is not read by the sharing plugin. Not a defect, see ③.

Accept-set change (the narrowing), bounded exactly.

• What is refused: a write whose singular type is permission only (args.type !== 'permission' returns early; the object draft test pins it), whose body carries readScope or writeScope equal to one of own_and_reports, unit, unit_and_below (both axes, each depth, pinned by the 3x2 loop), on a write with state: 'active', when hierarchyResolverMounted === false. own and org are untouched. One issues[] entry per grant, located at permissions.NAME.objects.OBJECT.readScope|writeScope, inside the gate's existing 422 INVALID_METADATA envelope under rule hierarchy-scope-capability-required. Right, and inside the ruling (9a: "refuse on publish").
• Which doors: assertRuntimeAuthoringRules is the one body all four reach. Direct active save (saveMetaItem, protocol.ts:21167); per-item publish and the package batch publish both go through promoteDraftForPublish (:22918, called at :22512 and :23957); restore goes through refuseRestoredBodyTheSaveDoorRefuses with state: 'active' (protocol-authoring-gate.ts:131). Four doors, one rule, right.
• Restore-to-version: refused too. This is not a new door the PR invented: "a restore refuses what the save door refuses" is the standing invariant of refuseRestoredBodyTheSaveDoorRefuses ([maintainer] refactor(metadata-protocol): split src/protocol.ts (33,065 lines, +10,169 in 30 days) along its ObjectStackProtocolImplementation seams, one move-only slice per PR #25467 cut 8), and re-activating a stored version that carries an unenforceable grant would make the same inert declaration live. The card names PUT and publish as the measured doors and asks that "the runtime path match" defineStack; a restore is a runtime activation. Within the ruling's shape; right. Restore carries no advisories (its receipt declares none), so a restore of a draft-state version hears nothing; drafts are not restored to active, so nothing is lost.
• Draft save: the draft branch of both assertRuntimeAuthoringRules and evaluateRuntimeAuthoringGate returns the same finding at severity: 'warning', error: null; saveMetaItem attaches a non-empty advisories array to the 2xx regardless of mode (:21590). The branch reads no collection and no stored row (the migrate-stored pass still returns [] first). Consistent with D1: no rule gates a draft; a draft now hears one warning. The gate's own D1 comment was updated to say so. Right.
• Host with no service registry: hierarchyResolverMounted() answers undefined only when getServicesRegistry is absent on the protocol (a direct construction) or the lookup throws; the gate judges nothing on undefined (pinned). Through MetadataProtocolPlugin (plugin.ts:249) the registry is always a function; on a kernel whose context lacks getServices it answers new Map(), which reads as false. Both in-repo kernels (ObjectKernel, and LiteKernel via kernel-base) expose getServices() as a copy of a plain Map (kernel-base.ts:130, kernel.ts:319), so every in-repo production host is judged, and the undefined reading is the exact shape rlsMembershipResolverKeys already has. Left unjudged on purpose, and the purpose holds: defineStack is that host's door. The PR body's "the CLI" phrasing is looser than the code (the CLI's os serve boots a kernel and is judged; what is unjudged is a protocol built without a registry), but the behaviour is right.
• Can a deployment WITH an enterprise resolver be refused? Not by any in-repo path. The protocol reads ctx.getServices(), a snapshot of kernel.services; kernel.registerService writes that map and the loader (kernel.ts:383-388), which is how the reference resolvers in the dogfood worlds register. The sharing plugin reads ctx.getService('hierarchy-scope-resolver') (sharing-plugin.ts:690), a three-tier lookup (services map, then the loader's instances, then factories). The two agree for a registerService-registered resolver. They would disagree for a resolver registered through registerServiceFactory and not yet resolved once (it sits in the loader only until the first ctx.getService caches it): the protocol would read "absent" while sharing enforces it. No in-repo plugin registers any service by factory, the enterprise plugin lives in cloud and is not readable from here, and rlsMembershipResolverKeys and the SDUI-manifest read carry the identical exposure today. Judged: the PR's "same lookup the sharing plugin uses" is overstated (same name, not same resolution), the practical answer is no, and the residue is a pre-existing shape; recorded as a ③ flag, not a defect of this PR.
• Resolver mounted: true returns [] on both states (pinned, pure and through a real registry). Nothing changes; right.
• package-author channel: assertRuntimeAuthoringRules still returns [] before the draft branch, so a package-author write hears neither the warning nor the refusal. That is the gate's standing posture (package authoring is judged by os build / defineStack, where this grant is already refused), and the ruling's door is the environment save door. Right, unchanged, noted in ③.

INVALID_METADATA with rule: 'hierarchy-scope-capability-required' and the ADR-0112 ledger. The ledger's unit is the code, and provenance is per emitting package: INVALID_METADATA is already registered under @objectstack/metadata-protocol (ledger line 673, inside the 653-723 block), so a new rule id inside its existing issues[] envelope adds no stamp site the provenance gate (check:error-code-provenance) would sweep and no row is owed. Reusing STACK_HIERARCHY_SCOPE_CAPABILITY_REQUIRED at an HTTP door would have been a new emitter of a door: 'none' spec code (line 1574, the defineStack family comment "where a throw aborts before any HTTP boundary exists"), owed a metadata-protocol row in the file this claim keeps off. The card's acceptance line ("either reused or a new row; the PR names which") is met: the PR names the reuse and says why. Correctly outside the ledger's requirement; right. A rule id is a RuntimeAuthoringIssue.rule string, the key a renderer groups by, not a wire code.

Explain (9b). The new arm sits after ownerIsMe and after depthAdmitsRow and before the sharingMatches === false arm (explain-engine.ts:2096-2110), guarded by depthScope !== 'org' (the !depthWidens arm above already caught own, so only hierarchy depths reach it) and deps.hierarchyResolverMounted?.() === false. depthAdmitsRow requires sharingMatches === true && !ownerIsMe && !anyShareAdmits && (org || sharingFilter !== null), so a row the depth really admitted is never reported as resolver-absent. Outcome excluded when the owner-match failed, not_evaluated when the row got in some other way. The wiring reads resolveKernelService('hierarchy-scope-resolver') != null per explain, kernel-side, and the real-stack harness now registers its stub under that kernel name and hands the sharing service the same lookup, which is the honest fixture. Right. One corner is worded wrong, not misattributed: a hierarchy depth on an object whose sharing filter is null (no owner column, a bypass object) on a resolver-less runtime now lands in the new arm with sharingMatches === true (the matcher admits a null filter) and anyShareAdmits === false, and the detail ends "a share admits this record (see the sharing layer)", where before the PR the sharingFilter === null arm said "the sharing service imposes no owner-match on this object". The outcome (not_evaluated) is right; the sentence is not. Reaching it needs a stored hierarchy grant on an ownerless object on an open-edition runtime, a row the door now refuses to create. Recorded in ③ as a follow-up, not blocking.

Shipped examples, apps and dogfood worlds. Read every world that declares a hierarchy depth: showcase-scope-depth (bootScopeWorld('unit', false)) and showcase-scope-depth-write (withResolver: false) deliver their profile through bootShowcase({ defaultPermissionSets }), the SecurityPlugin catalog, never the metadata door, so the gate does not run there; federated-phantom-share-grant drives sharing.checkEdit with a context __writeScope, no metadata write; admin-platform-admin-standing only mentions the scope in prose. authz-conformance.matrix.ts names the depth as a matrix id. examples/app-showcase deliberately authors no hierarchy depth (permission-sets.ts:131-137: "this open example does not author them"). The only world that PUT a hierarchy grant through /meta/permission with no resolver was showcase-scope-depth-fallback, and the dev's full battery at 4cf2c1a5 measured exactly that one failure. The fix at 1267e3cb is test-only, pins the 422 + rule through the real HTTP door first, then saves with the reference resolver mounted and unmounts it from both stores (kernel.services and pluginLoader.serviceInstances, consistent with the kernel's two-tier getService), so the fail-closed read is still proven against a stored row. No shipped example, app or world is newly refused; the one affected world is fixed honestly. The tests claimed (7 pure, 3 door rows, 2 explain cells, 1 real-stack cell, 2 spec rows, 4/4 dogfood) are all present in the diff, and the three ablation legs each name the line that would go red.

② Semver level

• Changeset .changeset/26188-hierarchy-scope-without-resolver.md: @objectstack/metadata-protocol: patch, @objectstack/plugin-security: patch, @objectstack/spec: patch. Metadata-protocol: none is the right kind: PermissionSetSchema parses exactly what it parsed before, no authorable key, value or default moves; the refusal is a runtime-gate rule conditional on a deployment fact, the class the [转移] 发布期护栏:多组织下「平台级 + schedule + create_record + 未显式 organization_id」拒绝——#6155 Q3=A 裁决的 lint 半边 #6285 and forms: on a walled tenancy posture a published public form bound to a tenant-scoped object is served (GET 200) but every anonymous submit answers 500 ERR_SYSTEM_WRITE_ORGANIZATION_REQUIRED #21476 rules belong to. Under ruling A the level follows the kind alone, so none takes patch on all three. (A reading of "a value refused" as narrowed would require minor on metadata-protocol; I resolve it for the PR because the protocol an author writes against is unchanged, and the gate's own rule reads narrowed as a contradiction only beside a missing (narrowing) arm.) Right.
• Clause-②: yes (narrowing: on a runtime with no hierarchy resolver, … ; widened: …) on both the PR body and the changeset. Through scripts/pm/clause2-line.mjs the value reads yes and readArmToken reads narrowing (the arm regex accepts the word followed by :, which is neither a word character nor |); the rest of the parenthetical is the seat's argument and is ignored. That is the documented combination "yes (narrowing): a diff that widens one surface and narrows another. Both facts are true and both are read." The spelling is what the repo's rules and the Check Changeset gate expect for a narrowing that also widens; the claim's provisional no (narrowing) was rightly revised, since a no would have denied the spec export. Right.
• BREAKING: the (narrowing) arm is BREAKING, so a banner and an ADR-0087 disposition are owed. Present: a **BREAKING** banner with Before / Now / Fix; the title and the changeset summary carry the ! (fix(metadata-protocol)!:); exactly one adr-0087 marker, not-required (no-migration-prescription), a category in CATEGORIES. The body carries no FROM→TO label, no rewrite arrow and no framed migration section, so the prescription detector has nothing to refuse, and the exemption is honest: the author's repair is a choice between a non-hierarchy depth and an enterprise runtime, which no ledger entry can derive. check-adr-0087-registration.mjs runs inside the Check Changeset job (pr-automation.yml:999), which concluded success on this head. Owed and present; right.
• No authorable-surface/ or authorable-defaults/ baseline moves; api-surface and export-origins rows are the only spec artifacts owed for a function export, and both are present.

③ Boundary flags

1. Dev deviation: Clause-②: yes (narrowing…) instead of the provisional no (narrowing). Accepted, see ②. The spec export and the public ExplainEngineDeps member are real widenings.
2. Dev deviation: two harnesses changed beyond the new cells. explain-read-verdict-inputs.test.ts moving its stub resolver into the kernel service map is a correction (the old harness gave the sharing service a resolver the kernel never knew, which is exactly the contradiction 9b is about). The dogfood world's rework is judged in ①. Accepted.
3. Acceptance note 1: SaveMetaItemResponseSchema.advisories .describe() left stale. Read at protocol.zod.ts:1064-1076: "applied to this body on its way to active" is now partly stale, since a draft save can carry this one warning. The key's shape and the invariant that matters to a consumer ("every entry has severity warning or info", "present only when at least one advisory was raised") still hold, and the text is description only. Accepted as a one-line docs-only follow-up on packages/spec, outside this claim's one-spec-change allowance. Not blocking.
4. Acceptance note 2: the object-level depth layer (no record) is unchanged. The ruling names explain-engine.ts:2040-2075, the record cell. The object-level cell describes the declared depth, which on a resolver-less runtime is still what the metadata says. Within scope; a future card could add the same resolver-absent sentence there. Not blocking.
5. Out-of-scope finding on the lookup shape (mine). The protocol reads ctx.getServices() (a snapshot of kernel.services) while the sharing plugin reads ctx.getService(...) (three tiers). A resolver registered by factory and never resolved would be read as absent at the publish door while sharing enforces it. No in-repo registration takes that path; the cloud SecurityEnterprisePlugin is not readable from this repo (the card says the same of apps/objectos-ee/objectstack.config.ts). The cloud checklist card the ruling names (Q4 cloud lane, licensed posture re-run) is the place this gets measured. Escalated as a one-line note to that card's owner; not blocking here.
6. Explain wording corner (mine). The sharingFilter === null case under a resolver-less hierarchy depth now says "a share admits this record" where no share and no owner-match exist (①). Outcome right, sentence wrong, reachable only for a stored pre-PR grant on an ownerless object. Follow-up on plugin-security; not blocking.
7. package-author channel unchanged. A package-author write of the same grant is still silent at the runtime gate, by the gate's standing design (os build / defineStack is that channel's door and already refuses it). Within the ruling; recorded so nobody reads the four doors as five.
8. Check-runs on the head. 20 concluded: Check Changeset, Governed Surface Queue Guard, Lint · PM dispatch-gates, Lint · scoped · tooling self-tests, Dogfood Regression Gate, Spec property liveness, Check PR Size, Check Documentation Links, Flag docs affected by code changes, Auto Label, filter, the three claim/closing-target guards and Part-of PR must not also close its card all success; Build Docs, Dogfood Regression Gate (matrix), Dogfood Verify CLI, Packed-tarball smoke, Temporal Conformance, 18.x upgrade harness skipped. 20 not yet concluded at the time of this record: Build Core, Build UI Deps, Lint · CI, release & engine gates, Lint · ESLint, Lint · docs & code guards (hosts check:error-code-provenance and check:dispatcher-error-vocabulary), Lint · repo & tooling gates, Lint · scoped · query-options erasure, Lint · scoped · slot lookup & corpus, Test Core (1/8) through (8/8), Type Check · consumer gates (hosts check:api-surface), Type Check · debt ledger, Type Check · source gates, Type Check · workspace. The dev's reading is 99 derived gates at exit 0 and three packages green locally; the landing still waits for every check to conclude green (Tier S: record plus every check green).
9. Governed surfaces. The file list touches none (GOVERNED_SURFACES paths absent; Governed Surface Queue Guard success). Head repo is objectstack-ai/objectstack, not a fork. The PR is a draft; its tier is decided by the published-schema hits (permission.zod.ts, stack.zod.ts), which is this record's face.
10. Dev open questions: none reported. Write budget and MCP calls: reads only, three relay writes, as reported; nothing to escalate.

Implemented-by: claude/project-thread-qp1ljk
Reviewed-by: session_01R1q2xdtYgU6FKrZ7LgjPCC

VERDICT: PASS

Generated by Claude Code

席位核对 · ACCEPT · domain:server seat 1 · os-project-manager · session_01R1q2xdtYgU6FKrZ7LgjPCC · 2026-10-26T20:27Z

Head 1267e3cb2b, report 6426008287 (on #26188), claim 6424008328. The contract review is owed, because the diff touches packages/spec/src/** and declares a narrowing. It is on record: PASS at CONTRACT_REVIEW_TIER on this head (6426321194).

Generated by Claude Code