Files
tutor-service/.planning/PROJECT.md

85 lines
3.5 KiB
Markdown
Raw Normal View History

2026-04-26 15:35:26 +09:00
# 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-go` workflow 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 to `deepseek-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-go` workflow
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.*