Measure cross-process Bridge admission across concurrent terminal MCP clients

[deverman]

Parent context

• Bound concurrent Bridge dispatch to prevent parallel MCP timeouts #170 / Bound concurrent Bridge dispatch #179 established one process-wide FIFO Bridge lane: one request runs,
  six may queue, and excess or expired work receives a structured retryable
  error.
• Add a direct MCP concurrent Bridge burst harness #176 / Add direct MCP Bridge burst harness #177 added the direct MCP burst harness, but its contract deliberately
  launches one stdio server process.
• Exit the stdio server when its MCP client disconnects #187 / Exit stdio server when MCP client disconnects #190 made one FocusRelay process exit when its client closes stdin.
• Spike: revisit multi-host transport decision — TCC diagnosis and Developer ID signing feasibility #196 owns the separate Desktop-host/TCC transport decision.
• Clarify the IPC spec's cross-process admission contract #217 owns the docs-only correction to the current IPC contract wording.

User outcome

Maintainers can determine whether several supported terminal MCP clients on one
Mac overload the shared OmniFocus Bridge path, rather than assuming that a
per-process admission lane also coordinates separate FocusRelay processes.

Validation impact

performance — this adds developer-only measurement coverage and sanitized
evidence. It does not change production admission, IPC, queries, mutations, or
the supported client surface.

User-facing acceptance journey

1. A maintainer installs the current Bridge plug-in and restarts OmniFocus once.
2. The maintainer runs the exact release FocusRelay binary with one, two, and
   four independent stdio server processes.
3. Every process completes MCP initialization, then all processes issue one
   synchronized read or mutation preview against the same ready OmniFocus
   session.
4. The harness reports only aggregate success, error, timeout, pickup-state,
   process-exit, and latency evidence.
5. The result either closes the cross-process concern with evidence or provides
   a reproduction for a separate transport-reliability product issue.

Current evidence and uncertainty

• BridgeRuntime.shared is shared only by service instances in one executable
  process. Its one-running/six-queued policy therefore multiplies when several
  MCP clients each launch focusrelay serve.
• The current bridge-burst harness launches one server process and cannot
  measure that multiplication.
• The file protocol uses UUID request, response, and lock paths, and the URL
  trigger carries the request ID directly. OmniFocus may naturally serialize
  URL actions, but FocusRelay has no checked-in cross-process evidence proving
  reliability or latency under that load.
• Design discussion: how should omnifocus-mcp behave when N agents on one machine share OmniFocus? (process accumulation + AppleEvent contention) themotionmachine/OmniFocus-MCP#80 observed real multi-agent AppleEvent
  contention in a different architecture. PR Kaizen: speed up validation and release flow #96 solved it with a shared Unix
  socket daemon. That is a useful hypothesis, not evidence that FocusRelay's
  plug-in URL path has the same failure.

Bounded implementation

Extend the developer-only focusrelay-dev bridge-burst command with an explicit
--server-count option:

• accepted values: 1, 2, or 4;
• default: 1, preserving the existing single-process behavior and artifacts;
• when greater than one, launch that many copies of the selected
  --server-path, initialize every copy, then issue exactly one synchronized
  scenario request per process;
• support the existing task-counts and completion-preview scenarios;
• completion-preview remains preview-only and requires
  --fixture-task-id;
• correlate responses within each process and terminate every child on success,
  failure, cancellation, or timeout;
• do not add an automatic retry or hide a failed/stranded child by replacing it.

Record serverCount in the sanitized summary along with aggregate:

• success, MCP tool error, protocol error, process exit, and timeout counts;
• p50, p95, maximum request latency, and whole-wave elapsed time;
• Bridge pickup-state classifications when FocusRelay already exposes them;
• exact server binary hash, production fingerprint, scenario, profile, and
  response deadline.

Do not persist raw MCP arguments or responses, OmniFocus IDs, names, notes,
paths, or process command lines.

Deterministic tests

Use Swift Testing and injected fake subprocess/transports to cover:

• one, two, and four server startup and initialize-before-call ordering;
• synchronized one-request-per-process dispatch;
• response IDs correlated independently when different processes reuse the same
  JSON-RPC request ID;
• one child error, timeout, or early exit does not strand the others;
• cancellation and every failure path terminate all owned children;
• serverCount and aggregate classifications appear in the artifact;
• the default single-process output remains backward compatible;
• no raw response, fixture ID, private path, or process command leaks into
  output or artifacts.

Live diagnostic

1. Install the Bridge only with ./scripts/install-plugin.sh.
2. Fully restart OmniFocus once at the beginning of the session.
3. Run health and semantic gates against that same ready session.
4. Build one release binary and run canary for both scenarios with
   --server-count 1, 2, and 4.
5. Keep artifacts under .build/benchmarks and publish only sanitized
   aggregates.

Decision rule:

• If all runs remain correct with no errors/timeouts/stranded dispatch and no
  material user-relevant tail regression, close this issue without production
  architecture work.
• If a repeatable reliability or latency failure appears only as process count
  increases, file a separate transport-reliability issue for the smallest
  proven fix. Do not select a daemon, broker, lock, or retry policy in this
  diagnostic issue.

Acceptance criteria

• bridge-burst --server-count 1|2|4 exercises independent real stdio server
  processes with one synchronized request per process.
• Both task-count and completion-preview scenarios are covered without live
  writes.
• Deterministic lifecycle, failure, artifact, and privacy tests pass.
• One live same-session canary matrix is recorded for the exact release
  binary and installed Bridge.
• The issue ends with an explicit no-change verdict or a linked reproduction
  and separately scoped product issue.

Non-goals

• Cross-process admission or locking
• A daemon, LaunchAgent, Unix socket, or alternate MCP transport
• Desktop-host/TCC enablement
• Query optimization, cache sharing, mutation changes, or automatic retries
• Running release or stress profiles for an unproven diagnostic question

[deverman]

Roadmap status: parked and evidence-gated

#218 now documents truthfully that admission control is process-local. This diagnostic remains unmilestoned until a supported multi-client journey produces a repeatable reliability or latency problem. Do not build a multi-process harness merely to investigate a latent risk; reopen active work from a sanitized reproduction or a release requirement that actually needs concurrent terminal clients.