Pack New

---
name: pack-new
description: "Create a new Pack — guided flow through SPF: choose domain, name Pack, scaffold structure, fill roadmap."
argument-hint: "[область знания или домен]"
realized_by:
  - DP.SC.048
---

# Pack New — создание нового Pack

Создаём Pack для домена: $ARGUMENTS

## Что делает этот скилл

- Проверяет наличие Base-репо (FPF, SPF) и клонирует при отсутствии
- Проводит через SPF §01 (выбор домена)
- Проверяет узнаваемость домена/имени на одном внешнем источнике (SoTA-Sheet-lite)
- Предлагает provisional-имя Pack по критериям SPF, фиксирует отклонённые варианты (PFAD-lite) и финализирует имя после первых различений
- Уточняет bounded context (SPF §02)
- Создаёт структуру директорий и стартовые файлы из SPF/pack-template
- Показывает дорожную карту наполнения с оценками времени

## Что НЕ делает

- Не заполняет Pack содержанием, кроме стартового SoTA Sheet из Шага 1.5 (см. Шаг 4) — остальное это `/ke` + ручная работа по SPF §03-11
- GitHub-репо предлагает создать командой, не делает автоматически

---

## Шаг 0. Проверка Base-репо (FPF + SPF)

Проверить существование `SPF/` и `FPF/` в рабочей директории IWE.

Если отсутствуют — сообщить пользователю и предложить команды:

```bash
cd ~/IWE
gh repo clone TserenTserenov/SPF SPF -- --depth=1   # если нет SPF/
gh repo clone ailev/FPF FPF -- --depth=1             # если нет FPF/
```

Если репо есть — зафиксировать путь к `SPF/pack-template/` для шага 4.

Зафиксировать также РП, в контексте которого запущен `/pack-new` (из активной сессии — WP Gate уже должен быть пройден до вызова этого скилла per Pack Creation Gate). Если Pack создаётся вне контекста РП — зафиксировать `wp: —`. Нужно для `wp:` в frontmatter `.pfad-decision.md` на Шаге 4.

---

## Шаг 1. Домен ≠ Тема (SPF §01)

> Задать пользователю **не более 3 вопросов** (все сразу, одним сообщением):

1. **Кто практикует этот домен?** (специальность, профессия, конкретная роль)
2. **Что они производят?** (артефакты, рабочие продукты — конкретные документы, системы, решения)
3. **Как типично ошибаются?** (3-5 failure modes — что идёт не так в этой практике)

**Если ответ — «интересуюсь темой X»**, объяснить различение:
> Тема = область интереса (нет собственных методов и артефактов).
> Домен = практика с методами, рабочими продуктами и failure modes.
>
> Тест: «Есть ли люди, которые ДЕЛАЮТ это профессионально? Что они производят?»
>
> Примеры: «машинное обучение» — тема. «Разработка ML-систем» — домен (есть: ML-инженеры, модели, метрики качества, failure modes). «Системное мышление» — тема. «Системный анализ» — домен.

Если пользователь затрудняется — помочь найти практиков и артефакты через уточняющие вопросы (до 2 дополнительных).

---

## Шаг 1.5. Источники домена (SoTA-Sheet-lite)

> Источник принципа: FPF `E.4.DPF` (source pack — шаг 2 из 11, до драфта паттернов) + `G.2` облегчённый вариант («1-page SoTA Sheet», informative). Полный `G.2` (CorpusLedger/ClaimSheets/BridgeMatrix) избыточен для личного Pack.

Прежде чем выбирать имя (Шаг 2), быстро проверить: как эту практику называют и описывают сами практики — не по памяти агента, а по одному внешнему источнику.

Задать пользователю (или найти самостоятельно, если пользователь не эксперт):
1. **Один авторитетный источник этой практики** — книга, метод, школа, стандарт (не блог)
2. **2-4 тезиса оттуда**, которые стоит унести в Pack
3. **Чем подтверждено** — цитата/страница/раздел

Это не полноценный research pass — цель узкая: проверить, что домен и будущее имя (Шаг 2) не оторваны от реальной практики. Опционально, если время есть: границы применимости источника (validity region), что явно отклонено, когда источник устареет (freshness).

Если пользователь говорит «источника под рукой нет» — не блокировать, идти дальше. Зафиксировать это явно на Шаге 4 (`sota_sources: none` в манифесте), не молчать.

