Operational Audit

Operational Audit

Зачем этот аудит существует

Конвейер итераций (aidd-orchestrator) — машина «дифф соответствует брифу и нормам»: каждая его роль входит в работу через дифф итерации, план или бриф. Свойства работающей системы — что переживёт рестарт процесса, второй uvicorn-воркер, обрыв соединения к зависимости, рост нагрузки — не являются свойствами диффа, поэтому структурно невидимы ни одной роли. Харвестер дополнительно отсеивает находки «без подтверждённого симптома», а риск класса «не переживёт вторую реплику» в single-worker деплое симптома не имеет по определению. Этот скилл — компенсирующий слой: периодический взгляд на систему целиком. Запускается архитектором вручную, ролью оркестратора не является.

Метод

Прогон состоит из трёх фаз; фазу верификации не пропускай никогда.

1. Свип. Разведи независимые направления по read-only сабагентам (fan-out) — каждому одна

ось и мандат читать код системы целиком, а не диффы. Точки входа: doc/tech/backend.md, agent-runtime.md, streaming.md, backend/app/main.py (lifespan), entrypoint.sh, docker-compose.yml, doc/tech/adr/.

1. Верификация. Каждую находку свипа проверь чтением реального кода — отдельным агентом

или сам: точные файлы и строки, воспроизводимость механизма, актуальность. Находка без верификации в отчёт не выходит. Правило родилось из практики: у непроверенных ревью этого класса около половины находок ложные — проблема уже починена, описан нормальный паттерн библиотеки, компонент выдуман.

1. Сверка с известным. Прогони подтверждённые находки через doc/backlog.md, тасклисты и

ADR: известное не дублируй — предлагай уточнение существующей записи; для осознанных решений ответь, держится ли ещё их обоснование.

Оси проверки

Список — примеры, не граница: смотри и на то, чего здесь нет, если оно относится к вопросу «как система ведёт себя в эксплуатации».

• Топология процессов и process-local состояние — что живёт в памяти процесса

(app.state, словари инстансов) и что произойдёт при втором воркере или реплике. Помни: конвенция «состояние в app.state» решает тестируемость, не multi-worker — соответствие конвенции не означает отсутствия проблемы.

• Lifecycle ресурсов — что собирается в lifespan; поведение при блипе каждой зависимости

(Postgres, Redis, LLM-провайдер, MCP): есть ли reconnect, деградация, самолечение.

• Shutdown — путь SIGTERM: что дренируется, что обрывается, хватает ли grace period

активным операциям (длинные агентные раны, стримы).

• Конкурентность под ростом — глобальные локи, сериализация на одном соединении, размеры

пулов, блокирующие вызовы в event loop.

• Таймауты внешних вызовов — «висящий вечно» дефолт считается багом

(conventions.md § таймауты).

• Предпосылки ADR — пройди условные обязательства («отложено до реальной нагрузки», «если

X станет узким местом») и ответь, не наступил ли триггер пересмотра.

Выход

Отчёт архитектору: по каждой находке — вердикт (подтверждена/опровергнута), механизм с путями file:line, серьёзность в текущей эксплуатации и известность проекту (новое / уточняет существующую запись / предпосылка конкретного ADR). К подтверждённым — готовые кандидаты-записи в стиле doc/backlog.md (приоритет, триггер активации, scope-теги). Сам ничего не пиши в doc/ и код — решение и фиксация за архитектором.

Каденция

Ориентир — раз в 3–4 итерации или перед сменой фазы roadmap; внепланово — после крупных изменений рантайма (стрим-ядро, lifespan, деплой-контур).

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Bbar0n234
• Source: Bbar0n234/learnflow-ai
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.