---
name: verify
description: Верификация артефакта по эталону из Pack. Загружает роль VR.R.001 (Верификатор) с context isolation — проверяет результат, а не процесс создания.
argument-hint: "[code|archgate|capture|pack|wp|chain|adversarial|subsection|section|guide|auto] [путь или id]"
version: 1.0.0
layer: L1
status: active
browser_safe: false
triggers:
  slash: [/verify]
  phrases: []
routing:
  executor: sonnet
  deterministic: false
agents: single
interaction: multi-step
gates_required: []
gates_enforced: []
gates_rationale: "операционный скилл; WP Gate применим только при создании нового РП, не для операционных вызовов"
---

# Верификация артефакта

> **Роль:** VR.R.001 Верификатор (PACK-verification)
> **Принцип:** Context isolation (VR.SOTA.002) — проверяю результат по эталону, НЕ процесс создания.
> **Архитектура:** Ядро (Pack, фиксированное) + Контекст (переменный) — AS.D.004.

Аргументы: $ARGUMENTS

## When to use

Верификация артефакта по эталону из Pack. Загружает роль VR.R.001 (Верификатор) с context isolation — проверяет результат, а не процесс создания.

## Algorithm

## Extensions `before`

```bash
bash .claude/scripts/load-extensions.sh verify before
```

Код `0` → прочитать каждый путь в алфавитном порядке и выполнить инструкции до
выбора типа проверки. Код `1` → расширений нет. Любой другой код или ошибка
обязательного шага расширения → верификацию не начинать и показать настоящую
причину.

## Шаг 0. Определить тип проверки

| Аргумент | Тип | Что проверяет |
|----------|-----|---------------|
| `code` | Проверка кода | Качество кода: логика, edge cases, безопасность, coupling |
| `archgate` | Проверка реализации АрхГейта | Код соответствует ЭМОГССБ-оценке, принципы воплощены |
| `capture` | Проверка capture-candidate | UL, полнота, непротиворечивость с Pack |
| `pack` | Проверка Package-адекватности | Проверяет 11 координат E.4.DPF.DA seed-пакета (Ф1-Ф3 артефакты): SoTA, decision-record, seed-маркер, их достаточность. Используется из `/verify pack` или `pack-creator` Шаг 4 |
| `wp` | Приёмка рабочего продукта | Критерии done из WP context file |
| `chain` | Data flow check | Прочитаны ли downstream consumers? Контракты совпадают? (CoVe stage 3) |
| `adversarial` | Scope & bias check | Scope определён анализом или выводом? Что НЕ прочитано? (Pre-mortem) |
| `subsection` | Проверка подраздела руководства (SS) | 🔴 v4-lint + 🟡 нарратив/дуга/практика/аналогия (G-L) по CHECKLIST-subsection-v1.md |
| `section` | Проверка раздела руководства (S) | 🔴 v4-lint section + 🟡 связность SS, дуга по ступеням, охват темы (D-H) по CHECKLIST-section-v1.md |
| `guide` | Проверка руководства целиком | 🔴 v4-lint guide + 🟡 целостность объекта, дуга, охват узлов мастерства, эпилог (E-I) по CHECKLIST-guide-v1.md |
| `auto` или пусто | Автоопределение | По типу файла и контексту сессии |

**Автоопределение:**
- Был АрхГейт в текущей сессии → `archgate`
- Указан путь к .py/.ts/.sh файлу → `code`
- Указан путь к Pack-сущности → `capture`
- Указан путь к WP context → `wp`
- Изменения >1 файла + cross-component → предложить `chain`
- После АрхГейта + код → предложить `adversarial`
- Путь содержит `subsection_id: PD.GUIDE.N.SX.SSY` во frontmatter, или один файл подраздела руководства → `subsection`
- Путь — папка раздела (`S{N}-*/`) или указан `section_id` во frontmatter → `section`
- Путь — `structure-guide-N.md` или папка руководства целиком → `guide`
- Не определился → спросить пользователя

**Триггеры от пилота:** «проверь подраздел X» / «проверь раздел S{N}» / «проверь руководство N» → соответственно `subsection` / `section` / `guide`.

## Шаг 1. Запустить sub-agent Верификатора

Запустить Agent tool с context isolation:

**Для `code`:**
- Прочитать `git diff` (или указанные файлы)
- Прочитать `CLAUDE.md` затронутого репо
- Передать sub-agent'у: diff + CLAUDE.md + чеклист code
- Модель sub-agent'а: Sonnet

**Для `archgate`:**
- Найти ЭМОГССБ-таблицу из текущей сессии (или запросить)
- Прочитать изменённые файлы реализации
- Прочитать DP.ARCH.001 §7 (21 принцип)
- Передать sub-agent'у: файлы + таблица + принципы + чеклист archgate
- Модель sub-agent'а: Opus

**Для `capture`:**
- Прочитать capture-candidate
- Прочитать manifest целевого Pack
- Передать sub-agent'у: candidate + manifest + чеклист capture
- Модель sub-agent'а: Sonnet

**Для `pack`:**
- Прочитать WP-контекст пакета (WP-474.md или папка пакета)
- Прочитать файлы артефактов Ф1-Ф3:
  - `06-sota/{slug}-sota-sheet.md` (Ф1: SoTA-лист)
  - `.pfad-decision.md` (Ф2: decision record)
  - `01B-distinctions.md` с маркером `**Maturity:** seed` (Ф3: seed-маркер + mature-lite чек-лист)
- Передать sub-agent'у промпт: `verify-pack-adequacy-subsection.md` + данные из контекста
- Модель sub-agent'а: Sonnet
- **Verdict**: `DPFPackageAdequacyStatus` — `admissibleForDeclaredDPFUse` / `seedOnly` / `repairBeforeDPFUse` (авто) + эскалационные `holdForPFADDecision` / `holdForCoreAmendmentDecision` / `refreshNeeded` — по координатам D1-D11, порядковая шкала 0-5 (WP-474 Ф8.1/Ф8.3, пир-сессия 2026-09-05-27)

**Для `wp`:**
- Прочитать WP context file (`{{GOVERNANCE_REPO}}/inbox/WP-{N}-*.md`)
- Прочитать артефакт РП
- Передать sub-agent'у: артефакт + критерии done + чеклист wp
- Модель sub-agent'а: по verification_class

**Для `chain` (CoVe — Chain-of-Verification, Meta ACL 2024):**
- Прочитать `git diff` изменённых файлов
- Для каждого изменённого output: `grep` по codebase — найти все файлы, которые import/require/вызывают изменённые функции
- Прочитать каждый downstream consumer
- Передать sub-agent'у: diff + consumers + чеклист chain
- Модель sub-agent'а: Sonnet
- **Чеклист chain:**
  1. Для каждого изменённого output — кто потребляет?
  2. Прочитан ли каждый потребитель?
  3. Типы/формат output совпадают с ожиданиями потребителя?
  4. Переменные, используемые в предложенном коде — откуда определены? Существуют ли в scope?
  5. Env vars / конфиги, на которые опирается код — определены ли в том же файле или переданы явно?

