Add keyword-based live topic detection during recording #20

New issue

Closed

opened 2026-05-23 01:21:59 +00:00 by Mark · 2 comments

Mark commented

2026-05-23 01:21:59 +00:00

Owner

Parent Issue

#6 — No speaker/subject assignment during live recording
#11 — Implementation plan

Description

Per the topic segmentation research (#10), keyword detection is a lightweight live supplement that can show low-confidence topic hints during recording. Implement a KeywordTopicDetector that processes incoming transcript words and surfaces topic suggestions as "uncertain" chips in the UI.

Scope

Implement KeywordTopicDetector class:
- Takes a list of TopicRule(pattern: Regex, subjectId: Long, confidence: Float)
- Processes each new transcript word against a sliding window
- Returns TopicMatch? when a keyword pattern matches
Wire into TranscriptionService.onResult() or RecordingViewModel:
- When a keyword match fires, show a suggestion chip with a "?" indicator
- User can tap to confirm (creates a TYPE_SUBJECT SessionTag) or dismiss
Default keyword rules: common transition phrases ("let's talk about", "next topic", "moving on to")
Allow users to define custom keyword rules in Manage tab

Acceptance Criteria

KeywordTopicDetector processes live transcript text
Suggestion chips appear during recording when keywords match (with "?" indicator)
Tapping a suggestion chip creates a TYPE_SUBJECT SessionTag
Dismissing a suggestion removes it
Default rules cover common transition phrases
Manage tab has a section for custom keyword rules

Dependencies

SessionTag time-range infrastructure from #13

## Parent Issue #6 — No speaker/subject assignment during live recording #11 — Implementation plan ## Description Per the topic segmentation research (#10), keyword detection is a lightweight live supplement that can show low-confidence topic hints during recording. Implement a `KeywordTopicDetector` that processes incoming transcript words and surfaces topic suggestions as "uncertain" chips in the UI. ## Scope - Implement `KeywordTopicDetector` class: - Takes a list of `TopicRule(pattern: Regex, subjectId: Long, confidence: Float)` - Processes each new transcript word against a sliding window - Returns `TopicMatch?` when a keyword pattern matches - Wire into `TranscriptionService.onResult()` or `RecordingViewModel`: - When a keyword match fires, show a suggestion chip with a "?" indicator - User can tap to confirm (creates a TYPE_SUBJECT SessionTag) or dismiss - Default keyword rules: common transition phrases ("let's talk about", "next topic", "moving on to") - Allow users to define custom keyword rules in Manage tab ## Acceptance Criteria - [ ] KeywordTopicDetector processes live transcript text - [ ] Suggestion chips appear during recording when keywords match (with "?" indicator) - [ ] Tapping a suggestion chip creates a TYPE_SUBJECT SessionTag - [ ] Dismissing a suggestion removes it - [ ] Default rules cover common transition phrases - [ ] Manage tab has a section for custom keyword rules ## Dependencies - SessionTag time-range infrastructure from #13

Mark referenced this issue

2026-05-23 01:27:25 +00:00

No speaker/subject assignment during live recording #6

Mark added the

blocked:needs-decision

label

2026-05-23 16:39:50 +00:00

Mark commented

2026-05-23 16:39:50 +00:00

Author

Owner

⏸ Needs Decision

Blocking factors:

Didn't meet auto-approve criteria — scope=medium, risk=low, spec=aligned

Scope: medium Risk: low Spec: aligned Type: feature
Summary: Adds a keyword-based live topic detector that scans transcript text for transition-phrase patterns and surfaces suggest-able topic chips during recording.
Suggestion: Create standalone KeywordTopicDetector class with TopicRule data class (regex/subjectId/confidence), inject into RecordingViewModel, observe currentPartialText for sliding-window matches, surface matches as MutableStateFlow<List> for the recording UI to render as dismissible chips; Manage tab gets a new composable section listing existing Subjects with regex rule editors, stored via DataStore or as a Room entity. No new DB migration needed since SessionTag infrastructure already exists.
Rationale: Medium scope because it touches 6-9 files across data layer (new detector class + optional rule persistence), ViewModel wiring, and UI (suggestion chips + Manage tab section), but each change is small and isolated. Risk is low since the feature is entirely additive with no breaking changes — the suggestion chip is purely advisory, tapping it calls the existing setCurrentSubject() path. Spec is fully aligned as this is explicitly documented in the parent issues #6 and #11 as a Phase 2 milestone, and the SessionTag dependency from #13 is already implemented.

Action: Review each blocking factor above. Remove blocked:needs-decision label to route back to triage.

## ⏸ Needs Decision **Blocking factors:** - **Didn't meet auto-approve criteria** — scope=medium, risk=low, spec=aligned --- **Scope:** medium **Risk:** low **Spec:** aligned **Type:** feature **Summary:** Adds a keyword-based live topic detector that scans transcript text for transition-phrase patterns and surfaces suggest-able topic chips during recording. **Suggestion:** Create standalone KeywordTopicDetector class with TopicRule data class (regex/subjectId/confidence), inject into RecordingViewModel, observe currentPartialText for sliding-window matches, surface matches as MutableStateFlow<List<TopicSuggestion>> for the recording UI to render as dismissible chips; Manage tab gets a new composable section listing existing Subjects with regex rule editors, stored via DataStore or as a Room entity. No new DB migration needed since SessionTag infrastructure already exists. **Rationale:** Medium scope because it touches 6-9 files across data layer (new detector class + optional rule persistence), ViewModel wiring, and UI (suggestion chips + Manage tab section), but each change is small and isolated. Risk is low since the feature is entirely additive with no breaking changes — the suggestion chip is purely advisory, tapping it calls the existing setCurrentSubject() path. Spec is fully aligned as this is explicitly documented in the parent issues #6 and #11 as a Phase 2 milestone, and the SessionTag dependency from #13 is already implemented. **Action:** Review each blocking factor above. Remove `blocked:needs-decision` label to route back to triage.

Mark added

triage-approved

and removed

blocked:needs-decision

labels

2026-05-23 18:04:01 +00:00

Mark commented

2026-05-25 17:29:32 +00:00

Author

Owner

Fixed in commit. Closing.

Mark closed this issue