admin
0d463a859e
- closed: R-922 R-255 R-266 R-333 R-577 R-554 R-562 (controller 0.308.0 on demo-hp, demo-felhom, Tester 1), R-288 (map 212 KB -> 48 KB, detail per section) - R-521 narrowed to F7; R-388 design in 08 §8.1 (two questions for the operator) - privacy draft: why the registered address stays (S1); 02 module map: setup wizard deleted - STATUS + REPORT-answers-2026-10-12.md; docs.md routing line names capability-map-detail/ Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
10 KiB
Capability map — detail, section F. Notifications & monitoring
What this file is. The long text of every row of section F of
00-capability-map.md, moved here verbatim on 2026-10-12 (R-288, R-290 folded in;09§3 decisions 214 and 229) from the map at commit1b45bb4d. Each entry is one former table row, its cells laid out one per paragraph; the cell text itself was not edited. The map row carries the capability's ONE status word and its dated evidence pointer; this file keeps the argument, the corrections and the history. Where this text and the map row disagree on the status, the map row is current (see the map header for the words that were normalised).A new correction goes under the entry it corrects, dated — never into the map row.
F1 — An ABSENT backup-target drive raises its OWN alarm, paired with a matching recovery
Map row: F1 · former map line 210.
Scenario (as written): An ABSENT backup-target drive raises its OWN alarm, paired with a matching recovery
Components (as written): agent v0.116.0, controller v0.184.1+, hub v0.81.0
Status (as written): PROVEN-LIVE (2026-07-30)
Evidence (as written): audits/R116-v0116-2026-07-30.md. On a fresh box built through the real day-0 on demo-hp, running the agent it installed unaided from the vouched Day-0 manifest (0.116.0), both drives enrolled through the real endpoints and device loss a real hot-detach — the full four-event sequence, two matched pairs, correctly discriminated: 07:20:04 backup_target_absent (error) / 07:22:34 backup_target_restored (info) for the TARGET, and 07:24:04 storage_disconnected (error) / 07:25:34 storage_reconnected (info) for a NON-target drive on the same box minutes apart. Gate fired in 3 s. All four reached the hub — specific alarm, severity, Hungarian copy and hub routing now exercised end-to-end. Discrimination is proven NON-trivially for the first time: both prior runs had the target itself emit the generic event, so the mirror proved nothing. Over-correction guard PASSES with a positive observable — 0 ABSENT lines and 0 drive events over a 2m14s window with both drives present, target degraded:false, while 2 RETURNED lines prove the gate was ticking.
Gap / roadmap (as written): The mechanism was isolated from the captured payload first (DIAG-r116-disks-payload-2026-07-30.md), after two fixes aimed at shapes that do not occur. v0.116.0 joins the two records of one drive on the only identity that survives the device — the CONFIGURED path — so one row carries both the flag and the guest path the gate keys on. Both smaller-looking fixes were rejected because they regress R-114 (backup_target_offer.go:79 reads flag+mount_path as healthy). Caveat worth reading: the drill box ran controller 0.185.1 from the golden, which PREDATES R-114 — so its absent-state banner showed the old false "backup is on the system disk" copy. That is the golden being a release behind, not a regression → R-120
F2 — Health-degradation email (edge-triggered, cooldowns, Hungarian) via hub → Resend
Map row: F2 · former map line 211.
Scenario (as written): Health-degradation email (edge-triggered, cooldowns, Hungarian) via hub → Resend
Components (as written): controller, hub
Status (as written): IMPLEMENTED
Evidence (as written): delivery pipeline live-proven for the enlarge-block trigger (CAMPAIGN-6D P3-DELIVERY, op+customer "Kedves Ügyfél!"); NotifyHealthChange ok→warn/fail edge-trigger implemented
Gap / roadmap (as written): The health-degradation trigger specifically has never fired an email live in any doc. Demoted (pipeline proven for a different event). Deliverability to HU freemail → R-4
F3 — Event catalog: app_start_failed, dead-app, offbox_enlarge_blocked, claim/reset codes, critical severity
Map row: F3 · former map line 212.
Scenario (as written): Event catalog: app_start_failed, dead-app, offbox_enlarge_blocked, claim/reset codes, critical severity
Components (as written): controller, hub v0.31/48/50/55
Status (as written): PROVEN-LIVE
Evidence (as written): live-delivered: CAMPAIGN-6D P3-DELIVERY (enlarge-block, op+customer); DRILL-day0-vm F-4 (claim code); DRILL-day0-take2 F-15 (reset code)
Gap / roadmap (as written): app_start_failed/dead-app delivery is unit-only (6C inconclusive) — the pipeline + 3 event families are live, those two are not
F4 — Prefs safety: empty-email wipe guard
Map row: F4 · former map line 213.
Scenario (as written): Prefs safety: empty-email wipe guard
Components (as written): controller v0.137 + hub v0.71.0
Status (as written): IMPLEMENTED
Evidence (as written): controller leg red-proofed 07-15; hub-side no-clobber belt (handleSavePreferences preserves a stored non-empty address on an empty-email push) red-proofed 07-22
Gap / roadmap (as written): Born from a live incident; controller 0.160.0 guards both its push legs, so the hub belt covers older/rogue boxes
F5 — Paired recovery notifications + prefs seeding at claim + priority headers (power-outage audit F11/F12/F14-light)
Map row: F5 · former map line 214.
Scenario (as written): Paired recovery notifications + prefs seeding at claim + priority headers (power-outage audit F11/F12/F14-light)
Components (as written): hub v0.71.0
Status (as written): IMPLEMENTED (recovery leg PARTIAL until a live staleness cycle fires it)
Evidence (as written): hub/CHANGELOG.md v0.71.0; 17 tests + 4 red-proofs (REPORT.md 2026-07-22); Resend headers mechanism probed live (HTTP 200) pre-implementation; operator+customer test rows live-fired via the controller's own test endpoint
Gap / roadmap (as written): Recovery = explicit eventType branch, severity semantics frozen; customer gate = PAIRING (notification_log evidence), not enabled_events. Live legs pending: a natural *_recovered mail (next real staleness cycle or the reboot-drill arc — never fabricated by blocking reports) and seed-at-claim on a real claim (Peti Friday reinstall). F14-full (operator push channel, ntfy/Telegram) stays open → R-69
F6 — System + container metrics (SQLite, Chart.js, 30-day downsampling)
Map row: F6 · former map line 215.
Scenario (as written): System + container metrics (SQLite, Chart.js, 30-day downsampling)
Components (as written): controller
Status (as written): IMPLEMENTED
Evidence (as written): metrics collection + /monitoring render present (page 200)
Gap / roadmap (as written): The cited CAMPAIGN-2 T-RES-CPU/T-SOAK-LOOP are H1/H2 harness artifacts (auth-302), not metrics tests; SQLite/Chart.js/30-day downsampling validated in no campaign. Demoted
F7 — Always-on debug rings + on-demand log-bundle pulls with TTL/custody
Map row: F7 · former map line 216.
Scenario (as written): Always-on debug rings + on-demand log-bundle pulls with TTL/custody
Components (as written): controller v0.116, agent v0.83, hub v0.46
Status (as written): PROVEN-LIVE
Evidence (as written): debug rings live-exercised CAMPAIGN-3 fix-6 (1000-cap ring, ~55min horizon under load)
Gap / roadmap (as written): The log-bundle-pull TTL/custody half is changelog-only (no dedicated observability audit doc); ring persistence across restart is a known gap
F8 — Operator alerting (Healthchecks → monitoring@felhom.eu)
Map row: F8 · former map line 217.
Scenario (as written): Operator alerting (Healthchecks → monitoring@felhom.eu)
Components (as written): k3s, Resend
Status (as written): IMPLEMENTED
Evidence (as written): operator infra, stated in production since 02-04; no corpus validation doc
Gap / roadmap (as written): (the row had no fifth cell)
F9 — Backup-deadline alerting (expected_backup_missed) is ANCHORED — absence of signal is UNKNOWN, not failure
Map row: F9 · former map line 218.
Scenario (as written): Backup-deadline alerting (expected_backup_missed) is ANCHORED — absence of signal is UNKNOWN, not failure
Components (as written): hub v0.75.0
Status (as written): IMPLEMENTED
Evidence and gap (as written — this row's text carries a | outside code, so its last cells are kept together as they stood): audits/DIAG-backup-missed-2026-07-26.md + red-proofs A/B/C + replay of the real 2026-07-26 03:00 reports (all three silent) | No row status flips — this signal had a FALSE-POSITIVE class (three instances: hub v0.12.0, v0.73.0, R-81), now anchored at first contact and read across retained host-report history. Still unit-proven only, not live-fired at a real deadline. The underlying PBS/offsite-DR tier gap it exposed is → R-82. | Per the status enum, no citation → not PROVEN-LIVE. Demoted pending an operator-cited live alert (candidate re-upgrade — see REPORT)
F10 — A box that is not always on (off at its backup time) makes the missed night up once when it comes back; the household sees a banner; the operator gets the missed-backup alarm, down or not
Map row: F10 · former map line 219.
Scenario (as written): A box that is not always on (off at its backup time) makes the missed night up once when it comes back; the household sees a banner; the operator gets the missed-backup alarm, down or not
Components (as written): controller v0.295.0, hub v0.134.0, agent v0.145.0
Status (as written): PARTIAL — the catch-up and the banner PROVEN-LIVE (9202 + demo-felhom; banner on 9202 by a hand-set ledger); R-872's alarm proven by tests, live at the next 05:00 (dated check); a host SUSPEND reasoned + unit-tested, not measured
Evidence (as written): audits/catchup-2026-10-05/partA/, partB/; design 07 §6.1.1
Gap / roadmap (as written): R-872 live; a suspend never measured