fix(codex-playbook): уточнён вердикт ревью планов

- Зачем:
  - ревью высокоуровневых документов могло требовать преждевременных деталей и постоянно блокировать одобрение.
- Что:
  - находки ограничены дефектами на уровне самого документа.
  - существенные отложенные риски отделены от блокирующих замечаний.
  - уточнено, что APPROVED допускает открытые вопросы будущей реализации.
- Проверка:
  - quick_validate.py, git diff --check и проверка локальных Markdown-путей.
This commit is contained in:
Dmitriy Dementiev committed 2026-07-13 14:09:25 +03:00
1 parent 70b18b9e9a
commit 02a98df8c3
3 files changed
+35 -3

No files matched your search

@@ -76,9 +76,23 @@ REPORT: absolute unique path
`review-focus.md` задаёт один выбранный фокус. Для постановки: `review-focus.md` задаёт один выбранный фокус. Для постановки:
```text ```text
Review the task statement, not an implementation. Check facts against code, Review the statement or plan at its own level of abstraction, not as an
hidden one-line decisions, boundaries, checkable acceptance criteria, and implementation. Check facts against code, hidden one-line decisions,
ways to satisfy the wording without the intended result. boundaries, checkable acceptance criteria, and ways to satisfy the wording
without the intended result.
A high-level document is not incomplete merely because implementation choices
remain open. Request changes only for a defect the document itself must
resolve: one that changes its goal, boundaries, architectural direction,
acceptance criteria, dependencies, or the ability to decompose work safely.
When a detail can be decided locally by a downstream owner without changing
those properties, do not make it a finding or prescribe the implementation.
If deferring it carries a relevant risk, record that risk as a non-gating
consideration.
APPROVED means that no defect at the document's own level requires revision.
It does not mean that all downstream questions have been answered.
``` ```
Для реализации выбери task lens или code lens из договора ревью: Для реализации выбери task lens или code lens из договора ревью:
@@ -15,6 +15,14 @@ Use stable IDs with FINDING PREFIX:
`PREFIX-N | BLOCKER|MAJOR|MINOR|NIT | file:line or task section | violated `PREFIX-N | BLOCKER|MAJOR|MINOR|NIT | file:line or task section | violated
criterion | failure scenario | evidence | minimal verification` criterion | failure scenario | evidence | minimal verification`
A non-gating consideration has no stable ID, severity, or counter. Use it only
for a material risk from a safely deferred decision, and do not prescribe the
downstream implementation. It does not change the verdict.
Use CHANGES_REQUESTED only when at least one finding requires revision at the
reviewed artifact's own level. APPROVED means that no such defect remains; it
does not mean that every downstream question has been answered.
If there are no findings, record the reviewed scope and every executed check If there are no findings, record the reviewed scope and every executed check
or tested hypothesis with its outcome. A bare approval is invalid. or tested hypothesis with its outcome. A bare approval is invalid.
@@ -25,6 +33,8 @@ Return only:
- `VERDICT: APPROVED | CHANGES_REQUESTED` - `VERDICT: APPROVED | CHANGES_REQUESTED`
- severity counters; - severity counters;
- one line per finding: `ID | severity | area | one-phrase essence`; - one line per finding: `ID | severity | area | one-phrase essence`;
- optional one-line material considerations:
`CONSIDERATION | area | one-phrase risk`;
- `REPORT: <absolute path>`. - `REPORT: <absolute path>`.
Do not repeat the detailed report or reasoning narrative in the final message. Do not repeat the detailed report or reasoning narrative in the final message.
@@ -66,11 +66,19 @@ reviewer -> detailed report file -> triage owner
- сценарий сбоя и доказательство; - сценарий сбоя и доказательство;
- минимальный способ проверки. - минимальный способ проверки.
Неблокирующее соображение не получает идентификатор и тяжесть, не входит в
счётчики и не меняет вердикт. Так сохраняй только существенный риск от
отложенного решения, не проектируя реализацию за следующего владельца.
`CHANGES_REQUESTED` означает, что хотя бы одна находка требует исправить
документ на его собственном уровне. `APPROVED` означает отсутствие такого
дефекта, а не отсутствие всех будущих вопросов.
В сообщение координатору верни только: В сообщение координатору верни только:
- `VERDICT: APPROVED | CHANGES_REQUESTED`; - `VERDICT: APPROVED | CHANGES_REQUESTED`;
- счётчики по тяжести; - счётчики по тяжести;
- по одной строке на находку: идентификатор, область, суть и тяжесть; - по одной строке на находку: идентификатор, область, суть и тяжесть;
- по одной строке на существенное неблокирующее соображение, если оно есть;
- абсолютный путь к полному отчёту. - абсолютный путь к полному отчёту.
При отсутствии находок полный файл перечисляет просмотренный объём и При отсутствии находок полный файл перечисляет просмотренный объём и