Krok 4 of the phase-4 plan done ahead of the local-embed-fallback step
(Krok 2, deliberately deferred -- embed stays a plain SOLARIA call, per
task instruction): one FastAPI process now serves both the /search API
and the UI, no separate frontend build (plan §2 decision 4).
- GET / renders a Jinja2 shell; app/static/app.js (vanilla, no build) and
style.css are the whole client. Query -> /search, results grouped by
envelope_id client-side (chunks sorted by dist, <details> fragments).
- Colour thresholds per plan §7: dist<0.45 green, 0.45-0.55 yellow (still
shown with a warning), >0.55 never rendered as an individual result; if
a query ends up with nothing renderable, one "Brak odpowiedzi w KB"
message replaces the list, carrying the best observed dist.
- Paperless hits link out; gmail hits get a "kopiuj Message-ID" button
(there's nothing to link to yet, plan §2 decision 3) plus header
metadata. Cascade/flat toggle defaults to cascade. Footer shows
sol_status, refreshed from /healthz on load and after each search.
- /search gained additive summary/summary_tags fields (document_summary,
haiku track) so the UI can show a document summary as each result
group's header -- non-breaking, existing response shape untouched.
- Tests: app/db.py + app/search.py unit tests (mocked DB/HTTP, no live
deps) cover the new summary join; tests/test_frontend.py drives GET /
and /static/* via TestClient without running the DB-requiring lifespan;
tests/frontend/app.test.js (Node's built-in test runner, no framework)
covers query-URL encoding, threshold colouring, and envelope grouping.
- Verified live: docker build + container against kb-postgres@PIHA over
LAN and Ollama@SOLARIA over Tailscale -- GET / (HTML), /static/app.js,
/healthz, and /search (cascade + flat) all round-tripped correctly,
including real summary/summary_tags data.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
a73a986bbe