Archgate

---
name: archgate
description: Оценка архитектурного решения по 7 характеристикам ЭМОГССБ (v3.1 — фильтр допуска, атрибут-сценарии, совет затронутых сторон; профиль без агрегатного балла, conjunctive screening). Используй когда пользователь предлагает архитектурное решение, новый инструмент или системное изменение.
argument-hint: "[описание решения]"
version: 1.1.0
layer: L1
status: active
triggers:
  slash: [/archgate]
  phrases: []
routing:
  executor: opus
  deterministic: false
agents: single
interaction: multi-step
gates_required: []
gates_enforced: []
gates_rationale: "операционный скилл; WP Gate применим только при создании нового РП, не для операционных вызовов"
---

# АрхГейт v3.1 — оценка архитектурного решения

Выполни оценку решения: $ARGUMENTS

## When to use

Оценка архитектурного решения по 7 характеристикам ЭМОГССБ (v3.1 — фильтр допуска, атрибут-сценарии, совет затронутых сторон; профиль без агрегатного балла, conjunctive screening). Используй когда пользователь предлагает архитектурное решение, новый инструмент или системное изменение.

## Algorithm

## Extensions `before` (БЛОКИРУЮЩЕЕ)

До Шага 0-А ровно один раз за верхнеуровневый вызов загрузить расширения (фаза `before` обязательна и для быстрого трека — фильтр допуска выполняется только после неё):

```bash
bash .claude/scripts/load-extensions.sh archgate before
```

Код `0` → прочитать каждый путь из вывода в алфавитном порядке и выполнить.
Код `1` → расширений нет, продолжить. Любой другой код, ошибка расширения,
явный `BLOCK`/`STOP` или содержательное возражение рецензента внутри расширения
блокирует начало оценки: показать путь файла и наблюдаемую причину.

Каждое `before`/`checks`-расширение завершает инструкции явным маркером
`ARCHGATE_EXTENSION: PASS` либо `ARCHGATE_EXTENSION: BLOCK — <причина>`.
Отсутствующий или неизвестный маркер = ошибка блокирующей фазы, не PASS.

**Защита от рекурсии:** каждая фаза `before`, `checks`, `after` выполняется не
более одного раза за верхнеуровневый вызов. Расширению запрещено вызывать
`/archgate`, повторно загружать `archgate.*` или иначе повторно входить в этот
жизненный цикл. Попытка рекурсии считается ошибкой текущей фазы: блокирует
`before`/`checks`, а в `after` даёт предупреждение и пропускается.

Расширения — доверенные локальные инструкции, а текстовый детектор — защита от
прямой случайной рекурсии, не песочница для враждебного shell-кода. Не исполнять
собранную через `eval`, декодирование, подстановку переменных или конкатенацию
команду/инструкцию из расширения: неоднозначную косвенную команду считать той же
ошибкой рекурсии (BLOCK в `before`/`checks`, WARN и пропуск в `after`).

## Шаг 0-А. Фильтр допуска (admission)

> Критерий «архитектурности» — стоимость изменения (Левенчук/ailev; Фаулер: архитектура — то, что трудно поменять). Полный гейт — для дорогих решений; дешёвые обратимые решения идут быстрым треком (WP-548 Ф1: сверка с мировой практикой).

Оцени решение по 3 осям. Ось «высокая», если:

| Ось | Высокая, если |
|-----|---------------|
| **Стоимость изменения** (cost-to-change) | правка затрагивает ≥3 единиц самостоятельной доставки (репозиторий, деплоящийся сервис, платформенный скилл/скрипт), ИЛИ меняет контракт данных/API, ИЛИ защищённые файлы платформы (перечень — `docs/critical-files-map.yaml`) |
| **Окно отката** (reversibility window) | откат требует миграции данных или внешних уведомлений, ИЛИ превышает 1 календарный день работы одного человека |
| **Внешние обязательства** (external commitments) | затрагивает обещания пользователям (SC), SLA, безопасность/PII, платежи, регуляторику |

