refactor(10/12): rewire CLI, daemon, and MCP server boundaries

[cameroncooke]

Summary

This is PR 10 of 12 in a stacked PR series that decouples the rendering pipeline from MCP transport. Depends on PR 9 (all tool migrations complete). This PR connects the dots -- it rewires the three output boundaries (CLI, daemon, MCP server) to use the render session from PR 3 with the event-based handlers from PRs 5-9.

Architecture: three boundaries, one rendering engine

The rendering pipeline has three consumers, each using the same render session differently:

CLI direct (src/cli/register-tool-commands.ts): Creates a render session with the user's chosen strategy (text or JSON). Wraps emit to write incrementally to stdout as events arrive (streaming output during builds). After the handler completes, calls finalize() to flush any buffered content (grouped diagnostics). Sets exit code from session.isError().

MCP server (src/utils/tool-registry.ts): Creates a render session with text strategy. After the handler completes, calls finalize() to get the complete rendered string, wraps it in a ToolResponse (the MCP protocol type). ToolResponse construction happens here and only here -- it is not exported or used anywhere else in the codebase.

Daemon (src/daemon/daemon-server.ts): Creates a render session in record-only mode. Sends raw events over the wire to the CLI client. The CLI client re-renders locally using its own session, giving the same output as CLI direct mode.

CLI changes

• output.ts: Deleted printToolResponse(), extractRenderedNextSteps(), and all _meta coordination logic. These were the main sources of complexity in the old rendering pipeline. Kept formatToolList() for --list output.
• register-tool-commands.ts: Now creates and manages the render session directly. Streaming output is handled by a thin wrapper around session.emit().
• daemon-client.ts: Updated to receive events from daemon and render locally.

Daemon protocol

• Protocol version bumped to v2. Wire payload is now { events, attachments?, isError? } instead of pre-rendered content.
• Old CLI + new daemon (or vice versa) gets a clear version mismatch error with restart instructions.

MCP resources

All MCP resource handlers updated to use the simplified context pattern (10 files). These are simpler than tool handlers since resources don't emit pipeline events.

Other changes

• src/integrations/xcode-tools-bridge/: Updated to work with the new handler context. Added bridge-tool-result.ts for structured bridge tool results.
• src/visibility/exposure.ts: Updated exposure predicates for new handler signatures.
• src/smoke-tests/: Updated test harness for new tool invocation pattern.
• Various utility files updated for signature changes: CommandExecutor, FileSystemExecutor, execution/, xcode-state-reader, xcode-state-watcher, video-capture, log_capture.

Stack navigation

• PR 1-9/12: Foundation, utilities, contract, tool migrations
• PR 10/12 (this PR): CLI, daemon, MCP server boundaries
• PR 11/12: Manifests, config, docs, examples
• PR 12/12: Snapshot test fixtures and benchmarks

Test plan

• npx vitest run passes -- boundary tests updated
• CLI text output matches expected formatting (manual spot check)
• CLI JSON output produces valid JSONL
• MCP server returns correctly structured ToolResponse content
• Daemon protocol v2 correctly transmits events over wire
• Smoke tests pass with new tool invocation pattern

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

Autofix Details

Bugbot Autofix prepared fixes for both issues found in the latest run.

• ✅ Fixed: Nullish coalescing changes Xcode availability detection logic
  • Changed nullish coalescing operator (??) back to logical OR (||) to properly handle empty strings in Xcode version field chain.
• ✅ Fixed: Unused outputStyle variable after refactoring
  • Removed the unused outputStyle variable extraction that was left behind after refactoring removed printToolResponse().

Or push these changes by commenting:

@cursor push 5001d2a65c

Preview (5001d2a65c)

diff --git a/src/cli/register-tool-commands.ts b/src/cli/register-tool-commands.ts
--- a/src/cli/register-tool-commands.ts
+++ b/src/cli/register-tool-commands.ts
@@ -221,7 +221,6 @@
       const jsonArg = argv.json as string | undefined;
       const profileOverride = argv.profile as string | undefined;
       const outputFormat = (argv.output as OutputFormat) ?? 'text';
-      const outputStyle = (argv.style as OutputStyle) ?? 'normal';
       const socketPath = argv.socket as string;
       const logLevel = argv['log-level'] as string | undefined;
 

