v1.0.0 to v1.0.0

---

name: archgate

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

argument-hint: "[описание решения]"

version: 1.0.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 — оценка архитектурного решения

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

## When to use

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

## Algorithm

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

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

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

> **СТОП. Не переходи к шагу 2 без ответа пользователя на ОБА вопроса.**

> Не угадывай за пользователя. Не определяй сам. СПРОСИ и ДОЖДИСЬ ответа.

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

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

| Характеристика | Моя оценка релевантности | Почему |

|----------------|--------------------------|--------|

| Эволюционируемость | высокая/средняя/низкая | [1 предложение] |

| Масштабируемость | высокая/средняя/низкая | [1 предложение] |

| Обучаемость | высокая/средняя/низкая | [1 предложение] |

| Генеративность | высокая/средняя/низкая | [1 предложение] |

| Скорость | высокая/средняя/низкая | [1 предложение] |

| Современность | высокая/средняя/низкая | [1 предложение] |

| Безопасность | высокая/средняя/низкая | [1 предложение] |

Рекомендация: «По моей оценке критичны [X] и [Y]. Согласен, или другие?»

Пометь ответ — ❌ в критических = немедленный СТОП (правило блокировки #1).

**Вопрос 2 (A.19 Lawful Comparison):** «Какие альтернативы рассматривались?»

- Ответ: ≥2 варианта → сравнительная таблица (шаг 2б).

- Ответ: «нет» / «только этот» → продолжай оценку, но отметь в вердикте (шаг 5): *«Оценка без сравнения — уверенность ниже.»*

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

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

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

Шкала:

- ✅ **Достаточно** — характеристика удовлетворена для данного контекста

- ⚠️ **Слабо** — риск присутствует, требует митигации или осознанного принятия

- ❌ **Блокер** — характеристика не выполнена на минимально допустимом уровне

| Характеристика | Вопрос | Статус | Обоснование |

|----------------|--------|--------|-------------|

| **Э**волюционируемость | Что сломается при изменении? Можно ли заменить компонент без каскада? | ✅/⚠️/❌ | [конкретно] |

| **М**асштабируемость | Что будет при 10x нагрузки? Где bottleneck? | ✅/⚠️/❌ | [конкретно] |

| **О**бучаемость | Сколько читать, чтобы начать? Экзоскелет или протез? | ✅/⚠️/❌ | [конкретно] |

| **Г**енеративность | Создаёт платформу? Работает в шаблоне экзокортекса? | ✅/⚠️/❌ | [конкретно] |

| **С**корость | Бот <3 сек, CLI <1 сек? Где latency? | ✅/⚠️/❌ | [конкретно] |

| **С**овременность | Как эту задачу решают лучшие? Что пропущено из SOTA? | ✅/⚠️/❌ | [конкретно] |

| **Б**езопасность | Какие угрозы? PII, секреты, injection surface? Lock-in? Чеклист §Б ниже. | ✅/⚠️/❌ | [конкретно] |

### 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✅) / не сработало.

**Итоговый вердикт:**

- Хотя бы одно правило сработало → **СТОП.**

> «Решение НЕ проходит АрхГейт. Блокирующие условия: [список]. Рекомендация: [что исправить].»

Перейди к шагу 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) |

Ни один триггер не сработал → пропусти L2, перейди к шагу 5.

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

```

Доменные расширения:

Триггер: [компонент] → [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 → переходи к Шагу 5

- ≥1 untrimmable + высокий ущерб → **revision** варианта (откат к Шагу 2 с уточнением)

- ≥1 untrimmable + средний ущерб → ⚠️-флаг в Шаге 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` | ✅/⚠️/❌ |

**Правила:**

- ≥1 ❌ → решение не готово к финальному вердикту; вернуться к шагу 2 с детализацией операционализации.

- ≥3 ⚠️ → финальный вердикт возможен, но с обязательным ⚠️-флагом и explicit acknowledgement.

- Иначе → DRR Adequacy Pass пройден.

**Запись:** если решение принято, оформи DRR по шаблону `.claude/templates/drr-template.md`.

## Шаг 5. Обратная связь

**Если проходит:**

> «Решение проходит АрхГейт.»

Для каждой ⚠️ (L1) — запроси явное решение:

> «[Характеристика] ⚠️. Выбери: (а) принимаю риск — [обоснование]; (б) митигация — [что конкретно].»

Для каждой ⚠️/❌ (L1) → обратная связь по принципам:

- Посмотреть DP.ARCH.001 §7.1 (покрытие принципами)

- Принцип есть, решение противоречит → пересмотреть

- Принцип есть, слабый → усилить

- Принципа нет → предложить (уровень: 2-й = домен, 3-й = ADR)

<!-- USER-SPACE -->

<!-- /USER-SPACE -->