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>
pastilhasandClaude Opus 5
80e1a746c0