diff --git a/docs/superpowers/specs/2026-05-15-user-uid-split-design.md b/docs/superpowers/specs/2026-05-15-user-uid-split-design.md
index b19d1dd..1bf6c5e 100644
--- a/docs/superpowers/specs/2026-05-15-user-uid-split-design.md
+++ b/docs/superpowers/specs/2026-05-15-user-uid-split-design.md
@@ -1,5 +1,31 @@
 # How many system users should left4me have? — 1, 2, or 3
 
+**Status: SUPERSEDED 2026-05-15 by the hardening refactor.**
+
+The original question — should left4me have 1, 2, or 3 system users — is
+now answered: **2 users (current state) is correct.** The
+defenses that motivated a 3-user split (DB readability from srcds,
+cross-server ptrace, same-uid /proc visibility, web-side reach into
+gameserver state) are closed by the systemd hardening composition
+landed in the hardening-refactor plan (`docs/superpowers/plans/2026-05-15-hardening-refactor.md`):
+- `PrivateUsers=true` blocks cross-uid ptrace at the kernel level.
+- `PrivatePIDs=true` hides peer processes even when uids match.
+- `TemporaryFileSystem=` + minimal binds hide the DB and web.env from
+  srcds entirely.
+- `SystemCallFilter=~@debug` + empty `CapabilityBoundingSet=` block
+  ptrace at the syscall layer.
+
+The residual filesystem-ACL surface (DB at `0640 root:left4me`,
+web.env same) is a separate concern: a uid split would close it via
+kernel ACLs, but for the current deployment shape it's covered by the
+systemd-imposed FS view. If the deployment shape changes (multi-tenant
+host, shell logins as the service uids, additional services running
+as `left4me` outside these units) the uid split should be revisited.
+
+The original content of this spec is preserved below for context.
+
+---
+
 **Status: open question, not settled design.** This is a handoff
 document. Today left4me has 2 system users: `left4me` (web app +
 gameservers + workshop builds) and `l4d2-sandbox` (script-overlay