FrameSignal is a spoiler-safe movie decision platform built around one simple idea:
Give viewers the practical answer first, then let them decide how deep they want to go.
Instead of forcing users through long reviews or spoiler-heavy discussion before they can decide whether a movie fits their night, FrameSignal surfaces the decision signals upfront:
- Should I watch it?
- What kind of mood does it fit?
- How heavy does the runtime feel?
- Is it family-safe?
- How risky are the spoilers?
- Is deeper analysis available?
- Where should I check for legal viewing options?
The platform combines a public editorial experience with a protected content-management system, PostgreSQL-backed content, Supabase authentication, Row Level Security, structured media workflows, server-side form handling, editorial governance, and production deployment on Vercel.
Movie discovery usually creates a tradeoff:
Too little information A generic rating or one-line recommendation does not tell you whether a film actually fits your mood, available time, company, or spoiler tolerance.
Too much information Traditional reviews, recaps, videos, and discussion threads can reveal twists, endings, emotional payoffs, or major plot details before you have even decided to watch.
FrameSignal separates those two jobs.
DECISION
↓
SPOILER BOUNDARY
↓
OPTIONAL DEEPER ANALYSIS
The public experience is therefore organized around decisions, not simply around publishing articles.
Each decision-oriented review can surface information such as:
Signal Score
Final Decision
Best For
Avoid If
Mood
Family Safety
Runtime Feel
Spoiler Risk
Best Time to Watch
Legal Watch Signal
This makes the most useful information available before a reader commits to a long editorial article.
Ending content is designed so the introduction can remain safe while major story details begin only after an explicit warning.
The goal is not to pretend ending analysis can be spoiler-free.
The goal is to make the boundary obvious before the spoilers begin.
Theory-oriented content distinguishes between levels of confidence such as:
Confirmed detail
Strong evidence
Possible reading
Speculative theory
Fan interpretation
This keeps interpretation useful while making the difference between evidence and speculation visible to the reader.
Mood-based discovery focuses on viewing context rather than only genre.
Examples can include:
Mind-bending
Emotional
Mystery
Family-safe
Reflective
Tense
The experience can then combine those signals with practical factors such as runtime, spoiler tolerance, and viewing company.
The guided discovery experience considers factors such as:
- Mood
- Company
- Available time
- Spoiler comfort
- Viewing context
The current system is intentionally curated and explainable rather than pretending to be an opaque recommendation engine.
FrameSignal is not a streaming platform.
It does not host films, provide downloads, embed unauthorized streams, or direct users to piracy sources.
Legal Watch Signal exists only to provide editorial guidance around official streaming, rental, purchase, or other authorized viewing options.
FrameSignal is divided into two primary application surfaces:
flowchart TB
Visitor["Public Visitor"]
Staff["Admin / Editor"]
subgraph App["Next.js Application"]
Public["Public Editorial Site"]
Admin["Protected Admin CMS"]
Actions["Server Actions"]
SEO["SEO / Metadata / JSON-LD"]
end
subgraph Supabase["Supabase"]
Auth["Supabase Auth"]
DB[("PostgreSQL")]
RLS["Row Level Security"]
Storage["Media Storage"]
end
Visitor --> Public
Public --> DB
Public --> SEO
Public --> Actions
Staff --> Auth
Auth --> Admin
Admin --> DB
Admin --> Storage
Admin --> Actions
DB --> RLS
Storage --> RLS
Public pages are built primarily around server-side data access.
Published content is queried from Supabase, while safe local fallback content allows the application to continue rendering in development when Supabase data is unavailable.
Public application areas include:
Homepage
Reviews
Movie profiles
Ending Explained
Theory Lab
Mood Signal
Watch Signal Generator
About
Contact
Newsletter
Legal & trust pages
Project Case Study
Draft and archived editorial content are not intended for anonymous public reads.
FrameSignal includes a separate protected administration surface.
Staff access requires:
Valid Supabase authentication
+
Active public.profiles row
+
Allowed admin/editor role
The protected CMS supports workflows around:
- Articles
- Movies
- Taxonomy
- Categories
- Tags
- Genres
- Moods
- CMS pages
- Site settings
- Contact submissions
- Newsletter subscribers
- Media assets
- Editorial audit history
Public navigation does not promote or expose the administration area.
Security is treated as part of the application architecture rather than a visual frontend feature.
- Administrative routes require authenticated active staff.
- Allowed staff roles are checked server-side.
- PostgreSQL Row Level Security acts as a database-level authorization boundary.
- Public queries are restricted to intended published data.
- Public form submissions do not expose private submission tables for reading.
- Admin routes are excluded from public navigation.
- Admin paths are blocked from sitemap exposure.
- Sensitive server credentials are not exposed through
NEXT_PUBLIC_*variables. - The application does not require a service-role key in normal client or CMS workflows.
- Public errors avoid returning raw database/provider details.
FrameSignal includes a controlled media-management workflow backed by Supabase Storage.
Staff Upload
↓
Validation
↓
Draft Media Asset
↓
Credit / License / Alt Text Review
↓
Approval
↓
Attach to Article or Movie
↓
Public Rendering
The media workflow supports:
- JPEG
- PNG
- WebP
- AVIF
- File-size validation
- Required alternative text
- Credit metadata
- License/usage metadata
- Draft/approved state
- Article cover relationships
- Movie poster relationships
- Movie backdrop relationships
- Safe gradient fallback when approved media is unavailable
Public pages only discover media through approved relationships.
There is intentionally no public upload path.
Protected CMS actions can produce a private append-only editorial history.
Tracked areas include operations involving:
Automation drafts
Articles
Movies
Media assets
CMS pages
Site settings
Taxonomy
The audit model records bounded metadata such as:
- Event type
- Entity type
- Actor
- Status transition
- Timestamp
- Safe summary
- Entity reference
The database design adds multiple protection layers so editorial history is not intended to become a normal editable content table.
There is no public audit route.
Contact and newsletter flows use server-side actions.
The current form protection strategy includes:
- Input normalization
- Validation
- Honeypot handling
- Generic public-facing errors
- Supabase insert-only workflows
- Optional Upstash Redis rate limiting
When rate limiting is configured, FrameSignal uses hashed normalized email identifiers rather than storing raw email values in Redis keys.
Current configured limits are designed around short windows for repeated submissions.
Rate limiting remains optional in local development so the application does not depend on Upstash credentials just to run locally.
FrameSignal includes a structured SEO foundation.
- Dynamic metadata
- Sitemap generation
robots.txt- JSON-LD helpers
- Published-content URLs
- Public CMS page URLs
- Article and movie metadata
The application does not fabricate:
Aggregate ratings
Streaming availability
Offers
Watch actions
Embeds
Structured data is intended to represent information FrameSignal actually has rather than inventing schema purely for search appearance.
FrameSignal includes public policy and trust surfaces such as:
- Privacy Policy
- Terms
- DMCA
- Editorial Policy
- Review Methodology
- Correction Policy
- Affiliate Disclosure
- Image Credit Policy
- AI-Use Policy
These pages help define the boundary between editorial opinion, interpretation, copyrighted media, legal viewing guidance, and site operations.
The visual system is designed around an editorial rather than generic dashboard aesthetic.
Near-black editorial surfaces
Warm gold decision accents
Violet theory accents
High-contrast typography
Restrained borders
Cinematic spacing
Clear spoiler labels
Media-ready aspect ratios
The intent is to feel like a focused movie publication and decision product rather than a streaming clone or poster gallery.
Public experiences are designed to stay as server-oriented as practical.
Key principles include:
- Server Components as the default
- Server-side public data reads
- No unnecessary public client-component surface
- Public/admin dependency separation
- Cached/revalidated published reads
- Responsive
next/imagehandling for approved media - Stable aspect-ratio fallbacks
- Sitemap/robots generated inside the application
- Production route and runtime QA
Performance documentation is kept in the repository rather than claiming unsupported Lighthouse scores.
FrameSignal is intentionally not presented as finished.
It is a live, production-minded portfolio product that continues to evolve through focused implementation and QA passes.
Some limitations are deliberate because the project favors controlled workflows over adding features without the necessary safety or product rules.
- No general public user-account system
- No movie hosting or streaming
- No piracy/download functionality
- No opaque recommendation engine
- No unrestricted media uploads
- No public admin navigation
- No destructive CMS delete workflow yet
- No full email campaign/delivery system yet
- No unsubscribe workflow yet
- No advanced global search yet
- No custom domain yet
Some newer protected workflows may also require final production rollout verification when related database migrations or infrastructure are introduced.
- Improve the Watch Signal Generator
- Expand mood and constraint-based discovery
- Add advanced search
- Add useful filters
- Expand movie/article content types
- Richer article editing
- Draft previews
- Additional review workflows
- Further audit-history presentation
- Continue hardening upload and approval workflows
- Improve image metadata and credits
- Add safer cleanup/replacement strategies
- Continue image-performance QA
- Continue production QA
- Expand abuse protection where justified
- Improve observability
- Add a custom domain
- Continue Core Web Vitals optimization
FrameSignal/
│
├── docs/
│ ├── architecture / implementation notes
│ ├── security verification
│ ├── production QA
│ ├── design documentation
│ ├── performance audits
│ └── roadmap
│
├── public/
│ └── static assets
│
├── src/
│ ├── app/
│ │ ├── (public)/
│ │ └── admin/
│ │
│ ├── components/
│ │ ├── public/
│ │ └── admin/
│ │
│ ├── content/
│ │
│ ├── lib/
│ │ ├── admin/
│ │ ├── auth/
│ │ ├── public/
│ │ ├── seo/
│ │ └── supabase/
│ │
│ └── types/
│
├── supabase/
│ ├── migrations/
│ ├── snippets/
│ ├── config.toml
│ └── seed.sql
│
├── .env.example
├── package.json
├── proxy.ts
└── README.md
Before starting, install:
Node.js
npm
Docker Desktop
Docker is required for the normal local Supabase workflow.
git clone https://github.com/abarman079/FrameSignal.git
cd FrameSignalnpm cicp .env.example .env.localCopy-Item .env.example .env.localAt minimum, local/public configuration uses:
NEXT_PUBLIC_SITE_URL=http://localhost:3000
NEXT_PUBLIC_SUPABASE_URL=<your-local-supabase-url>
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=<your-local-publishable-key>Do not commit .env.local.
Do not put secret credentials into NEXT_PUBLIC_* variables.
npm run supabase:startCheck its status with:
npm run supabase:statusnpm run supabase:resetnpm run supabase:typesnpm run devOpen:
http://localhost:3000
Public contact/newsletter rate limiting can be enabled with server-only Upstash configuration.
UPSTASH_REDIS_REST_URL=
UPSTASH_REDIS_REST_TOKEN=
FORM_RATE_LIMIT_HASH_SECRET=These values must remain server-side.
If they are not configured, local development can continue without the rate limiter.
After creating the first Supabase Auth user, an initial staff profile can be activated manually.
update public.profiles
set role = 'admin',
is_active = true
where id = '<AUTH_USER_UUID>';Verify the UUID carefully before executing the statement.
Admin/editor access depends on both authentication and the corresponding active profile.
| Command | Purpose |
|---|---|
npm run dev |
Start the Next.js development server |
npm run build |
Create a production build |
npm run start |
Run the production build |
npm run lint |
Run ESLint |
npm run supabase:start |
Start local Supabase |
npm run supabase:stop |
Stop local Supabase |
npm run supabase:status |
Show local Supabase status |
npm run supabase:reset |
Apply migrations and seed data |
npm run supabase:types |
Generate TypeScript database types |
FrameSignal is deployed on Vercel with Supabase Cloud providing the production PostgreSQL database, authentication, RLS policies, and supporting backend services.
- Apply required Supabase migrations.
- Regenerate database types where schema changes require it.
- Configure Vercel environment variables.
- Confirm the active admin/editor profile.
- Build successfully.
- Verify public routes.
- Verify protected admin redirects.
- Verify public forms.
- Verify sitemap and robots.
- Verify any newly introduced protected workflow manually.
The repository includes detailed implementation and engineering notes.
- Media Assets & Storage Implementation
- Editorial Audit Trail Implementation
- Content Automation / Editorial Approval Architecture
- Main Design / Media / Typography Plan
- Homepage Polish
- Movie Profile Polish
- Theory Lab Visual Identity
FrameSignal is also a place where I am deliberately practicing decisions that go beyond assembling a frontend.
Public content and protected data access stay server-oriented wherever practical.
Sensitive data does not depend only on hiding buttons or routes in the interface.
Draft and archived editorial content are treated differently from public content.
Public submissions avoid unnecessary tracking data and keep errors generic.
Media starts in reviewable states and requires metadata before approval.
Recommendation-style features remain understandable rather than pretending an opaque algorithm knows the viewer better.
SEO markup should describe real product data, not fabricated ratings or availability.
The product is about decisions and editorial guidance, not film hosting or unauthorized access.
FrameSignal is not intended to become a clone of IMDb, Letterboxd, Rotten Tomatoes, or a streaming service.
Its identity comes from a narrower question:
Can a movie platform help someone make tonight's decision without ruining tomorrow's experience?
That constraint influences the product, content model, visual design, spoiler system, discovery surfaces, CMS, and legal boundaries.
