# Future Areas — Recipe Seeds (per FVW v8) **Status:** Seed doc. Operator will fill in the blanks. **Created:** 2026-07-17 (after killing Comms + asking "what next for voice?") **Authority:** Operator-locked, not yet ratified as FVW doctrine. **Shape:** Each section is a recipe seed — what we know now, what's open, what would unblock it. Per FVW v8 §22: every FVW v8 module has 5 mandatory artefacts: `module.json` + `module-meta.json` + `facets.json` + `recipe-book/{recipe,codex,rules}.md` + `test-cases/`. This doc is the upstream seed for future work — **NOT** the artefacts themselves. --- ## 1. Voice Notes — Robust Upgrade **Why this is in future-areas:** Operator said "we already have voice notes can we do something more robust around that." Current state works but is thin. **Current state** (as of 2026-07-17): - `app/src/voice/VoiceView.tsx` — 661 lines, list/create/edit/filter voice artefacts - `app/src/voice/groq-transcribe.ts` — Groq Whisper fallback when Web Speech fails (Vivaldi) - `app/src/voice-pipeline/VoicePipeline.ts` — 5-stage state machine: capture → transcribe → edit → save → confirm - `app/src/data/models/Voice.ts` — model: id, project_id, title, audio_blob, duration, raw_transcript, edited_transcript, status, tags - IDB store: `voice` (DB_VERSION 4) - 5 fragments in `pact/fragments/oscar.voice-pipeline.*.001.md` - Codexes: `pact/codex/voice.codex.md` + `pact/codex/capture.codex.md` **What's currently working:** - Tap mic → Web Speech API live transcribes (or Groq Whisper fallback) - Save with title + tags - Edit transcript after recording - List view with filter - IDB persistence (local) **What's NOT robust** (the gaps operator is calling out): ### 1.1 — Audio playback is missing - `audio_blob?: Blob` is stored, but the UI doesn't show a play button - After saving, you can't replay what you said - After editing the transcript, you can't verify it matches the audio - **Open question for operator:** Should we surface audio playback inline (a play button next to the title in the list), or behind a detail view? ### 1.2 — Long notes are a flat string - `raw_transcript` + `edited_transcript` are just `string` — no structure - A 10-minute field dictation becomes a wall of text - No paragraph breaks, no "this is about a different tree" cues - **Open question:** Does Mark want automatic segmentation (pause detection → paragraph), or manual? LLM post-process into structured fields? Or keep it as-is and let the survey/notes view parse it? ### 1.3 — Link to artefacts is implicit - `tags: string[]` ties to other artefacts by string, no FK - A voice note "survey tree #14" doesn't actually link to tree #14 - The `project_id` exists but tree/survey links are guesswork - **Open question:** Should voice notes have a `linked_artefacts: { type, id }[]` field? Or stay loose? ### 1.4 — Background recording / redaction - Recording only works while the page is open - No "tap to start, close app, tap to stop later" - No way to redact a sensitive phrase from the audio - **Open question:** Is this in scope for a "robust upgrade" or a separate "pro" feature? ### 1.5 — Search across voice notes - Filter is by tag, not by content - "What did I say about the oak on Acacia Ave last week?" → unanswerable - **Open question:** Client-side full-text search on `edited_transcript`? Or LLM-backed semantic search? ### 1.6 — Export pipeline - Voice notes can be saved but can't be exported as a bundle (PDF, DOCX, plain .md) - The Reports module can export a report; voice notes have no equivalent - **Open question:** A "voice notes digest" export — chronological list, or grouped by tag/survey? ### What "robust" probably means (my read): The minimum useful upgrade is **1.1 (playback) + 1.5 (search) + a "what's this for" header on the /voice page**. The other items (segmentation, links, redaction) are speculative without a real user story. ### Recipe seed (when operator says "build"): ``` # Module: oscar.voice-robust # Status: SEED (not yet started) # Depends on: oscar.voice (existing) # Cost: ~1 day for 1.1 + 1.5 + header; ~1 week for everything §A — Purpose Voice notes, made reliable. Play back what you said, search what you meant, see what it's for at a glance. §B — Behaviour inventory - /voice list shows play button next to each note - Tap play → audio plays inline, transcript highlights current segment - Search bar at top of /voice searches edited_transcript content - Page header explains what a voice note is and what it does §C — Open (operator decision) - 1.2 segmentation: do we want it? - 1.3 artefact links: do we want it? - 1.4 background recording: scope? - 1.6 export: scope? ``` --- ## 2. Note-Taking Module (replaces what Comms was supposed to be) **Why this is in future-areas:** Operator said "we can make a proper note taking module later." Comms was the wrong shape (chat channels). The real need is structured notes for arborists — different shape. **What Comms was:** local-only chat, channels (#General, #Site visits), no team. Why it failed: no team, no real use case, jargon "channel" instead of "note". **What a real note-taking module would do:** ### 2.1 — Three note types - **Quick note** — free-form text, title + body + tags. The default. Created from any "+" button. - **Site visit note** — a note that's tied to a project/site/visit. Has a date, a location, a list of trees surveyed. - **Voice note** — already exists at /voice. Should integrate: create a quick note from a voice note's transcript, link a quick note to a voice note, etc. ### 2.2 — One unified list view at /notes - Currently /notes shows textarea-tags view (per fragment `oscar.view.notes.textarea-tags.001.md`) - The new /notes is the home of all note types with type filter chips at top - Chronological by default, group by project, group by tag, or filter by type ### 2.3 — One recipe for each type - `recipe-book/note-quick/recipe.md` - `recipe-book/note-site-visit/recipe.md` - `recipe-book/note-voice-link/recipe.md` (links the two) - All under the same `oscar.notes` module ### 2.4 — What it does NOT do (vs Comms) - No channels (too jargon-y for tree work) - No reactions / read receipts (single-user local) - No "team" concept (use a note's project + collaborator list if/when teams exist) - No "send to someone" — keep notes local; export to PDF/DOCX if the user wants to share ### Recipe seed (when operator says "build"): ``` # Module: oscar.notes # Status: SEED (replaces comms pattern) # Cost: ~3 days for unified view + 3 note types # Requires: existing /voice module, existing project context §A — Purpose Three kinds of notes for arborists: quick, site visit, voice. All in one place. No "channels" jargon. §B — Behaviour inventory - /notes is the unified list - Filter by type (quick / site visit / voice) - Group by project, tag, or date - Quick note: title + body + tags + project (optional) - Site visit note: project + date + location + tree refs + body - Voice note link: from a voice note, "make this a quick note" - Export single note or all notes to PDF/DOCX §C — Open (operator decision) - Does the Site Visit note need structured tree refs (linked_artefacts), or is it just a body that mentions trees by name? - Does /notes replace /notes?new=1 (the current "Add → Note" flow)? - Does it live in /notes (existing route) or move to a new /notebook? ``` --- ## 3. Other future-area seeds (one-liners, not yet started) ### 3.1 — Capture module (multimodal, currently `oscar.capture`) - `app/src/capture/CaptureFlow.tsx` is the 5-mode capture bar - Modes: voice, photo, gps, measurement, text - This is "robust" already; not sure what else needs to happen - **Status:** operational, not in upgrade list ### 3.2 — Inline-editing on the front-end - Operator parked design 2026-07-06 in user-scope memory - Pattern: `data-fv-source="page"` / `data-fv-source="post:{id}"` / `data-fv-source="global:{key}"` - **Status:** DESIGN captured, not built ### 3.3 — Panel manager v2 (multi-panel pinned to edges) - Operator parked design 2026-07-06 - Multiple panels on same edge, only one focused - **Status:** DESIGN captured, not built ### 3.4 — FVW v8 full audit of the rest of Oscar - QuickPanel is the first FVW v8 sovereign component - Other ~95% of Oscar still uses Mantine, has hardcoded styles - **Status:** not started, ~3-5 days for full app ### 3.5 — ai-tags module - Design captured 2026-07-15 (`/workspace/.mavis/plans/2026-07-15/ai-tags-module.md`) - 6 scopes, per-app namespaced, generic (no Oscar prefix) - **Status:** DESIGN captured, parked ### 3.6 — "Paste a key, keep chatting" flow - Operator's Oscar AI Brain plan, Phase C - Detects API key in user input, saves to store, re-prompts LLM with original intent - LLM never sees the key value - **Status:** DESIGN captured, not built ### 3.7 — Operator panel v1.0 (IONOS VPS) - Built 2026-07-10 by sister session - http://185.249.73.178/login (default creds: admin/changeme-on-first-login) - **Status:** operational, operator hasn't changed default password yet --- ## How to use this doc When operator says "build X" or "design Y": 1. Find the recipe seed in this doc 2. Copy the seed to `pact/recipes//recipe.md` 3. Fill in the open questions (consult operator) 4. Generate the 5 mandatory artefacts (module.json, module-meta.json, facets.json, recipe.md/codex.md/rules.md, test-cases/) 5. Build it When operator says "what should we build next?": - Read this doc top to bottom - Each seed is ranked by operator's stated priority + the gap it fills - The top 2-3 are the natural next moves --- ## Authority chain This doc is **operator-locked**, not doctrine. It captures the *shape* of what we might build, not the *contract* of what we will build. Per FVW v8 §11, the recipe-book is the source of truth for any module that gets built. This doc just feeds into the recipe-book. Cross-reference: `pact/dna/app.dna.json` is the current doctrine (sections §37-§45 ratified). New modules need to be added to app.dna.json before they become canonical.