docs(account): record step 6, the account deletion walk

Every row of ACCOUNT_DELETION.md §6 step 6 walked on 2026-10-30 against
website 7bd93b8 with Module-Rust edge on the Carbon rig and Module-uo main
with the local ServUO and a uo-link sidecar: web and app deletions, the other
device's session, the Rust grant leaving the rig, the UO link cleared with and
without the sidecar, the forum's two views, the reserved staff name, the demo
and the last admin. Three findings left unfixed (W1-W3).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
This commit is contained in:
2026-10-30 03:51:14 -05:00
parent a5984ab2ae
commit aa1472bfc4

View File

@@ -390,5 +390,58 @@ Asked while building core (§6 step 2), the same day:
- the deleted staff username is refused at registration and at a username change
- the demo refuses
- the last admin is refused
**Walked 2026-10-30**, every row passing. Two local cores at website `7bd93b8`, one module
each, on throwaway databases: Module-Rust `edge` `e30c7d5` linked to the Carbon rig (Rust
26139947, Carbon 2.0.262, both the latest), and Module-uo `main` `148cf0f` with the local
ServUO on servuo-plugins `main` and a uo-link sidecar built from link `main` (protocol 8). The
app was the step 4 build on the `s22_ultra` emulator.
- **Website, UO-linked.** A player linked to `seed_000` through the real `[link` code, with a
second session open on a phone token, deleted the account from */account*. The site showed
"Your account has been deleted.", and the phone token answered 401 on its next request.
The shard's `WebsiteUserId` tag was gone, the log held `shard.account.unlink` with
`reason: account deleted`, and Admin → Shard listed nothing still linked. A game login over
a real socket before the deletion sent `mob.login` with `webId: "2"`. The same login after
it sent no `webId`.
- **Sidecar stopped.** A second linked player deleted their account while the sidecar was
down. The deletion answered 200 at once, `seed_002` was queued as `pending` with the error
`fetch failed`, and Admin → Shard listed it under *Still linked on the shard*. The shard
still held the tag. When the sidecar started again, the ingest socket connected and the
queued unlink finished within a second. The row cleared and the tag was gone.
- **Forum.** The deleted player's two threads in their guild's Team forum read
"[deleted player]" to a member, on the thread and on the post, in the API and on the guild
page. Staff saw "uwplayer1 (deleted account)" there, with the moderation controls.
- **App, Rust-linked.** A player linked to a stand-in Steam id held `autodoors.use`, granted
from the site, and the app's *My Rust account* showed it as "Carbon rig · has it". They
deleted the account in the app while a web session stayed open. The app opened sign-in,
and the web cookie answered 401 on its next request. The log held `rust.account.unlink`.
The next permission sync, 29 s later, pushed one revoke, and `c.show user` on the rig
listed no permissions.
- **Staff name.** A moderator deleted their own account. `RwMod` was then refused at
registration ("That username is already taken.") and as rwmember's new username on
*/account*. An unused name registered.
- **Demo.** With `DEMO_MODE=true`, `demo-player` saw "This is turned off on the demo site."
on */account*, and an admin's `DELETE /admin/users/:id` on that account answered 403
`DEMO_LOCKED`. An ordinary account on the same demo deleted itself.
- **Last admin.** The UO site's only admin was refused on */admin/account*: "You are the only
admin. Make someone else an admin before you delete your account."
The walk used stand-ins in two places. The Steam link was written straight into
`rust_account_links`, because the rig had no second player to type `/link`. The `[link`
codes and the game logins came from a probe and a small socket client kept outside the repos.
The deletion paths themselves were the real ones.
**Found, not fixed:**
- **W1 (Module-Rust).** `edge` holds an empty file named `Promise.reject(dup)`, committed by
step 3's PR (#70). It is a stray from a tool, not code.
- **W2 (Module-uo).** *Still linked on the shard* says "tried 1 time, and tried again when the
bridge reconnects" about a retry that has not happened yet.
- **W3 (Rust bridge, not deletion).** On Carbon, a group membership for a Steam id the server
has never seen was reported as applied, but `c.show group` listed no users, and later
syncs found nothing to correct. A grant to the same id was reported as not landed and
landed on the next push.
- **Observed, unchanged:** `user.self_delete` names the id only, as §4.1 says, so the
activity log alone cannot tell staff which account deleted itself. The auth slow-down covers the delete route,
so a third call from one address took about 4 s.
7. Then `USER_SAFETY.md` (report, block and hide, now 1.21.0), then `android/PLAN.md` M8's
cutover.