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.
2.3 KiB
2.3 KiB
Vision — Session Branching
Started 2026-09-27, ideation round. No priority assigned yet (suggested slot: after practice + side chats — it is the deepest record-model change in this document set).
Now that the app is fully pi-native, support session branching: the message history becomes a tree; the learner can navigate back in time and branch — explore "what if" continuations, revisit decision points, keep alternate lines.
The UI (owner sketched 2026-09-27)
A popup overlay in the chat area — exactly the same overlay pattern as the plan window. It presents the session's teacher messages, separated by teacher message, and the user branches from those points.
Assessment (coordinator, 2026-09-27)
- The overlay UI is the easy part. The record today is a flat native message array, and everything downstream assumes linearity: the view projection/grouping canon, the write-ahead persistence, the turn runner's one-turn-per-chat liveness, coverage fingerprints (keyed by message id), extraction idempotency (refs by toolCallId), subscription replay. Branching means a tree-shaped record model designed deliberately — not a UI feature bolted on.
- The pi SDK carries no native session-tree branching (its
Branch*exports are compaction summarization only, verified 2026-09-27). This is our own record-model work. Per the owner: read the full pi docs on sessions/branching before designing — confirmed as implementation-time step 1 regardless. - Value is real: rewind/replay fits the tutoring domain well (alternate explanations, "what if I'd answered differently"), and it composes cleanly with the parked persistent-agent idea later (branches as parallel histories to reconcile).
Open questions (unruled)
- Tree representation: parent pointers per message vs. branch records referencing a base prefix.
- What happens to graph evidence from abandoned branches — does extraction run per-branch, active-path only, or all paths with branch-scoped attribution?
- Branch lifecycle: naming/labels, switching, deletion; is the original line just another branch?
- Are user messages also branch points (edit-and-resend), or teacher-message anchors only, per the sketch?
- Interaction with practice/side chats (presumably none — they attach to their own surfaces).