schema: spec-driven

context: |
  Project: Wedding Invitation & RSVP Automation App (single wedding, not SaaS).
  PRD: rsvp-prd.pdf at repo root — v1.0, 2 Aug 2026, owner Mod Murad. It is the source of truth.
  Architecture: SPLIT (owner decision 2026-08-07, overrides PRD §7.1's single-app stack) —
  monorepo with web/ (Next.js 15 App Router + TypeScript, Tailwind + shadcn/ui, rendering only)
  and api/ (FastAPI + Pydantic v2, SQLAlchemy 2.0 async + Alembic, PostgreSQL 16) owning all
  business logic, data access, and authorization. NO REDIS and no message broker — the
  message_job table IS the queue, claimed with FOR UPDATE SKIP LOCKED; the worker is an
  APScheduler process (hourly planner + 30s sender poll).
  Caddy reverse-proxies /api/* to FastAPI so both share one origin (no CORS).
  Two environments via explicit compose overlays driven by a Makefile: `make dev` (mounted
  source, hot reload, exposed DB port, DRY_RUN=true) and `make prod` (baked images, TLS,
  no published DB port). Never use docker-compose.override.yml — overlays are always explicit.
  OpenAPI generates the TypeScript client; CI fails on a stale client.
  Admin auth: Google sign-in OR username+password (owner decision 2026-08-18, partly reversing
  the 2026-08-07 Google-only decision and restoring most of PRD FR-4.1; TOTP is still out).
  An account is one kind or the other, fixed at creation. Passwords are Argon2id hashes.
  Sessions are a 2-day JWT in an httpOnly cookie carrying identity only — role, status and
  scope are re-read from the database every request. Two roles: super_admin sees everything;
  host sees only the events they own (event.owner_admin_id) and the guests under them.
  Animation: Framer Motion (UI), GSAP + ScrollTrigger (card reveal), canvas-confetti.
  Channels: v1 is EMAIL-ONLY (owner decision 2026-08-07, overrides PRD) — WhatsApp Business
  Cloud API and Bangladesh SMS gateway are deferred to v2; the provider interface stays channel-shaped.
  Locale: Bangla (bn) + English (en); timezone Asia/Dhaka; phone numbers normalised to E.164 (+880...).
  Three events: Mehedi, Marriage Ceremony, Walima — the Invitation (guest x event) is the unit of tracking, not the Guest.
  Scale: 300-1,500 guests, ~3,000 messages per reminder wave.
  Key invariants: idempotent message sends (invitation:schedule:channel unique key),
  cancellation is POST-only, headcount counts only accepted invitations summing party_size,
  128-bit crypto-random URL-safe tokens (22 chars), quiet hours 22:00-08:00 local.
  Requirement IDs (FR-x.y) and priorities (P0/P1/P2) come from the PRD — reference them in specs.

# Project context (optional)
# This is shown to AI when creating artifacts.
# Add your tech stack, conventions, style guides, domain knowledge, etc.
# Example:
#   context: |
#     Tech stack: TypeScript, React, Node.js
#     We use conventional commits
#     Domain: e-commerce platform

# Per-artifact rules (optional)
# Add custom rules for specific artifacts.
# Example:
#   rules:
#     proposal:
#       - Keep proposals under 500 words
#       - Always include a "Non-goals" section
#     tasks:
#       - Break tasks into chunks of max 2 hours

# Per-operation guidance (optional)
# Add advisory guidance for how apply and archive work should be conducted.
# This is separate from artifact rules above.
# Example:
#   operations:
#     apply:
#       guidance:
#         - Keep test summaries concise
#     archive:
#       guidance:
#         - Summarize the archive outcome before finishing
