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.

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

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:

# Тип репозитория

**Тип**: `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 — минимальный, содержит:

# 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-шаблона с практикой отмечено отдельно, не устранено этой правкой):

# Ключевые различения {домена}

> Источник: 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:

### {{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, если обсуждалась граница):

---
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:

# 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:

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:

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.