pastilhasandClaude Opus 5
80e1a746c0
Amending 10 in place rather than adding 12: it is my own file, nobody has read it or acted on it, and it carried a PREDICTION about deleting green that is now a measurement. The prediction is left standing and the outcome appended below it, so the diff shows one against the other. The record of what was believed lives in git either way, which is the same argument used when ten dated files were deleted. Item 1 of 01 is now observed. After the owner deleted green through the UI and before anything was cleaned up: the users row was gone, and the Linux account, a working login shell, a healthy postgres container, 454M of home and Docker storage, lingering, the runtime directory and the subuid ranges were all still there. Nothing broke, which is what makes it dangerous. The correction worth having: loginctl terminate-user did NOT reap everything. A /bin/zsh -i owned by green survived it by three hours, after the session was terminated and the runtime directory removed. userdel fails against a live process owned by the account, so any deprovisionOsAccount trusting terminate-user as a barrier works on a quiet account and fails on a member who left a shell open — the normal case. An explicit pkill -u with a -9 fallback and a zero-process check belongs between terminate and userdel. Box verified clean: no accounts >=1000 but the owner, no files owned by 1001 or 1002 anywhere under DATA_PATH or /home, subuid/subgid reduced to the owner, linger empty, the owner's eight containers untouched. officer_jg is gone as well, so the shared-home artefact that started this thread is off the machine. Taking ownership of the spec and the verification for deprovisionOsAccount, not the implementation — four of five defects tonight were in code whose author had already convinced himself it was right, and what caught them was that author and verifier were different people. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>