Public Access
33 lines
2.0 KiB
Markdown
33 lines
2.0 KiB
Markdown
# Design
|
|
|
|
## Live Transcript Ordering
|
|
|
|
`MeetingRecordingCoordinator` will treat the formatted transcript line as the durable fallback. For each live segment:
|
|
|
|
1. Format and relabel the segment.
|
|
2. Append the formatted line to the transcript store immediately.
|
|
3. Keep the returned transcript-line reference for that exact appended line.
|
|
4. Queue `transcript_line` workflow processing out of band so later live segments can continue to be appended.
|
|
5. If workflow processing returns a different line, ask the transcript store to replace the referenced line.
|
|
6. If workflow processing fails, log the failure and keep the original appended line.
|
|
|
|
This preserves the observable transcript even when local automation rules are invalid, slow, or unexpectedly fail after validation.
|
|
|
|
## Transcript Store Contract
|
|
|
|
Add a transcript-store operation for replacing one previously written line by stable line reference. The vault-backed implementation serializes transcript-file edits per file and rewrites the referenced body line while preserving frontmatter. Existing bulk replacement remains in place for final diarization and speaker relabeling rewrites.
|
|
|
|
## Workflow Logging
|
|
|
|
The workflow engine already logs when a rule is applied. Extend this so logs show:
|
|
|
|
- rule start with rule name and event type,
|
|
- rule completion with whether the meeting note changed and whether the transcript line changed,
|
|
- rule errors with rule name and event type.
|
|
|
|
The engine will still throw for general workflow events so non-transcript lifecycle automation failures remain visible to callers. The recording coordinator catches transcript-line workflow failures during live transcript writes so transcript persistence continues.
|
|
|
|
## Disk-Full Follow-Up
|
|
|
|
The temporary WAV disk-full exception is tracked as a follow-up task. The expected one-hour file size for the configured `16 kHz / mono / 16-bit` stream is about 110 MiB, so a one-off disk-full error with ample later free space needs separate investigation rather than speculative cleanup behavior.
|