/feature

name: feature
description: Запуск работы над одной фичей (WIP=1). Авто-запускает test-researcher + user-perspective-critic (dual critique), читает domain-rules.yaml, error-journal, выбирает light/heavy path по размеру. Триггеры — "/feature <id>", "берём feat-X", "поехали по feat-Y".
when_to_use: Когда пользователь начинает работу над конкретной фичей из feature_list.json. Это основной рабочий цикл FAST и FULL pipeline.

/feature <feature-id>

Запуск одной фичи. WIP=1 enforced — другую фичу взять нельзя пока эта не passing.

Pre-flight checks

Check 0: Enforcement жив? (v6.2 F2; discipline-слой, несущий канал — pre-commit backstop)

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

Любая строка с ❌ → **STOP**: запусти `/doctor`, почини активацию, потом возвращайся к фиче. Работать над фичей при мёртвых сторожах = «харнес не поднялся» (главный провал аудита 06-10).

Check 1: WIP=1

# В feature_list.json должна быть ровно одна active или ноль
python3 -c "
import json
d = json.load(open('feature_list.json'))
active = d.get('active')
if active is not None and active != '<this-feature-id>':
    print(f'❌ WIP=1 violated: feat \"{active}\" already active. Закрой её через /verify до passing или /handoff с paused.')
    exit(1)
"

Если нарушено — STOP, скажи пользователю.

Check 2: Feature существует в captured/up_next

Если фича в `done` — спроси пользователя зачем заново. Если фича в `superseded`/`rejected` — STOP.

Check 3: Зависимости

# Если feat.dependencies = ["feat-001", "feat-002"] — все должны быть в done

Если нет — предложить взять зависимости сначала.

Размер и ПОВЕРХНОСТЬ фичи → light/heavy path

Из feature_list.json смотрим `size_estimate` И `surface` (v6.2 F5 — урок П2 аудита: «зелёные тесты лгут» именно на интерфейсных фичах, которые по размеру проскакивали мимо критика):

• **S (<1 час, ~30 строк, 1 файл)** → **light path** (syntax + scope check, без dual critique)
• **M (1-4 часа, 30-200 строк)** → **medium path** (single critic + verify)
• **L (1+ день, >200 строк)** → **heavy path** (dual critique + 4-layer verify)

**Поверхность ПЕРЕБИВАЕТ размер (монотонно — только ужесточение):**

• `surface: ui` (или интерфейсные файлы в affected_files) → **user-perspective-critic ОБЯЗАТЕЛЕН

при любом размере** + evidence «нажми и подтверди» (layer_4/5) до passing. UI-фича размера S не существует с точки зрения проверки: кнопку видит пользователь, не линтер.

• `surface: api|job|service|cli` → evidence реального вызова по lane-таблице

([rules/verification-lanes.md](../../rules/verification-lanes.md)) до passing.

• Поле surface заполняй при создании фичи; hook проверит монотонность (заявить `lib`

при .tsx в diff нельзя — файловая эвристика остаётся полом).

Main flow (heavy path — для L)

> ⚠️ **Порядок enforced хуком, а не дисциплиной.** `hooks/checks/state-transition.sh` БЛОКИРУЕТ > перевод M/L-фичи в `active`, пока нет `docs/test-strategy.md` с её id. Поэтому критика идёт > ПЕРВОЙ (фича остаётся в `up_next`), перевод в `active` — последним. Это test-first: стратегия > проверки рождается до реализации. Закрывает H7 (раньше критику просили «по-доброму» — и пропускали).

Шаг 1: Параллельный dual critique (фича ещё в up_next)

Запусти 2 subagent **параллельно** через Task tool (детерминированный вариант через Workflow — Шаг 3-bis):

**Agent 1: test-researcher (engineering critique)**

• Читает: feature description, CLAUDE.md, ARCHITECTURE.md, существующий код в affected_files
• Делает: параллельный GitHub-ресёрч «как тестируют похожие фичи»
• Возвращает: 3-7 тестов с verification_commands (1 happy + 2-3 edge + 1-2 error + 1 e2e)

**Agent 2: user-perspective-critic (top-down user perspective)**

• Читает: PRODUCT.md, domain-rules.yaml (особенно invariants, disambiguation_triggers, anti_patterns, target_markets)
• Делает: смотрит на фичу глазами реального пользователя
• Возвращает:
• Какие сценарии test-researcher НЕ покрыл (но пользователь bы делал)
• Какие domain-rules invariants не отражены в тестах
• Top-down вопросы: «оптимизируем по правильной метрике?», «фиксим продукт или тест?», «работает ли при голосовом вводе по-русски?»

Шаг 2: Synthesizer merge → docs/test-strategy.md (артефакт-gate)

Третий subagent (synthesizer) читает оба выхода и пишет `docs/test-strategy.md`:

• объединённый список тестов; конфликты (engineering X vs user Y) — в пользу user perspective
• **ОБЯЗАТЕЛЬНО упомянуть id фичи** в файле (хук проверяет наличие id — без него active заблокируется)
• final verification_commands → записать в feature_list.json

Шаг 2-bis: data-model-reviewer (если фича трогает БД-схему)

Если `affected_files` содержит `*/schema/*`, `*/migrations/*`, `prisma/`, `drizzle/`, `supabase/migrations/` ИЛИ `category=data` — **ОБЯЗАТЕЛЬНО** запусти агента `data-model-reviewer` (Opus, fresh context) ПЕРЕД реализацией. Он пишет `docs/data-model-review.md` (недостающие/лишние сущности, упущенные поля, спорные решения, UX-фичи которые врут о связях). Утверждение пользователя по вердикту — gate для старта. Это глобальное правило `~/CLAUDE.md` (модель данных застывает — переделка дороже ревью).

Шаг 2-ter: Стадия детализации (v8 L2-F2/F3 — обязательна на M/L)

Для **M/L-фичи** (и любой с `detail_required: true`) разложи детальный план в `docs/changes/<feat-id>/` по образцу OpenSpec (шаблон — `templates/change-proposal.md`):

• `proposal.md` — что/зачем + **User Stories с приоритетом P1..Pn**, каждая independently testable, с Acceptance в **Given/When/Then** (это основа `verification_command`). **Минимум одна P1-US с G/W/T** — иначе хук заблокирует перех