Verify Hypotheses

---
name: verify-hypotheses
description: Сверка журнала гипотез (hypotheses-log.md) по запросу вне ритма week-close. Фильтрует записи со статусом «на сверке» и наступившей датой, сверяет критерий фальсификации с доступной фактурой, предлагает вердикт, пилот подтверждает, вердикт пишется новой записью. Вызывать на явную фразу пилота, не автоматически.
version: 0.1.0
status: experimental
layer: L1
agents: single
interaction: multi-step
gates_required: []
gates_enforced: []
gates_rationale: "IntegrationGate пропущен явным разрешением пилота 19.07 (РП-496 Ф3) — роль-носитель для гипотез ещё не выбрана (Ф4 не завершена), Service Clause/Role заводить преждевременно до этого решения"
triggers:
  slash: [/verify-hypotheses]
  phrases: ["сверь гипотезы недели", "сверь гипотезы"]
---

# /verify-hypotheses

> **Scope:** прочитать `hypotheses-log.md`, найти записи с наступившей датой сверки, сверить с фактурой, предложить вердикт, записать подтверждённый пилотом вердикт новой записью.
> **Not in scope:** не создаёт новые гипотезы (это Note-Review), не выполняет сверку на week-close автоматически (это шаг 6a `.claude/skills/week-close/SKILL.md` — этот скилл дублирует тот же алгоритм для вызова вне недельного ритма), не редактирует исходные записи.
> **Role:** нет выделенной роли-носителя — используется тем, кто сейчас ведёт week-close (Стратег, R1). См. открытый АрхГейт-вопрос РП-496 Ф4.

## When to use

- Пилот говорит «сверь гипотезы недели» или «сверь гипотезы» вне обычного ритма Week Close.
- Есть подозрение, что конкретная гипотеза уже разрешилась (пилот увидел факт раньше даты сверки) и хочет проверить досрочно.
- Диагностика: сколько гипотез сейчас «на сверке» и когда у них дата.

## Preconditions

1. **WP Gate precondition.** Задача привязана к РП-496 (Журнал гипотез, LPF-регламент обратной связи), фаза 3.
2. **Журнал существует.** `{{GOVERNANCE_REPO}}/current/hypotheses-log.md` — если файла нет, сообщить пилоту и завершить (журнал ещё не создан или создан в другом месте).

## Algorithm

### Step 1 — Прочитать журнал и отфильтровать

Input: `{{GOVERNANCE_REPO}}/current/hypotheses-log.md`
Action: прочитать все записи. Отобрать те, у которых `Статус: на сверке` И `Дата сверки` ≤ сегодня. Записи со статусом `черновик` (не подтверждённые пилотом на Note-Review) пропустить — они вне цикла сверки. Записи, уже имеющие вердикт (`подтверждена`/`опровергнута`/`частично подтверждена`/`неприменимо`), пропустить.
Output: список ID (H-NNN) с наступившей датой сверки, готовых к проверке. Если список пуст — сообщить «Нет гипотез с наступившей датой сверки» и завершить (не ошибка, штатный результат).

### Step 2 — Сверить каждую запись с фактурой

Input: список ID из Step 1
Action: для каждой записи прочитать критерий фальсификации и сверить с доступными источниками — коммиты (`git log` по затронутым репо), `domain_event` (если критерий про измеримую метрику платформы), инфраструктурные логи, факты из ближайшего WeekReport/DayPlan. Если критерий требует данных, которых нет в доступных источниках — явно пометить «данных недостаточно для вердикта», не гадать.
Output: для каждой записи — черновик вердикта (подтверждена / опровергнута / частично подтверждена / неприменимо) с обоснованием (какие факты сверены, откуда).

**Правило «неприменимо»:** если условие критерия физически не выполнено (например, зависимый артефакт, о котором гипотеза, не был доставлен) — вердикт «неприменимо», не «опровергнута». Нельзя отличить провал гипотезы от провала внедрения, если предпосылка критерия не соблюдена.

### Step 3 — Предложить пилоту и получить подтверждение

Input: черновики вердиктов из Step 2
Action: показать пилоту таблицу (ID, утверждение кратко, предложенный вердикт, обоснование). Спросить подтверждение или правку на каждую запись.
Output: финальный вердикт по каждой записи, согласованный с пилотом.

### Step 4 — Записать вердикт и предложить действие

Input: финальные вердикты из Step 3
Action: для каждой записи — добавить **новую** запись в конец `hypotheses-log.md` в формате `## Сверка H-NNN` со ссылкой на исходную запись, вердиктом и датой сверки. Исходную запись НЕ редактировать (запрет правки задним числом — `memory/lpf-hypothesis-log.md`). Обновить `Статус` в исходной записи на итоговый (это единственное поле исходной записи, которое меняется — статус, не содержание). Затем спросить: какое действие следует из этого вердикта — обновить уверенность на будущее / добавить шаг в чек-лист / завести РП / зафиксировать кандидат в паттерн (Capture-to-Pack). Выбранное действие исполняется вне этого скилла (терминальный выход — уходит в WeekPlan/Pack/РП, потребитель за пределами контура verify-hypotheses).
Output: журнал обновлён, каждый вердикт имеет привязанное действие (не «повисший»).

### Step 5 — Коммит

Input: обновлённый `hypotheses-log.md`
Action: закоммитить в governance-репо (тот же процесс, что и другие правки `current/`).
Output: изменения сохранены, история гипотез не потеряна.

## Bundled resources

Нет — алгоритм полностью текстовый, без скриптов/шаблонов.

## Anti-patterns

- Не выносить вердикт без сверки с реальной фактурой — «показалось, что подтвердилась» не считается.
- Не редактировать исходную запись гипотезы при вынесении вердикта — только новая запись со ссылкой.
- Не выносить «опровергнута» вместо «неприменимо», когда предпосылка критерия не выполнена.
- Не оставлять вердикт без выбранного действия — «повисший» вердикт не закрывает цикл.
- Не запускать этот скилл автоматически на каждой сессии — только по явному запросу пилота (недельный ритм покрыт шагом 6a week-close).

## Verification

```bash
bash scripts/verify-skill.sh verify-hypotheses
```
Ожидаемый результат: PASS. Живая проверка — вызвать скилл вручную после 2026-09-01 (дата сверки первой записи H-001 в `hypotheses-log.md`), убедиться, что алгоритм находит именно эту запись и не находит других (журнал сейчас содержит только H-001).

<!-- USER-SPACE -->
<!-- /USER-SPACE -->