Review Findings: что это и как фиксировать риски требований

Review Findings нужны, когда проект живет в нескольких источниках и команда уже не может доверять одному документу как единственной правде. Типовая ситуация: PDF-контракт говорит одно, Confluence описывает старую версию, код в POC показывает третий вариант, а письма от support уточняют детали, которых нет в документации.

Без отдельного слоя находок такие места растворяются в постановке. Аналитик пишет аккуратный абзац, разработка видит готовое требование, а через две недели оказывается, что в основе требования было неподтвержденное решение. Review Findings не дают этому случиться: спорные места остаются спорными, пока их не закрыли явно.

System Context Pack отвечает за картину проекта: факты, источники, ограничения, допущения и конфликты. Review Findings отвечают за управляемые решения. Это не пересказ всего SCP, а список мест, где требуется внимание: что блокирует запуск, что нужно подтвердить, где есть риск, где источник устарел, где формулировку можно прочитать двумя способами.

Практическая граница такая: если факт можно спокойно оставить в контексте проекта, он остается в SCP. Если по факту нужно решение, действие или отдельное обсуждение, он уходит в Review Findings.

Минимальная карточка Review Finding включает семь полей.

1. ID. Например, RF-01. Нужен для ссылок из SCP, Task Pack и обсуждений.
2. Название. Коротко: «Auth token lifetime: PDF vs email».
3. Тип. Противоречие, пробел, неоднозначность или риск.
4. Severity. HIGH, MEDIUM, LOW. Иногда добавляется blocker, security или compliance.
5. Evidence. Конкретные источники: документ, раздел, письмо, файл, строка кода.
6. Влияние. Что сломается, если оставить как есть.
7. Действие. Кого спросить, что подтвердить, что изменить, где зафиксировать решение.

Finding без evidence превращается в мнение. Finding без влияния превращается в заметку. Finding без действия превращается в тревогу. Рабочая находка должна вести команду к следующему шагу.

В учебном кейсе Acme Pay команда готовит миграцию платежной интеграции с API v1 на v2.1. После source map и SCP появляется 10 Review Findings. Пять из них HIGH severity.

## RF-01 — Auth token lifetime: PDF vs email

Тип: Противоречие источников.
Severity: HIGH.
Область: Authentication.

Что: две активные версии значения auth token lifetime.
- S01 PDF v2.1: "expires_in": 86400 (24 часа).
- S04 email support: в v2.1 срок изменен на 4 часа.

Влияние: если backend сделает refresh по PDF, токен протухнет
через 4 часа в production.

Действие:
1. Запросить у Acme письменное подтверждение значения 4h.
2. Обновить SCP после подтверждения.
3. Реализовать refresh заранее, с учетом короткого окна.

Статус: open.

Другие находки в этом кейсе: POC не валидирует webhook signature, customer_id обязателен в v2.1, POC использует /v1/, Idempotency-Key отсутствует, retry policy webhook-ов есть только в письме support.

Review Findings не должны жить отдельным кладбищем рисков. Они нужны как вход в Task Pack. HIGH находки становятся блокерами или open questions. MEDIUM находки превращаются в риски, ограничения или отдельные задачи. LOW находки обычно уходят в примечания, уточнения терминов или документацию.

Если в Task Pack написано требование «реализовать token refresh», рядом должна быть ссылка на RF-01. Если в рисках указано «webhook signature не валидируется», рядом должна быть ссылка на RF-02 и источники. Так команда видит не только что делать, но и почему это действие появилось.

В продукте «Подмастерье аналитика» Review Findings собираются после System Context Pack. Подмастерье читает источники в рамках Project-local RAG, показывает selected chunks перед внешним inference и поднимает места, где источники расходятся или требуют решения.

Мастер остается владельцем решения. Подмастерье может предложить тип находки, severity и действие, но финальную оценку делает человек: аналитик, PM, tech lead или архитектор.