tajniak81andClaude Opus 4.8
183c83c177
getSerialNumber() is a BaseComponent method, so every component answers for
itself — and the bridge reads it off the flight controller. A Mavic Pro reports
08RDE1J00103H1 (what DJI Go labels "Flight Controller SN") where the airframe
sticker, and the registration, say 08QDE3H012032E. We were publishing the former
as the drone's serial, onto records that exist to satisfy BEK 1649 §5.
Same trap as 002e484, where a component's own firmware stood in for the
aircraft's, but with no correct source to switch to: MSDK v4 exposes no
aircraft-level serial at all — BaseProduct offers only the model and the
firmware package version — so the registered serial can only be typed by hand.
So split the two rather than pick one:
serial the airframe's, hand-entered, and the only one that
reaches the logbook and the CSV export
flight_controller_serial what the aircraft reports; auto-filled on connect,
and what POST /api/drones/auto now upserts on
Keying auto-add on the flight controller's serial keeps the fleet recognising a
connected drone without typing — it is stable per airframe — while leaving the
compliance record's serial to the pilot. A flight controller swapped in a repair
now costs a duplicate fleet entry to merge, where before it would have quietly
rewritten what the logbook claimed the drone was.
Note droneInput.payload() is a whole-record write, so any UI editing a drone must
round-trip flightControllerSerial; blanking it forks the drone into a duplicate
on its next connect. Drones.vue carries it through the edit form for that reason.
The migration copies existing serials into flight_controller_serial rather than
moving them: every current value came from auto-add and is therefore a flight
controller's, but a pilot may since have corrected one by hand and this cannot
tell them apart. Copying keeps auto-add matching the airframes it matched before.
Applied to the remote PocketBase, where drones held no records, so the backfill
was a no-op there.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Web App (Control Panel)
The PilotVault control-panel BFF. It serves the embedded Vue single-page app and
proxies /bff/* to the API Server, so the browser only ever talks to this
server (same-origin). The API Server is the gateway to PocketBase and to the live
Fly App data; the browser never contacts either directly.
Layout
server/ # Go BFF (package main) — proxies /bff/* and serves the SPA
dist/ # built web assets (go:embed target — produced by the web build)
.env.example # configuration template
go.mod
main.go # entrypoint, routing, static serving
bff.go # /bff/* proxy handlers
web/ # Vue 3 + Tailwind source, built by Vite into ../server/dist
Configuration
See server/.env.example. Key variables:
ADDR— address the BFF listens on (default:8090).API_BASE— default API Server the BFF proxies to (defaulthttp://localhost:8080). Users can override this per-session at login.
Develop
# 1. Build the web app into server/dist (embedded by the Go binary)
cd web && npm install && npm run build && cd ..
# 2. Run the BFF
cd server && go run .
For a live UI with hot-reload, run npm run dev in web/ (it proxies /bff to
a locally running BFF on :8090).
Build
cd server && go build -o web-app .
Or build the container image (multi-stage; builds the web app then the binary):
docker build -t pilotvault-web-app .