Lucas RayanandClaude Opus 5
eec4a4e520
Sessions and password changes were the two things PLAN.md section 14.2 asks of the account area that were still missing, and the admin console had no audit trail at all despite section 14.3 requiring one for every mutation. Session revocation is enforced on every request, not just recorded. A JWT carries its own validity, so revoking a row without checking it would have made "sign out this device" a button that did nothing until the token expired eight hours later. Changing a password revokes every other session for the same reason: a password change that leaves the attacker's session alive has not locked anyone out. Admin queries are scoped by role in the SQL rather than in the UI, as section 14.3 requires: a DOMAIN_ADMIN calling the API directly sees only its own domain, and a mailbox outside that scope answers 404 rather than 403 so the scope cannot be used to enumerate what exists elsewhere. The two mutations that exist so far - enabling or disabling a mailbox, and retrying or cancelling a queued delivery - write actor, IP and target to audit_log, and there is an endpoint to read it back. Covered by tests against a real database: a revoked token stops working mid-session, a password change needs the current password and takes the other sessions down with it, and the minimum length is enforced. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>