@appsforgood/next-supabase-kit 0.2.1 → 0.4.0

package/assistant-adapters/antigravity.md

@@ -1,65 +0,0 @@
-# Antigravity Adapter
-
-This adapter packages Agent Kit as native Antigravity-style plugin assets while keeping the Agent Kit council contract canonical.
-
-## Source Of Truth
-
-- `AGENTS.md`
-- `AGENT_ROSTER.md`
-- `.agent-kit/agent-roster.json`
-- `MODEL_ROUTING.md`
-- `.agent-kit/model-routing.json`
-- `.agent-kit/project-context.json`
-- `.agent-kit/project-context.md`
-- `.agent-kit/corrections/project-rules.json`
-- `.agent-kit/corrections/agent-rules.json`
-- `COUNCIL.md`
-- `.agent-kit/council-sessions/`
-- `QUALITY_GATES.md`
-
-Runtime command files must wrap those files. Do not fork role definitions, security policy, frontend quality rules, release gates, or session evidence rules into command prompts.
-
-Antigravity commands are instruction adapters. They do not replace or prove execution by `@appsforgood/agent-kit-runtime`; use `agent-kit orchestrate status` and exported run evidence for that claim.
-
-## Activation
-
-```bash
-agent-kit init --activate antigravity
-agent-kit adapter validate antigravity
-```
-
-This installs:
-
-- `.antigravity/agent-kit/plugin.json`
-- `.antigravity/agent-kit/commands/*.toml`
-- `.antigravity/runtime-skills/*/SKILL.md`
-- `.antigravity/agent-kit/README.md`
-
-If the `agy` CLI is available, teams may additionally run its native plugin validation. Agent Kit only requires structural validation because many projects will not have Antigravity installed locally.
-
-## Command Contract
-
-Commands expose short runtime entrypoints:
-
-- `/setup`
-- `/spec`
-- `/audit`
-- `/plan`
-- `/handoff`
-- `/frontend`
-- `/test`
-- `/review`
-- `/security`
-- `/copy`
-- `/ship`
-- `/upgrade`
-
-UI harness commands (`/ui-audit`, `/ui-polish`, `/layout-cleanup`, `/responsive-cleanup`, `/accessibility-pass`, `/distinctiveness-pass`, `/screenshot-critique`, `/browser-qa`) are documented in `.agent-kit/prompts/ui-command-index.md`.
-
-Delivery lifecycle commands are documented in `.agent-kit/prompts/lifecycle-command-index.md`.
-
-Each command must load project context and correction rules when present, select the appropriate roster workflow, record required outputs with `agent-kit session output`, and render sessions when evidence changes.
-
-## Security
-
-Do not place tokens, credentials, private URLs, database URLs, customer data, or hidden model reasoning in Antigravity plugin files, command files, or runtime skills.

package/assistant-adapters/claude-code-subagents.md

@@ -1,38 +0,0 @@
-# Claude Code Subagent Adapter
-
-Claude Code projects can activate Agent Kit by creating project subagents that point back to the canonical council files.
-
-Use `MODEL_ROUTING.md` and `.agent-kit/model-routing.json` when adding model comments or frontmatter to those subagents.
-
-## Suggested Project Layout
-
-```text
-.claude/
-  agents/
-    planner.md
-    lead-architect.md
-    frontend-design-lead.md
-    security-reviewer.md
-    qa-engineer.md
-```
-
-## Subagent Frontmatter Pattern
-
-```md
----
-name: planner
-description: Use for planning, phasing, scope breakdown, workflow routing, and council setup in this repository.
----
-
-Read `AGENTS.md`, `AGENT_ROSTER.md`, `.agent-kit/agent-roster.json`, `.agent-kit/project-context.json`, `.agent-kit/project-context.md`, `.agent-kit/agent-briefs.md` when present, `.agent-kit/corrections/project-rules.json`, `.agent-kit/corrections/agent-rules.json`, `COUNCIL.md`, `.agent-kit/council-sessions/`, and `QUALITY_GATES.md` before making routing decisions.
-
-Start with the Planner workflow. For core changes, hand off to Lead Architect. For frontend changes, require Frontend Design Lead evidence. For auth, RLS, secrets, dependency, external-call, or release-risk changes, require Security Reviewer. Record meaningful decisions, risks, handoffs, human corrections, artifacts, evidence, and verification through Agent Studio session files when available.
-```
-
-## Guardrails
-
-- Keep detailed role behavior in `AGENTS.md` and `AGENT_ROSTER.md`; subagent files should be focused entry points.
-- Document active subagents and verification evidence in `ASSISTANT_ADAPTERS.md`.
-- Record model-selection evidence and limitations in `ASSISTANT_ADAPTERS.md`.
-- Avoid giving a subagent broader tool access than its role needs.
-- Treat Claude subagents as instruction adapters. Use `agent-kit orchestrate ...` and its run evidence when the task requires the executable checkpointed council.

