tutor-service/.planning/phases/002-diagnostic-interview-loop/002-RESEARCH.md

Phase 2 Research

Question

How should the diagnostic interview loop be implemented while preserving the Phase 1 typed workflow boundary and avoiding premature infrastructure?

Findings

In-memory persistence is enough for Phase 2

The goal is to prove request/response flow and evidence preservation. A database would add migration, repository, and lifecycle complexity before the product loop is proven. An in-memory store with clear interface boundaries keeps the future database replacement straightforward.

Standard library routing remains sufficient

The current backend already uses http.ServeMux. Phase 2 can add route patterns with path variables using Go 1.23's standard mux support. No router dependency is needed.

Deterministic grading is acceptable as a workflow stub

Phase 2 requires typed grading through the workflow boundary. It does not require live LLM grading. A deterministic stub can grade on answer length and preserve evidence. This proves the product state flow and keeps live model integration for a later phase.

Keep interview domain separate from HTTP

internal/interview should own session creation, question catalog selection, answer recording, and grade attachment. HTTP handlers should translate requests and responses only.

Recommendation

1. Add internal/interview domain service and in-memory store.
2. Add a small backend developer question catalog.
3. Add typed endpoints for creating/getting sessions and submitting answers.
4. Extend workflow stub to return deterministic GradedAnswer.
5. Add tests at domain and HTTP layers.
6. Verify with go test ./..., OpenSpec, and line-count checks.