**Точка сверки:** после Шага 3 (bounded context) — проверить, не изменилась ли граница домена настолько, что источник и тезисы нужно дополнить.

---

## Шаг 2. Provisional-имя Pack (SPF §01 §4)

Имя Pack = **существительное, узнаваемое практикам** домена.

**Критерии (все обязательны):**
- Специфично: исключает соседние домены (не «управление», а «управление продуктом»)
- Широко: включает ядро методов, не только один инструмент
- Узнаваемо: практик домена сразу понимает, о чём это
- Slug: латиница, kebab-case, ≤30 символов

**Предложить 2-3 варианта** с пояснением, затем дать выбор пользователю.

Формат: `PACK-{pack_id_slug}` (например: `PACK-product-management`, `PACK-system-analysis`, `PACK-digital-marketing`).

Эталоны из IWE: `PACK-digital-platform`, `PACK-education`, `PACK-personal`, `PACK-verification`.

**Антипримеры:**
- `PACK-everything` — слишком широко
- `PACK-jira` — инструмент, а не домен
- `PACK-notes` — нет практики и артефактов

**Короткий код (`pack_id_code`, WP-474 Ф3-фикс).** Отдельно от `pack_id_slug` (kebab-case, для имени директории) — короткий мнемо-код из 2-4 заглавных латинских букв, используемый как префикс в кодах сущностей (`{{PACK_ID}}.D.NNN` → например `DP.D.NNN`). Это два разных идентификатора — не путать: полные существующие Pack используют именно короткий код в этой роли (`PACK-digital-platform` → код `DP`), а не полный slug.

Алгоритм предложения кода: взять значимые слова slug'а (без предлогов/связок) → если домен однословный — первые 2-4 буквы (`education` → `EDU`); если из нескольких слов — по первой букве каждого значимого слова, заглавными (`product-management` → `PM`; `digital-platform` → `DP`). Предложить так полученный вариант + один альтернативный (например, первые буквы первого слова + первая буква второго, если инициалы дают <2 значимых слов) — дать пилоту выбрать/поправить. Если предложенный код уже занят (антипример ниже) — не переспрашивать пилота вслепую, а сразу предложить следующий по алгоритму вариант (например, добавить третью букву) и только если варианты исчерпаны — спросить пилота напрямую. Код тоже provisional — финализируется вместе со slug (см. «Финализация имени» ниже).

**Антипримеры кода:**
- Совпадение с уже существующим кодом другого Pack в IWE — проверить ПЕРЕД фиксацией: `find ~/IWE -maxdepth 4 -path "*/PACK-*/00-pack-manifest.md" -o -path "*/PACK-*/pack/*/00-pack-manifest.md" | xargs grep -l "^pack_id: <код>$" 2>/dev/null` (Pack бывают и плоские — `PACK-X/00-pack-manifest.md`, и вложенные — `PACK-X/pack/X/00-pack-manifest.md`, одна ветка `find` не покрывает оба варианта)
- Код длиннее 4 символов — теряет компактность в составных ID (`DIGPLAT.D.001` вместо `DP.D.001`)

**Провизорность (PFAD-lite, источник — FPF `E.4.PFAD`/`F.18`).** Выбранное здесь имя (slug + код) — **не финальное**. Директория `PACK-{pack_id_slug}/` создаётся сразу под этим slug'ом (Шаг 4), но:
- в `00-pack-manifest.md` проставляется `name_status: provisional`;
- отклонённые варианты домена/имени/границы фиксируются в `.pfad-decision.md` (Шаг 4) с причиной отказа — decision-record, аналог ADR, живёт внутри Pack, путешествует вместе с ним при переносе/переименовании;
- различения, добавленные в `01B-distinctions.md` до финализации (Ф1 дорожной карты, Шаг 5), получают заголовок `### {{PACK_ID}}.D.NNN: <Название>` — `{{PACK_ID}}` здесь placeholder, заменяется на финализации на короткий код (`pack_id_code`), НЕ на `pack_id_slug`;
- финализация имени — отдельный шаг после накопления материала (см. ниже), не автоматический переход.

