The four `MAC_OS_X_*` host-OS build-settings keys (`MAC_OS_X_PRODUCT_BUILD_VERSION`, `MAC_OS_X_VERSION_ACTUAL`, `MAC_OS_X_VERSION_MAJOR`, `MAC_OS_X_VERSION_MINOR`) are hardcoded with runtime-specific values (`25D2128`, `260301`, `260000`, `260300`) in the fixture instead of being normalized in code — any macOS update on the CI runner will break these snapshots. Add them to `normalizeBuildSettingsEntryValue` in `json-normalize.ts` (parallel to `SDK_PRODUCT_BUILD_VERSION`→`<SDK_BUILD_VERSION>` / `SDK_VERSION_*`→`<SDK_VERSION>`) and add the corresponding regex to `normalize.ts` for text fixtures, then regenerate all four affected surfaces.

The four `MAC_OS_X_*` host-OS build-settings keys (`MAC_OS_X_PRODUCT_BUILD_VERSION`, `MAC_OS_X_VERSION_ACTUAL`, `MAC_OS_X_VERSION_MAJOR`, `MAC_OS_X_VERSION_MINOR`) are hardcoded with runtime-specific values (`25D2128`, `260301`, `260000`, `260300`) in the fixture instead of being normalized in code — any macOS update on the CI runner will break these snapshots. Add them to `normalizeBuildSettingsEntryValue` in `json-normalize.ts` (parallel to `SDK_PRODUCT_BUILD_VERSION`→`<SDK_BUILD_VERSION>` / `SDK_VERSION_*`→`<SDK_VERSION>`) and add the corresponding regex to `normalize.ts` for text fixtures, then regenerate all four affected surfaces.

The four `MAC_OS_X_*` host-OS build-settings keys (`MAC_OS_X_PRODUCT_BUILD_VERSION`, `MAC_OS_X_VERSION_ACTUAL`, `MAC_OS_X_VERSION_MAJOR`, `MAC_OS_X_VERSION_MINOR`) are hardcoded with runtime-specific values (`25D2128`, `260301`, `260000`, `260300`) in the fixture instead of being normalized in code — any macOS update on the CI runner will break these snapshots. Add them to `normalizeBuildSettingsEntryValue` in `json-normalize.ts` (parallel to `SDK_PRODUCT_BUILD_VERSION`→`<SDK_BUILD_VERSION>` / `SDK_VERSION_*`→`<SDK_VERSION>`) and add the corresponding regex to `normalize.ts` for text fixtures, then regenerate all four affected surfaces.

The four `MAC_OS_X_*` host-OS build-settings keys (`MAC_OS_X_PRODUCT_BUILD_VERSION`, `MAC_OS_X_VERSION_ACTUAL`, `MAC_OS_X_VERSION_MAJOR`, `MAC_OS_X_VERSION_MINOR`) are hardcoded with runtime-specific values (`25D2128`, `260301`, `260000`, `260300`) in the fixture instead of being normalized in code — any macOS update on the CI runner will break these snapshots. Add them to `normalizeBuildSettingsEntryValue` in `json-normalize.ts` (parallel to `SDK_PRODUCT_BUILD_VERSION`→`<SDK_BUILD_VERSION>` / `SDK_VERSION_*`→`<SDK_VERSION>`) and add the corresponding regex to `normalize.ts` for text fixtures, then regenerate all four affected surfaces.

The four `MAC_OS_X_*` host-OS build-settings keys (`MAC_OS_X_PRODUCT_BUILD_VERSION`, `MAC_OS_X_VERSION_ACTUAL`, `MAC_OS_X_VERSION_MAJOR`, `MAC_OS_X_VERSION_MINOR`) are hardcoded with runtime-specific values (`25D2128`, `260301`, `260000`, `260300`) in the fixture instead of being normalized in code — any macOS update on the CI runner will break these snapshots. Add them to `normalizeBuildSettingsEntryValue` in `json-normalize.ts` (parallel to `SDK_PRODUCT_BUILD_VERSION`→`<SDK_BUILD_VERSION>` / `SDK_VERSION_*`→`<SDK_VERSION>`) and add the corresponding regex to `normalize.ts` for text fixtures, then regenerate all four affected surfaces.

