Создание нового РП

Новый рабочий продукт: $ARGUMENTS

---

When to use

Создание нового рабочего продукта (РП) с согласованной записью в 4 локальных места (+ условный пост-шаг во внешний трекер, если подключён). Используй когда появляется новая задача, которой нет в плане недели.

⛔ БЛОКИРУЮЩЕЕ ПРАВИЛО (Шаг 0): явное согласие пользователя

Создание РП требует согласия человека (карточка, REGISTRY, WeekPlan, active-wp; Strategy обновляется условно, внешний трекер — отдельный пост-шаг при подключённом MCP, issue #321). Откат стоит времени и создаёт шум в системе. Поэтому:

1. Сначала проверь: задача может быть выполнена в рамках существующего открытого РП (как новая фаза, под-задача, или продолжение)?
   • Открой WeekPlan текущей недели + WP-REGISTRY → найди РП с близким scope.
   • Если задача = расширение существующего scope → продолжай в рамках того РП (добавь Phase 2 / новый трек / context-file extension).
2. Если новый РП объективно нужен (отдельный lifecycle, отдельный артефакт, не вписывается в существующий):
   • Сначала выполни классификацию типа результата и получение имени по Шагу 1; это подготовка, без записи нового РП.
   • Предложи пользователю полученную формулировку: «Это потянет на новый РП #{N} <title>. Создать?»
   • Дождись явного "да" / "создавай" / "ок" перед записью в 4 места.
   • Явное утверждение человеком конкретного списка новых РП на стратегической сессии уже даёт это согласие для перечисленных РП. Не спрашивай повторно, но создай отдельный consent-маркер для каждого номера перед вызовом скрипта; изменение принятого списка требует нового решения.
   • Запрос здесь legitimate (не нарушение P5 «не задавать вопросы») — создание РП = создание artefact в системе, требует явного buy-in пользователя.
3. Запрещено:
   • Создавать РП «по аналогии» / «потому что задача похожа на новый scope» / «чтобы зафиксировать план».
   • Создавать РП после команды пользователя «сделай план для X» — план может быть документом в рамках существующего РП.
   • Создавать РП «на всякий случай» / «для прозрачности».

Это исключение из Правила 1 feedback_behaviour (автономность). Правило 1 запрещает спрашивать разрешения на действия, у которых уже есть достаточный context. Создание РП — нет: оно требует явного buy-in потому что (а) запись в 4 места необратима без отката, (б) влияет на бюджет недели и Strategy mapping, (в) при подключённом внешнем трекере РП добавляется и туда (виден другим).

Журнал нарушений: 26 апр 2026 WP-270 — создал РП после фразы пилота «давай сделаем новый план миграции» без явного согласия. План был отдельным документом, мог быть Phase 2 в рамках WP-268. Откат: WP-270 cancelled, план перенесён в WP-268 §Phase 2.

---

Algorithm

Рабочая копия: если вызывающая стратегическая сессия передала проверенный GOV_WT, на всех шагах читай и дополняй карточки, реестр, WeekPlan и Strategy именно в нём. Не начинай повтор с канонической копии; способ передачи пути в скрипт — шаг 4.

Шаг 1. Сбор информации

Тип результата — до имени и класса (WP-575)

Вызови Skill artifactor с сырым описанием задачи и сохрани его JSON-ответ. Вызов обязателен для любого класса задачи, включая trivial/closed-loop. Сначала прочитай result_type, затем используй artifact для имени и class для верификации. expected_result_kind — отдельная ось, из неё тип результата не выводится.

result_type	Следующее действие
system	Проверь применимость IntegrationGate (.claude/rules-lazy/integration-gate.md): для нового инструмента/агента/скрипта/сервиса зафиксируй обещание → сценарии → роль → реализацию. Для изменения существующей системы укажи её действующие обещание/сценарий/роль и границы изменения; новый паспорт автоматически не создавай.
episteme	Пройди Routing Gate (memory/routing-vocab.md, при неоднозначности — memory/repo-type-rules.md, DP.KR.001 §5) и зафиксируй целевой дом документа/знания. Описание системы — информационный объект, даже если в названии есть «сервис» или «агент».
unresolved, поле отсутствует или содержит другое значение	До имени и регистрации уточни у пилота, что останется результатом: действующая система или информационный объект. Повтори Артефактор с уточнённым запросом; до определённого system/episteme запись нового РП не выполняй. Не подменяй тип по имени, классу верификации или ближайшему expected_result_kind.

Если нужны и система, и её описание, явно различи основной результат и сопроводительные документы; если основной результат не определён — уточни его. Routing Gate применяется также к документам о системе: IntegrationGate его не отменяет. Уже данный пилотом явный ответ о результате используй без повторного вопроса.

Сохрани исходный JSON для передачи в create-wp.sh; не составляй заменяющий JSON вручную. После создания дополни карточку полем result_type из этого же JSON и краткой записью в «Артефакт»: основание классификации, применённый гейт и ссылки на его результат. Скрипт сохраняет контрольную сумму JSON, но пока не переносит result_type автоматически и не проверяет прохождение гейтов — эту запись и проверку выполняет агент.

Свидетельство для system при регистрации. В «Артефакт» укажи применимость IntegrationGate. Для новой системы запиши ссылки на уже готовые обещание, сценарии и роль либо открытые фазы их подготовки; будущие документы не отмечай выполненными. Регистрация карточки не означает прохождения IntegrationGate: реализация начинается только после обязательных шагов 1–3. Для изменения существующей системы без изменения её обещания запиши основание исключения из .claude/rules-lazy/integration-gate.md и ссылку на существующую систему; если обещание меняется — сначала актуализируй обещание, сценарии и роль.

Смена результата после регистрации. Если пилот явно меняет результат (например, вместо системы заказывает только её описание), повтори Артефактор с новым заданием и заново примени соответствующий гейт до продолжения. Сохрани исходный JSON и исходное artifactor_result_sha256; в «Артефакт» добавь решение пилота, прежний и новый тип, ссылку и контрольную сумму нового JSON, новый маршрут. Поле result_type обнови по новому результату классификации. Если агент лишь обнаружил расхождение между планом и исполнением, сообщи пилоту; это не разрешение самостоятельно менять результат РП или переписывать исходное свидетельство.

Запроси или определи:

• Название: формулировка артефакта (не задачи) из сохранённого ответа Артефактора выше — не формулировать название самому (WP-563, WP-7 Ф142). Сохранённый файл (например $STATE_DIR/artifactor-result-{slug}.json) передаётся в create-wp.sh на Шаге 4: скрипт берёт title из его поля artifact и отказывает, если файла нет или переданный отдельно --title с ним расходится (Артефактор-гейт, см. Шаг 4). Ответ INSUFFICIENT_INPUT или {"error": "INSUFFICIENT_INPUT"} → запросить более развёрнутое описание и повторить вызов. Название пилоту не показывать, минуя классификацию типа результата.
• Правка пилота. Пилот вправе поправить формулировку Артефактора сам — тогда на Шаге 4 передать --pilot-revision "причина" вместе с исправленным --title; без этого флага расхождение --title с результатом Артефактора — отказ скрипта, не тихая подмена.
• Репо: целевой репозиторий
• Бюджет: оценка в часах
• Приоритет: критический / высокий / средний / низкий
• Результат месяца: (только для РП ≥3h) к какому результату месяца (R1, R2, …) привязан? Допустимые ответы: R{N}, поддержка, off-plan. Source-of-truth маппинга: ${IWE_GOVERNANCE_REPO:-DS-strategy}/docs/Strategy.md → «РП → Результаты»
• Критерий готовности: что должно получиться
• Ставка — переход состояния (WP-457, WP-505): ось из docs/state-axes-registry.yaml (только gate_ready: permission/Доверие, belonging/Оснащённость, engagement/Увлечённость, mastery/Компетентность) + формулировка «из → в» одной строкой; субъект перехода — пользователь платформы / пилот / команда. Обязательно, если файл реестра осей существует — скрипт заблокирует создание без --state. Файла нет (типовая установка) → пропустить.
• Связь с гипотезой: выбрать до запуска РП: tests H-NNN, enables H-NNN, responds H-NNN, researches или operational. Первые три требуют ровно одну гипотезу; два последних — явное «—». Значение unclassified допустимо только при создании обратимой заготовки и блокирует начало работы.

Шаг 2. Нумерация

Найди последний номер РП в docs/WP-REGISTRY.md → следующий порядковый номер. Только целые числа (74, 75…). Буквенные суффиксы (73a, 73b) запрещены.

Шаг 3. Проверка бюджета

Прочитай текущий бюджет недели из WeekPlan. Предупреди если превышение.

Шаг 4. Запись — запустить $IWE_SCRIPTS/create-wp.sh

Все шаги ниже автоматизированы скриптом $IWE_SCRIPTS/create-wp.sh. Скрипт пишет в 4 места:

1. inbox/WP-{N}/WP-{N}.md → context file (всегда папка — WP-434, см. INBOX-CONVENTION)
2. docs/WP-REGISTRY.md → новая строка таблицы
3. current/WeekPlan W{N}…md → новая строка в таблице РП
4. current/active-wp.md → пересобирается автоматически (build-active-wp.py)

issue #280: до этого фикса скрипт дополнительно создавал заготовку archive/wp-contexts/WP-{N}-{slug}.md (§Закрытия stub). Эта заготовка больше не создаётся при регистрации — close-wp.sh сам создаёт файл заново при закрытии РП, канонический путь git mv из protocol-close.md не конфликтует с существующим файлом. Пустые заготовки, найденные в archive/wp-contexts/ с датой до этого фикса, — след старого поведения, не действующая норма.

После скрипта — агент дополняет карточку и вызывает MCP:

• Карточка РП — добавить result_type: system|episteme из сохранённого JSON и свидетельство маршрутизации по Шагу 1 до подтверждения создания.
• Linear issue — вызвать mcp__claude_ai_linear__save_issue: title: "WP-{N} {Название}", team: "{{LINEAR_TEAM_ID}}" <!-- L3-author: teamId was here, replaced with {{LINEAR_TEAM_ID}} --> priority: 2 (P2 → High), description: краткое описание фаз + путь к context file
• docs/Strategy.md § «РП → Результаты» — только для РП ≥3h. Передать --result R{N} скрипту для автовставки; без флага — добавить вручную.

Синтаксис скрипта:

При вызове из стратегической сессии используй уже проверенный GOV_WT. Простого cd недостаточно: скрипт выбирает governance через IWE_ROOT/IWE_GOVERNANCE_REPO. В той же оболочке перед вызовом ниже вычисли путь к копии; передавай его только этому вызову. IWE_ROOT оставь корнем установки: там общие номера и consent-маркеры.

WP_GOVERNANCE_REPO="${IWE_GOVERNANCE_REPO:-DS-strategy}"
if [ -n "${GOV_WT:-}" ]; then
  WP_GOVERNANCE_REPO=$(python3 -c 'import os,sys; print(os.path.relpath(os.path.realpath(sys.argv[2]), os.path.realpath(sys.argv[1])))' "${IWE_ROOT:-$HOME/IWE}" "$GOV_WT") || exit 1
  [ -d "${IWE_ROOT:-$HOME/IWE}/$WP_GOVERNANCE_REPO" ] || { echo "ERROR: governance-копия недоступна" >&2; exit 1; }
fi

Входные данные, проверки и последующее дополнение карточки тоже относятся к GOV_WT, если он задан; --repo этот адрес не меняет. Для каждого нового РП проверь предполагаемый следующий номер с учётом общего счётчика .claude/state/wp-numbers, затем создай consent-маркер. При гонке нумерации и отказе гейта перечитай фактическое состояние и перенеси согласие только на тот же одобренный кандидат; не отключай проверку.

В изолированной копии --repo обязателен: передай согласованное стабильное имя репозитория результата (если результат хранится в governance — его постоянное имя). Без него скрипт подставляет IWE_GOVERNANCE_REPO в колонку «Репо» реестра; временный путь GOV_WT не должен попасть в публикуемую запись. Перед публикацией проверь также ссылки на карточки.

touch "${IWE_ROOT:-$HOME/IWE}/.claude/state/wp-consent-{N}"   # WP Gate — обязательно перед запуском (тот же путь, что проверяет create-wp.sh, — НЕ ~/.claude, issue #556)
IWE_GOVERNANCE_REPO="$WP_GOVERNANCE_REPO" bash "$IWE_SCRIPTS/create-wp.sh" \
  --artifactor-result "$STATE_DIR/artifactor-result-{slug}.json" \
  --budget 5h \
  --priority P2 \
  --verification-class open-loop \
  --state "belonging (Оснащённость): пилот без Х → с Х" \
  --hypothesis H-101 \
  --hypothesis-relation tests \
  --result R3 \
  --repo "DS-repo"

В примере подставь согласованные данные. --artifactor-result и --verification-class обязательны всегда; --state — когда применим гейт состояния. --hypothesis нужен для tests/enables/responds; остальные допустимые связи — researches/operational. --result нужен для автовставки связи с результатом месяца при бюджете ≥3h. Только при правке названия самим пилотом добавь --pilot-revision "причина" и --title "Название".

Артефактор-гейт (WP-7 Ф142, 2026-09-11) — механический, не только инструкция. create-wp.sh отказывает (exit 1), если --artifactor-result не передан (кроме явного --no-artifactor-check — только для тестов/скриптов, никогда для обычного создания РП агентом) или если JSON нечитаем / без поля artifact. Title всегда берётся из этого файла; отдельно переданный --title, расходящийся с ним без --pilot-revision, — тоже отказ. Это закрывает дыру, которую нашла пир-сессия 2026-09-11-04-wp7-f140-artifactor-process: раньше ничто не проверяло, что агент реально использовал результат вызова, а не вписал своё.

Шаблон context file (создаётся скриптом автоматически; result_type и свидетельство маршрутизации дописывает агент по Шагу 1):

---
wp: {N}
title: {название}
status: pending
priority: {P1-P5}
budget: {Nh}
created: {YYYY-MM-DD}
last_session: {YYYY-MM-DD}
related: []
verification_class: {trivial|closed-loop|open-loop|problem-framing}
state_transition: "{ось (Русское имя): из → в}"
hypothesis: "{H-NNN или —}"
hypothesis_relation: "{tests|enables|responds|researches|operational}"
artifactor_resolution_path: {keyword|llm|bypassed}
artifactor_result_sha256: {sha256 результата Артефактора}
result_type: {system|episteme}
---

# WP-{N}: {название}

## Проблема
## Артефакт
## Связки с РП
## Фазы реализации
## Осталось

Шаг 5. Подтверждение

До сообщения об успехе проверь в той же рабочей копии (GOV_WT, если задан): карточка по фактическому пути из вывода скрипта существует; её поле wp совпадает с отдельной ячейкой номера в ровно одной строке реестра и WeekPlan; название совпадает; active-wp пересобран. Число 1, WP-1 и WP-001 обозначают один номер, WP-10 — другой. Поиск подстроки не подтверждает эту проверку. Проверь отсутствие временных путей рабочей копии в колонке «Репо» и ссылках.

Проверку выполняет скрипт: ненулевой код означает неполную регистрацию, успех не объявлять. Передай номер, каталог governance и WeekPlan, в который скрипт записал строку:

WEEKPLAN_PATH="<путь WeekPlan, в который скрипт записал строку>"   # задай явно
: "${WEEKPLAN_PATH:?путь WeekPlan не задан}"
bash "$IWE_SCRIPTS/check-wp-registered.sh" "{N}" "${GOV_WT:-${IWE_ROOT:-$HOME/IWE}/${IWE_GOVERNANCE_REPO:-DS-strategy}}" "$WEEKPLAN_PATH" || { echo "регистрация не согласована" >&2; false; }

При пропущенной записи не подтверждай создание: сохрани уже записанное, сообщи конкретную неполноту и восстанови регистрацию с тем же номером. Для стратегической сессии действуют также проверка повторного вызова и итоговая синхронизация MEMORY из раздела «Регистрация РП перед утверждением» скилла strategy-session.

После проверки выведи: «РП #{N} создан: карточка, реестр, WeekPlan и active-wp согласованы.» Результат внешнего трекера добавляй только если он подключён и запись подтверждена. Если ≥3h и --result не передан, укажи необходимость дополнить связь с результатом месяца в Strategy.md.

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