mirror of https://github.com/Matysh/houseplan-card synced 2026-09-30 19:58:50 +00:00

Files

T

Claude 57ce10721f process: tracks ship/show/ask are set by the owner's label (#695 )

The analysis of 85 closed tasks #600-#691 showed that the light track
cost as much as the full one (115 min and 12 events vs 102 and 13) and
that the owner had no label to choose the route. The owner accepted the
proposal on 2026-09-28.

- PROCESS §5 is the track table: track:ship (S1 -> S5, one line under
  "## ТЗ", <= 30 src lines, batch review before the beta), track:show
  (default, S2 -> S5, up to three AC, no spec review, 2 code cycles),
  track:ask (full route). The owner's label beats the criteria, which
  become a hint; any agent may raise a track, only the owner lowers it.
- §5.1: ci:full / ci:golden / ci:mutants order heavy checks on any track;
  small and trivial read as track:show, no label as track:ask, an
  infrastructure task as track:show.
- §2, §2.2, §2.4, §2.5, §4, §7.1, §7.2, §9, §11 follow; AUTHOR/REVIEWER
  digests and AGENTS.md follow with the digest test and its mutants.
- task-packet.mjs reports the track via trackFromLabels(); the pipeline
  reads track:show/track:ship for the cycle limit of 2 and lets an
  explicit track:ask win. Pipeline behaviour by track is #696.

Issue: #695
User-Visible: no
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd

2026-09-28 22:13:21 +03:00

13 KiB

Raw Blame History

Конспект для ревьюера

Роли: ревьюер ТЗ и ревьюер кода (§6). Штатный ревьюер конвейера получает этот файл из промпта .github/workflows/_process.yml; ручное ревью по просьбе владельца идёт по нему же.

Это выжимка, а не канон. Канон процесса — PROCESS.md; при расхождении побеждает он, а расхождение — issue с меткой process. Конспект правил не добавляет и не меняет: каждый пункт ссылается на раздел канона, где правило записано полностью, с причинами и прецедентами. Ссылки и ключевые формулировки сверяет test/process-digests.test.mjs.

Позиция ревьюера

Ревьюер ≠ исполнитель, свежая сессия без контекста реализации. Задача — не согласиться, а найти, где ТЗ не выполнимо или не проверяемо, где код не делает заявленного (§2.4, §2.7, §6).
Ревьюер не правит ни ТЗ, ни продуктовый код; ревью своей работы запрещено (§6, §12).
Первый вопрос к задаче — какую работу из docs/SCOPE.md она обслуживает; для видимого поведения терминология берётся из docs/USER-GUIDE.ru.md (§7.1).

Ревью ТЗ

Артефакт — docs/reviews/SPEC-REVIEW-<NN>-r<N>.md. Ревью ТЗ проходит только трек ask (§2.4).
ТЗ живёт в теле issue, раздел ## ТЗ; docs/specs/ — архив до 2026-09-10 (§2.3).
Проверить обязательные разделы, однозначность каждого AC и способ его доказательства; догадка, записанная как факт, — находка (§7.1, §2.5).
Владельцу задаются только продуктовые вопросы; технический вопрос, вынесенный владельцу, ревьюер снимает и решает по существу. Технический спор автора и ревьюера решается вердиктом, а не владельцем (§7.1).

Код-ревью

