blueprint-internal-offboarding

Offboarding

1. A callable function offboard({ uid }), admin only, declared onCall({ enforceAppCheck: true }, …) with that option first and on the onCall( line (the protect check reads it line by line): updateUser(uid, { disabled: true }), set custom claims to {}, revokeRefreshTokens(uid), then fetch the user AGAIN with getUser(uid) — the record you had is from before the revocation — and write revocations/{uid} with revokedAtSec = Math.floor(new Date(user.tokensValidAfterTime).getTime() / 1000), and an audit entry. auth_time in the rules is in seconds; a value in milliseconds would lock out everyone or no one.
2. The rules' notRevoked() (already in the internal rules) refuses any token whose auth_time is not after that.
3. If the spec says offboarding need not be immediate, still ship the function — it is the only way to remove access before tokens expire — but it need not be on the admin screen.
4. Write test/blueprint/offboarding.spec.ts: after offboard, a token issued before it is refused by the rules and the user cannot sign in again.

Done when the check passes: emulator-test.sh offboarding.

Always

• Read .blueprint/spec.md first. It is the agreed specification; do not widen it.
• When you need a decision, ask it through the blueprint question tool and stop. Do not guess.
• Never enable billing, deploy to production, delete data or handle a credential unless this step's gates say the user approved exactly that.
• Say you are done by stopping; the executor runs the check. Do not claim success yourself.