Пока идёт обсуждение (этот шаг и, если понадобится, Шаг 3) — вести черновой список отклонённых вариантов домена/имени/границы с причиной отказа (просто в рабочем контексте диалога). Этот черновик переносится в таблицы `.pfad-decision.md` на Шаге 4 — если сессия прервётся между Шагом 2 и Шагом 4, отклонённые варианты не должны потеряться.

### Финализация имени

Срабатывает по одному из двух триггеров (зафиксировать какой — в `.pfad-decision.md` поле `finalization_trigger`):
- **`pilot-requested`** — пользователь сам просит закрепить имя, в любой момент.
- **`agent-proposed-after-N-distinctions`** — агент предлагает финализацию после того, как в `01B-distinctions.md` появилось **минимум 3 различения** (не раньше — одного-двух недостаточно, чтобы оценить, ложится ли имя на содержание).

Два независимых идентификатора финализируются вместе, но переименовываются по-разному: `pack_id_slug` (kebab-case) — переименование ДИРЕКТОРИИ через `git mv`; `pack_id_code` (короткий мнемо-код) — замена ПЛЕЙСХОЛДЕРА `{{PACK_ID}}` в контенте различений. Не путать: `{new_slug}` в шагах ниже — это НЕ то же самое, что заменяет `{{PACK_ID}}`.

Пути в `provisional_distinction_files` хранятся **относительно корня Pack** (например `01-domain-contract/01B-distinctions.md`, без префикса `PACK-{slug}/`) — резолвить их в реальный файловый путь всегда через ТЕКУЩЕЕ имя директории Pack на момент операции. Поэтому после `git mv` (шаг 2 ниже) пути из списка уже корректны без отдельной правки — искать нужно по `PACK-{new_slug}/<путь-из-списка>`.

Порядок действий:
1. Пользователь подтверждает текущие `pack_candidate`/`pack_id_slug`/`pack_id_code` или называет новые (независимо друг от друга — slug мог остаться, а код поменяться, и наоборот).
2. Если `pack_id_slug` изменился: проверить, что `PACK-{new_slug}/` ещё не существует (`git mv` в уже существующую директорию перенесёт файлы ВНУТРЬ неё вместо переименования) — при коллизии остановиться и попросить пилота другой slug. Иначе выполнить `git mv PACK-{old_slug} PACK-{new_slug}`.
3. Если `pack_id_code` изменился или впервые фиксируется: проверить отсутствие коллизии с кодом другого Pack в IWE (см. антипример кода на Шаге 2). При коллизии — остановиться, попросить другой код.
4. По каждому пути из `provisional_distinction_files`, резолвя его как `PACK-{new_slug}/<путь>` (см. выше): посчитать вхождения `{{PACK_ID}}` ДО замены (`grep -c '{{PACK_ID}}' <файл>` = N), затем заменить все вхождения `{{PACK_ID}}` → `{new_code}` (короткий код, НЕ slug) в заголовках различений.
5. Проверить факт замены: `grep -c '{{PACK_ID}}' <файл>` после замены должен быть `0`, а число заголовков `### {new_code}.D.NNN` в файле должно равняться N. Расхождение (остались `{{PACK_ID}}` или число новых заголовков ≠ N) — не коммитить, показать диф пользователю.
6. Обновить все места, где материализованы имена: `pack_id` (= `{new_code}`) и `pack_name` в `00-pack-manifest.md`; если `pack_id_slug` изменился — заголовок `# PACK-{new_slug}` в `CLAUDE.md` Pack'а, поля `pack_id_slug`/`pack_candidate`/`pack_id_code` в `.pfad-decision.md`, переименовать `06-sota/{old_slug}-sota-sheet.md` → `06-sota/{new_slug}-sota-sheet.md` (если файл существует), переименовать `.iwe-runtime/state/spf/{old_slug}.yaml` → `.iwe-runtime/state/spf/{new_slug}.yaml` (если существует — `/pack-creator` уже запускался, WP-474 Ф3; иначе он не найдёт прогресс при следующем запуске и молча начнёт с Шага 0). Если на Шаге 4 был создан GitHub-репозиторий под старым slug'ом — сообщить пилоту, что его нужно переименовать отдельно (`gh repo rename`), скилл это не делает автоматически.
7. Очистить `provisional_distinction_files`, проставить `name_status: finalized` в манифесте **и** `status: finalized` в frontmatter `.pfad-decision.md`, дозаполнить секцию «Финальный выбор» в `.pfad-decision.md` (`decided_by`, `proposed_by`; если строка `**Kind:**` осталась незаполненной с Шага 3 — задать вопрос о Kind сейчас и заполнить). Бэкстоп лексикона: если `ontology.md` §2 Domain Glossary остался плейсхолдерным (термины Шага 3 не перенесены) — заполнить сейчас.
8. Закоммитить изменённые файлы (конкретным списком путей, не `git add -A`) — сообщением вида `feat: finalize Pack name → PACK-{new_slug} (код {new_code})`.

