docs: update CLAUDE.md for new-device alerting + router investigation context
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
@@ -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).
|
||||
|
||||
Reference in New Issue
Block a user