diff --git a/docs/215-strictmodes-verification.md b/docs/215-strictmodes-verification.md
new file mode 100644
index 0000000..75cfa52
--- /dev/null
+++ b/docs/215-strictmodes-verification.md
@@ -0,0 +1,57 @@
+# Ticket #215 verification — SSH StrictModes on /home/hatch
+
+Date: 2026-10-09 ~23:00 UTC
+Operator: operator-646 (muse-646-patha)
+Branch: `dev/646/215-strictmodes-fix`
+
+## Ticket premise
+
+#215 claims OpenSSH StrictModes rejects public-key auth on port 2226
+"for user hatch" because `/home/hatch` is `drwxrws---` (group-writable
+setgid), and asks whether `chmod g-w /home/hatch` or `StrictModes no`
+permits dial-in.
+
+## Investigation
+
+1. **No `hatch` user exists.** `/etc/passwd` has only `root` plus system
+   `nologin` users. The only viable dial-in identity is `root`
+   (`PermitRootLogin without-password`, i.e. pubkey-only).
+2. **Effective sshd config** (`sshd -T`): `strictmodes yes`,
+   `authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2`
+   (relative to the login user's passwd home — for root, `/root`).
+3. **Root's auth path is StrictModes-clean** and does not include
+   `/home/hatch`:
+   - `/` → `755 root:root`
+   - `/root` → `700 root:root`
+   - `/root/.ssh` → `700 root:root`
+   - `/root/.ssh/authorized_keys` → `600 root:root` (holds 646's
+     `id_ed25519.pub` + `id_frontdoor.pub`, installed by
+     `recover-after-rebuild.sh` §2 — by design)
+4. **Empirical dial-in test (the decisive check).** From the VM over the
+   live reverse tunnel, with `/home/hatch` still `2770` (group-writable):
+   `ssh -p 2226 root@127.0.0.1` with agent-forwarded `id_frontdoor`
+   → `DIALIN_OK`, `whoami` → `root`. Public-key dial-in on 2226
+   **works with zero changes**.
+
+## Verdict
+
+Neither proposed remediation is required or was applied:
+
+- `chmod g-w /home/hatch` — unnecessary for SSH (path not consulted);
+  would also alter the setgid shared-directory semantics for no benefit.
+- `StrictModes no` in sshd config — unnecessary, and would weaken
+  authentication security globally.
+
+The StrictModes denial described in #215 cannot occur for the actual
+login path. No sshd reload was needed (no config changed).
+
+## Adjacent real gap (flagged, not fixed — needs a decision)
+
+`super@bl`'s ed25519 key (`SHA256:UOeqKF5B…`) lives only in
+`/home/hatch/.ssh/authorized_keys`, which sshd **never reads** (no
+`hatch` user exists). If super needs 2226 dial-in, that key must be
+appended to `/root/.ssh/authorized_keys`. The recover script
+deliberately installs only 646's own keys there, so this is a
+provisioning decision for 646/super — left untouched.
+
+Fixes #215