docs: bootstrap tutor planning
This commit is contained in:
74
openspec/changes/bootstrap-job-tutor-platform/design.md
Normal file
74
openspec/changes/bootstrap-job-tutor-platform/design.md
Normal file
@@ -0,0 +1,74 @@
|
||||
# Design
|
||||
|
||||
## Product Boundary
|
||||
|
||||
The first user is a software job seeker. The product should begin with
|
||||
technical interview preparation because it gives clear task loops:
|
||||
|
||||
- ask a question
|
||||
- receive an answer
|
||||
- grade against a rubric
|
||||
- ask follow-ups
|
||||
- extract memory
|
||||
- recommend review
|
||||
- show progress and next challenge
|
||||
|
||||
General students remain a future expansion path, but the first requirements
|
||||
should not be diluted by full K-12 scope.
|
||||
|
||||
## Architecture Boundary
|
||||
|
||||
Use a Go backend as the product service boundary. Internalize `agent-farm-go`
|
||||
workflow patterns and contracts inside that backend boundary while keeping agent
|
||||
behavior configuration-first where possible. Use `third-one` as the LLM
|
||||
execution kernel with `deepseek-v4-flash` as the default configured model
|
||||
target.
|
||||
|
||||
The product backend owns durable user, learner, memory, ontology, and asset
|
||||
records. External memory or graph projects may inform design or become adapters,
|
||||
but they should not own product privacy or tenant semantics.
|
||||
|
||||
## Memory Boundary
|
||||
|
||||
The platform should not model memory as a flat RAG corpus. It should keep
|
||||
structured learning state:
|
||||
|
||||
- learner profile
|
||||
- concept mastery
|
||||
- misconception
|
||||
- evidence
|
||||
- intervention
|
||||
- review schedule
|
||||
|
||||
Every durable memory update must include evidence so the product can explain why
|
||||
it believes a learner is weak or strong on a concept.
|
||||
|
||||
## Ontology Boundary
|
||||
|
||||
Uploaded materials should become source-backed learning graphs. Inferred gaps
|
||||
and generated explanations are candidates until reviewed or otherwise validated.
|
||||
|
||||
## Visual Asset Boundary
|
||||
|
||||
Image generation should support diagrams and slide-like learning slices, but the
|
||||
asset pipeline must preserve prompt lineage, source concept links, and review
|
||||
state. The desired image provider key is `gpt-image-v2`, but production
|
||||
implementation must verify the current OpenAI API model name before wiring.
|
||||
|
||||
## Gamification Boundary
|
||||
|
||||
Use game-design principles to create healthy persistence: adaptive challenge,
|
||||
visible growth, clear goals, strong session endings, and long-term readiness
|
||||
progress. Do not optimize for compulsion alone. Random rewards, punitive streaks,
|
||||
and shame-based leaderboards are out of scope for the first product baseline.
|
||||
|
||||
The initial learning loop is:
|
||||
|
||||
- readiness goal
|
||||
- interview question
|
||||
- answer
|
||||
- rubric feedback
|
||||
- follow-up or correction
|
||||
- memory update
|
||||
- visible progress
|
||||
- next best challenge
|
||||
Reference in New Issue
Block a user