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

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

When to use

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

Algorithm

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

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

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: C.IT-Platform/C2.IT-Platform/C2.2.Architecture/Data-Governance/B7.3.1-l2-data-classification-map.md в своём 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 .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 .claude/scripts/load-extensions.sh archgate after

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

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

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