# 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.