[objectstack-fleet]

Requested by Tesla · project thread

Clause-②: yes (narrowing) — both arms. Narrowing: POST /api/v1/packages/:id/ensure-customization answers a kernel base (scope system / cloud) with 409 RESOURCE_CONFLICT, where it created <id>.custom; POST /api/v1/automation/:name/clone of a kernel-shipped flow with no package named answers that 409 where it answered 200 with the copy in <id>.custom; the exported pair helpers take the installed-manifest lookup as a required argument. Widening: five new exports, installedManifestsOf, InstalledManifestLookup, AppLookupManifest and InstalledPackageSource (@objectstack/metadata-core) and kernelPackageScope (@objectstack/metadata-protocol), and a copy of a kernel-shipped permission set with no package named is saved environment-wide under the new notice code PERMISSION_SET_CLONE_ENVIRONMENT_WIDE_KERNEL_SOURCE, where it landed in <kernel id>.custom.
Metadata-protocol: none

Refs #29594
Ruling-ref: 6691022506
Ruling-ref: 6691217245

维护者速读

• 改了什么：①所有「这个包的定制包是谁」的问题（pairOf / isPairOf / isServedOverrideRowOf / 写闸 / flow 优先级 等 23 处、14 个文件，连同 cli 与 cloud-connection 的调用方）都改为携带「已安装清单查询」，appOf 仍是恒等，行为不变；②ensure 门对内核包（scope system / cloud）返回 409 RESOURCE_CONFLICT，不再创建 <id>.custom。
• 为什么改：按裁定 6691022506（定制单位 = App）与 6691217245（本版本内核对象一律不可定制，ensure 门给可读的拒绝而非 422）。查询先穿好，PR 3 才能只改 appOf 一处把模块解析到它的 App。
• 风险与回滚：已在某些部署上由旧门建好的内核配对包继续安装、继续被读取、继续可写，只拒绝 ensure 调用；内核条目的无包写入与指名内核包的写入仍按 D11 拒绝（403 NOT_OVERRIDABLE），提示语改为「本版本内核对象不可定制」，不再点名配对包；克隆平台权限集（如 member_default）且未指定包时，副本改存为环境级（维护者已选 A，2026-11-07T01:01Z）。回滚即 revert 本 PR。
• 先看：packages/metadata-protocol/src/protocol-customization-package.ts（内核判定）、packages/metadata-core/src/customization-pair-lookup.ts（查询入口）、packages/objectql/src/protocol-custom-override-effective-read.test.ts 末尾两条钉子。
• 两分钟验证：pnpm --filter @objectstack/runtime exec vitest run --project local src/domains/packages-ensure-customization.test.ts（内核 409、旧配对包保留）；pnpm --filter @objectstack/objectql exec vitest run --project local src/protocol-custom-override-effective-read.test.ts（旧内核配对包的覆盖继续生效；两道关闭对内核条目仍拒绝且不点名配对包）。
• 需要你做的：无，席位落地。PR 3（appOf 翻转、旧配对包容忍、ensure 门回答 App 配对包、HotCRM 演练）在本 PR 合并且 ADR-0146 修订 docs(adr): ADR-0146 D3 — one .custom pair per App, and one platform pair for the kernel suite #31027 合并后开工。

What changes

1. The installed-manifest lookup, threaded through every pair site (behaviour unchanged)

pairOf(base) = customizationPackageId(appOf(base)) landed in #31026 with appOf the identity. Resolving a module to its App (ADR-0146 amendment, merge question 11, #31027) needs the registry's installed manifests (type / dependencies / namespace / scope) at every site that asks "which pair customizes this package?". If only the ensure door resolved the App, the override gate and the served-override read (still identity) would refuse or hide the very override written into the App pair. So this PR threads the lookup everywhere first, with appOf still the identity, and PR 3 becomes a one-place flip.

