Tfw Plan

/tfw-plan

Преврати обычный запрос любого типа в проверяемую задачу, отдели постановку от исполнения и после Gate 0 координируй выбранный пользователем режим. Пользователю не обязательно знать slash-команду или устройство TFW. Plan не исполняет результат и не подменяет handoff/review.

1. Ориентация до записи

1. Прочитай PROJECT.md, AGENTS.md, knowledge/INDEX.md и только нужные записи knowledge/records/.
2. Определи текущее состояние и проблему; желаемое изменение; адресата; владельца приёмки; наблюдаемые критерии; источники; ограничения; формат результата и способ проверки.
3. Отдели факты от предположений. Если ответа не хватает для выбора результата, проверки или удержания существенного риска, одним сообщением задай не более трёх вопросов. Иначе явно запиши допущения и продолжай.
4. Определи текущего участника и его корпоративную/проектную роли по identity gate из AGENTS.md и .agents/skills/tfw-identity/SKILL.md. Обычному человеку достаточно естественного ответа с полным именем и фамилией; не показывай команду, identifier или локальный формат. Для нового profile соблюдай surname/collision gate, существующий valid identifier не пересчитывай. Автор новой записи равен определённому участнику, но владелец существующей задачи не меняется из-за нового чата.

2. Создай ID и пройди Gate идентификации

1. Сформируй slug из строчных латинских букв, цифр, ., _, -; первый символ — буква или цифра, последовательность __ запрещена.
2. Новый ID = YYYYMMDD-HHMMSS__slug. Handle владельца в ID и путь не включай: авторство хранится только в обязательном поле Владелец.
3. Атомарно создай только отсутствующую папку workspace/<ID>/. Если путь уже существует, не переиспользуй и не перезаписывай его: получи новый фактический timestamp и повтори создание.
4. Сразу после создания папки и до содержательного заполнения плана установи точное имя текущей Codex-задачи plan | <ID> и проверь успешный ответ операции либо последующее состояние.
5. Если точное имя нельзя установить или подтвердить, не создавай содержательный trace: сообщи требуемое имя как блокер раннего gate.

Legacy task folders не переименовываются. Если plan продолжает ранее созданную legacy-задачу, видимый номер исключает только однозначный средний __handle, а полный ID и стабильный путь остаются прежними.

3. Запиши постановку

1. Создай workspace/<ID>/TRACE.md с начальным Статус: doing и отдельными полями Владелец, Текущий участник: <identifier>, Корпоративная роль текущего участника, Проектная роль текущего участника и Роль ИИ: plan.
2. Заполни обязательные поля и план по шаблоны/план_работы.md: результат и приёмка, текущее состояние, границы и источники, вопросы и допущения, DoD/DoF, фазы и Gates.
3. Обязательно добавь Режим исполнения: ожидает выбора пользователя и объясни:
   • ручной: пользователь сам запускает каждый следующий чат по точной команде;
   • автономный: plan с отдельного явного разрешения создаёт и контролирует Codex-задачи только текущего task ID.
4. Предъяви краткое понимание и план. Явно попроси одним решением утвердить Gate 0 и выбрать режим.

До утверждения не создавай итоговый результат, не начинай активные изменения и не создавай handoff/review-задачи.

4. После ответа пользователя

• Если Gate 0 не утверждён, запиши замечания и оставайся в планировании.
• Если утверждён, запиши отдельные поля Gate 0, Основание Gate 0, точное Режим исполнения: ручной либо Режим исполнения: автономный и основание выбора.
• Автономное разрешение ограничь этим task ID и последовательным циклом handoff/review. Оно не разрешает менять постановку, обходить неделегируемые gates, создавать посторонние задачи или одновременно редактировать один trace.

Ручной режим

Запиши следующий шаг и выдай точную команду нового чата /tfw-handoff <ID или стабильный путь>. Дальнейшие переходы контролирует пользователь; обязательные name gates и отчёты ролей сохраняются.

Автономный режим

1. Проверь, что среда действительно предоставляет создание, именование, ожидание, чтение и продолжение Codex-задач. Если нет — честно переключись только на ручной режим и выдай точную команду; не заявляй автономность, которой нет.
2. Зафиксируй идентификатор coordinator thread и обязательный адрес отчётов.
3. Создай отдельную Codex-задачу handoff с ожидаемым именем handoff | <visible_id>. Передай полный стабильный путь, coordinator thread, запрет параллельной записи, обязательные preflight/exception/final reports и указание не задавать identity-вопрос отсутствующему человеку: текущий участник и обе его роли для автономной задачи — не применимо, владелец наследуется из trace.
4. Пока дочерняя роль активна, plan не редактирует task folder. Ожидай bounded-wait операциями; запрос внимания, blocker или deviation немедленно возвращай человеку.
5. После финального отчёта read-only сверь фактический статус, trace, результат и решение о знании. Отсутствие отчёта, неверное имя или расхождение с trace не являются успехом: запроси отчёт повторно либо зафиксируй блокер.
6. При Статус: review и полной самопроверке создай отдельную Codex-задачу review | <visible_id> с /tfw-review <стабильный путь> и тем же протоколом отчёта.
7. При FAIL и Статус: doing передай доказанные дефекты новой handoff-задаче; после исправления создай новую review-задачу. Не меняй постановку и не проси пользователя вручную переносить дефекты.
8. Продолжай цикл, пока дефекты устранимы в границах. Повторяющийся нерешаемый дефект, отклонение от плана, конфликт писателей, недоступный обязательный ресурс или неделегируемое действие — доказанный blocker, а не бесконечный цикл.
9. При независимом PASS убедись, что Решение о знании фактически исполнено и проверено. Сформируй один финальный пакет: результат, доказательства, central/внешние эффекты, knowledge decision, остаточные риски и вопрос о человеческой приёмке.
10. Только явное принятие владельцем после PASS позволяет plan изменить единственное поле Статус: review → done. Отклонение возвращает задачу в новый handoff.

5. Отчётный протокол ролей

В автономном режиме каждый handoff/review обязан отправить coordinator thread:

• preflight: фактическое имя и thread ID, отдельно текущий участник, его корпоративная/проектная роли, владелец и роль ИИ, полный task ID и путь, статус, основание допуска, baseline/hash, первая фаза;
• exception: немедленно — точные доказательства blocker/deviation/conflict/name-gate failure и остановка;
• final: фактическое имя, отдельно текущий участник, его корпоративная/проектная роли, владелец и роль ИИ, статус, task/trace/result paths, созданные/изменённые файлы, проверки и hashes, shared/local manifests, дефекты/блокеры, решение о знании, остаточные риски и точный рекомендуемый переход.

Если сообщение coordinator thread технически не отправлено, этап не считается завершённым. Роль сохраняет устойчивое состояние в trace, возвращает тот же отчёт в своём чате и требует ручной передачи.

Где остановиться

До Gate 0 — на запросе утверждения и режима. В ручном режиме — после точной следующей команды. В автономном — на доказанном blocker/deviation, неделегируемом gate либо на финальной человеческой приёмке после PASS. Не обещай работу при закрытом Codex, универсальную доступность thread-операций, аутентификацию участника, безопасную параллельную запись или завершённую удалённую синхронизацию.

Исполнение — /tfw-handoff. Независимая проверка — /tfw-review. Обновление набора — /tfw-update.