Failure modes — где RENAR ломается и как восстанавливаться
Систематический обзор всех известных способов, которыми RENAR-проект может выйти из строя: технический дрейф между артефактами и реализацией, AI-специфичные риски, и (главное) организационные паттерны, при которых процесс существует на бумаге, но не работает. Для каждого failure mode — симптом, как обнаружить, как предотвратить, как восстановиться.
Источник: research/00-architecture-vision.md §7 + research/10-ai-risk-register.md + opservations from real implementations. Предпосылки: RENAR Core, reference/03-ai-risk-register.md.
1. Карта failure modes
Три класса проблем:
| Класс | Где живёт | Как обнаруживается |
|---|---|---|
| Drift | Несоответствие между разными представлениями одной сущности (frontmatter ↔ DB, требование ↔ код, TC ↔ требование) | Capability V6 (drift detection) + reconciliation hook |
| AI risks | Свойства AI-генерации (hallucination, bias, injection, model drift) | Adversarial review + eval-тесты + AI risk register (reference/03) |
| Organizational | Несоответствие между формальным процессом и реальными практиками команды | Поведенческие сигналы: pattern of approval, rate of dispute, frequency of bypass |
Drift и AI risks ловятся substrate-механизмами. Organizational — никаким substrate не ловятся; нужны human-уровневые ревью процесса. Эта глава покрывает все три.
2. 8 классов дрифта
Для каждого: симптом (как выглядит со стороны), detection (как обнаружить автоматически), prevention (как не допустить), recovery (что делать если уже случилось).
2.1 Schema drift
Симптом: Поля во frontmatter артефакта расходятся с теми, что substrate ожидает / поддерживает.
Detection: На каждое изменение артефакта substrate валидирует frontmatter по schema (reference/02-schemas.md). При расхождении — блок integration (QG-0 фейлит).
Prevention: Schema — single source of truth (closed list), не редактируется на проекте. Изменения schema — только через изменение полного RENAR Standard.
Recovery: Откатить frontmatter к schema-valid состоянию; если изменение нужно — открыть RFC на изменение стандарта.
2.2 Lifecycle drift
Симптом: Статусы (proposed / approved / verified / obsolete) и Quality Gates имеют разный смысл в разных subsystems / у разных команд.
Detection: Сравнить переходы статусов в audit log с нормативной state machine (standard/10-lifecycle-qg). Аномалии (переход без соответствующих pre-conditions) — флаг.
Prevention: Переходы выполняются substrate-механизмом, не ручной правкой frontmatter. Capability V3 (state machine enforcement).
Recovery: Откатить нелегитимный переход; провести QG-0 / QG-2 заново через корректный механизм.
2.3 Source-of-truth drift
Симптом: Одна и та же сущность редактируется в двух местах (например, и в .req директории, и в Jira-трекере). Версии расходятся.
Detection: Periodic reconciliation между substrate и tracker; diff показывает расхождения.
Prevention: В каждый момент времени для проекта выбран ровно один SSoT-substrate. Tracker — derived view, не источник истины. Substrate hook блокирует tracker-only изменения требований.
Recovery: Объявить один substrate winner; смерджить второй в первый; убрать редактирование во второй до миграции.
2.4 Implementation drift
Симптом: Код в реализации ссылается на SR, которого больше нет (deprecated, удалён, переименован). Или: SR существует, но реализация ушла от него (поведение не соответствует).
Detection: Capability V6 (drift detection):
- Forward: пройти по requirement → найти реализующий код → запустить TC.
- Backward: пройти по коду → найти ссылки на SR / TC → проверить, что они существуют и
verified.
Prevention: ID требований immutable — переименование запрещено. Deprecated требования остаются в репозитории со статусом obsolete, не удаляются.
Recovery: Открыть delta-ТЗ, который явно adopts текущую реализацию (или, наоборот, требует rollback кода до соответствия требованию).
2.5 Terminological drift
Симптом: «Verified», «implemented», «approved» означают разное у разных людей / команд.
Detection: Code review checklist: «использован термин не из глоссария?» — флаг. Аналогично — substrate validator проверяет, что значения enum-полей frontmatter только из closed list.
Prevention: Глоссарий — единственный источник терминов (reference/01-glossary). Каждый термин = ровно одно состояние lifecycle.
Recovery: Провести ревью всех артефактов проекта на использование out-of-glossary терминов; заменить или подать RFC на расширение глоссария.
2.6 Order / provenance drift
Симптом: Delta-ТЗ #2 ссылается на SR, который был создан в Delta-ТЗ #1, но применение пошло в обратном порядке — SR не существовал на момент применения #2.
Detection: Delta-ТЗ нумеруются и применяются строго в порядке номеров. Substrate hook проверяет, что upstream delta уже применена.
Prevention: Delta-ТЗ нельзя перенумеровать. Каждый артефакт хранит created-by-order (delta-ТЗ создания) и last-modified-by-order (последний апдейт).
Recovery: Откатить out-of-order применение; перепримерить в правильном порядке.
2.7 TC ↔ requirement provenance drift
Симптом: TC верифицирует требование, но требование уже изменилось — last-run.requirement-version ниже текущей version требования. Тест зелёный, но проверяет устаревшее поведение.
Detection: Coverage report показывает категорию «Stale» — TC с устаревшей last-run.requirement-version. Capability V6 ловит это автоматически.
Prevention: В TC обязательное поле verifies[].requirement-version — pinned версия. QG-2 запрещает перевод требования в verified, если хотя бы один TC из verified-by имеет stale last-run.
Recovery: Перепрогнать stale TC на текущей версии требования; обновить, если TC сам устарел.
2.8 Test-fitting drift
Симптом: AI-агент имеет тривиальный путь зеленения failing-теста — ослабить Pass/Fail-критерий вместо исправления кода. Без защиты тесты дрейфуют от «строгий проверщик» к «зелёная пустота».
Detection: Изменение Pass/Fail-критериев в TC без явного [test-spec-change] тега — флаг substrate. Periodic spot-check 5 случайных passing TC раз в спринт.
Prevention:
- MR / change, изменяющий Pass/Fail-критерии, обязан иметь тег
[test-spec-change]и отдельный approval инженера (не совмещённый с approval кода-фикса). - Изоляция judge-модели: production-модель ≠ judge-модель.
- Метрика test-fitting drift rate trending.
Recovery: Восстановить старые критерии; провести root cause analysis — почему AI-агент выбрал зеленение вместо фикса; обновить prompt / system instructions.
3. 14 AI-рисков (краткая сводка)
Полные описания, mitigations и owner’ы — в reference/03-ai-risk-register. Здесь — operational summary: id, название, severity, главный detection signal.
| ID | Название | Severity | Detection signal |
|---|---|---|---|
| AIR-01 | Hallucination в AI-генерируемых требованиях | High | Hallucination Rate metric > threshold; adversarial critic flags |
| AIR-02 | Prompt injection через ТЗ от клиента | High | Suspicious pattern в imports; sandbox violation |
| AIR-03 | Model drift / version change | Medium | Diff regression при смене модели; eval baseline failure |
| AIR-04 | Bias в AI-генерации требований | Medium | Stakeholder map gaps; missing accessibility/locale considerations |
| AIR-05 | Single-model failure (no diversity) | Medium | Все артефакты с одним ai-provenance.model; нет multi-model agreement |
| AIR-06 | Test-fitting / зеленение тестов | High | Diff в TC Pass/Fail без [test-spec-change] тега |
| AIR-07 | Hallucinated citations | Medium-High | Citation validator hook fails |
| AIR-08 | Adversarial inputs в client data | High | Application-level (out-of-scope RENAR, tracked в SPEC-SEC) |
| AIR-09 | Privacy leakage через AI logs | High | PII в tool_event audit; redaction скип |
| AIR-10 | Knowledge graph poisoning | Medium | Incorrect edges; circular dependencies в graph |
| AIR-11 | Reconciliation false positive overload | Low-Medium | Findings/week trending up без real issues; dismissal rate высокий |
| AIR-12 | Cost runaway (uncontrolled AI spend) | Medium | Project AI cost approaching budget cap |
| AIR-13 | Stakeholder не понимает AI-сгенерированные требования | Medium | Dispute rate at acceptance растёт; long approval cycles |
| AIR-14 | Vendor lock-in to specific LLM provider | Medium | All prompts работают только на одном provider |
Risk matrix и cadence ревью — reference/03 §4-§5.
4. Organizational failure patterns
Эти проблемы не ловятся substrate-механизмами — это поведенческие паттерны команд. Появляются типично через 2-6 месяцев после внедрения RENAR.
4.1 ADAPT как формальность
Симптом: Клиент / stakeholder не вычитывает ADAPT перед подписанием. Backward-секция (вопросы клиенту) пустая или содержит yes/no без контекста.
Признак: ADAPT approved за < 24 часов после генерации; rate of disputed requirements at acceptance растёт.
Mitigation: Двойная подпись ADAPT (standard/04-roles §4.5) — обязательны и стейкхолдер, и архитектор. Backward-секция обязана содержать ≥ 1 неrhetorical вопрос. Spot-check ADAPT в I&A.
4.2 SPEC overload
Симптом: Команда создаёт SPEC для каждой задачи, даже когда SR + TR достаточно. SPEC-каталог разрастается; каждый PR обновляет 5+ SPEC.
Признак: Rate SPEC / SR > 1.5 (ожидаемое < 0.3 для проектов средней сложности).
Mitigation: Pre-review checklist: «нужен ли SPEC для этого изменения?» SPEC оправдан только когда есть несколько SR с общим constraint. См. standard/08-specifications.md §8.2 — когда SPEC обязателен.
4.3 Hooks как препятствие
Симптом: Команда регулярно обходит substrate hooks (--no-verify, манипуляции с timestamp, ручная правка statuses).
Признак: Git log / substrate audit log показывает frequency of bypass commits; QG-0/QG-2 проходят за подозрительно короткое время.
Mitigation: Root cause — hooks слишком медленные / слишком noisy / слишком жёсткие. Не «запретить bypass», а починить hooks. Метрика bypass rate как trending — если растёт, провести retro с командой.
4.4 Drift detection без действия
Симптом: Capability V6 генерирует drift findings, но никто на них не реагирует. Findings backlog растёт, старые findings игнорируются.
Признак: Findings older than 14 days > 30; resolution rate < 20% / неделю.
Mitigation: Каждый drift finding — owner и SLA (resolve / accept / reject в течение N дней). Unresolved findings выше SLA — escalation. Capability V6 без human ownership = шум.
4.5 Tracker as parallel universe
Симптом: Команда живёт в Jira / Linear / ADO; .req директория обновляется раз в неделю «для галочки». Tracker — реальный источник истины, RENAR — формальный артефакт для аудита.
Признак: Diff .req vs tracker > 30% по any given week; commits в .req редкие и батчевые.
Mitigation: Single source of truth должен быть substrate-resident, не tracker-resident. Tracker — derived view только. Если команда не может работать без tracker — substrate должен пушить в tracker, не наоборот.
4.6 Critic burnout
Симптом: AI-критик (adversarial review) генерирует много findings; постепенно дев / архитектор начинают игнорировать его output. Findings dismissed без рассмотрения.
Признак: Dismissal rate AI-критика > 80%; time-to-dismiss < 30 секунд per finding.
Mitigation: Tunable thresholds для критика. Если ratio false positive высокий — recalibrate prompt / model. Метрика «critic findings → real issue» (% от dismissed findings, которые потом всплыли как defect) — если 0%, критик useless.
4.7 Single-engineer dependence
Симптом: Только один инженер на проекте «понимает RENAR». Все QG-0 / QG-2 проходят через него. Если он в отпуске — процесс встаёт.
Признак: Bus factor RENAR-владения = 1. Distribution of QG approvals heavily skewed к одному человеку.
Mitigation: Парный onboarding (минимум 2 инженера на проекте умеют RENAR). Rotation QG-approver роли. Documentation проектных конвенций в <project>.req/CONVENTIONS.md.
4.8 Ad-hoc delta
Симптом: Изменения требований происходят без оформления delta-ТЗ — «давай просто поменяем SR-12 прямо в репозитории».
Признак: Direct commits в <system>.req/sr/* без соответствующего delta-ТЗ; created-by-order поле пустое.
Mitigation: Substrate hook блокирует mutation существующих требований без delta-ref в commit metadata. Все изменения — через delta-ТЗ workflow (standard/07-adapt §7.6).
4.9 TC abandonment
Симптом: TC создаются вместе с требованиями, но затем не прогоняются. last-run старше N месяцев; coverage report показывает «zelёные» TC, которые в реальности никогда не запускались за полгода.
Признак: Median last-run age > 90 дней; TC count растёт, run count не растёт.
Mitigation: Substrate автоматически прогоняет TC по schedule (capability V4). TC без last-run за N дней автоматически помечаются stale; QG-2 блокирует, пока не перепрогнаны.
5. Failure recovery playbook
Что делать, когда система уже сломана. Последовательность общая для всех failure modes; specifics зависят от класса.
Шаг 1: Stop the bleeding
Найти и остановить ongoing damage:
- Drift: заморозить дальнейшие изменения в затронутой области.
- AI risk: приостановить AI-генерацию для затронутого класса артефактов.
- Organizational: вынести на retro / I&A — это не technical fix.
Шаг 2: Quantify
Измерить ущерб:
- Сколько артефактов в drift-состоянии?
- Сколько релизов с момента возникновения проблемы?
- Какие SR / SPEC / TC затронуты? (Capability V4 — coverage / drift report)
Шаг 3: Triage
Сегментировать ущерб на:
- Critical — уже в production, влияет на пользователей. Hot-fix.
- Active — в текущем PI, влияет на ongoing work. Block PI exit.
- Historical — старые артефакты, не активно используются. Batch fix.
Шаг 4: Fix
Для каждого класса — соответствующий fix:
- Schema drift → rollback frontmatter; RFC если schema нужно расширить.
- Implementation drift → delta-ТЗ adopt OR rollback кода.
- TC drift → repump TC на текущей requirement-version.
- Test-fitting → revert критерии; root cause AI-агента.
- Organizational → process retro + специфичные mitigations (§4).
Шаг 5: Prevent recurrence
- Усилить detection (нижний threshold, новая metric).
- Добавить mitigation в processed артефакт.
- Зафиксировать lessons learned в research/ или as decision в KAI.
Шаг 6: Verify
После fix — пройти QG-2 на затронутых артефактах заново. Drift detection должна показать clean state.
6. Negative: чего эта глава не покрывает
- Security incidents — breach response, forensics, regulatory notification. Это процесс уровня organization security, не RENAR scope.
- AI red team / penetration testing — отдельный security workflow; RENAR трекает только что соответствующие SR / SPEC-SEC должны быть.
- Compliance breach response — нарушение GDPR / ФЗ-152 / PCI-DSS требует юридического процесса с DPO / regulator, не technical recovery.
- Production incidents — outages, performance regressions. Это operational, см. SPEC-OPS runbook.
- Stakeholder conflicts — диспуты на acceptance, scope disagreements. RENAR даёт audit trail (кто что approved когда), но resolution — human process.
7. Connection с другими failure-related артефактами
| Документ | Что в нём | Когда читать |
|---|---|---|
| reference/03-ai-risk-register | Полный реестр 14 AIR-рисков с mitigations | При планировании AI use-case; при review eval-стратегии |
| standard/03-terms §3.11 | Closed list drift классов с нормативными определениями | При спорах о терминологии failure modes |
| 05-safe-comparison §9 | RACI matrix — кто accountable за каждую активность | При расследовании organizational failure |
| reference/04-ai-style-guide | Стиль AI-провенанса; minimal contract для AI-сгенерированных артефактов | При диагностике AIR-01 (hallucination), AIR-07 (citations) |
8. Open questions
- Quantitative thresholds для organizational failure patterns (§4) — какие именно метрики и пороги? Сейчас перечислены качественные «признаки»; нужны конкретные threshold values.
- Recovery playbook (§5) — нужна substrate-specific версия (как именно «заморозить дальнейшие изменения» зависит от substrate)?
- Bus factor measurement (§4.7) — как формально измерять; есть substrate-helper?
- Critic calibration (§4.6) — periodic re-tuning prompt’а критика как формальный процесс или ad-hoc?
См. research/00-architecture-vision.md §7 для исходных формулировок drift классов; research/10-ai-risk-register.md — исходный draft AI risks.