SPEC.md як контракт довгої задачі

SPEC.md — особистий контракт проєкту

SPEC.md створюють до написання коду. Він зменшує невизначеність для автора, Claude, ментора й ревʼюера та описує, що саме будується, чого не буде і як довести результат.

CAPSTONE_BRIEF.md містить спільні правила capstone, а SPEC.md фіксує конкретний контракт вашого проєкту. EVIDENCE.md згодом зберігає фактичні перевірки, рішення та зміни scope.

# Project name

## Problem
## Audience
## Current situation
## Expected result
## Scope
## Non-goals
## Constraints
## Acceptance criteria
## Verification plan
## Risks and open questions

Описуйте поведінку, а не бажаний стек

• почніть із конкретної проблеми користувача;
• опишіть один головний сценарій;
• сформулюйте спостережуваний очікуваний результат;
• винесіть інтеграції, мобільний клієнт і production deploy у non-goals, якщо вони не потрібні;
• запишіть технічні та процесні constraints окремо від acceptance criteria.

Acceptance criteria та verification plan

Критерії мають бути спостережуваними. План перевірки повинен пояснювати, як підтвердити кожен критерій і що робити після невдалого запуску або тесту.

Claude як редактор та інтервʼюер

1. Попросіть знайти неоднозначності в проблемі та core flow.
2. Перевірте прихований overscope і слабкі non-goals.
3. Попросіть виявити відсутні acceptance criteria або checks.
4. Розгляньте ризики та відкриті питання без автоматичного розширення проєкту.
5. Самостійно прийміть рішення, що потрапляє до SPEC.md.

SPEC.md залишається живим документом

Якщо змінюються scope, non-goals або спосіб перевірки, оновіть SPEC.md і занесіть причину та наслідки до EVIDENCE.md. Для migration, modernization, DevOps і workflow-проєктів структура зберігається, хоча набір доказів може відрізнятися.

Для прикладу Subscription Watch до scope можуть входити додавання підписки, список активних підписок, найближче списання та скасування. Банківські інтеграції, мобільний застосунок і AI-категоризація можна явно виключити.