Acceptance

---
name: acceptance
description: 'Author, run and repair human-written acceptance checks (образ результата) stored in acceptance/ACCEPTANCE.md — best-effort, prompt-held, no guarantees. Use when PM mentions "acceptance checks", "приёмка", "образ результата", "запусти приёмку", "acceptance run", "прогони приёмку", "почини по красным", or any request to record what "готово" means and hold the work against it. Trigger liberally — without it "готово" stays a matter of opinion; over-triggering is recoverable (PM can delete the file).'
argument-hint: "[author | run | repair] [AC-NNN]"
---

# /polisade:acceptance [author | run | repair] — Приёмка как практика

Человек записывает **образ результата** — пары «одна фраза интента + один
исполняемый чек» — в `acceptance/ACCEPTANCE.md`. Скилл гоняет эти чеки и чинит
код по красным. Разбор файла, линт и прогон — детерминированные
(`scripts/polisade_acceptance.py`, stdlib-only); интервью и ремонт — работа
модели.

---

## ⚠️ ЧЕСТНАЯ РАМКА — прочитай и повтори пользователю при первом запуске

```
┌─────────────────────────────────────────────────────────────┐
│  Это приёмка-ПРАКТИКА (best-effort), а НЕ приёмка-ГАРАНТИЯ. │
│                                                             │
│  Файл проверок лежит в репозитории: он виден модели и       │
│  доступен ей на запись. Запрет «не правь проверки, чини     │
│  код» держится ПРОМПТОМ этого скилла, а не барьером.        │
│  Прогон умеет ЗАМЕТИТЬ подмену (дайджесты пар и их          │
│  приборов), но не                                           │
│  умеет её ПРЕДОТВРАТИТЬ.                                    │
└─────────────────────────────────────────────────────────────┘
```

Что это значит на практике:

- зелёная приёмка здесь = «чеки прошли», а не «результат гарантирован»;
- самый вероятный способ получить ложную зелень — ослабить сам чек; ровно этот
  путь и не закрывается промптом;
- приёмка с гарантией (оракул вне досягаемости исполнителя, независимый судья,
  барьеры против правки тестов) — свойство отдельного **платного** продукта;
  граница описана в документе `docs/what-works-without-paid-parts.md`
  репозитория Polisade Orchestrator (в поставку плагина `docs/` не входит).

⛔ Запрещено (класс F1 — «отказ способности подан как положительный факт»):
подавать вывод этого скилла как «приёмка пройдена, качество подтверждено».
Пиши как есть: «чеки приёмки зелёные (best-effort, проверки правились/не
правились — см. отчёт)».

---

## Использование

```
/polisade:acceptance author            # интервью: записать образ результата (пары)
/polisade:acceptance author AC-003     # добавить/переписать ОДНУ пару
/polisade:acceptance run               # прогнать все чеки, показать красные
/polisade:acceptance run AC-001        # прогнать одну пару
/polisade:acceptance repair            # пересдача: чинить КОД по красным чекам
/polisade:acceptance repair AC-002     # пересдача по одной паре
```

Без аргумента режим выбирается так: файла приёмки нет → `author`; файл есть →
`run`. Ремонт (`repair`) никогда не выбирается сам — его просит человек.

---

## Алгоритм

### Шаг 0. Общий пре-чек (все режимы)

1. Корень проекта = текущая рабочая директория.
2. Канонический файл: `acceptance/ACCEPTANCE.md`.
3. Формат — не выдумывай, возьми канон:

```bash
python3 {plugin_root}/scripts/polisade_acceptance.py template
```

⛔ **НЕ реконструируй формат по памяти.** Скелет, который печатает `template`,
— единственный источник истины; линт проверяет ровно его.

---

### Режим `author` — интервью по одному пункту

Образ результата пишет **человек**. Модель здесь — стенографист и редактор:
задаёт вопрос, показывает черновик, фиксирует подтверждённое.

1. **Собери исходный материал** (read-only): SPEC/FEAT (`### FR-NNN` и Gherkin
   AC), свежие TASK, `README`/`knowledge.json` (как в этом проекте запускаются
   тесты). Если ничего нет — это нормально, интервью начнётся с чистого листа.
2. **Предложи черновой список пунктов** — по одной фразе на пункт, языком
   пользователя, не реализации. Максимум 7 за раз, иначе интервью
   превращается в вычитку простыни.
3. **Интервью — строго по ОДНОМУ пункту.** Для каждого пункта покажи:

