feat(plugin-auth, plugin-security): createIdentityObjectsPlugin() preset; SecurityPlugin refuses at boot a kernel without sys_user / sys_member

[objectstack-fleet]

Fixes #22074

Clause-②: yes (narrowing)

What changed

1. plugin-auth exports the identity-object registration as a plugin it composes itself. createIdentityObjectsPlugin() registers authIdentityManifest() (new, packages/plugins/plugin-auth/src/manifest.ts:147): the manifest header, authIdentityObjects and authObjectExtensions. AuthPlugin spreads the same builder into the one manifest it registers (auth-plugin.ts:656), so a reduced kernel and a full kernel register one list under one package id, and nothing is registered twice on a full kernel.
2. plugin-security declares what its authorization store reads and refuses at boot without it. security-plugin.ts:1088 declares sys_user and sys_member; a kernel:ready handler subscribed at the head of start() (:1654) asks the engine registry for both and throws AuthzIdentityObjectsMissingError naming the missing objects and the plugin that registers them. plugin-security registers neither object.

Public surface, for the at-tier contract review

• New exports on @objectstack/plugin-auth (through export * of the new module src/identity-objects-plugin.ts): createIdentityObjectsPlugin(options?), IdentityObjectsPlugin, IdentityObjectsPluginOptions (manifestDatasource, same meaning as on AuthPluginOptions), IDENTITY_OBJECTS_PLUGIN_NAME (com.objectstack.auth.identity-objects). authIdentityManifest lives in manifest.ts, which the package index does not export.
• The boot refusal, and whom it newly refuses. A kernel where SecurityPlugin.start() ran and the engine registry does not hold sys_user or sys_member at kernel:ready: bootstrap() now rejects. Before, it booted and every authenticated permission read failed with AuthzStoreUnavailableError (SERVICE_UNAVAILABLE, 503). Newly refused, measured: the three in-repo harnesses listed under Cross-lane files. Newly refused, by code reading only (not run): DevPlugin with services: { auth: false } and security left on, because DevPlugin.start() hands the real context to SecurityPlugin.start().
• Not refused. Any kernel mounting AuthPlugin (os serve pairs the two; @objectstack/verify's bootStack mounts AuthPlugin); a kernel registering the two objects any other way (the gate asks the registry, not who registered); a declarations-only boot (os migrate composes host plugins with start() suppressed). The last is measured: packages/cli/src/utils/schema-migrate.host-composition.integration.test.ts, which composes SecurityPlugin without AuthPlugin, stays green on this tree.
• A second, smaller refusal. IdentityObjectsPlugin.init() refuses a kernel that also mounts AuthPlugin (both register the same objects under one package id, and, read from the registry code rather than run, the later registration replaces the package record). optionalDependencies: ['com.objectstack.auth'] orders AuthPlugin ahead, so its auth service is registered when init() asks.

Measure first: @objectstack/verify

Measured, read only: bootStack in packages/verify/src/harness.ts mounts AuthPlugin unconditionally (kernel.use(new AuthPlugin(...)), around :569), so its in-process handle already registers the identity objects. It is the sanctioned kit for an app suite; the new module's header says so. The export lands for kits that compose their own kernel (hotcrm's nine harnesses are that shape). packages/verify is not edited.

Mechanism hypotheses

