Воркфлоу - анализ

(идея)

В связи с тем, что мой оркестратор чего то шуршит и уже даже что то может делать, и не каждый раз упирается в какую то хрень, начал думать над теми самыми воркфлоу, ради которых я его и делал.

Как тестовая штука хочу такую вещь прикрутить: анализ проекта через ИИ.

Стадия 1️⃣: структура

- берём проект вменяемого размера (чтобы список файлов вмещался в контекстное окно), путь к нему - это входящий параметр воркфлоу
- снимаем список файлов, фильтруем кодовые файлы, документацию
- обрабатываем каждый кодовый файл: достаем все сущности кода и складываем их в json; достаём внешние сущности - чего импортируем, чего зовём и откуда;
- обрабатываем файл документации: выбираем оттуда все сущности кода и складываем в json;
- по итогам берём все json и пихаем в sqlite для обработки

При извлечении пробуем получить гипотезу о месте сущности по C4 классификации в системе - к какой подсистеме она относится и тп. Гипотеза этапа извлечения остаётся в БД.

Итог стадии: неструктурированный массив сущностей кода

Стадия 2️⃣: формирование структуры

Берём итоги прогона, обрабатываем все необработанные сущности

- собираем все упоминания сущности в коде/доке; смотрим на гиптезы к какому уровню в структуре проекта она относится; принимаем решение куда её определяем - по совокупности информации;

Итог стадии: имеем структурированную информацию о проекте - со ссылками на источники информации

- побочно: видим какие сущности кода упоминаются в документации и где; получаем покрытие документацией кода;
- видим какие сущности упоминаются в документации но в коде отсутствуют (косячная документация)

- на сдачу можно построить repoWiki по проекту

🟢 Интересно попробовать имея БД сущностей кода (практически граф) - попробовать по разному его структурировать, выделить разные срезы. Хотя это немного сомнительно, но ведь у нас все карты: код, комменты, дока!

Стадия 3️⃣: анализ

У нас есть библиотека "аспектов". Аспект - это отдельное направление анализа кода (безопасность, архитектура, code smells, границы сервисов, контракты, обработка ошибок, стиль кода, ...). Аспект может быть применён к разным скоупам: по C4 уровню - система, домен, контейнер, компонент/юнит.

Для каждого аспекта выбираем набор сущностей, которые попадают под анализ по этому аспекту. Формируем набор задачек для анализа каждого аспекта. Анализируем. Агенту рассказываем как доп информацию смотреть - делать запросы в БД сущностей, ходить смотреть исходный код/доку по ссылкам из БД на источники.

Набор проведённых анализов по аспекту консолидируем в единый документ по этому аспекту.

Такой процесс производим по каждому аспекту.


🟢 Вот такая задумка. Что думаете? Годный план? Кто чего уловил - кому то актуально? или я чего то невнятно пояснил?

- хочу погонять анализ через разные модели: что найдёт на одной и той же базе gemini, codex, gpt-5, k2 thinking, sonnet.

🟢 Да, такие воркфлоу я и понимаю под сложными. может для кого то это и не сложно на агентах сделать - но мне кажется на стоковом СС такое вряд ли летает


#post
@deksden_notes