---

## Шаг 3. Bounded Context (SPF §02)

Заполнить три поля вместе с пользователем:

| Поле | Содержание |
|------|-----------|
| Что входит | 3-5 ключевых методов и практик домена |
| Что не входит | Соседние домены (граница) |
| Ключевые термины | 5-7 терминов, специфичных для домена (UL) |

Итог → запишется в `01-domain-contract/01A-bounded-context.md`

**Материализация терминов (WP-474 Ф5, флаг O координаты D6).** Ключевые термины из таблицы выше записываются НЕ только в 01A: каждый термин — строкой в `ontology.md` §2 Domain Glossary (Term RU/EN, Definition в 1-2 предложения, Parent Concept из SPF base ontology — см. `SPF/pack-template/ontology.md §1`). Без этого `/verify pack` честно покажет лексикон незаполненным — 01A verify не читает.

**Kind основного концепта (WP-474 Ф5, флаг S координаты D6).** Здесь же задать вопрос: «Какой базовый род сущности (Kind) у основного концепта домена — `U.Method` (способ действия), `U.System` (носитель), `U.Episteme` (знание), другой из SPF base ontology?» Обсуждённые и отклонённые варианты — в таблицу `## Kind` `.pfad-decision.md` (Шаг 4); принятое решение — строкой `**Kind:**` в «Финальном выборе» сразу, ждать финализации имени не нужно.

Точка сверки источника (Шаг 1.5): если граница домена здесь заметно изменилась — вернуться и дополнить SoTA Sheet перед Шагом 4.

---

## Шаг 4. Scaffold структуры

`{slug}` далее везде = `{pack_id_slug}`, выбранный на Шаге 2.

Создать `~/IWE/PACK-{slug}/` со следующей структурой:

```
PACK-{slug}/
├── README.md                      ← название + одно предложение о домене
├── REPO-TYPE.md                   ← тип: Pack, upstream: FPF + SPF
├── CLAUDE.md                      ← инструкции для агента в этом Pack
├── .pfad-decision.md              ← PFAD-lite: отклонённые варианты домена/имени/границы (Шаг 2)
├── 00-pack-manifest.md            ← метаданные + entity index
├── ontology.md                    ← термины домена (UL)
├── 01-domain-contract/
│   ├── 01A-bounded-context.md     ← из Шага 3
│   └── 01B-distinctions.md        ← ключевые различения (заготовка)
├── 02-domain-entities/            ← сущности: роли, методы, WP
├── 03-methods/                    ← методы практики
├── 04-work-products/              ← рабочие продукты
├── 05-failure-modes/              ← типичные ошибки
├── 06-sota/
│   └── {slug}-sota-sheet.md       ← из Шага 1.5 (если источник был)
└── 07-map/                        ← карта домена
```

**Заполнить стартовые файлы:**

`README.md` — одна строка описания домена.

`REPO-TYPE.md`:
```markdown
# Тип репозитория

**Тип**: `Pack`
**Source-of-truth**: yes

## Область
{название домена и что покрывает}

## Upstream dependencies
- [TserenTserenov/SPF](https://github.com/TserenTserenov/SPF) — Second Principles Framework
- [ailev/FPF](https://github.com/ailev/FPF) — First Principles Framework

## Non-goals
- НЕ содержит кода и конфигураций (→ DS)
- НЕ содержит планов и реестров (→ DS/governance)
```