- Любая ось высокая ИЛИ есть сомнение → полный гейт (Шаг 0 и далее). Сомнение всегда трактуется в сторону полного гейта (override-клапан, осознанно не формализован — ошибается только в безопасную сторону).
- Все три оси низкие → `core_result = fast_tracked`: Шаги 0–4.6 пропускаются, но маршрут НЕ обходит контракт публикации — обязательный проход через Extensions `checks` (Шаг 4.7) и публикацию в Шаге 5. Payload Шага 5 для fast-track: мини-DRR по секции «Fast-track» шаблона `.claude/templates/drr-template.md` (фикс-поля: дата, решение, по одной строке на каждую ось «почему низкая», владелец решения) — хранится там же, где полные DRR.
- Фильтр — часть жизненного цикла гейта: на него распространяется защита от рекурсии (расширению запрещено вызывать Шаг 0-А или core-пайплайн повторно).

## Шаг 0. Принципы (ДО оценки)

Сверь решение с принципами 2-го уровня (DP.ARCH.001 §7). Если решение нарушает принцип — сообщи и предложи исправление до подачи на оценку.

## Шаг 1. Три вопроса пользователю (БЛОКИРУЮЩЕЕ)

> **СТОП. Не переходи к шагу 2 без ответа пользователя на ВСЕ ТРИ вопроса.**
> Не угадывай за пользователя. Не определяй сам. СПРОСИ и ДОЖДИСЬ ответа.

**Вопрос 1:** «Какие 1–2 характеристики критичны для этого решения?»

Приведи список ВСЕХ 7 характеристик с предварительной оценкой релевантности для данного решения:

| Характеристика | Моя оценка релевантности | Почему |
|----------------|--------------------------|--------|
| Эволюционируемость | высокая/средняя/низкая | [1 предложение] |
| Масштабируемость | высокая/средняя/низкая | [1 предложение] |
| Обучаемость | высокая/средняя/низкая | [1 предложение] |
| Генеративность | высокая/средняя/низкая | [1 предложение] |
| Скорость | высокая/средняя/низкая | [1 предложение] |
| Современность | высокая/средняя/низкая | [1 предложение] |
| Безопасность | высокая/средняя/низкая | [1 предложение] |

Рекомендация: «По моей оценке критичны [X] и [Y]. Согласен, или другие?»
Пометь ответ: ❌ в критических фиксирует `core_result = rejected` по правилу
блокировки #1. Останови дальнейшую оценку ядра, но не завершай скилл: обязательный
маршрут через Extensions `checks` в Шаге 4.7 сохраняется.

**Вопрос 2 (A.19 Lawful Comparison):** «Какие альтернативы рассматривались?»
- Ответ: ≥2 варианта → сравнительная таблица (шаг 2б).
- Ответ: «нет» / «только этот» → продолжай оценку, но отметь в вердикте (шаг 5): *«Оценка без сравнения — уверенность ниже.»*

**Вопрос 3 (Advice Process — Harmel-Law «Facilitating Software Architecture»; ISO 42010 stakeholders):** «Кого затрагивает решение и чей совет собрать до вердикта?»
- Перечисли затронутые стороны (пользователи шаблона, соседние агенты/сессии, внешние сервисы, будущие сопровождающие) и экспертов по теме.
- Для системных решений дефолт — второе мнение напарника (peer-сессия; подключается расширением `archgate.checks`).
- Собранный совет фиксируется в DRR, секция «Совет затронутых сторон»: кого спросили → какой совет дали → что принято/отвергнуто и почему. Ответ «никого не затрагивает» допустим — с обоснованием, оно тоже идёт в DRR.

**Задай все три вопроса одним сообщением. Дождись ответа. Только потом — шаг 2.**

## Шаг 2. Профиль ЭМОГССБ

Оцени решение по 7 характеристикам. **Без агрегатного балла — только профиль.**

Шкала:
- ✅ **Достаточно** — характеристика удовлетворена для данного контекста
- ⚠️ **Слабо** — риск присутствует, требует митигации или осознанного принятия
- ❌ **Блокер** — характеристика не выполнена на минимально допустимом уровне

| Характеристика | Вопрос | Статус | Обоснование |
|----------------|--------|--------|-------------|
| **Э**волюционируемость | Что сломается при изменении? Можно ли заменить компонент без каскада? | ✅/⚠️/❌ | [конкретно] |
| **М**асштабируемость | Что будет при 10x нагрузки? Где bottleneck? | ✅/⚠️/❌ | [конкретно] |
| **О**бучаемость | Сколько читать, чтобы начать? Экзоскелет или протез? | ✅/⚠️/❌ | [конкретно] |
| **Г**енеративность | Создаёт платформу? Работает в шаблоне экзокортекса? | ✅/⚠️/❌ | [конкретно] |
| **С**корость | Бот <3 сек, CLI <1 сек? Где latency? | ✅/⚠️/❌ | [конкретно] |
| **С**овременность | Как эту задачу решают лучшие? Что пропущено из SOTA? | ✅/⚠️/❌ | [конкретно] |
| **Б**езопасность | Какие угрозы? PII, секреты, injection surface? Lock-in? Чеклист §Б ниже. | ✅/⚠️/❌ | [конкретно] |

