v0.1.0 to v0.1.0

---

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).