# C3 Command Center — Project Context

## Goal
Migrating KHAIZEN CS Command Center from Google Apps Script to Supabase + Next.js + Vercel.

## Stack
- Next.js (App Router), Tailwind, deployed on Vercel
- Supabase (Postgres + Auth + RLS)
- Legacy source lives in sibling repo ~/Desktop/apps-script-1P0T (read via clasp)

## Confirmed decisions (do not re-litigate without flagging)
- QPI is a line item inside invoices.items[], type='qpi' — NEVER a standalone invoice. Confirmed: attaches only on cut_number=2, eligible months March/June/September/December (verified against 6 call sites in JavaScript.html).
- Invoice status lifecycle: draft → submitted → approved/rejected → paid. 'rejected' is editable/resubmittable (goes back toward draft-like editability), NOT a dead end.
- Holiday-pay bug (buildLineItemsWithOverrides missing the Special Holiday Pay block) — FIXED and deployed to production Apps Script.
- RLS is real and enforced on invoices + qpi_qualifications (migration 0008). Approve/reject/reverse/paid all require is_invoice_approver. Content edits locked once submitted, re-opened once rejected, via trigger (not just RLS).
- profiles table is minimal (id, agent_id, is_invoice_reviewer, is_invoice_approver) — NOT the full 19-table role model from SUPABASE_RLS_PLAN.md. That plan is deferred/provisional beyond invoices + qpi_qualifications until those features are actually built.
- Migration 0005's temporary anon-read policy is intentionally still active — real auth.uid() policies coexist with it until the anon policy is deliberately retired.
- Design direction: clean, minimal, mobile-friendly. Stone neutral palette, soft-tinted status pills, monospace for invoice numbers/amounts.

## Process
- Auto-accept for routine file operations (creating/reading/editing files).
- STOP and ask before: running SQL against live Supabase, any RLS/permission change, any business-rule decision not already listed above as confirmed.
- Self-test before reporting done — don't claim something works without actually running/checking it.

## Migration workflow (standing instruction, applies automatically)
- Whenever a new migration `.sql` file is written, immediately `cat` its
  full contents to the terminal — don't wait to be asked. State clearly
  right after: **"Ready to paste into Supabase SQL Editor."**
- I never have DB access to run it. You will always manually copy-select
  the printed text yourself and paste it into Supabase — never assume a
  migration ran just because the file was written.
- After you confirm it ran, always give a verification query to check it
  actually took effect — never just trust a bare "Success" banner (see
  the hard lesson in C3_SPEC.md: this has fired identically for
  migrations that fully ran and ones that silently didn't).
- Remind you to use a fresh SQL Editor tab each time, to avoid
  leftover-paste corruption from a previous script still sitting in the
  editor.