archgate

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

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

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

Шаг 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: B7.3.1-l2-data-classification-map.md. Если затрагивается чувствительный класс — пройти 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 (тоже ✅/⚠️/❌, без числовой шкалы):

Чеклисты: DP.ARCH.001 §4.8–4.14. Формат:

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

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

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

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

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

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

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

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

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

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