Skip to content

Admit push-to-talk microphone input on the MARY governance console route, read intents only


Admit push-to-talk microphone input on the MARY governance console route, read intents only

Section titled “Admit push-to-talk microphone input on the MARY governance console route, read intents only”

Date: 2026-10-07 Status: closed Supersedes: none Superseded-by: none — current MR-compliance: MR-4, MR-7, MR-9

2026-10-07-mary-governance-console-route.md (closed, countersigned 2026-10-07) admitted /console/repo/mary-wiki/governance as a read-only route. It was built in #532 (abb6f753). Phase P7 of eva-hq:docs/reports/2026-10-03-mary-governance-surface-phases.md proposes voice on that route: the operator asks the instrument panel a read question by holding a key. This is D5 in that report’s decisions table.

Voice is a new input modality for the console. No console page asks for the microphone today. The dashboard sets no Permissions-Policy header (a grep of dashboard/ for Permissions-Policy, microphone and getUserMedia at 3dfd2e02 finds none), so the browser’s default prompt-on-request behaviour is the only control.

Precondition: mary-wiki D4. Voice on a MARY surface runs into DEC-APEX-0001 and DW-APEX-06 (mary-wiki:docs/APEX-MAP.md:51, :75): “Mary is never personified in conversation … never dialogic.” Whether that rule reaches this internal route, and whether a spoken query counts as “speaking to MARY”, is ruled in mary-wiki docs/decisions/2026-10-07-dw-apex-06-reach-console-voice-query-proposed.md (proposed, mary-wiki #785). This document cannot be countersigned until D4 is ratified with option (a) or (b). Under (c) the microphone terms here are void and only term 1 (the keyboard palette) survives. Under (d) this document does not fit and is withdrawn.

petrova-codes admits microphone input with push-to-talk on /console/repo/mary-wiki/governance only, on these terms. The route’s existing terms 1–6 (read-only, gated, mary-wiki R-2 scope) stand unchanged.

  1. The Cmd-K palette ships first, without a microphone. The first deliverable is a keyboard command palette on the route that uses the same intent parser (term 3). Voice is added on top of the palette and never ships without it. The palette alone needs no microphone and no D4 ruling beyond the route’s existing terms.
  2. Push-to-talk only. Recording happens only while a key or button is held. There is no wake word, no always-listening mode, and no recording after release. A visible recording state shows for the whole hold and at no other time. The microphone is requested on the first hold, never on page load.
  3. Closed read-intent grammar. The transcript maps to a fixed set of read intents, the scoping report’s list: “what needs me”, “what changed since ”, “show gate ”, “why is open”, “oldest countersign”, “convergence”. Each intent is navigation, filtering or highlighting on the rendered page. None performs a new computation or a new host read. An unmatched utterance shows its transcript and “no matching read”, and nothing else. No answer is generated.
  4. Act-shaped utterances are refused visibly. “Merge”, “approve”, “re-run”, “dispatch” and similar words show the transcript, “this surface cannot act”, and a link to where a human acts. The parser has no act intents to fall back to. Route term 3 (no form, no POST, no act import) covers the voice code’s module graph too.
  5. No audio retention. Audio is held in memory only for the length of one transcription and then discarded. It is not written to storage (local, session or IndexedDB), not logged, and not sent anywhere except a transcription step that term 6 allows. Transcripts are not persisted beyond the page view.
  6. On-device speech-to-text is preferred, and the choice is made by measurement. The candidates are: (i) an in-browser model (e.g. Whisper via WASM or WebGPU); (ii) a server-side transcription endpoint behind the same Airlock admin gate, with zero retention. The browser’s built-in Web Speech API is excluded, because in Chrome it sends audio to a third-party cloud recogniser by default, so speech about INTERNAL material would leave the estate. The build PR records latency, accuracy on a set recorded from the operator’s own voice and environment, and bundle or compute cost for (i) and (ii), and picks one with those numbers. If (ii) is chosen, the endpoint is a read-only transcription path that returns text and nothing else.
  7. Microphone permission is scoped to this route. The build adds a Permissions-Policy that denies microphone on every console route except this one, so no other page can ask for it.
  8. No persona. The voice has no name and no wake word, and it never says “I”. Any spoken output reads only rendered rows with their read times. It never speaks a generated statement except with that statement’s own label, and only on the terms of mary-wiki D3 (docs/decisions/2026-10-07-inferred-statements-on-governance-surface-proposed.md). Under D4 option (b) this term is a ratified requirement. Under (a) it stands as this repository’s own term.

This decision builds nothing.

  • Always-listening with a wake word — rejected. An ambient microphone in the operator’s room is surveillance. A “listening” indicator would also be a liveness light with no probe behind it, which PRODUCT.md principle 5 forbids (“no decorative states that could be mistaken for live signal”).
  • Browser Web Speech API (the cheapest path) — rejected. By default, in Chrome, audio goes to a third-party cloud recogniser. That is INTERNAL material leaving the estate (term 6).
  • An open grammar with a model producing the answer — rejected. It turns the route into a generated-answer surface. Generated statements are mary-wiki D3’s question, are made at snapshot time, and are never produced per query.
  • Microphone permission on the whole console — rejected. Other console routes carry act forms (dashboard/src/pages/console/acts/new/*), and voice next to an act form is the shape term 4 exists to prevent.
  • Palette only, no voice ever — not rejected, and it is the outcome if D4 rules (c). Voice is admitted here because the palette parser makes it cheap and it adds a hands-free, accessible path.

For code: none from this document. Build acts, in order:

  • palette PR: Cmd-K on the route, with the intent parser and tests for matched, unmatched and act-shaped input;
  • STT measurement (term 6), recorded in that PR or the next one;
  • voice PR: push-to-talk, the chosen STT, and the Permissions-Policy (term 7).

The voice PR carries the scoping report’s verification arms as tests or recorded checks:

  • V-voice-1: act refusal;
  • V-voice-2: no audio retained (network and storage inspection);
  • V-voice-3: the microphone is off unless the key is held;
  • V-voice-4: an unmatched utterance generates nothing;
  • V-voice-5: transcript-to-intent accuracy on the operator’s own voice (a target, not a gate).

For docs: dashboard/PRODUCT.md gains one line for the modality when the voice PR lands.

For in-flight phases: P7 starts only after P4 exit and P6-L1 is live (the scoping report’s gate), and after D4. This document does not move that gate.

For invariants: none added, modified or repealed. No blocking check is admitted.

For downstream consumers: eva.consumption.v1 is unchanged. If term 6 picks (ii), the host gains one authenticated transcription path and no new RPC read.

  1. D4’s ruling. Countersign only after mary-wiki D4 reads ratified with (a) or (b). State which one.
  2. Server-side fallback. Is term 6 (ii) acceptable at all, or is the rule on-device or nothing? The drafting agent recommends keeping (ii) as a measured fallback, because in-browser model size may be too large for a console page.
  • docs/decisions/2026-10-07-mary-governance-console-route.md (route admitted, terms 1–6; closed)
  • mary-wiki:docs/decisions/2026-10-07-dw-apex-06-reach-console-voice-query-proposed.md (D4; precondition; mary-wiki #785)
  • mary-wiki:docs/decisions/2026-10-07-inferred-statements-on-governance-surface-proposed.md (D3; terms for any generated statement)
  • mary-wiki:docs/APEX-MAP.md:51, :75 (DEC-APEX-0001, DW-APEX-06)
  • eva-hq:docs/reports/2026-10-03-mary-governance-surface-phases.md (P7, D5, V-voice-1..5)
  • dashboard/src/pages/console/repo/mary-wiki/governance.astro (the route, #532)
  • dashboard/src/pages/console/acts/new/ (act forms elsewhere on the console)
  • dashboard/PRODUCT.md:40 (principle 5)
  • Subagent: Claude Opus 5.5, 2026-10-07 (drafted; code read at 3dfd2e02)
  • Human: <<pending — countersign here to close>> — admits push-to-talk — alex@devarno.cloud, 2026-10-08 (jzero.run T1) microphone input on /console/repo/mary-wiki/governance on terms 1–8, states the D4 ruling relied on, and rules open question 2.

Countersigned by human:flight@arno.host on 2026-10-08 — box ticked in commit 111d2e68, authored by the human through jzero.run T1 (the app wrote the session email alex@devarno.cloud and left the <<pending>> placeholder in the line; both are app defects, the line stands as written under MR-7). D4 relied on: (b), ratified in mary-wiki 0e14b03 (2026-10-08): voice only as an unnamed instrument query, so terms 2 and 8 here are required, not recommended. Open question 2 ruled by FLIGHT in session on 2026-10-08 (“keep fallback”): term 6 (ii), the server-side transcription endpoint with zero retention, stays as a measured fallback. FLIGHT also noted in the same session that speech is not a priority for the foreseeable future: this close admits the modality on its terms and schedules nothing (P7 voice stays unbuilt until separately prioritised). Recorded by an agent as scribe. Status flipped open→closed on 2026-10-08 by an agent as scribe (MR-7).