docs: update CLAUDE.md for new-device alerting + router investigation context
CI / web (push) Successful in 15s
CI / api (push) Successful in 22s

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
2026-07-13 00:07:06 -06:00
parent dfdc37eec1
commit 5b2dab3203
+25 -4
View File
@@ -73,6 +73,17 @@ One login instead of logging into Proxmox, Zabbix, OMV, and every service separa
confirmed by running the built output with `node`, not just `tsc`); and SQLite's `ALTER TABLE ADD confirmed by running the built output with `node`, not just `tsc`); and SQLite's `ALTER TABLE ADD
COLUMN` has no `IF NOT EXISTS` clause (conflated with `CREATE TABLE`'s support for it) — check COLUMN` has no `IF NOT EXISTS` clause (conflated with `CREATE TABLE`'s support for it) — check
`pragma table_info` first instead. `pragma table_info` first instead.
- **New-device alerting** (done): `seen_macs` table (permanent, MAC-keyed, insert-only) tracks the first
time each device was ever seen; bootstrap-safe so turning this on doesn't alert on the whole existing
population. Pushes a Home Assistant `persistent_notification` when a genuinely new MAC appears
(`HOME_ASSISTANT_TOKEN` + `homeAssistant.url` in `hosts.yaml`**token not yet provided by the user**,
so notifications aren't live yet even though detection and the dashboard badge are). Also shows a blue
"new" badge in the dashboard for anything first seen in the last 24h, independent of HA config. Real
bug caught via actual deployment (not just the unit test): the notification path was correctly
bootstrap-safe, but the UI badge wasn't bootstrap-aware at all — 65/71 devices showed as new on first
deploy. Fixed with a `seen_macs.is_bootstrap` column + a migration that backfills it correctly for
already-deployed data. Verified with a full synthetic end-to-end test (injected a fake device into the
discovery pipeline, confirmed only it got flagged, cleaned up after).
## Infrastructure this project owns ## Infrastructure this project owns
@@ -134,17 +145,27 @@ both above), fixed, and now covered by `e2e/oidc-login.spec.ts` as regression co
OIDC login are Playwright-verified passing (5 consecutive runs) as of this writing. OIDC login are Playwright-verified passing (5 consecutive runs) as of this writing.
e2e coverage expanded beyond the happy path (invalid credentials, session persistence, unauthenticated e2e coverage expanded beyond the happy path (invalid credentials, session persistence, unauthenticated
API rejection, device labeling, deep-check) — 13 tests across 6 spec files, stable across repeated API rejection, device labeling, deep-check, Fingerbank, new-device badge) — 16 tests across 9 spec
full-suite runs with parallel workers. All credentials this project generated are in Vaultwarden. files, stable across repeated full-suite runs with parallel workers. All credentials this project
generated are in Vaultwarden except the Home Assistant token (see below, not provided yet).
Unknown-device identification (issue #15) shipped after the OIDC work: OUI vendor lookup, mDNS, Unknown-device identification (issue #15, then #16 Fingerbank, then #17 new-device alerting) shipped
manual labels, on-demand deep check. See the "Identifying unknown devices" architecture note above. after the OIDC work: OUI vendor lookup, mDNS, manual labels, on-demand deep check + Fingerbank, and
alerting on genuinely-new MACs. See the "Identifying unknown devices" and "New-device alerting"
architecture notes above.
If picking this up again with no specific ask from the user, there's no queued work — check in with them If picking this up again with no specific ask from the user, there's no queued work — check in with them
for what's next rather than inventing scope. Remaining known gaps, none blocking: for what's next rather than inventing scope. Remaining known gaps, none blocking:
- **`HOME_ASSISTANT_TOKEN` not yet set** — new-device detection and the dashboard badge both work now,
but the actual push notification to Home Assistant is silently skipped until this is provided (a
long-lived access token from HA's Profile > Security).
- `diskPaths` in `hosts.yaml` vs. the remote forced-command scripts on omv/ripper is a manual-sync point - `diskPaths` in `hosts.yaml` vs. the remote forced-command scripts on omv/ripper is a manual-sync point
(documented, not automated — only 2 hosts, hasn't been worth it). (documented, not automated — only 2 hosts, hasn't been worth it).
- `e2e/` isn't wired into CI — run by hand (`cd e2e && npm test`) after any auth-related change. - `e2e/` isn't wired into CI — run by hand (`cd e2e && npm test`) after any auth-related change.
- The two `avahi-utils`/`miniupnpc` host packages on CT122 aren't in any deploy script — see - The two `avahi-utils`/`miniupnpc` host packages on CT122 aren't in any deploy script — see
"Infrastructure this project owns" above. "Infrastructure this project owns" above.
- User is evaluating buying a self-administrable router (UniFi/OPNsense) instead of the locked-down
GFiber one — if that happens, `knownDevices`/`deepCheck` IPs in `hosts.yaml` may need updating, and a
self-administered router might expose a real local API/DHCP data worth integrating (see conversation
history around 2026-07-13 for the GFiber investigation — no usable local API found for it specifically).