/apply-captures — разбор кандидатов экстрактора

Полная ВДВ-карта цикла: ${IWE_GOVERNANCE_REPO:-DS-strategy}/inbox/WP-247-ke-pipeline-vdv.md Контракт скилла взят из шагов 5, 6, 6.5, 7 этой карты.

When to use

Scope

Этот скилл делает:

• Читает ${IWE_GOVERNANCE_REPO:-DS-strategy}/inbox/extraction-reports/*.md со status: pending-review или status: deferred.
• Для каждого кандидата в отчёте — запрашивает решение R15 (accept / reject / defer).
• Accept → опциональная редактура → валидация → запись файла в Pack → обновление MAP → коммит.
• Reject → запись причины + паттерна в feedback-log.md.
• Defer → запись причины + defer_until в отчёт.
• Обновляет status отчёта на applied / partially-applied / rejected / deferred.

Этот скилл НЕ делает:

• Не запускает агента R2 (экстрактор) — это /ke и launchd extractor.sh.
• Не создаёт extraction-reports — это R2.
• Не редактирует содержимое captures.md / fleeting-notes.md.

ВДВ-контракт (шаги 5–7 из ke-pipeline-vdv.md)

Вход:   ${IWE_GOVERNANCE_REPO:-DS-strategy}/inbox/extraction-reports/*.md  со  status: pending-review
Роль:   R15 Валидатор (accept/reject/defer)
        R4 Автор (conditional: редактура при edits_needed: yes)
        Скилл (автоматика записи, валидации, коммита)
Действие:
  Для каждого pending-review отчёта, для каждого кандидата:
    1. Показать кандидата (id, тип, предложенный target_path, текст).
    2. Запросить решение R15 по схеме ниже.
    3. Accept + edits_needed=yes → R4 редактирует текст.
    4. Шаг 6.5: валидация Pack-сущности (frontmatter, уникальность ID, путь).
    5. Accept + valid → записать файл в Pack, обновить MAP, дописать feedback-log (паттерн), коммит.
    6. Reject → записать в feedback-log причину + паттерн.
    7. Defer → записать defer_reason + defer_until в отчёт.
  Обновить status отчёта по итогам.
Выход:
  - Обновлённый Pack (новые файлы сущностей).
  - Обновлённый ${IWE_GOVERNANCE_REPO:-DS-strategy}/inbox/feedback-log.md (reject-паттерны).
  - Отчёт со финальным status (applied / partially-applied / rejected / deferred).
  - Коммит в PACK-* (при accept).

Algorithm

R15 = живой пилот, не агент (БЛОКИРУЮЩЕЕ, peer-session 2026-07-07-03)

Инвариант: решение accept/reject/defer по каждому кандидату принимает человек, управляющий текущей сессией — не другой агент, не сам исполняющий скилл агент, не автоматически принятый вердикт R2 (экстрактора). Это не рекомендация — источник: DP.ROLE.001 (держатель роли R15 — пользователь), DP.SC.040 («финальное утверждение — за человеком... полная автоматизация не работает», со ссылкой на SOTA-провал automated rule generation, accuracy <10%).

Запрещено:

• Подменять решение пилота консенсусом двух агентов внутри пир-сессии (peer-conversation/kimi-peer-writer) — согласие Kimi и Claude между собой НЕ есть решение R15, независимо от качества их аргументации.
• Автоматически принимать вердикт R2 («Вердикт: accept» в отчёте) как решение R15 без факта вопроса живому пилоту — даже когда обоснование R2 выглядит убедительно.
• Присваивать агенту роль R15-* в meta.yaml/frontmatter сессии — роль R15 не переносится на агента ни при каких обстоятельствах.

Если apply-captures вызван внутри пир-сессии (оба участника — агенты): пир-сессия может готовить кандидатов, проверять дубли/семантику/размещение, спорить о деталях — но на этом шаге обязана остановиться и передать вопрос пилоту напрямую, в текущем интерактивном чате с ним (не через turn-файл диалога с другим агентом), прежде чем зафиксировать решение по любому кандидату.

Найдено при аудите (2026-07-07): минимум 4 исторические сессии (2026-05-24-apply-captures-bulk-review, 2026-06-11-02-ke-candidates-review-pack, 2026-06-26-14-apply-captures-r15, 2026-06-28-09-peer-apply-captures-dp) зафиксировали решения по 90+ кандидатам целиком внутри диалога Kimi↔Claude, без единой реплики пилота. Полный разбор → ${IWE_GOVERNANCE_REPO:-DS-strategy}/inbox/bugs/bug-2026-07-07-r15-decisions-bypassed-pilot.md.

Формат решения R15

Каждый кандидат — структурированное решение:

candidate_id: 3
decision: accept        # accept | reject | defer
decision_source: pilot   # ОБЯЗАТЕЛЬНО — единственное валидное значение. Заполняется только по факту прямого вопроса пилоту (см. блок выше).
# --- при accept ---
edits_needed: no        # yes | no
target_path: PACK-digital-platform/pack/.../02-domain-entities/DP.D.NNN.md
# --- при reject ---
reason: "дубликат PD.METHOD.006"
pattern: "проверять существующие METHOD перед предложением нового"
# --- при defer ---
reason: "ждёт ArchGate WP-245"
defer_until: "после WP-245 Ф22"     # ОБЯЗАТЕЛЬНО — дата YYYY-MM-DD или событие

Инвариант decision_source (peer-session 2026-07-07-03): decision_source: pilot — обязательное поле при ЛЮБОМ решении (accept/reject/defer). Отсутствует или указано иное значение → решение invalid, Шаг 5 (запись в Pack) обязан отказать и вернуть кандидата на Шаг 2.

Инвариант defer (peer-session 2026-05-31-22): defer_until — обязательное поле при decision: defer. Без него решение invalid. Reason: deferred без defer_until = masked cancel (см. memory/lessons_defer_with_explicit_triggers.md). Формат: дата YYYY-MM-DD ИЛИ привязка к событию («после WP-NNN Ф{N}», «при следующем Week Close»).

Шаг 1. Найти незавершённые отчёты

GOV_DIR="$HOME/IWE/${IWE_GOVERNANCE_REPO:-DS-strategy}"
bash "$GOV_DIR/scripts/ke-queue-stats.sh" --reports-dir "$GOV_DIR/inbox/extraction-reports" --list

Если $ARGUMENTS задан путь — работать только с ним. Читатель ничего не изменяет и не обращается к Git или сети. Он одинаково учитывает pending/pending-review, partially-applied и deferred, отдельно показывает decide (решить), deliver (доставить), wait (ждать условия). Ноль только в первой категории не означает пустую очередь. Ошибка YAML, неизвестный статус, недоступный каталог и неподтверждённые исторические статусы дают диагностику и ненулевой код, а не сообщение об успешной пустой очереди.

Если открытых отчётов нет и диагностики нет → сообщить «Незавершённых отчётов нет». В изолированном рабочем дереве явно указывать его --reports-dir, чтобы не обратиться к общей копии. Прежние решения сохранять: продолжать нерешённые пункты или доставку уже принятого, не запрашивать те же решения снова.

Шаг 2. Для каждого отчёта: показать кандидатов

Прочитать отчёт. Для каждого кандидата (frontmatter + тело) показать пилоту напрямую в текущем чате:

• id, type, предложенный target_path
• Первые 15-20 строк текста (без служебного frontmatter)
• Флаг edits_needed из отчёта (если проставлен R2)

Запросить решение R15 у пилота — реальным вопросом в текущей интерактивной сессии (AskUserQuestion при работе через Claude Code, обычное сообщение в чате при другом интерфейсе). Один вопрос = один кандидат, ЛИБО (при большом количестве однотипных пред-одобренных R2 кандидатов) одна сводка на весь отчёт с явным перечислением каждого — пилот подтверждает/отклоняет по номерам. В любом случае ответ должен исходить от пилота, не быть выведен агентом из контекста разговора с другим агентом.

Шаг 3. Accept — редактура (conditional)

Если edits_needed: yes → предложить отредактировать текст совместно с пользователем. Если edits_needed: no → использовать текст as-is из отчёта.

Шаг 4 (= ВДВ шаг 6.5). Валидация Pack-сущности

Перед записью проверить три условия:

4а. Frontmatter по шаблону Pack

Обязательные поля (для большинства Pack-сущностей):

• id: — присутствует и соответствует типу (DP.D.NNN, PD.METHOD.NNN и т.д.)
• type: — присутствует
• status: — присутствует (обычно draft или active)
• created: — присутствует

Источник шаблонов: DP.ROLE.033 и соседние сущности целевой директории.

4а.1. Метод-специфичная проверка (WP-448 Ф12, decision Б): если target_path → 03-methods/ (кандидат *.M.NNN/*.METHOD.NNN) — текст кандидата обязан содержать заполненные ## Forces (≥1 полюс↔полюс, не плейсхолдер) и ## Bias-Annotation (≥1 названное смещение+направление, не плейсхолдер). Не основание для reject — вернуть на Шаг 3 (edits_needed: yes) для дозаполнения R4, затем повторить проверку. Действует только для новых карточек этого пайплайна, не для миграции backlog.

4б. Уникальность ID

ID из отчёта предварительный, резервирования не означает. Перед записью выбрать свободный ID в свежем опубликованном снимке целевого Pack по routing.yaml. Если ID уже занят другим содержанием, сохранить содержательное решение пилота accept, назначить свободный ID и согласованно обновить имя файла, frontmatter, ссылки и связь candidate_id → target_path. Коллизия номера сама по себе не основание для reject. Содержательный дубль проверить по Шагу 4г и решению пилота.

Перед публикацией, в том числе после переноса коммита, повторить проверку на свежей целевой ветке. Новая коллизия требует повторного назначения ID и проверки ссылок; чужую карточку не перезаписывать. Критерий приёмки: два параллельных писателя сохраняют обе разные карточки с разными итоговыми ID. Это контракт применения; наличие этого текста не доказывает машинную атомарность выделения ID.

4в-0. Фасетный классификатор (WP-429 Ф6.4)

Когда применяется: до Шага 4в, для кандидатов, у которых target_path не задан R2 однозначно (домен/полка неочевидны) — либо всегда как проверка предложенного R2 пути. Пропустить, если R2 уже дал target_path, совпадающий с производной полкой Шага 4в ниже.

Четыре явных вопроса R15 (или самопроверка агента перед вопросом пилоту, если ответ выводим детерминированно):

1. Уровень FPF. Base (ZP/FP/SP) / Pack (доменное знание) / DS (реализация) / LPF (личное)? Определяет репо-класс.
2. Артефактная роль. AR (правило) / DRR (решение) / lesson (занятие) / protocol (ритуал) / service-clause (обещание) / доменная сущность (D/METHOD/ROLE/FM/SOTA/…)? Определяет kind-код.
3. Домен. Какой Pack? Использовать тот же вызов knowledge_search, что и Шаг 0 выше (intra-batch) / kNN-подсказка домена: knowledge_search(query=<name>+<первые 400 символов текста>, limit=5) → агрегировать репо соседей. Confidence band обязателен (weak/moderate/strong/none — калибровка на реальном golden-set дала repo-level precision ~75%, ниже 80%; это advisory tie-breaker, не финальный ответ): при weak/none — спросить R15 напрямую, не решать за него.
4. Полка. Производная (1)+(2)+(3) по routing.yaml целевого Pack — см. Шаг 4в ниже, не отдельное суждение.

Результат — предложенный target_path, который Шаг 4в валидирует машинно.

4в. Расположение файла

SoT — routing.yaml целевого Pack (WP-429 Ф6.1): <PACK-repo>/pack/<domain>/routing.yaml → kinds.<KIND>.dir даёт каноническую директорию для kind-кода кандидата (DP.D, PD.METHOD, VR.M и т.д.). Прочитать файл, найти секцию по префиксу ID кандидата:

grep -A3 "^  <KIND>:" ~/IWE/<PACK-repo>/pack/<domain>/routing.yaml

dir: → каноническая директория. id_pattern: → проверить соответствие имени файла. frontmatter_check: (если не null) → соответствующее поле/значение должно быть в кандидате.

Fallback (Pack без routing.yaml ещё не покрыт контрактом): старое эвристическое правило —

• DP.D.* → .../02-domain-entities/
• DP.METHOD.* → .../03-methods/
• DP.ROLE.* → .../02-domain-entities/ или .../roles/
• DP.SOTA.* → .../06-sota/
• PD.* → аналогичная структура в PACK-personal/ или другом Pack-репо домена

При сомнении (оба пути) — проверить соседние файлы в целевой директории.

Результат валидации:

• valid → переходить к Шагу 4г
• invalid + причина → reject этого кандидата, записать в feedback-log, продолжить следующий кандидат

4г. Семантическая проверка (содержательная непротиворечивость)

Шаг 0 — pairwise intra-batch (WP-376 CC-120, решение пилота 2026-07-16, вариант А). Индекс/база Pack на момент проверки ещё не содержит соседей из ТЕКУЩЕГО отчёта — сравнение с базой (Шаг 1-2 ниже) слепо к дублям внутри одного батча кандидатов. Перед Шагом 1: для каждого кандидата отчёта с decision: accept сравнить его с остальными accept-кандидатами ТОГО ЖЕ типа (DP.D.* vs DP.D.*, PD.METHOD.* vs PD.METHOD.* и т.д.) из этого же отчёта:

• Сопоставить name/name_ru + первые 3 предложения тела каждой пары.
• Вердикт по паре: duplicate | related | unrelated (шкала как в Шаге 2 ниже).
• duplicate → предупредить R15: «кандидаты и этого отчёта дублируют друг друга» → R15 выбирает reject одного / accept обоих с взаимным see_also. Пропустить, если в отчёте меньше двух accept-кандидатов одного типа.

Перед записью проверить содержательную совместимость кандидата с соседними Pack-сущностями того же типа:

Шаг 1 — прочитать ±5 соседних ID того же типа в целевой директории:

ls <target_dir>/ | sort | grep -A5 -B5 "<ID-slug>"

Для каждого соседнего файла: прочитать summary: или первые 3 строки тела — проверить на пересечение.

Шаг 2 — grep ключевых существительных. Взять 2-3 ключевых существительных из имени кандидата. Искать в целевом Pack-репо:

grep -ri "<ключевое_слово>" ~/IWE/<PACK-repo>/pack/ --include="*.md" -l | head -10

Если найдено совпадение: прочитать файл. Проверить:

• Перекрытие: кандидат описывает то же самое другими словами → reject (дубликат), паттерн для R2.
• Противоречие: кандидат утверждает обратное существующему → выяснить, какой новее/точнее; если новый кандидат вытесняет старый — accept + пометить в отчёте supersedes: <ID>.
• Уточнение: кандидат добавляет деталь без конфликта → accept, добавить see_also: [<ID>] в frontmatter.

Результат 4г:

• clear → переходить к Шагу 4д
• overlap → reject; паттерн + ссылка на существующий ID в feedback-log
• contradiction → выявить новейший; при accept добавить supersedes:
• refinement → accept + see_also: в frontmatter кандидата
• intra-batch duplicate (Шаг 0) → решение R15 по паре; выживший кандидат продолжает с Шага 1

4д. Semantic Gate — WP-429 Контур A (write-time soft gate)

Когда применяется: кандидат с decision: accept и тип DP.* (DP.D., DP.ROLE., DP.SC., DP.METHOD.) или PD.* в PACK-digital-platform или PACK-personal. Soft gate: не блокирует — информирует R15. R15 принимает финальное решение. Когда пропускается: decision: reject / defer, или тип не Pack-сущность (скрипт, шаблон, docs).

Шаг 1 — семантический поиск соседей (inline, без внешнего скрипта):

Вызвать MCP-инструмент knowledge_search с текстом кандидата:

knowledge_search(query=<первые 400 символов текста кандидата>, limit=5)

Отфильтровать из результатов: только сущности с ID типа DP.* или PD.* (game концепты, не гайды). Взять top-3 с наибольшей близостью.

Шаг 2 — inline LLM-оценка каждой пары (кандидат × сосед):

Для каждого из top-3 соседей вынести суждение:

• Кандидат: <name> — <первые 500 символов текста>
• Сосед: <neighbor_id> «<neighbor_name>» — <первые 500 символов>
• Вердикт: duplicate | contradiction | related | unrelated

Критерии (из detector.py):

• duplicate — оба описывают то же понятие с тем же смыслом; держать оба = путаница
• contradiction — несовместимые утверждения об одном понятии
• related — связаны, но явно различны; конфликта нет
• unrelated — разные темы

Шаг 3 — результат gate:

Вердикт	Действие
Все related/unrelated	clear → перейти к Шагу 5
Найден duplicate	Предупредить R15 (формат ниже)
Найдено contradiction	Предупредить R15 (формат ниже)
partial	Предупредить R15 «судья недоступен, ручная проверка или повтор»

Формат предупреждения R15:

⚠️  Semantic Gate (WP-429 Контур A): возможный <дубль/противоречие>
Кандидат: <id/name>
Конфликт с: <neighbor_id> «<neighbor_name>»
Оценка: <verdict> (уверенность ~<confidence>%)
Причина: <reasoning>

Варианты:
  А. Reject кандидата → паттерн в feedback-log: «дубль <neighbor_id>»
  Б. Accept как уточнение → добавить `see_also: [<neighbor_id>]` в frontmatter
  В. Accept как замена → добавить `supersedes: <neighbor_id>` + пометить старый как superseded
R15 выбирает вариант:

Дождаться ответа R15. Обновить decision и frontmatter кандидата согласно выбору.

Если knowledge_search недоступен (MCP offline, ошибка сети):

• Пометить в отчёте: semantic_gate: skipped (MCP unavailable)
• Перейти к Шагу 5 без блокировки.

CLI-эквивалент (для batch/автоматизации):

cd ~/IWE/${IWE_GOVERNANCE_REPO:-DS-strategy}
OPENROUTER_API_KEY="sk-or-v1-..." WP429_DB_ID=3 WP429_TABLE=concept_graph.concepts \
  python3 inbox/WP-429/f2-poc/detector.py --check-candidate \
    --name "<имя кандидата>" \
    --text "<текст кандидата>"

Шаг 5. Запись в Pack и коммит

Gate перед записью (БЛОКИРУЮЩЕЕ): проверить, что решение кандидата имеет decision_source: pilot. Нет поля или значение иное → СТОП, вернуться к Шагу 2 и получить решение от пилота напрямую. Записывать в Pack можно только решения с подтверждённым decision_source: pilot.

5а. Записать файл

Write target_path (из решения R15) ← текст кандидата (после редактуры если была)

5б. Обновить MAP (если есть)

Pack-реестры обычно в:

• PACK-digital-platform/pack/.../MAP.md
• hard-distinctions.md — при добавлении DP.D.*

Проверить, есть ли MAP в целевой директории. Добавить строку.

5в. Записать в feedback-log (при reject)

Файл: ${IWE_GOVERNANCE_REPO:-DS-strategy}/inbox/feedback-log.md (создать если нет). Формат записи:

## <дата> — reject кандидата <id> из отчёта <filename>
**Причина:** <reason>
**Паттерн (для R2):** <pattern>

5г. Коммит

git add <target_path> [MAP если был] && git commit -m "feat(KE apply): <id> — <краткое название>" -- <target_path> [MAP если был]

Репо для коммита: то же, что target_path (PACK-digital-platform, PACK-personal и т.д.)

Шаг 6. Обновить status отчёта

Решение пилота и доказанная доставка — разные факты (WP-170/WP-569). Добавить в конец выбранного отчёта раздел ## R15 decisions с одним YAML-блоком. Номер candidate_id — исходный номер кандидата этого отчёта, независимо от нового ID в Pack. Общие decided_at (ISO timestamp с часовым поясом) и decision_session наследуются записями; запись может уточнить их своими значениями.

## R15 decisions

```yaml
decided_at: "2026-09-12T23:00:00+03:00"
decision_session: "<идентификатор сессии с решением пилота>"
decisions:
  - candidate_id: 1
    decision: accept
    decision_source: pilot
    action: merge  # необязательно; объединение с существующей карточкой
    target_path: PACK-digital-platform/pack/digital-platform/03-methods/<файл>.md
    publication:
      repo: PACK-digital-platform
      branch: main
      commit: "<полный SHA реально опубликованного коммита>"
      blob: "<git blob OID точных байтов целевого файла в этом коммите>"
  - candidate_id: 2
    decision: reject
    decision_source: pilot
    reason: "<причина>"
  - candidate_id: 3
    decision: defer
    decision_source: pilot
    reason: "<причина>"
    defer_until: "2099-01-01"
```

До публикации publication у принятого кандидата отсутствует. После штатного шлюза (scripts/lib/publish-gate.sh / scripts/ds-publish.sh) записать конечный SHA, а не SHA до переноса коммита, и blob из git rev-parse <SHA>:<путь-в-репо>. Проверяющий сверяет реальный tip origin указанной ветки через ls-remote, достижимость SHA и точный blob commit:target_path. Он не делает fetch, commit или push; если объект свежей удалённой вершины ещё отсутствует локально, сначала выполнить штатное безопасное обновление копии. Наличие только файла, локальной main, неподтверждённого SHA или старого Reports-Closed не закрывает доставку.

Все явные разделы ## R15 decisions читаются последовательно: более поздний переопределяет только перечисленных кандидатов, остальные прежние решения сохраняются. Они имеют приоритет над историческими inline YAML. Примеры внутри ограждённого Markdown не являются решениями. Историю не удалять. Обычный «Вердикт» экстрактора не является решением пилота. Старые повествовательные R15-итоги и терминальные статусы без нового доказательства сохраняются с диагностикой; не достраивать за пилота отсутствующие решения и публикации.

Условие	Статус
Решений ещё нет	pending-review (pending читается совместимо)
Осталось решить или доставить, включая все accept при нуле публикаций	partially-applied
Все оставшиеся вопросы отложены с причиной и триггером	deferred
Незавершённых нет, хотя бы один accept подтверждён опубликованными байтами	applied
Всё отклонено пилотом, причины сохранены	rejected

defer всегда остаётся незавершённым. Дата возвращает кандидата в decide при наступлении срока; естественно-языковое событие требует проверенного факта или подтверждения пилота, записанного как defer_trigger_confirmed: true. Одно предположение агента не даёт права ставить это поле. Без defer_until решение невалидно и кандидат остаётся в decide. Сбой повторной проверки remote сохраняет ранее подтверждённый терминальный статус с reconciliation_stale: true.

Статус и служебную проекцию меняет только реконсилер, адресно по выбранному отчёту:

bash "$GOV_DIR/scripts/ke-report-reconcile.sh" --reports-dir "$GOV_DIR/inbox/extraction-reports" --report "<имя отчёта>.md" --dry-run
bash "$GOV_DIR/scripts/ke-report-reconcile.sh" --reports-dir "$GOV_DIR/inbox/extraction-reports" --report "<имя отчёта>.md"

--report можно повторить. Запись всей очереди требует отдельного явного --all; вызов без области записи отказывает. --dry-run ничего не записывает. Вывод JSON содержит незавершённые номера и диагностические причины; код 1 означает, что подтверждение неполно, даже если нетерминальная проекция успешно сохранена. Просмотреть фактический diff выбранных отчётов, добавить точные файлы в commit и опубликовать через тот же шлюз. Проекция на диске сама по себе не означает доставку её другим читателям. Для запуска требуются Python 3 и PyYAML из requirements.txt шаблона.

Шаг 7. Итоговый отчёт

Вывести сводку:

Отчёт: <filename>
  Кандидатов всего: N
  Accept: N_a (записано в Pack)
  Reject: N_r (паттерны в feedback-log)
  Defer: N_d
  Статус отчёта: applied / partially-applied / rejected / deferred

Appendix

Состояния отчёта (справка)

Статус	Очистка Session-Prep
pending-review	Не трогать
partially-applied	Не трогать
deferred	Не трогать
applied	Удалять через 7 дней
rejected	Удалять через 7 дней
no-pending	Удалять через 7 дней

Интеграция в рабочий процесс

DayPlan (ежедневный обзор): Шаблон DayPlan содержит секцию «Наработки ИИ → Экстрактор» с обзором:

• N pending-review отчётов
• Дата самого старого отчёта
• SLA-статус (✅ в норме / ⚠️ истёк)
• Напоминание: разбор в отдельной сессии /apply-captures

Close Gate: extensions/protocol-close.checks.md — при N > 0 pending-review выдаёт предупреждение ⚠️ и SLA-напоминание (DP.SC.004 §Hard gate). Soft gate — не блокирует Close, но требует решения ≤24ч.

Полный цикл:

1. Cron / extractor.sh → создаёт extraction-reports/*.md (status: pending-review)
2. Day Open → секция «Наработки ИИ → Экстрактор» в DayPlan показывает N ожидающих
3. Close → protocol-close.checks.md напоминает о SLA
4. Пользователь запускает /apply-captures в отдельной сессии → R15 разбор → запись в Pack