P1 — wire transcript normalization into voice, dictation and semantic routing before #122 #216

Open
opened 2026-08-28 03:23:52 +00:00 by nsaspy · 0 comments
Owner

Parent: #215
Depends on: #216, #217, #218
Integrates with: #12, #25, #82/#83, #122, #132, #160

Goal

Integrate the selected post-STT transcript normalizer into Zara's actual user-input paths without creating a second voice stack or changing STT provider semantics.

Canonical placement

For voice/conversation turns:

final STT transcript
  -> transcript normalization
  -> optional #122 bounded semantic rewrite
  -> deterministic semantic routing / conversational fallback

For dictation:

final STT transcript
  -> transcript normalization
  -> ordered typing/output sink

Do not normalize partial transcripts in this issue.

Runtime behavior

  • normalization starts only after canonical final-transcript acceptance;
  • preserve turn/trace/principal/conversation correlation;
  • cancellation before/during normalization prevents later routing/output;
  • stale normalization result cannot append history, trigger intent routing or type into the dictation sink;
  • selected failure policy is honored exactly;
  • off backend preserves existing behavior;
  • successful normalized text is the text routed onward;
  • #122 receives normalized text, never bypasses this stage when both are enabled;
  • final runtime/client transcript events make raw-vs-normalized state explicit enough for supported UI/diagnostics without emitting two user turns.

Dictation requirements

Reuse #12 ordering/lifecycle guarantees. When parallel ASR work completes out of order, normalization and final output must still commit in capture sequence. A slow normalizer for chunk N cannot permit chunk N+1 to type first unless the dictation architecture explicitly changes to a different ordered commit mechanism with equivalent guarantees.

Daemon / client behavior

Reuse #132 and existing runtime event transport. Do not run S1-mini separately in each client when the canonical daemon owns STT/semantic processing. Client-owned display may show raw partial text and later replace/annotate the final with normalized text according to the runtime event contract.

Tests

TDD end-to-end fake pipeline cases for:

  • off unchanged path;
  • S1-style cleanup used for semantic routing;
  • correction changes the routed utterance to the speaker's final intended wording;
  • normalized dictation output preserves order;
  • normalizer timeout with raw fallback;
  • fail-turn policy;
  • cancel during normalization;
  • stale result after replacement turn;
  • #122 receives normalized input exactly once;
  • no duplicate conversation user message;
  • daemon event ordering raw-final -> normalization result -> route;
  • two principals normalize independently without shared mutable provider state.

Add one focused non-interactive integration script and include deterministic cases in full repo/Nix CI.

Acceptance

With backend = "s1-mini", real Zara voice/dictation paths use normalized final text before routing/output; with backend = "off", behavior remains compatible. Cancellation, ordering, daemon ownership and #122 placement are regression-proven.

Parent: #215 Depends on: #216, #217, #218 Integrates with: #12, #25, #82/#83, #122, #132, #160 ## Goal Integrate the selected post-STT transcript normalizer into Zara's actual user-input paths without creating a second voice stack or changing STT provider semantics. ## Canonical placement For voice/conversation turns: ```text final STT transcript -> transcript normalization -> optional #122 bounded semantic rewrite -> deterministic semantic routing / conversational fallback ``` For dictation: ```text final STT transcript -> transcript normalization -> ordered typing/output sink ``` Do not normalize partial transcripts in this issue. ## Runtime behavior - normalization starts only after canonical final-transcript acceptance; - preserve turn/trace/principal/conversation correlation; - cancellation before/during normalization prevents later routing/output; - stale normalization result cannot append history, trigger intent routing or type into the dictation sink; - selected failure policy is honored exactly; - `off` backend preserves existing behavior; - successful normalized text is the text routed onward; - #122 receives normalized text, never bypasses this stage when both are enabled; - final runtime/client transcript events make raw-vs-normalized state explicit enough for supported UI/diagnostics without emitting two user turns. ## Dictation requirements Reuse #12 ordering/lifecycle guarantees. When parallel ASR work completes out of order, normalization and final output must still commit in capture sequence. A slow normalizer for chunk N cannot permit chunk N+1 to type first unless the dictation architecture explicitly changes to a different ordered commit mechanism with equivalent guarantees. ## Daemon / client behavior Reuse #132 and existing runtime event transport. Do not run S1-mini separately in each client when the canonical daemon owns STT/semantic processing. Client-owned display may show raw partial text and later replace/annotate the final with normalized text according to the runtime event contract. ## Tests TDD end-to-end fake pipeline cases for: - `off` unchanged path; - S1-style cleanup used for semantic routing; - correction changes the routed utterance to the speaker's final intended wording; - normalized dictation output preserves order; - normalizer timeout with raw fallback; - fail-turn policy; - cancel during normalization; - stale result after replacement turn; - #122 receives normalized input exactly once; - no duplicate conversation user message; - daemon event ordering raw-final -> normalization result -> route; - two principals normalize independently without shared mutable provider state. Add one focused non-interactive integration script and include deterministic cases in full repo/Nix CI. ## Acceptance With `backend = "s1-mini"`, real Zara voice/dictation paths use normalized final text before routing/output; with `backend = "off"`, behavior remains compatible. Cancellation, ordering, daemon ownership and #122 placement are regression-proven.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
nsaspy/zara#216
No description provided.