/planning

name: planning
description: После принятого ретро выбрать результаты следующей недели, обновить задачи и сохранить связанный HTML-план. Триггеры: "планирование", "план недели", "что делаем на следующей неделе".
disable-model-invocation: true

Planning

Планирование смотрит вперёд и не выполняет запланированную работу.

Пререквизит

До начала найди принятый отчёт `reports/ГГГГ-WNN-retro.html` за предыдущую неделю.

Если ретро не завершено или не принято, остановись и предложи сначала запустить `retro`.

Граница

Планируй только текущий отдел. Не обходи штаб и соседние отделы. GitHub разрешён только как активный источник задач текущего отдела, указанный в `tasks/README.md`.

Источниками состояния остаются локальные записи задач или GitHub Issues согласно активному режиму. HTML-план — представление выбранных результатов и ссылок.

Этап 1. Собрать вход

Прочитай:

1. `AGENTS.md`, `README.md` и блок "Активный режим" в `tasks/README.md`; 2. принятый отчёт ретро; 3. все открытые задачи из активного источника; 4. решения по незавершённым задачам; 5. последнее принятое изменение правил.

Для планирования открыты только задачи со статусом `новая`, `в работе`, `на приёмке` или `заблокирована`. Задачи `завершена` и `снята`, а также закрытые GitHub Issues не являются обязательствами новой недели.

Не переноси открытую задачу автоматически. Используй решение из ретро. Если в режиме GitHub Issues остался хотя бы один локальный файл со статусом `новая`, `в работе`, `на приёмке` или `заблокирована`, остановись до устранения конфликта источников.

Этап 2. Выбрать результаты недели

Результат недели описывает проверяемое состояние, а не действие.

Плохо:

Поработать над рассылкой.

Хорошо:

Первое письмо отправлено выбранному сегменту, ссылка и результат проверки записаны в задаче.

Предложи варианты на основе фактов, затем задавай founder по одному вопросу для решений, которых нет в источниках.

Для каждого принятого результата зафиксируй:

• что должно стать правдой;
• как это проверить;
• к какой дате;
• какая запись задачи владеет состоянием;
• что сознательно не входит в неделю.

Этап 3. Создать или обновить задачи

• В режиме `локальные файлы` создай запись по `tasks/_template.md`, если задачи ещё нет, или обнови существующий файл.
• В режиме `GitHub Issues` создай новую Issue в указанном репозитории или обнови существующую Issue той же задачи.
• Не создавай второй файл или Issue для той же работы.
• Заполни дату планирования и один следующий шаг в действующем источнике.
• Не выполняй следующий шаг во время планирования.

Этап 4. Сохранить HTML-план

Создай:

reports/ГГГГ-WNN-plan.html

План содержит:

• результаты недели и критерии проверки;
• раскладку по дням, если даты уже выбраны;
• ссылки на записи задач;
• сознательно исключённую работу;
• ссылку на отчёт предыдущего ретро.

Используй семантический HTML и встроенный CSS без сборщика. Не копируй полное состояние задач.

Добавь в навигационный блок предыдущего HTML-отчёта ретро ссылку на новый план, не переписывая остальные секции отчёта. В плане должна быть обратная ссылка на ретро.

Этап 5. Проверка и приёмка

Проверь:

• каждый результат проверяем;
• каждый результат связан с одной или несколькими задачами;
• одна задача не продублирована несколькими файлами;
• даты не находятся в прошлом;
• HTML ведёт к актуальным записям задач;
• ссылки ретро и плана работают в обе стороны;
• ни одна задача не была выполнена во время планирования;
• HTML содержит закрытые `html`, `head`, `body`, `main` и `section`, а число открывающих и закрывающих структурных тегов совпадает;
• каждая относительная ссылка разрешается в существующий локальный файл;

Покажи план founder. После приёмки можно завершить сессию планирования и отдельно перейти к выполнению первой задачи.

Запрещено

• планировать без принятого ретро;
• превращать список всех идей в обязательства недели;
• выполнять задачи внутри planning;
• хранить состояние только в HTML;
• создавать новые задачи вместо обновления существующих;
• молча переносить незавершённое.