```
──────── ПУНКТ ПРИЁМКИ (черновик) ────────
id:          AC-001
интент:      Пустой заказ не даёт нулевую сумму, а падает с понятной ошибкой
требование:  SPEC-001.FR-003
цели:        src/orders/total.py
чек:
    python3 -m pytest tests/acceptance/test_order_total.py::test_empty_order_raises -q
──────────────────────────────────────────
Подтвердить / изменить / выбросить?
```

   Ответы: **подтверждаю** → пара идёт в файл; **изменить `<что>`** → покажи
   исправленный пункт и спроси снова; **выбросить** → пара не пишется.
   ⛔ Молчание/пустой ответ = **прервать интервью**, а НЕ «принято»: оракул,
   которого никто не читал, хуже отсутствующего.
4. **Владелец обязателен**: в паре проставь `ratified_by:` — имя/роль того, кто
   подтвердил (`PM`, имя человека). Если подтверждающего нет — пару не пиши.
5. **Пиши файл** `acceptance/ACCEPTANCE.md` в формате из `template`
   (существующие пары не трогай, если человек не просил их переписать).
6. **Линт — обязательно** после записи:

```bash
python3 {plugin_root}/scripts/polisade_acceptance.py lint --root .
```

   Ошибки (`E-AC-*`) чини сразу и покажи человеку, что именно поправил.
   Предупреждения (`W-AC-*`) — озвучь, решает человек.
7. **Зафиксируй базу дайджестов** (нужна режиму `repair`):

```bash
python3 {plugin_root}/scripts/polisade_acceptance.py digest --root . --save
```

   Если база уже стояла и набор изменился, скрипт потребует `--force` —
   добавляй его ТОЛЬКО когда человек в этом же интервью подтвердил правку
   проверок, и скажи вслух, какие пары перефиксированы.

**Правила чека (повтори их человеку, если он диктует чек сам):**

- чек — команда, у которой rc=0 значит «зелено», rc≠0 — «красно»;
- у чека ОБЯЗАН быть путь к красноте: `true`, `... || true`, а также любая
  всегда-успешная ПОСЛЕДНЯЯ команда (`echo ok`, `printf ...`, `exit 0` —
  именно она решает rc) — это пара-декорация, линт такое отвергает;
- если чек не называет файлов (`pytest -q`, `make acceptance`, gradle-таск),
  спроси человека и запиши **`instruments:`** — пути теста/фикстуры, которые
  этот чек запускает. Без них ремонту нечего защищать: линт предупредит
  (`W-AC-NO-INSTRUMENTS`), а прибор останется беззащитным;
- чек **read-only** над рабочей копией: он ничего не коммитит, не чекаутит и
  не переписывает файлы (иначе приёмка сама станет причиной красноты соседних
  чеков);
- чек не ссылается на сам файл приёмки — это самоподтверждение;
- один интент — один чек. Пара «проверим всё сразу» не диагностируется;
- пара внутри HTML-комментария **не существует**: рендер её человеку не
  показывает, значит и ратифицировать её никто не мог — скрипт такие секции
  игнорирует целиком (комментарий годится только для пояснений).

---

### Режим `run` — прогон

1. Прогон (весь набор или одна пара):

```bash
python3 {plugin_root}/scripts/polisade_acceptance.py run --root .
python3 {plugin_root}/scripts/polisade_acceptance.py run --root . --only AC-001
```

2. Скрипт сам:
   - линтует формат и **отказывается исполнять** набор со структурными
     ошибками (дефект формата ≠ дефект кода — не смешивать);
   - исполняет каждый чек отдельно (таймаут по умолчанию 300 с на чек);
   - пишет отчёт `.state/acceptance-report.json`;
   - если база дайджестов зафиксирована — печатает, какие проверки изменились
     с момента фиксации.
3. **Перескажи вывод честно.** Красные — списком, с последними строками
   вывода. Зелёные — числом. Если набор проверок изменился — скажи это ВСЛУХ
   отдельной строкой, даже если всё зелёное.
   ⛔ «Нет красных» ≠ «зелено»: **таймаут** (`[TMOUT]`) и **сбой запуска**
   (`[ERROR]`) — это «не подтверждено», а не успех. Зелёным набор считается,
   только когда `зелёных == всего` (rc=0). Пересказывай статусы как есть.
4. Дальше: есть красные/таймауты/сбои → предложи
   `/polisade:acceptance repair`; всё зелено → скажи «чеки приёмки зелёные»
   **с оговоркой best-effort**, не «качество подтверждено».

