Raise autotune process timeout from 30s to 7260s (2h1m)

[Augustas11]

Summary

Raise AutotuneRecommendationRunner.processTimeout from 30s to 7260s (2h1m) so fresh-install onboarding actually reaches .live on real hardware.

Root cause: The 30s value in AutotuneRecommendationRunner.swift was ~240× too short. Every fresh-install v1.8.3 smoke on this Mac hit AutotuneRecommendationError.timedOut at T+30s while autotune was still spawning MLX probes. Autotune runs Stage-1 benchmarks against every non-blocked, RAM-eligible catalog row — each candidate takes up to 720s (readyTimeout 120s + prewarm probe 300s + measured probe 300s per SPEC-023 v1.7.5), catalog cardinality scales with Mac tier, and the CLI --recommend path does NOT enforce its own declared maxDuration=7200s. So the App-side timeout IS the authoritative ceiling for autotune runtime.

Value: 7260s = realistic worst-case autotune (10 candidates × 720s = 7200s) + 60s grace. Below 2.5h untenable-spinner ceiling. Median UX unaffected (empirical: 2-5 min).

Files

• phase3-binary/app/Sources/Malibu/Onboarding/AutotuneRecommendationRunner.swift — bump processTimeout 30→7260s, visibility private static→static so tests can pin the invariant, rewrite rationale comment with 4 numbered reasons for the value and the honest note that the CLI --recommend path doesn't enforce its own maxDuration.
• phase3-binary/app/Tests/MalibuTests/AutotuneRecommendationRunnerTimeoutTests.swift — new test file, 2 tests pinning: (1) processTimeout ≥ realisticWorstCaseAutotuneSec (7200s); (2) processTimeout ≤ untenableSpinnerCeilingSec (2.5h).
• specs/AUDIT_FIX_AUTOTUNE_TIMEOUT_{COMMON,CODE,SECURITY,ARCHITECT}_PROMPT.md — 3-lane codex audit prompts kept in-tree for future reference and R2-R5 convergence history.

Audit convergence (5 rounds, R5 final)

Round	Lane	Verdict	Findings
R1	SEC	READY	L=1 (unbounded stdout buffer, still LOW at final 7260s per R5)
R1	ARCH	READY	L=1 (obsoleted by R2+ test rewrite)
R1	CODE	NEEDS REVISION	M-1: per-candidate math missed prewarm probeOnce step
R2	CODE	NEEDS REVISION	M-1: candidate count is not fixed at 2-3, --recommend iterates all non-blocked RAM-eligible rows; M-2: pre-existing CLI-side orphan-child bug (deferred, see below)
R3	CODE	NEEDS REVISION	M-1: rationale claimed 7260s "mirrors CLI cap", but --recommend doesn't enforce maxDuration
R4	CODE	READY	L=1 (wording typo, fixed)
R5	CODE	READY	0/0/0/0
R5	SEC	READY	L=1 (SEC-L-1 unbounded stdout buffer, see below)
R5	ARCH	READY	L=3 (ARCH-L-1/2/3, see below)

All CRITICAL / HIGH / MEDIUM findings converged to zero.

LOW findings — documented, deferred

Per project convention: LOWs ship with PR-body docs.

• SEC-L-1 — ProcessOutputBuffer at AutotuneRecommendationRunner.swift:33-50 is unbounded. Realistic autotune stdout is single-digit MB (per-probe JSON + final result). Would need a compromised/spoofed CLI to matter. Local DoS/OOM only.
• ARCH-L-1 — CLI --recommend path at phase3-binary/Sources/macprovider-cli/AutotuneCommand.swift:131-139 does NOT enforce declared maxDuration=7200s (deadline is only installed in non-recommend at :157-161). CLI-side fix belongs in a follow-up PR.
• ARCH-L-2 — 10-candidate floor in the App test is a defensible current-policy assumption, not a real enforced catalog upper bound. If the catalog ever admits >10 candidates on some Mac tier, this timeout gets tight; heartbeat protocol becomes necessary before that point.
• ARCH-L-3 — AutotuneRecommendationError.timedOut copy is generic. At 2h1m, human failure copy per SPEC-026 §6.4 should convey the wait was long. Follow-up.

Deferred to CLI-side follow-up

• R2 CODE-M-2 — Orphan child macprovider-cli serve subprocess when App-side timeout fires. Stage1Prober spawns the serve child at Stage1Iterator.swift:436-442 and relies on defer { runner.stop(...) } (:443-445). The CLI --recommend path does NOT install signal handlers (only non-recommend does at AutotuneCommand.swift:157-161), so process.terminate() from the App kills the parent CLI without giving Stage1Prober a cleanup path. The child leaks and can hold port 18080 + model memory. This is a pre-existing CLI-side bug that exists at any App-side timeout value ≥ 0; not introduced by this PR. Fix belongs in phase3-binary/Sources/macprovider-cli/AutotuneCommand.swift to install signal handlers on the recommend path.

Test plan

• MalibuTests: 91/91 pass locally (xcodebuild -project Malibu.xcodeproj -scheme MalibuTests test)
• 3-lane codex audit converged to 0 CRITICAL / 0 HIGH / 0 MEDIUM across all lanes
• Post-merge: bump binaryVersion 1.8.3 → 1.8.4, dispatch v1.8.4 prerelease
• Post-merge: clean-slate install v1.8.4 on this Mac, drive Malibu.app onboarding through the state machine, verify .live end-to-end

🤖 Generated with Claude Code

[antfleet-ops]

Autotune timeout fix. 5 rounds of 3-lane codex audit; all lanes converged 0 C/H/M. LOWs documented. R2 CODE-M-2 orphan child correctly deferred to CLI-side follow-up. Approved.