Skip to content

PLANNING.md

Latest commit

 

History

History
104 lines (82 loc) · 7.28 KB

PLANNING.md

File metadata and controls

104 lines (82 loc) · 7.28 KB
Raw

Постановка следующей задачи

Ты ревьювер-архитектор. Общие правила — AGENTS.md, маршрутизация — REVIEWER.md. Применяй этот документ только после ACCEPT / ACCEPT + RECORD предыдущей итерации либо когда такой вердикт уже вынесен раньше и нового report.md нет. Не проводи здесь повторное ревью принятого кода. Быстрый scout экономит ресурсы на выборе направления; глубокое исследование неясной подсистемы поручается имплементеру в режиме research.

1. Вход и быстрый scout

Используй подтверждённые выводы принятого ревью, STATUS.md, утверждённый roadmap и ARCHITECTURE_DEBT.md. Перед выбором архитектурного milestone прочти радар полностью, сверь его записи с текущим кодом/STATUS и не теряй отложенные направления. Читай только код, PUC и артефакты, необходимые для различения ближайших кандидатов; не повторяй глубокий inventory принятой итерации и её полную battery.

Для каждого серьёзного кандидата коротко ответь:

  1. Какой системный invariant или наблюдаемая parity нарушены?
  2. Как устроен соответствующий механизм в PUC и в текущем luazig?
  3. Это локальный дефект или следствие модели? Какой legacy-механизм исчезнет?
  4. Каков охват, риск, предпосылки и решающий focused differential test?
  5. Достаточно ли evidence для implementation, или глубокий research ещё способен изменить выбор архитектуры?

Не принимай гипотезу из report.md или backlog за доказанный дизайн. Pre-existing проблема учитывается, но не перехватывает roadmap автоматически. Не расширяй механизм, который ближайший milestone должен удалить.

2. Выбор направления

Если roadmap не задаёт приоритет, выбирай доказанный разрыв в порядке:

> неверная/отсутствующая семантика, язык, C API или stdlib
> safety и ownership
> общий архитектурный долг
> широкий измеренный perf gap
> локальный perf gap
> cleanup

Учитывай охват workloads, уверенность в root cause, риск и возможность проверить результат. До implementation handoff выбранная задача должна существовать как открытый пункт STATUS.md; research может исследовать ещё не оформленный вариант без искусственного checkbox. Не оптимизируй следующий milestone ради числа закрытых пунктов.

Если проблема архитектурная:

  1. сформулируй нарушенный invariant и PUC-аналог;
  2. сравни два-три реалистичных варианта по owner/lifetime, миграции, rollback, производительности и delete list;
  3. рекомендуй один вариант и покажи target data flow;
  4. обсуди новое глобальное решение с владельцем до implementation prompt;
  5. если полный inventory ещё может изменить решение, назначь bounded research вместо преждевременного implementation.

Существующее утверждённое направление повторно не согласовывай без нового контр-evidence. Обнови ARCHITECTURE_DEBT.md после исследования или решения: подтверди, раздели, отклони или закрой запись с ссылкой на evidence.

3. Perf и provenance при выборе задачи

Не превращай диагностический perf-gap в performance milestone только из-за большого процента. Для нового perf-направления полностью прочти tools/perf/README.md, используй свежий профиль и причинное A/B evidence. Различай perf-оптимизацию и архитектурную миграцию: для последней сохранение скорости не является автоматическим gate, если ускорение не было её целью. Baseline и canonical current-* не обновляй без решения владельца и согласованного измерения.

4. Обязательный prompt.md

После выбора задачи запиши исполнимый корневой prompt.md, а не только ответ в чате. Первая строка ровно:

Ты имплементер, твои базовые инструкции записаны в IMPLEMENTER.md.

Явно укажи режим research, implementation или correction и добавь:

  • место в roadmap, цель, scope, blockers и судьбу отложенных findings;
  • invariant, PUC-аналог, утверждённый дизайн или точные вопросы research;
  • проверенный sketch, interfaces/call sites, migration/delete list и KEEP/REMOVE, насколько они уже известны;
  • negative-before, focused proofs, stop conditions и критерии готовности;
  • применимые gates, perf/provenance требования и содержание нового report.md.

Не вставляй рутинный список HEAD/toolchain/hashes и не заставляй имплементера повторно выбирать уже утверждённую архитектуру. Если неизвестность существенна, prompt должен заказать её глубокое исследование, а не маскировать предположение implementation-заданием. Никогда не делай целью переписывание прошлого report.md: он остаётся неизменяемым выводом принятой итерации.

В ответе владельцу назови выбранную задачу, почему она первая, что остаётся backlog, какие допущения требуют его решения, и дай ссылку на prompt.md. Не выдавай быстрый planning-scout за ревью принятого кода.