fix(cli): split MCP capability provider to avoid pulling runtime-host/server into TUI - #4007
Conversation
jackwener
left a comment
jackwener
left a comment
There was a problem hiding this comment.
I reviewed exact head 69f85d443f58cf441466a92c6a3c0df1317ce162. I found no P0–P2 defect in the extraction.
The production behavior is preserved: createMcpCapabilityProvider() moved unchanged into mcp-capability-provider.ts, the command module re-exports it for existing consumers, and the TUI now imports the pure module directly. The new module has no runtime dependency on @maka/runtime-host/server.
I also reproduced the performance premise with fresh builds of the PR base and this head on the same machine. Median cold imports of tui-mcp-control.js fell from about 383 ms to 99 ms, and runtime-host-tui-command.js fell from about 416 ms to 197 ms. The corresponding Node ESM debug events dropped by roughly 79% and 66%. The full repository build and all 541 CLI tests passed. Exact-head hosted test succeeded, and the current-main merge is clean.
Two non-blocking P3 gaps remain:
- The tests still import the compatibility re-export from
runtime-host-capability-provider-command.ts, so they protect function behavior but do not protect the import boundary that this PR fixes. A small dependency-boundary check should fail iftui-mcp-controlagain reaches@maka/runtime-host/server. - The PR body replaced the repository template and only says
Generated-by: Muse Spark. Please restore the AI-use declaration with the tool's scope, the verification section, and the checklist required by the contribution template.
Posted by an automated review agent operated by @WAWQAQ. This is not an
independent human review and does not satisfy the committer review required by
CONTRIBUTING.md. A human is accountable for this comment — please push back if
anything here is wrong.
简体中文
本条评论由 @WAWQAQ 运行的自动化审查程序发出。它不构成 CONTRIBUTING.md
所要求的独立人类审查，也不能替代人类审查。有人类对本条评论负责，如有错误请直接指出。
…/server into TUI TUI imported createMcpCapabilityProvider from runtime-host-capability-provider-command.ts, which statically imports runRuntimeHostProcessLifecycle from @maka/runtime-host/server. That pulled 372 runtime files and 879 total ESM modules, making runtime-host-tui-command import ~1.28s vs 0.23s for cli-core. Split the pure createMcpCapabilityProvider into mcp-capability-provider.ts (deps only on @maka/core/mcp, @maka/mcp, @maka/runtime-host/protocol). tui-mcp-control now imports from the pure module; the command file re-exports for compatibility and keeps the server import only for runRuntimeHostCapabilityProviderCli. Fixes apache#4005 Measured: - tui-command import 1280ms/879 files/233 runtime -> 563ms/287 files/3 runtime (-56%) - tui-mcp-control 1110ms/808 files/233 runtime -> 76 core/5 storage/0 runtime Generated-by: Muse Spark
Generated-by: Codex
69f85d4 to
532dbc2
Compare
jackwener
left a comment
jackwener
left a comment
There was a problem hiding this comment.
I re-reviewed the updated exact head 532dbc2fb6def5ce34ec77167aa3bde9e55f52a5. I found no P0-P3 issues.
The two earlier non-blocking gaps are closed:
- The original extraction commits are patch-equivalent after the rebase. The added emitted-module regression now verifies that the TUI imports
mcp-capability-provider.js, that both the TUI and provider stay free of@maka/runtime-host/server, and that the command compatibility re-export is the same implementation. Reverting the import boundary makes this test fail. - The PR body now contains the verification results, AI-use scope, checklist, and behavior declaration required by the repository template. The new commit also carries its
Generated-by: Codextrailer.
The exact-head hosted test check completed successfully, and the current-main merge is clean. The prior same-machine performance measurements remain applicable because the rebased extraction is patch-equivalent: median cold imports fell from about 383 ms to 99 ms for tui-mcp-control and from about 416 ms to 197 ms for the TUI command.
Posted by an automated review agent operated by @WAWQAQ. This is not an
independent human review and does not satisfy the committer review required by
CONTRIBUTING.md. A human is accountable for this comment — please push back if
anything here is wrong.
简体中文
本条评论由 @WAWQAQ 运行的自动化审查程序发出。它不构成 CONTRIBUTING.md
所要求的独立人类审查，也不能替代人类审查。有人类对本条评论负责，如有错误请直接指出。
3 participants
Summary
Fixes #4005.
The CLI TUI previously reached
createMcpCapabilityProviderthrough a command module that also imports@maka/runtime-host/server. This keeps the provider implementation inmcp-capability-provider.ts, letstui-mcp-controlimport that pure module directly, and retains the command-module re-export for existing callers. The follow-up test guards the emitted TUI-to-provider boundary so it cannot silently regain the Runtime Host server dependency.Verification
mise exec node@24.18.1 -- npm --workspace maka-agent run buildmise exec node@24.18.1 -- node --test packages/cli/dist/__tests__/runtime-host-capability-provider-command.test.js— 3 passedtestcheck passed before this follow-up; this push reruns CI.AI use
Tool(s) and scope: Muse Spark was declared for the initial provider extraction. Codex added the emitted-module import-boundary regression test and restored this PR template metadata. The follow-up commit carries a
Generated-by: Codextrailer.Checklist
Does this PR entail a change in behavior?