Note

    Family Shapes Cursor Rules (.cursorrules)

    Secondary automation rules and contribution constraints referenced during AI-assisted work in the Family Shapes repo.

    Source Summary

    Non-negotiable rules for DB changes - All database schema changes must be made via Supabase migrations in supabase/migrations/. Do NOT edit production via the dashboard.

    Imported Context

    Non-negotiable rules for DB changes

    • All database schema changes must be made via Supabase migrations in supabase/migrations/. Do NOT edit production via the dashboard.
    • Before creating a migration, ensure local env is linked and up-to-date:
      • Run make db/reset to rebuild from migrations.
      • Run make db/check to verify NO DRIFT.
    • To create a migration: make db/diff name=0002_<short_description> then make db/reset to verify.
    • CRITICAL: When creating migrations manually, ALWAYS use current timestamp: date +%Y%m%d%H%M%S
    • Migration order is determined by timestamp, NOT the number. NEVER use past/future dates!
    • Never modify the baseline *_0001_baseline_prod_schema.sql. New changes start at 0002_* and up.
    • Regenerate types if relevant: make db/types.
    • Open a PR with checklist:
      • migration file added,
      • make db/reset ok,
      • make db/check → “No drift”,
      • types updated if needed.
    • Only apply to prod via make db/push AFTER PR merge/CI green.

    If a command prompts for a password, use .env with: SUPABASE_PROJECT_REF=... SUPABASE_DB_PASSWORD=...

    Documentation rules (read these before making changes)

    • Authoritative docs live under documentation/.
      • Start with documentation/README.md for the full index.
      • Governance artifacts: documentation/project-master.md, documentation/roadmap.md, documentation/changelog.md.
      • Primary migration/process guide: documentation/agents.md.
    • Agents (Cursor, etc.) must consult documentation/agents.md plus any relevant guides before generating or modifying migrations, RLS, functions, or policies.
    • When updating the database or operational process, update all of the following:
      1. documentation/agents.md (full guide)
      2. .cursorrules (non-negotiable rules)
      3. .zencoder/rules/ entries (automation alignment)
      4. documentation/changelog.md (record the change)
    • Promote [Unreleased] entries in documentation/changelog.md with npm run changelog:release so the release date/time is in sync with reality.
    • PRs that alter the DB workflow must include a summary of changes and updated doc links.

    Community Hub schema

    • New community features are implemented via migrations under supabase/migrations/.
    • Current community schema includes: blog_posts, blog_comments, forums, forum_threads, forum_posts, and resources with RLS.
    • After creating or modifying community tables:
      • Run make db/reset then make db/check (expect “No drift”).
      • Run make db/types to refresh src/types/database.ts if needed.

    Operational guardrails for agents

    • Always use Makefile targets: make db/diff name=..., make db/reset, make db/check, make db/types, make db/push.
    • Do not push if make db/check fails or hangs; seek human input.
    • Never modify or remove *_0001_baseline_prod_schema.sql. New work begins at 0002_* and higher.
    • Do not commit .env or any secrets. Use GitHub Actions secrets for CI and local .env for development.
    • If a migration depends on data, add idempotent statements to supabase/seed.sql (optional), not to the migration.
    • Keep archived pre-baseline files in supabase/_archived_migrations/; do not move them back into the loader path.

    Provenance

    domain:builderdomain:entrepreneuragentsgovernance