@appsforgood/next-supabase-kit 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/BEST_PRACTICE_EVIDENCE.md +45 -0
- package/CHANGELOG.md +44 -0
- package/CODE_OF_CONDUCT.md +26 -0
- package/CONTRIBUTING.md +48 -0
- package/DOGFOOD.md +121 -0
- package/GOVERNANCE.md +45 -0
- package/LICENSE +21 -0
- package/README.md +251 -0
- package/REPOSITORY_SETTINGS.md +70 -0
- package/RESEARCH_CITATION_POLICY.md +26 -0
- package/SECURITY.md +29 -0
- package/SUPPLY_CHAIN.md +55 -0
- package/SUPPORT.md +28 -0
- package/UPGRADE.md +77 -0
- package/agents/deployment-observability-engineer.md +13 -0
- package/agents/docs-maintainer.md +17 -0
- package/agents/frontend-design-lead.md +22 -0
- package/agents/lead-architect.md +25 -0
- package/agents/marketing-copy-lead.md +20 -0
- package/agents/nextjs-engineer.md +20 -0
- package/agents/planner.md +20 -0
- package/agents/qa-engineer.md +19 -0
- package/agents/research-analyst.md +13 -0
- package/agents/security-reviewer.md +16 -0
- package/agents/supabase-postgres-engineer.md +19 -0
- package/assistant-adapters/README.md +28 -0
- package/assistant-adapters/claude-code-subagents.md +37 -0
- package/assistant-adapters/codex-agents.md +35 -0
- package/assistant-adapters/cursor-agent-kit.mdc +30 -0
- package/assistant-adapters/github-copilot-instructions.md +35 -0
- package/assistant-adapters/github-next-supabase.instructions.md +28 -0
- package/assistant-adapters/model-selection/claude-code-subagents-with-models.md +32 -0
- package/assistant-adapters/model-selection/codex-config.example.toml +29 -0
- package/assistant-adapters/model-selection/cursor-model-selection.mdc +24 -0
- package/assistant-adapters/model-selection/github-copilot-model-selection.md +20 -0
- package/checklists/accessibility.md +12 -0
- package/checklists/agent-council.md +13 -0
- package/checklists/brand-content.md +15 -0
- package/checklists/deployment.md +10 -0
- package/checklists/design-critique.md +13 -0
- package/checklists/frontend-distinctiveness.md +12 -0
- package/checklists/frontend-product-quality.md +13 -0
- package/checklists/frontend-quality.md +20 -0
- package/checklists/marketing-copy.md +11 -0
- package/checklists/owasp.md +12 -0
- package/checklists/rls.md +10 -0
- package/checklists/testing.md +12 -0
- package/checklists/upgrade.md +13 -0
- package/checklists/visual-regression.md +11 -0
- package/design-adapters/claude-design.prompt.md +27 -0
- package/design-adapters/figma.prompt.md +18 -0
- package/design-adapters/google-stitch.prompt.md +36 -0
- package/design-adapters/human-designer-brief.prompt.md +36 -0
- package/design-briefs/admin-dashboard.md +21 -0
- package/design-briefs/ai-workflow-product.md +25 -0
- package/design-briefs/community-social.md +26 -0
- package/design-briefs/content-app.md +21 -0
- package/design-briefs/ecommerce.md +25 -0
- package/design-briefs/education-course.md +25 -0
- package/design-briefs/marketplace.md +21 -0
- package/design-briefs/portfolio-venue.md +25 -0
- package/design-briefs/saas.md +21 -0
- package/design-briefs/tool.md +21 -0
- package/dist/index.d.ts +2 -0
- package/dist/index.js +3521 -0
- package/dist/index.js.map +1 -0
- package/examples/next-supabase-installed/.agent-kit/agent-roster.json +228 -0
- package/examples/next-supabase-installed/.agent-kit/manifest.json +58 -0
- package/examples/next-supabase-installed/.agent-kit/model-routing.json +164 -0
- package/examples/next-supabase-installed/.agent-kit/overrides.json +9 -0
- package/examples/next-supabase-installed/README.md +15 -0
- package/examples/next-supabase-installed/audit-output.json +336 -0
- package/examples/next-supabase-installed/tree.txt +38 -0
- package/model-routing/default-model-routing.json +164 -0
- package/package.json +98 -0
- package/profiles/admin-app.md +17 -0
- package/profiles/content-app.md +17 -0
- package/profiles/marketplace.md +17 -0
- package/profiles/saas.md +17 -0
- package/profiles/stack-next-firebase.md +25 -0
- package/profiles/stack-next-postgres.md +24 -0
- package/profiles/stack-remix-supabase.md +24 -0
- package/prompts/audit-project-setup.md +28 -0
- package/prompts/brand-content-intake.md +17 -0
- package/prompts/copy-review.md +15 -0
- package/prompts/council-session-review.md +17 -0
- package/prompts/creative-direction-matrix.md +22 -0
- package/prompts/design-critique-gate.md +28 -0
- package/prompts/docs-update.md +16 -0
- package/prompts/frontend-design-review.md +29 -0
- package/prompts/frontend-distinctiveness-benchmark.md +32 -0
- package/prompts/frontend-product-quality-scorecard.md +35 -0
- package/prompts/implement-feature.md +14 -0
- package/prompts/migration-review.md +14 -0
- package/prompts/screenshot-review.md +27 -0
- package/prompts/security-review.md +17 -0
- package/prompts/upgrade-review.md +18 -0
- package/prompts/visual-qa-plan.md +16 -0
- package/research/proposed-updates.md +70 -0
- package/research/scan-config.json +261 -0
- package/research/scan-plan.md +24 -0
- package/research/summaries/.gitkeep +1 -0
- package/research/summaries/agent-workflow-patterns.md +37 -0
- package/research/summaries/creative-design-patterns.md +38 -0
- package/research/summaries/design-critique-patterns.md +34 -0
- package/research/summaries/docs-and-agent-patterns.md +64 -0
- package/research/summaries/dogfood-adoption-patterns.md +33 -0
- package/research/summaries/frontend-design-patterns.md +64 -0
- package/research/summaries/frontend-distinctiveness-benchmark-patterns.md +38 -0
- package/research/summaries/frontend-product-quality-rubric-patterns.md +37 -0
- package/research/summaries/maturity-model-patterns.md +29 -0
- package/research/summaries/nextjs-patterns.md +65 -0
- package/research/summaries/repo-health-patterns.md +41 -0
- package/research/summaries/scan-overview.md +46 -0
- package/research/summaries/security-patterns.md +64 -0
- package/research/summaries/supabase-rls-patterns.md +54 -0
- package/research/summaries/supply-chain-patterns.md +38 -0
- package/research/summaries/testing-patterns.md +63 -0
- package/research/summaries/upgrade-lifecycle-patterns.md +26 -0
- package/research/summaries/visual-qa-patterns.md +39 -0
- package/rosters/next-supabase-default-council.json +228 -0
- package/schemas/agent-roster.schema.json +54 -0
- package/schemas/audit-report.schema.json +50 -0
- package/schemas/correction-rules.schema.json +32 -0
- package/schemas/council-session.schema.json +65 -0
- package/schemas/model-routing.schema.json +72 -0
- package/schemas/project-context.schema.json +94 -0
- package/schemas/session-event.schema.json +46 -0
- package/schemas/studio-session.schema.json +48 -0
- package/skills/accessibility-wcag.md +15 -0
- package/skills/agent-handoff-tracing.md +44 -0
- package/skills/best-practice-maturity-review.md +26 -0
- package/skills/content-first-design.md +50 -0
- package/skills/conversion-copywriting.md +38 -0
- package/skills/deployment-observability.md +14 -0
- package/skills/docs-maintainer.md +19 -0
- package/skills/frontend-design-system.md +68 -0
- package/skills/frontend-distinctiveness-benchmark.md +40 -0
- package/skills/frontend-product-quality-rubric.md +59 -0
- package/skills/landing-page-copy.md +29 -0
- package/skills/nextjs-app-router.md +18 -0
- package/skills/onboarding-empty-state-copy.md +37 -0
- package/skills/owasp-security-review.md +19 -0
- package/skills/planning-council.md +21 -0
- package/skills/positioning-messaging.md +42 -0
- package/skills/postgres-migrations.md +14 -0
- package/skills/product-voice-tone.md +35 -0
- package/skills/reference-led-design-critique.md +48 -0
- package/skills/supabase-auth-rls.md +20 -0
- package/skills/testing-qa.md +15 -0
- package/skills/upgrade-maintenance.md +32 -0
- package/skills/visual-regression-qa.md +42 -0
- package/templates/next-supabase/AGENTS.md +138 -0
- package/templates/next-supabase/AGENT_ROSTER.md +98 -0
- package/templates/next-supabase/ASSISTANT_ADAPTERS.md +82 -0
- package/templates/next-supabase/COUNCIL.md +54 -0
- package/templates/next-supabase/DECISIONS.md +45 -0
- package/templates/next-supabase/DEPLOYMENT.md +45 -0
- package/templates/next-supabase/DESIGN.md +171 -0
- package/templates/next-supabase/DOCS.md +62 -0
- package/templates/next-supabase/MESSAGING.md +81 -0
- package/templates/next-supabase/MODEL_ROUTING.md +109 -0
- package/templates/next-supabase/QUALITY_GATES.md +87 -0
- package/templates/next-supabase/SECURITY.md +54 -0
- package/templates/next-supabase/SKILLS.md +221 -0
- package/templates/next-supabase/SPEC.md +114 -0
- package/templates/next-supabase/STYLE_GUIDE.md +104 -0
- package/templates/next-supabase/TESTING.md +68 -0
- package/templates/next-supabase/UPGRADE.md +59 -0
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
# Reference-Led Design Critique Skill
|
|
2
|
+
|
|
3
|
+
## Use When
|
|
4
|
+
|
|
5
|
+
Reviewing or designing a user-facing screen, component system, marketing surface, dashboard, tool, onboarding flow, marketplace, content page, ecommerce flow, portfolio, venue page, community surface, education product, or AI workflow UI where visual quality and product specificity matter.
|
|
6
|
+
|
|
7
|
+
## Goal
|
|
8
|
+
|
|
9
|
+
Prevent generic AI-looking UI by grounding design decisions in a small reference set, explicit anti-references, product content, accessibility, and a written critique verdict before implementation is accepted.
|
|
10
|
+
|
|
11
|
+
## Required Inputs
|
|
12
|
+
|
|
13
|
+
- `DESIGN.md` brand/content inputs and selected creative direction.
|
|
14
|
+
- 3-5 category references to learn from without copying.
|
|
15
|
+
- 2-3 anti-references that show what the product must not look like.
|
|
16
|
+
- Real content, assets, data examples, and workflow constraints.
|
|
17
|
+
- Screenshots or preview links for desktop and mobile when implementation exists.
|
|
18
|
+
|
|
19
|
+
## Critique Workflow
|
|
20
|
+
|
|
21
|
+
1. Identify what each reference teaches: density, hierarchy, navigation, content treatment, typography, imagery, motion, or interaction behavior.
|
|
22
|
+
2. State what must not be copied: brand marks, layouts, proprietary components, exact copy, visual signatures, or protected assets.
|
|
23
|
+
3. Compare the proposed UI against the chosen creative direction and product content.
|
|
24
|
+
4. Score distinctiveness as `weak`, `adequate`, or `strong`.
|
|
25
|
+
5. Apply the frontend product-quality scorecard for user/task fit, content specificity, visual identity, IA, states, accessibility, and source safety.
|
|
26
|
+
6. Reject the work if the first screen could fit any generic product in the same category.
|
|
27
|
+
7. Require the smallest useful visual QA evidence for the risk: screenshot review, Playwright screenshots, Storybook states, visual-regression baseline, or equivalent.
|
|
28
|
+
|
|
29
|
+
## Reject By Default
|
|
30
|
+
|
|
31
|
+
- References used as permission to copy a brand, layout, or source design.
|
|
32
|
+
- One-reference design direction.
|
|
33
|
+
- A UI that has tokens and states but no product-specific point of view.
|
|
34
|
+
- Designs that hide missing content behind abstract gradients, fake dashboards, generic illustrations, or vague copy.
|
|
35
|
+
- Screenshot evidence that omits mobile, empty, error, loading, or permission states when those states affect the workflow.
|
|
36
|
+
|
|
37
|
+
## Review Output
|
|
38
|
+
|
|
39
|
+
Return:
|
|
40
|
+
|
|
41
|
+
- Reference set and anti-references used.
|
|
42
|
+
- What was learned from each reference without copying.
|
|
43
|
+
- Product-specific details that make the UI belong to this project.
|
|
44
|
+
- Generic or AI-slop risks that remain.
|
|
45
|
+
- Distinctiveness verdict: weak, adequate, or strong.
|
|
46
|
+
- Frontend product-quality scorecard verdict and total score.
|
|
47
|
+
- Required design changes before implementation or release.
|
|
48
|
+
- Required screenshot, accessibility, and visual QA evidence.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
# Supabase Auth And RLS Skill
|
|
2
|
+
|
|
3
|
+
## Use When
|
|
4
|
+
|
|
5
|
+
Working on Supabase Auth, SSR clients, middleware, sessions, tables, policies, Storage, or service-role operations.
|
|
6
|
+
|
|
7
|
+
## Checklist
|
|
8
|
+
|
|
9
|
+
- RLS is enabled on user-owned and tenant-owned tables.
|
|
10
|
+
- Policies enforce ownership and tenant boundaries.
|
|
11
|
+
- Service-role key is never exposed to client code.
|
|
12
|
+
- Auth middleware handles session refresh safely.
|
|
13
|
+
- Storage buckets have explicit policies.
|
|
14
|
+
- IDOR attempts are considered and tested.
|
|
15
|
+
- `SPEC.md` contains an RLS policy inventory.
|
|
16
|
+
- Security-sensitive policy assumptions are recorded in `DECISIONS.md`.
|
|
17
|
+
|
|
18
|
+
## Safe Default
|
|
19
|
+
|
|
20
|
+
If a table stores user-specific data, assume it needs RLS before it is queried from application code.
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
# Testing And QA Skill
|
|
2
|
+
|
|
3
|
+
## Use When
|
|
4
|
+
|
|
5
|
+
Adding or reviewing tests, smoke checks, regression coverage, or acceptance evidence.
|
|
6
|
+
|
|
7
|
+
## Checklist
|
|
8
|
+
|
|
9
|
+
- Core logic has unit tests.
|
|
10
|
+
- Preserved behavior has regression tests.
|
|
11
|
+
- Critical user flows have Playwright smoke tests.
|
|
12
|
+
- High-risk UI changes have screenshot or visual-regression evidence.
|
|
13
|
+
- Auth and data mutation paths are prioritized.
|
|
14
|
+
- Network failure, empty state, and error state behavior is covered.
|
|
15
|
+
- Test gaps are documented when infrastructure is missing.
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
# Upgrade Maintenance Skill
|
|
2
|
+
|
|
3
|
+
## Use When
|
|
4
|
+
|
|
5
|
+
Upgrading Agent Kit, Next.js, Supabase, UI libraries, testing tools, release workflows, assistant adapters, or any shared package that can change project behavior.
|
|
6
|
+
|
|
7
|
+
## Goal
|
|
8
|
+
|
|
9
|
+
Make upgrades repeatable, reviewable, reversible, and evidence-backed.
|
|
10
|
+
|
|
11
|
+
## Required Checks
|
|
12
|
+
|
|
13
|
+
- Read `UPGRADE.md`, `CHANGELOG.md`, `ROADMAP.md`, and `DECISIONS.md` before changing versioned behavior.
|
|
14
|
+
- Run `agent-kit diff` before accepting template changes.
|
|
15
|
+
- Use `agent-kit update` only on a branch where conflicts can be reviewed.
|
|
16
|
+
- Preserve valid local overrides in `.agent-kit/overrides.json`.
|
|
17
|
+
- For Next.js upgrades, check official upgrade guidance and codemods.
|
|
18
|
+
- For Supabase upgrades, verify migration history, RLS impact, service-role exposure, generated types, and rollback risk.
|
|
19
|
+
- Run `agent-kit audit --min-readiness baseline-setup` after the upgrade.
|
|
20
|
+
- Use `agent-kit audit --min-readiness best-practice-candidate` only after project-specific evidence is complete.
|
|
21
|
+
- Record package versions, migration order, rollback notes, verification commands, owner, and date.
|
|
22
|
+
|
|
23
|
+
## Output
|
|
24
|
+
|
|
25
|
+
Return:
|
|
26
|
+
|
|
27
|
+
- Upgrade scope.
|
|
28
|
+
- Files and templates changed.
|
|
29
|
+
- Conflicts accepted, deferred, or rejected.
|
|
30
|
+
- Migration and rollback risk.
|
|
31
|
+
- Verification commands and results.
|
|
32
|
+
- Remaining warnings before best-practice readiness.
|
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
# Visual Regression QA Skill
|
|
2
|
+
|
|
3
|
+
## Use When
|
|
4
|
+
|
|
5
|
+
Reviewing or changing user-facing UI, reusable components, app shells, dashboards, marketing pages, visual design tokens, responsive layouts, image-heavy pages, or any screen where appearance is part of the acceptance criteria.
|
|
6
|
+
|
|
7
|
+
## Goal
|
|
8
|
+
|
|
9
|
+
Turn visual quality from subjective review into repeatable evidence. Capture important UI states, compare them across changes, and require intentional approval for visual diffs.
|
|
10
|
+
|
|
11
|
+
## Coverage Tiers
|
|
12
|
+
|
|
13
|
+
- Baseline: desktop and mobile screenshots reviewed with `prompts/screenshot-review.md`.
|
|
14
|
+
- Strong: Playwright screenshot checks for primary workflows and responsive breakpoints.
|
|
15
|
+
- Mature: Storybook stories for reusable component states plus visual regression in CI through a tool such as Chromatic, Argos, Loki, or Playwright snapshots.
|
|
16
|
+
|
|
17
|
+
## Required Checks
|
|
18
|
+
|
|
19
|
+
- Primary screens have screenshot evidence for desktop and mobile.
|
|
20
|
+
- Reusable components have meaningful state coverage: default, hover/focus where practical, loading, empty, error, disabled, success, permission-denied, and mobile.
|
|
21
|
+
- Dynamic data, animations, dates, avatars, ads, third-party widgets, and generated media are stabilized, mocked, or masked before visual comparison.
|
|
22
|
+
- Baseline updates are reviewed as product changes, not accepted automatically.
|
|
23
|
+
- Visual diffs are linked in PRs, CI artifacts, or review notes.
|
|
24
|
+
- Accessibility and interaction tests still run; visual diffs do not replace semantic checks.
|
|
25
|
+
|
|
26
|
+
## Reject By Default
|
|
27
|
+
|
|
28
|
+
- A single happy-path screenshot as final UI evidence.
|
|
29
|
+
- Visual baselines updated without rationale.
|
|
30
|
+
- Full-page visual snapshots that are flaky because dynamic content is uncontrolled.
|
|
31
|
+
- Screenshot tests that ignore mobile, long text, empty data, or error states.
|
|
32
|
+
- Treating a visual testing service as proof of good design without `DESIGN.md` and screenshot review.
|
|
33
|
+
|
|
34
|
+
## Review Output
|
|
35
|
+
|
|
36
|
+
Return:
|
|
37
|
+
|
|
38
|
+
- Visual surfaces covered and missing.
|
|
39
|
+
- Component states covered and missing.
|
|
40
|
+
- Baseline/diff evidence and where it can be reviewed.
|
|
41
|
+
- Flake risks and stabilization strategy.
|
|
42
|
+
- Whether the visual QA tier is appropriate for the change risk.
|
|
@@ -0,0 +1,138 @@
|
|
|
1
|
+
# Agent Setup
|
|
2
|
+
|
|
3
|
+
This project uses explicit agent roles so implementation, security, quality, and documentation do not collapse into one vague assistant.
|
|
4
|
+
|
|
5
|
+
Use `.agent-kit/agent-roster.json` as the default council contract. Use `MODEL_ROUTING.md` and `.agent-kit/model-routing.json` to choose model profiles for each agent. Before meaningful work, read `.agent-kit/project-context.json` and `.agent-kit/project-context.md` when present, then apply active corrections from `.agent-kit/corrections/project-rules.json` and `.agent-kit/corrections/agent-rules.json`. When a request is ambiguous, planning-oriented, or cross-layer, start with Planner and follow the matching workflow in `AGENT_ROSTER.md`. Use `ASSISTANT_ADAPTERS.md` to confirm which AI coding tools load these instructions and how model selection is handled. Record meaningful council sessions in `COUNCIL.md` or the local Agent Studio files under `.agent-kit/council-sessions/`.
|
|
6
|
+
|
|
7
|
+
## Planner
|
|
8
|
+
|
|
9
|
+
Owns planning, scope breakdown, sequencing, and council routing before implementation starts.
|
|
10
|
+
|
|
11
|
+
Responsibilities:
|
|
12
|
+
- Convert requests into phased, checkable work.
|
|
13
|
+
- Decide whether the work is planning-only, frontend-only, security-sensitive, release-related, or a core change.
|
|
14
|
+
- Select or confirm the model profile from `MODEL_ROUTING.md` before delegating complex work.
|
|
15
|
+
- Route core changes to Lead Architect before implementation.
|
|
16
|
+
- Name required handoffs and acceptance evidence.
|
|
17
|
+
- Record council-session workflow, decision, risk, next handoff, and evidence for meaningful multi-agent work.
|
|
18
|
+
- Compare proposed work against `QUALITY_GATES.md` and name the required evidence level.
|
|
19
|
+
- Keep roadmap and delivery status current.
|
|
20
|
+
|
|
21
|
+
## Lead Architect
|
|
22
|
+
|
|
23
|
+
Owns system design, affected-layer mapping, tradeoffs, and final implementation direction.
|
|
24
|
+
|
|
25
|
+
Responsibilities:
|
|
26
|
+
- Confirm existing behavior before changing it.
|
|
27
|
+
- Map each change across data, business logic, presentation, auth, and deployment.
|
|
28
|
+
- Decide whether logic belongs in Supabase SQL/RLS, Route Handlers, Server Actions, Server Components, or client state.
|
|
29
|
+
- Keep changes scoped and preserve behavioral contracts.
|
|
30
|
+
|
|
31
|
+
## Next.js Engineer
|
|
32
|
+
|
|
33
|
+
Owns App Router implementation, Server Components, Client Components, Route Handlers, Server Actions, forms, data loading, caching, and UI state.
|
|
34
|
+
|
|
35
|
+
Responsibilities:
|
|
36
|
+
- Keep server/client boundaries explicit.
|
|
37
|
+
- Avoid exposing secrets or privileged data to client bundles.
|
|
38
|
+
- Provide loading, error, empty, and success states.
|
|
39
|
+
- Preserve accessibility and responsive behavior.
|
|
40
|
+
|
|
41
|
+
## Supabase/Postgres Engineer
|
|
42
|
+
|
|
43
|
+
Owns schema, migrations, RLS policies, Auth integration, Storage policies, SQL functions, triggers, indexes, and seed data.
|
|
44
|
+
|
|
45
|
+
Responsibilities:
|
|
46
|
+
- Enforce authorization in Postgres RLS, not only in UI code.
|
|
47
|
+
- Keep service-role access server-only.
|
|
48
|
+
- Add constraints and indexes that protect data integrity and performance.
|
|
49
|
+
- Document migration order and rollback risks.
|
|
50
|
+
|
|
51
|
+
## Security Reviewer
|
|
52
|
+
|
|
53
|
+
Owns OWASP Top 10 review, auth boundary review, IDOR prevention, input validation, output encoding, SSRF prevention, dependency risk, and secret handling.
|
|
54
|
+
|
|
55
|
+
Responsibilities:
|
|
56
|
+
- Review all data mutations and privileged reads.
|
|
57
|
+
- Verify least privilege for Supabase, API routes, automation tokens, and storage.
|
|
58
|
+
- Flag unsafe dependencies or misconfiguration.
|
|
59
|
+
- Ensure every failure path is explicit and observable.
|
|
60
|
+
|
|
61
|
+
## Frontend Design Lead
|
|
62
|
+
|
|
63
|
+
Owns content-first creative direction, visual quality, design systems, accessibility, and prevention of generic AI-looking UI.
|
|
64
|
+
|
|
65
|
+
Responsibilities:
|
|
66
|
+
- Maintain `DESIGN.md` as the project visual identity and content-direction contract.
|
|
67
|
+
- Require audience, user needs, content inventory, brand constraints, and creative-direction options before implementation.
|
|
68
|
+
- Require reference-set evidence, anti-references, source-safety notes, and a design critique verdict before accepting significant frontend work.
|
|
69
|
+
- Require a frontend product-quality scorecard before accepting significant frontend work.
|
|
70
|
+
- Reject generic gradient heroes, vague SaaS copy, card soup, and fake dashboard metrics.
|
|
71
|
+
- Prefer task-first screens, domain-specific hierarchy, real workflow affordances, and reusable components.
|
|
72
|
+
- Require visual QA evidence for important responsive screens and reusable component states.
|
|
73
|
+
- Maintain WCAG 2.1 AA, keyboard navigation, focus states, and mobile-first behavior.
|
|
74
|
+
- Use design adapters for Stitch, Claude, Figma, or human review when visual direction is weak.
|
|
75
|
+
|
|
76
|
+
## Marketing Copy Lead
|
|
77
|
+
|
|
78
|
+
Owns positioning, value proposition, conversion copy, product voice, and UX copy for public-facing or conversion-facing surfaces.
|
|
79
|
+
|
|
80
|
+
Responsibilities:
|
|
81
|
+
- Maintain `MESSAGING.md` as the positioning, value proposition, voice, proof, objection, and CTA contract.
|
|
82
|
+
- Ask discovery questions when audience, pain, outcome, differentiator, proof, objections, voice, or conversion goal is unclear.
|
|
83
|
+
- Reject vague SaaS copy, unsupported AI claims, invented proof, and headlines that could fit any competitor.
|
|
84
|
+
- Translate product facts into specific headlines, CTAs, onboarding copy, empty states, pricing copy, and objection handling.
|
|
85
|
+
- Handoff public-facing copy to Frontend Design Lead so layout, hierarchy, imagery, and interaction tone reinforce the message.
|
|
86
|
+
- Flag risky pricing, security, privacy, compliance, financial, legal, medical, or performance claims before release.
|
|
87
|
+
|
|
88
|
+
## QA Engineer
|
|
89
|
+
|
|
90
|
+
Owns tests, regression coverage, smoke checks, and acceptance evidence.
|
|
91
|
+
|
|
92
|
+
Responsibilities:
|
|
93
|
+
- Add unit coverage for core logic and edge cases.
|
|
94
|
+
- Add regression tests for preserved behavior.
|
|
95
|
+
- Add Playwright smoke coverage for auth and primary workflows.
|
|
96
|
+
- Add screenshot or visual-regression evidence for high-risk UI changes.
|
|
97
|
+
- Report test gaps explicitly when infrastructure is missing.
|
|
98
|
+
|
|
99
|
+
## Documentation Maintainer
|
|
100
|
+
|
|
101
|
+
Owns living markdown docs.
|
|
102
|
+
|
|
103
|
+
Responsibilities:
|
|
104
|
+
- Validate handoff evidence against `COUNCIL.md` and `.agent-kit/schemas/`.
|
|
105
|
+
- Update `SPEC.md`, `DECISIONS.md`, `DOCS.md`, `ASSISTANT_ADAPTERS.md`, `MODEL_ROUTING.md`, `QUALITY_GATES.md`, `DESIGN.md`, `MESSAGING.md`, `STYLE_GUIDE.md`, `SECURITY.md`, `TESTING.md`, `DEPLOYMENT.md`, and `UPGRADE.md`.
|
|
106
|
+
- Record decisions with context, decision, and consequences.
|
|
107
|
+
- Keep docs actionable for another engineer or agent to continue safely.
|
|
108
|
+
|
|
109
|
+
## Deployment/Observability Engineer
|
|
110
|
+
|
|
111
|
+
Owns deployment config, environment variables, migrations, logs, monitoring, and rollback guidance.
|
|
112
|
+
|
|
113
|
+
Responsibilities:
|
|
114
|
+
- Verify production-critical env vars.
|
|
115
|
+
- Confirm migration and release order.
|
|
116
|
+
- Ensure errors are visible through logs or monitoring.
|
|
117
|
+
- Define rollback and recovery steps for risky changes.
|
|
118
|
+
|
|
119
|
+
## Default Handoff
|
|
120
|
+
|
|
121
|
+
Use this order for feature work:
|
|
122
|
+
|
|
123
|
+
1. Planner classifies the request, maps the workflow, and names the council.
|
|
124
|
+
2. Planner starts or updates an Agent Studio session with `agent-kit session start` when the work is meaningful, risky, or cross-agent, then records fallback notes in `COUNCIL.md` if CLI tooling is unavailable.
|
|
125
|
+
3. Lead Architect maps affected layers and preserved behavior.
|
|
126
|
+
4. Supabase/Postgres Engineer handles schema, RLS, and migrations when data/auth changes are involved.
|
|
127
|
+
5. Next.js Engineer implements runtime behavior and UI.
|
|
128
|
+
6. Frontend Design Lead owns content-first creative direction and reviews UX quality/accessibility when user-facing screens change.
|
|
129
|
+
7. Marketing Copy Lead owns positioning, value proposition, conversion copy, product voice, and UX copy when public-facing or conversion-facing copy changes.
|
|
130
|
+
8. Security Reviewer checks OWASP, auth, data boundaries, dependencies, external calls, and secrets.
|
|
131
|
+
9. QA Engineer adds and runs tests.
|
|
132
|
+
10. Documentation Maintainer updates living docs and council evidence.
|
|
133
|
+
11. Deployment/Observability Engineer verifies release and upgrade readiness.
|
|
134
|
+
12. The active agent records decisions, handoffs, corrections, artifacts, required-output status, verification, and status with `agent-kit session ...` commands, then runs `agent-kit session render` so `index.md` and `transcript.md` are current. Run `agent-kit studio export` when the user needs a local visual session view.
|
|
135
|
+
|
|
136
|
+
## Council Rule
|
|
137
|
+
|
|
138
|
+
Core changes cannot skip Planner or Lead Architect. Frontend changes cannot skip content/brand intake, creative-direction rationale, reference-led critique, product-quality scorecard, visual QA evidence, and Frontend Design Lead review. Public-facing or conversion-facing copy changes cannot skip Marketing Copy Lead discovery questions, value proposition, proof, objection, voice/tone, and CTA review. Auth, RLS, data mutation, dependency, secret, external-call, and release-risk changes cannot skip Security Reviewer. Behavior changes cannot skip QA evidence. Significant changes cannot skip Documentation Maintainer. Meaningful multi-agent work cannot skip a decision, risk, next-handoff, required-output status, and evidence record. Human corrections must be recorded before continuing work, and durable project or agent corrections must be applied in future sessions. Work is not best-practice ready until it satisfies the relevant `QUALITY_GATES.md` evidence level.
|
|
@@ -0,0 +1,98 @@
|
|
|
1
|
+
# Agent Roster
|
|
2
|
+
|
|
3
|
+
This project uses `.agent-kit/agent-roster.json` as the default council contract. Agents should use it before planning, implementation, review, and handoff. Use `MODEL_ROUTING.md` and `.agent-kit/model-routing.json` to select model profiles for each agent. The roster contract is backed by `.agent-kit/schemas/agent-roster.schema.json`.
|
|
4
|
+
|
|
5
|
+
## Default Rule
|
|
6
|
+
|
|
7
|
+
Planner handles planning by default. Lead Architect reviews core changes before implementation. Frontend Design Lead owns content-first creative direction, reference-led critique, frontend distinctiveness benchmarking, product-quality scoring, and visual QA before significant frontend implementation is accepted. Marketing Copy Lead owns positioning, value proposition, public-facing copy, proof, objections, voice, and CTA hierarchy before conversion-facing copy is accepted. Security Reviewer, QA Engineer, Documentation Maintainer, and Deployment/Observability Engineer join when their trigger areas are touched. Meaningful multi-agent work records council-session evidence in `COUNCIL.md` or a structured record that follows `.agent-kit/schemas/council-session.schema.json`.
|
|
8
|
+
|
|
9
|
+
## Default Workflows
|
|
10
|
+
|
|
11
|
+
### Planning
|
|
12
|
+
|
|
13
|
+
Use when the request asks for a plan, roadmap, phases, scope, or a breakdown.
|
|
14
|
+
|
|
15
|
+
Handoff order:
|
|
16
|
+
|
|
17
|
+
1. Planner
|
|
18
|
+
2. Lead Architect
|
|
19
|
+
3. QA Engineer
|
|
20
|
+
4. Documentation Maintainer
|
|
21
|
+
|
|
22
|
+
### Core Change
|
|
23
|
+
|
|
24
|
+
Use when the request touches schema, auth, RLS, API behavior, Server Actions, Route Handlers, dependency changes, package behavior, upgrade workflows, release workflows, or cross-layer architecture.
|
|
25
|
+
|
|
26
|
+
Handoff order:
|
|
27
|
+
|
|
28
|
+
1. Planner
|
|
29
|
+
2. Lead Architect
|
|
30
|
+
3. Supabase/Postgres Engineer
|
|
31
|
+
4. Next.js Engineer
|
|
32
|
+
5. Security Reviewer
|
|
33
|
+
6. QA Engineer
|
|
34
|
+
7. Documentation Maintainer
|
|
35
|
+
8. Deployment/Observability Engineer
|
|
36
|
+
|
|
37
|
+
### Frontend Change
|
|
38
|
+
|
|
39
|
+
Use when the request touches screens, components, layout, visual design, accessibility, responsiveness, or screenshot review.
|
|
40
|
+
|
|
41
|
+
Handoff order:
|
|
42
|
+
|
|
43
|
+
1. Planner
|
|
44
|
+
2. Frontend Design Lead
|
|
45
|
+
3. Marketing Copy Lead when the surface is public-facing or conversion-facing
|
|
46
|
+
4. Next.js Engineer
|
|
47
|
+
5. QA Engineer
|
|
48
|
+
6. Documentation Maintainer
|
|
49
|
+
|
|
50
|
+
Required outputs:
|
|
51
|
+
|
|
52
|
+
- Brand/content intake
|
|
53
|
+
- Copy/value-proposition brief when public-facing or conversion-facing
|
|
54
|
+
- Creative-direction rationale
|
|
55
|
+
- Reference-set evidence
|
|
56
|
+
- Frontend distinctiveness benchmark
|
|
57
|
+
- Design critique verdict
|
|
58
|
+
- Frontend product-quality scorecard
|
|
59
|
+
- Domain-specific UI rationale
|
|
60
|
+
- Visual QA evidence
|
|
61
|
+
- State coverage
|
|
62
|
+
- Accessibility checks
|
|
63
|
+
- Desktop/mobile verification
|
|
64
|
+
|
|
65
|
+
### Marketing Copy
|
|
66
|
+
|
|
67
|
+
Use when the request touches copy, copywriting, marketing, positioning, messaging, value proposition, landing pages, headlines, CTAs, conversion, onboarding, empty states, or pricing.
|
|
68
|
+
|
|
69
|
+
Handoff order:
|
|
70
|
+
|
|
71
|
+
1. Planner
|
|
72
|
+
2. Marketing Copy Lead
|
|
73
|
+
3. Frontend Design Lead
|
|
74
|
+
4. QA Engineer
|
|
75
|
+
5. Documentation Maintainer
|
|
76
|
+
|
|
77
|
+
Required outputs:
|
|
78
|
+
|
|
79
|
+
- Discovery questions answered or explicitly marked unknown
|
|
80
|
+
- Audience and segment assumptions
|
|
81
|
+
- Problem, pain, desired outcome, and value proposition
|
|
82
|
+
- Differentiators, proof points, objections, and counter-messaging
|
|
83
|
+
- Voice/tone guidance
|
|
84
|
+
- Page or flow copy inventory
|
|
85
|
+
- CTA and conversion hypothesis
|
|
86
|
+
- Handoff notes for design and implementation
|
|
87
|
+
|
|
88
|
+
## Handoff Rules
|
|
89
|
+
|
|
90
|
+
- Each agent must state its decision, risk, and required next handoff.
|
|
91
|
+
- Each meaningful council session must record workflow, affected layers, required outputs, handoff decisions, risks, evidence, and verification status.
|
|
92
|
+
- Core changes cannot skip Lead Architect.
|
|
93
|
+
- Frontend changes cannot skip content/brand intake, creative-direction rationale, reference-set evidence, distinctiveness benchmark, design critique verdict, product-quality scorecard, visual QA evidence, or Frontend Design Lead review.
|
|
94
|
+
- Public-facing or conversion-facing copy cannot skip Marketing Copy Lead discovery questions, value proposition, proof, objection, voice/tone, and CTA review.
|
|
95
|
+
- Auth, data mutation, dependency, external-call, secret, and release-risk changes cannot skip Security Reviewer.
|
|
96
|
+
- Behavior changes cannot skip QA evidence.
|
|
97
|
+
- Significant changes cannot skip living docs.
|
|
98
|
+
- Upgrade changes cannot skip `UPGRADE.md`, conflict review, audit evidence, and rollback notes.
|
|
@@ -0,0 +1,82 @@
|
|
|
1
|
+
# Assistant Adapters
|
|
2
|
+
|
|
3
|
+
Use this file to record how the agent council is activated in the AI coding tools used by this project.
|
|
4
|
+
|
|
5
|
+
Canonical source of truth:
|
|
6
|
+
|
|
7
|
+
- `AGENTS.md`
|
|
8
|
+
- `AGENT_ROSTER.md`
|
|
9
|
+
- `.agent-kit/agent-roster.json`
|
|
10
|
+
- `MODEL_ROUTING.md`
|
|
11
|
+
- `.agent-kit/model-routing.json`
|
|
12
|
+
- `.agent-kit/project-context.json`
|
|
13
|
+
- `.agent-kit/project-context.md`
|
|
14
|
+
- `.agent-kit/corrections/project-rules.json`
|
|
15
|
+
- `.agent-kit/corrections/agent-rules.json`
|
|
16
|
+
- `COUNCIL.md`
|
|
17
|
+
- `.agent-kit/council-sessions/`
|
|
18
|
+
- `.agent-kit/schemas/council-session.schema.json`
|
|
19
|
+
- `.agent-kit/schemas/studio-session.schema.json`
|
|
20
|
+
- `.agent-kit/schemas/session-event.schema.json`
|
|
21
|
+
- `.agent-kit/schemas/project-context.schema.json`
|
|
22
|
+
- `.agent-kit/schemas/correction-rules.schema.json`
|
|
23
|
+
- `QUALITY_GATES.md`
|
|
24
|
+
|
|
25
|
+
## Active Tool Surfaces
|
|
26
|
+
|
|
27
|
+
| Tool | Instruction surface | Instruction status | Model-selection status | Enforcement | Evidence | Notes |
|
|
28
|
+
| --- | --- | --- | --- | --- | --- | --- |
|
|
29
|
+
| Codex / AGENTS.md-compatible tools | `AGENTS.md`, optional `.codex/config.toml`, optional `.codex/agents/*.toml` | TBD | TBD | Partial | TBD | Confirm the tool loads root `AGENTS.md`, follows council routing, and uses `MODEL_ROUTING.md` for model choice. |
|
|
30
|
+
| GitHub Copilot / VS Code | `.github/copilot-instructions.md` and `.github/instructions/*.instructions.md` | TBD | TBD | Advisory | TBD | Use `.agent-kit/assistant-adapters/github-copilot-instructions.md`, `github-next-supabase.instructions.md`, and `model-selection/github-copilot-model-selection.md` as starting points. |
|
|
31
|
+
| Cursor | `.cursor/rules/cursor-agent-kit.mdc` and `.cursor/rules/cursor-model-selection.mdc` | Active on init | Advisory | Advisory | `agent-kit init` copies canonical rules from `.agent-kit/assistant-adapters/`; verify in Cursor Settings > Rules that both rules load. | `agent-kit init` installs `.cursor/rules/cursor-agent-kit.mdc` and `.cursor/rules/cursor-model-selection.mdc`. Re-run `agent-kit diff` after kit updates if the canonical adapter files changed. |
|
|
32
|
+
| Claude Code | `.claude/agents/*.md` and optional `CLAUDE.md` | TBD | TBD | Partial | TBD | Use `.agent-kit/assistant-adapters/claude-code-subagents.md` and `model-selection/claude-code-subagents-with-models.md` as starting points. |
|
|
33
|
+
|
|
34
|
+
## Model Selection
|
|
35
|
+
|
|
36
|
+
- Use `.agent-kit/model-routing.json` as the provider-neutral routing contract.
|
|
37
|
+
- Use `MODEL_ROUTING.md` for dated setup comments and evidence requirements.
|
|
38
|
+
- Treat exact model names as June 2026 recommendations that must be reviewed when IDE or provider docs change.
|
|
39
|
+
- Do not claim per-agent model enforcement in tools where model selection is controlled by a user picker, organization policy, or hosted agent setting.
|
|
40
|
+
|
|
41
|
+
## Adapter Rules
|
|
42
|
+
|
|
43
|
+
- Keep `AGENTS.md`, `AGENT_ROSTER.md`, and `.agent-kit/agent-roster.json` as the source of truth.
|
|
44
|
+
- Adapter files should reference the council contract; they should not fork role definitions, security policy, frontend quality rules, or release gates.
|
|
45
|
+
- Agents should read project context and active correction rules before meaningful work.
|
|
46
|
+
- Agents should record meaningful decisions, handoffs, human corrections, artifacts, required-output status, and verification with `agent-kit session ...` commands when the CLI is available.
|
|
47
|
+
- Agents should run `agent-kit session render` after changing session evidence so Markdown views stay current.
|
|
48
|
+
- Agents may run `agent-kit studio export` after rendering sessions when a local visual review page would help the user inspect collaboration.
|
|
49
|
+
- Do not place secrets, tokens, credentials, private URLs, or customer data in assistant instruction files.
|
|
50
|
+
- Keep commands concrete and verified. Document known failures or environment prerequisites.
|
|
51
|
+
- Update this file when a tool is added, removed, or confirmed to load the project instructions.
|
|
52
|
+
- Record MCP/tool connector setup separately from model-selection setup. Tool access and model choice are different controls.
|
|
53
|
+
|
|
54
|
+
## Cursor Activation
|
|
55
|
+
|
|
56
|
+
`agent-kit init` installs the canonical Cursor rules automatically:
|
|
57
|
+
|
|
58
|
+
- `.cursor/rules/cursor-agent-kit.mdc`
|
|
59
|
+
- `.cursor/rules/cursor-model-selection.mdc`
|
|
60
|
+
|
|
61
|
+
Verification steps:
|
|
62
|
+
|
|
63
|
+
1. Run `agent-kit init --stack next-supabase` in the target project.
|
|
64
|
+
2. Confirm both files exist under `.cursor/rules/`.
|
|
65
|
+
3. Open Cursor Settings > Rules and verify the rules are active for the workspace.
|
|
66
|
+
4. Start a meaningful task and confirm the agent reads `AGENTS.md`, `.agent-kit/agent-roster.json`, and project context before implementation.
|
|
67
|
+
5. Record the verification date, owner, and evidence path in the Active Tool Surfaces table above.
|
|
68
|
+
|
|
69
|
+
If a project already customized `.cursor/rules/`, review `.agent-kit/conflicts/` after `agent-kit update` before adopting newer adapter wording.
|
|
70
|
+
|
|
71
|
+
## Acceptance Evidence
|
|
72
|
+
|
|
73
|
+
Before claiming strong or best-practice maturity, replace the TBD rows above with:
|
|
74
|
+
|
|
75
|
+
- The active tool and instruction-surface path.
|
|
76
|
+
- The active model profile or model-selection policy.
|
|
77
|
+
- The enforcement level: enforced, partial, advisory, or manual.
|
|
78
|
+
- The command, screenshot, PR, or session evidence proving the instructions loaded.
|
|
79
|
+
- Any manual invocation needed to select the correct agent, rule, or subagent.
|
|
80
|
+
- The Agent Studio session path, rendered Markdown, or audit output proving the agent read context and recorded handoff evidence.
|
|
81
|
+
- Optional `.agent-kit/studio/index.html` evidence when a static local Studio export was used.
|
|
82
|
+
- The date and owner of the verification.
|
|
@@ -0,0 +1,54 @@
|
|
|
1
|
+
# Council Sessions
|
|
2
|
+
|
|
3
|
+
Use this file to record agent council evidence for meaningful planning, core-change, frontend-change, security-review, release, or research work.
|
|
4
|
+
|
|
5
|
+
The machine-readable roster lives at `.agent-kit/agent-roster.json`. Model profile routing lives at `.agent-kit/model-routing.json`. Project-specific context lives in `.agent-kit/project-context.json` and `.agent-kit/project-context.md`. Durable corrections live in `.agent-kit/corrections/`. Schemas live in `.agent-kit/schemas/`. For structured Agent Studio records, write session metadata to `.agent-kit/council-sessions/<session-id>/session.json`, append visible events to `events.jsonl`, and render `index.md` plus `transcript.md`. Run `agent-kit studio export` when a self-contained local HTML view is useful for inspecting sessions. Legacy structured session JSON files should follow `.agent-kit/schemas/council-session.schema.json`. Machine-readable audit output follows `.agent-kit/schemas/audit-report.schema.json`.
|
|
6
|
+
|
|
7
|
+
## Session Template
|
|
8
|
+
|
|
9
|
+
```md
|
|
10
|
+
## YYYY-MM-DD - Short Request Name
|
|
11
|
+
|
|
12
|
+
- Workflow: planning | core-change | frontend-change | security-review | release | research
|
|
13
|
+
- Status: planned | in-progress | blocked | complete
|
|
14
|
+
- Request: What the user asked for
|
|
15
|
+
- Affected layers: data, business logic, presentation, auth, deployment, docs
|
|
16
|
+
|
|
17
|
+
### Required Outputs
|
|
18
|
+
|
|
19
|
+
| Output | Status | Evidence |
|
|
20
|
+
| --- | --- | --- |
|
|
21
|
+
| Phased checklist | Missing/Partial/Complete/N/A | Link or note |
|
|
22
|
+
| Architecture decision | Missing/Partial/Complete/N/A | Link or note |
|
|
23
|
+
| Security review | Missing/Partial/Complete/N/A | Link or note |
|
|
24
|
+
| Test evidence | Missing/Partial/Complete/N/A | Command or report |
|
|
25
|
+
| Visual QA evidence | Missing/Partial/Complete/N/A | Screenshot, Storybook, or visual diff |
|
|
26
|
+
| Docs impact | Missing/Partial/Complete/N/A | Updated file |
|
|
27
|
+
|
|
28
|
+
### Handoffs
|
|
29
|
+
|
|
30
|
+
| Agent | Decision | Risk | Next Handoff | Evidence |
|
|
31
|
+
| --- | --- | --- | --- | --- |
|
|
32
|
+
| Planner | TBD | TBD | Lead Architect | TBD |
|
|
33
|
+
|
|
34
|
+
### Verification
|
|
35
|
+
|
|
36
|
+
| Command Or Review | Result | Notes |
|
|
37
|
+
| --- | --- | --- |
|
|
38
|
+
| TBD | Pass/Fail/Skipped | TBD |
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
## Rules
|
|
42
|
+
|
|
43
|
+
- Every handoff must include decision, risk, next handoff, and evidence.
|
|
44
|
+
- Meaningful multi-agent work should use `agent-kit session start`, `decision`, `handoff`, `correct`, `artifact`, `verify`, `output`, and `render` when the CLI is available.
|
|
45
|
+
- Static Studio export is optional, but exported HTML must be regenerated after session evidence changes and must not contain secrets.
|
|
46
|
+
- Structured session JSON records must pass `agent-kit audit`.
|
|
47
|
+
- Agent Studio `events.jsonl` rows must stay append-only, valid JSONL, and free of secrets.
|
|
48
|
+
- Required outputs must be explicitly marked `complete`, `not-applicable`, `missing`, or `partial`; do not close a session as complete while any required output is still missing or partial.
|
|
49
|
+
- Core changes must include Lead Architect evidence.
|
|
50
|
+
- Auth, data mutation, dependency, external-call, secret, and release-risk work must include Security Reviewer evidence.
|
|
51
|
+
- User-facing frontend work must include Frontend Design Lead, reference-set evidence, design critique verdict, creative direction, accessibility, and visual QA evidence.
|
|
52
|
+
- Public-facing or conversion-facing copy work must include Marketing Copy Lead evidence, discovery questions, value proposition, proof, objections, voice/tone, and CTA hierarchy.
|
|
53
|
+
- Behavior changes must include QA evidence or a documented test gap.
|
|
54
|
+
- Human corrections must be recorded before continuing work and promoted into durable project or agent rules when they should affect future sessions.
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
# Decisions
|
|
2
|
+
|
|
3
|
+
Record architectural, technical, security, release, and design-direction decisions here.
|
|
4
|
+
|
|
5
|
+
## Template
|
|
6
|
+
|
|
7
|
+
```md
|
|
8
|
+
## YYYY-MM-DD - Decision Title
|
|
9
|
+
|
|
10
|
+
### Context
|
|
11
|
+
|
|
12
|
+
What problem, constraint, or tradeoff forced this decision?
|
|
13
|
+
|
|
14
|
+
### Decision
|
|
15
|
+
|
|
16
|
+
What did we choose?
|
|
17
|
+
|
|
18
|
+
### Consequences
|
|
19
|
+
|
|
20
|
+
What becomes easier, harder, safer, or riskier because of this decision?
|
|
21
|
+
|
|
22
|
+
### Follow-Up
|
|
23
|
+
|
|
24
|
+
What should be revisited later?
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
## Active Decisions
|
|
28
|
+
|
|
29
|
+
Add new decisions above this line or keep newest first.
|
|
30
|
+
|
|
31
|
+
Record major frontend choices here when a creative direction, reference set, anti-reference, brand constraint, information architecture, visual QA tier, or component-system rule materially affects implementation.
|
|
32
|
+
|
|
33
|
+
## Agent Kit Model Routing
|
|
34
|
+
|
|
35
|
+
### Context
|
|
36
|
+
|
|
37
|
+
AI coding tools differ in whether repository files can enforce per-agent model selection.
|
|
38
|
+
|
|
39
|
+
### Decision
|
|
40
|
+
|
|
41
|
+
Use `MODEL_ROUTING.md` and `.agent-kit/model-routing.json` as the provider-neutral source for agent model profiles. Record IDE-specific setup and limitations in `ASSISTANT_ADAPTERS.md`.
|
|
42
|
+
|
|
43
|
+
### Consequences
|
|
44
|
+
|
|
45
|
+
Exact model names remain dated recommendations, while agents keep stable profile intent and evidence requirements.
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
# Deployment
|
|
2
|
+
|
|
3
|
+
## Environments
|
|
4
|
+
|
|
5
|
+
Document each environment:
|
|
6
|
+
|
|
7
|
+
- Local
|
|
8
|
+
- Preview
|
|
9
|
+
- Production
|
|
10
|
+
|
|
11
|
+
## Environment Variables
|
|
12
|
+
|
|
13
|
+
Document required variables with placeholder examples only.
|
|
14
|
+
|
|
15
|
+
Required Supabase variables usually include:
|
|
16
|
+
|
|
17
|
+
- `NEXT_PUBLIC_SUPABASE_URL`
|
|
18
|
+
- `NEXT_PUBLIC_SUPABASE_ANON_KEY`
|
|
19
|
+
- Server-only service-role key when needed
|
|
20
|
+
|
|
21
|
+
## Migration Order
|
|
22
|
+
|
|
23
|
+
Before deploying code that depends on database changes:
|
|
24
|
+
|
|
25
|
+
1. Review migration safety.
|
|
26
|
+
2. Apply schema and RLS changes.
|
|
27
|
+
3. Verify policies and constraints.
|
|
28
|
+
4. Deploy application code.
|
|
29
|
+
5. Run smoke tests.
|
|
30
|
+
|
|
31
|
+
## Observability
|
|
32
|
+
|
|
33
|
+
Document:
|
|
34
|
+
|
|
35
|
+
- Application logs
|
|
36
|
+
- Supabase logs
|
|
37
|
+
- Error reporting
|
|
38
|
+
- Cron or background jobs
|
|
39
|
+
- Alerting expectations
|
|
40
|
+
|
|
41
|
+
## Rollback
|
|
42
|
+
|
|
43
|
+
Document rollback steps for code, database migrations, and environment variable mistakes.
|
|
44
|
+
|
|
45
|
+
Link upgrade-specific rollback evidence from `UPGRADE.md` when the release includes package, framework, Agent Kit, or migration changes.
|