---
name: workflow-kit-verify
description: Финальная проверка изменения по spec.md, plan.md, scope.md, tasks.md и verification.md. Используй после workflow-kit-implement или перед завершением change.
metadata:
  title: "Верификация изменения"
---

# Workflow Kit: verify

Проверь изменение и обнови `verification.md`: `$ARGUMENTS`.

Цель: дать честный финальный статус change для пользователя и следующего AI: что реализовано, что проверено, где gaps/risks, не нарушены ли границы `scope.md` и можно ли считать change завершённым.

Не исправляй код на этапе verify, если пользователь явно не попросил. Verify — это проверка и фиксация результата, не новая implementation-фаза.

## Порядок работы

### 1. Найди workspace

Найди workspace:

- если `$ARGUMENTS` содержит путь к workspace, используй его;
- если `$ARGUMENTS` содержит `change-name`, найди `ai/specs/*_{change-name}/`;
- если совпадений несколько — выбери последний по timestamp или уточни;
- если workspace не найден — остановись и попроси путь или точный `change-name`.

В workspace должны быть:

- `spec.md`;
- `plan.md`;
- `scope.md`;
- `tasks.md`;
- `verification.md`.

Если любого из обязательных файлов нет — остановись и скажи, какой этап нужно выполнить перед verify.

### 2. Загрузи контекст

Прочитай:

- `spec.md`;
- `plan.md`;
- `tasks.md`;
- `verification.md`;
- `scope.md`;
- `research.md`, если есть;
- `data-model.md`, если есть;
- `implementation-fix.md`, если есть;
- project instructions, если они не были в контексте и влияют на проверку;
- релевантный код и тесты;
- результаты команд, если они уже есть в чате, логах или `verification.md`.

Не используй старые `ai/specs/*`, `plan.md` или `tasks.md` из других workspaces как источник требований для этого change, если пользователь явно не указал связанный workspace.

### 3. Проверь completeness

Проверь:

- все P0/обязательные acceptance criteria из `spec.md` покрыты реализацией или явно помечены как not done;
- все обязательные задачи в `tasks.md` выполнены или имеют объяснение;
- optional/P1/P2 не выданы за завершённые P0;
- `implementation-fix.md`, если есть, закрыт или его риски перенесены в `verification.md`;
- открытые вопросы не замазаны как выполненная работа.

Если P0/обязательный пункт не выполнен — финальный статус не может быть `Ready`.

### 4. Проверь correctness

Проверь:

- реализация соответствует `spec.md`;
- технический подход соответствует `plan.md` или отклонение явно объяснено;
- edge cases из spec покрыты тестами, ручной проверкой или явно указаны как gap;
- нет поведения, противоречащего `## Вне скоупа`;
- нет незапланированного scope creep.

Если spec/plan/tasks устарели относительно реализации — не переписывай их молча. Зафиксируй gap и предложи вернуться к нужному этапу.

### 5. Проверь границы `scope.md`

Проверь изменённые файлы против `scope.md`:

- все изменённые файлы входят в `Freely editable` или были подтверждены;
- `Requires confirmation` изменялись только после подтверждения;
- `Forbidden` files не изменялись;
- shared/public surfaces отмечены и проверены;
- generated/external files не редактировались руками без команды регенерации;
- нет очевидного scope creep за пределы `plan.md` и `tasks.md`.

Если границы нарушены — статус не `Ready`; используй `Blocked` или `Needs user decision`.

### 6. Запусти проверки

Запусти минимально достаточные команды из `verification.md`, `tasks.md` и `plan.md`, если окружение позволяет.

Приоритет:

1. проверки, явно указанные в `verification.md`;
2. финальные проверки из `tasks.md`;
3. тестовая стратегия из `plan.md`;
4. минимальные релевантные проверки проекта.

Если команда не может быть запущена:

- запиши причину;
- запиши риск;
- не притворяйся, что всё проверено.

Не запускай опасные команды, миграции, deploy, destructive scripts или внешние side-effect команды без явного разрешения пользователя.

### 7. Обнови `verification.md`

Обнови существующий `verification.md`; не затирай предыдущие результаты без причины.

`verification.md` должен содержать:

- summary/status;
- automated checks;
- manual checks;
- coverage/gaps;
- scope boundary check;
- known risks;
- final decision;
- следующий шаг, если change не готов.

Если текущий `verification.md` создан по `template/VERIFICATION-TEMPLATE.md`, сохрани его верхнеуровневую структуру и заполни фактическими результатами. Если структура старая или неполная — аккуратно дополни её нужными секциями, не теряя существующие записи.

### 8. Статусы

Используй один итоговый статус:

- `Ready` — P0/обязательное выполнено, проверки прошли, границы `scope.md` чистые, блокеров нет.
- `Ready with warnings` — P0/обязательное выполнено, есть некритичные gaps/risks или часть проверок не запускалась с понятным риском.
- `Blocked` — нельзя завершить без исправления реализации, тестов или задач.
- `Needs user decision` — нужно решение человека: scope, продуктовый вопрос, confirmation, риск или спорное отклонение от spec/plan.

Не используй `Ready`, если есть незакрытый P0, forbidden change, падающая обязательная проверка или несанкционированный public/shared change.

### 9. Git и `.gitignore`

Нельзя добавлять в git файлы или директории, которые игнорируются `.gitignore`, без явного разрешения пользователя. Не используй `git add -f` для workflow artifacts.

Перед `git add`/commit проверь созданные и изменённые файлы одним из способов:

```bash
git check-ignore -v -- <path>
git status --short --ignored
```

Политика коммита:

- Не выполняй `git add`, commit или push без явного запроса пользователя.
- Если пользователь попросил подготовить commit, включай обновлённый `verification.md` и связанные workflow artifacts, предварительно проверив `.gitignore`.
- Если workspace находится в ignored-директории, не добавляй его в git и явно скажи в финале: `workflow artifacts не закоммичены, потому что путь игнорируется .gitignore`.
- Не добавляй ignored-файлы без явного разрешения пользователя.

### 10. Результат

В финале покажи:

- путь к workspace;
- путь к `verification.md`;
- итоговый статус;
- прошедшие/падающие/not run проверки;
- scope boundary issues;
- known risks;
- готовность завершить change: да/нет;
- если не готово — следующий конкретный шаг;
- статус git/commit или причину, почему артефакты не добавлены.

## Связанные скиллы

- `workflow-kit-specify`
- `workflow-kit-plan`
- `workflow-kit-tasks`
- `workflow-kit-implement`