Stevens / Ivan Issue Report

PR #842 — итоговая позиция

PR: https://bitbucket.org/stevens_edu/stevens_main_nextjs/pull-requests/842 Задача: IX-SIT60 — Add schema for youtube Статус: OPEN (на 2026-04-16, не замержен) Цикл (на текущий момент): 31.03.2026 → 16.04.2026 → продолжается = 16+ дней

Краткое резюме

#ТипТемаОбоснованно
1ПретензияDebug console.log оставлен в коде✅ Да
2🚨 ПретензияPR требует pre-merge tasks, но они не описаны → build сломался у ревьюера✅ Да, прямой кейс из письма Alexis
3ПретензияНевалидный VideoObject — schema без обязательного uploadDate✅ Да
4СлужебныйVercel deploy bot—
5СнятMichael сам снял свой вопрос—
6Претензия (UX/process)~700 Video entries в "Not synced yet" — нет миграционной стратегии✅ Да

4 обоснованные претензии на одном PR.

🚨 Этот PR — почти точная иллюстрация письма Alexis

Письмо от 29.04.2026 содержит четыре основные претензии, и минимум три из них именно про этот PR:

Претензия из письмаКонкретика в PR #842
"deliverables that deviate considerably from spec and require revisiting"Schema без uploadDate (Comment #3), backfill для 700 entries не предусмотрен (Comment #6)
"PRs that require post-deployment tasks are always accompanied by such"Comment #2 — pre-merge tasks отсутствовали в описании, Michael узнал через сломанный build
"internal validation pass prior to sending things over"Comment #1 — console.log в проде; Comment #6 — продуктовый gap про 700 entries
"chunk this work into smaller batches, smaller incremental releases to reduce TTM"PR висит 16+ дней OPEN, охватывает: schema + Contentful field + Stevens CMS Tools + backfill script — большой батч

PR #842 очень вероятно — один из триггеров письма Alexis (одновременно по тематике, времени написания и набору проблем). Хронологически: PR открыт 31 марта, последний апдейт 16 апреля, письмо 29 апреля → PR в это время всё ещё OPEN.

Что признаём (объективно)

  1. Debug-код в PR (console.log) — недопустимо. Self-review бы это отловил за 10 секунд.
  2. Нет pre-merge tasks в описании PR на момент открытия — Michael был вынужден сам разбираться через сломанный build (Stevens CMS Tools нужно деплоить отдельным PR + Contentful merge develop→master).
  3. Невалидная schema (VideoObject без uploadDate) — функциональная ошибка, отсутствие сверки со schema.org spec.
  4. Не подумали про существующие 700 entries до того, как ревьюер задал вопрос — gap в продуктовом мышлении.
  5. PR висит ~3 недели OPEN — большой батч работы (schema + поле в Contentful + Stevens CMS Tools + backfill script), долгий цикл ревью.

Что в нашу пользу

  • Иван оперативно реагирует:
    • console.log убран в следующем коммите.
    • Условие на uploadDate добавлено за 1 день.
    • Backfill script предложен и реализован.
  • Конструктивное обсуждение с Michael — нашли решения для всех замечаний.
  • Финальное описание PR хорошее: pre-merge tasks, инструкция по backfill, ссылка на VIDEO_DATE_BACKFILL.md.
  • Иван придумал толковое решение (backfill script + дамп environment + dev-test) для проблемы 700 entries.

Корневые причины

  1. Нет self-review checklist перед отправкой PR на ревью Stevens (debug-код не должен туда попадать).
  2. Нет шаблона PR description с обязательными секциями (Pre-merge tasks / Post-deployment / Migration plan).
  3. Нет фазы продуктового продумывания до начала кодинга: "что с существующими данными?", "соответствует ли schema.org spec?", "какие env shifts нужны?".
  4. Slow review cycle — 16+ дней не из-за ревьюеров, а из-за нескольких раундов "поймали → исправили → нашли следующее".

Уточнение по спеке (после получения ICUS-211/212)

Спека есть — задачи ICUS-211 и ICUS-212 (одинаковый текст), обновлены 2026-03-12. PR открыт 2026-03-31 → через 19 дней после обновления спеки, времени на чтение более чем достаточно.

Что соответствует спеке:

  • ✅ Чтение сохранённого youtubeUploadDate из Contentful (без runtime-вызовов YouTube)
  • ✅ Использование Contentful Delivery API

Что не соответствует:

  • ❌ Сначала VideoObject выводился без uploadDate (Comment #3) — спека прямо требует валидной schema
  • 🟡 Sync trigger выбран на URL change, хотя спека предпочитала on Publish (Comment #6) → отсюда UX-проблема "Not synced yet"

Что спека сама не закрывает:

  • 🟡 Поведение для существующих entries (~700) — спека описывает только "при создании/обновлении". Это частично пробел спеки (Stevens не продумал миграцию), а не только реализации Ивана. Backfill script — корректное решение, его нужно было только заранее запланировать.

⚠️ В тексте задачи был YouTube API key — обязательно проверить, не попал ли в код.

Действия

  • ⚠️ Срочно проверить: YouTube API key не попал в исходники PR #842 / репо Contentful App. Если попал — ротировать.
  • Подтянуть PR #842 в встречу с Антоном/Иваном как иллюстрацию к письму Alexis.
  • Уточнить у Ивана: почему выбран trigger on URL change, а не on Publish (как предпочитает спека)?
  • Уточнить у Ивана: реализовано ли youtubeUploadDate как disabled для ручного редактирования (требование спеки)?
  • Обсудить с Антоном:
    • PR template с обязательными секциями (pre-merge tasks, migration, validation steps)
    • Self-review checklist перед "Open PR" (debug-код, lint, schema-spec, миграция данных)
    • Кто и когда делает internal validation pass
  • Обсудить с Иваном:
    • Почему console.log попал в PR? Используешь ли ты pre-commit hooks / lint правила?
    • Сверял ли реализацию VideoObject с schema.org требованиями до коммита?
    • Думал ли про существующие 700 entries на этапе кодинга, или это вылезло только после вопроса Michael?
  • К встрече со Stevens — этот PR использовать как признание + конкретный план: ввести PR template + self-review checklist + product checkpoint.

Ключевой вывод

PR #842 — главная иллюстрация претензий Alexis из письма. Здесь сошлись три из четырёх основных пунктов письма одновременно: deviate from spec (uploadDate), отсутствие post-deploy tasks (pre-merge через Contentful), необходимость internal validation (debug-код, продуктовые gap'ы). На встрече этот PR будет ключевым доказательством, что претензии обоснованы. Соответственно — наша позиция должна быть не "это перегиб", а "согласны, вот что меняем процессно".