Анализ по каждой претензии

Формат: что говорят → что было на самом деле → наша позиция → что предлагаем.

1. Header отклоняется от спеки

Что говорят: Deliverable (header) сильно отличается от спецификации, потребовалась переделка.

Что было на самом деле: (заполнить после разбора)

Наша позиция: (заполнить)

Что предлагаем: (заполнить)

2. Squash коммитов в PR #847 после расшаривания ветки

Что говорят: История переписана, ревьюерам приходится перечитывать всё заново вместо того чтобы смотреть только дельту.

Что было на самом деле: (заполнить — git log, reflog)

Наша позиция: (заполнить)

Что предлагаем: Договориться о правиле: не делать squash/rebase после первого ревью; squash только при финальном merge через GitHub UI.

3. Rebase после расшаривания кода

Что говорят: Просят не делать rebase после того как код расшарен — это ломает историю для ревьюеров.

Что было на самом деле: (заполнить — частота force-push)

Наша позиция: Согласны / не согласны?

Что предлагаем: (заполнить)

4. Post-deployment tasks отсутствуют в PR

Что говорят: PR-ы, требующие post-deployment действий, должны их содержать.

Что было на самом деле: (заполнить — какой конкретно PR имеется в виду?)

Наша позиция: (заполнить)

Что предлагаем: Чеклист в PR template.

5. Предложение: меньшие батчи + internal validation + AI-tooling

Что предлагают: Дробить работу мельче, делать internal validation до отправки на ревью, использовать AI-tooling.

Наша позиция: Признаём, что PR #832 по факту долго висел и раздулся (27+ коммитов) — для ревью это тяжело, даже если у Alexis формулировка была как предложение, не отдельная претензия. Контекст без снятия ответственности: объём частично исторически сложился (схема для страниц, затем в ту же ветку — merge/next-seo и платформенные обновления); это тема ретро и процесса, не готовый ответ клиенту «нас не винить».

Что предлагаем: Лимит времени OPEN + правило: dependency/platform merge — отдельный PR или явный блок в description; internal validation до отправки (см. другие пункты плана).