Increment 2 - Step 1: Authentication Schema

[angelobarbu]

Increment 2 – Step 1: Authentication Schema

First step of the auth & RBAC increment: the database schema that users, roles and sessions will be built on.

What's new

• db/migrations/0002_auth.sql (append-only, applied to both modulo_dev and modulo_test):
  • users - uuid primary key, case-insensitive citext email (unique), display name, Argon2id password hash, disabled_at for lock-out, not-blank checks.
  • roles - fixed catalogue with stable ids (1 = admin, 2 = user) and user_roles linking table (cascades on user deletion).
  • sessions - stores only the SHA-256 digest of each opaque bearer token (a check constraint enforces exactly 32 bytes), sliding expires_at, last_seen_at, revoked_at, plus a partial index on active sessions per user for "log out everywhere".
  • a reusable set_updated_at() trigger function that later tables will attach as well.
• docs/high_level_design.md - new Data model section with an ER diagram of every table, cross-checked against the migrations and the live database.
• README - current-schema note in the migrations section, status line updated to v0.1.0 shipped / Increment 2 in progress, table of contents, log row 2.1.

Notes

• pgcrypto is not enabled: gen_random_uuid() is built into PostgreSQL 13+ and password hashing happens in libsodium on the server, so only citext is added.
• Tokens themselves are never written to the database - a leaked table cannot be replayed as a login.

Verified: migration applied and re-run as a no-op; constraint probe in a rolled-back transaction - duplicate email differing only by case rejected, short token rejected, user deletion cascades to sessions and roles, updated_at trigger overrides manual values; ctest --preset all 7/7.