`CLAUDE.md` — минимальный, содержит:
```markdown
# PACK-{slug}

Source-of-truth для домена: {название}.
Структура: SPF/pack-template. Upstream: FPF, SPF.

При работе с этим Pack: читать 00-pack-manifest.md для навигации.

Пока `name_status: provisional` в манифесте: каждое новое различение в `01-domain-contract/01B-distinctions.md` получает заголовок `### {{PACK_ID}}.D.NNN: <Название>` (плейсхолдер `{{PACK_ID}}`, не реальный код Pack'а), а путь `01-domain-contract/01B-distinctions.md` добавляется в `provisional_distinction_files` в `.pfad-decision.md` (если его там ещё нет — не дублировать). Если в `01B-distinctions.md` набралось 3+ различений — предложить пользователю финализацию имени (см. `pack-new/SKILL.md` Шаг 2 «Финализация имени» в FMT-exocortex-template).
```

`01-domain-contract/01A-bounded-context.md` — из Шага 3.

`01-domain-contract/01B-distinctions.md` — шаблон (заголовок на различение, согласовано с реальным форматом действующих Pack, например `PACK-digital-platform` — таблица из предыдущей версии этого шаблона не соответствовала ни используемому ниже заголовочному формату provisional-плейсхолдера, ни фактическому формату действующих Pack; исправлено при WP-474 Ф3. `SPF/pack-template/01-domain-contract/01B-distinctions.md` использует другую нотацию — `### [D.001] Название` без префикса кода Pack — расхождение upstream-шаблона с практикой отмечено отдельно, не устранено этой правкой):
```markdown
# Ключевые различения {домена}

> Источник: FPF A.7 (Strict Distinction)
> Критерий: если два термина часто путают — это различение.

### {{PACK_ID}}.D.001: <Название>

**Определение A:** ...
**Определение B:** ...
**Тест:** ...
```

