[objectstack-fleet]

Requested by Elon · project thread
Fixes #27977

domain:server#3 · os-elon-musk · session_016WV4cx4GVsYbtK2oE4scBf

Clause-②: no
Metadata-protocol: none

维护者速读

• 改了什么:只加一个测试文件 connector-definition-cluster.test.ts,用两个内核(各自 ObjectQLPlugin 元数据协议 + 自动化插件)共享一个 SQLite 文件和一条总线,测量「在 A 上发布改过的连接器定义,B 会不会跟着重建」。不改任何运行时代码。
• 为什么改:service-automation: a connector credential written through the door reaches only the replica that took it; a held instance on any other replica stays down until a metadata reload or a restart #27428 的裁决 6513279565 要求单独测量这一点。结论:B 不跟。lane 2 把变更送到了 B 的协议监听器,但自动化插件的监听只认 flow,metadata:reloaded 又只在本内核触发,所以 B 一直用旧定义,直到重载或重启。缺口以 it.fails 钉住,修复卡是 automation (cluster): a published connector definition change re-materialises only on the publishing replica; peers keep the old instance until reload #28002。
• 风险与回滚:零运行时风险,测试不进发布包(files 只发 dist)。回滚即删掉这个文件。
• 先看:packages/services/service-automation/src/connector-definition-cluster.test.ts,it.fails 那一例和其后的对照例。
• 两分钟验证:pnpm --filter @objectstack/service-automation exec vitest run src/connector-definition-cluster.test.ts,预期 2 passed | 1 expected fail (3)。
• 需要你做的:无,席位落地。

What changes

