Local Development¶
VS Code Run and Debug¶
The repository includes a VS Code Run and Debug profile in
/.vscode/launch.json.
Available profiles:
Backend: FastAPI: starts the API onhttp://localhost:8000Frontend: Vite: starts the UI onhttp://localhost:5173Full stack: backend + frontend: launches both together
The frontend dev server proxies /api to http://localhost:8000, so the
backend and frontend profiles work together without extra frontend changes.
Prerequisites¶
Install dependencies first:
Backend, from backend/:
python3 -m venv .venv
source .venv/bin/activate
pip install --upgrade pip
pip install -r requirements.txt
Frontend, from frontend/:
The backend reads backend/.env when present. For a simple local setup, the
default SQLite configuration is sufficient.
For a Docker-based check of the exact working tree, run ./quickstart from the
repository root. It builds docker-compose.build.yml, so the first run can be
slower than the direct development servers but cannot silently test stale
published images.
Equivalent terminal commands¶
If you prefer not to use VS Code launch profiles, the matching commands are:
Backend:
Frontend:
Manual UI smoke test¶
AI agents that need repeatable authenticated Admin or Browser access should use Authenticated UI access for AI agents. The commands below remain useful for a human-driven route check or a local instance whose existing data is intentionally in scope.
For a quick browser check of a real development route, run the backend and frontend with explicit loopback addresses and ports:
Backend, from backend/:
Frontend, from frontend/:
Open http://127.0.0.1:5173/<route>, for example
http://127.0.0.1:5173/admin/storage-endpoints. The Vite dev server proxies
relative /api requests to http://localhost:8000 by default.
If a fresh database redirects to /login, issue a one-time link from the
running backend:
Open the printed /setup/first-admin#token=... URL and enroll a passkey. The
Browser E2E harness uses the same web bootstrap with E2E_ADMIN_* variables.
If the database already contains users, sign in with a known local account; do
not reset or reseed unrelated development data.
When validating an interface change, check the route content and the browser
console. A successful npm run dev, type check, or unit test run does not prove
that the route renders correctly in the browser.
Other interface testing options:
- Use Vitest and Testing Library for component states, forms, and request payload assertions.
- Use
cd frontend && rtk npm run test:e2efor repeatable/browserflows backed by the browser E2E Playwright config. - Use
cd frontend && rtk npm run docs:screenshotsand thenrtk npm run docs:screenshots:checkfor documentation screenshots and visual states.
Documentation scenarios declare a typed API user separately from browser UI
preferences. Their identity comes only from the simulated /api/auth/session
response; do not seed authentication tokens or users in localStorage.
npm run typecheck includes the documentation scripts, and npm test covers
their session mocking and UI preference setup. This simulated coverage is not
proof of authentication or permissions against a live backend.