cli: os migrate plan / apply cannot boot the stock showcase or a fresh blank app — Dependency 'com.objectstack.service-automation' not found for the connector plugins

[objectstack-fleet]

QA-source: #21721 · cli.migrate-plan-apply-json · acceptance[0]

Clause A1 of cli.migrate-plan-apply-json (rev 2) fails in the 17.7 pre-release run #21721 (subject 251a7dd4); seen by lanes L11 and L12, and verifier V5 reproduced it twice in each of two setups: CONFIRMED, high — schema migration is unusable for every new blank app and for the showcase. Predates 17.6.0 (introduced by fc8a33935c, #12952, 2026-08-28).

Reproduction

1. In examples/app-showcase, or a fresh create-objectstack qa -t blank scaffold: os migrate plan --database-url file:/tmp/x.db.
2. Expected: the plan. Actual: exit 1, ✗ [Kernel] Dependency 'com.objectstack.service-automation' not found for plugin 'com.objectstack.connector.openapi' (the scaffold names connector.rest). --json and os migrate apply --json --yes exit 1 with {"error":"[Kernel] Dependency …"}.
3. Isolating control: adding new AutomationServicePlugin({ armRuntime: false, suspendedRunStore: 'memory' }) to a scratch config's plugins makes the plan exit 0. os migrate recorded-by / resume work (the data-migration stack adds automation). os dev is unaffected.

Mechanism

• The configs request automation only through requires: ['automation', …] (blank template line 52); serve resolves that token to AutomationServicePlugin (serve.ts:1868-1873).
• packages/cli/src/utils/schema-migration-plugins.ts:1296 composes config.plugins but never reads requires.
• Each connector declares a hard dependencies = ['com.objectstack.service-automation'] (connector-rest-plugin.ts:53, connector-openapi-plugin.ts:66); the kernel throws on the missing dependency (packages/core/src/plugin-order.ts:86-88).
• data-migration-plugins.ts:69-84 adds automation only when opts.automation === true.

More generally, any host plugin with a hard dependency on a service that requires supplies hits this on the schema stack.

---

Generated by Claude Code

[objectstack-fleet]

Triage: first grade — bug · priority:p1 · domain:cli · area:devpath · pm:queue. The schema-migration stack composes config.plugins but never resolves requires, so a hard-dependency connector cannot boot

Triage seat (objectstack-wide, first touch) · session_018zT8d8NpiQ1ExhuNd5TxY6 · 2026-10-04T11:50Z. ⛔ Not a claim, ⛔ not a dispatch.

Path: the road (devpath) | cli.migrate-plan-apply-json | P66

Filing gate. Category ① (a named placement and a reproduction), extracted under the RUNNER extraction obligation from run #21721. reach: the public entry os migrate plan / os migrate apply gives a wrong result on the stock showcase and on a fresh blank scaffold. Acting reader: the domain:cli execution seat.

Mechanism verified on main @ 16d241a6a.

• packages/cli/src/utils/schema-migration-plugins.ts:1297-1300 pushes only config.plugins. Nothing in that file reads config.requires.
• serve resolves the automation token through Serve.CAPABILITY_PROVIDERS (packages/cli/src/commands/serve.ts:1866-1873).
• The blank template asks for automation only through requires: ['automation', 'triggers'] (packages/create-objectstack/src/templates/blank/objectstack.config.ts:52). The showcase does the same (examples/app-showcase/objectstack.config.ts:107).
• Four connectors carry a hard dependencies = ['com.objectstack.service-automation']: connector-rest :53, connector-openapi :66, connector-mcp :70 and connector-slack :39.
• The kernel throws on the missing dependency (packages/core/src/plugin-order.ts:85-88).
• packages/cli/src/utils/data-migration-plugins.ts:69-84 adds automation only when opts.automation === true.

Why p1. The checklist item is P1 and its clause fails. Under North Star priority rule 2 that is a broken step on the road: a migration plan cannot be produced for any new app. It is not a security issue.