⛔ В режиме `run` файл `acceptance/ACCEPTANCE.md` **не редактируется вообще** —
ни «поправить опечатку», ни «уточнить путь».

---

### Режим `repair` — пересдача по проваленным

Чинится **КОД**, а не проверки. Лимит — **3 раунда**, потом честная остановка.

1. **Убедись, что база зафиксирована** (её ставит `author`; если базы нет —
   поставь сейчас):

```bash
python3 {plugin_root}/scripts/polisade_acceptance.py digest --root . --save
```

   ⛔ Если база уже есть и **отличается** от текущего набора — скрипт откажет
   (rc=2). Это не препятствие, которое надо обойти `--force`: отличие означает,
   что проверки уже правились. Останови ремонт и покажи человеку
   `ACCEPTANCE TAMPER`. `--force` — команда человека, не твоя.
   ⚠️ Если базы **не было** и ты ставишь её сейчас — скажи вслух: «база
   зафиксирована только что; правки проверок, сделанные ДО этого момента, не
   будут замечены». Сравнивать не с чем — это честная оговорка, а не формальность.

2. Прогон → возьми из `.state/acceptance-report.json` **все не-зелёные** пары
   (поле `"status"` ≠ `"green"`), и работай с ними по-разному:
   - `"red"` — чек отработал и не сошёлся: чинится код;
   - `"timeout"` — чек не успел: сначала пойми, это медленный код или
     недостаточный `timeout:` пары; правка `timeout:` — работа человека
     (`author`), не твоя;
   - `"error"` — чек не запустился (нет инструмента, опечатка в команде):
     это дефект пары или окружения, а не кода → покажи человеку, не «чини»
     код вслепую.
   ⛔ Пустой список не-зелёных при `blocked: true` в отчёте — это не «всё
   зелено», а заблокированный формат: иди в `author`.
   ⛔ Читай отчёт только **сразу после собственного прогона** (сверься с
   `generated_at`): чужой/старый отчёт описывает другое дерево.
3. **Раунд ремонта** (для каждой красной пары, по одной):
   - прочитай интент пары и вывод чека;
   - локализуй правку: сначала `target_files` пары, затем — точечный
     `grep -n "<символ>" <файл>` по терминам из интента (детерминированный
     LOCALIZE, тот же протокол, что в `/polisade:implement`);
   - ⛔ **не трогай ПРИБОР пары** — файлы из её `referenced_paths` в отчёте
     (это то, что чек запускает: тест-файл, фикстура, конфиг прогона).
     Поправить прибор — второй способ купить ложную зелень, и он такой же
     запрещённый, как правка самого чека;
   - ⚠️ если у пары `referenced_paths` **пуст** (чек вида `pytest -q` или
     `make acceptance` не называет файлов, и `instruments:` не заполнен) —
     защищать нечего механически: **не трогай тесты вообще** без явного
     разрешения человека и скажи ему, что паре нужен `instruments:`;
   - правь **код**; чужие (не приборные) тесты репо — только если правка
     реально того требует, и скажи об этом в отчёте раунда;
   - перепрогон только этой пары:
     `... run --root . --only <ID> --fail-on-changed`.
4. **Проверка честности раунда** — обязательна, до объявления зелени:

```bash
python3 {plugin_root}/scripts/polisade_acceptance.py run --root . --fail-on-changed
```

   Флаг `--fail-on-changed` делает rc=1, если после фиксации базы изменилась
   проверка **или прибор** (файл, который она запускает). Красный по этой
   причине → **немедленный STOP** и артефакт `ACCEPTANCE TAMPER` (ниже). Это
   детект, а не барьер: он ловит собственную ошибку/дрейф, а не защищает от
   намеренного обхода.
5. **Лимит 3 раунда.** Пара всё ещё красная после третьего → **honest halt**:
   печатай артефакт `ACCEPTANCE HALT`, статус связанной TASK (если ремонт идёт
   в контексте TASK) переводи в `waiting_pm`, дальше — решение человека.

⛔ Категорически запрещено в режиме `repair`:

- править `acceptance/ACCEPTANCE.md` (ослаблять чек, менять команду, удалять
  пару, «уточнять» интент) — правка проверок делается ТОЛЬКО через
  `/polisade:acceptance author` и ТОЛЬКО с явным подтверждением человека;
- править **приборы** пары — файлы из `referenced_paths` (тест, который
  запускает чек, его фикстуры и конфиг прогона): подгонка прибора под код —
  та же ложная зелень, что и подгонка чека;