package/assistant-adapters/codex-agents.md

@@ -1,53 +0,0 @@
-# Codex / AGENTS.md Adapter
-
-Use `AGENTS.md` as the primary project instruction surface.
-
-## Required References
-
-- `AGENTS.md`
-- `AGENT_ROSTER.md`
-- `.agent-kit/agent-roster.json`
-- `MODEL_ROUTING.md`
-- `.agent-kit/model-routing.json`
-- `.agent-kit/project-context.json`
-- `.agent-kit/project-context.md`
-- `.agent-kit/agent-briefs.md` when present
-- `.agent-kit/corrections/project-rules.json`
-- `.agent-kit/corrections/agent-rules.json`
-- `COUNCIL.md`
-- `.agent-kit/council-sessions/`
-- `QUALITY_GATES.md`
-
-## Council Custom Agents
-
-After `agent-kit init --activate codex`, council specialists live in `.codex/agents/*.toml`.
-
-Spawn a dedicated custom agent instead of role-playing the whole council in one thread:
-
-- **Planning / scope:** `.codex/agents/planner.toml`
-- **Security / RLS / secrets:** `.codex/agents/security-reviewer.toml` (high reasoning effort)
-- **Frontend UI:** `.codex/agents/frontend-design-lead.toml`
-- **QA / tests:** `.codex/agents/qa-engineer.toml`
-
-Each file sets `model_reasoning_effort` from `.agent-kit/model-routing.json`. Verify model names in your Codex environment against `MODEL_ROUTING.md`.
-
-## Operating Rule
-
-When a task is planning-oriented, ambiguous, risky, frontend-facing, security-sensitive, or release-related, start from the roster workflow instead of treating the request as a single generic implementation pass.
-
-Use `MODEL_ROUTING.md` to choose the model profile or reasoning effort for the active role. Exact model names belong in dated config comments, not in the role definitions.
-
-Before meaningful work, load project context, agent briefs when present, and active correction rules. For meaningful handoffs, record visible decisions and evidence with `agent-kit session checkpoint --file <json>` or individual `agent-kit session ...` commands, then run `agent-kit session render`.
-
-## Verification
-
-Record in `ASSISTANT_ADAPTERS.md`:
-
-- The tool/version or environment where `AGENTS.md` was observed.
-- The command, session, or screenshot that proves the instructions loaded.
-- The model-selection setting or profile used for the active role.
-- Any known limitations or manual invocation steps.
-
-Run `agent-kit adapter validate codex` after activation.
-
-Codex custom agents are instruction adapters. Use `agent-kit orchestrate validate`, `plan`, `run`, and `status` when a task requires the executable checkpointed council; do not infer graph execution from a delegated IDE thread.

package/assistant-adapters/cursor-frontend.mdc

