Cross-PR анализ — повторяющиеся паттерны

Цель: выделить системные проблемы, проходящие через несколько PR. На них надо реагировать процессом, не разбираться по каждому PR отдельно.

Сводная матрица — претензии по PR

Категория проблемы	PR #837 (FAQ)	PR #842 (YouTube)	PR #832 (pages)	PR #846 (header)	PR #847 (FAQ hotfix)
Невыполнение acceptance criteria из приложенной спеки	✅ конфигурация поля	—	✅ Minisite Right Nav пропущен	✅ text-only logo, search styling, dropdown center	✅ bottomComponentsCollection пропущен
Делает то, чего нет в спеке	—	—	—	✅ dropdown center-justified	—
Невалидный schema.org объект	—	✅ VideoObject без uploadDate	✅ VideoObject без uploadDate (повтор!)	—	—
Pre-merge / post-deployment tasks отсутствуют в PR	—	✅ broke build у ревьюера	✅ Alexis 23.02 прямо спрашивал	—	—
Debug-код / dead code / лишние whitespace	—	✅ `console.log`	✅ whitespace-only changes	—	✅ dead env-var fallback
Незнание / неиспользование существующих абстракций	—	—	✅ getExternalPath, Image Wrapper.credit	—	—
Функциональный баг на проде/preview	—	—	✅ `undefined/profile/...` URL	—	—
Регрессия от собственных изменений	—	—	—	✅ меню в 2 строки 1024-1091px	—
Self-QA / responsive / accessibility пропуски	—	✅ ~700 unsynced	✅ многочисленные	✅ dark mode WCAG, RWD	✅ existing data
Contentful environment ошибки	✅ master vs develop	—	—	—	—
Неполный фикс после ревью (reopen)	—	—	✅	✅ sticky после фикса	—
🚨 Workflow violation (commit-after-approve)	—	—	—	—	✅ TODO "when approve PR"
🚨 Squashing/rebase подозрение	подозр.	—	—	—	TBD git log

Топ-5 системных паттернов

1. Невыполнение acceptance criteria приложенной спеки (4 из 5 PR)

PR #837 — спека ICUS-214 в Jira за 2 дня до PR; реализация не по спеке.
PR #832 — пропущен Minisite Right Nav из spec docs.
PR #846 — text-only logo, search styling — прямо в мокапе v3, не реализовано.
PR #847 — bottomComponentsCollection — Иван сам в description обещал покрыть Right Nav и Program Detail, в коде gap.

Корневая причина: спека читается поверхностно или не сверяется с реализацией построчно перед открытием PR.

Что лечит:

Spec-read checkpoint в начале задачи (Иван явно подтверждает прочтение parent + attachments).
Side-by-side сверка мокап ↔ preview перед открытием PR.

2. Самостоятельные решения в обход спеки (positive AND negative) (2 из 5)

PR #846 Comment #2 — Info For dropdown центрирован, в спеке нет.
PR #847 — pageId формат с #faq-суффиксом (хотя Michael говорил "URL path of the page").