Routing. The fix lands in packages/cli, which is domain:cli. The connectors and the kernel are correct: a hard dependency on a declared capability is a legitimate shape.

Direction (triage's technical call, no ruling cited).

• The schema-migration composition resolves the config's requires tokens through the same seam serve uses. It does not keep a second copy of the token table.
• Automation is taken in the engine-only posture the data-migration arm already uses (armRuntime: false, memory run store), so that "a migration is not a second server" still holds.
• The dev decides which other requires tokens need the same treatment, and states that decision in the PR.

Pins.

• A blank scaffold and the showcase: os migrate plan, --json and os migrate apply --json --yes exit 0.
• Nothing is armed: no flow is registered and no trigger or job is bound.
• Control: a config with no connector is unchanged.

Dedupe. I read all 118 open issues; none covers this file and mechanism. #21733 (a plain os dev never runs autoMigrate) is a separate mechanism and is not a duplicate.

Size/model suggestion: M, mode:subagent.

---

Generated by Claude Code

[objectstack-fleet]

Claim: PM loop round 1 (17.7 pre-release defect from QA run #21721, dispatched on the maintainer's direct order)
Session: session_018zT8d8NpiQ1ExhuNd5TxY6
Account: hotlong (the seat's linked user as GET /user answers it; always the card's assignee)
Branch: claude/issue-21732-migrate-plan-requires
Worktree: objectstack-issue-21732
Domain: domain:cli (card label, as triage set it); expected surface packages/cli/src/utils/schema-migration-plugins.ts and the requires resolution serve already uses
File surface: packages/cli/src, packages/cli/test (or co-located tests), packages/qa/dogfood/test, .changeset/
Container & model: M, mode:subagent, model: opus (default tier; no path-derived mandate)
Clause-②: no
Thread-read: 5979626293
Serial constraints cleared: none named

Provenance: the maintainer, in Claude Code session session_018zT8d8NpiQ1ExhuNd5TxY6, 2026-10-04, verbatim: 「21732 和 #21723 你可以派发处理」; landing per the standing order 「开发完整就进队列合并」.

---

Generated by Claude Code

[objectstack-fleet]

os-dev-report
{
"issue": 21732,
"status": "done",
"branch": "claude/issue-21732-migrate-plan-requires",
"pr": "#21739",
"session": "session_018zT8d8NpiQ1ExhuNd5TxY6",
"premise_still_valid": true,
"summary": "Premise reproduced on base 316be32: os migrate plan exited 1 on a /tmp copy of examples/app-showcase ('Dependency com.objectstack.service-automation not found for plugin com.objectstack.connector.openapi') and on a /tmp blank scaffold (connector.rest). Fix: packages/cli/src/utils/schema-migration-plugins.ts gains resolveRequiredProviders, which resolves the config's requires (plus serve's always-on slate) through serve's own Serve.CAPABILITY_PROVIDERS and providesCapability. It composes a provider only when an already-composed plugin hard-depends on it, iterates to a fixed point, and keeps serve's explicit-instance-wins rule. Each provider boots in a declared posture: automation is the one row, { armRuntime: false, packageRoot }, with the run store left at its default ON PURPOSE (a deviation from triage's 'memory' suggestion). In inert mode the store is never attached, and the default makes init() declare sys_automation_run and sys_flow_dispatch, so the plan covers the tables serve creates. A token resolved without a posture is refused by name. A dependency no token supplies is left to the kernel, matching serve. Decision on other tokens: only automation, because it is the only provider any shipped plugin hard-depends on. Configs with no unmet dependency are untouched (the resolver returns before even loading serve.js).",
"tests": "Proof at cli build 826d5ce, fresh file:/tmp/i21732/.db each time. showcase: plan exit 0 (34 to create), plan --json 0 (34 pending), apply --json --yes 0 (34 created), re-plan --json 0 (0 pending). Blank scaffold: 0/0/0/0 (13/13/13/0). After apply, every table in both DBs has 0 rows, and the plan prints '[Automation] inert mode (armRuntime: false) ... no flow registered, no trigger or schedule armed'. New pins: 5 unit cases in src/utils/schema-migration-plugins.test.ts, plus src/utils/schema-migrate.requires-providers.integration.test.ts (a real kernel boot: dependent init ordered after the provider, listFlows() == [], sys_automation_run and sys_flow_dispatch in allObjects). Targeted run: 2 files, 38/38 passed. Ablation via scripts/ablation-replace.mjs at committed HEAD: 'plugins.push(...resolved.plugins);' replaced by a no-op, anchor 1 to 0, blob 1ad093cfbcd6 to 7465100641c3. Both new pins went red (2 failed / 36 passed); the integration error was exactly "[Kernel] Dependency 'com.objectstack.service-automation' not found for plugin 'com.example.os21732.connector'". Restore: blob == HEAD, git diff HEAD empty. The suite reads src, so no dist leg. pnpm --filter @objectstack/cli typecheck: exit 0. cli unit tier (--project unit): 3776 tests, 11 failed in 3 files on the first pass. Two of those (published-subpath-.pin) read the packed .d.ts of a CLI dist I had built with OS_SKIP_DTS=1; the third was a 5000ms timeout in hook-timeout-override-refusal on a shared box. After a real-types cli build, those 3 files passed 33/33. Integration tier declared to CI, except the new file (run locally, green). dispatch-gates --commands: 64 derived, all run, final exit 0 for each. check:dts-closure and check:dual-build-cjs-loads were red on the first pass for the same OS_SKIP_DTS dist and green after the rebuild. --ran: 64 derived / 64 run / 0 unrun. eslint narrowed: 'eslint --no-inline-config --format json' on the 3 changed .ts files gave 3 files, 0 errors, 0 warnings. The population is eslint.config.mjs over 'eslint .', and the files are not ignored. Invariance: the config enables no type-aware linting (no parserOptions.project, as the config itself states), so untouched files' verdicts cannot move. Full pnpm lint is CI's. All readings at HEAD 826d5ce. CI: in_progress / NOT MEASURED at report time.",
"mcp_calls": "0",
"api_writes": "3 - all through scripts/pm (fleet relay, one repository_dispatch each): pr_create POST /repos/objectstack-ai/objectstack/pulls (#21739, draft forced); label-write --assign hotlong POST /repos//issues/21739/assignees; post-stamped POST /repos//issues/21732/comments (this os-dev-report). Plus git push (not REST). No labels written: the dispatch named none, and a changeset is present, so no skip-changeset.",
"open_questions": [],
"out_of_scope_findings": [
"class: a (candidate; seat decides) · reach: public door 'os migrate plan' on examples/app-showcase at 826d5ce lists 34 tables and none of sys_approval_action / sys_approval_approver / sys_inbox_message / sys_notification_delivery / sys_webhook. The showcase declares requires: ['approvals', 'messaging', 'webhooks'], whose providers (plugin-approvals, service-messaging, plugin-webhooks) register those objects under os serve. The coverage line ('34 of 36 declared object(s)') cannot see objects that were never declared, so the omission is silent. This PR composes only providers the kernel cannot order without, by design, and states the residue in Acceptance notes. · evidence: /tmp showcase plan --json pending list (0 hits for approval|inbox|webhook); grep of sys_ object names in those packages' src · dedupe words: 'migrate plan requires providers coverage', 'schema-migration composition requires tokens object set', 'sys_approval_action migrate plan', 'os migrate plan partial served object set'",
"carrier: 承接者:无 · noted, not filed (observation): a fresh-database plan prints platform boot lines that read like faults: 'WARN [ObjectQLPlugin] sys_metadata_activation is registered but could not be read', the federated-binding ERROR for the showcase's two external objects, and 'Core service missing: auth, job'. They predate this diff and are recorded in the PR's Acceptance notes."
]
}

---

Generated by Claude Code