@@ -1,16 +0,0 @@
----
-description: Require Frontend Design Lead evidence for significant UI and component work.
-globs:
-  - "src/app/**"
-  - "src/components/**"
-  - "**/*.css"
-alwaysApply: false
----
-
-# Frontend design gate reminders
-
-Significant UI changes require **Frontend Design Lead** review: brand/content intake, creative-direction rationale, reference-led critique, product-quality scorecard, accessibility, and visual QA evidence.
-
-Delegate to `@frontend-design-lead` in `.cursor/agents/frontend-design-lead.md` for isolated design review context.
-
-Reject generic AI-looking UI that is not specific to the product workflow and content model.

package/assistant-adapters/cursor-planner.mdc

@@ -1,14 +0,0 @@
----
-description: Route ambiguous, planning, and cross-layer requests through the Planner workflow first.
-globs:
-  - "**/*"
-alwaysApply: false
----
-
-# Planner routing
-
-When a request is ambiguous, planning-oriented, roadmap-related, or spans multiple layers, start with the **Planner** workflow before implementation.
-
-Delegate to the `@planner` subagent in `.cursor/agents/planner.md` when the task needs isolated planning context.
-
-Read `AGENTS.md`, `.agent-kit/agent-roster.json`, `MODEL_ROUTING.md`, project context, and active corrections before choosing a workflow.

package/assistant-adapters/cursor-security.mdc

@@ -1,18 +0,0 @@
----
-description: Require Security Reviewer for auth, RLS, secrets, API mutations, and external calls.
-globs:
-  - "supabase/**"
-  - "**/auth/**"
-  - "**/api/**"
-  - "**/middleware.ts"
-  - "**/proxy.ts"
-alwaysApply: false
----
-
-# Security gate reminders
-
-Auth, RLS, data mutation, dependency, secret, external-call, and release-risk changes require **Security Reviewer** review before acceptance.
-
-Delegate to `@security-reviewer` in `.cursor/agents/security-reviewer.md` or Task `security-review` for isolated review context.
-
-Verify OWASP Top 10, IDOR, SSRF, injection, broken auth, and least-privilege boundaries.

package/assistant-adapters/github-copilot-instructions.md

@@ -1,35 +0,0 @@
-# Repository Instructions
-
-This repository uses Agent Kit. Treat `AGENTS.md`, `AGENT_ROSTER.md`, `.agent-kit/agent-roster.json`, `MODEL_ROUTING.md`, `.agent-kit/model-routing.json`, `.agent-kit/project-context.json`, `.agent-kit/project-context.md`, `.agent-kit/agent-briefs.md` when present, `.agent-kit/corrections/project-rules.json`, `.agent-kit/corrections/agent-rules.json`, `COUNCIL.md`, `.agent-kit/council-sessions/`, and `QUALITY_GATES.md` as the source of truth for agent routing, project context, correction rules, model profiles, quality gates, and handoff evidence.
-
-## Workflows
-
-- Planning, phased roadmap, or ambiguous work starts with Planner.
-- Core changes require Lead Architect before implementation.
-- Frontend changes require Frontend Design Lead, brand/content intake, creative-direction rationale, visual QA evidence, state coverage, accessibility checks, and desktop/mobile verification.
-- Auth, RLS, data mutations, dependency changes, external calls, secrets, and release risk require Security Reviewer.
-- Behavior changes require QA evidence.
-- Significant changes require Documentation Maintainer updates.
-- Meaningful work should read local project context and active correction rules before implementation.
-- User corrections should be recorded before continuing, then applied to future sessions when durable.
-- Meaningful multi-agent work should record visible decisions, handoffs, artifacts, and verification in Agent Studio session files when available.
-
-## Validation
-
-Before proposing completion, run the repo's documented checks. For projects installed from this kit, the minimum setup check is:
-
-```sh
-agent-kit audit --min-readiness baseline-setup
-```
-
-Use a stronger gate before claiming best-practice readiness:
-
-```sh
-agent-kit audit --min-readiness best-practice-candidate
-```
-
-Do not claim best-practice readiness while starter placeholders remain in `COUNCIL.md`, `SPEC.md`, `DESIGN.md`, `SECURITY.md`, `TESTING.md`, `DEPLOYMENT.md`, or `ASSISTANT_ADAPTERS.md`.
-
-## Model Selection
-
-Use the active Copilot model selector or organization policy with `MODEL_ROUTING.md`. Repository instructions advise model choice but should not be treated as hard enforcement where Copilot keeps model selection user-controlled.

