The testFailures array is reordered to put MCPTestTests before MCPTestsXCTests, but normalizeDiagnosticTestFailures sorts by suite|test|location via localeCompare, which orders MCPTestsXCTests first — so this fixture will not match generated output.

The CLI fixture now reports the test-owned <TMPDIR>/DerivedData/... app path, but mcp/json/macos/get-app-path--success.json still contains the old workspace-managed ~/Library/Developer/XcodeBuildMCP/workspaces/XcodeBuildMCP-<HASH>/DerivedData/MCPTest-<HASH>/... path, so the MCP and CLI JSON fixtures are inconsistent.

Also found at:

• src/snapshot-tests/__fixtures__/cli/json/simulator/build--success.json:28
• src/snapshot-tests/__fixtures__/cli/text/device/install--success.txt:5
• src/snapshot-tests/__fixtures__/cli/text/device/test--success.txt:8
• src/snapshot-tests/__fixtures__/cli/text/simulator/install--success.txt:5
• src/snapshot-tests/__fixtures__/cli/text/swift-package/build--error-bad-path.txt:8

The device test text fixtures advertise a Test Products: ...xctestproducts artifact line, but neither cli/json/device/test--success.json nor mcp/json/device/test--success.json include a corresponding testProductsPath in data.artifacts, leaving the structured envelope out of sync with the text output and with the equivalent simulator JSON fixture. Both renderings derive from the same createXcodebuildTestArtifacts domain result (src/utils/test-common.ts), which populates testProductsPath in the default two-phase test flow, so the device JSON fixtures are stale.

Also found at:

• src/snapshot-tests/__fixtures__/mcp/json/macos/test--success.json:20

The e2e discovery smoke test asserts build_sim advertises xcodebuildmcp.output.build-result version '2', but this manifest now advertises version '3', so the toEqual assertion will fail.

This debugging fixture drops a previously-recorded breakpoint listing (ContentView.swift:42) and replaces it with No breakpoints currently set., a content change unrelated to the PR's prepared-test-artifacts feature. The new content is consistent with the test as written (it attaches and runs breakpoint list without adding a breakpoint), so it is likely a legitimate re-record rather than a re-record purely to make tests pass — but it should still be confirmed as an intentional, documented change since it falls outside the PR's stated scope.

The test 'normalizes Settings.app compact capture refs without hiding capture content' is meant to prove that the count under settingsCapture/appCapture is passed through unchanged (unlike the count under a capture object, which is normalized to 99999). By setting both the raw input and the expected count to 99999 — the exact normalizer sentinel — the assertion no longer distinguishes preserved values from normalized ones: a regression that started normalizing these counts to 99999 would still pass. Use distinct non-sentinel values (e.g. 144 and 19) for input and expected so the assertion fails if normalization is ever applied to compact-capture counts.

This test early-returns (with no assertion) whenever the working directory is not under /private/tmp/, so it passes vacuously on Linux CI and typical dev machines, providing no real coverage of the alias normalization; assert against an injected/constructed path or use it.skip with a clear condition instead of a silent return.