Archgate

АрхГейт 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 (тоже ✅/⚠️/❌, без числовой шкалы):

Чеклисты: 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)

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