• @objectstack/metadata-core: InstalledManifestLookup, installedManifestsOf(registry); appOf, pairOf, isPairOf take the lookup (required, so the compiler names every site that has not passed it).
• @objectstack/metadata-protocol: installedManifestsOfEngine(engine); isServedOverrideRowOf(row, base, installed), OverrideWriteClosure.installed, the overlay merge, the lock state, the layered/list reads, the per-package layer, the stored-flow slot, the served-overrides census, the package-less migration census, the packaged-base refusal and the write gates. Hosts that read the engine gain the engine getter (the codebase's readEngine pattern).
• Callers outside it: objectql (plugin, registry uninstall refusal), runtime (customizeInPairRemedy, the per-package customizations read), service-automation (flow precedence, with the objectql registry), service-datasource, cli (offline override declarations: the walked manifests), cloud-connection (install-local: the delivered manifests over the registry's).
• Proof nothing moves: customization-pair-lookup.test.ts asks every row twice, with nothing installed and with every row installed (the module declaring its App the way HotCRM's modules do), and gets the old derivation; every existing suite of the touched packages is green with the lookup passed.
• Review nit 3 of refactor(metadata-core): look up a package's customization pair through the App that carries it (pairOf), behaviour unchanged #31026: os validate's customization-namespace advisory skips a pair through isCustomizationPackage. Edge: an id ending in .custom that no base derives (a.custom.custom, bare .custom, A.custom) was skipped before, because customizationPackageId answers base_is_customization_package for it, and is now judged like any package, because isCustomizationPackage answers false (measured on the head's spec build).

2. The kernel verdict on the ensure door (narrowing)

Call	Before	After
ensure a kernel base (scope system / cloud), no pair yet	201, creates <id>.custom	409 RESOURCE_CONFLICT, nothing created or written
ensure a kernel base whose pair an earlier version created	200, created: false	409 RESOURCE_CONFLICT; the pair stays installed and readable
every read of a kernel item's name with a declared override in that legacy pair	the override is served	unchanged
a save into that legacy pair declaring the override	admitted	unchanged (the write gate never asks the ensure door)
package-less save onto an item a kernel package ships (overlay types)	403 NOT_OVERRIDABLE, naming the pair	403 NOT_OVERRIDABLE, the sentence says kernel objects are not customizable in this version and names no pair
save naming the kernel package onto an item it ships	403 NOT_OVERRIDABLE, naming the pair	403 NOT_OVERRIDABLE, the same sentence, no pair named
clone a kernel-shipped permission set, no package	200, copy in <kernel id>.custom (created)	200, copy environment-wide, code PERMISSION_SET_CLONE_ENVIRONMENT_WIDE_KERNEL_SOURCE
clone a kernel-shipped flow, no package	200, copy in <kernel id>.custom	409 RESOURCE_CONFLICT, the ensure door's sentence
any non-kernel base	—	unchanged

The code. 409 RESOURCE_CONFLICT is the door's existing family for "the base's state rules the pair out" (a writable base, no namespace, a namespace with no pair namespace, a non-SemVer version, a malformed existing pair), every one of which answers RESOURCE_CONFLICT in packages-ensure-customization.test.ts. 403 would misread as an authority problem (even the platform operator is refused), and 422 NAMESPACE_CONFLICT names another condition. No ledger code and no packages/spec edit.

Where. First in customizationPairEnsureRefusal, the one reading of the door's registry-decidable refusals, and the two overlay closes keep their place: overlayPairFixOf asks the door's other judgements with the kernel verdict left out (judgeKernel: false) and marks a kernel base's fix with its kernelScope, so the package-less close and the close of a write naming the base stay shut on a kernel item exactly where they were, with a sentence that names no pair (seat ruling on review should-fix 2; ruling record 6691217245; #31027 Q10 is unmerged).

The "new similar" doors (found by the dogfood battery). The permission-set clone door landed a copy of a kernel-shipped set (member_default, shipped by com.objectstack.plugin-security, scope system) in the source package's pair through the ensure door, so the verdict refused the commonest lock-and-clone path. A clone is a new item, not a customization of the kernel item, so with no package named the copy is now saved environment-wide, exactly as a copy of an environment-authored set is, with its own notice and code (PERMISSION_SET_CLONE_ENVIRONMENT_WIDE_KERNEL_SOURCE; a Console that does not know the code shows the English sentence, as it does for any unknown code). A named package still lands there. The kernel predicate is one spelling, kernelPackageScope (@objectstack/metadata-protocol), read by the door and the clone door. The flow clone door has no environment-wide landing (an unpackaged flow already needs package), so a kernel-shipped flow gets the ensure door's 409 sentence. This landing is option A of a decision card put to the maintainer; B (refuse, naming package) and C (a kernel pair for clones only) are the alternatives.

Test fixtures. packages-ensure-customization.test.ts and automation-flow-clone-custom-package.test.ts modelled "an installed app" as scope: 'system', which is the kernel's scope (manifest schema: system = cross-project shared identity, cloud = control plane). They now hold the base as code, the way an installed app's packages are held (HotCRM 6961ab1 declares no scope).

Blast radius (measured on origin/main 3fe5f2a)

23 pairOf / isPairOf sites in 14 files; isServedOverrideRowOf 17 non-test callers; judgeOverrideWrite 4 (incl. cli offline and cloud-connection install-local). This PR: 31 source files (+471 / −156), 16 test files (+342 / −123), one changeset; 48 files, +842 / −279 in all.

PR 2 / PR 3 split

• PR 2 (this): the lookup through every site, appOf the identity; the kernel verdict.
• PR 3 (after this lands and docs(adr): ADR-0146 D3 — one .custom pair per App, and one platform pair for the kernel suite #31027 merges): appOf resolves App membership from the lookup (Q11); legacy per-package pairs stay served (Q12: isPairOf accepts the App pair or an installed legacy <base>.custom); the ensure door answers the App pair with basePackageId = the App id (the spec describe "packageId: <basePackageId>.custom" stays true); the HotCRM rehearsal.

Findings kept for PR 3: the package-less migration's incomplete-declarations census parses pair→base (customizationBasePackageId) and misses module overrides under the App unit; its census still lists a kernel item's package-less row as movable and the apply step fails it with the kernel sentence (a disposition for it is a contract question); the dogfood helper customization-pair.ts and six ui/packages/app-shell call sites derive <base>.custom client-side; a customizable flag on the package list row would need a spec sub-card. A package-less row on a kernel item stored before the D11 close stays served, but nothing can move it now: its package-less delete is closed, and the ceremony's ensure step refuses the kernel base. Its disposition belongs with the census question already listed.

Verification

Head b94d1ac68d151d99ad908992ad25f65bf2413a6d, which merges today's origin/main 022b4e7 (merge commit 20c8cd6, no conflicts; no rebase). Exit codes landed on disk before reading.

Run	Result
pnpm typecheck in metadata-protocol, objectql, runtime, service-automation (head)	exit 0 each
pnpm test on the head: metadata-protocol / objectql / runtime / service-automation / metadata-core / lint	exit 0 each: 22512 (+26 skipped) / 11360 / 8876 (+19 skipped) / 3431 / 962 / 8331 passed
pnpm test on 1340933c for the packages this round did not touch: service-datasource / cloud-connection / cli	exit 0 each: 1279 / 931 / 7415 (+9) passed
dogfood battery on 021a8a3d (no dogfood pin moved this round)	exit 0: 428 files passed, 3 skipped; 3562 tests passed
eslint --no-inline-config on every .ts file this round changed	exit 0
dispatch-gates --commands on the head (102 families: the 101 of the last round plus check:overlay-whitelist-table, which the lifecycle docs edit adds), each run with </dev/null	102 exit 0 on the first pass; reconciled with --ran: 102 derived, 102 run, 0 NOT-MEASURED, 0 UNRUN

Gate notes: the three first-pass non-zeros of the earlier round (check-plugin-teardown-shape --self-test, check:dual-build-cjs-loads, check:test-source-alias) all exit 0 on this head with no further change.

Ablations (scripts/ablation-replace.mjs, restore proven by blob hash == HEAD and an empty git status --porcelain):

• the kernel check in customizationPairEnsureRefusal disabled (ablation-dist-preflight confirmed the mutation in metadata-protocol/dist): red — the three runtime door pins (system, cloud, the legacy kernel pair) and the objectql pin of the legacy pair served after a refused ensure;
• the kernel landing in resolveDefaultCloneLanding disabled: red — [#29594] a set a kernel package ships copies environment-wide;
• the kernel close in overlayPairFixOf disabled (judgeKernel: false removed, metadata-protocol dist rebuilt and checked): red, the closes keep refusing a kernel item's save, naming no pair (the save was admitted);
• restoreFlowRegistration on a refused landing in registerAndSaveFlow disabled: red, both [#29594] a kernel-shipped flow cases (the engine held the copy).

Both restored with git checkout, tree clean, suites re-run green.

The lookup threading needs no ablation: it changes no answer, which every existing suite of the nine packages confirms, and customization-pair-lookup.test.ts pins that both lookups (nothing installed, every row installed) give the old derivation.

Acceptance notes

• The harness's assignee/reviewer step is skipped: this PR goes through the relay as a draft, and review is requested by the seat.
• No packages/spec, ui/ or skills/ edit; no ADR edit.
• 51 files: 31 source files, 16 test files, 3 docs pages (content/docs/concepts/metadata-lifecycle.mdx added), 1 changeset.

[github-actions]

📓 Docs Drift Check

This PR changes 9 package(s): @objectstack/cli, @objectstack/cloud-connection, @objectstack/lint, @objectstack/metadata-core, @objectstack/metadata-protocol, @objectstack/objectql, @objectstack/runtime, @objectstack/service-automation, @objectstack/service-datasource, touching 105 documentable anchor(s). ⚠️ 1 changed file(s) yielded no anchor (packages/metadata-protocol/src/index.ts), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

21 hand-written doc(s) name something this change touched — list omitted above 15 rows. Re-derive on the tree named below: node scripts/docs-audit/affected-docs.mjs --json 23cf11a4b9f3fa8c7291b5d7a308c5d14793b006.

⛔ 10 release-owned page(s) also affected — read-only, see AGENTS.md Documentation Guardrails.

What this run could not see

• 1 changed file(s) yielded no anchor (packages/metadata-protocol/src/index.ts) — pages documenting those are invisible to this run
• 1 cross-cutting symbol(s) contributed no route anchor: packageId (4 routes)
• 7 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 63 of 224 client-bound route-ledger rows — the other 161 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 161: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 57 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 104 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 — 70 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 23cf11a4b9f3fa8c7291b5d7a308c5d14793b006 → packageMentionDocs.

Which tree this was computed on

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

node scripts/docs-audit/affected-docs.mjs --json 23cf11a4b9f3fa8c7291b5d7a308c5d14793b006

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

[objectstack-fleet]

domain:server#2 · os-tesla · session_01L9qibyvxbrLP4jm4PargoH

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: ee5587b408d451fe8bc52c83d9b630d4f15852d3
Local-runs: none
Scope: the whole net diff 3fe5f2a025...ee5587b408 (50 files, +850 / −281): packages/metadata-core/src/customization-pair-lookup.ts (+ test), packages/metadata-protocol/src/installed-manifests.ts (new), index.ts, protocol.ts (the six host getters), protocol-class-head.ts, protocol-customization-package.ts (the kernel verdict), protocol-diff-delete-load.ts, protocol-discovery-and-bases.ts, protocol-environment-rows.ts, protocol-lock-state.ts, protocol-meta-layered-reads.ts, protocol-meta-list-reads.ts, protocol-overlay-merge.ts, protocol-package-bindings.ts, protocol-packaged-base-refusal.ts, protocol-packageless-overlay-migration.ts, protocol-registry-hydration.ts, protocol-served-overrides.ts, protocol-write-gates.ts, served-override.ts, stored-flow-slot.ts; packages/objectql/src/plugin.ts, registry.ts; packages/runtime/src/domains/packages.ts, permission-set-clone.ts; packages/services/service-automation/src/flow-precedence.ts, plugin.ts; packages/services/service-datasource/src/plugin.ts; packages/cli/src/utils/override-declarations.ts; packages/cloud-connection/src/marketplace-install-local-plugin.ts; packages/lint/src/validate-customization-namespace.ts; the 16 test files and the dogfood pin; .changeset/29594-pair-lookup-installed-kernel-verdict.md; content/docs/api/metadata-api.mdx, content/docs/permissions/permission-sets.mdx (the docs commit ee5587b4). Read beside it on the head: packages/metadata-protocol/src/package-writability.ts 38–83 (READ_ONLY_PACKAGE_SCOPES, isWritablePackage), protocol-customization-package.ts 274–470 whole (the door's order of judgement, ensurePairOnce), protocol-packaged-base-refusal.ts 400–470 (overlayPairFixOf), packages/runtime/src/domains/automation.ts 2432–2625 (registerAndSaveFlow, resolveCloneTarget), permission-set-clone.ts 300–345 and 490–612 (landing, name-taken, save), new-similar-target.ts header, packages/spec/src/kernel/manifest.zod.ts 636 (scope enum), packages/spec/src/api/package-lifecycle.zod.ts 623–660 (the ensure describe), packages/spec/src/api/error-code-ledger.zod.ts (RESOURCE_CONFLICT rows), every scope: 'system' | 'cloud' declaration under packages/** non-test (35 sites, all platform-delivered), the three PERMISSION_SET_CLONE_* code readers under ui/packages/app-shell, content/docs/concepts/metadata-lifecycle.mdx 185 and 216, content/docs/deployment/install-modes.mdx 112, PR #31027's ADR-0146 text at 2990a3dc (D3 "The unit is the App", D11 merge questions 10, 11, 12), HotCRM 6961ab1 src/*/index.ts manifests (no scope), the check-runs on 1340933c and on ee5587b4.

Inputs read: rulings 6691022506 (2026-11-06T17:24Z, unit = App; (b) readable verdict; ② "always installed whole" recorded as goal, not fact) and 6691217245 (2026-11-06T17:33Z, every kernel object not customizable in step 1; the ensure door refuses a kernel base with the readable verdict, not 422; whitelist next version); the seat's claim amendments 6694004188 (2026-11-06T19:50Z) and 6694069747 (2026-11-06T19:53Z, the re-split: PR 2 = lookup threaded with appOf the identity + the kernel verdict, BREAKING banner, legacy pairs stay served; PR 3 = the appOf flip, legacy pairs, the App pair, the rehearsal; spec/ui/skills fenced); the order dispatch-29594-pr2.md (predates the re-split; the amendment governs) and FRAME.md; the dev's out/29594-pr2-scope-fork.md and out/29594-pr2-kernel-clone-collision.md (option A taken, "a new notice code", decision card open); the os-dev report 6698312513 (2026-11-06T23:20Z); PR 1 #31026 (merged 9ed2ee17) and its review record; PR #31027 (open, unmerged, Q10/Q11/Q12); the PR body at ee5587b4 (Clause-② yes (narrowing), Metadata-protocol: none, Refs #29594, two Ruling-ref lines, before/after table, ablations, gates). The head moved from 1340933c to ee5587b4 during this review (one docs-only commit, read in full). Merge-tree against today's origin/main 022b4e7e: clean.

① Lookup threading — behaviour unchanged

• The lookup is inert by construction. appOf(packageId, installed) is void installed; return packageId; (customization-pair-lookup.ts 103–106); pairOf and isPairOf only forward installed to it (113–127). So every pairOf(x, L) ≡ customizationPackageId(x) and every isPairOf(p, x, L) ≡ isCustomizationPairOf(p, x) for every lookup L, refusal reasons included (base_id_missing, base_is_customization_package, base_id_invalid all still come from the spec helper). Nit 4 of PR 1 holds: pairOf('x.custom', L) is still refused. The unit table pins exactly this for six shapes × two lookups (nothing installed; every row installed with the HotCRM module declaring its App), plus the refusal rows under both lookups (customization-pair-lookup.test.ts 61–129). TRUE.
• installedManifestsOf cannot throw on a lookup that answers nothing (customization-pair-lookup.ts 86–92: no registry / no getPackage → NOTHING_INSTALLED; a non-object manifest → undefined), pinned by the six it.each sources (test 76–87). installedManifestsOfEngine(engine) is the same over engine?.registry (installed-manifests.ts 19–22).
• Every site moved only its argument list. I read all 23 pairOf / isPairOf hunks and the isServedOverrideRowOf callers: discovery 409, environment-rows 121–147 and 295–304, lock-state 149–173, layered 403–417 (sort ranks unchanged), list reads 86 / 200 / 274 / 363 / 534 / 569 / 678 / 894, overlay-merge 96–99 and 327–340, package-bindings 273–282, packaged-base-refusal 165–176 / 195–235 / 430 / 690–700 / 1099–1100 / 1290–1292, packageless-migration 381–397 / 461 / 478 / 616 / 679 / 801, registry-hydration 527, served-overrides 97–118, write-gates 641–659, served-override 88–96, stored-flow-slot 89–97, class-head 186–192, diff-delete-load 428–431 / 1167–1171. Branches, status codes, sentences and sort order are byte-identical around each call. TRUE.
• The type seam is sound. ServedOverlayAddress (overlay-merge 114–146) and mergePackageAwareOverlay's options (282–299) are discriminated unions: servedOverride without installed does not compile, so no serving read can lose its pair silently; the two callers that pass { packageId } alone (overlay-merge 167, the view-container package order) passed no servedOverride on main either. OverrideWriteClosure.installed is required (packaged-base-refusal 846–852), so the compiler names every caller — which is why cli and cloud-connection are in the diff.
• Sites whose answer could move — each checked, none moves. cli offline (override-declarations.ts 114–116): the lookup is byId.get(id)?.manifest over the artifact's own walked manifests, no registry, so an offline validate reads the same artifact it already read. cloud-connection install-local (marketplace-install-local-plugin.ts 3823–3829): delivered manifest first, else installedManifestsOf(registry); the registry was already read for dependenciesOf on main. objectql plugin (plugin.ts 3842–3851): installedManifestsOf(this.ql.registry), the registry it already held; built once per call, not per row. Flow precedence (flow-precedence.ts 143–151, 184–191, 261–263, 345–348, 392): the lookup is a fourth required parameter; undeclaredRemedy's sentence is unchanged. Served-override row readers: all 17 non-test callers pass installedManifestsOfEngine(host.engine) or the registry they hold. Write gate (overrideWriteVerdict 1290–1292; judgeOverrideWrite 1099–1100): same pairOf / isPairOf pair as before. Runtime customizeInPairRemedy (packages.ts 676–681) and readPackageCustomizations (3992–3993) — the two deferred PR 1 sites — now go through pairOf; identity, so the remedy sentence and the extensions read are unchanged. Lint 108: isCustomizationPackage(manifest.id) replaces the base_is_customization_package parse — the one edge the body names (a.custom.custom, bare .custom) is a base_id_invalid input that the old parse also did not skip-by-reason, so the advisory's outcome on real manifests is the same.
• Registries newly held; ordering and boot. No site holds a registry it could not reach before. The protocol facets gain engine on their host Picks and protocol.ts hands it over as a lazy getter (get engine() { return readEngine(); }, six sites 3827–7263): read at call time, never at construction, so no boot-order change. The one genuinely new service read is service-automation/plugin.ts 594–600 objectqlRegistryOf(ctx): ctx.getService('objectql') inside try { } catch { return undefined; }, called at the boot pull (5245) beside the loader set. An absent or not-yet-registered objectql answers "nothing installed" → identity → the same precedence. It introduces no await and no dependency ordering, only an optional read, the same shape as the plugin's flowHistoryReader read. service-datasource (plugin.ts 223–229) refactors its existing safeGetService('objectql') read into objectqlRegistry(); no new read. registry.ts 7337 passes installedManifestsOf(this). So: no new boot read, no ordering change, no registry a caller did not already own. TRUE.

② The kernel verdict

• What "kernel base" is. kernelPackageScopeOf(row) (protocol-customization-package.ts 162–165) = the installed manifest's scope ∈ READ_ONLY_PACKAGE_SCOPES = ['system', 'cloud'] (package-writability.ts 38). It is a manifest-scope test, not a namespace test: sys is not read, and a project-scoped package of namespace sys would not be kernel. Exported as kernelPackageScope(engine, id) (170–174) for the clone doors. Every scope: 'system' declaration under packages/** non-test (35 sites) is a platform-delivered package: the plugins (plugin-auth, plugin-security, organizations, …), the services, platform-objects, the platform apps (apps/account, apps/setup, apps/studio), the UI contributions of cloud-connection / mcp. HotCRM declares no scope (its five manifests), so it is not kernel.
• Misclassification. The manifest schema admits scope: 'system' | 'cloud' on any manifest (manifest.zod.ts 636, default project), and no install path stamps, strips or refuses it (grepped registry.ts, marketplace-install-local-plugin.ts, runtime packages.ts: the scope is read as posture, never written). So a vendor App that mis-declares scope: 'system' would be read as kernel and get no pair. That is a pre-existing meaning of the scope — isWritablePackage 80 and isDisableableAppModule (packages.ts 759) already treat it as "the platform's", and the dev's own fixtures had modelled "an installed app" as scope: 'system' and were moved to code (packages-ensure-customization.test.ts 63–69, automation-flow-clone-custom-package.test.ts 68–73). The predicate is the right one for this version; the vendor's remedy (drop the scope) belongs in the changeset's "who moves" (nit 4).
• 409 RESOURCE_CONFLICT. A standard ledger member (error-code-ledger.zod.ts 2001 shadows: 'RESOURCE_CONFLICT'; error-code-ledger.test.ts 71), already the door's code for a writable base, no namespace, a bad pair namespace, a non-SemVer version and a malformed existing pair (customizationPairEnsureRefusal 363–406; expectRefusal(r, 409, 'RESOURCE_CONFLICT', …) on each in the runtime test). No new ledger row, no packages/spec edit (the file list carries none). The message (353–358): "Package '' is a kernel package (scope ''): kernel objects are not customizable in this version, so '' has no paired customization package and '.custom' is not ensured. A pair an earlier version created stays installed, and the overrides in it stay served (ADR-0146 D3)." Readable, names the base, the scope and the pair id, says "in this version" and nothing about which objects may open later — neutral about the whitelist. TRUE. check:error-status-conformance exit 0 in the dev's gate list.
• Nothing is created. The verdict is the second judgement in customizationPairEnsureRefusal (after the 404 for an uninstalled base, 341–359) and ensurePairOnce throws whatever that function answers before reading the version or calling installPackage (416–448). ensureCustomizationPackage itself only parses, derives the pair id and takes the in-flight slot before ensurePairOnce (280–330); nothing is written on the refused path. The leavesNothing harness pins it for system and cloud plus getPackage('<id>.custom') === undefined (runtime test 254–266).
• Legacy kernel pairs. The door's existing branch is below the kernel check, so a legacy <kernel>.custom is neither adopted nor rewritten: the refusal says it stays (354–357) and the pin compares the registry row before/after (structuredClone, runtime test 268–280) and reads it 200. Served: the objectql pin installs the pair under a scope: 'system' base, saves a declared override, gets 409 on ensure, then reads the override on the by-name, package-scoped, layered and list reads (protocol-custom-override-effective-read.test.ts 475–493). Writable: the write gate is judgeOverrideWrite over pairOf / isPairOf — identity, no ensure-door read anywhere in protocol-packaged-base-refusal.ts 1060–1110 — and the same pin lands a second save into the pair (494–496). TRUE.
• The two closes. overlayPairFixOf (packaged-base-refusal 427–445) answers null when customizationPairEnsureRefusal answers a refusal, and the package-less close and the named-base close then leave the save open — the existing family for every base the door refuses (the docblock at 336–347 says so). For a kernel item that means: package-less save onto a kernel-shipped overlay-type item, 403 NOT_OVERRIDABLE naming the pair on main → admitted now; a save naming the kernel package → admitted (effective-read test 498–515, with an App control that still gets 403). This is a widening, and it is in the body's table but not in the Clause-② line (should-fix 1). Its governing text is PR docs(adr): ADR-0146 D3 — one .custom pair per App, and one platform pair for the kernel suite #31027's Q10 ("its package-less write stays open until the kernel whitelist admits the item into the platform pair", decided where the rulings were silent), which is unmerged; ruling 6691217245 itself says every kernel object is served as not customizable and says nothing about reopening the package-less write D11 closed. Contract question for the seat (should-fix 2), not a code defect: the code follows the ensure-door family as designed.
• Narrowing declaration. Clause-② yes (narrowing) at line start in both carriers, one each; Metadata-protocol: none (right: no authorable key, value or meaning moves; the ensure response schema is untouched). Changeset: patch on the nine packages whose dist changes; **BREAKING** for a caller that ensures the customization pair of a kernel package … and for a TypeScript importer of the pair helpers; who moves and the one-line remedy ("drops that call …; passes installedManifestsOf(engine.registry), or installedManifestsOf(undefined)") present; adr-0087: not-required comment reasoned. The ! title + patch bumps pass check-changeset-no-major (exit 0 in the gate list) and Check Changeset is green on both heads. The Clause-② line names the ensure door, the clone landing and the retyped helpers; it omits the reopened closes (widening) and the flow clone's new 409 (a second narrowing row in the table) — one sentence (should-fix 1).
• Flow clone of a kernel-shipped flow. resolveCloneTarget (automation.ts 2608–2618) relays the ensure door's thrown 409 through deps.errorFromThrown, and registerAndSaveFlow 2463–2474 calls restoreFlowRegistration on a refused landing, so the engine registration made before land() is undone and nothing is created. Correct, and in the table; no pin covers that row (should-fix 4).

③ The clone collision (option A)

• Is the "new notice code" a published spec key? No. PERMISSION_SET_CLONE_NOTICE_CODES lives in packages/runtime/src/domains/permission-set-clone.ts 186–191 and nowhere under packages/spec/** on main or on the head (git grep of all four codes: runtime, dogfood, the Console's reader ui/packages/app-shell/src/views/metadata-admin/permission-set-clone.ts 90–94 and two UI tests, CHANGELOGs). The clone response's noticeCode is an untyped string the Console switches on, with a documented fallback to the served notice for an unknown code (the UI test at StudioDesignSurface.accessNewSimilar-28573.test.tsx 360 pins PERMISSION_SET_CLONE_SOMEWHERE_NEWER → sentence as sent). So the new value PERMISSION_SET_CLONE_ENVIRONMENT_WIDE_KERNEL_SOURCE is a new runtime value on an existing untyped field, not a new ledger row and not a packages/spec edit; no spec fence is crossed. It is nonetheless a new value a client may switch on — the body declares it in the Clause-② line, the changeset and now permission-sets.mdx 456–460, and the dev's out-of-scope note hands the zh sentence to the ui lane. Flagged here as the seat asked; nothing to stop the PR.
• Is landing environment-wide safe? The copy takes a new machine name: taken || target.name === source.name → PERMISSION_SET_CLONE_NAME_TAKEN_STATUS after a catalog resolve of the target name (permission-set-clone.ts 497–525), and the save is create-only, with METADATA_CONFLICT re-answered as name-taken (585–595). permission_set is not an overridable type (served-override.test.ts 66: isServedOverrideRowOf is false for it), so an environment-wide row cannot be read as an override of anything, and a same-name shadow is refused by the name check. The grants are the source's, judged as inherited (inheritedGrantObjects, 576–583), unchanged from the environment-authored landing. What changes for the operator is only where the copy lives (no package, so it does not travel with one) — the notice says so and names package as the way to keep it in a package (210–215). The kernel item itself is untouched. A named package still goes through newSimilarTargetRefusal (544–550). No shadow, no override, nothing unintended.
• Option B instead. resolveDefaultCloneLanding 319–323 is the whole switch: replace the return { packageId: null, created: false, kernelSource } with a thrown refusal (409, naming package=<a writable package of yours>), drop kernelSource from PermissionSetCloneLanding (168–172), the fourth code and its sentence (186–215), the unit pin (permission-set-clone.test.ts 247–261) and the four-code table rows (369–375 → three), re-point the dogfood pin (permission-set-clone-door.dogfood.test.ts 231–248) to the refusal, and revert the permission-sets.mdx sentence. About 60 lines across four files plus the docs line; the kernel verdict and the lookup threading are untouched. Option C would reopen the ensure door for a clone source, against the ruling, and would be a larger change in the door. The maintainer's card is open; A is implemented and reversible.

④ Tests, ablations, dogfood, gates (the dev's readings; Local-runs: none)

• Lookup: the identity pinned under two lookups × six shapes + refusals (metadata-core 962 green). Kernel verdict: system and cloud 409 with nothing created, legacy pair unchanged and readable (runtime 8851 green); legacy override served on four reads and a further save lands; the two closes reopen for a kernel item with an App control (objectql 11211 green). Clone: unit pin (no ensure, packageId absent on the save, the code and the sentence), the four-code distinctness table, the dogfood pin re-pointed (package: null, the code, GET /packages/<kernel>.custom 404). Adapted suites: 22489 metadata-protocol, 8288 lint, 1279 datasource, 3431 automation, 931 cloud-connection, 7415 cli — all pass with the lookup passed; no test skipped, quarantined or deleted.
• Ablations (server-lane negative-pin rule): kernel check disabled (dist preflight confirmed) → 3 runtime + 2 objectql pins red; clone landing disabled → its unit pin red; both restored, blob == HEAD, tree clean. The lookup threading has no ablation by design (nothing to red; the table pins both lookups equal). Honest shape.
• Dogfood battery on 021a8a3d (the two later commits are test warm-imports and docs): first run 1 failed — the very pin that found the collision — final run exit 0, 428 files, 3562 tests. The body says so and names the commit.
• Gates: dispatch-gates --commands 75 families, --ran 75/75, 0 NOT-MEASURED; three first-pass non-zeros fixed and re-run to 0 (check-plugin-teardown-shape --self-test after fetching the pinned fixture commit; check:dual-build-cjs-loads after a full build; check:test-source-alias with the four warm imports that are the 1340933c commit). eslint --no-inline-config exit 0 on every changed .ts.

⑤ Commits and body

Seven commits over the base 3fe5f2a0: 98e6c224, cca74048, 6c336bab, a5372388, 021a8a3d, 1340933c, ee5587b4. Each trailer is Co-Authored-By: Claude <noreply@anthropic.com> + Claude-Session: …session_01L9qibzCo6pa7SSUFmosQD8; no model name, no Fixes, no bare login. Body: Refs #29594, Ruling-ref: 6691022506, Ruling-ref: 6691217245, Clause-② and Metadata-protocol lines at line start, the 维护者速读 six lines consistent with the diff (the 风险与回滚 line states the reopened closes and the clone landing plainly). The verification table still names head 1340933c2 (should-fix 5).

⑥ Check-runs

On 1340933c (superseded): the push of ee5587b4 cancelled the run; the three failure aggregates (Lint & Repo Gates, Test UI, TypeScript Type Check) carry annotations that read "lane … concluded cancelled -- expected success" — cancellation, no red leg. 23 success before the cancel, among them Check Changeset, Dogfood Regression Gate, PR-body guards, Governed Surface Queue Guard, Lint · ESLint, Lint · PM dispatch-gates, Type Check · source gates, Plan Test Core shards.
On ee5587b4, read at 2026-11-06T23:25Z: 41 check-runs, 19 completed/success (Check Changeset, Check Documentation Links, Dogfood Regression Gate, Flag docs affected by code changes, Governed Surface Queue Guard, PR-body guards, Check PR Size, Lint · PM dispatch-gates, Lint · scoped · tooling self-tests, Spec property liveness, Auto Label, filter …), 7 skipped, 15 in_progress (Build Core, Build Docs, Build UI Deps, the four Lint · legs, Type Check · workspace / debt ledger / consumer gates / source gates, Plan Test Core shards, Live E2E UI), 0 failed. Test Core 1–8 not yet started. Landing condition: every check completed, 0 failed, re-read from the API; check:dual-build-cjs-loads runs inside Build Core.

⑦ Docs (the moved head)

content/docs/api/metadata-api.mdx 113–116: "a kernel package (scope system or cloud) has no pair in this version and answers 409 RESOURCE_CONFLICT, though a pair an earlier version created keeps serving what it holds" — matches customizationPairEnsureRefusal 350–358 and the legacy-pair pins. content/docs/permissions/permission-sets.mdx 456–460: "A copy of a set the platform itself ships (a kernel package of scope system or cloud, such as member_default) is saved environment-wide, in no package … (noticeCode PERMISSION_SET_CLONE_ENVIRONMENT_WIDE_KERNEL_SOURCE)" — matches resolveDefaultCloneLanding 319–323 and permissionSetCloneNotice 210–215; the surrounding "<X>.custom … created on the first copy" paragraph now reads as the non-kernel case, which it is. Two pages are left stale (should-fix 3). Check Documentation Links and Flag docs affected by code changes are green on the head.

Findings:

must-fix: none.

should-fix:

1. Declaration (PR body line 4, changeset line 15). The Clause-② line names the narrowing arms and the retyped helpers but not the widening the diff also makes: a package-less save, or a save naming the kernel package, onto a kernel-shipped overlay-type item moves from 403 NOT_OVERRIDABLE to admitted (effective-read test 498–515; table rows 5–6), and five new re-exported names widen the public faces (installedManifestsOf, InstalledManifestLookup, AppLookupManifest, InstalledPackageSource on @objectstack/metadata-core; kernelPackageScope on @objectstack/metadata-protocol), plus the flow clone's 200 → 409 row. The spelling stays yes (narrowing) (the order: the narrowing governs); the line should say "both arms" and name the widening in one clause. One sentence in each carrier; delta review by this reviewer.
2. Governing text for the reopened closes (seat decision, not code). The reopening rests on PR docs(adr): ADR-0146 D3 — one .custom pair per App, and one platform pair for the kernel suite #31027 Q10, unmerged and marked "decided where the rulings were silent"; ruling 6691217245 says every kernel object is served as not customizable and is silent on the package-less write D11 closed. The seat records one of: (a) PR 2 lands on the Q10 reading and the record names docs(adr): ADR-0146 D3 — one .custom pair per App, and one platform pair for the kernel suite #31027 as its governing text (the body already makes PR 3 wait for docs(adr): ADR-0146 D3 — one .custom pair per App, and one platform pair for the kernel suite #31027); or (b) the two closes refuse a kernel item without naming a pair until the whitelist version, which is a small change in packagelessOverlayWriteRefusal / namedBaseCloseSubject reading kernelPackageScopeOf. I read (a) as consistent with the door family and with Q10 at CR PASS; it needs the seat's sentence.
3. Docs left stale (content/docs/** is in the file surface): content/docs/concepts/metadata-lifecycle.mdx 185 says a package-less write onto a ✅-type item one installed read-only package ships is refused naming the pair — not for a kernel item now; 216 says a flow copy lands in <base>.custom "created on first use" — a kernel-shipped flow now answers the ensure door's 409. One clause each, the shape of the two edits already made in ee5587b4.
4. Pin the flow row. The table's "clone a kernel-shipped flow, no package → 409" has no test: automation-flow-clone-custom-package.test.ts moved its base off scope: 'system' and adds no kernel case, and the ablation reds the ensure door only. One case asserting 409, the relayed sentence and that the engine's flow map holds no copy (restoreFlowRegistration, automation.ts 2463–2474).
5. Body head. The verification table names 1340933c2; the head is ee5587b4 (docs-only; the suites and the battery were run on 021a8a3d / 1340933c). One line saying so.

nits:

1. kernelPackageScope (protocol-customization-package.ts 170–174) reads registry.getPackage through its own Partial<PairRegistry> cast beside installedManifestsOfEngine; the same read spelled twice. Could be kernelPackageScopeOf({ manifest: installedManifestsOfEngine(engine)(packageId) }).
2. appOf's void installed; is the right pin for PR 2, but the "every row installed" half of the unit table proves only that the lookup is ignored; the docblock at customization-pair-lookup.ts 26–34 says so, which is enough — worth one line in the test's docblock so PR 3's reviewer expects the module row to flip.
3. service-automation/plugin.ts 594–600 swallows every error from getService, not only "not registered"; the sibling reads do the same and the docblock says so. Consistent; leave.
4. Changeset "who moves": add that a vendor package which declares scope: 'system' or 'cloud' in its own manifest is read as kernel by this predicate (as it already is by isWritablePackage); the remedy is to drop the scope. And "always installed whole" (changeset line 19) is the goal ruling 6691022506 ② recorded, not today's behaviour (serve mounts by tier preset); "ships with the runtime at the runtime's version" is the fact.
5. The lint hunk's docblock (validate-customization-namespace.ts 36–38) is right; the body's "Edge" sentence overstates it — the old parse never skipped a.custom.custom either (it is base_id_invalid, not base_is_customization_package), so no answer moves.

Implemented-by: claude/project-thread-kwumcu
Reviewed-by: session_01L9qibyvxbrLP4jm4PargoH

VERDICT: PASS — landing waits on: every check on ee5587b4 completed with 0 failed (re-read from the API); the maintainer's answer on the clone decision card (A implemented; B is a ~60-line reversal in four files + one docs line); the seat's sentence on should-fix 2 (the Q10 reading, or a shut close for kernel items until #31027 merges); the two carrier lines of should-fix 1 and the body head line of should-fix 5, delta-reviewed by this reviewer. Should-fix 3 and 4 may ride the same delta or a follow-up the seat names.

[objectstack-fleet]

domain:server#2 · os-tesla · session_01L9qibyvxbrLP4jm4PargoH

Contract review · delta, round 1

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: b94d1ac68d151d99ad908992ad25f65bf2413a6d
Local-runs: none
Scope: the delta only — b94d1ac6 diffed against the merge-tree of ee5587b4 + origin/main 022b4e7e (tree a7aa8b0f), so main's side of the merge commit 20c8cd6e is excluded; git diff a7aa8b0f 20c8cd6e is empty, so the merge commit carries nothing of its own. Eight files, +153 / −35: packages/metadata-protocol/src/protocol-customization-package.ts (the judgeKernel option, kernelPackageScope through the lookup, the docblock), protocol-packaged-base-refusal.ts (kernelOverlayWriteRefusal, OverlayWriteClose, OverlayPairFix.kernelScope, both closes), protocol-packageless-overlay-migration.ts (packagelessCloseSubject carries the scope), packages/objectql/src/protocol-custom-override-effective-read.test.ts (the re-pin), packages/runtime/src/domains/automation-flow-clone-custom-package.test.ts (the kernel flow-clone pins), packages/runtime/src/domains/packages-ensure-customization.test.ts (one comment), .changeset/29594-pair-lookup-installed-kernel-verdict.md, content/docs/concepts/metadata-lifecycle.mdx. Read beside it on the head: protocol-diff-delete-load.ts 505–535 (the package-less delete close), protocol-packaged-base-refusal.ts 264–330 (the package-less refusal as it now stands), the close callers (protocol-save.ts 520, protocol-history-and-publish.ts 354, protocol-package-commits.ts 1848, protocol-diff-delete-load.ts 523), packages/metadata-protocol/src/index.ts 275, packages/spec/src/kernel/customization-package.ts 94–123 (the nit 5 dispute), package.json 65 (check:overlay-whitelist-table), the body delta /mnt/project-files/server-seat-2/r2026-11-06/out/31060-body-delta.md, the live PR body (still at the ee5587b4 text; the delta is the seat's to apply), the check-runs on b94d1ac6. The three new commits 3ddfa1c7, 38ddd867, b94d1ac6 carry the Co-Authored-By: Claude + Claude-Session trailers, no model name, no Fixes, no bare login.

① Should-fix 2, the seat's option (b): both D11 closes stay 403 on a kernel item, naming no pair

• Mechanism. customizationPairEnsureRefusal gains options.judgeKernel (protocol-customization-package.ts 341–350, 362): false skips only the kernel verdict; the door itself passes nothing, so the ensure door's own answer is unchanged. overlayPairFixOf (protocol-packaged-base-refusal.ts 487–507) asks the door's other judgements with judgeKernel: false, then reads kernelPackageScope(host.engine, base) and marks the fix with kernelScope (installed pair or pending pair alike). packagelessCloseSubject (protocol-packageless-overlay-migration.ts 769–811) and namedBaseCloseSubject (653–675) carry it into the new OverlayWriteClose shape; packagelessOverlayWriteRefusal (264–272) and namedBaseOverlayWriteRefusal (391–399) branch first on kernelScope to kernelOverlayWriteRefusal (326–346), which answers closedOverlayWriteError — the same 403 NOT_OVERRIDABLE the non-kernel close answers — with "'view/x' ships in kernel package '' (scope ''): kernel objects are not customizable in this version, so <a write naming no package | a delete of its package-less row | a rollback … | a write naming ''> is refused (ADR-0146 D3, D11). ." No pair id, no ?package= address, no ceremony named. Every caller of the closes (save, publish, delete, rollback, commit revert) goes through these two functions, so all four operations of the package-less close and the three of the named-base close carry the kernel sentence.
• "Exactly where it was shut before." Because the other door judgements still run, a kernel base the door would refuse for a non-kernel reason (no namespace, a non-SemVer version, a malformed existing pair, a namespace another package owns) still answers null → the write stays open, as it did on main for that base. And overlayPairFixAdmits is still asked on the declared body (packagelessCloseSubject 810; namedBaseCloseSubject 673), so a body the override gate would refuse (an email_template member at a locale the base does not ship, fix(metadata-protocol)!: the override write gate judges an email template by its locale, so a pair's override of a locale the base does not ship is refused (#28746) #28777) stays open too, as on main. So the set of closed kernel writes is the set main closed; only the sentence moves. That is what the seat ruled. It also means the ruling's "every kernel object not customizable" is not enforced on a kernel package that declares no namespace or no SemVer version — the same gap main has, and not this PR's to widen (observation, nit 1).
• Pins. protocol-custom-override-effective-read.test.ts 500–523: the App control still gets 403 naming the pair on both addresses; the kernel item gets 403 NOT_OVERRIDABLE on both, the message contains the kernel sentence and not.toContain(PAIR), and rowsOf(VIEW) is [] after both attempts. The legacy-pair case (475–497) is unchanged: the override in a pre-existing kernel pair is still served on four reads and a further save into the pair still lands (the write gate never asks the closes). Ablation (dev's reading): judgeKernel: false removed, metadata-protocol dist rebuilt and checked → the re-pinned case red (the save was admitted); restored, tree clean.
• Table rows 5–6 and the changeset. The body delta's rows 5–6 now read 403 NOT_OVERRIDABLE → 403 NOT_OVERRIDABLE, the sentence names no pair; the changeset bullet "The closes stay shut on a kernel item" (line 25) says the same. With (b) there is no widening of the accept set left in the diff: the Clause-② arms are the two narrowings (ensure door, flow clone) and the public-face widening (five exports, one noticeCode value). Consistent.

② Should-fix 1: the Clause-② line

Changeset line 15 now reads Clause-②: yes (narrowing) — both arms. Narrowing: …ensure door 409…; …clone of a flow a kernel package ships … 409 where it answered 200…; the retyped helpers… Widening: five new exports, installedManifestsOf, InstalledManifestLookup, AppLookupManifest and InstalledPackageSource (@objectstack/metadata-core) and kernelPackageScope (@objectstack/metadata-protocol), and one new noticeCode value … PERMISSION_SET_CLONE_ENVIRONMENT_WIDE_KERNEL_SOURCE…. The body delta item 1 carries the same line, shorter. Both name both arms; the spelling stays yes (narrowing); Metadata-protocol: none stays. Met. One accuracy note: judgeKernel is a new optional parameter on customizationPairEnsureRefusal, which is not on the package index (index.ts 275 exports only customizationPairManifestRefusal and kernelPackageScope from that module), so it is not a public-face change; nothing to add.

③ Should-fix 3: the docs

content/docs/concepts/metadata-lifecycle.mdx 185: "for an item a kernel package (scope system or cloud) ships, the same write is refused with a sentence that names no pair, because kernel objects are not customizable in this version and a kernel package has no pair" — matches kernelOverlayWriteRefusal. 216 (flow row): "a kernel package … has no pair in this version, so a copy of a flow it ships answers the ensure door's 409 until the body names package" — matches resolveCloneTarget 2608–2618 and the new pin. 218 (permission row): "a copy of a set a kernel package ships lands environment-wide" — matches resolveDefaultCloneLanding 319–323. The docs edit adds the check:overlay-whitelist-table gate family (package.json 65), which the dev ran (102/102). Check Documentation Links and Flag docs affected by code changes are green on the head. Met.

④ Should-fix 4: the kernel flow-clone pin

automation-flow-clone-custom-package.test.ts 263–290: for system and cloud, a clone of the kernel-shipped source with no package answers 409 RESOURCE_CONFLICT whose body contains "Package 'com.acme.crm' is a kernel package (scope '')", the engine's flow map has no copy and is unchanged, no sys_metadata row for the copy, the pair is not installed, and the source stays active. The fixture gains baseScope (113–129) and the non-kernel cases keep the code base. Ablation (dev's reading): restoreFlowRegistration on a refused landing disabled → both cases red (the engine held the copy); restored. Met.

⑤ Nits 1 and 4

Nit 1: kernelPackageScope (protocol-customization-package.ts 176–179) now reads installedManifestsOfEngine(engine)(packageId); one spelling. Met. Nit 4: the changeset's "Who moves" (line 29) names a vendor package that declares scope: 'system' / 'cloud' as read as kernel, with the remedy; "installed whole" is replaced by "ships with the runtime, at the runtime's version (installing it whole is the goal ruling 6691022506 records, not yet what every serve tier does)" in the changeset (line 22), the docblock (156–158) and the runtime test comment (251). Met.

⑥ Nit 5, disputed — the dev is right; the nit is withdrawn

customizationPackageId (packages/spec/src/kernel/customization-package.ts 94–102) tests baseId.endsWith('.custom') before MANIFEST_ID_PATTERN, so a.custom.custom, bare .custom and A.custom all answer base_is_customization_package, and the old lint line (!pairId.ok && pairId.reason === 'base_is_customization_package') skipped them. isCustomizationPackage(id) is customizationBasePackageId(id) !== null (119–123), and customizationBasePackageId('a.custom.custom') strips the suffix to a.custom, derives customizationPackageId('a.custom') — refused base_is_customization_package — and answers null; .custom → base '' → base_id_missing → null; A.custom → A → base_id_invalid → null. So the new lint judges those three ids where the old one skipped them, exactly as the body's "Edge" sentence (body delta item 4) now says. My reading in the first record was wrong on the order of the two checks. The moved answer is an advisory on a malformed package id, declared in the body and the changeset (line 27); no finding.

⑦ The PR 3 item: a package-less row on a kernel item stored before D11

On main: such a row is served (D8 item 1), its package-less delete is closed by D11 naming the pair (protocol-diff-delete-load.ts 516–531, unchanged), and os migrate packageless-overlays could move it, because its step 1 ensured the kernel pair, which the door then created. On this head: the row is still served, the package-less delete is still closed (now with the kernel sentence, 326–346), and the ceremony's ensure step refuses the kernel base (the census still lists it movable, the apply fails it with the kernel sentence — the dev's PR 3 finding from round 0). So the delete close is pre-existing; what this PR adds is the ceremony refusal, which is the ruled kernel verdict applied at the ceremony's one creation path, not a defect of the closes. No served answer changes for the row; what is lost is an operator path that would have created a kernel pair, which ruling 6691217245 forbids in this version. #31027 Q10 already names this row ("stays as it is, served … until the kernel whitelist admits the item into the platform pair"). Judgment: not a regression; a state the ruling creates, whose disposition (a census label such as kernel_held, and the whitelist version's move into the platform pair) is PR 3's / the ceremony card's. The body delta's item 8 sentence should say which half is old and which is new (nit 2).

⑧ Body delta

Item 1 (Clause-②, both arms): matches the changeset's line in substance; the body form drops the retyped-helper list to "the exported pair helpers take the installed-manifest lookup as a required argument", which is the same claim. Item 2 (速读): the 风险与回滚 clause now says the two closes still refuse a kernel item 403 and no longer name the pair; 两分钟验证 likewise. Item 3 (rows 5–6): 403 → 403, no pair named. Item 4 (Edge): right, per ⑥. Item 5 ("Where."): matches overlayPairFixOf 493–507 and names the seat ruling. Item 6 (ablations): three ablations, each with its red pin named. Item 7 (verification): head b94d1ac6, the merge of 022b4e7e, the suites on the head for the six touched packages and on 1340933c for the three untouched (service-datasource, cloud-connection, cli — none of their files moved this round: TRUE by the delta's file list), dogfood on 021a8a3d (no dogfood pin moved: TRUE), 102/102 gates. Item 8 (PR 3 sentence): see ⑦. Item 9: 51 files = 48 + metadata-lifecycle.mdx + the two docs pages of ee5587b4: TRUE. The live PR body is still the ee5587b4 text (Clause-② line 4 without "both arms", rows 40–41 as "saved package-less", head 1340933c2 at line 67); the delta is applied by the seat through the relay and is a landing condition.

⑨ Check-runs on b94d1ac6

Read at 2026-11-07T00:33Z: 64 check-runs, 55 completed/success, 8 skipped, 1 in_progress (Test Core (4/8)), 0 failed, 0 cancelled. Green among them: Build Core (hosts check:dual-build-cjs-loads), Check Changeset, Check Documentation Links, Dogfood Regression Gate, Flag docs affected by code changes, Governed Surface Queue Guard, Lint & Repo Gates with every Lint · leg, PR-body guards, TypeScript Type Check with Type Check · workspace / debt ledger / consumer gates / source gates, Test Core 1–3 and 5–8, Test UI and all 16 shards, Build & E2E UI, Live E2E UI, Build Docs. GitHub reports mergeable: null / mergeable_state: unknown at read time (recomputing after origin/main moved to 23cf11a4, four commits past 022b4e7e); git merge-tree of b94d1ac6 against 23cf11a4 is clean. Landing condition: Test Core (4/8) completed success, re-read from the API; the seat applies the body delta.

Findings:

must-fix: none.

should-fix: none. The five should-fix items of the first record are met as read in ①–⑤; nit 5 is withdrawn (⑥).

nits:

1. With (b) the kernel close holds only where main held it: a kernel package that declares no namespace or a non-SemVer version, or a body the override gate refuses, still has its package-less write open (overlayPairFixOf answers null before reading kernelScope). That is main's set and the seat's ruling ("exactly where they were shut"); worth one sentence in the changeset's closes bullet so the whitelist card knows the gap is inherited, not new. Not a change for this PR.
2. Body delta item 8: say that the package-less delete close is D11's (pre-existing) and the ceremony's refusal is this PR's kernel verdict at the ceremony's ensure step, so PR 3 reads the item at its true size.
3. OverlayWriteClose and OverlayPairFix.kernelScope are new exported names of the module but not of the package index; nothing to declare. judgeKernel likewise.

Implemented-by: claude/project-thread-kwumcu
Reviewed-by: session_01L9qibyvxbrLP4jm4PargoH

VERDICT: PASS — landing waits on: Test Core (4/8) completing green on b94d1ac6 (0 failed re-read from the API); the seat applying the body delta through the relay (Clause-② both arms, rows 5–6, the 速读 clauses, the Edge sentence, the verification table at b94d1ac6); the maintainer's pending answer on the clone decision card (option A is what the head implements; B stays a ~60-line reversal in four files + two docs lines).

[objectstack-fleet]

domain:server#2 · os-tesla · session_01L9qibyvxbrLP4jm4PargoH

维护者速读

• 改了什么：所有「这个包的定制包是谁」的判断（23 处 pairOf / isPairOf 及其调用方）都带上已安装清单这个参数，appOf 仍原样返回，所以行为不变，PR 3 只需改一处就能把模块归到它的 App。ensure 门对内核包（scope system / cloud）答 409 RESOURCE_CONFLICT，提示「本版本内核对象不可定制」，什么都不建。
• 为什么改：卡片 Customization pairs: every system package shares namespace sys, so only the first can get a .custom pair (422 NAMESPACE_CONFLICT on the rest) #29594 第二步，按你的裁定 6691022506（定制单位 = App）与 6691217245（本版本内核对象一律不可定制，给可读的拒绝而不是 422）。
• 风险与回滚：旧版本建好的内核配对包继续安装、继续生效、继续可写。内核条目的无包写入仍按 D11 拒绝（403），只是不再点名配对包。克隆内核 flow 且未指定包时答 409；克隆内核权限集时副本存为环境级（你选的 A）。对导入配对包辅助函数的 TypeScript 调用方是 BREAKING（多一个必填参数），changeset 写明了谁要改、改一行。回滚＝撤销本 PR。
• 先看：packages/metadata-protocol/src/protocol-customization-package.ts（内核判定）与 protocol-packaged-base-refusal.ts（kernelOverlayWriteRefusal）。
• 两分钟验证：pnpm --filter @objectstack/runtime exec vitest run --project local src/domains/packages-ensure-customization.test.ts，内核 409、什么都不建、旧配对包不变。
• 需要你做的：无，席位落地。PR 3（appOf 翻转、App 配对包、HotCRM 演练）等本 PR 与 ADR 修订 docs(adr): ADR-0146 D3 — one .custom pair per App, and one platform pair for the kernel suite #31027 合并后开工。

席位意见：可以落地。

席位核对

ACCEPT · seat domain:server#2 · head b94d1ac6 · 2026-11-07T01:03Z

1. Shape: Refs #29594 (PR 2 of 3), draft, base main, 51 files, +984/−297 (1,281 changed lines; check-governed-merges --pr 31060: 0 of 51 paths governed, under the human-merge threshold). Clause-②: yes (narrowing) — both arms. The narrowing governs, and the changeset carries the BREAKING banner with who moves and the one-line remedy. Metadata-protocol: none. Ruling-ref: 6691022506, Ruling-ref: 6691217245. Claim amendments 6694004188 and 6694069747 (the re-split). No packages/spec, ui/ or skills/ edit.
2. Premise: measured in the PR. Every system package shares a namespace, so the ensure door either created a kernel pair or answered 422. It now answers the ruled readable verdict, and the lookup is threaded so PR 3 can resolve App membership in one place.
3. Review: CONTRACT_REVIEW_TIER review 6698634718 (PASS on ee5587b4, 0 must-fix) and delta 6699680357 (PASS on this head, 0 must-fix, 0 should-fix).
   • The seat ruled should-fix 2 as option (b): both D11 closes stay 403 on a kernel item and name no pair. Ruling 6691217245 serves every kernel object as not customizable, and docs(adr): ADR-0146 D3 — one .custom pair per App, and one platform pair for the kernel suite #31027 Q10 is unmerged, so this PR reopens no close.
   • The clone-landing question went to the maintainer as a decision card; option A was picked at 2026-11-07T01:01Z, which is what the head implements.
   • Nit 5 was withdrawn on the dev's measurement.
   • The new noticeCode value is a runtime value on an untyped field, not a spec key.
4. Gates / check-runs: on head b94d1ac6: 69 runs, 59 success, 10 skipped, 0 failed. Dev: metadata-protocol 22512, objectql 11360, runtime 8876, automation 3431, metadata-core 962, lint 8331 (all exit 0); typecheck and eslint exit 0; dispatch-gates --commands 102/102 exit 0, --ran 102/102. Dogfood battery on 021a8a3d: 428 files, 3562 tests (no dogfood pin moved since). Four ablations are red once each and were restored (kernel check, clone landing, the kernel close, restoreFlowRegistration).
5. Accepted deviations / follow-ups (PR 3):
   • A package-less row on a kernel item stored before D11 stays served but has no door left. It goes with the census question in docs(adr): ADR-0146 D3 — one .custom pair per App, and one platform pair for the kernel suite #31027.
   • The incomplete-declarations census parses pair→base.
   • The dogfood helper and the six ui/packages/app-shell sites derive <base>.custom client-side.
   • A list-row customizable flag needs a spec sub-card.
6. Landing: not governed. The seat readies the PR and arms auto-merge on the maintainer's word in the seat thread 「你应该使用 pm-dispatch 技能审核和落地pr」(2026-11-06T16:49Z). The card stays open for PR 3.