# Phase 3: Learner Memory - Context **Gathered:** 2026-04-26 **Status:** Ready for planning **Source:** GSD continuation after Phase 2 completion ## Phase Boundary Phase 3 converts graded answer evidence into structured learner memory. It should build the memory boundary needed by later progression work while keeping storage in-memory for now. ## Implementation Decisions ### Persistence - Use in-memory learner memory storage in Phase 3. - Do not introduce a database until the product loop needs durability across restarts. - Preserve a clear store interface so persistent storage can replace it later. ### Memory Model - Store learner profile. - Store concept mastery with evidence. - Store misconception records linked to answer evidence. - Store intervention history and review schedule placeholders. - Do not promote temporary session context unless workflow output includes evidence. ### Integration - Diagnostic answer submission should invoke memory extraction after typed grading. - The workflow runner should emit `MemoryUpdateCandidate` values. - Memory service should apply only updates with evidence. ## Canonical References - `docs/planning/PRD.md` - learner memory product goals. - `docs/planning/ARCHITECTURE.md` - memory strategy. - `docs/planning/WORKFLOW_CONTRACTS.md` - memory update contract. - `.planning/REQUIREMENTS.md` - MEM-01 through MEM-05. - `.planning/ROADMAP.md` - Phase 3 success criteria. - `openspec/changes/bootstrap-job-tutor-platform/specs/learner-memory/spec.md` - learner memory requirements. ## Specific Ideas - Add `internal/learnermemory`. - Add `GET /api/v1/learners/{userID}/memory`. - Wire diagnostic answer submission to memory ingestion. - Keep memory extraction deterministic in the workflow stub. ## Deferred Ideas - Database persistence. - Cross-session ranking/decay. - UI readiness map. - Spaced repetition scheduling details. --- *Phase: 003-learner-memory* *Context gathered: 2026-04-26*