**Для `adversarial` (Pre-mortem + Devil's Advocate, PROClaim 2026):**
- Прочитать `git diff` изменённых файлов
- Составить список файлов, которые автор НЕ прочитал, но которые могут быть затронуты (`git diff --stat` vs файлы из diff)
- Прочитать описание задачи (из WP context или commit message)
- Передать sub-agent'у: diff + unread files list + task description + чеклист adversarial
- Модель sub-agent'а: Sonnet
- **Чеклист adversarial:**
  1. Scope определён анализом кода или подогнан под заранее выбранный вывод?
  2. Какие файлы/компоненты НЕ прочитаны, но могут быть затронуты?
  3. Предположи, что этот фикс сломается в production. 3 наиболее вероятные причины?
  4. Есть ли альтернативные объяснения проблемы, которые не были рассмотрены?
  5. Заявленный scope («1 файл», «не архгейт», «простой фикс») — соответствует реальному?

**Для `subsection` (один подраздел руководства, WP-322 Ф0.10):**

> Двухэтапная проверка: 🔴 машинная (оркестратор) → 🟡 семантическая (sub-agent). 🟢 пилот не делается агентом.

**Переменные окружения:**
- `IWE_ROOT` — корень рабочей директории (default: `$HOME/IWE`). Используется для путей к Pack и `DS-principles-curriculum`.

**Hotfix-исключение:** если последний коммит содержит `[hotfix]` в message — запускается только 🔴, без 🟡 (см. CHECKLIST-subsection-v1.md §«Правило»).

**Auxiliary-режим:** если frontmatter подраздела содержит `format_version: 4.1-aux` — это auxiliary-подраздел (.08-concepts, .09-exercises, .10-review-questions, .11-section-conclusions). Применяется **упрощённая** проверка: только 🔴 B (минимальный frontmatter: `subsection_id`, `title`, `order`) + 🟡 проверка типа содержимого (concepts = сводка, exercises = практики, review = вопросы, conclusions = выводы). Полный G-L НЕ применяется (auxiliary не вводит понятий, не имеет цепочки мем→метод→мировоззрение).

- **Этап 🔴 (оркестратор, локально):**
  ```bash
  IWE_ROOT="${IWE_ROOT:-$HOME/IWE}"
  cd "$IWE_ROOT/DS-principles-curriculum"
  PACK_FORM_089="$IWE_ROOT/PACK-personal/pack/personal-development/02-domain-entities/formalizations/PD.FORM.089-learner-rcs.md"
  # 1. Структура (A.1-A.11) + контракт Портного (B.1-B.9)
  python3 tools/v4-lint.py porter <subsection.md>
  # 2. Кросс-руководная согласованность
  python3 tools/v4-lint.py cross-guide specs/v4-reference/
  # 3. Pack-drift (cp/bh)
  python3 tools/v4-lint.py pack-drift specs/v4-reference/ --pack "$PACK_FORM_089"
  # 4. Граф понятий
  python3 tools/v4-lint.py graph build specs/v4-reference/ --out-json /tmp/graph.json
  # 5. Блок F (Git-целостность + F.4 формат степеней) — вне v4-lint:
  git -C "$IWE_ROOT/DS-principles-curriculum" status --porcelain specs/v4-reference/   # F.1 чисто
  grep -l "$(basename <subsection.md>)" "$IWE_ROOT/aisystant/docs" 2>/dev/null || \
    echo "F.3 WARN: файл может быть не в правильном репо"
  # F.4 (формат «Степени мастерства» — таблица, не список) проверяется вручную или в 🟡
  ```
  - Любой FAIL → verdict `FAIL` с диагностикой из stderr, sub-agent НЕ запускается
  - Все PASS → перейти к 🟡

- **Этап 🟡 (два специализированных sub-agent, Opus, context isolation) — WP-322 Ф14:**

  > Разделение на два субагента: смешанный промпт снижает качество обеих веток. FPF-агент видит только FPF; педагог-агент видит только педагогику.

  **Пропустить auxiliary:** если `format_version: 4.1-aux` — Этап 🟡 заменяется упрощённой проверкой типа содержимого.

  **Порядок: FPF → педагог** (FPF-нарушения часто блокируют педагогическую оценку).

  **Sub-agent 1 — verify-fpf (промпт: `verify-fpf-subsection.md`):**
  - Вход: файл подраздела
  - Промпт: `.claude/skills/verify/verify-fpf-subsection.md`
  - Модель: Opus
  - Проверяет: G (границы понятий, A.6), H (нарратив мем→метод→мировоззрение), L (Pack-согласованность), border-objects
  - Если FPF-Verdict = FAIL → остановиться, вернуть FAIL автору, Sub-agent 2 не запускать

  **Sub-agent 2 — verify-pedagogy (промпт: `verify-pedagogy-subsection.md`):**
  - Вход: файл подраздела
  - Промпт: `.claude/skills/verify/verify-pedagogy-subsection.md`
  - Модель: Opus
  - Проверяет: I (дуга по ступени, нет дидактических запрещённых слов), J (практика и время), K (аналогия), transfer test

- **Итоговый Verdict (агрегированный):**
  - PASS = FPF-PASS + Педагог-PASS → готов к 🟢 пилот-тесту (вывести шаблон issue `pilot-feedback.yml`)
  - CONDITIONAL = любой CONDITIONAL без FAIL → можно к 🟢 с оговорками
  - FAIL = любой FAIL → диагностика автору с разбивкой по блокам

**Для `section` (раздел руководства S, WP-322 Ф0.10):**

> Предусловие: ВСЕ подразделы раздела уже прошли `verify subsection` (🔴+🟡 PASS). Если нет — остановиться, попросить сначала закрыть SS.

**Hotfix-исключение:** если последний коммит содержит `[hotfix]` в message И затронут только один SS — запускается `verify subsection` для этого SS, без полного `verify section`.

- **Этап 🔴 (оркестратор):**
  ```bash
  IWE_ROOT="${IWE_ROOT:-$HOME/IWE}"
  cd "$IWE_ROOT/DS-principles-curriculum"
  # 1. Структурная полнота раздела (A.1-A.4, B.1-B.3, C.1-C.2)
  python3 tools/v4-lint.py section --id <section-id> specs/v4-reference/
  # 2. Связность prerequisites внутри раздела (отдельная проверка B.1-B.3, дублирует часть section)
  python3 tools/v4-lint.py prerequisites-graph --scope section --id <section-id> specs/v4-reference/
  ```
  - Любой FAIL → verdict `FAIL`
  - PASS → перейти к 🟡

- **Этап 🟡 (sub-agent, Opus, context isolation):**
  - Прочитать: ВСЕ SS раздела (в порядке оглавления) + frontmatter раздела + `CHECKLIST-section-v1.md` §🟡 (D-H)
  - Объём: типично 5-12 SS × 0.5-1.5K слов = 3-20K слов
  - Передать sub-agent'у промпт: все SS подряд + frontmatter + чек-лист §D-H
  - **Модель: Opus** — по эталону `CHECKLIST-section-v1.md` §🟡 («Claude Opus, context isolation»). Sonnet справляется по объёму, но связность нарратива и согласованность метафор раздела требуют глубокого анализа — Opus.
  - **Чеклист D-H (5 блоков по 3-4 пункта):**
    - D. Нарративная связность подразделов (логический переход, нет «висящих» SS, нет повторов)
    - E. Дуга по ступеням внутри раздела (stage_relevant согласован, тональность, сложность нарастает)
    - F. Охват темы (обещанное раскрыто, нет «дыры» в зоне раздела, нет «лишнего»)
    - G. Аналогии в разделе (согласованность сквозных метафор, нет конкурирующих)
    - H. Связь с другими разделами (ссылки корректны, нет противоречий)
  - Sub-agent для каждого пункта: PASS/FAIL + конкретные SS-ссылки

- **Verdict:** PASS = 🔴+🟡 PASS → готов к 🟢 пилот-тесту раздела (≥3 пилота × 6/6). FAIL = диагностика по конкретным SS.

**Для `guide` (руководство целиком, WP-322 Ф0.10):**

> Предусловие: ВСЕ разделы руководства уже прошли `verify section`. Если нет — остановиться.
> Это **самый дорогой** тип проверки — Opus, объём 20-100K слов.

**Hotfix-исключение:** при `[hotfix]` в коммите — только `verify subsection` затронутых файлов; полный `verify guide` не запускается. Полный запуск guide — ежеквартально (content-аудит) или при релизе нового руководства.

- **Этап 🔴 (оркестратор):**
  ```bash
  IWE_ROOT="${IWE_ROOT:-$HOME/IWE}"
  cd "$IWE_ROOT/DS-principles-curriculum"
  PACK_FORM_089="$IWE_ROOT/PACK-personal/pack/personal-development/02-domain-entities/formalizations/PD.FORM.089-learner-rcs.md"
  GUIDE_ID="<guide-id>"   # PD.GUIDE.<N> или N (1-4)
  # 1. Структурная полнота руководства (A.1-A.5, B.1-B.4, C.1-C.3)
  python3 tools/v4-lint.py guide --id "$GUIDE_ID" --pack "$PACK_FORM_089" specs/v4-reference/
  # 2. Кросс-руководная согласованность (внутри guide + между guides)
  python3 tools/v4-lint.py cross-guide --scope guide --id "$GUIDE_ID" specs/v4-reference/
  # 3. Граф понятий руководства
  python3 tools/v4-lint.py graph build --scope guide --id "$GUIDE_ID" --out-json /tmp/guide-graph.json specs/v4-reference/
  # 4. Pack-drift на масштабе руководства (если не прошло через cmd_guide --pack)
  python3 tools/v4-lint.py pack-drift --scope guide --id "$GUIDE_ID" --pack "$PACK_FORM_089" specs/v4-reference/
  ```
  - Любой FAIL → verdict `FAIL`
  - PASS → перейти к 🟡

- **Этап 🟡 (sub-agent, Opus, context isolation):**
  - Прочитать: ВСЕ S/SS руководства + структуру (`structure-guide-N.md`) + README + `CHECKLIST-guide-v1.md` §🟡 (E-I) + frontmatter руководства
  - Объём: типично 4-8 разделов × 5-12 SS × 0.5-1.5K слов = 20-100K слов — нужен Opus с большим контекстом
  - **Стратегия для большого объёма (20-100K слов):**
    - Если объём ≤ 30K слов — передать всё руководство одним промптом Opus с extended thinking
    - Если объём > 30K — батчинг: sub-agent читает разделы по 2-3 за раз, аккумулирует findings, в финале — meta-pass на согласованность дуги (E-I критерии требуют видения всего руководства)
    - Альтернатива: разделить guide-чек-лист на «целостность объекта + дуга» (E, F — требуют целостного видения, один проход) и «охват + связность + эпилог» (G, H, I — можно по частям)
  - Передать sub-agent'у промпт: руководство целиком + структура + чек-лист §E-I
  - Модель: Opus (объём + глубина анализа мировоззренческого сдвига)
  - **Чеклист E-I (5 блоков по 3-4 пункта):**
    - E. Целостность объекта (с первого раздела ясно, не подменяется, границы соблюдены)
    - F. Дуга нарратива (прогрессия 1-2 → 3-5, нет «прыжков», мировоззренческий сдвиг отчётлив, тональность согласована)
    - G. Охват узлов мастерства (cp/bh-измерения покрыты, нет «дыр» по ступеням, bottleneck-узлы помечены)
    - H. Связность с другими руководствами (cross-references, нет дублирования, точки сопряжения объяснены)
    - I. Эпилог и навигация (эпилог есть, связь со ступенями, README с картой)
  - Sub-agent для каждого пункта: PASS/FAIL + конкретные S/SS-ссылки

- **Verdict:** PASS = 🔴+🟡 PASS → готов к 🟢 пилот-тесту руководства (≥3 пилота × 6/6, типично 2-4 недели). FAIL = диагностика по конкретным S/SS.

## Шаг 2. Sub-agent: промпт

Sub-agent получает промпт с заполненными данными из шага 1.

**⛔ Sub-agent НЕ получает:**
- Историю обсуждения текущей сессии
- Задание создателя
- Промежуточные рассуждения

**Для `code`, `capture`, `wp`, `archgate`** — определить эталон:

| Тип артефакта | Эталон |
|---------------|--------|
| Pack-сущность | SPF pack-template + доменные принципы Pack |
| Описание метода | SPF process/07 + Pack |
| Код (DS) | CLAUDE.md репо + Pack-описания сервисов |
| Архитектурное решение | DP.ARCH.001 §7 (→ используй /archgate вместо /verify) |
| План (WeekPlan/DayPlan) | Протоколы Open/Close |
| Подраздел руководства (SS) | `DS-principles-curriculum/specs/v4-reference/CHECKLIST-subsection-v1.md` (v1.2+) |
| Раздел руководства (S) | `DS-principles-curriculum/specs/v4-reference/CHECKLIST-section-v1.md` |
| Руководство целиком | `DS-principles-curriculum/specs/v4-reference/CHECKLIST-guide-v1.md` |

Если эталон не определяется → **СТОП.** Сообщи: «Эталон не найден. Нужен рецензент, не верификатор.»

**Для `chain`, `adversarial`** — эталон = сам код (downstream consumers, scope analysis). Чеклисты встроены в шаг 1.

## Шаг 3. Verdict

До формирования итогового verdict выполнить Extensions `checks`:

```bash
bash .claude/scripts/load-extensions.sh verify checks
```

Код `0` → прочитать и выполнить каждый файл поверх результатов основного
проверяющего. Код `1` → дополнительных проверок нет. Любой другой код или провал
проверки → итог не может быть `PASS`; вернуть `FAIL` с именем расширения и
наблюдаемой причиной.

Sub-agent возвращает verdict:

```
## Verdict: [PASS / FAIL / CONDITIONAL]

**Контекст:** [тип проверки]
**Артефакт:** [что проверялось]
**Эталон:** [по чему проверялось]

### Несоответствия

| # | Severity | Файл | Строка | Что | Почему (reasoning) | Эталон |
|---|----------|------|--------|-----|-------------------|--------|
| 1 | критический / высокий / средний / низкий | path | N | описание | почему проблема | принцип/правило |

### Сводка

- **Критических:** N
- **Высоких:** N
- **Средних:** N
- **Низких:** N

### Рекомендация

[1-3 предложения]
```

**Правила verdict:**
- **PASS:** 0 критических, 0 высоких
- **CONDITIONAL:** 0 критических, ≥1 высоких
- **FAIL:** ≥1 критических

## Шаг 4. Показать пользователю

Вывести verdict. Пользователь решает:
- **Принять** → продолжить работу
- **Исправить** → внести изменения по рекомендациям
- **Отклонить verdict** → аргументировать почему (→ feedback для обучения)

После показа результата выполнить Extensions `after`:

```bash
bash .claude/scripts/load-extensions.sh verify after
```

Код `0` → прочитать и выполнить файлы в алфавитном порядке. Код `1` →
расширений нет. Ошибка `after` не переписывает уже показанный verdict, но
обязательно выводится отдельным предупреждением с именем расширения и причиной.

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

---
name: verify-fpf-subsection
description: FPF-верификатор подраздела руководства. Context isolation. Проверяет концептуальные границы, нарратив мем→метод→мировоззрение и согласованность с Pack.
argument-hint: "<путь к subsection.md>"
---

# FPF-верификация подраздела

> **Роль:** FPF-верификатор (специализированный субагент Ф14, WP-322)
> **Принцип:** Context isolation — проверяю только FPF-качество, не педагогику.
> **НЕ проверяю:** длительность практик, достижимость can-do, тональность для ступени (это verify-pedagogy).

Путь к подразделу: $ARGUMENTS

## Шаг 1. Загрузить материалы

1. Прочитать указанный файл подраздела (frontmatter + тело)
2. Извлечь из frontmatter: `subsection_id`, `introduces`, `uses`, `stage_relevant`, `mastery_node`

## Шаг 2. Проверить блоки G, H, L

Для каждого пункта выдать: **PASS** / **FAIL** + цитата из текста (≤2 строки) + конкретная рекомендация.

### G. Границы понятий (A.6 Boundary Discipline, FPF)

G.1 **Нет смешения уровней.** Одно понятие описывает один уровень абстракции. Например, нельзя одновременно говорить о методе и о его физическом носителе как об одной сущности.

G.2 **Нет тавтологии.** Понятие не определяется через само себя («Метод — это способ методично делать что-то»).

G.3 **Чёткая граница ≠.** Каждое вводимое понятие имеет явное «≠ X, ≠ Y» — что это НЕ есть.

G.4 **Понятия из `introduces` действительно вводятся в тексте** (есть определение или контекст). Не просто упомянуты, а объяснены.

### H. Нарративная цепочка (FPF H-паттерн)

H.1 **Мем → метод → мировоззрение.** Подраздел строится по схеме: (1) показать неэффективный или привычный паттерн мышления (мем), (2) предложить метод как альтернативу, (3) показать, как применение метода меняет картину мира.

H.2 **Нет «повисших» мемов.** Если мем назван, объяснён путь из него. Нет «вот проблема — теперь следующая тема».

H.3 **Блок «Что дальше» или связка в конце.** Подраздел не обрывается — есть мост к следующему или рефлексивный вопрос читателю.

H.4 **Мировоззренческий сдвиг сформулирован** (явно или через вопрос). Читатель должен понять: «после этого подраздела я смотрю на X иначе».

### L. Согласованность с Pack

L.1 **cp.* / bh.* индексы корректны.** Если упомянуты, соответствуют PD.FORM.089 (cp.rhy, cp.wld, cp.skl, cp.iwe, cp.int, cp.agt, bh.sys, bh.inv, bh.awr).

L.2 **Нет противоречий с Pack-определениями.** Понятия из `introduces` и `uses` используются в тексте в том же смысле, что в PACK-personal/ontology.md.

L.3 **`prerequisites` соблюдены по логике.** Если SS ссылается на понятие как известное (`uses`), оно было введено в предыдущих SS (по `prerequisites`).

## Шаг 3. Особая проверка: border-objects

**Border-objects** — понятия, которые легко спутать с понятием из другой дисциплины или Pack. Признак: слово общеупотребительное (метод, система, роль, культура), но в этом руководстве используется в специфическом Pack-смысле.

Проверить: есть ли в тексте border-objects? Если да — введено ли различение явно (хотя бы в одном SS раздела)?

## Шаг 4. Вернуть verdict

```
## FPF-Verdict: [PASS / FAIL / CONDITIONAL]

**Подраздел:** <subsection_id>

### Несоответствия

| # | Блок | Пункт | Severity | Цитата | Проблема | Рекомендация |
|---|------|-------|----------|--------|----------|--------------|

### Сводка

- Критических (G/H/L FAIL): N
- Условных (border-object без различения): N
- Всего замечаний: N

### Вердикт

PASS = 0 критических, 0 высоких.
CONDITIONAL = 0 критических, ≥1 высоких (border-objects).
FAIL = ≥1 критических (G/H/L FAIL).
```

---
name: verify-pack-adequacy-subsection
description: Package-адекватность верификатор по 11 координатам E.4.DPF.DA (порядковая шкала 0-5, статус DPFPackageAdequacyStatus). Context isolation. Проверяет Package-качество пакета и вызывается из /verify с типом `pack` или из pack-creator Шаг 4.
argument-hint: "<путь к pack или wp-контексту пакета>"
---

# Package-адекватность верификация

> **Роль:** Package-верификатор (специализированный субагент WP-474 Ф4, шкала и словарь вердиктов — Ф8.1/Ф8.3, пир-сессия 2026-09-05-27)
> **Принцип:** Context isolation — проверяю только адекватность пакета по 11 координатам спецификации E.4.DPF.DA, не педагогику и не FPF-границы отдельно.
> **Спецификация:** E.4.DPF (Framework for Domain Package Formation), раздел DA (Domain Adequacy) — 11 из 12 координат спецификации (D12 вне объёма этой фазы, см. находку в Шаге 2).

Путь к пакету или контексту: $ARGUMENTS

## Шаг 1. Загрузить материалы

1. Прочитать `00-pack-manifest.md` Pack'а (и WP-контекст, если указан)
2. Извлечь из манифеста:
   - `pack_id` (короткий код) / `pack_name` — идентификаторы пакета
   - `status` (`draft | active | deprecated`) и `name_status` (`provisional | finalized`)
   - `sota_sources` (`none | grounded`)
3. **Определение «пакет-заготовка» (для порога floor, Шаг 2):** Pack считается заготовкой, если манифест содержит `status: draft`. Maturity различений (`**Maturity:** seed` в 01B) — атрибут отдельного различения, НЕ Pack'а; для классификации Pack'а не используется.
4. Проверить наличие файлов-свидетельств (фазы Ф1-Ф3 WP-474):
   - `06-sota/{slug}-sota-sheet.md` (SoTA-лист, Ф1)
   - `.pfad-decision.md` (decision record: таблицы Домен/Имя/Граница/Kind + «Финальный выбор», Ф2+Ф5)
   - `01-domain-contract/01B-distinctions.md` (различения с маркерами `**Maturity:**`, Ф3)
   - `ontology.md` (термины домена, SPF/pack-template)
   - `03-methods/` (карточки методов, D7/D8)
5. **Особое внимание (Ф8.1, 2026-09-05):** для пакета-заготовки ожидаются низкие значения по координатам зрелости (D2, D4, D7, D8, D10 и др.) — это честный результат, а не FAIL. `E.4.DPF.DA:4.2` прямо запрещает заранее выводить координату из оценки («assign the value that the seed earns») — незрелость пакет несёт через порог допуска и статус `seedOnly` (Шаг 2 и Шаг 4), не через предрешённый вердикт координаты.

**Плейсхолдер-конвенция (используется флагами ниже, фиксированная):** значение ячейки/поля считается плейсхолдером, если оно пустое, обёрнуто в `_..._` (курсив шаблона), `{{...}}` или `<...>`, либо равно (case-insensitive) одному из: `...`, `TBD`, `todo`, `—`. Плейсхолдером также считается: (а) отсутствие поля/строки целиком — эквивалентно пустому значению; (б) для дата-полей (`created`, `last_updated`) — буквальный шаблонный дефолт `YYYY-MM-DD` (case-insensitive); (в) для полей с шаблонным перечнем вариантов — буквальный нетронутый текст с разделителем ` | ` (например `draft | active | deprecated`), т.к. это список опций шаблона, не выбранное значение. (Пир-сессия 2026-07-11-13, находка код-ревью: без пп. а-в нетронутый скаффолд-манифест механически проходил как `addressed` в координате D9.)

## Шаг 2. Проверить координаты D1-D11 по порядковой шкале

> **Ф8.1/Ф8.3 (пир-сессия 2026-09-05-27, консенсус с Kimi).** До этой фазы координаты оценивались тремя значениями `addressed(4)/partial(2)/missing(0)`, а шесть координат имели вердикт, прописанный заранее — `missing(seed-expected)`, то есть выводились из оценки до всякого чтения пакета. `E.4.DPF.DA:4.2` это прямо запрещает: «Do not drop a coordinate because the package is "only a seed"; assign the value that the seed earns». Незрелость пакета теперь несёт не пометка у координаты, а порог допуска (ниже) и агрегатный статус `seedOnly` (Шаг 4).

### Шкала (`E.4.DPF.DA:4.1`, дословно)

| Значение | Метка | Смысл |
|---|---|---|
| `0` | `wrongKindOrNoBasis` | Оцениваемого объекта для объявленного применения нет, либо отсутствует требуемое основание. |
| `1` | `namedOnly` | Имя или тема есть, но пакет не может вести доменную или локальную работу. |
| `2` | `partialSeed` | Полезный источник, затравка паттерна или материал есть, но обязательства пакета неполны или хрупки. |
| `3` | `locallyUsableWithVisibleLimits` | Пакет годится для ограниченного исследования или локального применения при явно названных пределах и ремонтах. |
| `4` | `wellGroundedForDeclaredDPFUse` | Пакет связен, заземлён в источниках, зависит от FPF, навигируем и обновляем для объявленного применения. |
| `5` | `exceptionallyGroundedForDeclaredDPFUse` | Пакет воспроизводим по источникам, набору паттернов, записям связей, разнородным случаям, носителям публикации, маршруту улучшения, маршруту обновления и заблокированным перечитываниям. |

**Значение `5` этот верификатор механически не присваивает.** Воспроизводимость по носителям публикации и заблокированным перечитываниям требует свидетельств, которых конвейер `pack-new`/`pack-creator` не производит. `5` ставится только явным разбором автора с приложенными loci; отсутствие `5` в автоматическом прогоне — не дефект пакета.

### Порог допуска (floor)

`E.4.DPF.DA:4.1` дословно: «Default floor is `4` for public, teaching, enterprise, operational, or reliance-bearing DPF use. A fast seed or exploratory prompt output may use floor `3` **only when non-use, missing evidence, and next repair are explicit**».

Порог выводится из объявленного применения, а не из метки статуса самой по себе:

- **floor = 4** — по умолчанию для любого пакета.
- **floor = 3** — только когда выполнены ВСЕ три условия:
  1. манифест несёт `status: draft` (пакет объявлен заготовкой);
  2. в `.pfad-decision.md`, секция «Финальный выбор», строка `**Граница:**` заполнена не-плейсхолдерно И её текст называет не только то, что входит в домен, но и явно — для чего пакет не годится (non-use). Шаблон `pack-new` не заводит отдельного поля под non-use — эта строка единственный носитель обоих смыслов, поэтому проверка контентная, не структурная: одно «домен — Х» без границы применения не считается.
  3. в таблице результата (Шаг 3) у КАЖДОЙ строки ниже порога заполнены обе колонки `EvidenceLocus` и `RepairOrNoProposal` — то есть недостающее свидетельство и следующий ремонт названы явно.

`status: draft` сам по себе порог не понижает (пир-сессия 2026-09-05-27, уточнение Kimi): пониженный порог даётся не за метку «черновик», а за выполненную работу по объяснению, для чего пакет не годится и что чинить следующим. Условие 3 выполняется по построению — колонка `RepairOrNoProposal` обязательна (Шаг 3); реальное авторское обязательство — содержательная строка `**Граница:**` (условие 2).

Зафиксировать в отчёте: `Объявленное применение: <разведочное | операционное>` и `Порог: <3 | 4>` с указанием, какое из трёх условий не выполнено, если порог остался `4` при `status: draft`.

### Общая лестница значений (применяется, если у координаты ниже не сказано иначе)

- `0` — обязательный носитель свидетельства отсутствует целиком
- `1` — носитель есть, но всё его содержимое плейсхолдерное (нетронутый скаффолд)
- `2` — есть реальное содержимое, обязательства координаты выполнены частично
- `3` — содержимого хватает для ограниченного локального применения, пределы названы
- `4` — свидетельство полное для объявленного применения

### Шаблон координаты (для расширения)

Каждая координата описывается одинаково — код, вопрос оценки, носитель свидетельства, лестница `0-4`. Добавление новой координаты = одна такая секция плюс одна строка в таблице Шага 3; переписывать агрегат Шага 4 при этом не требуется.

```
### D{N} — {ИмяКоординаты}
**Вопрос:** {что именно оценивается}
**Носитель свидетельства:** {файл или раздел пакета}
**Лестница:** 4 — … · 3 — … · 2 — … · 1 — … · 0 — …
```

> **Находка, не входящая в эту фазу (пир-сессия 2026-09-05-27).** В текущей редакции `E.4.DPF.DA:4.2` координат **двенадцать**: добавлена `D12DomainProblemFamilyCoverageAdequacy` (покрывает ли текущая редакция обещание публичного поля через выбранные наборы паттернов). Подпасс `:4.3a` тоже вырос — `PFM1`…`PFM12` плюс `PFM1a`, а не `PFM1-PFM11`. Здесь остаются одиннадцать координат: расширение объёма требует отдельного решения пилота (Ф8.2 владеет подпассом формы, D12 — кандидат в отдельную под-фазу). Шаблон выше сделан расширяемым именно под это.

---

### D1 — DomainScopeAndUseAdequacy

**Вопрос:** восстановимы ли доменная ситуация, читатель, объявленное применение и граница неприменения.
**Носитель свидетельства:** `.pfad-decision.md`, секция «Финальный выбор», строка `**Граница:**`, и секция `## Граница` (отвергнутые варианты). Шаблон `pack-new` не заводит отдельного поля non-use — обе стороны (что входит / для чего не годится) оцениваются по содержанию одной строки `**Граница:**`.

**Лестница:**
- `4` — `**Граница:**` заполнена не-плейсхолдерно И текст явно называет как область домена, так и то, для чего пакет не годится
- `3` — `**Граница:**` заполнена не-плейсхолдерно, но называет только область домена, без явного non-use
- `2` — `**Граница:**` пуста, но секция `## Граница` содержит ≥1 отвергнутый вариант с причиной (граница обсуждалась, решение не зафиксировано)
- `1` — файл существует, всё содержимое плейсхолдерное
- `0` — `.pfad-decision.md` отсутствует

**Сценарии использования — по-прежнему вне объёма** (пир-сессия 2026-07-11-13): use-case-уровень не материализуется ни в одном артефакте потока `pack-new`/`pack-creator`. Требовать его для `4` означало бы проверять несуществующий артефакт.

### D2 — DidacticEntryAndAdoptionAdequacy

**Вопрос:** может ли предполагаемый читатель найти первый полезный вход и получить первый рабочий результат без знаний разработчика FPF.
**Носитель свидетельства:** `README.md` пакета, `CLAUDE.md` пакета.

**Лестница:**
- `4` — `README.md` заполнен по существу И называет, для кого пакет и с какого файла начинать работу
- `3` — `README.md` заполнен по существу, но маршрута первого использования нет (читатель понимает, о чём пакет, но не с чего начать)
- `2` — `README.md` заполнен частично (часть разделов плейсхолдерна)
- `1` — `README.md` — нетронутый скаффолд
- `0` — `README.md` отсутствует

### D3 — ScalableFormalityAndAssurancePathAdequacy

**Вопрос:** обозначена ли лестница от обычного локального применения к более строгим записям и свидетельствам.
**Носитель свидетельства:** `01-domain-contract/01B-distinctions.md`, маркеры `**Maturity:**` (конвенция Ф3: отсутствие строки = mature).

**Лестница:**
- `4` — ≥1 различение, maturity определена у каждого, и хотя бы одно различение mature (лестница пройдена, не только объявлена)
- `3` — ≥1 различение, maturity определена у каждого, все seed
- `2` — ≥1 различение, но у части maturity не определить
- `1` — файл существует, различений нет (только шаблон-заготовка)
- `0` — файла нет

### D4 — CoreDependencyAndDomainBoundaryAdequacy

**Вопрос:** опирается ли пакет на понятия ядра, не переопределяя их локально.
**Носитель свидетельства:** `ontology.md` §Domain Glossary, колонка Parent Concept (SPF).

**Лестница:**
- `4` — у всех строк глоссария Parent Concept заполнен, и ни один локальный термин не переопределяет одноимённое понятие SPF base ontology
- `3` — Parent Concept заполнен у части строк
- `2` — глоссарий заполнен, Parent Concept не заполнен нигде
- `1` — `ontology.md` — нетронутый скаффолд
- `0` — `ontology.md` отсутствует

### D5 — PackageFormLayeringAndRelationAdequacy

**Вопрос:** разделены ли форма пакета, его слои и записи связей.
**Носитель свидетельства:** 8 корневых элементов структуры, создаваемой `pack-new` Шаг 4 (НЕ дерева `SPF/pack-template/`): `README.md`, `REPO-TYPE.md`, `CLAUDE.md`, `00-pack-manifest.md`, `ontology.md`, `01-domain-contract/`, `06-sota/` (или `sota_sources: none` в манифесте вместо директории), `07-map/`; плюс содержимое `07-map/`.

**Лестница:**
- `4` — все 8 элементов на месте И `07-map/` содержит не-плейсхолдерную карту связей
- `3` — все 8 элементов на месте, карта связей пуста или шаблонна (форма выдержана, связи не записаны)
- `2` — отсутствует ровно один элемент
- `1` — отсутствует более одного элемента
- `0` — структуры пакета нет

### D6 — DomainLexiconAndKindSettlementAdequacy

**Вопрос:** улажены ли лексикон домена и род (Kind) основного концепта.
**Носитель свидетельства:** `ontology.md` + `01B-distinctions.md` + `.pfad-decision.md` (пир-сессия 2026-07-10-18: PFAD — decision record, дублировать в нём термины из ontology запрещено).

**Три бинарных флага (плейсхолдер-конвенция — Шаг 1):**
- **O** (лексикон, часть 1) = `ontology.md` §Domain Glossary содержит ≥1 строку, в которой ВСЕ ТРИ ячейки — Term (RU/EN), Definition, Parent Concept (SPF) — не-плейсхолдерные
- **D** (лексикон, часть 2) = `01B-distinctions.md` содержит ≥1 различение (заголовок вида `### <код>.D.NNN` или `### {{PACK_ID}}.D.NNN`)
- **S** (settlement) = строка `**Kind:**` в секции «Финальный выбор» `.pfad-decision.md` заполнена не-плейсхолдерным значением. Таблица `## Kind` (отвергнутые альтернативы) свидетельством settlement НЕ является — она может быть заполнена без принятого решения.

**Лестница:**
- `4` — O ∧ D ∧ S
- `3` — ровно два флага из трёх
- `2` — ровно один флаг
- `1` — ни одного флага, но `ontology.md` и `01B-distinctions.md` существуют
- `0` — оба файла отсутствуют

**Отвергнутые термины (не kind) — по-прежнему вне объёма**, осознанно: места для такого реестра в текущем шаблоне нет (`ontology.md` не имеет колонки отклонённых синонимов), её добавление = правка `SPF/pack-template` по процедуре §8.2, отдельное решение.

### D7 — PracticeUtilityAndProblemResolutionAdequacy

**Вопрос:** меняет ли пакет реальное доменное действие — диагностику, проектирование, объяснение, ремонт.
**Носитель свидетельства:** `03-methods/` — карточки методов (шаблон `_method-card-template.md`).

**Лестница:**
- `4` — ≥1 карточка метода, у которой заполнены не-плейсхолдерно Definition, Purpose и Failure Modes (проблема, ход решения и известный способ провалиться названы)
- `3` — ≥1 карточка, часть обязательных секций плейсхолдерна
- `2` — `03-methods/` существует, но содержит только `_method-card-template.md`
- `1` — `03-methods/` существует и пуста
- `0` — `03-methods/` отсутствует

### D8 — HeterogeneousCaseAndTransferAdequacy

**Вопрос:** проверялся ли пакет против достаточно разных случаев домена и ролей читателя.
**Носитель свидетельства:** разобранные случаи применения, где бы они ни лежали — секции примеров в карточках методов, отдельная директория случаев, `01-domain-contract/`.

**Лестница:**
- `4` — ≥2 разных разобранных случая, и видно, где один и тот же набор понятий работает, а где даёт сбой
- `3` — ровно один разобранный случай
- `2` — случаи упомянуты, но не разобраны (перечисление без разбора)
- `1` — упоминаний случаев нет, но содержательное наполнение пакета есть
- `0` — содержимого для оценки нет

### D9 — EditionStateAndCurrentnessAdequacy

**Вопрос:** может ли читатель понять, какой именно редакцией он пользуется и насколько она свежа.
**Носитель свидетельства:** `00-pack-manifest.md`.

**Три бинарных флага (плейсхолдер-конвенция — Шаг 1):**
- **O** (edition) = `version` не-плейсхолдерный
- **E** (currentness) = `last_updated` не-плейсхолдерный
- **S** (state) = `status` не-плейсхолдерный

**Лестница:**
- `4` — O ∧ E ∧ S
- `3` — ровно два флага из трёх
- `2` — ровно один флаг
- `1` — манифест существует, все три плейсхолдерные
- `0` — манифеста нет

### D10 — ImprovementAndRefreshAdequacy

**Вопрос:** может ли пакет улучшаться и обновляться без большого переоткрытия.
**Носитель свидетельства:** `00-pack-manifest.md`, `README.md` — условие возврата к источникам и маршрут устаревания.

**Лестница:**
- `4` — зафиксированы и условие пересмотра (при каком наблюдении возвращаться к источникам), и маршрут устаревания (что происходит с пакетом, когда он устарел)
- `3` — условие пересмотра названо, маршрута устаревания нет
- `2` — обновление упомянуто без проверяемого условия
- `1` — ни условия, ни маршрута, но носители (манифест, README) заполнены
- `0` — носителей нет

### D11 — DomainSoTAAlignmentAdequacy

**Вопрос:** дисциплинирует ли содержание пакета текущее состояние практики домена, или источники приложены как библиография.
**Носитель свидетельства:** `06-sota/{slug}-sota-sheet.md`, манифест `sota_sources`.

**Лестница:**
- `4` — SoTA-лист содержит ≥1 источник с не-плейсхолдерными Claims и Evidence, И в содержании пакета видно влияние источника (различение или карточка метода ссылается на него)
- `3` — ≥1 источник с заполненными Claims и Evidence, влияния на содержание не видно (источник приложен, но ничего не изменил)
- `2` — SoTA-лист существует, Claims или Evidence плейсхолдерны
- `1` — SoTA-листа нет, И манифест несёт `sota_sources: none` (отсутствие источников зафиксировано честно)
- `0` — SoTA-листа нет, А манифест несёт `sota_sources: grounded` (манифест противоречит факту — основание отсутствует)

**Порог `4` здесь пока требует одного источника, не трёх.** `G.2` задаёт `FamilyCoverageFloorK := 3`; сближение с этим требованием — предмет Ф8.5 WP-474, не этой фазы.

## Шаг 3. Построить строку результата

Форма строки задана `E.4.DPF.DA:4.3` — пять колонок, не четыре:

| Координата | Значение | ShortRationale | EvidenceLocus | RepairOrNoProposal |
|---|---|---|---|---|
| `<D1..D11>` | `<0..5>` | почему именно это значение: почему ниже — занизило бы свидетельство, почему выше — завысило | конкретное место: файл, раздел, строка манифеста, отсутствующий locus | ремонт ИЛИ явный отказ от предложения с перечислением проверенных мест |

**`RepairOrNoProposal` обязательна. Пустая ячейка делает строку невалидной** — результат с такой строкой не выдаётся. Допустимы ровно две формы: конкретный ремонт либо явный «предложения нет» с перечислением проверенных мест. Проза вида «см. рекомендации ниже» ремонтом не считается.

**`EvidenceLocus` обязателен и для значения `0`** — там указывается отсутствующий носитель («`03-methods/` не существует»), а не прочерк. `E.4.DPF.DA:4.3` прямо отбрасывает таблицу без evidence loci как «only assessment material».

**Порядок строк — сортировка, не фиксированный список** (пир-сессия 2026-09-05-27, замена правила «критичные координаты»): по возрастанию значения, при равных значениях — по коду координаты по возрастанию (D1 < D2 < … < D11). Сортировка стабильна и детерминирована: сверху то, что чинить первым, и это следует из данных, а не из списка приоритетов, составленного однажды. До этой фазы приоритет несло захардкоженное правило «критичны D1, D7, D11» — оно врало при учебном применении пакета, где D2 (вход читателя) важнее D11.

## Шаг 4. Вернуть статус пакета

Агрегат — `DPFPackageAdequacyStatus` (`E.4.DPF.DA:4.5`), шесть значений вместо прежних `PASS/CONDITIONAL/FAIL`.

Спецификация отдельно ограничивает силу этого статуса: это **локальное утверждение о допустимости для объявленного применения**, а не решение о допуске, состояние публикации, результат гарантии или разрешение на работу. Принимающий процесс использует его только через собственное правило.

### Три статуса присваиваются автоматически (первое совпадение выигрывает)

| Статус | Условие |
|---|---|
| `admissibleForDeclaredDPFUse` | все координаты ≥ порога, граница неприменения и условие переоткрытия названы |
| `seedOnly` | есть координаты ниже порога, И порог фактически опустился до 3 (все три условия floor=3 из Шага 2 выполнены — не только `status: draft`) |
| `repairBeforeDPFUse` | есть координаты ниже порога, И порог остался 4 — либо манифест не несёт `status: draft`, либо несёт, но хотя бы одно из условий floor=3 не выполнено (автор объявил заготовку, но не назвал non-use или не по каждой низкой строке дал `RepairOrNoProposal`) |

`seedOnly` — не провал. `E.4.DPF.DA:5` дословно: «That status is not failure or admission; it is an honest package-use result and next repair route». Заготовка честно получает низкие значения по координатам зрелости и статус `seedOnly`; это и есть ожидаемый результат для свежего пакета, а не признак поломки.

### Три статуса — эскалационные люки, автоматически не присваиваются

Верификатор их не ставит сам, но проверяет условие и, если оно выполнено, добавляет в отчёт строку предупреждения: «Результат склоняется к `<статус>` — требуется решение автора». Решение принимает автор пакета.

| Статус | Условие эскалации | Как проверяется |
|---|---|---|
| `holdForPFADDecision` | ремонт координаты ниже порога трогает архитектуру пакета, а не содержимое файла | в `RepairOrNoProposal` строки D4 или D5 предложен ремонт уровня «переразложить пакет», «поменять набор паттернов», «поменять единицу публикации» |
| `holdForCoreAmendmentDecision` | утверждение пакета может принадлежать ядру и не должно прятаться внутри домена | ремонт требует правки самого FPF или SPF, а не пакета |
| `refreshNeeded` | пакет был адекватен раньше, но с тех пор изменились источник, редакция ядра или пин зависимости | требует **предыдущего результата проверки**, сохранённого в пакете. Такого хранилища у конвейера `pack-new`/`pack-creator` сейчас нет — значит значение структурно недостижимо в автоматическом прогоне и присваивается только автором вручную. Это ограничение, а не дефект проверки |

### Форма отчёта

```
## Package-Adequacy Result

**Пакет:** <pack_id_code> / <slug>
**Объявленное применение:** <разведочное | операционное>
**Порог (floor):** <3 | 4>   <если 4 при status: draft — какое из трёх условий не выполнено>
**Статус:** <admissibleForDeclaredDPFUse | seedOnly | repairBeforeDPFUse>

### Строки результата (по возрастанию значения)

| Координата | Значение | ShortRationale | EvidenceLocus | RepairOrNoProposal |
|---|---|---|---|---|
| (заполнить, отсортировать) | | | | |

### Эскалации

<строки «Результат склоняется к <статус> — требуется решение автора», либо «нет»>

### Ниже порога

<перечень координат со значением < floor, в порядке сортировки>
```

## Шаг 5. Контекстная изоляция

**НЕ проверяю:**
- Педагогическое качество (это verify-pedagogy-subsection)
- FPF-границы понятий (это verify-fpf-subsection)
- Качество кода или инструментов в пакете (это domain-specific review)

**ПРОВЕРЯЮ ТОЛЬКО:**
- Наличие и качество артефактов Ф1-Ф3 (SoTA-лист, decision-record, maturity маркер)
- Соответствие 11 из 12 координат спецификации E.4.DPF.DA (D12 — отдельная под-фаза, см. находку в Шаге 2)
- Честность оценки: заготовка получает честные низкие значения и статус `seedOnly`, а не предрешённый вердикт координаты

---
name: verify-pedagogy-subsection
description: Педагогический верификатор подраздела руководства. Context isolation. Проверяет достижимость can-do, реалистичность практики, тональность для ступени, качество аналогии.
argument-hint: "<путь к subsection.md>"
---

# Педагогическая верификация подраздела

> **Роль:** Педагогический верификатор (специализированный субагент Ф14, WP-322)
> **Принцип:** Context isolation — проверяю только педагогическое качество, не FPF-концептуальные границы.
> **НЕ проверяю:** правильность определений понятий, нарратив мем→метод→мировоззрение, Pack-согласованность (это verify-fpf).

Путь к подразделу: $ARGUMENTS

## Шаг 1. Загрузить материалы

1. Прочитать указанный файл подраздела (frontmatter + тело)
2. Извлечь из frontmatter: `subsection_id`, `stage_relevant`, `mastery_node`, `can_do`, `practice_time_minutes`

## Шаг 2. Проверить блоки I, J, K

Для каждого пункта выдать: **PASS** / **FAIL** + цитата из текста (≤2 строки) + конкретная рекомендация.

### I. Дуга по ступени (stage arc)

I.1 **Тональность соответствует `stage_relevant`.** Ступени 1-2: конкретные образы, короткие предложения, бытовые аналогии, без «механизмов» и «системных закономерностей». Ступени 3-5: горизонт, перенос в новые домены, мета-рефлексия.

I.2 **Сложность нарастает внутри раздела.** Этот подраздел не сложнее следующего по порядку (если есть информация о соседних SS).

I.3 **Нет педагогических запрещённых слов.** Запрещены: «шаг», «урок», «за N дней», «внедри», «сначала/потом», «упражнение», «модуль», «неделя 1», «попробуй это». Проверить наличие в тексте.

I.4 **Нет нотации сценария вместо метода.** Сценарий = конкретная последовательность событий («ты делаешь X, потом Y, потом Z»). Метод = принцип, применимый в разных ситуациях. Если весь подраздел — один сценарий, это FAIL.

### J. Практика и время

J.1 **Can-do из frontmatter наблюдаемы и проверяемы за ≤5 мин.** Формат: «Могу [наблюдаемое действие]». Не «знает», не «понимает», не «осознаёт». Если can_do отсутствует в frontmatter — предупреждение (не критично, если в тексте).

J.2 **`practice_time_minutes` реалистичен для действия.** Если написано «5 мин» — действие за 5 мин выполнимо. Если «15 мин» — в тексте есть ≥3 шага. Примерные нормы: чтение = 2-3 мин/страница; написать черновик = 10-20 мин/300 слов; аудит = 5-15 мин зависит от сложности.

J.3 **Практика привязана к конкретному контексту.** Не «попробуй применить», а «возьми последние 5 рабочих задач и...». Конкретный материал, конкретный момент времени.

J.4 **Есть критерий завершения практики.** Читатель знает, когда остановиться: «если у тебя получилось X» / «запиши три [конкретные вещи]» / «результат — это файл с...».

### K. Аналогия

K.1 **Аналогия есть (или явно не нужна).** Для ступеней 1-3: аналогия обязательна, если понятие абстрактное. Для ступеней 4-5: необязательна.

K.2 **Аналогия работает.** Аналогия объясняет именно то, что трудно понять напрямую. Нет «притянутых» аналогий, которые вводят новую путаницу.

K.3 **Нет смешения уровней в аналогии.** Аналогия из физического мира (автомобиль, строительство, спорт) — не из той же цифровой/интеллектуальной области, что объясняемый концепт (иначе аналогия не помогает новичку).

K.4 **Аналогия НЕ попала в `introduces`.** `introduces` — для понятий, не для иллюстраций. Если аналогия вдруг оказалась в `introduces`, это FAIL I/K.

## Шаг 3. Особая проверка: перенос знания

**Transfer test:** есть ли в тексте задание, требующее применить освоенный метод в НОВОМ домене? Без transfer test — неизвестно, произошло ли обучение или только узнавание.

Если transfer test отсутствует — это предупреждение (не FAIL, если practice достаточно). Если practice тоже минимальная — это высокий severity.

## Шаг 4. Вернуть verdict

```
## Педагог-Verdict: [PASS / FAIL / CONDITIONAL]

**Подраздел:** <subsection_id>

### Несоответствия

| # | Блок | Пункт | Severity | Цитата | Проблема | Рекомендация |
|---|------|-------|----------|--------|----------|--------------|

### Сводка

- Критических (I.3/I.4 дидактика/сценарий): N
- Высоких (J.1 can-do ненаблюдаемо, J.2 время нереалистично): N  
- Средних (K.1-K.4, transfer test): N
- Всего замечаний: N

### Вердикт

PASS = 0 критических, 0 высоких.
CONDITIONAL = 0 критических, ≥1 высоких.
FAIL = ≥1 критических (дидактический язык или сценарий вместо метода).
```