One new test file, packages/services/service-automation/src/connector-definition-cluster.test.ts, built like connector-credential-cluster.test.ts (#27941): two ObjectKernel replicas, each running ObjectQLPlugin's metadata protocol and AutomationServicePlugin, over ONE better-sqlite3 file both open, joined by a bus that delivers every publish to every subscriber (publisher included). Each replica is attached the way MetadataClusterBridgePlugin attaches it at kernel:ready: lane 2 (attachMetadataMutationPubSub) and lane 4 (attachConnectorCredentialPubSub). Lane 1 (metadata.changed) is not attached: it replays into a MetadataManager's caches, and the connector reconcile reads the ObjectQL registry and the protocol's execution view, never that manager.

A definition change is published on A through the per-item door (a draft saveMetaItem, then publishMetaItem), changing providerConfig.endpoint from V1 to V2.

Measurement

	result
A, the publishing replica	re-materializes with V2 (ObjectQLPlugin announces A's own metadata:reloaded after the per-item publish)
lane 2 to B	delivered: B's protocol replays connector/NAME into B's mutation listeners
B's live instance, no reload on B	does not converge: B's provider is never called (expected undefined to be 'https://v2.billing.example.test')
control: metadata:reloaded on B	B materializes V2 from its own read of the shared store

Cause, read from the code: subscribeFlowMutations in plugin.ts returns early for any mutation whose type is not flow, and metadata:reloaded is a kernel-local hook a peer never receives. So the gap is the trigger, not the store or the read. The lane choice for the fix belongs to #28002.

Tests

• connector-definition-cluster.test.ts: Tests 2 passed | 1 expected fail (3).
  • Harness health, a plain it: A converges and lane 2 reaches B. This keeps the it.fails from passing on a broken harness.
  • The gap, it.fails naming automation (cluster): measure whether a published connector definition change materialises on every replica or only on the publishing one #27977 and automation (cluster): a published connector definition change re-materialises only on the publishing replica; peers keep the old instance until reload #28002: B converges with no reload on B. Its failure was read with the case temporarily run as a plain it: the one assertion that fails is B's last endpoint, undefined instead of V2.
  • Control, a plain it: B holds no instance before the reload, and holds V2 after it.
• pnpm --filter @objectstack/service-automation test: Test Files 222 passed (222) · Tests 2832 passed | 1 expected fail (2833), lock VERDICT command-exit 0.
• pnpm --filter @objectstack/service-automation typecheck: lock VERDICT command-exit 0.

Acceptance notes

• Side finding, same root, measured with a throwaway probe that is not committed: a direct active save (saveMetaItem with no mode, what PUT /api/v1/meta/connector/:name calls) does not re-materialize even on the writing replica. A stayed on V1 after saving V2, and its listeners heard the mutation. The seat recorded it on automation (cluster): a published connector definition change re-materialises only on the publishing replica; peers keep the old instance until reload #28002.
• No changeset (skip-changeset): the package publishes only dist. After pnpm --filter @objectstack/service-automation build, grep for the test's names in dist gave 0 hits, and the positive control AutomationServicePlugin gave 4 files.

Verification

Head 022ad12c, base 46943657.

Derived gate families and lint

node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack derived 50 families over the 1 changed path. 49 exited 0. pnpm check:dual-build-cjs-loads exited 3 (PREREQUISITE NOT MET: it needs every package's dist in this worktree), so it is NOT MEASURED locally and CI runs it. check-plugin-teardown-shape --self-test exited 3 on the shallow clone and 0 after git fetch --unshallow. --ran reconciliation: 50 derived, 49 run, 1 NOT-MEASURED, 0 UNRUN. pnpm lint exited 0.

Human Minimum

• 1. Schemas start as Zod; packages/spec holds no runtime logic. (Not touched.)
• 2. Every name I added uses the casing for its kind.
• 3. No formatter ran; pnpm lint passes.
• 4. One issue, one branch off an up-to-date main, one pull request.
• 5. A change that publishes carries a changeset: nothing published, skip-changeset.
• 6. packages/spec touched: not touched.
• 7. No hand edits to content/docs/references/, packages/*/CHANGELOG.md or content/docs/releases/.
• 8. Title, body and comments are in English.
• The Before Submitting list in CONTRIBUTING.md is done.

---

Generated by Claude Code

🤖 Generated with Claude Code

https://claude.ai/code/session_016WV4cx4GVsYbtK2oE4scBf

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• 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 — 0 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 b1eb3cf9411f773bf6bac996e52a1b8db7ba3d30 → packageMentionDocs.

[objectstack-fleet]

domain:server#3 · os-elon-musk · session_016WV4czuTWNgKR22fKv7jia

Seat ACCEPT · PR #28010 · head 022ad12cff5a202bf1155d69de81cb8bfd4fd277 · 2026-10-30T07:56Z

维护者速读

This PR is test only. It measures what #27977 asked: when one replica publishes a changed connector definition, does a peer pick it up? It does not. The publishing replica re-materialises, and lane 2 delivers the mutation to the peer, but the automation plugin on the peer ignores a connector mutation, so the peer keeps its old instance until a reload. The gap is pinned as it.fails, and the fix card is #28002 (lane choice is triage's). A control shows that a reload on the peer converges it from the shared store, so only the trigger is missing.

席位核对

• Shape: draft → main, Fixes #27977. One new file, service-automation/src/connector-definition-cluster.test.ts (+219). skip-changeset (test only).
  • check-governed-merges --pr 28010: NOT governed.
• Read of the test: two ObjectKernels over one shared SQLite file and one bus, attached with lanes 2 and 4 as the cluster bridge attaches them, like fix(service-automation): a connector credential written through the door reaches every replica #27941's harness. There are three cases. (1) The publisher re-materialises V2 and lane 2 reaches the peer: green. (2) The peer converges with no reload: it.fails, citing automation (cluster): measure whether a published connector definition change materialises on every replica or only on the publishing one #27977 and automation (cluster): a published connector definition change re-materialises only on the publishing replica; peers keep the old instance until reload #28002, to be promoted to a plain it when automation (cluster): a published connector definition change re-materialises only on the publishing replica; peers keep the old instance until reload #28002 lands. (3) Control: a metadata:reloaded on the peer converges it: green.
• Measurement result: the peer does not converge. The cause, as the dev read it, is that service-automation's mutation listener takes flow only and metadata:reloaded is kernel-local. Side finding (unpinned probe): a direct active PUT /meta/connector/:name does not re-materialise even on the writing replica. Both are carried on automation (cluster): a published connector definition change re-materialises only on the publishing replica; peers keep the old instance until reload #28002.
• Declarations: Clause-②: no, Metadata-protocol: none. No runtime edit, so no contract review is owed.
• Local (card thread): package suite 222 files, 2832 passed plus 1 expected fail; typecheck and pnpm lint exit 0; 49 of 50 derived gate families exit 0, with check:dual-build-cjs-loads NOT MEASURED locally (CI runs it).
• Gate check-runs on this head: 53 total, 35 success, 18 skipped by the path filter, 0 failed. mergeable_state: clean.
• Landing: Tier S, under the maintainer's landing grant for this term (2026-10-29 22:05Z, seat thread). Ready + auto-merge through the relay.

ACCEPT