/verify

name: verify
description: Four-layer verification фичи. syntax → runtime → e2e → user-reported. Только passing all 4 = feature в done. Триггеры — "/verify", "проверь работает", "запусти тесты".
when_to_use: По завершению implementation фичи. Это единственный путь перевести feature_list.json state из active в passing.

/verify

Four-layer verification (4-уровневая проверка) активной фичи.

Layer 0: Enforcement жив? (v6.2 F2)

P="$(cat .harness/profile 2>/dev/null)"; HB=.harness/hooks-heartbeat
case "$P" in pending-*) echo "❌ профиль $P не подтверждён живым хуком"; esac
[ -f "$HB" ] && [ $(( $(date +%s) - $(awk '{print $1;exit}' "$HB") )) -le 1800 ] \
  || echo "❌ heartbeat несвежий — хуки в этой сессии НЕ работают"

❌ → СТОП: verify при мёртвых сторожах легко станет «зелёным враньём» (passing-гейт не проверит evidence). Сначала `/doctor`.

Layer 1: Syntax & Static Analysis

Минимальный gate, фундамент.

# JavaScript/TypeScript
npm run check          # tsc --noEmit
npm run lint           # eslint

# Python
ruff check .
mypy src/

# Common
git diff --check       # whitespace

Если хоть что-то красное — STOP, чинить.

Layer 2: Runtime Behavior (unit + integration)

# из feature_list.json[active].verification.layer_2_runtime
npm test -- --filter=<feature>
# или
pytest tests/test_<feature>.py -v

Все тесты зелёные = pass.

Layer 3: End-to-End

Закрывает lecture-10 (E2E меняет результат).

# Из feature_list.json[active].verification.layer_3_e2e
./e2e/test-<feature>.sh
# или
playwright test e2e/<feature>.spec.ts
# или chrome-devtools-mcp scenarios

Кейс из реального проекта: unit-тесты прошли 3/3, e2e нашёл 5 дефектов на границах. Этот слой не пропускать.

Evidence по поверхности (v6.2 F5)

Тип доказательства обязан соответствовать `surface` фичи — полная таблица: [rules/verification-lanes.md](../../rules/verification-lanes.md). Кратко: ui → браузер + layer_4/5; api → curl + статус; cli → команда + exit; job → лог реального прогона; service → behavior-probe (НЕ pgrep). Hook не пустит passing с пустым evidence у этих поверхностей.

**«Не могу прогнать живьём» → Live-Target Probe, 4 яруса** (см. ту же таблицу): найти живой сервер → поднять самому → preview-деплой → только после задокументированного провала всех трёх — честный `UNIT_VERIFIED` (не passing). Skip молча — не вариант.

Layer 4: User-reported (НОВОЕ в v5.1)

Закрывает CRITICAL инсайт: «если verification passing, но пользователь говорит не работает — у нас плохие verification commands».

**Этот слой = реальное использование пользователем.**

Если layer 1-3 зелёные:

• Если фича без UI → автоматический pass (нет user-facing)
• Если UI → попросить пользователя протестировать кратко ОДИН раз
• «Готово feat-XXX. Проверь поведенческий сценарий: <описание из verification.layer_4_user>. Работает?»
• Ответ «да» → layer 4 pass
• Ответ «нет / не так» → запись в error-journal.md + откат фичи в active + улучшение тестов

Negative-Verification self-check

Перед промоушеном в passing — повторно прогнать negative-test:

# Специально внести ошибку → verification должна упасть
# Если verification всё равно зелёная — verification сломана, не код

Это единоразовая проверка на фичу. Закрывает реальный случай (ожидаемое значение «утекло» в контекст теста) и общий «verification not verified» gap.

Adversarial verifier (v8 L5-F4) — независимый эшелон перед passing

Layer 1-4 + negative прогнал сам имплементатор — тот же агент, что писал код. Финальный слой — **независимый** свежий взгляд: запусти агента `stage-verifier` (fresh context, `disallowedTools=Write/Edit` — физически не может подгонять код) в **adversarial-режиме**.

• Передай ему **claim** (что фича делает — из feature.description + business_invariant) + **diff** фичи.
• Он работает по установке **assume broken until proven**: НЕ доверяет твоему «зелёному», прогоняет edge-cases сам (пустой/граничный ввод, error-пути, конкурентность, шов changed/unchanged) и возвращает **CONFIRMED** или **REFUTED** с repro.
• **REFUTED** → фича НЕ идёт в passing: заводишь дефект, чинишь (Шаг «Если что-то падает»), повторяешь /verify. **CONFIRMED** → можно в passing.

Обязателен на M/L (surface=logic/ui). На S — по усмотрению. Гарантия независимости — `disallowedTools` во фронтматтере (self-check раздел 4 флагует verifier с Write/Edit).

State transition

Все 4 слоя + negative passed → feature_list.json:

"state": "passing",
"evidence": {
    "layer_1_at": "ISO timestamp",
    "layer_2_at": "...",
    "layer_3_at": "...",
    "layer_4_at": "...",
    "negative_verified_at": "...",
    "commit_hash": "abc123"
}

Auto-commit:

git add -A
git commit -m "feat(<feature-id>): <feature-name>

Implements: <feature-id>
Verified-By: <verification_command_hash>
State-Transition: active→passing"

Если что-то падает

Counter увеличивается, до 3

d['features'][f]['verify_attempts'] = d['features'][f].get('verify_attempts', 0) + 1

При **3 неуспешных попытках** на layer 2+3 (не syntax — syntax чинить сразу) → **auto-trigger /stuck**.

Запись в error-journal

При любом fail записываем в error-journal.md:

## err-NNN | <date> | <feature_id>
**Триггер**: verification fail (layer N)
**User reported**: no (auto-detected)
**5 Why**: 1) ... 5) корневая причина ...
**Класс ошибки**: <verification_gap / scope_leak / state_drift / ...>

Anti-patterns

• ❌ Помечать passing если хоть один слой не зелёный
• ❌ Использовать `--skip-layer` флаги
• ❌ Игнорировать negative-verification self-check
• ❌ Скрывать verify_attempts от пользователя
• ❌ Считать что unit pass = feature passing (реальный случай: unit пройдены, e2e нашёл 5 дефектов на границах)