Files

T

tajniak81andClaude Opus 4.8 21c99ad762 Add technical check history

A car's mandatory roadworthiness inspections — przegląd techniczny, MOT,
TÜV — had nowhere to live. Log them behind Service history, which this
mirrors minus the odometer: an inspection falls due on a date whatever
the mileage reads.

The cycle is legal rather than mechanical, and it is not constant — a new
car's first check falls due years later than its third. So the car's
technical_check_interval_days only prefills the next date, and any check
overrides it with the valid-until printed on its own certificate. A
failed check derives no next date at all: reading one off a failure would
stamp a reassuring "valid until" on a car that just flunked.

The next-due date and its status are derived on every read rather than
stored, for the same reason documents are — a stored verdict goes stale
as the date passes. The response carries the same expiry shape documents
use, so the web app reuses the existing badge rather than growing a
second one.

Each check records result, cost, station and notes, and holds the
certificate as its single attachment on the same terms as every other
record.

Needs `node scripts/setup-pocketbase.mjs` to create technical_checks and
add the interval to cars. The reformatting in records.go is gofmt
realigning the car struct around a longer field name.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-17 11:54:26 +02:00

.claude

Restructure Web App into server/ + web/ (GsmNode parity)

2026-07-13 11:34:02 +02:00

server

Restructure Web App into server/ + web/ (GsmNode parity)

2026-07-13 11:34:02 +02:00

web

Add technical check history

2026-07-17 11:54:26 +02:00

README.md

Restructure Web App into server/ + web/ (GsmNode parity)

2026-07-13 11:34:02 +02:00

README.md

DriverVault — Web App

Maintenance tracker for your cars: a Vue 3 + Vite + Tailwind CSS v4 SPA served by a small Go backend-for-frontend (BFF). The BFF serves the built SPA and reverse-proxies /api/* to the API Server, so the browser is always same-origin and all data access still flows through the API Server (never PocketBase directly).

Browser ─► Web App BFF (:8090) ──/api/*──► API Server (:8080) ─► PocketBase
                  └── serves embedded Vue SPA

Layout

server/           Go BFF: embeds web/dist, proxies /api -> API_BASE
  main.go
  .env.example
  dist/           built SPA (generated; embedded at compile time)
web/              Vue 3 + Vite + Tailwind v4 source
  src/
    main.js       app bootstrap
    router.js     /login, / (dashboard), /cars/:id, /settings, /admin
    api.js        the only place that calls the API Server (base URL resolution)
    auth.js       session/profile state, isAdmin
    prefs.js      theme/locale/date/font preferences -> <html>
    lib/format.js date/km formatting + next-service status badges
    style.css     Tailwind v4 entry (+ dark custom-variant)
    App.vue       layout shell + nav (Admin link when admin)
    components/    Modal, CarFormModal, ServiceFormModal, PartFormModal, ShareModal, Logo
    views/         Login, Dashboard, CarDetail, Settings, AdminUsers

Requirements

Node 18+ and Go 1.26+
A running API Server (see ../API Server)

Develop

Two terminals:

# terminal 1 — API Server (see ../API Server/README.md)
cd "../API Server"; ./api-server.exe

# terminal 2 — Vite dev server with hot reload (proxies /api -> :8080)
cd web; npm install; npm run dev      # http://localhost:5173

The dev server proxies /api/* to the API Server (default http://localhost:8080, override with VITE_API_TARGET), so the client uses same-origin relative URLs and avoids CORS. It also listens on all interfaces (host: true) so it's reachable on the LAN (e.g. http://10.2.1.101:5173).

At runtime, users can override the API base URL from the login screen's Server settings (persisted in localStorage as cc_server_url); resolution order is that override → VITE_API_BASE → /api.

Build & run (production-style)

./server/Run-WebApp.ps1               # builds frontend, then serves on :8090
# or manually:
cd web; npm run build                 # outputs to ../server/dist
cd ../server; go run .                # http://localhost:8090

Config (server/.env, copy from .env.example):

Variable	Purpose	Default
`WEB_ADDR`	Listen address	`:8090`
`API_BASE`	API Server base URL	`http://localhost:8080`

Features

Dashboard — one card per car: last service, odometer, next-due date/km, and a status badge (OK / due soon ≤30d / overdue) from the Excel formulas. Add a car; shared cars are labelled and gated by your access level.
Car detail — full service history (date, km, computed next date/km, and the changed-parts flags) plus the per-car parts catalog and all car spec fields (engine / transmission / differential oil, brake fluid, coolant, VIN, …). Add/edit/delete service records, parts, and the car; share the car with other users (read/write, owner only). Edit/delete controls are hidden for read-only shares.
Settings — account (name / email verification / password), appearance (theme light/dark/system, locale, date format, font size), profile (avatar, bio), data export/import, active sessions with remote logout, and the account-deletion state machine.
Admin — /admin user management (list / create / role / reset password / delete), gated by the admin role via a router guard + nav link.
Theming — light/dark/system app-wide (Tailwind v4 class strategy); prefs.js toggles .dark on <html> and applies the saved theme/locale/date/font.

Auth & access

Login gets a JWT from the API Server (stored client-side) and creates a server session. auth.js exposes isAdmin and the current profile; the router guards public / admin routes. Cars are per-user (owned + shared), and the UI mirrors the server's read / write / owner access levels.