RL-026 Optional Spark with local Windows voice

Observation

The paid Realtime connection failed with HTTP 429. User asked to use their Spark subscription allowance, then: “okay add that as another option”. Existing voice supports only Realtime; existing optimizer tests use a fake process, not Spark.

Hypotheses

• H1: Explicit provider selection can preserve Realtime while Spark receives bounded text through ChatGPT-authenticated Codex, never an API-key fallback.
• H2: Windows in-process recognition and synthesis can keep audio local, with cancellation releasing the helper and rejecting late results.
• H3: Spark proposals update only the revision-checked canvas; conversation changes, interruption and manual edits cannot apply stale proposals or start builds.

Intervention

Added a second opt-in connection, fixed native Windows speech helper, bounded Spark planning adapter and tests. ChatGPT-only CLI authentication, disabled action features and read-only sandboxing; validated JSON proposals use the existing revision-checked canvas and exact build review. No dependencies, model-controlled commands or automatic paid fallback. Low-confidence recognition holds the whole pending thought for correction, including subsequent fragments. Local speech pauses recognition during synthesis and supports explicit button interruption, not spoken barge-in.

Method

Baseline: existing voice has no provider choice. Run new targeted regression before implementation, then the same instrument after; full unit/type/build and Electron fixture checks. Native probe does not access microphone. Any live Spark experiment is explicitly labelled separately from synthetic output.

Results

757/757 tests, typecheck and build pass. Seven Spark Electron fixture checks and nine existing Realtime fixture checks pass. These use real host/preload/SQLite paths but synthetic model and microphone transports. Installed native engines were probed and an in-memory synthesis-to-recognition test recovered all three short phrases, with low confidence on two; no microphone was accessed.

One live GPT-5.3-Codex-Spark text request completed in 4,762 ms through existing ChatGPT sign-in, with eight cards and preserved constraint titles. Its initial assertion incorrectly required the literal phrase “no accounts”, rejecting “No user accounts”. The instrument was corrected and the saved response passed replay; no second model call was made. This is not a latency benchmark or reliability rate. Full prompt, processed reply and original failed assertion remain in the evidence directory.

Threats to validity

Offline Windows recognition is not equivalent to neural speech-to-speech: language availability, accents, pauses, and interruption quality require live user audio. Synthetic tests cannot prove those qualities.

Conclusion

H1 and H3 are supported by deterministic integration checks; one live call supports subscription-authenticated Spark text transport only. H2 has native synthetic-audio and lifecycle fixture evidence, not real microphone evidence. This adds a usable option, not equivalent fluidity or accuracy to Realtime. CLI has no documented server-side output-token cap; timeout/output limits are application backstops, not fixed-cost guarantees.

Follow-ups

Measure real voice accuracy and latency with complex instructions; keep exact corrections visible for review.

Reproduce

Run npm test, npm run typecheck, npm run build, npm run check:voice:spark, npm run check:voice, and node scripts/check-local-speech.mjs. Replay the saved live result with node scripts/check-spark-live.mjs --replay; only an explicitly supplied --live makes another allowance-consuming request. See evidence record for scope and failures.