VAPP-3: /setup onboarding drives first-user creation against VERVAIN_SERVER_URL #6

Merged
David merged 1 commit from feat/setup-onboarding-vapp-3 into main 2026-06-05 19:11:44 +02:00
Owner

Implements VAPP-3: wires vervain-apps to vervain-server's setup mode (VS-26) and adds a /setup onboarding route that drives first-user creation against VERVAIN_SERVER_URL.

What changed

  • Server config: the /app/server binary reads VERVAIN_SERVER_URL at startup. Unset is a warning, not a crash; the setup server fns return a "server URL not configured" error the UI surfaces instead of crash-looping.
  • New real (not canned) server fns in src/server_fns/mod.rs: get_setup_state() proxies GET /api/setup (404 -> Disabled, 2xx -> NeedsFirstUser/Complete), and register_first_user() proxies POST /api/setup/register (403 -> "user already exists", other failures surface the server's own message).
  • Auto-login: on successful registration the session token is re-issued as an HTTP-only cookie on the vervain-apps origin via the server fn response (FullstackContext::add_response_header), then the page navigates to the dashboard.
  • SetupState enum (Disabled / NeedsFirstUser / Complete) in src/models/mod.rs, modeled as an enum so future setup-only steps slot in as new variants.
  • New /setup route + src/components/pages/setup.rs step-walker. Declared before #[layout] so it renders standalone (no sidebar/topbar). Renders the form, a "setup not enabled" message, or a completion screen. Password match is checked client-side only; the policy stays the server's call.
  • App-load redirect: the root Layout runs one setup-state check and redirects to /setup only when NeedsFirstUser. Disabled/Complete/unreachable render the app normally.
  • reqwest added as a server-only dependency (rustls, no native-tls; feature set matches what Cargo.lock already resolved, so no new crates are pulled).

Note on the compose template

The issue's AC references docker/template/vervain-apps/compose.yml, which did not exist in this repo (no docker/ tree at all). I scaffolded a minimal, convention-following template carrying VERVAIN_SERVER_URL in mapping syntax alongside IP/PORT. If a separate deploy repo actually owns this template, relocate it there.

Verification

just check passes end to end: cargo fmt --check, cargo clippy --all-targets --features server -- -D warnings, cargo check --features server, cargo check --target wasm32-unknown-unknown, and cargo test --features server --bin vervain-app.

Depends on VS-26 (server-side setup endpoints). The frontend is coded against the documented contract; live integration testing requires VS-26 deployed.

#VAPP-3

🤖 Generated with Claude Code

Implements VAPP-3: wires vervain-apps to vervain-server's setup mode (VS-26) and adds a `/setup` onboarding route that drives first-user creation against `VERVAIN_SERVER_URL`. ## What changed - Server config: the `/app/server` binary reads `VERVAIN_SERVER_URL` at startup. Unset is a warning, not a crash; the setup server fns return a "server URL not configured" error the UI surfaces instead of crash-looping. - New real (not canned) server fns in `src/server_fns/mod.rs`: `get_setup_state()` proxies `GET /api/setup` (404 -> `Disabled`, 2xx -> `NeedsFirstUser`/`Complete`), and `register_first_user()` proxies `POST /api/setup/register` (403 -> "user already exists", other failures surface the server's own message). - Auto-login: on successful registration the session token is re-issued as an HTTP-only cookie on the vervain-apps origin via the server fn response (`FullstackContext::add_response_header`), then the page navigates to the dashboard. - `SetupState` enum (`Disabled` / `NeedsFirstUser` / `Complete`) in `src/models/mod.rs`, modeled as an enum so future setup-only steps slot in as new variants. - New `/setup` route + `src/components/pages/setup.rs` step-walker. Declared before `#[layout]` so it renders standalone (no sidebar/topbar). Renders the form, a "setup not enabled" message, or a completion screen. Password match is checked client-side only; the policy stays the server's call. - App-load redirect: the root `Layout` runs one setup-state check and redirects to `/setup` only when `NeedsFirstUser`. `Disabled`/`Complete`/unreachable render the app normally. - `reqwest` added as a server-only dependency (rustls, no native-tls; feature set matches what `Cargo.lock` already resolved, so no new crates are pulled). ## Note on the compose template The issue's AC references `docker/template/vervain-apps/compose.yml`, which did not exist in this repo (no `docker/` tree at all). I scaffolded a minimal, convention-following template carrying `VERVAIN_SERVER_URL` in mapping syntax alongside `IP`/`PORT`. If a separate deploy repo actually owns this template, relocate it there. ## Verification `just check` passes end to end: `cargo fmt --check`, `cargo clippy --all-targets --features server -- -D warnings`, `cargo check --features server`, `cargo check --target wasm32-unknown-unknown`, and `cargo test --features server --bin vervain-app`. Depends on VS-26 (server-side setup endpoints). The frontend is coded against the documented contract; live integration testing requires VS-26 deployed. #VAPP-3 🤖 Generated with [Claude Code](https://claude.com/claude-code)
feat(setup): /setup onboarding for first-user creation
All checks were successful
Check / fmt + clippy + build + tests (pull_request) Successful in 45s
Create release / Create release from merged PR (pull_request) Has been skipped
459ec86381
Wire vervain-apps to vervain-server's setup mode (VS-26). The /app/server binary reads VERVAIN_SERVER_URL at startup; an unset value logs a warning and the binary still starts, so the setup server fns return a "server URL not configured" error the UI surfaces instead of crash-looping.

New server fns in src/server_fns/mod.rs make real calls (not canned): get_setup_state() proxies GET /api/setup (404 maps to Disabled, a 2xx body reports NeedsFirstUser vs Complete) and register_first_user() proxies POST /api/setup/register (403 maps to "user already exists", other failures surface the server's own message). On success the returned session token is re-issued as an HTTP-only cookie on the vervain-apps origin via the server fn response.

A new /setup route (declared outside the app shell) renders the step for each SetupState: the first-user form, a "setup not enabled" message, or a completion screen with a link into the app. The form does a client-side password-match check only; the password policy stays the server's call. On success the page navigates to the dashboard.

The root Layout runs one setup-state check at load and redirects to /setup only when NeedsFirstUser; Disabled, Complete, and unreachable-server states render the app normally.

Adds docker/template/vervain-apps/compose.yml carrying VERVAIN_SERVER_URL in mapping syntax (no such template existed in this repo yet; relocate if a deploy repo owns it).

#VAPP-3

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: David Randall <David@NiceGuyIT.biz>
David merged commit e413130a91 into main 2026-06-05 19:11:44 +02:00
David deleted branch feat/setup-onboarding-vapp-3 2026-06-05 19:11:44 +02:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
psa-systems/vervain-apps!6
No description provided.