28 lines
907 B
Markdown
28 lines
907 B
Markdown
|
# Phase 7 Research: Web App Shell and Diagnostic Start
|
||
|
|
|
||
|
|
## Findings
|
||
|
|
|
||
|
|
The existing Go backend can serve static assets without adding frontend build
|
||
|
|
tooling. For the first MVP UI, plain HTML/CSS/JavaScript is enough and keeps
|
||
|
|
the repo dependency-light.
|
||
|
|
|
||
|
|
The diagnostic APIs already provide all Phase 7 data:
|
||
|
|
|
||
|
|
- `POST /api/v1/diagnostic-sessions`
|
||
|
|
- `POST /api/v1/diagnostic-sessions/{id}/answers`
|
||
|
|
- `GET /api/v1/diagnostic-sessions/{id}`
|
||
|
|
|
||
|
|
## Recommended Shape
|
||
|
|
|
||
|
|
- Add `internal/webapp` with embedded static assets.
|
||
|
|
- Register web app routes from `httpapi.Handler`.
|
||
|
|
- Keep frontend files small and focused.
|
||
|
|
- Use fetch calls directly against existing API routes.
|
||
|
|
|
||
|
|
## Risks
|
||
|
|
|
||
|
|
- A mock UI would not prove the backend loop. The UI must call real APIs.
|
||
|
|
- A marketing-style landing page would distract from the core product surface.
|
||
|
|
- Overbuilding a frontend stack before interaction validation would violate
|
||
|
|
YAGNI.
|