# OPEN QUESTIONS — DESIGN ROUND 3
**Disagreements with Spec v4, stated sharply, with alternatives · July 7, 2026**
**Resolved by Moto, same day — all six adopted, one with a stated caveat (#2). Resolution under each item; folded into UX-SPEC-R3.md, MOTION-ADDENDUM.md, and REALM-EXPRESSION.md.**

---

## 1. The live transcript will make voice feel like dictation. Ship voice-first sessions with a *folded* transcript.

v4 §1 says voice and text land in one thread with one memory — right — and the R3 screens render the transcript live into the thread. But watch anyone talk to a screen that echoes their words: they start speaking *to the transcript*, self-correcting, slowing down. The live echo turns conversation into dictation review.

**Alternative:** during a voice session, the thread shows only **settled turns** (utterance-complete bubbles), and the in-flight words render *in the voice band itself* — small, peripheral, at the composer, not in the thread. The thread stays a record; the band stays the conversation. Same memory, same artifact, different attention geometry. The current mockups (§2) can be read either way; I recommend the fold and have drawn the forming bubble as peripheral as the thread placement allows.

**Resolution — Moto, July 7:** Adopted. This is probably the strongest point in the review. Voice mode should feel like a conversation with your ally, not a transcript you're managing — live echo teaches people to talk to the screen instead of to her. Fold it: only settled turns land in the thread, in-flight words stay in the band. The transcript is the record; the band is the conversation.

## 2. "At least four fuller UIs" is one fuller UI too many: the record browser shouldn't exist.

v4 §2 lists the record/wisdom view among the fuller UIs, and R2 already established "the record is asked, never browsed." A browsing surface — however chip-refined — is a search results page, and a search results page trains *going somewhere to look*, which is the paradigm we killed. In six months it will have grown filters.

**Alternative:** the record's fuller view should be only ever **the answer, expanded** — the ally's cited sentence with its supporting artifacts unfolded beneath, refinable by saying so. That is what screen §8 draws (no query field, chips in the ally's voice), but I want the disagreement on the record: if usage data ever shows members opening the record view *without a question*, the right fix is a better Renderer, not a better browser. Same argument as R2's Vigil Disagreement 4.

**Resolution — Moto, July 7:** Adopted, with a caveat: "the record is asked, never browsed" is the right principle, but not an absolute. "Show me everything we've decided about Dunathon" is still a question put to the ally, answered as a question — it doesn't need a browsing surface to be broad. Keep the mental model centered on dialogue, not navigation; if usage ever shows members reaching for something that looks like a browser, the fix is a better answer, not a search page.

## 3. The portal card's press-and-hold is doing double duty, and one of them is a lie.

Press-and-hold is the signature gesture — R2 §4: "the only way to sign," reserved for acts with consequence (codes, votes, seals, births). Entering a training has **no consequence by construction** (that is the whole point of trainings). Using the signature gesture to enter one either dilutes the gesture (holds that aren't signatures) or mis-teaches newcomers that entering costs something — and newcomers meet trainings *first* (onboarding is a regimen, v4 §3).

**Alternative:** portals open on a plain tap with the 1400ms crossing serving as the deliberation window (release/interrupt to abort — the crossing is itself abortable). Reserve press-and-hold inside training for *practice signatures*, where teaching the gesture is the exercise. The mockups currently follow the brief (hold to enter); I think the brief is wrong here and the fix is one line in the spec.

**Resolution — Moto, July 7:** Adopted. The signature gesture should mean one thing — an act with consequence. Entering a training has none by design, so holding to enter weakens what the hold means everywhere else. Portals now open on a tap; the crossing itself is the deliberation and abort window. Press-and-hold stays reserved for real signatures, votes, authorizations, and practice signatures inside training.

## 4. Hollow gold needs a second, independent tell — one tell is a single point of failure.

The "gold is never filled in training" rule (UX-SPEC §7) is strong precisely because it's systemic — but it is *learned*, not self-evident, and a first-time member in their onboarding regimen has never seen filled gold. For them, hollow gold is just… gold. The fast-breathing ground (~20s) is the drawn secondary tell, but it's subliminal by design.

**Alternative (recommendation, not just a flag):** make the sim boundary *narratively* self-evident at first contact — the first sim wallet a member ever touches should be handed to them by an actor **in the fiction** ("Harl pays you in foundry scrip"), so the practice currency has a practice *name* and provenance before it has a style. Foundation §6 already permits sim tokens to be arbitrary; naming them in-world costs nothing and makes the hollow-gold rule a confirmation rather than a lone signal. Words in the world are not "saying it in words" on the UI.

**Resolution — Moto, July 7:** Adopted. A first-time member has never seen filled gold, so hollow gold alone doesn't communicate anything yet. Give the simulation its own in-world currency and provenance — Foundry Scrip, Academy Credits, whatever the world calls it — before it gets a style. The Foundry Row mockup (1m) already does exactly this: Harl's crew pays in foundry scrip, said in the fiction before the wallet ever renders. That's the standard now, not the exception — training should read as different in vocabulary and atmosphere, not just render treatment.

## 5. Realtime voice on Gemini live vs. the R2 register system — who wins mid-drift?

REALM-EXPRESSION gives each realm a rendering voice (clinical / loud / quiet), and drift blends them. A realtime voice session has an *audible* voice — pacing, warmth, interruption style — that members will experience as far more identity-bearing than type mood ever was. v4 is silent on whether the spoken voice drifts with grounding.

**Position:** it must not, or barge-in trust dies — a voice that changes personality mid-conversation reads as a different *person*, which violates "one system wearing personas / never show switching agents" at the sensory level. **Alternative:** the spoken voice is constant per ally; realm register expresses in *word choice and pacing of content* only (what the ally says, not how it sounds). Needs a decision before the voice stack is tuned.

**Resolution — Moto, July 7:** Adopted, and treated as architecture rather than a styling question. The ally's spoken voice stays constant — timbre, pacing, warmth, interruption style. Realm drift changes vocabulary and the pacing of ideas, not the identity of the speaker. If the voice itself changed mid-conversation it would feel like a different person, and that undermines trust. Added to REALM-EXPRESSION.md as an invariant a realm may never touch.

## 6. The cream sheet is designed; the web surface behind it isn't — and E's seamlessness depends on the part nobody owns yet.

The handoff moment (screens §15–§16) can be made to feel like reaching across a desk only if the web surface honors the same design system (espresso↔cream inversion, Goudy figures, gold-for-signature, no promotional chrome, no cookie-wall). If the web money app ships as a generic Stripe-checkout-looking page, the material metaphor collapses and the handoff *will* feel like an eviction regardless of the transition.

**Ask:** commission the web money surface as a design deliverable in R4 (it is small — join, wallet, limits, authorize), with a hard rule that the authorize page renders **nothing** but the act: what, how much, to whom, one signature. The receipt-line return contract (MOTION-ADDENDUM §6) should be specified as an API between the two surfaces now, not discovered later.

**Resolution — Moto, July 7:** Adopted. This was less a disagreement than a missing deliverable — the handoff only works if the web surface feels like part of the same world. The wallet/join/authorize flow is now a first-class R4 design project, not an afterthought behind the cream sheet. The receipt-line return contract is specified now (MOTION-ADDENDUM §6) rather than left to be discovered when R4 ships.