Создание нового РП
Новый рабочий продукт: $ARGUMENTS
When to use
Создание нового рабочего продукта (РП) с атомарной записью в 4 локальных места (+ условный пост-шаг во внешний трекер, если подключён). Используй когда появляется новая задача, которой нет в плане недели.
⛔ БЛОКИРУЮЩЕЕ ПРАВИЛО (Шаг 0): явное согласие пользователя
Создание РП — необратимое действие (запись в 4 локальных места: REGISTRY/WeekPlan/Strategy/context-file; внешний трекер — условный пост-шаг, только при подключённом MCP, issue #321). Откат стоит времени и создаёт шум в системе. Поэтому:
- Сначала проверь: задача может быть выполнена в рамках существующего открытого РП (как новая фаза, под-задача, или продолжение)?
- Открой WeekPlan текущей недели + WP-REGISTRY → найди РП с близким scope.
- Если задача = расширение существующего scope → продолжай в рамках того РП (добавь Phase 2 / новый трек / context-file extension).
- Если новый РП объективно нужен (отдельный lifecycle, отдельный артефакт, не вписывается в существующий):
- Предложи пользователю формулировку: «Это потянет на новый РП #{N}
<title>. Создать?» - Дождись явного "да" / "создавай" / "ок" перед записью в 4 места.
- Запрос здесь legitimate (не нарушение P5 «не задавать вопросы») — создание РП = создание artefact в системе, требует явного buy-in пользователя.
- Предложи пользователю формулировку: «Это потянет на новый РП #{N}
- Запрещено:
- Создавать РП «по аналогии» / «потому что задача похожа на новый scope» / «чтобы зафиксировать план».
- Создавать РП после команды пользователя «сделай план для X» — план может быть документом в рамках существующего РП.
- Создавать РП «на всякий случай» / «для прозрачности».
Это исключение из Правила 1 feedback_behaviour (автономность). Правило 1 запрещает спрашивать разрешения на действия, у которых уже есть достаточный context. Создание РП — нет: оно требует явного buy-in потому что (а) запись в 4 места необратима без отката, (б) влияет на бюджет недели и Strategy mapping, (в) при подключённом внешнем трекере РП добавляется и туда (виден другим).
Журнал нарушений: 26 апр 2026 WP-270 — создал РП после фразы Tseren «давай сделаем новый план миграции» без явного согласия. План был отдельным документом, мог быть Phase 2 в рамках WP-268. Откат: WP-270 cancelled, план перенесён в WP-268 §Phase 2.
Algorithm
Шаг 1. Сбор информации
Запроси или определи:
- Название: формулировка артефакта (не задачи). Обязательный шаг (WP-563): вызвать Skill
artifactorс сырым описанием задачи — не формулировать название самому. Взять полеartifactиз JSON-ответа как кандидат. Ответ{"error": "INSUFFICIENT_INPUT"}→ запросить у пилота более развёрнутое описание, повторить вызов. Название пилоту не показывать, минуя этот вызов. - Репо: целевой репозиторий
- Бюджет: оценка в часах
- Приоритет: критический / высокий / средний / низкий
- Результат месяца: (только для РП ≥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 места:
inbox/WP-{N}/WP-{N}.md→ context file (всегда папка — WP-434, см. INBOX-CONVENTION)docs/WP-REGISTRY.md→ новая строка таблицыcurrent/WeekPlan W{N}…md→ новая строка в таблице РП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 (не вручную):
- Linear issue — вызвать
mcp__claude_ai_linear__save_issue:title: "WP-{N} {Название}",team: "{{LINEAR_TEAM_ID}}"priority: 2(P2 → High), description: краткое описание фаз + путь к context file docs/Strategy.md§ «РП → Результаты» — только для РП ≥3h. Передать--result R{N}скрипту для автовставки; без флага — добавить вручную.
Синтаксис скрипта:
touch "${IWE_ROOT:-$HOME/IWE}/.claude/state/wp-consent-{N}" # WP Gate — обязательно перед запуском (тот же путь, что проверяет create-wp.sh, — НЕ ~/.claude, issue #556)
bash "$IWE_SCRIPTS/create-wp.sh" \
--title "Название РП" \
--budget 5h \
--priority P2 \
--verification-class open-loop \ # обязателен всегда: trivial|closed-loop|open-loop|problem-framing
--state "belonging (Оснащённость): пилот без Х → с Х" \ # обязателен при наличии docs/state-axes-registry.yaml
--hypothesis H-101 \ # для tests/enables/responds
--hypothesis-relation tests \ # tests|enables|responds|researches|operational
--result R3 \ # необязательно; если ≥3h — передать для автовставки в Strategy.md
--repo "DS-repo" # необязательно
Шаблон context file (создаётся скриптом автоматически):
---
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}"
---
# WP-{N}: {название}
## Проблема
## Артефакт
## Связки с РП
## Фазы реализации
## Осталось
Шаг 5. Подтверждение
Выведи: «РП #{N} создан. Скрипт записал в 4 местах: context file, Registry, WeekPlan, active-wp пересобран. Linear — {TSR-NN}.»
Если ≥3h и --result не передан: добавить «+ добавить маппинг в Strategy.md вручную».
# Postcondition check — substitute {N} with the real WP number before running
WP_NUM={N} # real number from Step 2
grep -q "WP-${WP_NUM}" "{{WORKSPACE_DIR}}/{{GOVERNANCE_REPO}}/docs/WP-REGISTRY.md" \
&& echo "✅ WP-${WP_NUM} найден в WP-REGISTRY.md" \
|| echo "❌ WP-${WP_NUM} НЕ найден — проверить вывод create-wp.sh выше"