- помечать красную пару зелёной, «потому что по сути работает»;
- глушить чек в коде (пропуск/скип теста, заглушка вместо реализации,
  подстройка под конкретный ассерт вместо реализации интента);
- продолжать после третьего раунда;
- перефиксировать базу дайджестов (`digest --save --force`), чтобы «сбросить»
  сигнал о правке — это ровно заметание следа.

**Это промптовые запреты, и они названы промптовыми.** Барьер, физически
закрывающий правку проверок, живёт в платном продукте — здесь его нет.

---

## Формат вывода

### Прогон (`run`)

```
════════ ПРИЁМКА (best-effort) ════════
Пар: 5 · зелёных: 3 · красных: 2
Красные:
  AC-002 — Итог заказа считается по позициям, а не по последней цене
      | assert 120 == 100
  AC-004 — Экспорт заказа отдаёт CSV с заголовком
      | FileNotFoundError: export.csv
Набор проверок: не менялся с момента фиксации базы.
Оговорка: чеки видны модели и доступны ей на запись — это практика, не гарантия.
Дальше: /polisade:acceptance repair
═══════════════════════════════════════
```

### Honest halt (`repair`, лимит раундов)

```
──────── ACCEPTANCE HALT (AC-002) ────────
раунды: 3/3 (лимит достигнут)
интент: Итог заказа считается по позициям, а не по последней цене
последний вывод чека: assert 120 == 100
пробовал:
  - раунд 1: <что менял> → <почему не прошло>
  - раунд 2: <...>
  - раунд 3: <...>
проверки не менялись: да/нет
next: человек — интент неверен? чек проверяет не то? нужен re-scope?
──────────────────────────────────────────
```

### Подмена проверки (`repair`, `--fail-on-changed`)

```
──────── ACCEPTANCE TAMPER ────────
изменены после фиксации базы: AC-002
изменены приборы пар: tests/acceptance/test_order_total.py
Ремонт ОСТАНОВЛЕН: в режиме repair не правятся ни проверки, ни их приборы.
Если проверка действительно неверна — это работа человека:
  /polisade:acceptance author AC-002
───────────────────────────────────
```

---

## Пример пары (вымышленный домен `com.example.orders`)

````markdown
## AC-001 — Пустой заказ не даёт нулевую сумму, а падает с понятной ошибкой

- requirement: SPEC-001.FR-003
- target_files: src/com/example/orders/OrderTotalCalculator.java
- instruments: src/test/java/com/example/orders/OrderTotalCalculatorTest.java
- ratified_by: PM

```bash
mvn -q -Dtest=OrderTotalCalculatorTest#emptyOrderRejected test
```
````

Интент — на языке пользователя («не даёт нулевую сумму»), а не реализации
(«бросает `EmptyOrderException` в строке 42»). Чек — исполняемый и
фальсифицируемый: на сломанном коде он обязан краснеть. `instruments:` здесь
обязателен: команда сборки не называет файл теста, и без явной записи ремонт
не знал бы, что именно ему запрещено трогать.

---

## Важно

- **Файл приёмки — артефакт репозитория.** Он коммитится, ревьюится в PR и
  живёт рядом с кодом; его изменения видны в диффе — это и есть главный
  (человеческий, не машинный) контроль над проверками.
- **Скрипт не пишет ничего, кроме** `.state/acceptance-report.json` и
  `.state/acceptance-baseline.json` (по `digest --save`). **Но сам чек — это
  произвольная команда из файла репозитория**: он исполняется `bash -c` с
  правами и окружением сессии и технически может писать куда угодно.
  Песочницы здесь нет; граница доверия — человек, который читает и
  подтверждает проверки, и ревьюер, который видит их в диффе PR. Линт ловит
  только грубые пишущие формы и только предупреждением (`W-AC-WRITES`).
- **Чужой файл приёмки — чужой код.** Прежде чем в первый раз гонять приёмку
  из репозитория, который ты не писал (форк, чужой PR), покажи тела чеков
  человеку и дождись подтверждения.
- **Красный чек ≠ красный формат.** Структурные ошибки набора блокируют
  прогон целиком — чинится `author`, а не ремонтом кода.
- Приёмка **не заменяет** ни регрессионный прогон в `/polisade:implement`, ни
  ревью в `/polisade:review-pr`. Это отдельный вопрос: «получил ли заказчик
  то, что просил», а не «не сломали ли соседнее».
- Связанные команды: `/polisade:implement` (реализация TASK),
  `/polisade:review-pr` (ревью PR), `/polisade:unblock` (ответы на вопросы,
  когда приёмка встала в `waiting_pm`).