# Процесс работы над House Plan > **Статус документа:** черновик 3 (2026-08-12), на согласование владельцу. > Решения владельца, зафиксированные в этой редакции: прямые коммиты в `dev` без > PR · канон статуса — **метки** · лёгкий трек для мелких задач **включён**. > > **Область действия:** обязателен для владельца и для любого агента (Cowork, > Cursor Cloud, Codex, локальные сессии). Читается сразу после `AGENTS.md`, до > `docs/STATUS.md`. > > **Приоритет источников:** GitHub Issues + Project v2 — канонический бэклог. > Статус живёт в метках issue. При расхождении документации с GitHub побеждает > GitHub; при расхождении процесса и привычки побеждает процесс. --- ## 1. Основное правило **Изменение продуктового кода без issue запрещено.** Код меняется только тогда, когда issue существует и находится в статусе «Готово к разработке» или дальше. Исключения — только §11, и каждое оставляет след. Правило работает лишь при точной границе «продуктового кода», иначе спор переносится на границу: | Класс | Что входит | Нужен ли issue | |---|---|---| | **A. Продукт** | `src/**`, `custom_components/houseplan/**/*.py`, `manifest.json`, `hacs.json`, `src/i18n/*.json`, `custom_components/**/translations/*` | **Да, обязательно.** Только из «Готово к разработке» или дальше | | **B. Гейты и инструменты** | `test/**`, `tests_backend/**`, `demo/**`, `scripts/**`, `.github/workflows/**`, `rollup.config.mjs`, `tsconfig*.json` | **Да.** Может использовать issue того изменения, которое покрывает; самостоятельная работа над гейтом получает свой issue (тип «техдолг») | | **C. Документация** | `docs/**`, `README*`, `CHANGELOG*`, `AGENTS.md` | Документирование A/B в том же коммите — часть DoD своего issue. Самостоятельная работа над документацией — свой issue | | **D. Сгенерированное** | `dist/**`, `custom_components/houseplan/frontend/**`, `demo/srv/assets/houseplan-card.js`, `demo/golden/baselines/**` | Никогда не меняется само по себе. Коммит **только** класса D допустим лишь как релизный промоушен или как принятие эталонов с доказательством ревью | Практический смысл таблицы: «я только поправил тест» и «я только пересобрал бандл» перестают быть лазейками. --- ## 2. Жизненный цикл Семь рабочих статусов и два служебных. Фазы тестирования в цикле сознательно **нет**: найденные позже дефекты заводятся отдельными issue и проходят цикл заново. Issue закрывается после выпуска беты. ``` Новое → Аналитика и оценка → ТЗ в работе → ТЗ на ревью ⟲ → Готово к разработке → → В разработке → Код-ревью ⟲ → Закрыт (после выпуска беты) служебные: Заблокировано (parking) Отклонено (закрыт) ⟲ — возврат на правки, не более 4 циклов (§4) ``` ### 2.1 Новое — заведение задачи - **Кто:** любой — владелец, агент, пользователь (Telegram, GitHub). - **Вход:** проблема в пользовательских терминах; как проявляется или зачем нужно. Решение **не требуется** и не приветствуется. - **Запрещено:** ставить приоритет, оценивать, писать ТЗ, начинать код. ### 2.2 Аналитика и оценка Задача разбирается, продуктовое «да» ещё не дано. - **Кто:** агент-аналитик готовит, владелец решает. - **Чек-лист**, результат — комментарием в issue: 1. дубликаты проверены (ссылки на похожие issue); 2. в скоупе по `docs/SCOPE.md` и `docs/TOUCH-SUPPORT.md`; 3. **пользовательская ценность 1–10** и **ценность для разработки** — что упрощает или разблокирует; 4. **сложность и риск 1–10** — трудоёмкость плюс вероятность задеть смежное; 5. приоритет **P1/P2/P3**; 6. тип: баг / фича / техдолг; 7. затронутые поверхности (модули, диалоги, бэкенд, i18n); 8. лёгкий трек — да/нет по критериям §5. - **Приоритет и ценность — поля владельца.** Агент предлагает, владелец утверждает; иначе агенты приоритизируют сами и P1 разрастается. - **Выход:** «ТЗ в работе» либо «Отклонено» с записанной причиной. ### 2.3 ТЗ в работе — написание ТЗ - **Кто:** автор ТЗ, назначает себя. Статус означает «занято». - **Артефакт:** `docs/specs/-.md`, где `NN` — **номер issue**. Многоэтапная задача: `--stage.md`. - **Лёгкий трек:** ТЗ пишется в теле issue, файл не создаётся (§5). - **Выход:** полная первая редакция по §7. ### 2.4 ТЗ на ревью - **Ревьюер ≠ автор.** Ревьюер получает issue и ТЗ, без устных пояснений автора. Его задача — не согласиться, а найти, где ТЗ не выполнимо или не проверяемо. - **Артефакт:** `docs/reviews/SPEC-REVIEW--r.md`, вердикт зелёный / жёлтый / красный. Лёгкий трек — комментарий в issue. - **High-находки блокируют.** Medium/Low — либо правятся, либо становятся отдельными issue со ссылкой; «оставили в тексте ревью» не считается закрытием. - **Выход:** «Готово к разработке» либо возврат в «ТЗ в работе» — не более 4 циклов (§4). ### 2.5 Готово к разработке (DoR) Не работа, а **очередь**: единственный статус, из которого можно трогать код. Все пункты обязательны: - ТЗ существует, ревью ТЗ зелёное, ссылки issue ↔ ТЗ на месте; - **AC1…ACn** — пронумерованные проверяемые критерии приёмки; у каждого указано, чем он доказывается: `unit` / `backend` / `smoke` / `golden` / «ревью кода»; - перечислены затронутые файлы и модули; - i18n: ключи en + ru перечислены; - миграция и compatibility-поля решены по `docs/CONFIG-COMPATIBILITY.md`; - влияние на производительность и бюджеты названо (или явно «нет»); - влияние на touch по `docs/TOUCH-SUPPORT.md` (View и киоск — блокирующие); - release-артефакты по правилу `docs/specs/README.md` (changelog RU+EN, документация, golden/скриншоты, performance/security); - **откат**: как выключить или вернуть назад (флаг Labs, обратная миграция); - открытых продуктовых вопросов нет; риски перечислены. Если хоть один пункт не выполнен — статус не «Готово к разработке», как бы ни хотелось начать. ### 2.6 В разработке — реализация - **Занятие (claim):** назначить себя, поставить метку, комментарий «Взял: <роль> · сессия · ветка `issue/-`». - **WIP-лимиты:** не более **1** issue в «В разработке» на исполнителя, не более **3** одновременно на цикл релиза, не более **2** в «Код-ревью». - **Трассируемость:** ветка `issue/-`; каждый коммит несёт трейлеры `Issue: #` и `User-Visible: yes|no`. - **Автотесты — часть реализации, а не отдельная фаза.** Каждый AC, помеченный `unit`/`backend`/`smoke`/`golden`, получает свою проверку здесь же. «Тестирование вне жизненного цикла» означает отсутствие фазы ручного тестирования, а не отсутствие тестов. - **Скоуп не расширяется.** Найденное по пути становится новым issue в «Новое». Если находка блокирует — текущий issue уходит в «Заблокировано» со ссылкой. Попутных правок «раз уж я здесь» не бывает. - **Документация — в том же коммите,** что и поведение (действующая политика `docs/STATUS.md`): changelog RU+EN для пользовательского, `STATUS.md` для состояния, `DEVELOPMENT.md` для новых грабель, `ARCHITECTURE.md` для дизайна. - **Выход:** локальный гейт зелёный (§8), хендофф-комментарий (§7.2). ### 2.7 Код-ревью - **Ревьюер ≠ исполнитель**, свежая сессия без контекста реализации. - **Артефакт:** `docs/reviews/CODE-REVIEW--r.md` в действующем формате: скоуп, как проверялось (таблица гейтов с результатами), находки High/Medium/Low с воспроизведением, что проверено и корректно, чего не проверял. - **Ревьюер отвечает за AC.** Раз ручного тестирования в цикле нет, именно ревью кода отвечает на вопрос «оно вообще работает»: каждый AC либо доказан автотестом — и ревьюер убедился, что **тест умеет падать**, — либо разобран по коду с явной записью «проверено чтением, не исполнением». - **High блокируют.** Medium **обязаны** превратиться в issue. - **Выход:** очередь на пре-релиз либо возврат в «В разработке», не более 4 циклов (§4). ### 2.8 Закрытие после выпуска беты - **Вход:** изменение вошло в опубликованную бету/RC, CI Validate зелёный на **точном SHA** тега (промоушен-правило: ни одна фича не попадает в стабильный релиз, не побывав в бете). - **Закрывает** релиз-менеджер, не исполнитель. Комментарий закрытия: тег беты, ссылка на прогон CI, ссылка на бюллетень changelog. - **Стабильный релиз статусов не двигает** — issue уже закрыты; релизный коммит promotion-only, changelog ссылается на закрытые issue. - **Что приходит потом:** дефект, найденный на стенде, дома или пользователем, — **новый issue** типа «баг» со ссылкой на исходный. Исходный не переоткрывается. ### 2.9 Заблокировано / Отклонено - **Заблокировано:** обязательна ссылка на блокирующий issue или внешнюю причину и дата пересмотра. Без причины статус не ставится. - **Отклонено:** закрытие с записанной причиной (вне скоупа, дубликат, цена не оправдана). Тихое закрытие без причины запрещено. --- ## 3. Правила Продолжение черновика владельца. Каждое правило проверяемо — глазами или машиной. 1. **Никаких изменений в код, если нет issue** и он не помечен «Готово к разработке» или дальше. 2. **Issue не может быть взят в разработку**, пока у него нет ТЗ с зелёным ревью, пронумерованных AC с указанием доказательства и назначенного исполнителя. 3. **Issue не может быть взят дважды.** Занятие фиксируется назначением, меткой и комментарием с именем ветки. У одного исполнителя одновременно не более одного issue в разработке. 4. **Статус меняется до действия, а не после.** Взял — поставил метку; отдал на ревью — поставил метку. Метка, поставленная задним числом, — дефект процесса. 5. **Ровно одна метка статуса** на issue в любой момент. Ноль или две — дефект, еженедельная гигиена его показывает. 6. **Автор не ревьюит своё** — ни ТЗ, ни код. Никто не переводит свою работу через ревью-гейт. 7. **Ревью возвращает не более 4 раз.** Пятый заход — решение владельца: разделить, отклонить или арбитраж (§4). 8. **High блокирует. Medium становится issue.** Low либо правится, либо снимается решением ревьюера с записью в документе. 9. **Скоуп не расширяется.** Всё найденное вне ТЗ — новый issue, а не попутная правка. Блокирующая находка отправляет текущий issue в «Заблокировано». 10. **Каждый коммит класса A и B несёт трейлер `Issue: #NN`**, ветка называется `issue/NN-slug`, а `User-Visible: yes` требует правок в **обоих** changelog в том же коммите. 11. **Документация — в том же коммите, что поведение.** Отдельным «допишу потом» коммитом документация не бывает. 12. **Сгенерированное не коммитится само по себе.** Только релизный промоушен или принятие эталонов со ссылкой на прогон CI. 13. **Golden-эталоны принимаются только** `npm run golden:accept -- --reviewed` по полному Linux-артефакту. Принятие ради зелёного CI — нарушение процесса. 14. **Issue закрывается после выпуска беты** с зелёным CI на точном SHA. Не раньше, не «по факту наличия кода», не исполнителем. 15. **Закрытый issue не переоткрывается.** Новый дефект — новый issue со ссылкой. 16. **Стабильный релиз — promotion-only:** версии, сгенерированные бандлы, changelog и release-метаданные. Продуктового кода там нет. 17. **История `dev` не перезаписывается.** На неё ссылаются теги. Нарушение исправляется следующим коммитом плюс issue с меткой `процесс` — не force-push'ем. 18. **AC доказывает автотест или запись ревьюера.** Фразы «проверил локально, всё работает» в процессе не существует: либо тест, который умеет падать, либо честное «проверено чтением, не исполнением». 19. **Параллельных бэклогов нет.** Планы, разборы и приоритеты живут в issue; файловые отчёты — разовые и датированные. 20. **Аварийный хотфикс — только решением владельца** и только по §11.2. --- ## 4. Лимит циклов ревью: 4 Оба ревью-гейта возвращают задачу на правки не более **4 раз**. Счётчик виден в имени документа: `-r1` … `-r4`; на четвёртом заходе ставится метка `ревью-4`. - **Что считается циклом:** отправка на ревью → вердикт с блокирующими находками → возврат. Уточняющий вопрос без вердикта циклом не считается. - **Исчерпание лимита — не «пятая попытка», а разбор.** Задача уходит владельцу, решение одно из трёх: 1. **разделить** — issue закрывается как «заменён», вместо него 2–3 меньших с ясным скоупом (частый настоящий диагноз: ТЗ было слишком большим); 2. **отклонить** — цена решения оказалась выше ценности; 3. **арбитраж владельца** — владелец фиксирует решение в issue, оно принимается как есть; несогласие ревьюера записывается, но не блокирует. - **Граница между «циклом» и «новым багом»:** до закрытия беты находка ревьюера — возврат на правки; после закрытия — новый issue. Иначе лимит 4 обходится заведением issue вместо возврата. - Для лёгкого трека лимит ревью ТЗ — **2** цикла: задача на три часа, которую переписывают трижды, лёгкой не была. --- ## 5. Лёгкий трек (метка `малое`) **Критерии — все одновременно:** - сложность и риск ≤ 3; - одна поверхность (один диалог, один модуль, один эндпоинт); - нет миграции конфига и новых compatibility-полей; - нет нового UX-контракта — меняется поведение в рамках уже описанного; - нет влияния на производительность и на touch-контракт. **Что упрощается:** - ТЗ пишется **в теле issue** по шаблону: проблема · контракт · AC1…ACn с доказательством · откат. Файл в `docs/specs/` не создаётся; - ревью ТЗ — комментарий второго агента, отдельный документ не нужен; - лимит ревью ТЗ — 2 цикла. **Что не упрощается:** issue, оценка, статусы, трейлеры коммитов, changelog, **код-ревью и его документ**, закрытие после беты. Код-ревью не пропускается никогда — именно оно в этом процессе заменяет тестирование. Если по ходу выясняется, что критерий нарушен (появилась миграция, задело второй модуль) — метка `малое` снимается, issue возвращается в «ТЗ в работе» и получает нормальный файл ТЗ. Это не провал, это ранняя диагностика. --- ## 6. Роли Один агент может исполнять несколько ролей в разных issue, но **не две роли в одном артефакте**. | Роль | Делает | Не имеет права | |---|---|---| | Аналитик | разбор, оценки, поверхности | окончательно ставить приоритет | | Автор ТЗ | `docs/specs/NN-*.md` или ТЗ в issue | ревьюить своё ТЗ | | Ревьюер ТЗ | `docs/reviews/SPEC-REVIEW-NN-rN.md` | править ТЗ вместо автора | | Разработчик | код, автотесты, документация, changelog | ревьюить свой код, принимать golden | | Ревьюер кода | `docs/reviews/CODE-REVIEW-*-rN.md`, проверка AC | править продуктовый код | | Релиз-менеджер | пре-релиз, стабильный релиз, закрытие issue | добавлять код в релизный коммит | | Владелец | приоритет, ценность, скоуп, отклонение, арбитраж, хотфикс | — | **Правило разделения:** ревьюер работает состязательно. Ему передаётся тег или диапазон коммитов и ТЗ — не рассказ автора о том, как всё хорошо. **Принято по умолчанию, поправь если не так:** ревьюер — отдельная сессия (Cowork / Codex / Cursor Cloud), выбор чередуется, лишь бы это была не та сессия, что делала артефакт; релиз-менеджер — владелец. --- ## 7. Артефакты и трассируемость ### 7.1 Цепочка ``` issue #NN ↔ ТЗ docs/specs/NN-slug.md (или тело issue при `малое`) ↔ ревью ТЗ docs/reviews/SPEC-REVIEW-NN-rN.md (или комментарий при `малое`) ↔ ветка issue/NN-slug ↔ коммиты трейлеры Issue: #NN · User-Visible: yes|no ↔ ревью кода docs/reviews/CODE-REVIEW--rN.md ↔ changelog бюллетень RU+EN со ссылкой на #NN ↔ бета тег, зелёный CI на точном SHA → закрытие ``` Обязательные разделы ТЗ: проблема · скоуп и **не-скоуп** · контракт поведения · UX · модель данных и миграция · i18n · критерии приёмки AC1…ACn с указанием доказательства · план автотестов · риски · откат · release-артефакты. ### 7.2 Шаблоны комментариев Короткие и однообразные, чтобы читались и человеком, и машиной. - **Аналитика:** `Оценка: ценность N/10 · сложность N/10 · P<1-3> · тип · поверхности: … · дубликаты: … · лёгкий трек: да/нет` - **Занятие:** `Взял: <роль> · сессия · ветка issue/NN-slug` - **Хендофф:** `Сделано: … · Файлы: … · Гейты: <команда → результат> · НЕ сделано: … · Риски: … · Следующий статус: … · Новые issue: #…` - **Вердикт ревью:** `Вердикт: зелёный/жёлтый/красный · цикл r/4 · High: N · Medium: N → #… · Документ: docs/reviews/…` - **Закрытие:** `Выпущено в <тег беты> · CI: <ссылка> · Changelog: <ссылка>` ### 7.3 Расхождения с текущим состоянием, которые надо закрыть 1. **Ревью живут вне репозитория.** 20+ файлов `CODE-REVIEW-*.md` и `SPEC-REVIEW-*.md` лежат только в личной папке владельца. Агент, пришедший через месяц, не видит, почему решение принято именно так, и повторяет разобранную ошибку. → `docs/reviews/`. 2. **Статус ТЗ дублирует статус issue.** `docs/specs/README.md` держит колонку «Статус ТЗ» со своим словарём («черновик решения», «в реализации», «реализовано»). Два источника статуса уже расходятся. Колонку убрать, оставить таблицу «issue ↔ ТЗ». --- ## 8. Гейты **Локальный гейт перед выходом из «В разработке»** — минимальный набор, покрывающий изменённые поверхности (действующее правило владельца): ``` npx tsc --noEmit npm test npm run build && cmp dist/houseplan-card.js custom_components/houseplan/frontend/houseplan-card.js \ && cmp dist/houseplan-card.js demo/srv/assets/houseplan-card.js node demo/smoke_<целевые>.mjs npm run golden:verify # если менялся визуал python -m pytest tests_backend -q # py3.13, если менялся бэкенд ``` **Гейт беты** (условие закрытия issue): CI Validate зелёный на точном SHA тега. **Гейт стабильного релиза:** полный локальный прогон плюс Validate и Full Performance зелёные на точном SHA; статусов issue не касается. --- ## 9. Метки — канонический статус Статус читается из меток: их видно в списке issue и их читает любой токен с доступом к Issues, в отличие от Project v2, который требует отдельного скоупа. Project v2 остаётся человеческим представлением и синхронизируется по меткам. | Метка | Статус | |---|---| | `S1-новое` | Новое | | `S2-аналитика` | Аналитика и оценка | | `S3-тз` | ТЗ в работе | | `S4-тз-ревью` | ТЗ на ревью | | `S5-к-разработке` | Готово к разработке | | `S6-в-разработке` | В разработке | | `S7-код-ревью` | Код-ревью | | `заблокировано` | Заблокировано (поверх статусной метки) | | `отклонено` | Отклонено, issue закрыт | Модификаторы: `малое` (лёгкий трек), `hotfix`, `процесс`, `ревью-4`, приоритет `P1`/`P2`/`P3`, тип `баг`/`фича`/`техдолг`. Правила: ровно одна `S*`-метка; закрытый issue статусных меток не несёт; `заблокировано` не заменяет статус, а дополняет его. --- ## 10. Механизация при прямых коммитах в `dev` Решение владельца — работать без PR. Значит, GitHub не может ничего заблокировать на своей стороне: **основной гейт переезжает на клиента, CI остаётся страховкой.** ### 10.1 Хуки, которые невозможно забыть поставить `.githooks/` в репозитории, `core.hooksPath` выставляется автоматически при установке зависимостей: ```json "scripts": { "prepare": "node scripts/install-hooks.mjs" } ``` `npm ci` вызывает `prepare` сам — значит, хуки появляются в каждом окружении, включая свежий контейнер облачного агента, без отдельного шага в инструкции. - **`commit-msg`** — отклоняет коммит без `Issue: #NN`, если тронут класс A или B; проверяет `User-Visible`. - **`pre-push`** — прогоняет `scripts/process-gate.mjs` по всему пушимому диапазону. Это и есть блокирующий гейт вместо PR. ### 10.2 Что проверяет `process-gate.mjs` Офлайн, без GitHub API: 1. трейлер `Issue: #NN` у каждого коммита класса A/B; 2. имя ветки `issue/NN-slug` соответствует трейлерам; 3. для класса A существует `docs/specs/NN*-*.md` со ссылкой на issue — **или** issue помечен `малое` (для этого нужен этап 2, до него — исключение по списку); 4. `User-Visible: yes` → правки в обоих changelog в том же коммите; 5. коммит только класса D невалиден без `Release: vX.Y.Z` либо `Baseline-Reviewed: <ссылка на прогон CI>`; 6. релизный коммит не содержит изменений в `src/` и `custom_components/**/*.py`; 7. документов ревью на один issue не больше четырёх (`-r1`…`-r4`). С токеном GitHub (PAT уже есть у релизных скриптов): 8. `--issues` тянет каждый упомянутый issue и требует метку из {`S5-к-разработке`, `S6-в-разработке`, `S7-код-ревью`}; закрытый или отсутствующий issue — отказ (fail closed); 9. `npm run release:prerelease -- --issues=…` отказывается, если у issue нет зелёного вердикта код-ревью; 10. закрытие issue и снятие статусных меток автоматизируются по факту публикации беты — в `publish-prerelease.yml`, а не по памяти человека. ### 10.3 Страховка и разбор - **Тот же `process-gate.mjs` — job в `validate.yml`.** При прямом push проверка догоняющая: код уже в `dev`, CI краснеет после. Это принятая цена отказа от PR. - **Нарушение не откатывается force-push'ем** (правило 17): исправляющий коммит плюс issue с меткой `процесс`. Починить надо проверку, а не только симптом. - **Еженедельная гигиена** (workflow): issue в «Новое» дольше 14 дней и в «В разработке» дольше 7; issue класса A в `S5` без ТЗ; issue с нулём или двумя `S*`-метками; коммиты без трейлера за неделю — **цель 0**; rework rate и число issue, дошедших до `ревью-4`; **баги, заведённые после закрытия беты** — прямая цена отказа от фазы тестирования. --- ## 11. Исключения ### 11.1 Лёгкий трек См. §5 — это не исключение из правила №1, а более дешёвый путь по тем же статусам. ### 11.2 Аварийный хотфикс (метка `hotfix`, решение владельца) Разрешено писать код до появления issue. Обязательно: - issue создан в **той же сессии до коммита**, метка `hotfix`; - ТЗ «как сделано» + раздел «почему нельзя было ждать»; - в течение 24 часов задача ретроспективно проходит код-ревью; - аварийность названа явно в релизном хендоффе (действующее правило `AGENTS.md`). ### 11.3 Гигиена репозитория Механические изменения без изменения поведения (форматирование, мёртвые файлы) идут под квартальный umbrella-issue «Гигиена репозитория»; каждый коммит ссылается на него. Трассируемость 1:1 сохраняется. --- ## 12. Запрещено - код без issue или из статуса раньше «Готово к разработке»; - ТЗ, написанное после кода (кроме §11.2, и тогда с пометкой «как сделано»); - ревью своей работы; перевод своей работы через ревью-гейт; - пятый цикл ревью вместо разбора по §4; - заведение issue вместо возврата на правки, чтобы обойти лимит циклов; - принятие golden-эталонов ради зелёного CI или по частичному артефакту; - закрытие issue до выпуска беты с зелёным CI; - переоткрытие закрытого issue вместо нового бага; - Medium-находки, оставленные как TODO в документе ревью; - **параллельные бэклоги** в файлах (`BACKLOG-*.md`, «планы» в docs); - ревью-документы вне репозитория; - попутные правки «раз уж я здесь»; - фича или материальное изменение поведения в стабильном релиз-коммите; - force-push в `dev`; - ручное копирование на домашний инстанс. **Нарушение процесса — тоже issue** (метка `процесс`): если правило удалось нарушить незаметно, виновата проверка. --- ## 13. Внедрение 1. Создать метки §9; разметить 38 открытых issue. Всё, что по `docs/specs/README.md` «в реализации», но не прошло ревью, — в честный статус. 2. Перенести существующие `CODE-REVIEW-*.md` и `SPEC-REVIEW-*.md` в `docs/reviews/`; убрать колонку «Статус ТЗ» из `docs/specs/README.md`. 3. Завести issue на сам гейт (класс B, техдолг): `scripts/process-gate.mjs`, `.githooks/`, `prepare`-скрипт, job в `validate.yml`. По новому процессу он сам обязан пройти ТЗ → ревью → реализацию. 4. Закрыть текущий долг ревью: `beta.2…beta.4` без код-ревью, среди них две новые фичи (#90, #94). 5. Завести issue на находку «смок `visual_continuity` не умеет падать» из разбора 11.08 — это ровно тот класс дефектов, который в процессе без ручного тестирования стоит дороже всего. 6. `BACKLOG-2026-08-11.md` объявить разовым отчётом: решения — в issue. 7. Добавить в `AGENTS.md` блок §14. --- ## 14. Блок для AGENTS.md ```markdown ## Процесс: код только через issue Изменение продуктового кода без issue запрещено. Код меняется только из статуса «Готово к разработке» или дальше. Полные правила, критерии статусов и гейты — `docs/PROCESS.md`, читать до начала работы. Жизненный цикл (статус = метка issue): `S1-новое` → `S2-аналитика` → `S3-тз` → `S4-тз-ревью` → `S5-к-разработке` → `S6-в-разработке` → `S7-код-ревью` → закрытие после выпуска беты. Оба ревью возвращают на правки не более 4 циклов; пятый заход — разбор у владельца (разделить / отклонить / арбитраж). - ветка `issue/-`, коммиты с трейлерами `Issue: #NN` и `User-Visible: yes|no`; - работаем прямыми коммитами в `dev`, без PR: блокирующий гейт — локальный `pre-push` (ставится автоматически через `npm ci`), CI — страховка. Force-push в `dev` запрещён; - автор ≠ ревьюер, ни для ТЗ, ни для кода; - фазы ручного тестирования нет: автотесты пишутся в реализации, AC проверяет код-ревью, найденные позже дефекты — новые issue типа «баг»; - мелкие задачи (метка `малое`, сложность ≤3): ТЗ в теле issue, ревью ТЗ комментарием, код-ревью — как обычно; - найденное вне скоупа — новый issue, а не попутная правка; - issue закрывает релиз-менеджер после выпуска беты, не исполнитель. ```