package/assistant-adapters/github-next-supabase.instructions.md

@@ -1,28 +0,0 @@
----
-applyTo: "app/**/*.{ts,tsx},src/app/**/*.{ts,tsx},pages/**/*.{ts,tsx},src/pages/**/*.{ts,tsx},components/**/*.{ts,tsx},lib/**/*.{ts,tsx},utils/**/*.{ts,tsx},supabase/**/*,*.sql"
----
-
-# Next.js + Supabase Agent Kit Instructions
-
-Follow `AGENTS.md`, `AGENT_ROSTER.md`, `.agent-kit/agent-roster.json`, `MODEL_ROUTING.md`, `.agent-kit/model-routing.json`, `.agent-kit/project-context.json`, `.agent-kit/project-context.md`, `.agent-kit/agent-briefs.md` when present, `.agent-kit/corrections/project-rules.json`, `.agent-kit/corrections/agent-rules.json`, `COUNCIL.md`, `.agent-kit/council-sessions/`, and `QUALITY_GATES.md`.
-
-## Next.js
-
-- Keep Server Component, Client Component, Route Handler, and Server Action boundaries explicit.
-- Do not expose secrets, service-role keys, privileged queries, or admin-only data to client bundles.
-- Preserve loading, empty, error, disabled, success, focus, and mobile states for user-facing changes.
-
-## Supabase
-
-- Enforce authorization with Postgres RLS where applicable.
-- Treat service-role access as server-only.
-- Document migration order, rollback risk, indexes, constraints, and policy changes.
-
-## Council Routing
-
-- Schema, auth, RLS, API behavior, dependency, and release changes require Lead Architect and Security Reviewer handoff.
-- UI changes require Frontend Design Lead evidence before implementation is accepted.
-- Behavior changes require QA evidence and living-doc updates.
-- Use the model profile in `MODEL_ROUTING.md`; treat Copilot model selection as advisory unless the active tool surface can enforce it.
-- Read project context and active corrections before changing behavior.
-- Record visible decisions, handoffs, human corrections, artifacts, and verification with Agent Studio session commands when available.

package/assistant-adapters/model-selection/claude-code-subagents-with-models.md

@@ -1,32 +0,0 @@
-# Claude Code Subagents With Model Notes
-
-Use this as a starter for `.claude/agents/*.md` files. Keep the canonical role definitions in `AGENTS.md` and `AGENT_ROSTER.md`.
-
-```md
----
-name: lead-architect
-description: Use for core architecture, cross-layer changes, package behavior, and technical decisions.
-# June 2026 Agent Kit suggestion:
-# model: opus
-# effort: high
----
-
-Read `AGENTS.md`, `AGENT_ROSTER.md`, `MODEL_ROUTING.md`, `.agent-kit/agent-roster.json`, and `.agent-kit/model-routing.json`.
-
-Review affected layers, preserved behavior, security impact, test plan, docs impact, and required council handoffs before implementation.
-```
-
-```md
----
-name: frontend-design-lead
-description: Use for creative direction, reference-led critique, frontend distinctiveness, product-quality scorecards, and visual QA.
-# June 2026 Agent Kit suggestion:
-# model: opus
-# effort: high
----
-
-Use `DESIGN.md`, `STYLE_GUIDE.md`, `MODEL_ROUTING.md`, and the frontend skills before accepting significant UI work.
-Reject generic AI-looking UI that is not specific to the product content, workflow, audience, and state model.
-```
-
-Record the actual Claude Code behavior, model field support, date, and owner in `ASSISTANT_ADAPTERS.md`.

package/assistant-adapters/model-selection/codex-config.example.toml