Корневая причина: Иван иногда дополняет спеку своими интерпретациями — иногда это улучшения (aggregation в #847), иногда нежелательные изменения (центрирование).

Что лечит:

В сложных случаях — задавать вопрос до реализации, не после ревью.
Self-rule: "если в спеке этого нет — не делай. Хочешь сделать — спроси."

3. Self-QA пропуски (визуальные, responsive, accessibility, env-vars) (5 из 5 PR)

PR #837 — Contentful env разные.
PR #842 — console.log, отсутствие миграции 700 entries.
PR #832 — undefined URL на проде, multiple hardcoded values, whitespace shuffles.
PR #846 — RWD регрессия 1024-1091, dark mode WCAG, не открыли expanded mobile.
PR #847 — dead env-var fallback (один grep по проекту).

Корневая причина: нет дисциплины самопроверки перед "Open PR".

Что лечит:

Self-QA checklist (ниже).
Internal validation pass на стороне менеджера/тимлида.

4. Невыученные уроки между PR

VideoObject без uploadDate — пойман Michael в PR #832 31.03 и в PR #842 31.03. Оба раза один день, оба раза автор Иван. Между PR урок не закрепился.
Spec-deviation — Bemin указывал на нарушение спеки в #837 (16.03), в #832 (24.02), в #846 (23.04). Ревьюеры системно ловят одни и те же классы ошибок.

Корневая причина: нет ретроспективы / разбора каждого замечания так, чтобы стало правилом.

Что лечит:

Лог "lessons learned" — после каждого PR с замечаниями записывать класс ошибки и проверять на следующих PR.
Антон в роли тимлида — ответственный за это.

5. Workflow дисциплина

PR #832 — Alexis уже 23.02 прямо спросил про pre-deployment steps; ответили "no additional steps required"; через 5 недель в PR #842 ровно эта же проблема повторилась — Michael узнал через сломанный build.
PR #847 — commit с TODO "when approve PR" → намеренный commit-after-approve.
PR #837/#847 — squashing на расшаренной ветке (TBD на встрече).
PR #846 — language barrier в комментариях ревью, потеря циклов на расшифровку.

Корневая причина: правила PR-workflow не формализованы / не проговорены явно.

Что лечит:

Свод правил workflow (ниже).
Менеджер/тимлид перечитывает существенные комментарии Ивана к ревьюерам перед публикацией.

Что в нашу пользу (плюсы для встречи со Stevens)

Плюс	Где
Реактивность Ивана — фиксит на следующий день	все 5 PR
Архитектурно правильное решение	PR #847 (aggregation > shortcut Michael)
QA с первого раза	PR #837 (3/3 кейса)
Хорошее PR description	PR #847, #842 (после правок)
Merge вместо rebase	PR #837 (по совету Alexis)
Branch reuse по предложению Michael	PR #847
Хороший вопрос с собственной инициативой	PR #846 alignment magnifier/X
Спека сама требовала уточнений (3 случая)	PR #846 (sticky 1024+, alignment, data-cta stability)

Системный вывод

Распределение замечаний по корневым причинам (по всем PR суммарно ~33 содержательных претензий):

~70% — наши self-QA / spec-discipline промахи — лечатся checklist'ом + spec-read checkpoint.
~15% — workflow violations (squashing, commit-after-approve, missing pre-merge tasks) — лечатся свод правил.
~10% — пробелы в спеке у клиента (3 случая в PR #846) — это процессный gap на их стороне, аккуратно подсвечиваем.
~5% — знание codebase / абстракций — лечится онбордингом + кодревью с акцентом на реюз.

Главное: проблема процессная, не индивидуальная. Иван — реактивный, технически достаточный разработчик. Что отсутствует — дисциплина пред-выпускной проверки и формализованный workflow. Это лечится за 1-2 итерации, если ввести checklist'ы и правила.

Предлагаемые процессные изменения

A. Self-QA checklist (Ивану — обязательно перед "Open PR")

Spec sweep: открыт parent-тикет в Jira; прочитаны все attachments; acceptance criteria построчно сверены с реализацией.
Mockup overlay: preview ↔ мокап разложены рядом; пройдены все состояния (default, sticky, hover, expanded, search open).
Responsive: RWD-режим в DevTools, ползунок ширины через все breakpoint'ы (тестировать между ними, не только на стандартных).
Mobile menu / overlays / dropdowns — открыты вручную хоть раз.
Dark mode / accessibility: Lighthouse / axe DevTools / contrast check.
Code hygiene: git diff пройден глазами; нет console.log, // TODO when approve, dead fallback'ов; grep env-vars подтверждает их существование.
Schema/spec compliance: если выводится structured data — провалидирован через Rich Results / Fast Schema Analyzer.
Existing data: если фича триггерится на новых данных — продумано, что с историческими данными.

B. PR description template (обязательные секции)

Summary — что и зачем
Changes — список изменений
Pre-merge tasks — что нужно сделать до merge (отдельные PR, Contentful changes, env-var-добавления и т.д.)
Migration plan — что с существующими данными, какой backfill
Validation done — какие тесты прогнаны, ссылки на preview-валидаторы
Compare — preview URL ↔ prod URL (если применимо)

C. Workflow rules (свод)

После первого git push ветки на remote — никаких rebase / force-push / squash. Только новые коммиты сверху.
Squash — только при финальном merge через UI ("Squash and merge" кнопка).
Никаких "TODO when approve" в коде. Если код не готов — PR в Draft, не Open.
После approve — изменения только с явным "please re-review". Approve привязан к коммиту.
Branch reuse OK (как предложил Michael), но история не переписывается.

D. Spec-read checkpoint

Перед стартом задачи Иван пишет в Jira-комменте: "Read parent ICUS-X + attachments [список]. Acceptance criteria: [перечисляет]. Questions: [если есть]."
Антон подтверждает или уточняет.

E. Internal validation pass

Перед "Open PR на ревью Stevens" Антон / Андрей делает 5-минутный pass по checklist'у выше.
Если что-то не сходится — возвращает Ивану до отправки клиенту.

F. Lessons learned log

После каждого замержённого PR Антон записывает 1-2 замечания, которые повторились бы, если бы не поймали.
Перед началом следующего PR — Иван перечитывает.

G. Размер батча

Договариваемся: PR не должен висеть OPEN дольше 2 недель. Если затягивается — деление на части.
Примеры: PR #832 (2+ месяца) и PR #846 (2 недели + 11 issues) — кандидаты на ретроспективное разбиение в будущем.

Что прямо упомянуто в письме Alexis и наш ответ

Тезис письма	Ответ
"deviate considerably from spec"	Признаём (5 из 5 PR). Вводим Self-QA checklist + Spec-read checkpoint.
"PR #847 commit squashing"	TBD на встрече с Иваном (git log). Заводим правило "no rebase after share".
"internal validation pass prior to sending"	Не делалось. Вводим (Антон/Андрей перед отправкой PR клиенту).
"ensure post-deployment tasks accompanied"	Не делалось. Вводим обязательную секцию PR description.
"smaller batches, reduce TTM"	Признаём. PR #832 был 2+ мес, PR #846 — 2 нед + 11 issues. Договоримся о делении.
"AI-assisted tooling"	Открытый вопрос — обсудить с Иваном/Антоном.