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/.
2. Верификация. Каждую находку свипа проверь чтением реального кода — отдельным агентом или сам: точные файлы и строки, воспроизводимость механизма, актуальность. Находка без верификации в отчёт не выходит. Правило родилось из практики: у непроверенных ревью этого класса около половины находок ложные — проблема уже починена, описан нормальный паттерн библиотеки, компонент выдуман.
3. Сверка с известным. Прогони подтверждённые находки через 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, деплой-контур).