Рабочие сценарии: как применять возможности вместе
Это учебные сценарии, а не выдуманный отчёт о личной эксплуатации. Способы открытия чатов проверены по документации. Описанные модельные запросы не запускались при подготовке страницы. Читайте их как разбор ситуаций; выполнять упражнения необязательно.
Проверить, началась ли работа после очереди CLI
Сверка 2 ноября 2026 года, Developer commands. Для codex queue --resume подтверждение очереди не доказывает возобновление. Нужен работающий локальный daemon либо выбранный удалённый сервер; при неудаче возобновления возможны предупреждение и успешное завершение команды. Сообщения очереди используют модель сеанса и принимают только текст. Возможность --resume описана для CLI 0.166.0; установленный клиент здесь не обновлялся.
Windows / PowerShell: значение $LASTEXITCODE после команды — только один сигнал. Прочитайте предупреждения, откройте нужный чат, проверьте состояние и затем сохранённый результат. Код 0 сам по себе не является подтверждением выполнения. Команда в этом разборе не запускалась; задача не ставилась в очередь.
Без практики: представьте запись «очередь принята; возобновление не удалось; код 0». Можно утверждать лишь, что поручение принято в очередь. Нельзя отметить задачу выполненной или молча отправлять её заново: сначала проверьте, что произошло с первым сообщением. Успешную проверку описывайте как «чат выполнил ограниченную задачу, результат сохранён и проверен».
1. Учиться, пока агент делает задачу
Ситуация: основной чат исправляет импорт CSV. В ответе появился незнакомый термин — идемпотентность.
Действия: откройте /side или Ctrl+Alt+S в Windows Codex. Попросите:
Объясни идемпотентность на примере повторной загрузки одного CSV.
Что произойдёт без неё и какое поведение ожидается с ней?
Только объяснение. Не меняй реализацию и не давай указаний основному чату.
Что оценить: вы можете привести конкретный повторный запрос и ожидаемый результат. Агент не получил незаметного разрешения расширить реализацию. Если разбор выявил пропущенное требование, вернитесь в основной чат и добавьте его явно.
Если только читаете: повторная отправка файла не должна создавать дубликаты там, где контракт требует однократного эффекта. Но само слово «идемпотентность» не определяет, по какому ключу распознаются повторы: это нужно согласовать в задаче.
2. Сравнить два решения, сохранив требования
Ситуация: вы выбираете между синхронной обработкой файла и фоновой очередью.
Действия: после уточнения требований создайте /fork. В новой переписке попросите альтернативный план, сохраняя исходный объём, формат API и критерии. Сначала сравните планы. Если оба варианта будут реализованы, выберите отдельные worktrees и проверьте начальное состояние каждой копии.
Рассмотри альтернативу текущему плану: фоновые задания.
Сохрани согласованный контракт загрузки и требования к повторной отправке.
Пока только анализ: сравни сложность, отказоустойчивость и проверки.
Не меняй файлы и не начинай развёртывание.
Что оценить: варианты отвечают на один вопрос и сравниваются по одинаковым критериям. Чаты не меняют одни и те же файлы одновременно. Результат fork не считается автоматически принятым в основном чате.
Если только читаете: очередь добавляет состояния ожидания, выполнения и ошибки, а также проверку повторов. Она полезна при подходящей нагрузке, но не является обязательным улучшением маленькой синхронной задачи.
3. Связать требования, реализацию и проверку
Ситуация: работа длится несколько дней. Один чат уточняет требования, другой реализует, третий проверяет.
Действия: держите работу в подходящем проекте, но передавайте состояние явно. Результат обсуждения требований — документ с датой и согласованным статусом. Для реализации укажите путь и ревизию. Для ревью — ту же версию требований, фиксированный diff и выполненные проверки.
Проверь изменение по docs/import-requirements.md в указанной ревизии.
Кандидат: [полный commit], база: [полный commit].
Ничего не меняй. Для замечания назови место, условие и последствие.
Не считай неподтверждённые идеи из обсуждения обязательными требованиями.
Что оценить: проверяющий работает с теми же требованиями и конкретной версией кода. Ссылка на соседний чат помогает восстановить обсуждение, но не заменяет доступный документ и ясное поручение.
Если только читаете: общая папка — общие файлы; общая переписка из этого не следует. Фиксация требований нужна даже тогда, когда агент умеет находить и читать другие чаты.
4. Уточнить текущую задачу или поставить следующую
Steer подходит, когда появилась важная поправка к выполняемой работе. Queue — когда это отдельное следующее задание, которое не должно менять текущую цель. Конкретные элементы управления зависят от клиента. Источники: Prompting, официальный Remote field guide.
Поправка к текущей задаче:
Сохрани прежнюю схему API. Продолжай текущее исправление в этом ограничении.
Следующая задача:
После завершения исправления подготовь отдельную заметку для пользователя.
Не расширяй ради неё текущий код.
Если вы хотите только разобраться, почему выбрано решение, откройте side chat. Не используйте случайное уточнение как способ незаметно заменить цель текущей работы.
Реальный пример из подготовки этого руководства
Первая русская редакция была подготовлена как Markdown-материалы и отдельный автономный HTML. Затем для обновления и чтения по модулям создан отдельный репозиторий. Материалы опубликованы через PR №1.
Для сайта оставлен один источник текста: те же Markdown-файлы. Метаданные страниц задают меню, а GitHub Pages собирает обычные веб-страницы. Это позволяет исправлять объяснение в одном месте. Такой вывод подтверждается структурой репозитория; он не доказывает, что side chat был использован при написании этих страниц, и не является измерением экономии времени.
Практический урок: выбирайте связь между работами по результату. Объяснение — в короткое обсуждение, альтернативу — в развилку, подтверждённое решение — в документ, готовое изменение — в проверяемую ревизию.