Cannot retrieve the full diff because there are too many (300) changed files in the pull request.

Cannot retrieve the full diff because there are too many (300) changed files in the pull request.

Cannot retrieve the full diff because there are too many (300) changed files in the pull request.

The `frame` objects in this fixture (e.g. lines 21–26) appear in expanded multi-line form because `compactFrameObjects` in `json-normalize.ts` matches `"x"` before `"y"`, but `JSON.stringify` serialises the actual data with `"y"` first — the regex never fires, silently defeating the intended compact format.

The `nextSteps` array is absent from this MCP JSON fixture while the parallel MCP text fixture (`mcp/text/swift-package/run--success.txt`) explicitly records `"Stop Swift package run: swift_package_stop()"`, and every other MCP JSON build-run-result success fixture (`simulator/build-and-run`, `macos/build-and-run`, `device/build-and-run`) carries a `nextSteps` field at the envelope root. This misalignment leaves the JSON contract understating what the runtime actually emits.

The `nextSteps` array is absent from this MCP JSON fixture while the parallel MCP text fixture (`mcp/text/swift-package/run--success.txt`) explicitly records `"Stop Swift package run: swift_package_stop()"`, and every other MCP JSON build-run-result success fixture (`simulator/build-and-run`, `macos/build-and-run`, `device/build-and-run`) carries a `nextSteps` field at the envelope root. This misalignment leaves the JSON contract understating what the runtime actually emits.

The `nextSteps` array is absent from this MCP JSON fixture while the parallel MCP text fixture (`mcp/text/swift-package/run--success.txt`) explicitly records `"Stop Swift package run: swift_package_stop()"`, and every other MCP JSON build-run-result success fixture (`simulator/build-and-run`, `macos/build-and-run`, `device/build-and-run`) carries a `nextSteps` field at the envelope root. This misalignment leaves the JSON contract understating what the runtime actually emits.

The new `mcp/json/utilities/clean--success.json` is byte-for-byte identical to `cli/json/utilities/clean--success.json`, but for all build operations the MCP JSON fixture omits `data.request` that the CLI JSON fixture includes — and the text fixtures for clean correctly show this same minimal-vs-normal split. If the runtime applies surface differentiation to clean's JSON output (as it does for builds), the MCP fixture should reflect that; if not, the envelope's `data.artifacts` is misclassifying input parameters (workspacePath, scheme, configuration, platform) as output artifacts rather than omitting them on the minimal (MCP) surface.

This new `cli/json` fixture locks in `nextSteps` as a required field of the `xcodebuildmcp.output.simulator-list` envelope and advances `schemaVersion` to `"2"`; any consumers parsing the structured envelope by schema or version must be updated, and the fixture itself must be deliberately regenerated when the next-step copy changes.

`JSON.parse(text)` on line 22 operates on `formatStructuredEnvelopeFixture` output, which replaces every `processId` with `99999` (see `json-normalize.ts` line 53). The loop will always try to stop PID 99999, fail silently (no such process), then loop forever since `activeProcesses` still holds the real PIDs. Use `structuredEnvelope.data.processes` instead — it carries the unnormalized envelope.

The `schemaVersion` change from `'1'` to `'2'` is a breaking change for any downstream consumer that validates or discriminates on the schema version field — they will now receive `"2"` where they expected `"1"`. Have you considered publishing a migration guide or changelog entry for integrators?

The `schemaVersion` change from `'1'` to `'2'` is a breaking change for any downstream consumer that validates or discriminates on the schema version field — they will now receive `"2"` where they expected `"1"`. Have you considered publishing a migration guide or changelog entry for integrators?

The `schemaVersion` change from `'1'` to `'2'` is a breaking change for any downstream consumer that validates or discriminates on the schema version field — they will now receive `"2"` where they expected `"1"`. Have you considered publishing a migration guide or changelog entry for integrators?