Специфікація для reviewer'а

Специфікація для reviewerʼа

Reviewer-oriented specification пишеться не як рекламний опис, а як компактний contract для незалежного рішення. Вона має дозволити іншій людині зрозуміти проблему, replay-нути bounded flow, перевірити acceptance і побачити, що залишилося Unknown.

SPEC.md може бути довгоживучим project contract, TASK_SPEC.md — постановкою конкретної роботи, а EVIDENCE.md — записом фактичних перевірок. Не змішуйте ці ролі в один текст і не називайте filled documented example evidence фактичного виконання.

Reviewer checklist

• Чи зрозуміло, хто користувач і який JTBD має бути покращений?
• Чи узгоджені value proposition, scope, non-goals і release slice?
• Чи має кожен acceptance criterion спосіб verification?
• Чи відділені факти, assumptions, Unknowns і claims про майбутнє?
• Чи можна переглянути один core flow без прихованих залежностей?
• Чи має reviewer достатньо evidence для GO, HOLD або запиту на зміну scope?

Мінімальний reviewer-ready contract

# SPEC.md
Problem: reviewers lose context while checking a bounded AI-assisted change
User: reviewer of one repository workflow
Core flow: intake -> AI-assisted outline -> human review -> evidence note
In scope: one flow, one metric, one review checklist
Non-goals: autonomous merge, production deployment, broad product roadmap
Acceptance: reviewer can reproduce the outline and locate Unknowns
Verification: static checks and documented review steps; execution status: Unknown
Status: documented example; no product outcome is claimed.