### 2а. Атрибут-сценарии критичных характеристик (обязательно)

> ATAM (SEI): оцениваются атрибут-сценарии, не абстрактные качества. «Абстрактно зелёное» запрещено.

Для каждой характеристики, названной критичной в Шаге 1, — минимум один конкретный сценарий: **стимул → среда → ожидаемая реакция**, плюс деловая значимость (business importance — почему этот сценарий важен для дела). Критичная характеристика без сценария не может получить ✅ — максимум ⚠️ с пометкой «оценка без сценария».

### 2б. Сравнительный режим (несколько вариантов)

Если передано ≥2 вариантов — строй сводную таблицу:

| Характеристика | Вариант A | Вариант B | ... |
|----------------|-----------|-----------|-----|
| Эволюционируемость | ✅/⚠️/❌ | ✅/⚠️/❌ | |
| Масштабируемость | ✅/⚠️/❌ | ✅/⚠️/❌ | |
| Обучаемость | ✅/⚠️/❌ | ✅/⚠️/❌ | |
| Генеративность | ✅/⚠️/❌ | ✅/⚠️/❌ | |
| Скорость | ✅/⚠️/❌ | ✅/⚠️/❌ | |
| Современность | ✅/⚠️/❌ | ✅/⚠️/❌ | |
| Безопасность | ✅/⚠️/❌ | ✅/⚠️/❌ | |
| **Предварительный результат ядра** | ГОТОВ/ЗАБЛОКИРОВАН | ГОТОВ/ЗАБЛОКИРОВАН | |

Рекомендуемый вариант: наименьшее число ⚠️ при отсутствии ❌ в критических характеристиках.

### Coordination cost check (мультиагентные/мультисистемные решения)

Три условия для multi-agent: (1) context isolation, (2) parallelism gain, (3) tool specialization.
Все три НЕ выполнены → single-agent.

### Чеклист безопасности (§Б) — WP-212 B7.1

Применяй при оценке характеристики **Безопасность**. Отвечай на каждый пункт кратко.

**Auth & Access:**
- Требует ли компонент аутентификации? JWT верифицируется локально (JWKS), не через доверие заголовкам? (ADR-IWE-012)
- Есть ли авторизация (subscription check / RBAC)? Нет — ⚠️.
- Могут ли аргументы инструмента подменить identity пользователя? (например, `user_id` в теле запроса — должен браться из JWT, не из body)

**Secrets:**
- Есть ли новые секреты? Где хранятся (Cloudflare secrets / GHA secrets / `.secrets/`)? Не хардкодятся?
- Обновлён ли B2.1 Secrets Inventory?

**Классификация данных (B7.3.1) — БЛОКИРУЮЩЕЕ для РП с PII / payment_credentials / secrets:**

Source-of-truth: `{{WORKSPACE_DIR}}/DS-ecosystem-development/C.IT-Platform/C2.IT-Platform/C2.2.Architecture/Data-Governance/B7.3.1-l2-data-classification-map.md` (если файл не найден — ищи в своём DS-ecosystem-development-репо). Если затрагивается чувствительный класс — пройти 6 пунктов:

1. **Класс данных?** public / PII / payment_credentials / secrets — определить по тестам §1 B7.3.1. Если только public → §Б пропустить остальное.
2. **Слой?** L1 / L2 / L3 / L4 — проверить таблицу B7.3.1 §2 «где какие классы могут жить». Размещение запрещено таблицей = ❌.
3. **Логирование** соответствует §3.1 B7.3.1? PII только маскированно/тип-без-значения; payment_credentials + secrets запрещены в любом виде. Иначе ❌.
4. **Шифрование at-rest + column-level** соответствует §3.2? Для secrets/payment_credentials column-level Fernet обязателен. Иначе ❌.
5. **RLS-политика** есть для user-level ownership? Если нет — БЛОКЕР до первого insert на prod.
6. **Cross-user агрегация** соблюдает §3.5 (k-anonymity k=10 для группировок, consent для индивидуальных строк)? Экспорт PII во внешнюю систему без DPA = ❌.