Пока `name_status: provisional` (см. Шаг 2) — каждое добавленное различение оформляется заголовком `### {{PACK_ID}}.D.NNN: <Название>` (не реальным кодом Pack'а), а путь `01-domain-contract/01B-distinctions.md` добавляется в `provisional_distinction_files` в `.pfad-decision.md` (если пути там ещё нет — не дублировать при повторных различениях в том же файле). После финализации имени (Шаг 2 «Финализация») `{{PACK_ID}}` заменяется на короткий код (`pack_id_code`) — НЕ на slug — одним проверяемым шагом.

**Seed/mature (WP-474 Ф3, пир-сессия 2026-07-09-14-seed-mature-spf-state).** Каждое новое различение по умолчанию — черновик (seed). Помечать строкой сразу под заголовком, не суффиксом в самом заголовке (суффикс в заголовке ломает стабильность markdown-якорей при переходе seed→mature — ссылки из других файлов на `#packid-d-001-название-seed` разорвутся, когда метка уйдёт). Поле называется `**Maturity:**`, не `**Status:**` — в существующих Pack-карточках `**Status:**` уже занято под SoTA-статус (`current`/`deprecated`/`hypothesis`, другая ось), совпадение имени поля создало бы путаницу для любого будущего инструмента, который ищет `Status` по Pack:

```markdown
### {{PACK_ID}}.D.001: <Название>
**Maturity:** seed

**Определение A:** ...
```

mature = отсутствие строки `**Maturity:**` (симметрично остальному формату — «нормальное» состояние не маркируется явно).

**Переход seed → mature** — не автоматический, по запросу автора или предложению агента, когда различение выглядит устоявшимся. Чек-лист «mature-lite» (облегчённая версия FPF `E.8` — 13 канонических секций паттерна избыточны для короткого Pack-различения, тот же принцип лайт-версий, что в Ф1/Ф2):

1. **Проблема/мотивация** — зачем это различение, что путают без него
2. **Forces** — против какой альтернативы/напряжения оно устоялось (без этого пункта зрелость — декларация: непонятно, автор проработал конфликт или различения на самом деле нет)
3. **Пример** — минимум один реальный worked example, не абстракция
4. **Частая ошибка** — минимум один реальный misuse-кейс, не placeholder
5. **Последствия** — что ломается на практике, если различение проигнорировать

Все 5 пунктов должны быть закрыты содержательно (не placeholder'ами) перед снятием строки `**Maturity:** seed`. Если какой-то пункт неприменим — явно написать почему, не молчать.

`.pfad-decision.md` — PFAD-lite decision record (SPF `E.4.PFAD`, облегчённая версия — 3 таблицы вместо полного формата), создаётся вместе со scaffold на Шаге 4, наполняется по итогам Шага 2 (и Шага 3, если обсуждалась граница):
```markdown
---
wp: "{WP, в контексте которого создаётся Pack}"
pack_candidate: "{предложенное на Шаге 2 имя}"
pack_id_slug: "{slug}"
pack_id_code: "{короткий код, 2-4 буквы}"
created: "{YYYY-MM-DD}"
status: provisional
finalization_trigger: ""
provisional_distinction_files: []
---

# PFAD-lite: {pack_candidate}

## Домен

| Вариант | Почему отклонён |
|---------|------------------|

## Имя

| Вариант | Почему отклонён |
|---------|------------------|

## Граница

| Вариант | Почему отклонён |
|---------|------------------|

## Kind

| Вариант kind | Почему отклонён |
|--------------|------------------|

## Финальный выбор

**Домен:** ...
**Имя (slug):** ... (было provisional: "...")
**Код:** ... (было provisional: "...")
**Граница:** ...
**Kind:** ...
**decided_by:** pilot
**proposed_by:** agent | pilot
```
Заполнять таблицы вариантами, которые реально обсуждались на Шаге 2 (и Шаге 3) — не изобретать отклонённые варианты задним числом, если пользователь сразу согласился с первым предложением, таблицы остаются пустыми. Секция «Финальный выбор» заполняется на финализации (Шаг 2 «Финализация имени»), не на Шаге 4.

**Таблица `## Kind` и строка `**Kind:**` (WP-474 Ф5, D6-settlement).** Kind — базовый род сущности основного концепта домена по SPF base ontology (`U.Method` / `U.System` / `U.Episteme` / ... — см. `SPF/pack-template/ontology.md §1`). Решение о Kind принимается на Шаге 3 (вопрос там же). Таблица `## Kind` — реестр отвергнутых альтернатив kind (может остаться пустой по общему правилу «не изобретать задним числом»); сама по себе она НЕ является свидетельством решения. Свидетельство settlement — только заполненная строка `**Kind:**` в «Финальном выборе» (проверяется `/verify pack`, координата D6). **Исключение из правила абзацем выше:** в отличие от Домена/Имени/Границы, строка `**Kind:**` заполняется сразу по решению (Шаг 3), финализации имени не ждёт.

`06-sota/{slug}-sota-sheet.md` — из Шага 1.5:
```markdown
# SoTA Sheet: {источник}

**Claims:** {2-4 тезиса, унесённых в Pack}
distinction: {X} vs {Y}
**Evidence:** {цитата/страница/раздел}
**Validity region:** {где работает, где не работает — опционально}
**Rejected:** {что явно отклонено и почему — опционально}
**Freshness:** {когда пересматривать — опционально}
```

Строки `distinction: X vs Y` (0..N, опционально) — кандидаты различений, которые источник проводит явно. Формат жёсткий (строка начинается с `distinction:`, разделитель ` vs `), позиция свободная — парсер pack-creator ищет такие строки в любом месте sota-sheet-файла. По ним `/pack-creator` assembly-режим детерминированно собирает чек-лист кандидатов (WP-474 Ф6). Не обязательны на Шаге 1.5 — их можно дописывать позже, в том числе через LLM-fallback pack-creator с подтверждением автора.
Если источника не было (Шаг 1.5, пользователь пропустил) — файл не создавать, отметить это только в `00-pack-manifest.md` (`sota_sources: none`).

`ontology.md` — взять шаблон из `SPF/pack-template/ontology.md`, затем СРАЗУ заполнить §2 Domain Glossary терминами, зафиксированными на Шаге 3 («Материализация терминов»): построчно Term (RU/EN) / Definition / Parent Concept (SPF) из обсуждения. Не оставлять шаблонные `_Term 1_` / `_TBD_` — `/verify pack` (флаг O координаты D6) считает плейсхолдерные строки незаполненным лексиконом.

`00-pack-manifest.md` — взять шаблон из `SPF/pack-template/00-pack-manifest.md`, заполнить `pack_id` = `pack_id_code` с Шага 2 (короткий мнемо-код, например `DP`, а НЕ `pack_id_slug` и НЕ `PACK-{slug}` — расхождение найдено и исправлено при WP-474 Ф3: реальные Pack используют в этом поле короткий код), `pack_name` = `pack_candidate`. В блок `## Metadata`, сразу после `pack_name`, добавить две новые строки (в апстрим-шаблоне их пока нет — не путать с заполнением существующего плейсхолдера; перенос в шаблон, если понадобится всем Pack'ам, — отдельное решение по SPF, не работа pack-new):
- `sota_sources: none | grounded` по итогу Шага 1.5 — `none`, если источника не было, `grounded`, если источник и тезисы собраны.
- `name_status: provisional | finalized` по итогу Шага 2 — всегда `provisional` на момент scaffold (Шаг 4); переходит в `finalized` только на финализации имени (Шаг 2 «Финализация»).

Затем инициализировать репо и установить CI guard:
```bash
cd ~/IWE/PACK-{slug}
git init

# Установить CI guard (ID collision detector)
IWE_TEMPLATE="${IWE_TEMPLATE:-$HOME/IWE/FMT-exocortex-template}"
if [ -d "$IWE_TEMPLATE/pack-templates/.github" ]; then
  cp -r "$IWE_TEMPLATE/pack-templates/.github" .
fi

git add -A
git commit -m "feat: initial scaffold PACK-{slug} (SPF/pack-template) + CI guard R4"
```

CI guard — GitHub Action, который при каждом push/PR проверяет уникальность ID (DP.M.NNN, AR.NNN и т.д.) и блокирует слияние при коллизии.

Опционально — создать на GitHub:
```bash
gh repo create {GITHUB_USER}/PACK-{slug} --private --source=. --push
```

---

## Шаг 5. Дорожная карта наполнения

Показать пользователю план — что делать дальше:

```
═══════════════════════════════════════════════════════
  PACK-{slug} — дорожная карта наполнения
═══════════════════════════════════════════════════════

Сейчас: scaffold готов. Pack пустой — ценность появится после Ф1.

[ ] Ф1. РАЗЛИЧЕНИЯ (SPF §03) ← начать здесь
        Файл: 01-domain-contract/01B-distinctions.md
        Цель: 7-10 ключевых различений домена
        Время: ~1-2ч
        Как: перечислить что часто путают; проверить каждое на FPF A.7
        Инструмент: /ke — фиксировать различения в процессе работы с доменом

[ ] Ф2. СУЩНОСТИ (SPF §04)
        Файл: 02-domain-entities/
        Цель: перечислить роли, WP, методы — без детального описания
        Время: ~1-2ч
        Как: ответить на вопрос «кто делает, что производит, как проверяет?»

[ ] Ф3. МЕТОДЫ (SPF §07)
        Файл: 03-methods/
        Цель: описать ключевые методы практики
        Время: ~2-4ч
        Шаблон: для каждого метода — входы, выходы, критерии качества

[ ] Ф4. РАБОЧИЕ ПРОДУКТЫ (SPF §07)
        Файл: 04-work-products/
        Цель: описать артефакты практики
        Время: ~1-2ч
        Шаблон: название, описание, критерии готовности (Definition of Done)

[ ] Ф5. FAILURE MODES (SPF §08) ← высокая ценность
        Файл: 05-failure-modes/
        Цель: 5-10 типичных ошибок домена
        Время: ~1ч
        Формат: FM.NNN — причина, сигнал, как избежать

[ ] Ф6. SoTA — расширение источников (SPF §09)
        Файл: 06-sota/
        Цель: собрать первый источник (если Шаг 1.5 был пропущен, sota_sources: none) или углубить источники сверх стартового SoTA Sheet — по мере роста Pack
        Время: ~1-2ч

═══════════════════════════════════════════════════════
  Инструменты для наполнения:
  /ke — захват знания в Pack в процессе работы
  /fpf — проверить корректность сущностей по FPF A.*
  /verify pack — baseline-оценка адекватности по 11 координатам
      E.4.DPF.DA (ожидаемо CONDITIONAL для свежего скаффолда:
      часть координат partial/missing(seed-expected) — это норма).
      Обязательный прогон — в /pack-creator Шаг 4.
  SPF/process/03-distinctions-work.md — детальный процесс для Ф1
  SPF/process/08-failure-modes-extraction.md — процесс для Ф5
═══════════════════════════════════════════════════════

Принцип: Pack не заполняется за один присест.
Первая ценность — 7-10 различений (Ф1, 1-2ч).
Дальше Pack растёт в процессе работы с доменом через /ke.
```