feat: add diagnostic interview loop

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

@@ -0,0 +1,43 @@
+# 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.