**Injection & Input:**
- SQL: параметризованные запросы? Нет whitelist динамических имён? (иначе ⚠️)
- Команды: shell injection возможна?
- MCP tools: аргументы sanitized перед SQL/shell?

**Шифрование:**
- Токены OAuth в БД — шифруются? (B2.5 pending — отмечать как ⚠️ до закрытия)
- HTTPS везде? TLS до БД (Neon — да по умолчанию)?

**Итог §Б:** если ≥2 пунктов ❌ или PII логируется → Безопасность = ❌ (блокер).

### Чеклист современности (§С)

Приоритетная тройка (всегда):
1. **Context Engineering** (DP.SOTA.002): Write/Select/Compress/Isolate — что в контексте агента?
2. **DDD Strategic** (DP.SOTA.001): BC определён? UL консистентен? Context Map есть?
3. **Coupling Model** (DP.SOTA.011): knowledge/distance/volatility coupling оценены?

Полный справочник: `memory/sota-reference.md`.

## Шаг 3. Вето-фильтр (conjunctive screening)

> Принцип: non-compensatory. Высокий статус по одной характеристике НЕ компенсирует блокер по другой.

Проверь каждое правило явно и выведи результат по каждому отдельно:

**Правило 1. Критические характеристики.**
Перечисли характеристики, помеченные как критические в Шаге 1, и их статус из Шага 2.
Пример: «Безопасность (критическая) → ⚠️ — правило не сработало».
→ Вывод: сработало / не сработало.

**Правило 2. Количество блокеров (❌).**
Перечисли все характеристики со статусом ❌ из Шага 2 (с названиями).
Пример: «❌ не найдено» или «❌ Безопасность, ❌ Эволюционируемость — итого 2».
→ Вывод: [N] блокеров — сработало (N≥2) / не сработало (N<2).

**Правило 3. Соотношение ⚠️ и ✅.**
Перечисли все ⚠️ и все ✅ из Шага 2 (с названиями).
Пример: «⚠️ Эволюционируемость, Современность, Безопасность (3 шт.) | ✅ Масштабируемость, Обучаемость, Генеративность, Скорость (4 шт.)».
→ Вывод: сработало (≥4⚠️ и 0✅) / не сработало.

**Предварительный результат ядра (ещё не публиковать как вердикт):**
- Хотя бы одно правило сработало → остановить дальнейшую оценку ядра.
  Зафиксируй `core_result = rejected` и блокирующие условия. Шаги 4–4.6 для
  отклонённого решения не выполняются (`DRR = N/A`); перейди в общую точку
  Extensions `checks` (Шаг 4.7). Не обходи `checks` прямым переходом к Шагу 5.
- Ни одно не сработало → **Решение проходит вето-фильтр** → шаг 4.

## Шаг 4. Доменные расширения (L2)

> L2 = информативный (не блокирующий до обкатки). Полное описание: DP.M.005 §9.

**4a. Определи триггеры:**

| Триггер | L2-характеристика |
|---------|-------------------|
| Формат хранения user-data, схема данных, зависимость от вендора/API | **Переносимость данных** (L2.1) |
| ИИ-система (Зона А), Intervention Loop, недетерминированный компонент | **Наблюдаемость** (L2.2) |
| ИИ-оценка пользователя (квалификация, прогресс, рекомендация, обратная связь) | **Объяснимость** (L2.3) |
| Оценка/измерение (ЦД, метрики, stage, score) | **Воспроизводимость** (L2.4) |
| Автоматическое действие от имени пользователя | **Контролируемость** (L2.5) |
| Миграция данных, хранилище, схема ЦД | **Сохранность знаний** (L2.6) |
| Внешняя интеграция, протокол обмена, MCP Registry | **Интероперабельность** (L2.7) |
| Новый автоматический процесс (агент, конвейер, скрипт с LLM-вызовом) или изменение частоты/объёма уже существующих вызовов | **Экономичность** (L2.8) |

Ни один триггер не сработал → пропусти только оценку L2 и продолжай с Шага 4.5.

**4b. Оцени сработавшие L2 (тоже ✅/⚠️/❌, без числовой шкалы):**

Чеклисты: DP.ARCH.001 §4.8–4.15 (Экономичность — §4.15: три вопроса — reflex-first вместо LLM там, где логика формализуема; модель по размеру задачи, не с запасом; виден ли расход до того, как стал проблемой). Формат:

```
Доменные расширения:
  Триггер: [компонент] → [L2-характеристика]

| [Характеристика] | Статус   | Обоснование |
|------------------|----------|-------------|
| Вопрос 1         | ✅/⚠️/❌ | ...         |
| Вопрос 2         | ✅/⚠️/❌ | ...         |
| Вопрос 3         | ✅/⚠️/❌ | ...         |
| **L2.N итог**    | ✅/⚠️/❌ | Информативно |
```

Вердикт L2: ✅ (нет ❌), ⚠️ (1–2 ❌), ❌ (≥3 ❌) — рекомендация, но не блокирует.

## Шаг 4.5. NBR — Negative Branch Reservation

> Источник: TOC Thinking Processes (Goldratt / Dettmer); Schragenheim S&T tree «monitoring entries». Дёшево, мощно, предотвращает foreseeable damage.

После того как решение прошло вето-фильтр (Шаг 3) и L2 (Шаг 4), но **до** финальной обратной связи — построй 3 negative branches:

«Если внедрить выбранное решение, **что плохого может случиться** в течение 1–4 недель после? Перечисли 3 наиболее вероятных негативных последствия (по убыванию вероятности или ущерба).»

Для каждой ветки — **trim** (как митигировать или почему ветка untrimmable):

| # | Negative branch | Вероятность | Ущерб | Trim |
|---|-----------------|-------------|-------|------|
| 1 | [что сломается / какой риск проявится] | низкая/средняя/высокая | низкий/средний/высокий | [конкретная митигация] или **untrimmable** |
| 2 | ... | ... | ... | ... |
| 3 | ... | ... | ... | ... |

**Решающее правило:**
- Все 3 ветки trimmable → переходи к Шагу 4.6
- ≥1 untrimmable + высокий ущерб → **revision** варианта (откат к Шагу 2 с уточнением)
- ≥1 untrimmable + средний ущерб → зафиксируй ⚠️-флаг, продолжай с Шага 4.6,
  а при публикации в Шаге 5 затребуй explicit acknowledgement пользователя

**Анти-паттерн:** writing «всё будет хорошо» / «риски минимальны» / общие фразы без конкретики. NBR работает только когда ветки **специфичны** (что именно, какой компонент, какой стейкхолдер).

## Шаг 4.6. DRR Adequacy Pass

> Проверяем, что решение прошло из декларации в операционализируемый контракт.

После NBR, прежде чем выдать финальный вердикт, пройди **DRRAdequacyPass**:

| # | Вопрос | Почему важно | Статус |
|---|--------|--------------|--------|
| 1 | Решение операционализировано: есть чеклист, тест или инвариант, который проверяет его выполнение? | Декларация ≠ работающий механизм | ✅/⚠️/❌ |
| 2 | Детектор/гейт реально блокирует, а не только существует в документе? | Наличие правила не останавливает действие | ✅/⚠️/❌ |
| 3 | Есть forcing function или explicit acknowledgement пользователя? | Подсказка показана ≠ ответ затребован | ✅/⚠️/❌ |
| 4 | Контракт/обещание проверено приёмкой (verify-pass, smoke, canary, acceptance report)? | Обещание дано ≠ исполнение измерено | ✅/⚠️/❌ |
| 5 | Запись решения ведётся в одном месте (OwnerIntegrity)? | Один факт — одно место | ✅/⚠️/❌ |
| 6 | Указан срок/условие пересмотра решения? | Решение устаревает без `review_date` / `superseded_by` | ✅/⚠️/❌ |
| 7 | Какой автоматический контроль (fitness-check) охраняет критичную характеристику после внедрения? | Разовая оценка ≠ охрана: деградацию должен ловить механизм, не память (принцип #27 Intervention Loop; fitness functions — Ford/Parsons) | ✅/⚠️/❌ |

**Правила:**
- ≥1 ❌ → решение не готово к финальному вердикту; вернуться к шагу 2 с детализацией операционализации.
- ≥3 ⚠️ → финальный вердикт возможен, но с обязательным ⚠️-флагом и explicit acknowledgement.
- Иначе → DRR Adequacy Pass пройден.

**Черновик DRR:** подготовь данные по шаблону `.claude/templates/drr-template.md`,
но до успешных `checks`, обязательных подтверждений и финального вердикта не
записывай решение как принятое.

## Шаг 4.7. Extensions `checks` (БЛОКИРУЮЩЕЕ)

После DRR (либо `DRR = N/A` для отклонённого ядром решения, либо
`core_result = fast_tracked` из Шага 0-А), но до публикации
вердикта ровно один раз загрузить проверки:

```bash
bash .claude/scripts/load-extensions.sh archgate checks
```

Код `0` → прочитать и выполнить каждый файл в алфавитном порядке. Код `1` →
проверок нет. Ошибка loader/исполнения или попытка рекурсии блокирует публикацию:
вернуть `extension_check_error`, путь и наблюдаемую причину. Явный `BLOCK`/`STOP`
или содержательное возражение рецензента блокирует публикацию с типом
`extension_check_blocked`, путём и причиной. После такого исхода Шаг 5 запрещён;
исправление проверяется новым верхнеуровневым вызовом, где каждая lifecycle-фаза
снова выполняется ровно один раз.

Маркер `ARCHGATE_EXTENSION: BLOCK` всегда даёт `extension_check_blocked`;
`ARCHGATE_EXTENSION: PASS` разрешает переход только после успеха всех файлов.

## Шаг 5. Публикация вердикта и обратная связь

Это единственная точка, где результат называется и показывается пользователю
как вердикт.

Если `core_result = rejected`, обязательные подтверждения рисков не запрашивай:
после успешных `checks` сразу опубликуй отрицательный вердикт. Уже блокирующее
решение нельзя задерживать в `pending_ack` просьбой «принять риск».

Если `core_result = fast_tracked` (Шаг 0-А), после успешных `checks` опубликуй
облегчённый вердикт: «Решение прошло быстрым треком (все оси допуска низкие)» +
мини-DRR (секция «Fast-track» шаблона). Обязательных подтверждений рисков нет —
рисковых флагов быстрый трек не создаёт; фаза `after` выполняется как обычно.

Только если ядро прошло, **сначала собери обязательные подтверждения.** Для
каждой ⚠️ (L1), а также для флагов NBR/DRR, требующих acknowledgement, запроси
явное решение:
> «[Характеристика] ⚠️. Выбери: (а) принимаю риск — [обоснование]; (б) митигация — [что конкретно].»

Пока обязательный ответ не получен, состояние = `pending_ack`; это не вердикт,
DRR не финализируется, фаза `after` не запускается. Если выбрана митигация,
изменённое решение проходит новый верхнеуровневый вызов АрхГейта с начала жизненного цикла (Extensions `before`, Шаг 0-А).

**После всех обязательных подтверждений опубликуй ровно один вердикт:**

- Если `core_result = fast_tracked`: облегчённый вердикт быстрого трека (абзац выше).
- Если `core_result = rejected`:
  > «Решение НЕ проходит АрхГейт. Блокирующие условия: [список]. Рекомендация: [что исправить].»
- Если ядро прошло и обязательные риски приняты или устранены:
  > «Решение проходит АрхГейт.»

Только если опубликован проходящий вердикт, финализируй DRR как принятое решение
по шаблону `.claude/templates/drr-template.md`. При `core_result = rejected` не
записывай решение как принятое; черновик остаётся нефинализированным до новой
успешной оценки.

Для каждой ⚠️/❌ (L1) → обратная связь по принципам:
- Посмотреть DP.ARCH.001 §7.1 (покрытие принципами)
- Принцип есть, решение противоречит → пересмотреть
- Принцип есть, слабый → усилить
- Принципа нет → предложить (уровень: 2-й = домен, 3-й = ADR)

## Extensions `after` (НЕ МЕНЯЕТ ВЕРДИКТ)

После публикации вердикта (и, для проходящей ветки, получения всех обязательных
explicit acknowledgement из Шага 5) ровно один раз загрузить расширения:

```bash
bash .claude/scripts/load-extensions.sh archgate after
```

Код `0` → прочитать файлы в алфавитном порядке и выполнить каждый, продолжая со
следующим даже после ошибки предыдущего. Код `1` → расширений нет. При любом
другом коде всё равно выполнить каждый корректный путь, который loader успел
вывести в stdout, а каждую диагностику stderr показать отдельным предупреждением
с путём и причиной. Повреждённый файл и попытку рекурсии не выполнять. Фаза
`after` не может переписать, отозвать или понизить уже опубликованный вердикт.

Для диагностического исхода `after` может использовать
`ARCHGATE_EXTENSION: WARN — <причина>`; `BLOCK` после вердикта также трактуется
только как предупреждение.

<!-- USER-SPACE -->
<!-- /USER-SPACE -->