acceptance

Acceptance

Скилл-хореограф и единственный обязательный гейт после реализации. Он исполняет уже существующий контракт верификации и никогда не выдумывает проверки. Контракта нет — шаг 1.5 останавливает прогон и называет вышестоящий скилл, который его производит.

Сильнее всего этот скилл опирается на принцип пирамиды: уровень говорит, что обязано быть доказано, а проект говорит, чем именно. Поэтому каждую команду acceptance выводит из проекта, с которым работает.

Входные данные

Аргументы приходят одной свободной строкой — её надо разобрать, позиционной подстановки не ждать. Всё необязательно: без аргументов гейт прогоняет полную пирамиду для слага, выведенного из ветки. Неизвестный токен — остановиться и сказать, что именно не понято; не угадывать.

По умолчанию гейт только читает. Он прогоняет все уровни, сообщает все находки и ничего не меняет. Правки включаются флагом --fix, потому что незапрошенная правка — это изменение, которого вызывающий не просматривал; а на чужом репозитории гейт, переписывающий рабочий код, чтобы доказать себя, хуже гейта, который просто отчитывается.

Служебный параметр, в подсказке не показывается: --base=<ref> задаёт базу диффа для diff-триггеров и diff_hash. Руками он не нужен — по умолчанию берётся merge-base с дефолтной веткой remote, и этого хватает; параметр существует для вызывающего агента, который уже знает точную границу scope.

Флаг сужает scope, но никогда не меняет вердикт. Каждый исключённый уровень, подавленный ревьюер и пропущенный аудит попадают в расписку в раздел принятых рисков — с аргументом дословно и причиной вызывающего. Исключённый уровень это отслеживаемое исключение, а не молчаливый проход. Если флаг исключает уровень, обязательный для данного типа задачи (L5 для бампов версий, миграций, изменений infra-слоя и задач «поведение не должно измениться»), сказать это в начале прогона и потребовать подтверждения.

L0 исключить нельзя. Это неявный входной гейт всех остальных уровней: про код, который не собирается, не доказано ничего.

Модель исполнения — три блока

Пирамида отвечает на вопрос «что обязано быть проверено», а не «в каком порядке запускаются процессы». Исполнение делится на три блока, и ось контракта — соответствие источнику истины — проходит поперёк всех трёх.

1. Механический блок — L0 сборка, L1a линт и типы, L2 изолированные тесты, затем гейт покрытия public API. Машинные вердикты, fail-fast, без суждения.
2. Слои суждения — L1b. code-reviewer плюс условная экспертная панель и coverage-аудит, поверх зелёного механического блока. Под --fix механический блок перепрогоняется после каждой мутации; этот интерливинг несущий, а не деталь: фикс, ломающий сборку, обесценивает все суждения, вынесенные после него.
3. Device-блок — L3 UI-тесты → L4 E2E → L5 ручная верификация, строго в этом порядке. Гейт владеет устройством и установленной сборкой на всём протяжении блока.

Блоки упорядочены. Красный механический блок не веерится в суждение; слой суждения с непогашенным BLOCK не пускает в device-блок.

Словарь

Канонические значения; create-pr и все потребители ниже по потоку читают их из расписки.

• project_type — android | ios | web | desktop | backend-jvm | backend-node | cli | library | generic.
• has_ui_surface — выводится из project_type. Истина для android, ios, web, desktop; для generic — спросить пользователя.
• ecosystem — стек сборки (gradle | node | rust | go | python | xcode), нужен только для выбора команд механического блока. Ортогонален project_type.
• Вердикт подпроверки — PASS | WARN | FAIL | SKIPPED, плюс severity (critical | major | minor), confidence (high | medium | low) и domain_relevance для агрегации.
• Оценка находки — находки суждения оцениваются по рубрике confidence 0–100, определённой один раз в ~/.claude/agents/code-reviewer.md и унаследованной везде. BLOCK — critical/major ≥ 75. WARN — minor ≥ 50, только сообщается. Ниже порога — отбрасывается.
• Aggregated Status — VERIFIED | FAILED | PARTIAL.
• Уровни пирамиды — L0 сборка, L1a статический анализ, L1b экспертное агентное ревью, L2 изолированные тесты, L3 интеграционные, L4 E2E, L5 ручная верификация. --levels адресует их этими именами; L1 означает оба подуровня сразу.

Шаг 0: определить тип проекта

Определять по build-файлам, манифестам и раскладке исходников: Android (AndroidManifest.xml, build.gradle* с com.android.application), iOS (*.xcodeproj, Package.swift с iOS-таргетами), web (package.json с браузерным фреймворком), desktop (Compose Desktop, Tauri, Electron), backend (Spring/Ktor/Express без UI), CLI и библиотека (UI-поверхности нет). Неоднозначно — спросить. На выходе: project_type, has_ui_surface, ecosystem.

Правило переопределения. Непустой platform: во frontmatter спецификации побеждает: первое его значение становится project_type, полный список записывается как platforms: [...], тип multi-platform не выдумывается. Записать project_type_override: spec, либо user, если пользователь поправил определение по ходу.

Чтения файлов шага 0 и шага 1 не пересекаются — выдать оба набора одним пакетом вызовов Read.

Шаг 1: собрать входы

Приёмке нужен хотя бы один источник верификации. Прочитать источники спецификации (Figma, PRD, список AC, описание PR, issue) и загрузить frontmatter спеки (platform, surfaces, risk_areas, non_functional, acceptance_criteria_ids, design.figma).

Прозондировать артефакты одним пакетом вызовов Read: swarm-report/<slug>-test-plan.md, docs/testplans/<slug>-test-plan.md, swarm-report/<slug>-debug.md.

Чистота рабочего дерева. Проверить git status --porcelain до всего остального. Слои суждения считают дифф по диапазону коммитов, а механический блок и device-блок исполняют рабочее дерево: пока в дереве есть незакоммиченные изменения затронутых исходников, эти два блока проверяют не то, что судят ревьюеры, и diff_hash описывает не то, что прогонялось. Найдено — назвать файлы и потребовать решения (закоммитить либо явно принять расхождение записью в расписке), а не продолжать молча. Незакоммиченный прогон code-simplifier — самый частый источник этого расхождения, но правило общее и от него не зависит.

Выбранный источник запускает одну из четырёх веток — test_plan_source: receipt | mounted | on-the-fly | absent. debug.md как единственный источник подходит под ветку 3 (on-the-fly): верификация багфикса относится к нему как к спека-подобному входу. Семантика веток, переопределения mount-расписки и инварианты по surfaces — в references/source-branches.md. Ветку записать в расписку.

Верификация инструментирования. Если тест-план несёт раздел ## Non-functional / Instrumentation, и он не N/A: <причина>, проверить на работающем приложении, что каждое объявленное событие, метрика или span действительно испускается, когда исполняется его поведение. Объявлено, но не испускается, либо испускается с неверными полями — находка P1 через обычный цикл FAILED.

Шаг 1.5: гейт отсутствующего источника

Срабатывает только на test_plan_source: absent.

Content truncated.