diff --git a/src/daemon.ts b/src/daemon.ts
--- a/src/daemon.ts
+++ b/src/daemon.ts
@@ -208,9 +208,9 @@
       return { success: result.success, output: result.output };
     });
     const xcodeAvailable = Boolean(
-      xcodeVersion.version ??
-        xcodeVersion.buildVersion ??
-        xcodeVersion.developerDir ??
+      xcodeVersion.version ||
+        xcodeVersion.buildVersion ||
+        xcodeVersion.developerDir ||
         xcodeVersion.xcodebuildPath,
     );
     const axeVersion = await getAxeVersionMetadata(async (command) => {

_{This Bugbot Autofix run was free. To enable autofix for future PRs, go to the Cursor dashboard.}

[cursor]

Nullish coalescing changes Xcode availability detection logic

Medium Severity

Replacing || with ?? changes the semantics for empty strings. If xcodeVersion.version is "" (common when a command fails), ?? considers it non-nullish and stops evaluation, making Boolean("") return false. With ||, the chain would continue to check buildVersion, developerDir, and xcodebuildPath. This can incorrectly report xcodeAvailable as false even when later fields have valid values.

 

^{Reviewed by Cursor Bugbot for commit b91063e. Configure here.}

[cameroncooke]

Not a bug. The XcodeVersionMetadata fields are typed as string | undefined and are only assigned under result.success guards. The values come from regex captures ((.+) requires 1+ chars) or trim() on successful command output, so they are either undefined or non-empty strings. Empty string is not a realistic case, making ?? and || equivalent here.

[cameroncooke]

• refactor(12/12): add snapshot test fixtures and benchmarks #330
• refactor(11/12): update manifests, config, docs, and example projects #329
• refactor(10/12): rewire CLI, daemon, and MCP server boundaries #328 👈 (View in Graphite)
• refactor(9/12): migrate debugging, swift-package, and remaining tools #327
• refactor(8/12): migrate UI automation tools to event-based handlers #326
• refactor(7/12): migrate device and macOS tools to event-based handlers #325
• refactor(6/12): migrate simulator tools to event-based handlers #324
• refactor(5/12): change handler contract to event-based emission #323
• refactor(4/12): extract build/test utilities, platform steps, and xcodebuild pipeline #322
• refactor(3/12): add rendering engine and output formatting #321
• refactor(2/12): add pipeline event types, parsers, and event builders #320
• refactor(1/12): remove deprecated logging tools #319
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit a089cf9. Configure here.}

[cameroncooke]

Merge activity

• Apr 10, 12:18 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• Apr 10, 12:31 PM UTC: Graphite rebased this pull request as part of a merge.
• Apr 10, 12:31 PM UTC: @cameroncooke merged this pull request with Graphite.

[sentry]

Bug: A type cast from CallToolResult to ToolResponse causes toolResponseToDaemonResult to corrupt structured text output and silently discard image content from Xcode IDE tools.
_{Severity: HIGH}

Suggested Fix

Update toolResponseToDaemonResult to correctly handle a CallToolResult object. This involves adding logic to process its content array, properly handling both text and image items without wrapping them in statusLine events, and removing the incorrect type cast as ToolResponse in daemon-server.ts.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: src/daemon/daemon-server.ts#L229-L234

Potential issue: A type mismatch occurs when invoking Xcode IDE tools through the
daemon. The `invokeTool` function returns a `CallToolResult`, but this is incorrectly
cast to a `ToolResponse`. This triggers fallback logic in `toolResponseToDaemonResult`
that is not designed for this type. As a result, any structured text output (like JSON)
is corrupted by being wrapped in status line events, and any image content returned by
the tool is silently discarded. This affects all Xcode IDE tools that return structured
data or images when invoked via the CLI daemon.

[sentry]

Bug: When using --output raw, the tool's output is buffered but never written to stdout because the result of session.finalize() is discarded. Subprocess output is sent to stderr instead.
_{Severity: HIGH}

Suggested Fix

Capture the return value of session.finalize() and write its contents to process.stdout. This will ensure that the buffered raw output is correctly emitted, aligning its behavior with other output formats like json and text.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: src/utils/command.ts#L79-L82

Potential issue: When a command is run with the `--output raw` flag, the tool's output
is not written to stdout as expected. The code creates a text render session that
buffers the output, but the final result from `session.finalize()` is discarded. While
subprocess output is redirected to stderr due to the `XCODEBUILDMCP_VERBOSE=1` flag, the
primary tool output is lost. This prevents users from piping the raw output to other
commands or using it in scripts, as stdout will be empty.