@@ -1,32 +0,0 @@
-# Codex model-selection example for Agent Kit.
-# Copy the relevant comments into ~/.codex/config.toml or a trusted project .codex/config.toml.
-# Verify current model availability in your Codex environment before uncommenting.
-#
-# Custom council agents generated by agent-kit live under .codex/agents/*.toml.
-# Run `agent-kit init --activate codex` to create them from the project roster.
-
-# June 2026 Agent Kit suggested baseline:
-# model = "gpt-5.5"
-# model_reasoning_effort = "medium"
-
-# Use high reasoning for Lead Architect, Security Reviewer, and Supabase/Postgres Engineer
-# when spawning custom Codex agents or starting dedicated review threads.
-# model_reasoning_effort = "high"
-
-# Optional custom-agent files can live under .codex/agents/*.toml.
-# Keep each custom agent narrow and point it back to:
-# - AGENTS.md
-# - AGENT_ROSTER.md
-# - .agent-kit/agent-roster.json
-# - MODEL_ROUTING.md
-# - .agent-kit/model-routing.json
-
-# Example custom-agent fragment:
-# name = "lead-architect"
-# description = "Architecture and core-change council review."
-# model = "gpt-5.5"
-# model_reasoning_effort = "high"
-# developer_instructions = """
-# Read AGENTS.md, AGENT_ROSTER.md, MODEL_ROUTING.md, and .agent-kit/agent-roster.json.
-# Review affected layers, preserved behavior, tradeoffs, security impact, test plan, and docs impact.
-# """

package/assistant-adapters/model-selection/cursor-model-selection.mdc

@@ -1,24 +0,0 @@
----
-description: Agent Kit model-selection reminder for Cursor.
-globs:
-  - "**/*"
-alwaysApply: true
----
-
-# Agent Kit Model Selection
-
-Use `MODEL_ROUTING.md` and `.agent-kit/model-routing.json` when choosing a model for the active task.
-
-## June 2026 Recommendations
-
-<!--
-Cursor model selection is controlled by the user, workspace, model picker, or team policy.
-This rule advises routing; it should not be treated as hard enforcement.
--->
-
-- Use a deep reasoning model for Lead Architect, Security Reviewer, Supabase/Postgres Engineer, migrations, RLS, auth, dependencies, release risk, and cross-layer decisions.
-- Use a strong coding model with large context for Next.js Engineer work across App Router, Server Actions, Route Handlers, forms, caching, and UI state.
-- Use a creative/vision-capable model for Frontend Design Lead work, especially screenshot critique, references, and distinctiveness benchmarking.
-- Use a fast or balanced model for low-risk docs, deployment notes, and repeated QA summaries.
-
-Record the selected Cursor model, rule evidence, date, owner, and limitations in `ASSISTANT_ADAPTERS.md`.

package/assistant-adapters/model-selection/github-copilot-model-selection.md

@@ -1,20 +0,0 @@
-# GitHub Copilot Model Selection
-
-Repository instructions can advise model choice, but model selection remains controlled by the Copilot surface, organization policy, and the user's active model picker.
-
-Use `MODEL_ROUTING.md` and `.agent-kit/model-routing.json` before starting agentic work.
-
-## June 2026 Recommendations
-
-<!--
-Select the strongest available Copilot model for architecture, security, Supabase RLS, migrations, release risk, and ambiguous planning.
-Select a faster available model for docs-only cleanup, narrow test triage, or low-risk repeated checks.
-These comments are dated setup guidance, not a guarantee that Copilot will enforce model choice from repository files.
--->
-
-## Evidence To Record
-
-- Copilot surface used: chat, edit, coding agent, PR review, or other.
-- Active model or organization policy, if visible.
-- Instruction file loaded: `.github/copilot-instructions.md` or `.github/instructions/*.instructions.md`.
-- Date, owner, and known limitations.

package/assistant-adapters/orchestrator-runtime.md

