Add post-recording LLM topic extraction #19

New issue

Closed

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

Mark commented

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

Owner

Parent Issue

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

Description

Per the topic segmentation research (#10), the recommended approach is post-recording LLM topic extraction. After a recording completes, send the full transcript to an LLM to identify topic boundaries and labels, then write them as SessionTag entries for the user to review.

Scope

Add a "Generate Topics" button on TranscriptDetailScreen
Implement LLMTopicExtractor that sends the full transcript to an LLM API (OpenAI/Anthropic/self-hosted, configured in BackendConfig)
Prompt template: segment the transcript by topic, return JSON with start/end offsets and topic labels
For each detected topic:
1. Create or match a Subject entity
2. Write SessionTag(tagType=TYPE_SUBJECT, referenceId=subject.id, startOffsetMs, endOffsetMs) entries
Show a review screen where the user can accept, rename, merge, or delete suggested topics
Fall back gracefully if no API key or network

Acceptance Criteria

"Generate Topics" button appears on TranscriptDetailScreen for completed recordings
Clicking it sends transcript to configured LLM API
Progress indicator during processing
Detected topics are created as Subject entities
SessionTag entries with TYPE_SUBJECT are written with correct time offsets
Review screen shows suggested topics with accept/rename/delete actions
Graceful error handling for missing API key or network issues

Dependencies

LLM API key configured in BackendConfig (or reuse existing cloud STT key)
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), the recommended approach is post-recording LLM topic extraction. After a recording completes, send the full transcript to an LLM to identify topic boundaries and labels, then write them as SessionTag entries for the user to review. ## Scope - Add a "Generate Topics" button on TranscriptDetailScreen - Implement `LLMTopicExtractor` that sends the full transcript to an LLM API (OpenAI/Anthropic/self-hosted, configured in BackendConfig) - Prompt template: segment the transcript by topic, return JSON with start/end offsets and topic labels - For each detected topic: 1. Create or match a `Subject` entity 2. Write `SessionTag(tagType=TYPE_SUBJECT, referenceId=subject.id, startOffsetMs, endOffsetMs)` entries - Show a review screen where the user can accept, rename, merge, or delete suggested topics - Fall back gracefully if no API key or network ## Acceptance Criteria - [ ] "Generate Topics" button appears on TranscriptDetailScreen for completed recordings - [ ] Clicking it sends transcript to configured LLM API - [ ] Progress indicator during processing - [ ] Detected topics are created as Subject entities - [ ] SessionTag entries with TYPE_SUBJECT are written with correct time offsets - [ ] Review screen shows suggested topics with accept/rename/delete actions - [ ] Graceful error handling for missing API key or network issues ## Dependencies - LLM API key configured in BackendConfig (or reuse existing cloud STT key) - 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:41:05 +00:00

Mark commented

2026-05-23 16:41:05 +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 post-recording LLM topic extraction that sends completed transcripts to an LLM and creates Subject + SessionTag(TYPE_SUBJECT) entries with a user review screen.
Suggestion: Implement as a clean domain layer: an LLMTopicExtractor interface (with an OpenAI-compatible HTTP client impl) injected via Hilt. Add an LLM API key field to the existing BackendConfig screen (or a dedicated LLM section) reusing SharedPreferences. Use a BottomSheet dialog for the topic review to avoid navigation complexity. The existing SubjectRepository and SessionTagRepository already provide all the persistence wiring needed.
Rationale: SCOPE=medium: ~5-7 files (new LLMTopicExtractor, new ViewModel, modified TranscriptDetailScreen, topic review dialog/UI, BackendConfig extension for LLM key) — not trivial but well-bounded. RISK=low: purely additive, no existing transcription/speech paths touched, the SessionTag #13 infrastructure is already in place with TYPE_SUBJECT and time-offset support. SPEC=aligned: the project's self-description as a 'semantic notebook for conversations' and the explicit recommendation in the #10 research doc both point to this approach. The Subject + SessionTag data model already models this perfectly.

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 post-recording LLM topic extraction that sends completed transcripts to an LLM and creates Subject + SessionTag(TYPE_SUBJECT) entries with a user review screen. **Suggestion:** Implement as a clean domain layer: an LLMTopicExtractor interface (with an OpenAI-compatible HTTP client impl) injected via Hilt. Add an LLM API key field to the existing BackendConfig screen (or a dedicated LLM section) reusing SharedPreferences. Use a BottomSheet dialog for the topic review to avoid navigation complexity. The existing SubjectRepository and SessionTagRepository already provide all the persistence wiring needed. **Rationale:** SCOPE=medium: ~5-7 files (new LLMTopicExtractor, new ViewModel, modified TranscriptDetailScreen, topic review dialog/UI, BackendConfig extension for LLM key) — not trivial but well-bounded. RISK=low: purely additive, no existing transcription/speech paths touched, the SessionTag #13 infrastructure is already in place with TYPE_SUBJECT and time-offset support. SPEC=aligned: the project's self-description as a 'semantic notebook for conversations' and the explicit recommendation in the #10 research doc both point to this approach. The Subject + SessionTag data model already models this perfectly. **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:00 +00:00

Mark commented

2026-05-25 17:20:57 +00:00

Author

Owner

Fixed in commit. Closing.

Mark closed this issue