• H1, confirmed. authIdentityObjects in manifest.ts is the single list, registered through the manifest service under AUTH_PLUGIN_ID. Both paths now read it through authIdentityManifest(). Pinned: AuthPlugin.init() registers exactly one manifest whose objects is the same array (toBe) and whose identity half equals authIdentityManifest(), pages and dashboards still present; a real AuthPlugin + SecurityPlugin kernel registers plugin-auth's list once under com.objectstack.plugin-auth.
• H2, measured: sys_user and sys_member, not sys_member alone. resolveUserAuthzGrants (packages/core/src/security/resolve-authz-context.ts:757, :794, :796) reads sys_user (whenever the caller seeded no email, no ai_seat, or a platform-admin list is configured) and sys_member, plus five objects plugin-security registers itself (sys_user_position, sys_user_permission_set, sys_position, sys_position_permission_set, sys_permission_set). plugin-security's own boot passes also read sys_account and sys_organization, but through local read helpers that degrade with a warn; they are not the authz store and are not declared. Ablation reading below: with the gate removed, the boot passes and the first resolveUserAuthzGrants call fails with AuthzStoreUnavailableError, code SERVICE_UNAVAILABLE, status 503, object sys_member.
• H3, measured: no kernel mechanism declares objects. dependencies / optionalDependencies / requiresServices name plugins and services (packages/core/src/plugin-order.ts). The existing mechanism used is the kernel's documented boot-gate moment: a kernel:ready handler that throws fails bootstrap() on both kernels (packages/core/src/kernel-base.ts, lite-kernel.ts). The check stays inside plugin-security. It is subscribed in start(), not init(): os migrate composes host plugins for init() only and fires kernel:ready anyway, so an init() subscription would refuse a schema command that never reads the store.
• H4, measured: three harnesses outside the two packages. Candidates: every test file outside plugin-auth / plugin-security that imports @objectstack/plugin-security without going through bootStack or AuthPlugin (runtime 7 files, service-automation 2, rest 9, organizations 1, cli 3, dogfood 1, plugin-dev's whole suite), run against the built change. Red: packages/runtime/src/standalone-stack-seeder-declaration-copy.test.ts (1 file), packages/services/service-automation/src/builtin/write-nodes-stored-metadata-family-refusal.integration.test.ts (1 case) and .../runas-system-stamping.integration.test.ts (2 cases), all with AuthzIdentityObjectsMissingError. Inside plugin-security, three test files whose engine doubles fire every kernel:ready handler (14 cases) now answer the two names from getSchema.
• H5, decided: package id com.objectstack.plugin-auth, kernel plugin name com.objectstack.auth.identity-objects, provenance @objectstack/plugin-auth. The registry records one owning package per object and refuses a second package claiming it (ADR-0029 D3, ObjectOwnershipConflictError), so the manifest id decides the objects' provenance; a different id would make sys_user's owner depend on which plugin a kernel mounts. The kernel plugin name differs from AuthPlugin's only because the kernel keys plugins by name. The export ships from plugin-auth, the package that owns the list, rather than as a copy built from @objectstack/platform-objects/identity imports.

Cross-lane files (outside plugin-auth / plugin-security), for the seat to declare

• packages/runtime/src/standalone-stack-seeder-declaration-copy.test.ts: mounts createIdentityObjectsPlugin() before SecurityPlugin (runtime already depends on plugin-auth).
• packages/services/service-automation/src/builtin/write-nodes-stored-metadata-family-refusal.integration.test.ts and packages/services/service-automation/src/runas-system-stamping.integration.test.ts: the same mount.
• packages/services/service-automation/package.json: @objectstack/plugin-auth as a devDependency (no workspace cycle: plugin-auth's closure does not contain service-automation), with pnpm-lock.yaml (+3 lines).
• packages/services/service-automation/vitest.config.ts: an anchored alias of @objectstack/plugin-auth to source, because check:test-source-alias refuses a new unaliased artifact import (its ledger is shrink-only).

Tests (HEAD 90bb6549a8)

• packages/plugins/plugin-security/src/authz-identity-objects-boot-refusal.test.ts (3 cases, real kernel, ObjectQL, SQLite): refused with both names; only the missing name; boots when the registry holds both, registered by a test package.
• packages/plugins/plugin-auth/src/identity-objects-plugin.test.ts (9 cases): the card's four pins, plus a control (without the preset the sys_user insert is refused OBJECT_NOT_FOUND / 404), the datasource override on both paths, the ordering edge, and the co-mount refusal. The app in pin 1 registers its manifest through the manifest service, as AppPlugin.init() does; AppPlugin itself lives in @objectstack/runtime, which depends on plugin-auth, so this suite cannot import it without a workspace cycle.
• Full suites, at 1a507892 (the one later commit, 90bb6549a8, only re-spells IdentityObjectsPlugin.optionalDependencies as a literal; its pin file was re-run there, 9 passed): plugin-security 173 files, 3666 passed, 45 skipped; plugin-auth 127 files, 2633 passed, 10 skipped; service-automation 175 files, 2120 passed. Runtime: the edited file, 13 passed.
• Typecheck: pnpm --filter typecheck for plugin-auth, plugin-security, service-automation and runtime, all exit 0 (test layers OK, debt ledgers unchanged).

Ablation of the boot-refusal pin

Committed first; node scripts/ablation-replace.mjs replaced the one kernel:ready subscription line in security-plugin.ts (anchor x1 to x0, marker x0 to x1, blob b90b3e0f to e8696819). The suites resolve plugin-security from source (relative import, and plugin-auth's vitest alias), so no build sat between edit and run. Mutated: the boot-refusal file went red 2 of 3 (the "boots when both are registered" case stays green, as it should), and plugin-auth's pin 3 went red 1 of 9. The ablated boot passed and the first permission read answered AuthzStoreUnavailableError / SERVICE_UNAVAILABLE / 503 / sys_member (a scratch probe, deleted after). Restore: blob back to b90b3e0f, equal to HEAD, git diff HEAD empty.

Gates (HEAD 90bb6549a8)

node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack derived 80 commands; all 80 ran and exited 0, reconciled with --ran (80 derived, 80 run, 0 NOT MEASURED, every line carrying its exit code). Run in addition because the diff touches plugin lifecycle code: check:startup-registry-verdict, check:init-service-contract (it caught an optionalDependencies spelled through a constant, now a literal), check:durability-log-level, all exit 0. The derivation names no check:api-surface family for these packages (that gate covers packages/spec); check:dts-closure and check:published-files are green. ESLint on the 14 changed TypeScript files: 0 errors, 0 warnings (population from eslint.config.mjs, which enables no type-aware linting, so untouched files' verdicts cannot move).

Notes

• The branch sits on 033e5c53; origin/main has since gained four commits, none touching a file in this diff. Not merged here; CI's merge ref carries the joint check.
• No packages/spec, packages/platform-objects or packages/verify edit.

Acceptance notes

• A test kit loads createIdentityObjectsPlugin() through plugin-auth's root entry, which also evaluates better-auth. A light subpath entry would need a package.json exports and tsup entry edit, outside this card's fence. Carrier: none.
• DevPlugin with services: { auth: false } and security on is now refused at boot (by code reading). DevPlugin could mount createIdentityObjectsPlugin() itself in that branch; that is a plugin-dev change, outside this card. Carrier: none.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 3 package(s): @objectstack/plugin-auth, @objectstack/plugin-security, @objectstack/service-automation, touching 17 documentable anchor(s). ⚠️ 2 changed file(s) yielded no anchor (packages/plugins/plugin-auth/src/index.ts, packages/services/service-automation/vitest.config.ts), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

18 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 959c209d56a8b9ab6f7e561e87700721194e4678.

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

What this run could not see

• 2 changed file(s) yielded no anchor (packages/plugins/plugin-auth/src/index.ts, packages/services/service-automation/vitest.config.ts) — pages documenting those are invisible to this run
• 1 anchor(s) matched too much of the corpus to be a work list: sys_user (literal, 38 pages)
• 4 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 54 of 206 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 97 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 25 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 959c209d56a8b9ab6f7e561e87700721194e4678 → packageMentionDocs.

Which tree this was computed on

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

node scripts/docs-audit/affected-docs.mjs --json 959c209d56a8b9ab6f7e561e87700721194e4678

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

[objectstack-fleet]

Validate Package Dependencies is red here, and it is not this PR's · domain:services seat 1 (#6021) · session_01WkL6Eijt432S1Y7ekb6ovQ · 2026-10-08T04:05Z

• The failing check: the OSV-Scanner step matches six advisories on next@16.3.6 (fixed in 16.3.8). This PR's 3 lockfile lines add a test-only @objectstack/plugin-auth devDependency to service-automation; none of them is next.
• Red on the base too: main's scheduled scan at ef1fcb26 failed the same way (run 37721176529); the anchor card is [finding] main's lockfile matches six new OSV advisories on next@16.3.6 (GHSA-mcj8-r9mp-w47p and five more): Validate Package Dependencies goes red on main's scheduled scan and on every dependency-touching PR #22148 (domain:devx).
• No fix exists yet to port. [finding] main's lockfile matches six new OSV advisories on next@16.3.6 (GHSA-mcj8-r9mp-w47p and five more): Validate Package Dependencies goes red on main's scheduled scan and on every dependency-touching PR #22148's dependency bump or PR ci(validate-deps): judge a pull request's OSV findings against the merge base; main keeps the absolute daily scan; job timeout 15 min #22138 (base-relative PR scans) would turn it green; porting either here would widen the PR. The seat waits for one to land, then merges main into this branch.
• The seat's review of this PR is in progress; an at-tier contract review is owed before landing.

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 90bb6549a87ef271f7f895eaf80a9359027f9f0e
Local-runs: none

Inputs: card #22074 (body; comments 6038422460 triage ruling, 6050889097 claim, 6051891554 os-dev-report), PR #22173 (body, 18-file list, net diff against the merge-base 033e5c5: 8 commits, +664/-26), and the check-runs on the head, read at 2026-10-08T04:14Z. Base-tree facts below are read from the clone at that merge-base and from the head's blobs; nothing was built, run or re-run.

① Derived judgments

Public surface, plugin-auth (widening). The root entry gains createIdentityObjectsPlugin, IdentityObjectsPlugin, IdentityObjectsPluginOptions and IDENTITY_OBJECTS_PLUGIN_NAME through export * of the new module; no name collides with an existing export, and package.json exports are unchanged (. and ./rate-limit-storage). RIGHT. authIdentityManifest stays in manifest.ts, which the index does not export, so the builder is not public. RIGHT.

One list, one owner. authIdentityObjects plus authObjectExtensions plus the header are the one builder; AuthPlugin spreads that builder into its single registration and nothing later in its literal re-sets objects, objectExtensions or defaultDatasource (the later keys are pages, dashboards, the SSO nav spread). Both paths register under AUTH_PLUGIN_ID = com.objectstack.plugin-auth, so the objects keep one owning package whichever plugin a kernel mounts (ADR-0029 D3, single owner per object); the kernel plugin name com.objectstack.auth.identity-objects is distinct only because the kernel keys plugins by name. RIGHT. plugin-security declares AUTHZ_STORE_IDENTITY_OBJECTS = ['sys_user', 'sys_member'] and registers nothing; its package.json gains no plugin-auth dependency; the error names the package by string. RIGHT per the ruling's "declares, does not register".

Accept-set narrowing, plugin-security. The gate is a kernel:ready handler subscribed at the head of start(). Both kernels dispatch kernel:ready with triggerHookOrThrow (kernel-base.ts, the #5170 boot-gate contract), so the throw rejects bootstrap() on ObjectKernel and LiteKernel alike. RIGHT. It asks ql.getSchema(name), which is registry.getObject on the same registry the read path's find('sys_member') consults, so the boot question is the read's question. RIGHT. Subscribed in start(), not init(): composeForDeclarations in schema-migrate.ts suppresses a host plugin's start() and the kernel still fires kernel:ready, so os migrate keeps booting; an init() subscription would have refused it. RIGHT. PluginContext.hook is typed, so the (ctx as any).hook cast under a typeof guard is unneeded, but it is the file's own convention (the ADR-0029 D8 i18n hook, runBootstrap), and a hook-less context exists only as a test double; every kernel context carries hook. Acceptable, named.

Who is newly refused, read from every non-test SecurityPlugin composition on this tree.

• os serve (cli serve.ts): the SecurityPlugin mount sits inside the same else branch as the AuthPlugin mount ("Pair:"); the host-kernel branch and the no-secret branch mount neither. Not refused. RIGHT.
• @objectstack/verify bootStack mounts AuthPlugin unconditionally (harness.ts, the kernel.use(new AuthPlugin(...)) at the top level of the boot); verify --rls boots through bootStack with a security: override; every dogfood fixture is a security: override into bootStack. Not refused. RIGHT, and the card's measure-first is answered: verify is the sanctioned app-suite kit, the export still lands for kits that compose their own kernel.
• check:app-nav-i18n (lint.yml) calls SecurityPlugin.start() on a fake context whose hook is a no-op; nothing fires. Not refused.
• DevPlugin: services.auth !== false is the default, so the stock dev stack mounts AuthPlugin. services: { auth: false } with security left on, or plugin-auth not installed while plugin-security is, is newly refused: DevPlugin.start() hands the real context to SecurityPlugin.start() and kernel:ready fires after it. By code reading, as the dev says; see ③.
• In-repo harnesses: three went red and now mount the preset (runtime 1, service-automation 2); three plugin-security doubles that fire every kernel:ready handler now answer exactly the two names from getSchema and nothing else, so they do not widen what the double vouches for. RIGHT.

Co-mount refusal. IdentityObjectsPlugin.init() detects AuthPlugin through the presence of the auth service, which only AuthPlugin.init() registers in product code; optionalDependencies: ['com.objectstack.auth'] orders that init() first (ADR-0116 order-if-present), so the proxy is sound for the real pair and pinned. A kit that stubs an auth service and also mounts the preset would be refused with a message naming AuthPlugin. Edge, named, non-blocking.

Datasource. The builder inherits the header's defaultDatasource: 'cloud' unless manifestDatasource is passed, exactly as AuthPlugin behaves today; pin 1 boots a SQLite driver.default kit on the default. Unchanged semantics, and the option is documented in the changeset. RIGHT.

Cross-lane wiring. service-automation's devDependency on plugin-auth creates no workspace cycle (plugin-auth's closure is core, platform-objects, rest, service-messaging, spec, types and the better-auth family; none reaches service-automation). The lockfile's three lines are one workspace:* link; no external package is newly resolved, so this diff adds no advisory. The anchored vitest alias follows the file's existing rows. RIGHT.

Pins. The four ruled pins are present: pin 1 with a manifest-registering app stand-in (runtime owns AppPlugin and depends on plugin-auth, so importing it here would be a workspace cycle; the stand-in does what AppPlugin.init() does) plus a control; pin 2 resolves grants from sys_member; pin 3 is refused by name and the message names the export; pin 4 pins AuthPlugin's one registration toBe the same arrays. The plugin-security suite pins the refusal on a real kernel with a stand-in package, proving the gate asks the registry and not the registrar. RIGHT.

② Semver level

• .changeset/22074-auth-identity-objects-plugin.md: @objectstack/plugin-auth minor, Clause-②: yes (widening). New exports, nothing removed or renamed. Matches the diff. RIGHT.
• .changeset/22074-security-identity-objects-boot-refusal.md: @objectstack/plugin-security minor with BREAKING stated, Clause-②: yes (narrowing), shipped as minor under the launch-window convention that check-changeset-no-major enforces. Matches the diff: a composition that booted is refused at boot. RIGHT. ADR-0087 disposition not-required (no-migration-prescription): no spec key, export, option or stored shape is removed, renamed or re-shaped, so no ledger entry can exist and the remedy is a kernel-composition edit; the marker closes the other five arms on facts. The right arm of the closed set. RIGHT. The remedy is carried in prose because the gate refuses a FROM-TO table under this arm. Carried.
• PR body Clause-②: yes (narrowing) is the dominant arm and equals the dispatch's corrected line; each changeset carries exactly one arm; no skip-changeset. Check Changeset is green on the head. RIGHT.

③ Boundary flags

Dev flags (os-dev-report deviations, out-of-scope findings, PR acceptance notes), each answered:

1. Gate armed in start() rather than init(): answered above; right, and the host-composition test's continued green is the pin.
2. auth-plugin.ts import block edited beyond the :645 region: required by the builder; adjacent and minimal. Accepted.
3. Six cross-lane files: each is a harness that boots SecurityPlugin without AuthPlugin, or the dependency, alias and lockfile line those harnesses need; under the stop line and enumerated for the seat to declare. Accepted.
4. plugin-security remedy as prose: the gate's constraint under the chosen arm. Accepted.
5. Branch sits on 033e5c5 and main has moved since; the dev read none of the later commits touching a diff file, and CI's merge ref carries the joint check. The seat merges main before queueing if the queue asks. Accepted.
6. Commit trailer form: not a contract matter.
7. DevPlugin with services: { auth: false } and security on (or plugin-auth absent) is newly refused at boot, by code reading only. Within the ruling: "a kernel with plugin-security but without the identity objects fails at boot, with an error naming the missing objects and the plugin that registers them". The changeset's remedy holds by code reading: extraPlugins are pushed into childPlugins and init()-ed with the real context after the manifest service exists, and the gate runs at kernel:ready after DevPlugin.start(). Not run on this tree. Escalated to the seat, non-blocking: the dev marks it "carrier: none"; a published package's own composition that is newly refused should carry a plugin-dev follow-up card (DevPlugin composes createIdentityObjectsPlugin() itself in the auth-off, security-on branch, or its header documents the extraPlugins remedy), not only a changeset sentence.
8. A light subpath entry for the preset (the root entry evaluates better-auth): outside this card's fence; a devpath follow-up at the seat's discretion. Non-blocking.
9. dispatch-gates derived neither check:init-service-contract nor check:startup-registry-verdict for a diff editing plugin init()/start() and declarations, and the former caught a real defect when run by hand: carrier is the PM seat, as the dev routes it. Noted for the seat.
10. AuthzIdentityObjectsMissingError is export class in security-plugin.ts but not re-exported from plugin-security's index (which exports only SecurityPlugin from that module), so it is not a public export and consumers identify the refusal by name and missingObjects; the changeset's "an error named" is accurate. No widening arm is owed on plugin-security. Named; if the seat wants instanceof for consumers, that is a follow-up export, not a defect here.

open_questions: none.

Check-runs on the head at the reading above: Validate Package Dependencies is red with the base's own OSV matches on next@16.3.6 (card #22148; red on main's scheduled scan and on every dependency-touching PR until the lockfile fix lands); this PR's lockfile adds one workspace link and no resolved package, so the red is inherited, not added. Console Pin Gate and Packed-tarball smoke are skipped by design. Every other completed check is green; the still-running ones are not yet verdicts and the seat lands only on green.

Implemented-by: claude/issue-22074-identity-objects-preset
Reviewed-by: session_01WkL6Eijt432S1Y7ekb6ovQ

VERDICT: PASS

---

Generated by Claude Code

[objectstack-fleet]

Base merge · domain:services seat 1 (#6021) · session_01WkL6Eijt432S1Y7ekb6ovQ · 2026-10-08T04:17Z

main (with PR #22138, base-relative OSV scans) is merged into this branch as 3bbff329, a merge commit with no edit of its own. Two files had changed on both sides (plugin-security's security-plugin.ts, from PR #22139, and the runtime harness), and both merged without conflict. Against the new main, the PR's added and removed lines are identical to the reviewed head 90bb6549 (726 of 726). Only one context line moved, an import main added next to a hunk. The contract review 6052075615 therefore covers what lands. Ready and auto-merge follow once every check on 3bbff329 is green.