v1.0.0 to v1.0.0

9 added, 2 removed. Audit A to A.

---

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): явное согласие пользователя

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

1. **Сначала проверь:** задача может быть выполнена в рамках **существующего открытого РП** (как новая фаза, под-задача, или продолжение)?

- Открой WeekPlan текущей недели + WP-REGISTRY → найди РП с близким scope.

- Если задача = расширение существующего scope → **продолжай в рамках того РП** (добавь Phase 2 / новый трек / context-file extension).

2. **Если новый РП объективно нужен** (отдельный lifecycle, отдельный артефакт, не вписывается в существующий):

- **Предложи** пользователю формулировку: «Это потянет на новый РП #{N} `<title>`. Создать?»

- **Дождись явного "да" / "создавай" / "ок"** перед записью в 4 места.

- Запрос здесь legitimate (не нарушение P5 «не задавать вопросы») — **создание РП = создание artefact в системе**, требует явного buy-in пользователя.

3. **Запрещено:**

- Создавать РП «по аналогии» / «потому что задача похожа на новый 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"}` → запросить у пилота более развёрнутое описание, повторить вызов. Название пилоту не показывать, минуя этот вызов.

+ - **Название:** формулировка артефакта (не задачи). **Обязательный шаг для ЛЮБОГО класса задачи, без исключений (WP-563, ужесточено WP-7 Ф142 2026-09-11 — go-ahead пилота: trivial/closed-loop НЕ освобождены от вызова):** вызвать Skill `artifactor` с сырым описанием задачи — не формулировать название самому. Сохранить JSON-ответ в файл (например `$STATE_DIR/artifactor-result-{slug}.json`) — этот файл передаётся в `create-wp.sh` на Шаге 4, скрипт сам берёт `title` из его поля `artifact` и механически откажет, если файла нет или переданный отдельно `--title` с ним расходится (Артефактор-гейт, см. Шаг 4). Ответ `{"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 (не вручную):**

- **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}` скрипту для автовставки; без флага — добавить вручную.

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

```bash

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 "Название РП" \

+ --artifactor-result "$STATE_DIR/artifactor-result-{slug}.json" \ # результат Шага 1, обязателен всегда

--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" # необязательно

+ # --pilot-revision "причина" \ # только если пилот сам поправил формулировку Артефактора

+ # --title "Название" \ # тот же класс случая — только вместе с --pilot-revision

```

+ **Артефактор-гейт (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** (создаётся скриптом автоматически):

```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 результата Артефактора}

---

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

## Проблема

## Артефакт

## Связки с РП

## Фазы реализации

## Осталось

```

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

Выведи: *«РП #{N} создан. Скрипт записал в 4 местах: context file, Registry, WeekPlan, active-wp пересобран. Linear — {TSR-NN}.»*

Если ≥3h и `--result` не передан: добавить «+ добавить маппинг в Strategy.md вручную».

```bash

# 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 выше"

```