Перевірка на основі diff: L1 review

Diff — джерело правди для L1 review

Diff показує фактичний результат, а не задум або історію діалогу з Claude. Verification відповідає на питання «якими перевірками це підтверджено», а L1 review — «хто переглянув зміну, які ризики знайшов і чи можна її прийняти».

Review має бути сфокусованим на конкретному diff у межах approved scope, а не перетворюватися на повторне дослідження всього проєкту.

Self-review: спочатку межі, потім деталі

1. Перевірте, чи список змінених файлів відповідає approved plan.
2. Знайдіть зміни, що стосуються початкового сценарію.
3. Виявить випадкові файли, перейменування та супутній рефакторинг.
4. Перевірте сусідні endpointʼи, конфігурацію та неповʼязані модулі.
5. Зіставте коміти, walkthrough та evidence.
6. Перегляньте стан репозиторію після перевірки.

git diff --stat
git status --short
git diff --check

Фокус Claude-assisted review

• порівняти diff з approved plan;
• знайти scope creep і неочікувані файли;
• виявити відсутні regression або edge-case тести;
• перевірити backward compatibility та зміни validation;
• позначити неясні місця з файлом і рядком, якщо можливо;
• не редагувати файли під час review.

Fresh-context review і REVIEW_NOTES.md

Новій сесії або reviewer-subagent передають approved plan, PR_DESCRIPTION.md, diff, test plan та evidence. Відсутність авторського контексту допомагає побачити невідповідності між задумом і фактичним результатом.

У REVIEW_NOTES.md варто зберегти результати self-review, findings Claude, результати незалежного перегляду, прийняті й відхилені зауваження, follow-up та фінальне людське рішення.

Scope: checkout empty-cart fix
Changed files: approved / unexpected: none
Tests: regression passed; valid checkout passed
Finding: no API redesign required
Decision: ready for human merge approval

Зелений тест не замінює diff review

• Перевірте, що тест відтворює реальний root cause.
• Переконайтеся, що рівень тесту відповідає прояву проблеми.
• Для HTTP-багу перевірте endpoint, статус і response body.
• Перевірте, що не тестується лише внутрішній exception.
• Зіставте manual checks, test plan та evidence.
• Якщо diff надто широкий, приберіть зайві зміни, створіть follow-up або поверніться до debugging.