Skip to content

AGENTS.md

Latest commit

 

History

History
46 lines (40 loc) · 4.26 KB

AGENTS.md

File metadata and controls

46 lines (40 loc) · 4.26 KB
Raw

FrameSignal Agent Rules

FrameSignal is a legal, spoiler-safe movie decision platform. The project blueprint in docs/framesignal-blueprint.md is the source of truth for product direction, stack, security, content policy, and build order.

Working Rules

  • Follow the FrameSignal blueprint before making implementation decisions.
  • Work task by task. Do not build the whole project at once.
  • Keep each task scoped to the requested goal, files, constraints, and acceptance criteria.
  • Build the static frontend with mock data first.
  • Supabase packages, client utilities, and admin auth protection are installed, but do not connect public/CMS data until explicit integration tasks.
  • Protected admin pages may use server-side Supabase queries. Article, movie, and taxonomy create/update workflows exist; do not add additional mutations until a focused CRUD task asks for them.
  • Article and movie create/update server actions exist for the protected admin CMS. Do not add delete, storage/upload, external movie APIs, or public Supabase content reads until explicitly requested.
  • Taxonomy create/update server actions exist for categories, tags, moods, and genres. Do not add taxonomy removal workflows or public filtering until explicitly requested.
  • CMS page create/update and site setting update workflows exist in the protected admin. Do not add page/setting removal workflows or public page rendering from Supabase until explicitly requested.
  • Public content pages may perform server-side read-only Supabase queries for published articles, movies, moods, and genre relationships with mock fallback. Do not add public mutations, tracking, forms, or draft/private data reads until explicitly requested.
  • Public trust/legal/editorial CMS pages may perform server-side read-only Supabase queries for published pages rows with static fallback. Do not add public forms, page mutations, or lawyer-final legal copy unless explicitly requested.
  • SEO metadata, sitemap, robots, and JSON-LD foundations exist. Do not add analytics scripts, fake rating schema, tracking, or SEO-visible private/draft routes unless explicitly requested.
  • Public contact and newsletter forms use server actions with insert-only Supabase writes. Do not add public comments, reactions, tracking, reader accounts, file uploads, or public table reads for contact/newsletter data unless explicitly requested.
  • The initial schema, RLS policy migrations, and seed file exist, but do not apply migrations, load seed data, or connect UI to Supabase until explicitly requested.
  • Do not create public reader signups unless explicitly requested.
  • Do not allow self-promotion to admin or self-activation in profile/auth work.
  • Admin auth exists for staff-only access. Do not add public signup, password reset, OAuth, reader accounts, or new auth flows unless explicitly requested.
  • Do not bypass the active profile role check for admin access.
  • src/types/database.types.ts is a generated-types placeholder. Do not manually edit it after real Supabase type generation.
  • Do not run destructive Supabase commands such as database reset without explicit user confirmation.
  • Do not add authentication, additional database schema changes, CRUD flows, storage, or admin logic until a later task explicitly asks for it.
  • Never add Supabase secret or service role keys to client code.
  • Do not add GSAP, Lenis, Zod, React Hook Form, or extra libraries until requested.
  • Never add piracy, illegal streaming, download, torrent, fake watch button, or fake embedded player features.
  • Use npm for package management. Do not switch to pnpm, yarn, or bun.
  • Keep public UI spoiler-safe and legally framed when UI work begins.
  • Run npm run build and npm run lint before reporting a task as done.
  • Run any task-specific checks requested by the user.
  • Report changed files, commands executed, validation results, and warnings/errors clearly.

Current Build Direction

The safe first-build order is:

  1. Base Next.js project setup.
  2. Project hygiene, shadcn/ui setup, Prettier, docs, and folder skeleton.
  3. Design tokens, fonts, color system, typography, and layout rules.
  4. Static public layout and reusable UI components with mock data.
  5. Public pages and admin shell mock.
  6. Supabase, auth, database, CRUD, media upload, and production data only after the static frontend is clear.