"Воркфлоу - анализ (идея) В связи с тем, что мой оркестратор чего то шуршит и уже даже что то может делать, и не каждый раз упирается в какую то хрень, начал думать над теми самыми воркфлоу, ради которых я его и делал. Как тестовая штука хочу такую вещь прикрутить: анализ проекта через ИИ. Стадия 1️⃣: структура - берём проект вменяемого размера (чтобы список файлов вмещался в контекстное окно), путь к нему - это входящий параметр воркфлоу - снимаем список файлов, фильтруем кодовые файлы, документацию - обрабатываем каждый кодовый файл: достаем все сущности кода и складываем их в json; достаём внешние сущности - чего импортируем, чего зовём и откуда; - обрабатываем файл документации: выбираем оттуда все сущности кода и складываем в json; - по итогам берём все json и пихаем в sqlite для обработки При извлечении пробуем получить гипотезу о месте сущности по C4 классификации в системе - к какой подсистеме она относится и тп. Гипотеза этапа извлечения остаётся в БД. Итог стадии: неструктурированный массив сущностей кода Стадия 2️⃣: формирование структуры Берём итоги прогона, обрабатываем все необработанные сущности - собираем все упоминания сущности в коде/доке; смотрим на гиптезы к какому уровню в структуре проекта она относится; принимаем решение куда её определяем - по совокупности информации; Итог стадии: имеем структурированную информацию о проекте - со ссылками на источники информации - побочно: видим какие сущности кода упоминаются в документации и где; получаем покрытие документацией кода; - видим какие сущности упоминаются в документации но в коде отсутствуют (косячная документация) - на сдачу можно построить repoWiki по проекту 🟢 Интересно попробовать имея БД сущностей кода (практически граф) - попробовать по разному его структурировать, выделить разные срезы. Хотя это немного сомнительно, но ведь у нас все карты: код, комменты, дока! Стадия 3️⃣: анализ У нас есть библиотека ""аспектов"". Аспект - это отдельное направление анализа кода (безопасность, архитектура, code smells, границы сервисов, контракты, обработка ошибок, стиль кода, ...). Аспект может быть применён к разным скоупам: по C4 уровню - система, домен, контейнер, компонент/юнит. Для каждого аспекта выбираем набор сущностей, которые попадают под анализ по этому аспекту. Формируем набор задачек для анализа каждого аспекта. Анализируем. Агенту рассказываем как доп информацию смотреть - делать запросы в БД сущностей, ходить смотреть исходный код/доку по ссылкам из БД на источники. Набор проведённых анализов по аспекту консолидируем в единый документ по этому аспекту. Такой процесс производим по каждому аспекту. 🟢 Вот такая задумка. Что думаете? Годный план? Кто чего уловил - кому то актуально? или я чего то невнятно пояснил? - хочу погонять анализ через разные модели: что найдёт на одной и той же базе gemini, codex, gpt-5, k2 thinking, sonnet. 🟢 Да, такие воркфлоу я и понимаю под сложными. может для кого то это и не сложно на агентах сделать - но мне кажется на стоковом СС такое вряд ли летает #post @deksden_notes"