@@ -1,39 +0,0 @@
-# Orchestrator Runtime Adapter
-
-`@appsforgood/agent-kit-runtime` is the optional executable layer for the Agent Kit council. IDE rules, subagents, slash commands, and model-routing documents remain instruction adapters; they do not imply that a checkpointed graph ran.
-
-## Activation
-
-```bash
-npm install --save-dev @appsforgood/agent-kit-runtime
-agent-kit orchestrate validate
-agent-kit orchestrate plan "Describe the goal"
-```
-
-Edit `.agent-kit/orchestrator.json`, add provider credential references such as `env:OPENAI_API_KEY` or `keychain:team-openai`, configure at least one deterministic model alias, and set `enabled` to `true` only after validation passes.
-
-## Execution Contract
-
-- Roster workflows compile to explicit, bounded LangGraph nodes.
-- Runs pause at plan, network, worktree-write, host-execution, and final-commit gates when applicable.
-- Mutations occur in an isolated Git worktree. Agent Kit may create one scoped commit after approval; it never merges, pushes, or opens a pull request.
-- Docker is the default mutation command boundary. Network access is off unless configured and approved.
-- Provider and remote MCP requests reject redirects, embedded credentials, non-allowlisted hosts, and private or special-use addresses unless private access is explicitly configured.
-- Stdio MCP servers execute on the host only when both `allowHostExecution` and `sandbox.allowHostMutations` are enabled and the host gate is approved.
-- Run checkpoints live in `.agent-kit/runtime/runtime.sqlite`; redacted run records and JSONL evidence live under `.agent-kit/runtime/runs/` and are ignored by Git.
-
-## Cursor Executor
-
-Set an agent route to `cursor` only when Cursor CLI execution is intentionally required. The runtime invokes argv directly inside the isolated worktree, with no shell, a bounded timeout, minimal inherited environment, and an explicit host-mutation approval. Provider-backed model agents remain the default.
-
-## Verification
-
-Record:
-
-- `agent-kit orchestrate validate --json`
-- the offline `orchestrate plan` output
-- provider and MCP probe results, without credentials
-- run ID, approval decisions, scoped commit, and exported evidence
-- Docker image ID and any private-network or host-execution exception rationale
-
-Use `agent-kit studio serve` to inspect and decide paused runs in the local Studio UI.

package/checklists/accessibility.md

@@ -1,12 +0,0 @@
-# Accessibility Checklist
-
-- Semantic HTML used first.
-- ARIA used only when needed.
-- Keyboard navigation works.
-- Focus states are visible.
-- Color contrast meets WCAG 2.1 AA.
-- Forms have labels and error messages.
-- Custom controls expose state.
-- Content does not rely only on color or motion.
-- Critical flows have keyboard-only smoke coverage.
-- Accessibility tooling or manual checks are documented in `TESTING.md`.

package/checklists/agent-council.md

@@ -1,13 +0,0 @@
-# Agent Council Checklist
-
-- `.agent-kit/agent-roster.json` exists and matches the expected default council contract.
-- `.agent-kit/schemas/agent-roster.schema.json` exists for roster validation.
-- `.agent-kit/schemas/council-session.schema.json` exists for structured session evidence.
-- Planner starts planning, roadmap, ambiguous, and cross-layer requests.
-- Lead Architect reviews core changes before implementation.
-- Security Reviewer joins auth, data mutation, dependency, external-call, secret, and release-risk work.
-- Frontend Design Lead joins user-facing frontend work with creative direction and visual QA evidence.
-- QA Engineer verifies behavior changes before completion.
-- Documentation Maintainer updates living docs when behavior, architecture, release, or standards change.
-- Every handoff records decision, risk, next handoff, and evidence.
-- Missing required outputs are marked missing or partial rather than hidden.

package/checklists/brand-content.md

