Archgate

АрхГейт 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 осям. Ось «высокая», если:

• Любая ось высокая ИЛИ есть сомнение → полный гейт (Шаг 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 характеристик с предварительной оценкой релевантности для данного решения:

Рекомендация: «По моей оценке критичны [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 характеристикам. Без агрегатного балла — только профиль.

Шкала:

• ✅ Достаточно — характеристика удовлетворена для данного контекста
• ⚠️ Слабо — риск присутствует, требует митигации или осознанного принятия
• ❌ Блокер — характеристика не выполнена на минимально допустимом уровне

2а. Атрибут-сценарии критичных характеристик (обязательно)

ATAM (SEI): оцениваются атрибут-сценарии, не абстрактные качества. «Абстрактно зелёное» запрещено.

Для каждой характеристики, названной критичной в Шаге 1, — минимум один конкретный сценарий: стимул → среда → ожидаемая реакция, плюс деловая значимость (business importance — почему этот сценарий важен для дела). Критичная характеристика без сценария не может получить ✅ — максимум ⚠️ с пометкой «оценка без сценария».

2б. Сравнительный режим (несколько вариантов)

Если передано ≥2 вариантов — строй сводную таблицу:

Рекомендуемый вариант: наименьшее число ⚠️ при отсутствии ❌ в критических характеристиках.

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

Предварительный результат ядра (ещё не публиковать как вердикт):

• Хотя бы одно правило сработало → остановить дальнейшую оценку ядра. Зафиксируй 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 и продолжай с Шага 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):

Решающее правило:

• Все 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 ⚠️ → финальный вердикт возможен, но с обязательным ⚠️-флагом и 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 после вердикта также трактуется только как предупреждение.