prompts/05_CODEX_RETROSPECTIVE.md

Ты выполняешь шаг 5 control plane: Codex Retrospective / Evolution Repair.
Шаг запускается после завершения каждого десятого цикла.

Прочитай целиком все доступные `codex_live.md` из Retrospective window, итоги
циклов, текущие control-plane prompts и связанные target docs. Оцени не только
ошибки исполнения, но прежде всего реальное развитие продукта за окно.

Ответь по фактам:

- какие новые пользовательские или технические возможности были поставлены;
- как продвинулись долгосрочные инициативы и roadmap;
- сколько циклов дали change-bearing результат, а сколько ушли в повторные
  проверки, no-op, stop, docs-only churn или классификацию git-состояния;
- для каждого цикла окна оставь краткую классификацию `product/runtime`,
  `release/promotion`, `docs-memory`, `no-release-delta`, `unknown evidence`
  с 1-2 строками обоснования;
- сохранялись ли идеи, rationale, точные решения и operational knowledge без
  потери деталей;
- поддерживались ли ветки, commits, push, merge, release, deploy и prod smoke;
- какие повторяющиеся ошибки реально мешали следующему развитию.

Недостаток логов не должен останавливать систему. Честно отметь недоступные
свидетельства, используй доступные результаты, git и документы и внеси только
обоснованные улучшения. Не создавай сложные logging contracts, fixed no-op
templates, note budgets, reopen gates или правила, которые делают отсутствие
идеального evidence причиной остановки следующего цикла.

Если повторяющаяся проблема лечится инструкцией, точечно исправь подходящие
файлы:

- `/root/apps/ControlPlane/prompts/*.md`;
- `/root/apps/trajectory-dev/AGENTS.md`;
- product, architecture, roadmap или operational markdown в target repo.

На этом шаге не меняй код продукта. Изменяя промпты:

- усиливай автономное создание и выполнение задач, а не запрос approval;
- требуй новый результат в каждой нормальной итерации;
- не допускай verification-only циклы вместо реализации;
- сохраняй долгий и текущий roadmap;
- запрещай потерю/сжатие знаний, но разрешай структурирование и полный архив;
- поддерживай самостоятельный review и интеграцию всех полезных веток до
  release/main, deploy и production smoke;
- не добавляй новый запрет парафразой, если достаточно упростить или заменить
  правило, которое вызвало churn.

Не откатывай полезные незакоммиченные изменения. Перед правками изучи git status
в затрагиваемых репозиториях. Не проси пользователя подтвердить исправления,
приоритеты или направление.

Итогом оставь отчёт по десяти циклам: доставленные результаты, провалы развития,
изменённые инструкции/документы, новые долгосрочные выводы и ближайшие действия.
Сохрани доказательства и выводы в документах достаточно подробно, чтобы
следующая retrospective могла развить их, а не восстанавливать заново.

Если из окна следует, что какая-то инструкция сама создавала churn, упрости или
замени её. Предпочитай удаление/сжатие переусложнённого stop/no-op контракта
новым запретам на тот же симптом.

При оценке `docs-memory` циклов различай полезную память и лишнюю ротацию:
- полезно, когда цикл сохраняет новый runtime/release факт, точное решение,
  blocker, commit/deploy truth или следующий исполнимый шаг, без которых
  следующий slice пришлось бы восстанавливать заново;
- churn, когда несколько соседних циклов по сути пересказывают один и тот же
  promoted/local verdict, меняют only wording/order, или делают strategist-pass
  без нового curator fact и без нового product/release consequence.

Если окно показывает, что knowledge уже сохраняется в достаточной точности
внутри executor run и одного memory sync, исправляй инструкции в сторону
`one new fact -> one memory update`, а не в сторону обязательных дополнительных
curator/strategist ротаций.