docs: matrix_e2ee v0.3.12/v0.3.9 notes; gw/ubnt IPv6 re-verification; agent sandbox SSH quirk (2026-08-20)

AGENTS.md

@@ -18,6 +18,19 @@ Also readable as `agent.md` (symlink → this file).
 6. Default SSH access (`ssh -4 windy@<host>`) is for focused diagnostics,
    imperative upstream procedures, and incident work. Prefer **IPv4** from this
    WSL client (AAAA often exists but IPv6 route does not).
+
+   > **Agent sandbox SSH quirk (verified 2026-08-20):** the agent shell runs in
+   > a sandboxed user namespace — system files such as
+   > `/etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf` appear owned by `nobody`,
+   > so plain `ssh` aborts with `Bad owner or permissions on ...`. Always use
+   > `ssh -F /dev/null` from the agent shell and pass options explicitly
+   > (`~/.ssh/config` is skipped; e.g. `ssh -F /dev/null -p 2222
+   > -i ~/.ssh/id_ed25519 windy@repo.windy.me`). `sudo` never works in the
+   > sandbox (`NoNewPrivs`, no capabilities, `/` read-only). The host itself is
+   > healthy — to inspect or act on the real host from the sandbox use
+   > `/mnt/c/WINDOWS/system32/wsl.exe -u root -- <cmd>` (real root: keep
+   > read-only unless a change is approved).
+
 7. Record each material VPS operation, incident, configuration change, or
    verification outcome in the corresponding **Linear `vps` project**. Include
    scope, action, verification, and remaining follow-up; never put passwords,

docs/home-assistant-matrix.md

@@ -179,8 +179,10 @@ automation:
 ## matrix_e2ee (custom E2E integration)
 
 Custom integration [`windyboy/ha-matrix-e2ee`](https://github.com/windyboy/ha-matrix-e2ee),
-release **v0.3.0** (W1N-180/#32: bot-initiated device verification wizard),
-deployed on `hass.windy.lan` 2026-08-18 (upgraded from v0.2.10).
+release **v0.3.12** (Matrix activity events + push diagnostics), deployed on
+`hass.windy.lan` 2026-08-20 (upgraded from v0.3.2, W1N-182/#34 emoji-wait
+wizard fix; v0.3.9 brought the Connection health binary sensor, SAS/command
+allowlist split, URL normalization and single-entry enforcement, W1N-156/W1N-190).
 Runs a dedicated bot with a **persistent E2EE device identity**.
 
 - Domain `matrix_e2ee`; Config Flow (UI) with YAML import migration, not in HACS. Does **not**
@@ -212,6 +214,13 @@ Runs a dedicated bot with a **persistent E2EE device identity**.
     optional `emojis`, optional `expires_at`; `expires_at` added v0.1.3)
   - `matrix_e2ee_fingerprint` (`user_id`, `device_id`, `ed25519`, `curve25519` —
     public keys only; added v0.1.3)
+  - `matrix_e2ee_message_received` (`room_id`, `sender`, `event_id`; added v0.3.12
+    activity events)
+  - `matrix_e2ee_verification_done` (`transaction_id`, `user_id`, `device_id`;
+    added v0.3.12)
+- v0.3.12 also adds an `event.` platform entity (`Bot activity`,
+  `event_types: ["message", "command", "verification_done"]`) and a diagnostic
+  Connection binary sensor (`binary_sensor.*_connection`, CONNECTIVITY class).
 - `notify.matrix_e2ee` is **not implemented** (upstream deferred) — notifications
   must call `matrix_e2ee.send_message` (message + room_id).
 - Commands fire Home Assistant events only; the integration never calls
@@ -240,8 +249,10 @@ matrix-nio [examples](https://matrix-nio.readthedocs.io/en/latest/examples.html)
 [element-android#6832](https://github.com/vector-im/element-android/issues/6832),
 Element [device-verification](https://element.io/features/device-verification).
 
-`matrix_e2ee` supports three verification paths (the v0.3.0 wizard automates
-the bot-initiated flow):
+`matrix_e2ee` supports three verification paths (the wizard — v0.3.0
+bot-initiated, reworked in v0.3.1/v0.3.2 to wait for a peer-initiated inbound
+SAS from the user's Matrix client with emoji comparison — automates the SAS
+flow):
 
 ### 1. SAS (mutual, manual confirmation since v0.1.4)
 
@@ -284,8 +295,26 @@ the bot-initiated flow):
   dropped when the peer device was unknown (W1N-170/W1N-172);
   `VERIFICATION_TIMEOUT_SECONDS` 600→240 (fires before nio's `_max_age`).
 - **v0.2.11**: `receive_mac_event` no longer overrides canceled state (W1N-179/#31).
+- **v0.3.12**: Matrix activity events (`matrix_e2ee_message_received`,
+  `matrix_e2ee_verification_done`) + `event.` Bot activity entity + Connection
+  diagnostic binary sensor.
+- **v0.3.9**: SAS driver gate split from the command allowlist — new
+  `verification_peer_users` option (W1N-156/#41); SAS/sync logs demoted
+  warning→info/debug (W1N-188/#38); Connection health binary sensor
+  (W1N-185/#40); URL normalization + single-entry enforcement (W1N-190/#42).
+- **v0.3.8**: `m.key.verification.done` handshake completion for
+  request-based SAS (W1N-183/#35).
+- **v0.3.2**: wizard waits for the inbound SAS to show emojis before moving
+  to the compare step (`_wait_for_inbound` requires `latest_sas_snapshot()` to
+  return `emojis`) — W1N-182/#34.
+- **v0.3.1**: verification wizard now waits for a peer-initiated inbound SAS
+  (options flow no longer starts verification from the bot; `latest_sas_snapshot()`
+  skips verified/canceled transactions) — GitHub #33.
 - **v0.3.0**: bot-initiated device verification wizard (W1N-180/#32).
-- Inbound SAS is gated to `allowed_users` (v0.1.3).
+- Inbound SAS is gated to `allowed_users` (v0.1.3); **since v0.3.9 (W1N-156)
+  the gate is the separate `verification_peer_users` allowlist**, which is
+  unset on hass.windy.lan — only the bot's own account may drive SAS until
+  `@zhiqiang:chans.xyz` is added there.
 
 ### 2. One-sided fingerprint (added v0.1.3, hardened v0.1.4)
 

hosts/gw.md

@@ -124,3 +124,8 @@ from `192.168.55.254` reached the UniFi controller at `192.168.66.46` with
 3/3 ICMP replies. This supports the AP Inform path to
 `192.168.66.46:9080`; the controller listener and an online LAN55 AP provide
 the corresponding application-level evidence. No firewall changes were made.
+
+IPv6 was re-verified by read-only SSH on 2026-08-20 during the UniFi AP/AC
+check: the IPv6 routing table shows connected `/64`s on `eth0` (LAN66) and
+`switch0` (LAN55) plus `::/0` via `pppoe0`; both UniFi APs obtained SLAAC
+addresses from the router's RAs. No configuration changes were made.

hosts/ubnt.md

@@ -53,6 +53,11 @@ of `8080`. During adoption or recovery, use the documented `:9080/inform` URL;
 an AP left on `:8080` can remain reachable by ping and SSH while showing
 offline in the controller.
 
+IPv6 is enabled on the controller's `Default` network (`ipv6_enabled: true`,
+client assignment SLAAC; RA is served by `gw`, so `ipv6_interface_type` is
+`none`); both managed APs hold global SLAAC addresses — verified 2026-08-20.
+See [docs/unifi-network.md](../docs/unifi-network.md).
+
 ## Safe reconciliation and verification
 
 ```bash