Немного про то как устроена магия под капотом CodeGraph:

1. Одним из источников истины помимо кода и документации в проекте является карта кода - Code Property Graph. Работа с ней выстроена не напрямую, а через слой MCP ориентированный на несколько сценариев использования: изучение кода, написание и проверка кода, проверка качества, безопасности и степени влияния изменений
2. Этими инструментами пользуются 11 ролей - цифровых сотрудников с общей проектной и индивидуальной памятью, разрешенным набором инструментов и правилами приемки и передачи задач по цепочке
3. Задачи бывают двух типов - быстрый фикс или какой-то отдельный таск который можно выполнить изолированно - он оформляется через внутренний механизм task capsule и обычно не требует полной цепочки исполнителей. Второй тип - более комплексные задачи, например, рефакторинг или разработка новой функциональности - всегда оформляются через спецификации (PRD) и здесь работает целый конвейер со строгими правилами: все PRD имеют единую структуру и проходят через валидатор, каждая спека связана с одной или несколькими user story по которым ведется и автоматически отслеживается единый реестр требований.
4. Запуск такого PRD в работу - это отдельный процесс требующий прохождения 9 обязательных стадий - от планирования реализации до документирования и автоматизированного контроля всех документационных реестров. За каждую стадию отвечает отдельная роль - цифровой сотрудник с именем и полномочиями. Выполнение задач строго последовательное, но могут быть возвраты на предыдущие шаги если проверяющие роли обнаружили какие-то недочеты. Весь этот цикл всегда идет в рамках одной Codex-сессии без использования субагентов, оркестраторов и т.п. Т.к. это снижает затраты на пересылку данных, на токены и т.п. Путаницы это не вызывает т.к. весь механизм передач строго детерминирован и работает через MCP-вызовы фиксирующие каждую стадию, каждую передачу и блокирующие продолжение при пропуске какого-то шага.
5. Если требуется явное подтверждение от человека, то процесс будет доведен до конца, но с явным блокером и по завершении задачи об этом будет явно сказано, что, например, требуется разрешение на такое-то действие (например, деплой на сервер)
6. В процессе работы накапливается память 3-х типов: а) Документационная - спецификации, планы реализации, приемочные листы, общий реестр требований оформленный как список user story со ссылками на конкретные участки кода и тесты подтверждающие реализацию требования и связанные с этим документационные артефакты. б) Проектная память и память цифровых сотрудников - различные агрегированные данные из чатов, правила которые были выявлены и добавлены в ходе общения и диалогов и т.п. в) Записи о реализации конкретных task capsule/story capsule - своего рода внутренний таск-трекер ориентированный на детальный аудит и полную прослеживаемость процесса - позволяет отслеживать эффективность самого SDLC-процесса. В идеальном варианте - отслеживать эффективность и вклад каждого цифрового сотрудника, его стоимость в токенах, влияние на результат и т.п.