@@ -1,15 +0,0 @@
-# Brand And Content Checklist
-
-- Product category is named.
-- Primary audience and user needs are written in user language.
-- Real content inventory exists: nouns, labels, records, data fields, examples, and assets.
-- First screen is tied to a real task, object, or workflow.
-- Brand personality has 3-5 visible traits.
-- Existing logo, colors, fonts, platform conventions, and accessibility constraints are captured.
-- Category references are used for learning only; no source is copied.
-- Non-goals name visual tropes, copy patterns, palettes, or layouts to avoid.
-- Anti-references are explicit enough to prevent generic AI-site defaults.
-- Source-safety notes name brand marks, layouts, copy, or assets that must not be copied.
-- At least two creative directions were considered before implementation.
-- Chosen direction affects tokens, layout, copy, imagery, and interaction tone.
-- Missing content or assets are documented instead of hidden behind generic placeholders.

package/checklists/deployment.md

@@ -1,10 +0,0 @@
-# Deployment Checklist
-
-- Required env vars are present.
-- Server-only secrets are not exposed.
-- Migrations are applied in the right order.
-- RLS and Storage policies are verified.
-- Build passes.
-- Smoke tests pass.
-- Logs and monitoring are checked.
-- Rollback steps are documented.

package/checklists/design-critique.md

@@ -1,13 +0,0 @@
-# Design Critique Checklist
-
-- `DESIGN.md` includes a reference set and anti-references.
-- References are used for learning, not copying.
-- Source-safety notes identify brand marks, layouts, copy, or assets that must not be copied.
-- The first screen shows the product's real task, object, content, or workflow.
-- The chosen creative direction is visible in typography, layout, density, color, imagery, copy, and interaction tone.
-- Distinctiveness verdict is recorded as weak, adequate, or strong.
-- Frontend product-quality scorecard records user/task fit, content specificity, visual identity, information architecture, component states, accessibility and interaction, and source safety.
-- Generic AI-site risks are explicitly accepted, changed, or rejected.
-- Desktop and mobile screenshots or previews were reviewed.
-- Important empty, loading, error, disabled, success, and permission states were reviewed.
-- Accessibility and visual QA evidence match the risk of the UI change.

package/checklists/frontend-distinctiveness.md

@@ -1,12 +0,0 @@
-# Frontend Distinctiveness Checklist
-
-- First viewport shows the real product object, task, workflow, content, or decision.
-- Product nouns, labels, data shapes, records, actions, and edge cases are visible or documented.
-- Reference benchmark includes 3-5 references with lessons to learn.
-- Anti-references include 2-3 category tropes, palettes, layouts, copy patterns, or interaction habits to avoid.
-- Source-safety notes explain what must not be copied from references.
-- At least two creative directions were compared before implementation.
-- Asset provenance is recorded for real, generated, licensed, and placeholder visuals.
-- Loading, empty, error, disabled, success, permission, and focus states are covered where relevant.
-- Desktop and mobile evidence exists, plus visual QA for high-risk screens.
-- A design cannot pass if it would still work unchanged for another product in the same category.

package/checklists/frontend-product-quality.md

@@ -1,13 +0,0 @@
-# Frontend Product Quality Checklist
-
-- User/task fit score is at least `1`, and preferably `2`.
-- Content specificity score is at least `1`, and preferably `2`.
-- Visual identity score explains why the result fits this product rather than a generic category.
-- Information architecture score covers primary and secondary workflows.
-- Component state score covers important loading, empty, error, disabled, success, permission, and focus states.
-- Accessibility and interaction score covers keyboard path, focus, contrast, labels, reduced motion, and error feedback.
-- Source-safety score confirms references were learned from, not copied.
-- Total score is at least `10/14` before acceptance.
-- Best-practice claim requires at least `12/14`, no critical zeroes, desktop/mobile screenshot review, and visual QA evidence.
-- Best-practice claim also requires frontend distinctiveness benchmark evidence: first-screen proof, content fingerprint, reference benchmark, asset provenance, state proof, and visual QA proof.
-- `DESIGN.md` records the scorecard verdict and required changes.

package/checklists/frontend-quality.md

