Queued Directions — Response-Length Discipline + Voice-Out — v0_1

Version. 0.1 Date. 2026-06-29 Status. Queued — not scoped. Sequenced after Memory-room Findings 1–3 (CR-2026-120, CR-2026-122, and the Finding-3 false-success pass) are merged and verified. Origin. Operator question, 2026-06-29: "Is it worth adding text-to-speech for responses? Some responses are too long, but for a quick question it may be useful."

Two directions, separated

The TTS question surfaced two distinct things. They are filed together because they are sequenced together (one depends on the other), but they are separate pieces of work.

Direction A — Response-length discipline (the real issue behind the question)

The Operator observed responses are too long. TTS does not fix this — it worsens it (a long response is slower and unskimmable as speech). The fix is making the Companion concise: short answers to short questions, long form only when asked.

Key design question to ground before scoping: prompt vs structural. "Be concise" as prompt guidance loses to model priors over a long conversation (per the seed's "correctness in code, not prompts" and the Operator's standing principle). Check whether conciseness can be made structural — e.g. short-answer intents return short server-composed replies, the way the held-tray motions (CR-2026-122) return composed confirmations — rather than a prompt plea for brevity. The difference is "concise most of the time" vs "reliably concise."

Value on its own merits: improves the current text experience immediately, independent of voice. Worth doing whether or not voice-out ever ships.

Direction B — Voice-out (TTS), for the short-answer case

Voice output, paired with the already-shipped voice input (mic in the navigation bar, voice-listening-v0_1), closes an eyes-free loop: voice-in → short answer → voice-out. The valuable case is the quick factual, hands-busy moment ("when did I last water Fenwick?") — a one-line spoken answer beats picking up the phone to read.

Scope when reached: voice-out for short replies specifically. Likely toggle-able or length-gated (speak short replies; do not auto-speak long ones) — which sidesteps the "long response read aloud" problem by construction.

Why sequenced after Room 1 (the dependency reasoning)

1. **Voice-out makes a working Companion nicer; it makes a broken one broken out loud.** Mid-repair, the Companion can't reliably save a note, can't view Companion-authored memory (the 422), and says "Logged" when nothing logged. TTS on top of that voices the failures. The loop must be trustworthy first (CR-2026-120, CR-2026-122).

1. Length-discipline (A) is the precondition for voice-out (B) being usable. Spoken-back long responses are unusable; voice-out only works if responses are already short. So A before B, and both after the loop.

Sequence: Room-1 loop fixes (correct) → response-length discipline (concise) → voice-out (spoken). Correct, then pleasant.

Not yet decided / to ground when picked up

• A: is conciseness achievable structurally (server-composed short replies per intent) or only via prompt? Ground before scoping.
• B: toggle vs length-gated auto-speak; which TTS path (engine-side synthesis vs client/browser speech API); whether it reuses any infra from the voice-input shipment.
• Both: confirm against the seed's voice/surface commitments before scoping (the seed governs the Operator-facing surface; check it does not constrain or already speak to voice-out).