[objectstack-fleet]

Requested by Leehom · project thread

Fixes #28713

Clause-②: yes (widening) — @objectstack/core adds one read-only public member, dispatchesBootPhaseHooks(), on ObjectKernel and ObjectKernelBase (so LiteKernel); no accepted value changes, nothing is narrowed.
Metadata-protocol: none

维护者速读

• 改了什么:环境里保存的连接器(元数据门 / Studio 保存)若与宿主插件提供的连接器同名,平台启动时的处理与运行中完全一致:插件的连接器照常服务,保存的那条不服务并记录日志。保存的连接器改为在所有插件启动完成后再实例化(仍在服务器开始接收请求之前)。另在 @objectstack/core 的两种内核上加一个只读方法 dispatchesBootPhaseHooks(),让插件在自己的 start() 里知道启动阶段钩子是否会派发;不会派发(或宿主不回答)时,保存的连接器仍在自动化插件的 start() 中实例化,与原来一样,绝不落空。
• 为什么改:运行中已经判定"插件优先、保存条目跳过",启动时却在插件注册前就下了"名字空闲"的结论,两处判定不一致。这是可用性问题,不是数据问题;细节在席位处。
• 风险与回滚:优先级不变(插件仍优先,未改 ADR-0097 §4),宿主自己声明的连接器与已安装包的连接器启动行为不变,有对照测试钉住。core 只新增一个只读方法。回滚即还原本 PR。
• 先看:packages/services/service-automation/src/plugin.ts(holdStoredEntries、kernelDispatchesBootPhaseHooks、kernel:bootstrapped 那一轮的 held 判断)、packages/core/src/kernel.ts 与 kernel-base.ts 的新方法、src/connector-materialization.test.ts 新的 service-automation: a stored connector saved under a host plugin connector's name stops the next boot (#28698 follow-up) #28713 一节。
• 两分钟验证:pnpm --filter @objectstack/service-automation exec vitest run src/connector-materialization.test.ts,预期 108/108 通过(含 service-automation: a stored connector saved under a host plugin connector's name stops the next boot (#28698 follow-up) #28713 一节 6 例:插件同名跳过、空闲名在监听前就绪、宿主同名仍失败、三种不派发钩子的宿主仍在 start 中实例化)。
• 需要你做的:无,席位落地(core 新增公开成员,席位先跑契约复核)。

What changes

• A saved connector under a host plugin connector's name: the start agrees with the running platform. While the platform runs, a provider-bound connector saved in the environment (through the metadata door or Studio) under the name of a connector a host plugin provides is not served beside the plugin's connector: the plugin's connector keeps the name, and the conflict is logged. The start now reaches the same verdict: the plugin's connector is served ready under that name, and the saved connector is skipped with the same log record naming it. Precedence is unchanged (the plugin's connector wins, as ADR-0097 §4 already has it on a running platform), so no §4 ruling is needed.
• When saved connectors materialize. Connectors saved in the environment are now materialized once every plugin has started (the automation service's existing kernel:bootstrapped connector pass), instead of during the automation plugin's own start. They are still ready before the server accepts requests. Connectors the host's own stack declares, and an installed package's, still materialize during the automation plugin's start, with their fail-loud behavior unchanged, including on a name a plugin's connector also uses.
• A saved connector is never left unserved. The deferral applies only on a kernel that says it dispatches its boot-phase hooks. @objectstack/core gains dispatchesBootPhaseHooks(), read-only: ObjectKernel answers false exactly when its bootPhaseHooks option is false; LiteKernel (and anything on ObjectKernelBase) answers true. On a kernel that answers false, or a host whose kernel does not expose the member, saved connectors materialize during the automation plugin's start, as before.
• No save-door change: a connector under such a name is still accepted at save. Rows already at rest are covered by this change; a save-door refusal would be a separate narrowing.

Tests

• Unit, connector-materialization.test.ts, new #28713 describe (6 cases): a saved entry under a name a plugin registers in its own start() (after the automation plugin's): the boot starts, the plugin's connector serves its own action, the saved entry is skipped with the §4 record; control: a saved entry under a free name is not yet registered when a later plugin starts and is registered by kernel:listening; control: the host's own entry under such a name still fails the boot; a real ObjectKernel with bootPhaseHooks: false, and a host whose kernel has no reader or answers false, keep saved entries in the start reconcile so they serve.
• Kernel pins: kernel.boot-phase-hooks.test.ts reads dispatchesBootPhaseHooks() from a plugin's own start(): false under bootPhaseHooks: false, true for absent / true / undefined; lite-kernel.test.ts pins true.
• Restart dogfood, stored-connector-package-ref-restart.dogfood.test.ts: the first start also saves an environment-wide connector under the showcase's slack plugin connector name; the second start over the same database starts, lists the plugin's slack connector ready with the plugin's actions (not the saved one's), and its start record names the saved entry; control: the saved inline connector is already ready on the first read after the start.

Red on base, green on head, ablations

• Red: production sources (plugin.ts, kernel.ts, kernel-base.ts) restored to base 1c5b1773, rebuilt: unit 2 failed | 106 passed (108) (the two new service-automation: a stored connector saved under a host plugin connector's name stops the next boot (#28698 follow-up) #28713 cases that measure behavior; the hookless-host cases pass on base, as base keeps every saved entry in the start reconcile); restart dogfood 8 failed | 1 passed (9). Tree restored, git diff HEAD empty.
• Green on head: unit 108 passed (108); dogfood stored-connector-package-ref-restart, stored-connector-package-ref, install-local-restart-connectors: 3 passed (3) files, 21 passed (21) tests.
• Ablation 1 (saved entries back into the start reconcile: the hold set to a constant false): marker present in both built files of @objectstack/service-automation; unit 2 failed | 106 passed, restart dogfood 8 failed | 1 passed. Restored: blob 9f3bdcad == HEAD, marker absent after rebuild, tree clean.
• Ablation 2 (the kernel reader forced to answer "dispatches"): unit 3 failed | 105 passed (the three hookless-host cases). Restored: blob 9f3bdcad == HEAD, marker absent after rebuild, tree clean.

Package suites and type checks

• pnpm --filter @objectstack/core --filter @objectstack/service-automation run typecheck: exit 0 (both check:test-typecheck OK).
• pnpm --filter @objectstack/core test: 129 passed files, 2892 passed tests.
• pnpm --filter @objectstack/service-automation test: 251 passed files, 3216 passed tests.

Acceptance notes

• Measured, not observed (residue). Saved connectors now become available a little later during the start (on the showcase, about a third of a second later), still before the server accepts requests. A showcase restart with an instrumented connector registry saw no connector call, effect read or pull before that point. Possible in principle and not observed: an automation that runs during the start itself (a record change made by the app's own start-up work, or a scheduled job whose first run falls inside the start) and calls a saved connector would find it not yet available.
• A kernel that withholds its boot-phase hooks, or a host whose kernel does not say, keeps today's behavior for saved connectors: they are materialized during the automation plugin's start, so they are never left unserved; the conflict this card fixes is not fixed on such a host.
• No save-door refusal for such a name (a narrowing, and it would not cover rows already at rest); it is with the seat as a possible follow-up.

Verification

Every local reading above is on head 525f355c. Derived gate families (node scripts/pm/dispatch-gates.mjs --commands, reconciled with --ran): 67 derived, 66 run with exit 0, 1 not measured (check:dual-build-cjs-loads, exit 3: its prerequisite, every package's dist/, is not met in this checkout). The changeset, ADR-0087, empty-changeset and closing-keyword gates were also run against this body: exit 0. The repo-wide lint, test:repo and the full farm are CI's. Overlap: open PR #28693 also edits service-automation/src/plugin.ts; git merge-tree of its head with this one is clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FEkQ5oNHddQQdvMrpeQxiJ

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 2 package(s): @objectstack/core, @objectstack/service-automation, touching 9 documentable anchor(s).

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

• content/docs/ai/knowledge-rag.mdx (via ObjectKernel (symbol, a top-level class))
• content/docs/automation/flows.mdx (via AutomationServicePlugin (symbol, a top-level class))
• content/docs/kernel/architecture.mdx (via ObjectKernel (symbol, a top-level class))
• content/docs/kernel/cluster.mdx (via AutomationServicePlugin (symbol, a top-level class))
• content/docs/kernel/events.mdx (via ObjectKernel (symbol, a top-level class))
• content/docs/kernel/index.mdx (via ObjectKernel (symbol, a top-level class))
• content/docs/permissions/authentication.mdx (via ObjectKernel (symbol, a top-level class))
• content/docs/plugins/anatomy.mdx (via ObjectKernel (symbol, a top-level class))
• content/docs/plugins/packages.mdx (via ObjectKernel (symbol, a top-level class))
• content/docs/protocol/kernel/index.mdx (via ObjectKernel (symbol, a top-level class))
• content/docs/protocol/kernel/lifecycle.mdx (via ObjectKernel (symbol, a top-level class))

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

• content/docs/releases/v15.mdx (via ObjectKernel (symbol, a top-level class))
• content/docs/releases/v17/17-6.mdx (via AutomationServicePlugin (symbol, a top-level class))

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

What this run could not see

• 1 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 60 of 215 client-bound route-ledger rows — the other 155 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 155: 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; 100 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 — 44 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 5493b8842995fabb0979ae535301d3f3cb9fc65e → packageMentionDocs.

Which tree this was computed on

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

node scripts/docs-audit/affected-docs.mjs --json 5493b8842995fabb0979ae535301d3f3cb9fc65e

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

[objectstack-fleet]

domain:server#2 · os-project-manager · session_0186vfjHHMsRXC9EUT9hTFMo

Contract review

Served-tier: TIER_DEFAULT
Head-sha: 525f355ce2b02f8877ae5d405b85347a4949a079
Local-runs: none

PR #28755 (card #28713), reviewed 2026-11-01T17:38Z against merge-base 1c5b1773 with origin/main. Face: the Clause-②: yes (widening) declaration alone (record-recognisers --paths finds no schema, governed or narrowing hit on the eight changed paths; the changeset's Clause-②: line decides the declaration face, whose tier is TIER_DEFAULT). The review itself was run at the contract tier on the seat's instruction; the tier a face sets is not a ceiling. Inputs: the diff, the card and its four comments (triage 6559633664, claim 6560597942, amendment 6560860207, os-dev-report 6561408622), the PR body, the head's check-runs, the order and the seat's two later conditions.

① Derived judgments

• @objectstack/core gains one public member, dispatchesBootPhaseHooks(): boolean, on ObjectKernelBase (so LiteKernel) and on ObjectKernel. Right. It is read-only (no setter, no state written; ObjectKernel reads a construction-time option), documented on both classes with the same contract, and correct on both kernels: ObjectKernelBase answers true, and LiteKernel.bootstrap() dispatches kernel:ready, kernel:bootstrapped, kernel:listening unconditionally after every start(); ObjectKernel answers config.bootPhaseHooks !== false, and its bootstrap() returns before the three hooks exactly when bootPhaseHooks === false. The method name follows the option it reports. Reachable from a plugin through PluginContext.getKernel() (typed ObjectKernel), which is how the automation service and the three kernel tests read it. Additive: no signature, export or accepted value of either package changes; no consumer break. The spec package's api-surface covers @objectstack/spec only, so no baseline moves. No content/docs page names bootPhaseHooks, so no prose falls out of date.
• @objectstack/service-automation: stored entries deferred to the kernel:bootstrapped pass, conditionally. Right. start() sets holdStoredEntries from kernelDispatchesBootPhaseHooks(ctx) once, just before the boot reconcile; the reader answers false when getKernel is absent or throws, when the member is absent or not a function, or when it answers anything but true. While held, reconcileDeclaredConnectors skips an entry only when PR fix(service-automation)!: a connector stored in the environment never reads the host's files #28671's unchanged classifier says why === 'stored' and records storedEntriesHeld; host-declared and installed entries take the start pass as before. The existing install-local: after a restart an installed package's connector never materializes — the kernel:ready rehydrate runs after automation's boot reconcile and announces no reload #28591 kernel:bootstrapped pass (fatal: false) clears the hold inside the serialized reconcile queue and runs the reconcile when anything was held even on an unchanged fingerprint. Because the hold is cleared only there, the metadata:reloaded reconcile and the degraded-retry timer cannot serve a stored entry early. On a kernel that answers false, and on a host that does not expose the member, the hold is never set and stored entries keep today's start pass: a stored connector is never left unserved (seat condition 1), pinned by three unit cases (a real ObjectKernel with bootPhaseHooks: false; a LiteKernel with the reader removed; one answering false) and by ablation 2 reddening exactly those three.
• Outcome for a stored row under a plugin connector's name. Right. The connector plugin registers in its own start() (connector-slack declares dependencies: ['com.objectstack.service-automation']), so by the bootstrapped pass the plugin holds the name; the reconcile's existing ADR-0097 §4 check (!existing && getConnectorOrigin(name) === 'plugin') reports through the one fail(msg, cause, stored) reporter from PR fix(service-automation): a stored connector's configuration fault never stops the platform starting #28729, which in soft mode logs the same record and skips. No second skip path is added; the §4 text, the plugin-wins precedence and assertSameOriginOrFree are untouched, so no §4 ruling is needed. Pinned by the unit case (origin plugin, the plugin's action resolves, the stored one does not, the record present) and by the restart dogfood (second start finishes, the plugin's slack lists ready with the plugin's actions, the boot record names the stored entry).
• Controls. Right. A stored entry under a free name is absent when a later plugin starts and present at kernel:listening (unit), and ready on the first read after the restart (dogfood): the moment it becomes ready is pinned. PR fix(service-automation): a stored connector's configuration fault never stops the platform starting #28729's #28698 stored-fault describe is unchanged and, on LiteKernel, now exercises the deferred pass: green. The host's own entry under a plugin connector's name still fails the boot (unit control); connector materializer: an installed package's package-relative providerConfig file ref is read from the HOST's package root, so an install-local app can bind the host's own file (measured: it materialized ready with the host's OpenAPI document) #28534's installed / unrecorded readings are not touched.
• Order rulings. All held: same verdict as the running platform; no precedence change; no save-door refusal (named as a follow-up); host-declared entries unchanged.
• Availability class. The PR body, commits and changeset state the outcome in product words and carry no recipe. The restart dogfood and the unit describe carry the measurement, which is where the order puts it; the card body was already public.

② Semver level

• Changeset .changeset/28713-stored-connector-plugin-name-at-start.md: @objectstack/service-automation: patch, @objectstack/core: patch, with Clause-②: yes (widening) and Metadata-protocol: none, matching the PR body line for line. Consistent and correct. The level axis (AGENTS.md, maintainer ruling A on changeset levels: minor only when the metadata protocol changes (added / narrowed / semantic), patch otherwise; release notes grouped by what the reader must do (maintainer ruling A, 2026-10-21) #25105; check-changeset-no-major.mjs) grades by the metadata protocol alone: a none declaration must grade every introduced entry patch, and "a non-protocol change, widening or breaking, ships patch". A new read-only kernel method is a public-surface widening and no change to what a metadata author can write, so yes (widening) + none + patch is the honest pair; the minor the claim amendment named for core would have been refused by that gate. The declaration pair is right, not the level.
• The Check Changeset check-run on this head concluded success; the dev also ran the gate with the PR body as event, exit 0.

③ Boundary flags

• open_questions: none.
• Dev deviation "Clause-② measured yes (widening), not the order's expected no": accepted; the measurement is right (see ①) and the order said to declare what is measured.
• Dev deviation "core changeset patch, not the amendment's minor": accepted (see ②); the amendment's level was not per the rule.
• Out-of-scope finding "save-door refusal for a stored connector under a host plugin connector's name": with the seat as a possible follow-up; a narrowing, correctly left out of this PR per the order.
• Residue (seat condition 2), stated in product words in the PR's Acceptance notes, first bullet: saved connectors become available a little later during the start (about a third of a second on the showcase), still before the server accepts requests; an automation that runs during the start itself (a record change made by the app's own start-up work, or a scheduled job whose first run falls inside the start) and calls a saved connector would find it not yet available; measured on an instrumented showcase restart as not observed. Honestly stated; the second bullet also says the fix does not apply on a kernel that withholds its boot-phase hooks or a host that does not say. Nothing else observable during start changes for host-declared or installed connectors.
• Overlap: open PR feat(service-automation, metadata-protocol): a flow override declared in BASE.custom is the packaged flow, saved, served and armed in place of the base (#28412) #28693 edits service-automation/src/plugin.ts in one hunk near line 4971 (flow precedence), far from this pass; git merge-tree of this head with its head is clean.
• CI state at 2026-11-01T17:38Z: on head 525f355c, Check Changeset, Governed Surface Queue Guard, PR-body guards, Dogfood Regression Gate, Plan Test Core shards, Spec property liveness, Lint · PM dispatch-gates and Lint · scoped · tooling self-tests are success; Test Core 1–8, Build Core, Build UI Deps, Live E2E UI, the remaining Lint and Type Check jobs are in_progress; none failed. The merge-base 1c5b1773 carries no non-green check-run over its 131 runs, so no red can be excused by signature. Landing waits for the full set green (precondition ②), which is the seat's read at queue time.
• Not measured locally: check:dual-build-cjs-loads (dev: prerequisite not met in the checkout); CI's Build Core covers it.
• Author: PR user.login is objectstack-fleet[bot]; no relay author note owed.
• No must-fix. Not required for landing, for the seat's judgment: the PR is still a draft and carries no needs:contract-review label; nothing in the record changes that.

Implemented-by: claude/project-thread-3zwnx2
Reviewed-by: session_0186vfjHHMsRXC9EUT9hTFMo

VERDICT: PASS

---

Generated by Claude Code

[objectstack-fleet]

domain:server#2 · os-project-manager · session_0186vfjHHMsRXC9EUT9hTFMo

席位核对

ACCEPT · domain:server seat 2 · os-project-manager · session_0186vfjHHMsRXC9EUT9hTFMo · 2026-11-01T17:39Z · head 525f355c · #28713

The maintainer's standing authorisation for landing reviewed PRs, verbatim: 「按照 pm-dispatch 规则复核过的都授权」.

1. Shape:
   • Against main with Fixes #28713; changesets patch for @objectstack/core and @objectstack/service-automation; Clause-②: yes (widening), Metadata-protocol: none.
   • check-governed-merges --pr 28755 reads NOT governed (0 of 8 paths), +331 / -7. Landing tier S.
   • The claim (6560597942, surface amended at 6560860207) names this PR's branch, claude/project-thread-3zwnx2. The amendment's expected minor for core is superseded: a non-protocol widening ships patch (AGENTS.md), as the review confirms.
2. Against the order and the seat's two conditions:
   • A stored connector saved under a host plugin connector's name no longer stops the next start: the plugin's connector serves, and the stored row is skipped with PR fix(service-automation): a stored connector's configuration fault never stops the platform starting #28729's one stored record. No precedence change, no second skip path, no save-door refusal.
   • Stored entries wait for the after-start pass only where the kernel says that pass runs; on any other host they keep today's start pass, so a stored connector is never left unserved (three unit pins, an ablation reds exactly them).
   • The window between the kernel being ready and the after-start pass is named in product words in the acceptance notes.
   • Restart dogfood red on base (8 failing), green at head (21/21); unit 108/108; both ablations red; host-declared fatal pins unchanged.
3. Contract review: owed (a new public read-only kernel member). PASS on this head, no must-fix (record 6561495065).
4. Gates: the dev reports 66 of 67 derived gates run green, check:dual-build-cjs-loads NOT MEASURED locally; CI on this head was in progress with 0 red at review, and auto-merge waits for it.
5. Overlap: git merge-tree against PR feat(service-automation, metadata-protocol): a flow override declared in BASE.custom is the packaged flow, saved, served and armed in place of the base (#28412) #28693 is clean.
6. Landing: pr_ready + automerge_enable through the relay.

---

Generated by Claude Code

[objectstack-fleet]

domain:server#2 · os-project-manager · session_0186vfjHHMsRXC9EUT9hTFMo

CI note · 2026-11-01T18:07Z

• Failing: Test UI (rollup) on 525f355c, because Test UI (15/16) was cancelled at its 30-minute job timeout. It was not a test failure. The diff touches @objectstack/core, so the UI tree ran in mode=full.
• Reading: the shard was still passing tests when it was killed. No test failed, and no gap between log lines exceeds 2 minutes after setup. Recent full-mode merge-group runs of the same shard finish in about 14 minutes. That is runner time, not a red test, but it is not yet proven to be independent of this diff.
• Re-run: the relay re-runs only runs that concluded failure, so this cancelled run cannot be re-run from the seat. The card thread is merging origin/main into the branch, which re-runs CI against the current base. If shard 15 times out again in full mode, the thread measures the UI shard's per-file time against base before anything else is pushed.

---

Generated by Claude Code

[objectstack-fleet]

domain:server#2 · os-project-manager · session_0186vfjHHMsRXC9EUT9hTFMo

Contract review

Served-tier: TIER_DEFAULT
Head-sha: 08182e92e841af25746ca51776c4847728033dac
Local-runs: none

Re-pin, 2026-11-01T18:09Z, of the PASS record on head 525f355ce2b02f8877ae5d405b85347a4949a079 (PR #28755, card #28713). Head 08182e92 is a merge commit with parents 525f355c and origin/main at 5493b884; the merge-base with origin/main is now 5493b8842995fabb0979ae535301d3f3cb9fc65e. Face unchanged: the Clause-②: yes (widening) declaration alone, TIER_DEFAULT.

① Derived judgments

• The branch's own diff is unchanged. git diff 5493b884..08182e92 is byte-identical to the reviewed git diff 1c5b1773..525f355c across all eight files (331 insertions, 7 deletions); the only textual difference between the two diffs is the index blob line of packages/services/service-automation/src/plugin.ts, which is main's. Every judgment of the earlier record stands: the new read-only dispatchesBootPhaseHooks() on both kernels, the conditional deferral of stored entries to the kernel:bootstrapped pass, the one §4 soft path, no precedence change, host-declared entries unchanged, a stored connector never left unserved.
• Main's delta in the PR's files. Between the old and new merge-bases, main changed exactly one of the eight files: plugin.ts, eight added lines of doc comment on resolveFlowContenders from PR feat(service-automation, metadata-protocol): a flow override declared in BASE.custom is the packaged flow, saved, served and armed in place of the base (#28412) #28693 (merged as 3ee6af44), at line ~4970, in the flow-precedence area, nowhere near the connector reconcile, the hold or the bootstrapped pass. No code line moved.
• The merge is clean. The head's tree (b52c8425) equals a recomputed git merge-tree --write-tree 525f355c 5493b884; no conflict markers in plugin.ts. The overlap noted earlier with open PR feat(service-automation, metadata-protocol): a flow override declared in BASE.custom is the packaged flow, saved, served and armed in place of the base (#28412) #28693 is now resolved by that PR's merge.

② Semver level

• Unchanged: .changeset/28713-stored-connector-plugin-name-at-start.md at patch for both packages, Clause-②: yes (widening), Metadata-protocol: none, identical on the new head and matching the PR body. Correct per the level axis (a non-protocol widening ships patch).

③ Boundary flags

• No new dev flag or open question since the earlier record; the residue statement in the PR's Acceptance notes is unchanged.
• CI on 08182e92 at 2026-11-01T18:09Z: 33 runs, 4 success, 21 pending, none failed. origin/main at 5493b884 shows one non-green run, Fleet write relay | failure, a relay workflow that is not one of this PR's check families; no PR gate is red on the base. Landing still waits for the head's full set green (precondition ②), the seat's read at queue time.
• Author remains objectstack-fleet[bot]; no relay author note owed.
• No must-fix.

Implemented-by: claude/project-thread-3zwnx2
Reviewed-by: session_0186vfjHHMsRXC9EUT9hTFMo

VERDICT: PASS

---

Generated by Claude Code