Артефакт — docs/reviews/CODE-REVIEW-<tag|NN>-r<N>.md: скоуп, как проверялось (таблица гейтов с результатами), находки High/Medium/Low с воспроизведением, что проверено и корректно, чего не проверял (§2.7).
Ревьюер отвечает за полноту доказательств AC, а не заменяет их исполнение. Каждый AC либо доказан автотестом, и ревьюер убедился, что тест умеет падать, либо разобран с записью «проверено чтением, не исполнением». Применимые классы риска §2.6 сверяются отдельно (§2.7, §2.6).
Защитный AC доказывается таблицей «чем краснеет»: AC · чем доказан · чем краснеет — мутация, снятая защита или отрицательная проба с результатом прогона. Пустой третий столбец — находка Medium, а не примечание. «Тест умеет падать» без названной мутации и её вывода доказательством не является (§2.7).
Вердикт привязан к SHA (#312): числа и факты сверяются с git rev-parse HEAD перед итогом; более новый коммит, которого нет в материале, — находка, а не повод его подтянуть (§2.7, §10.4).
Контракты по монолиту — исполнением, не regex по тексту: список тестов, читающих монолит как текст, заморожен, и новое имя в нём — находка ревью, а не запись в список (§2.7).
Трейлеры Issue: #NN и User-Visible: yes|no на каждом коммите класса A и B; при yes — оба changelog в том же коммите (§3 п.10).
Одно число — один источник: ревьюер отвечает на вопрос прямо: какое число в этом диффе видно дважды и один ли у него источник (§8).

Объём гейтов

Всегда: typecheck, npm test, npm run build + bundle-policy --verify (копии сверяются только на кандидате, #657); при диффе по src/** — ещё node scripts/check-docs.mjs. Зелёный Validate на SHA материала подтверждает дешёвые гейты (§8).
По диффу и AC: смоки — названные в AC плюс вывод node scripts/smoke-select.mjs --base <base> --head <head> с решением по каждой строке; golden:verify при видимом изменении; pytest tests_backend при правке Python; инварианты модели при правке геометрии; performance — если назван в AC. Полные наборы — предрелизный гейт, а не гейт ревью (§8).
Условие честности сужения: ревьюер обязан перечислить, какие гейты прогнал, какие нет и почему (§8).
Зелёный pytest tests_backend без Home Assistant скипает test_ha_*.py и ничего не доказывает — это «чего не проверял» (docs/TESTING.md; §8).

Повторный раунд

Предмет повторного раунда — дельта, а не задача целиком: найти вердикт и материал предыдущего раунда (блок «Материал раунда»), объявить git diff <тот SHA>..HEAD, по каждой находке показать, чем она закрыта, заново проверить только AC, которые дельта задевает (§2.10).
Если SHA не резолвится — это не находка, а обычное дело: материал ищется по дереву и блобу. Находка — SHA, мёртвый уже в момент публикации отчёта (§2.10).
Обязателен раздел «Унаследовано из r<N−1>»: что принято без повторной проверки, с документом и материалом того раунда (§2.10).
Разбор остаётся полным, если дельта не локальна: ребейз на ушедший вперёд dev, смена контракта, новая подсистема, объём сопоставим с задачей. Сокращается объём разбора, а не строгость (§2.10).
Перед разбором подсистемы — её строки в docs/reviews/INDEX.md (§2.10).

Находки и вердикт

High блокирует. Medium в скоупе чинится в текущем issue: без High это жёлтый вердикт и повторный цикл. Medium вне скоупа — отдельный issue со ссылкой. Low правится или снимается ревьюером с записью (§3 п.8, §2.7).
Жёлтый вердикт допустим и при выполненных AC, если изменение не решает заявленный сценарий или ухудшает смежный; продуктовое рассуждение не отменяет AC и не меняет скоуп (§2.7).
Строка вердикта, первой строкой комментария: Вердикт: зелёный/жёлтый/красный · заход r<N> · блокирующих циклов K/<лимит> · High: N · Medium: N → в задаче | #… · Документ: docs/reviews/… («→ #…» — только у Medium вне скоупа) (§7.2).
Вперёд двигает только зелёный вердикт; жёлтый и красный возвращают автору (§7.2).
Зелёный вердикт цикла не образует; лимит — 4 цикла, на track:show 2; бюджет считается по этапу (§4, §10.4).
Запрещено: Medium-находки, оставленные как TODO в документе ревью; ревью-документы вне репозитория (§12).

Независимое ревью линии

Перед стабильным релизом release-review.yml судит поверхности всей линии бет против пользователя, а не дифф против ТЗ: ТЗ задач и документы раундов не читаются, основа — docs/SCOPE.md и docs/USER-GUIDE.ru.md (§11.5).
Проверка исполнением: посимвольный ввод, настоящие Escape и крестик, фикстура ha-dialog (#505) для диалогов; по каждой поверхности — обычный сценарий и самый рискованный соседний (§2.6, §11.5).
Документ docs/reviews/RELEASE-REVIEW-vX.Y.Z.md — рекомендация: выпуск не блокируется, решение по находкам за владельцем; ревьюер ничего не публикует и issue не заводит (§11.5).

13 KiB Raw Blame History