| 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 пунктов:
- Класс данных? public / PII / payment_credentials / secrets — определить по тестам §1 B7.3.1. Если только public → §Б пропустить остальное.
- Слой? L1 / L2 / L3 / L4 — проверить таблицу B7.3.1 §2 «где какие классы могут жить». Размещение запрещено таблицей = ❌.
- Логирование соответствует §3.1 B7.3.1? PII только маскированно/тип-без-значения; payment_credentials + secrets запрещены в любом виде. Иначе ❌.
- Шифрование at-rest + column-level соответствует §3.2? Для secrets/payment_credentials column-level Fernet обязателен. Иначе ❌.
- RLS-политика есть для user-level ownership? Если нет — БЛОКЕР до первого insert на prod.
- 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 логируется → Безопасность = ❌ (блокер).
Чеклист современности (§С)
Приоритетная тройка (всегда):
- Context Engineering (DP.SOTA.002): Write/Select/Compress/Isolate — что в контексте агента?
- DDD Strategic (DP.SOTA.001): BC определён? UL консистентен? Context Map есть?
- Coupling Model (DP.SOTA.011): knowledge/distance/volatility coupling оценены?
- FPF июльская дельта (WP-481 Ф5): A.22.CGUS — не путаем декларативную структуру ограничений с линейным порядком исполнения (гейт ≠ порядок мантры, различение в distinctions); E.11.PUA — для разговорного масштаба не тащить сквозную формализацию (проверить релевантность: решение про диалог с пользователем или про машинный конвейер?)
Полный справочник: 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 (тоже ✅/⚠️/❌, без числовой шкалы):
Чеклисты: DP.ARCH.001 §4.8–4.14. Формат:
Доменные расширения:
Триггер: [компонент] → [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)
