Прод: https://school-purchasing.vercel.app

Шаблон проєкту розробника: Next.js + Supabase + OpenSpec

Стартовий репозиторій для вебзастосунку «з нуля». Кожен розробник команди створює з шаблону власне репо й робить у ньому свою реалізацію продукту команди: власні Supabase і Vercel, задачі → гілки → PR → CodeRabbit → merge. Вимоги пише PM людською мовою у своєму репо вимог (шаблон koldovsky/2026-quitcode-06-spec-template): в issues або файлами docs/. Сюди їхній знімок приносить команда агента /requirements-sync (без скриптів і тегів), а специфікацію в OpenSpec пишете ви — перекладаєте вимоги PM, зберігаючи ID його критеріїв приймання. Наприкінці PM порівнює, як різні розробники (і їхні агенти) прочитали й реалізували ті самі вимоги. В агенції шаблон так само береться для нового клієнтського проєкту.

• Застосунок: Next.js 16 (App Router, src/), вхід email + пароль через Supabase Auth, сторінка з email і роллю користувача з таблиці profiles; сесію оновлює src/proxy.ts.
• База як код: ваша власна база Supabase; supabase/migrations/ (профілі й ролі з RLS і явними GRANT), ідемпотентний seed.sql, синтетичні користувачі (npm run users:demo). Міграції в базу застосовує лише CI.
• Вимоги й специфікація: requirements/ — знімок вимог PM (оновлює лише /requirements-sync); OpenSpec (openspec/, правила перекладу в openspec/config.yaml) — ваша специфікація: зміна add-<зріз> перекладає вимоги PM, impl-<зріз> — ваш план реалізації. AC ID PM наскрізно: вимога PM → сценарій специфікації → задача → назва тесту → docs/conformance.md.
• Агенти: AGENTS.md (+ CLAUDE.md = @AGENTS.md), команди /requirements-sync, /conformance і /opsx:*, скіли spec-clarify і spec-review — однаково в Claude Code і Cursor; .mcp.json (Supabase MCP лише на читання) і .claude/settings.json (дозвіл на команди gh/git для читання й синхронізації вимог; заборона читати .env* і запускати supabase db push та деструктивні команди Supabase CLI) діють лише в Claude Code — Cursor цих файлів не читає (див. AGENTS.md, «Секрети»).
• Ворота: GitHub Actions ci.yml (spec, app, conformance, db-check — обов'язкові для PR; db-deploy — міграції в прод після merge), ruleset solo-main, шаблон PR, .coderabbit.yaml.

Шар курсу	Де в шаблоні
Правила й команди	AGENTS.md, CLAUDE.md, .claude/commands/ (requirements-sync, conformance, opsx/), .cursor/commands/
Скіли	.claude/skills/ (spec-clarify, spec-review, openspec-*; Cursor читає цю ж теку)
MCP з мінімальними правами	.mcp.json, .claude/settings.json (лише Claude Code)
Вимоги й специфікації	requirements/, openspec/, product/ (denylist), scripts/check-*.mjs, docs/conformance.md
Процес і ворота	.github/ (CI, шаблон PR), .coderabbit.yaml, docs/bootstrap.md

Модель роботи: репо вимог PM і власне репо розробника

 PM:  <pm>/<team-slug>-spec          (шаблон вимог, публічне; PM працює лише у вебінтерфейсі GitHub)
      issue «Продукт» + issues «Вимога» (мітки product, requirement)   — або —   docs/product.md + docs/requirements/*.md
      issues «Питання до вимог» (мітка question) — тут питають і відповідають
          ▲ питання (issue через вебформу)          │ /requirements-sync у Claude Code чи Cursor:
          │                                         ▼ агент робить знімок вимог PM у вашому репо
 Ви:  <dev>/<team-slug>              (цей шаблон, публічне) — у кожного розробника своє
        ├─ main               ← лише через PR (ruleset solo-main: зелений CI, 0 approve)
        ├─ sync/<дата>        ← /requirements-sync: requirements/ + рядок «Вимоги: …» у docs/conformance.md
        ├─ spec/<id зміни>    ← ваша специфікація: переклад вимог PM в openspec/ (add-<зріз>, уточнення), план impl-<зріз>
        ├─ task/<коротко>     ← реалізація: код, міграції, тести, рядки матриці
        └─ template/<коротко> ← виправлення шаблону (cherry-pick)
      Supabase: ваша організація й проєкт   ← міграції застосовує CI (db-deploy)
      Vercel: ваш проєкт, прод з main, preview для кожного PR

Чотири правила:

1. Вимоги пише PM — людською мовою за шаблоном у своєму репо (issues або docs/) і пише в чат команди «вимоги оновлено».
2. У своєму репо ви підтягуєте їх командою /requirements-sync. requirements/ руками не правите.
3. Специфікацію пишете ви: перекладаєте вимоги PM в OpenSpec — кожен AC PM стає сценарієм із тим самим ID, нічого не вигадуєте.
4. Питання до вимог — issues у репо PM через вебформу «Питання до вимог» (https://github.com/<pm>/<team-slug>-spec/issues/new?template=question.yml). Відповіді там само — їх бачить уся команда.

Роль	Де працює	Що робить
PM	репо вимог <pm>/<team-slug>-spec (лише вебінтерфейс)	issue чи файл «Продукт», вимоги за шаблоном з AC, відповіді на питання й «Журнал змін» кожної вимоги; наприкінці — нотатка-порівняння реалізацій
Розробник	власне репо <dev>/<team-slug> з цього шаблону	налаштування (docs/bootstrap.md), /requirements-sync, питання (spec-clarify), переклад у специфікацію (spec-review), план impl-<зріз>, задачі PR-ами

Колег у вашому репо немає: approve не потрібен, рев'ю робить CodeRabbit (коментар @coderabbitai review), а ви відповідаєте на кожен його коментар — виправленням або поясненням, чому ні. Команда лишається: той самий бриф, чат, зустріч команди й питання в репо PM. Подивитися реалізації колег можна, але це необов'язково.

以上為 README 的開頭部分。其餘內容請閱讀原文。 檢視完整 README ↗