`claude-ui-tool-config.test.ts` defines `runParserScript` (lines 45–62) which calls `spawn('python3', args, ...)` and invokes it at line 665 against the on-disk `benchmarks/claude-ui/parse_claude_conversation.py`, asserting on real filesystem output (`readdir`, `readFile`). This violates the unit-test guardrail that external processes/filesystem dependencies must be injected/mocked rather than executed for real. The test depends on a `python3` interpreter being installed on the host, unlike the sibling new tests (e.g. `first-run-preflight.test.ts`, `simulator-lifecycle.test.ts`) which correctly inject a `LifecycleCommandExecutor` mock.

If a `tool_result` block has no `content` field, `JSON.stringify(undefined)` returns `undefined` at runtime (not a string), making `message.length` on the next line throw a `TypeError`. Consider defaulting: `stringifyContent(block.content ?? '')`

If the overall `timeoutMs` fires while the `terminalJsonResultGraceMs` grace timer is still running (i.e., Claude emitted a `result` record before the deadline but cleanup hadn't finished), `timedOut` is set to `true` and the resolved exit code is hard-coded to 143 — discarding `terminalResultExitCode` that was already recorded. A task that completed before the timeout is then reported as timed out.

When a Bash command contains a tracked prefix multiple times (e.g. `xcodebuild build && xcodebuild test`), `classifyBashCommandTool` returns one `ToolClassification` per occurrence; if the tool result errors, the loop `for (const trackedTool of trackedTools)` pushes a separate failure record for each classification, inflating `audit.failures.length` used by `countCompletionIssues`.