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
COLUMN` has no `IF NOT EXISTS` clause (conflated with `CREATE TABLE`'s support for it) — check
`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
@@ -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.
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
full-suite runs with parallel workers. All credentials this project generated are in Vaultwarden.
API rejection, device labeling, deep-check, Fingerbank, new-device badge) — 16 tests across 9 spec
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,
manual labels, on-demand deep check. See the "Identifying unknown devices" architecture note above.
Unknown-device identification (issue #15, then #16 Fingerbank, then #17 new-device alerting) shipped
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
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
(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.
- The two `avahi-utils`/`miniupnpc` host packages on CT122 aren't in any deploy script — see
"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).