amosblomqvist
cd09c12b56
Four living documents capturing the post-explain ideation: - vision-practice.md (priority 1): exams over chosen node sets; assessment record model (extractor observation = data point zero, practice appends, labels-for-extractor/numbers-for-everyone-else, aggregation TBD-Bayesian); problem-engineer agent flow with self-verifiable coverage metadata and commit-before-pose grading via a dedicated write-seam tool; formats configurable, theory pending from owner. - vision-side-chat.md (priority 2): per-block hover-revealed mini threads, invisible to the teaching record; v1 = block-only context, escalation ladder documented; fork idea set aside (role confusion). - vision-branching.md (unscheduled): tree-shaped records, plan-overlay UI; pi SDK has no native branching (verified) — our own record-model work. - vision-persistent-agent.md (PARKED): markdown session records as the pull-based substrate, graph-as-truth over user.md, graph composer as interface, session kinds/three-surfaces note.
28 lines
2.4 KiB
Markdown
28 lines
2.4 KiB
Markdown
# Vision — Side Chats (block-scoped clarification threads)
|
|
|
|
Started 2026-09-27, ideation round. **Priority 2** of the post-explain roadmap (practice module first — this one is expected to be easy at the end of the day).
|
|
|
|
Quick clarification for quick questions — *between* the teaching. A separate, minimal agent exists beside the main learning agents; the teaching agents must stay unloaded (the owner's ruling: side chats have **zero effect on the teaching session**).
|
|
|
|
## The shape (owner sketched 2026-09-27)
|
|
|
|
- **Per teaching block.** Each block of the session transcript (the units divided by separators — turn groups) can carry its own mini thread.
|
|
- **UI discipline — invisible until relevant:**
|
|
- No side chats → **nothing changes in the UI**, except:
|
|
- a small chat button in the **bottom-right corner of each block, visible on hover** of that block;
|
|
- opened threads render as a **collapsible mini-chat underneath their block**, accumulating inline.
|
|
- **Never part of the teaching record.** The teaching agent never sees these threads; they are annotations on the session, not conversation within it. Where they persist (same file under a teacher-invisible namespace, or a side store keyed by chat + block anchor) is open.
|
|
|
|
## The agent (v1, first try — owner ruled the starting point)
|
|
|
|
- **Block-only context.** The ONE block being asked about is its only input, plus a system prompt instructing it to answer **very non-verbosely, directly, simply**. Questions are about specific sections, and the UI makes that scoping clear.
|
|
- **Forking the session was considered and set aside.** A fork (session-so-far + different system prompt) gets role-confused — it reads the transcript as its own words. If block-only proves ungrounded, the agreed escalation ladder, in order: + the plan tree, + the relevant graph propositions, + selected earlier blocks.
|
|
- Bare, cheap, tool-less, one model slot down from the teacher. The honest risk on record: an ungrounded answer that confidently contradicts the lesson is poison under the accuracy doctrine — watch it, don't pre-solve it.
|
|
|
|
## Open questions (unruled)
|
|
|
|
- Block identity/anchor stability (blocks are derived groupings — anchor by the block's first message id).
|
|
- Persistence location and shape (teacher-invisible namespace in the chat record vs. a separate store).
|
|
- Model slot (cheap, presumably) and any context ceiling.
|
|
- Keyboard/affordance details (hover-only button, or also focus-reachable).
|