--- name: wp-new description: Создание нового рабочего продукта (РП) с согласованной записью в 4 локальных места (+ условный пост-шаг во внешний трекер, если подключён). Используй когда появляется новая задача, которой нет в плане недели. argument-hint: "[название РП]" version: 1.0.0 layer: L1 status: active browser_safe: false triggers: slash: [/wp-new] phrases: [] routing: executor: haiku deterministic: false agents: single interaction: multi-step gates_required: [] gates_enforced: [] gates_rationale: "операционный скилл; WP Gate применим только при создании нового РП, не для операционных вызовов" --- # Создание нового РП Новый рабочий продукт: $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} ``. Создать?» - **Дождись явного "да" / "создавай" / "ок"** перед записью в 4 места. - Явное утверждение человеком конкретного списка новых РП на стратегической сессии уже даёт это согласие для перечисленных РП. Не спрашивай повторно, но создай отдельный consent-маркер для каждого номера перед вызовом скрипта; изменение принятого списка требует нового решения. - Запрос здесь legitimate (не нарушение P5 «не задавать вопросы») — **создание РП = создание artefact в системе**, требует явного buy-in пользователя. 3. **Запрещено:** - Создавать РП «по аналогии» / «потому что задача похожа на новый scope» / «чтобы зафиксировать план». - Создавать РП после команды пользователя «сделай план для X» — план может быть документом в рамках существующего РП. - Создавать РП «на всякий случай» / «для прозрачности». **Это исключение из правила автономности** (не спрашивать подтверждения). Правило 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-маркеры. ```bash 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` не должен попасть в публикуемую запись. Перед публикацией проверь также ссылки на карточки. ```bash 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): ```markdown --- 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, в который скрипт записал строку: ```bash 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 -->