Прод: 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
Чотири правила:
- Вимоги пише PM — людською мовою за шаблоном у своєму репо (issues або
docs/) і пише в чат команди «вимоги
оновлено».
- У своєму репо ви підтягуєте їх командою
/requirements-sync. requirements/ руками не правите.
- Специфікацію пишете ви: перекладаєте вимоги PM в OpenSpec — кожен AC PM стає сценарієм із тим самим ID, нічого не
вигадуєте.
- Питання до вимог — 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. Подивитися реалізації колег можна, але це необов'язково.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