@@ -1,21 +0,0 @@
-# Frontend Quality Checklist
-
-- First screen shows the actual product or task.
-- `DESIGN.md` includes product category, audience, user needs, content inventory, brand constraints, and creative direction.
-- Brand/content intake was completed before visual implementation.
-- At least two creative directions were considered.
-- Reference set, anti-references, and source-safety notes are recorded.
-- Design critique verdict is adequate or strong before release.
-- Frontend product-quality scorecard is at least adequate before release.
-- Visual direction fits the domain.
-- No generic AI-site gradient/card defaults.
-- No accent-border cards, glow rails, neon strokes, gradient borders, oversized glass panels, ornamental icon walls, fake dashboard proof, decorative credibility badges, vague SaaS sayings, or layout filler sections unless documented as a brand-system exception.
-- Navigation is clear and predictable.
-- Loading, empty, error, disabled, and success states exist.
-- Mobile layout is designed, not incidental.
-- Component spacing, type, and density are consistent.
-- Forms are accessible and provide useful feedback.
-- Design tokens cover color, typography, spacing, radius, motion, depth, state color, and focus treatment.
-- A product-specific design brief has been used for SaaS, admin, marketplace, content, tool, ecommerce, portfolio/venue, education, community/social, or AI workflow surfaces.
-- Desktop and mobile screenshots have been reviewed with `prompts/screenshot-review.md`.
-- Visual QA tier is documented for high-risk UI changes.

package/checklists/marketing-copy.md

@@ -1,11 +0,0 @@
-# Marketing And Copy Checklist
-
-- `MESSAGING.md` identifies audience, pain, desired outcome, alternatives, differentiator, proof, objections, voice, and conversion goal.
-- Missing positioning inputs are asked as explicit questions before final copy is written.
-- Claims are supported by named proof or marked as assumptions.
-- Headline, subhead, CTA, proof, and objection handling match the same value proposition.
-- Copy uses real product nouns, workflows, constraints, and customer language.
-- CTAs have one primary action and clear secondary actions.
-- Onboarding, empty, error, upgrade, and permission copy provide a useful next step.
-- Risky claims around pricing, privacy, security, compliance, performance, medical, financial, or legal topics are reviewed before release.
-- Marketing Copy Lead hands off to Frontend Design Lead for public-facing layout and visual hierarchy.

package/checklists/owasp.md

@@ -1,12 +0,0 @@
-# OWASP Checklist
-
-- Broken access control: RLS, ownership, tenant boundary, admin checks.
-- Cryptographic failures: secrets, tokens, PII, transport security.
-- Injection: SQL, command, template, prompt, and header injection.
-- Insecure design: abuse cases and missing security controls.
-- Misconfiguration: env vars, CORS, headers, storage, public buckets.
-- Vulnerable components: dependency additions and audit status.
-- Auth failures: login, logout, refresh, session expiry, protected routes.
-- Integrity failures: CI, package installs, migrations, webhooks.
-- Logging failures: errors visible without leaking secrets.
-- SSRF: external URL validation and egress restrictions.

package/checklists/rls.md

@@ -1,10 +0,0 @@
-# Supabase RLS Checklist
-
-- RLS enabled on every user-owned or tenant-owned table.
-- Policies exist for each required operation.
-- Policies enforce `auth.uid()` or tenant membership.
-- Admin policies are explicit and least-privilege.
-- Storage buckets have policies.
-- Service-role use is isolated to server-only code.
-- IDOR attempts are tested.
-- Policy assumptions are documented.

package/checklists/testing.md

@@ -1,12 +0,0 @@
-# Testing Checklist
-
-- Unit tests cover core logic.
-- Regression tests preserve existing behavior.
-- Playwright smoke tests cover critical paths.
-- Visual QA evidence exists for high-risk UI changes.
-- Auth, admin, and data mutations are prioritized.
-- Empty/error/loading states are covered where practical.
-- Test gaps and residual risks are documented.
-- CI gates are documented and match the commands used by the project.
-- Playwright smoke coverage exists for the primary workflow before release.
-- Visual baseline updates require human review and rationale when visual-regression tooling exists.