[sloanfinger]

What it delivers

DogPack now handles the platform's user.delete moderation message. moderation.apply_event records the id and ordering decision, sets the user state to deleted (reason dropped, and data.reason nulled in the stored payload), and locks the linked account out at once (banned_until, auth sessions revoked). The platform-moderation function then finds the local user through the custom:devdogsuga identity and calls auth.admin.deleteUser. All DogPack tables reference auth.users with on delete cascade, so profile, enrollments, hosted sessions and rosters, memberships, blocks (both directions) and the onboarding marker go with the account. moderation.user_states keeps only the platform user id with state deleted.

Decisions implemented

• Q48 and section 14 of the deferred-features plan (devdogs-plan): user.delete handling via the admin API, 500 on a failed admin call so the platform retries, 404 / user_not_found counts as success.
• Q168: no new tables, so no new deletion rules. The cascade behaviour is documented in docs/guides/backend.md and the SQL comments, and covered by pgTAP.
• Signature verification and the idempotency mechanism are unchanged. A repeat returns duplicate (200); an unknown platform user returns applied (200).
• Deletion runs on every outcome, including stale and duplicate, because deletion is final on the platform.
• The vendored @devdogsuga/sdk moderation files are untouched (check-vendored.mjs reports all three ok). _shared/user-delete.ts parses user.delete locally; delete it once the vendored copy is re-vendored from a commit that includes DevDogsUGA #215.

New secrets / env

None.

Product decisions for Sloan to confirm

• The user_states row stays with state deleted and no reason, so a late or replayed message about that account is harmless. Say so if you want it purged.
• Earlier ban/suspend payloads for a deleted user stay in moderation.events with their reasons (Q48 does not require nulling).
• Destructive gate: user_states_state_valid is widened with DROP CONSTRAINT + ADD CONSTRAINT, which the destructive gate may flag. Apply the allow-destructive label knowingly if so.

Unverified

• pgTAP (03_moderation.test.sql, plan 59) and the Deno e2e case were not run locally (no Supabase/Docker per machine rules); CI runs them. Assertion count was verified by hand.
• The new apply_event body and constraint change were not applied to a database; the generated migration SQL needs review in CI.
• Audit ran deno check --frozen on the handler (passes) and deno test on _shared (7 passed).
• No Dart, platform or UI code changed; Flutter analyze/test, eslint and vitest not run.

Screenshots

None (no UI).

Part of the DevDogs deferred-features plan, stage A5 (TASK-527). Pairs with DevDogsUGA #215 (A1, the user.delete event type) and #218 (A2, the job that sends it).

🤖 Generated with Claude Code

[sloanfinger]

Reviewed user.delete parsing, moderation recording, retry handling, and local account deletion against main at b836aa541109.

No additional confirmed correctness issue identified in the inspected changes.

Existing CI results were inspected; the complete repository test suite was not rerun for this review.