3.5 KiB
3.5 KiB
Tutor Platform
What This Is
Tutor Platform is a web service for software job seekers preparing for technical interviews. It combines adaptive interview practice, evidence-backed learner memory, source-backed learning ontology, and game-inspired progression to make interview readiness visible and repeatable.
The backend is Go because the product will internalize agent-farm-go workflow
patterns and call third-one with deepseek-v4-flash through typed service
boundaries.
Core Value
The user should feel and prove that they are becoming more interview-ready after each short practice loop.
Requirements
Validated
(None yet; ship to validate.)
Active
- Developer job seekers can complete a diagnostic technical interview.
- Answers are graded with rubrics and preserved as evidence.
- Learner memory tracks concept mastery, misconceptions, evidence, and interventions.
- The system selects the next best interview challenge from learner state.
- The user sees a readiness map and meaningful progression after each loop.
- Uploaded learning materials can become source-backed ontology candidates.
- Generated learning assets preserve prompt, source, and review lineage.
- Backend implementation uses Go and keeps
agent-farm-goworkflow patterns internalized behind typed interfaces.
Out of Scope
- Full school LMS replacement; the first product target is job seekers.
- Marketplace course publishing; not needed to prove the learning loop.
- Automatic certification or hiring decisions; readiness is advisory.
- Unreviewed generated canonical content; generated ontology and assets require provenance and review state.
- Gambling-like rewards or shame-based leaderboards; progression must be tied to learning evidence.
Context
- Product planning lives in
docs/planning/. - OpenSpec change baseline lives in
openspec/changes/bootstrap-job-tutor-platform/. - The service should use a Go backend.
- Workflow behavior should be configuration-first and inspired by
agent-farm-go. - LLM execution should use
third-one, defaulting todeepseek-v4-flash. - Memory should be structured learner state, not a flat RAG transcript.
- Gamification should use Flow, adaptive difficulty, growth lines, and strong session endings without exploitative mechanics.
Constraints
- Backend stack: Go, to align with internalized
agent-farm-goworkflow patterns. - File size: manually authored source files must stay at or below 600 lines.
- Design principles: SOLID, KISS, and YAGNI govern implementation.
- Workflow state: product state changes should use typed contracts, not freeform prose parsing.
- Privacy: learner memory and evidence may become sensitive, especially for future student/school expansion.
Key Decisions
| Decision | Rationale | Outcome |
|---|---|---|
| Start with software job seekers | Clear, testable interview-practice loop | Pending |
| Use Go backend | Aligns service with internalized agent-farm-go substrate |
Pending |
Use third-one and deepseek-v4-flash by default |
Matches current local model/runtime direction | Pending |
| Structured learner memory, not RAG-first | Product value is learner modeling and readiness | Pending |
| Game-inspired progression must be evidence-backed | Creates retention without empty rewards | Pending |
| 600-line source limit | Forces responsibility boundaries early | Pending |
Last updated: 2026-04-26 after Go backend and GSD planning direction were set.