Repository navigation
v0.2.1 — Phase 2 patch: dockerized local-dev + auth UX fixes
Patch release on top of v0.2.0 — same scope, fixes discovered during the first end-to-end local-dev bring-up.
Fixes
Dockerfile(new) — multi-stage build (rust:1.90-bookworm → debian:bookworm-slim). The api crate's compiledgenuflowbinary runs as the container CMD. SQLx migrations are embedded at compile time, so the runtime image carries no source..dockerignore(new) — keepstarget/,frontend/,.git/,.envand similar out of the build context.docker-compose.yml— addsJWT_SECRETandCOOKIE_SECUREto the api service env, threads sensible dev defaults through${VAR:-…}, remaps the db service host port to 5433 and the api host port to 8081 to avoid common local-port collisions, and uses the compose-network service namedbforDATABASE_URLinside the api container.frontend/lib/api.ts—request()previously calledres.json()on every non-204 success, which threwSyntaxErroragainst200 OK/201 Createdresponses with an empty body (login and register both fit this shape — they only set a cookie). Both flows surfaced as "Network error." in the UI even though the backend succeeded and the cookie was set. The helper now reads the body as text first and only parses if non-empty.frontend/app/register/page.tsx— the register form mapped every409 Conflictto "An account with that email already exists." But the backend returns 409 for bothemailand brand-slugcollisions with distinct messages. The page now surfaces the backend's message verbatim so the user knows which field to change.
Operational notes
After this release, the canonical local-dev bring-up is:
docker compose up -d
cd frontend && INTERNAL_API_URL=http://localhost:8081 npm run dev
…then http://localhost:3000/register.
Unchanged from v0.2.0
No backend behavior changes. No new migrations. No schema changes. Same per-brand anchor hash projection, same auth model, same endpoint surface. cargo clippy --workspace -- -D warnings and tsc --noEmit && next build remain clean.