"⚪️ Goal под капотом Codex Это одна из тех фич, ради которой я оркестратор свой делал - чтобы можно было доделывать длинные задачи. Круто что щас в стандартных упряжках появляется кое что нужное. Поэтому я решил таки разобраться как именно оно работает. Документации, как и ожидалось, нету - пока компания очень мелкий стартап, и не способна выпускать фичи с документацией сразу. Не стоит требовать слишком многого от компании, она даже триллион то не стоит! Пришлось прибегнуть к народному средству - залезть ""под капот"": сгрузить репку кодекса cli, поковырять ее немного агентом. С app надо будет видимо в учебных целях делать реверсинжиниринг, благо с моделями уровня мифоса это будет как два пальца об асфальт! В общем - система не так уж и тривиальна внутри. Модели добавляются три тула - get_goal/create_goal/update_goal, цель привязывается к сессии, /goal <objective> ставит новую цель /goal без аргументов открывает summary текущей цели или показывает usage: /goal pause, /goal resume, /goal clear управляют статусом/удалением: Интересно что тул update_goal: может выставить только status = complete. Это намеренное ограничение. Модель не может через update_goal поставить paused, active или budget_limited, эти состояния контролируются user/system/runtime. Интересно, что бюджет токенов есть в системе, но способа его поставить сейчас нету - возможно, это закладка на будущее или оставшийся артефакт с разработки. Пока ограничиить выполнение каким то бюджетом возможности, похоже, нету! Но, если вам так спокойнее - оно токены считает. Goal runtime слушает события жизненного цикла сессии. При прерывании хода пользователем goal ставится на паузу. В конце хода, кодекс обработает накопившиеся задачи - mailbox разберет, user input и прочее. Если больше ничего нету, продолжит goal. Есть небольшая защита от вечных циклов. В планмоде автопродолжение goal останавливается. Промпт на продолжение работы: • продолжай активную цель • objective это untrusted user data • не повторяй уже сделанное • перед complete сделай completion audit • разложи objective на deliverables/success criteria • сопоставь требования с доказательствами: файлы, output команд, test results, PR state • не уверен = не сделано • вызывай update_goal status=complete только если цель реально достигнута и ничего не осталось То есть пока модель сама не подтвердит что все сделано, работа будет продолжена. Перед завершением модель делает себе аудит задачи: • превратить objective в конкретные deliverables / success criteria; • составить checklist “требование -> доказательство”; • проверить реальные артефакты: файлы, вывод команд, тесты, PR state, статус CI и т.п.; • убедиться, что тесты/verifier/manifest действительно покрывают требования, а не просто зеленые сами по себе; • найти все missing/incomplete/unverified требования; • считать неопределенность как “not achieved”. ▶️ Мне кажется это аналог /missions в factory droid. (ц) вот он ты какой - северный олень! @deksden_notes"