Automation testing for desktop application, watched live over a pipe

Browser tests talk to a headless Chromium in the same process tree. Playwright hands you an internal events API (test.beforeEach, reporter, onStepBegin) and the reporter runs in the same node process. Desktop test runs do not get that for free. The test process drives Win32 UI via UIAutomation, which lives in a separate COM service; the test framework is a second process; and if an AI coding assistant is watching over MCP, that is a third boundary. Stdout and stderr become the lowest common denominator, which is why most desktop test tools end up with a reporter plugin that scrapes lines. Terminator replaces that scraping surface with a dedicated Windows Named Pipe per execution and a JSON line protocol tagged __mcp_event__:true. The pipe is created by the Rust MCP agent on the fly, its path is handed to the test child via the MCP_EVENT_PIPE_PATH env var, and the test emits with a tiny helper from @mediar-ai/terminator. That is the design choice the other playbooks skip.

The string "__mcp_event__":true as a required field on the JSON object, deserialized into the is_mcp_event bool on the RawEvent struct at lines 106 and 143 of event_pipe.rs. try_parse_event at line 207 first rejects anything that does not start with {, then deserializes, then rejects anything where is_mcp_event is false. Only survivors reach the WorkflowEvent::try_from conversion at line 139 and become typed events. Plain console.log output stays stdout, gets forwarded as log_pipe.rs LogEntry records, and ends up in the tracing subscriber at a normal log level. The two pathways never mix. That is how the pipe stays free of structured noise even when the test is chatty.

generate_pipe_name at line 243 of event_pipe.rs formats the full pipe path as \\.\pipe\mcp-workflow-events-{execution_id}, where execution_id is a UUID-shaped string the Rust agent allocates when execute_sequence is invoked. That string is unique per run, so two concurrent runs get two distinct pipe names. The server-side ServerOptions call at line 277 sets first_pipe_instance(true), which on Windows makes it an error for a second writer to attach to the same name. Combined, those two decisions make the pipe a single-writer, single-reader channel scoped to exactly one workflow. No mutex, no reference counting, no cleanup worker. When the child process exits and its end of the pipe closes, the reader loop breaks on next_line returning Ok(None) and the whole server tears down with its PipeServerHandle.

Eight. Defined as the WorkflowEvent enum at lines 30-101 of event_pipe.rs: Progress, StepStarted, StepCompleted, StepFailed, Screenshot, Data, Status, Log. The mapping from event_type strings to enum variants lives in WorkflowEvent::try_from at line 139 ('progress', 'step_started', 'step_completed', 'step_failed', 'screenshot', 'data', 'status', 'log'). Adding a new variant is a three-line change: add the enum variant, add the matching string arm in try_from, and re-expose it on the emit helper. There is no versioning; the pipe is consumed by the same repo that produces it, and MCP itself does not require a stable event catalog beyond the notifications it already spells out.

Progress events map straight to MCP notifications/progress on the outer tool call's progress token. The JSON payload already carries current, total, and message, which is the exact shape the protocol expects. Step lifecycle events (StepStarted, StepCompleted, StepFailed) and Log events with error level map to notifications/message with matching level fields. The screenshot variant is more flexible: it can be streamed as an in-flight notifications/message with an embedded image resource, or held for the final CallToolResult.structuredContent depending on the client's declared capabilities. That negotiation happens on the agent side, which means a test run does not need to know whether the client can render images mid-call; the pipe protocol stays flat.

It replaces them for the in-flight phase. Post-mortem JUnit XML is still the right format for external CI systems like GitHub Actions or Buildkite that expect a well-known file path at the end of the run. The pattern is to write a small sink on top of the event stream: keep a buffer of StepStarted/StepCompleted/StepFailed records per stepId, render them to testsuite XML at the end. That sink lives in 100 lines of Rust or TypeScript and does not need to be a vendor plugin. The advantage of the Terminator approach is that the sink is optional. The AI coding assistant gets live feedback directly from the event pipe; the CI adapter is just one more consumer of the same stream.

Nothing breaks. The agent checks the peer's declared capabilities at initialization. If notifications/progress is not supported, it downgrades Progress events to notifications/message at info level, which every MCP client accepts. Screenshot events without image-resource support become log entries that reference the path. The test itself never sees that negotiation: emit.progress() and emit.screenshot() both write the same JSON line regardless. You do not branch your test code on client capability; the Rust agent does it once at the transport edge.

Yes, the pipe is language-agnostic. Any program that can open a named pipe on Windows and write newline-delimited JSON with the __mcp_event__:true tag can be a producer. That includes Python (pywin32), PowerShell (System.IO.Pipes), Go (winio/npipe), or a C# NUnit test running via dotnet. The env-var handshake (MCP_EVENT_PIPE_PATH) is the only coordination needed. If you are bridging an existing test framework (TestComplete, Ranorex, pywinauto) into an MCP-driven AI assistant, writing a small adapter that forwards the framework's native hooks to the pipe is usually under a hundred lines. The source of truth for the wire format is the RawEvent struct in event_pipe.rs and its try_from at line 139.

Yes, for two reasons. First, the same pipe protocol and execution_logger.rs combination gives you a clean per-step replay artifact on disk: a .json record, a regenerated .ts snippet, and a .png screenshot, all correlated by execution_id, all under %LOCALAPPDATA%\mediar\executions\ with 7-day retention. That is a post-mortem debugging primitive even if you never attach a live consumer. Second, forward_log_to_tracing in log_pipe.rs writes your test's console output to the Rust tracing subscriber at the correct level, which means you get structured logging out of plain console.log calls. Both behaviors kick in the moment you run your test through the MCP agent, even if you immediately disconnect the MCP client.

crates/terminator-mcp-agent/src/event_pipe.rs, 866 lines, MIT licensed. The tests at the bottom of the file (#[cfg(test)] mod tests, lines 361 onward) round-trip the eight event types against the exact JSON shape the emit helper produces. Run cargo test -p terminator-mcp-agent event_pipe to see them pass. The companion file, crates/terminator-mcp-agent/src/log_pipe.rs, 458 lines, handles the structured logging half of the same architecture. Both files are small enough to read in under thirty minutes end-to-end. The integration into the main server is in main.rs and server_sequence.rs where execute_sequence_impl creates the pipe server, attaches it to the child process, and drains events into the MCP transport.