القائمة
Create a new Pack — guided flow through SPF: choose domain, name Pack, scaffold structure, fill roadmap.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Создание нового рабочего продукта (РП) с записью в 5 мест атомарно. Используй когда появляется новая задача, которой нет в плане недели.
Многотуровый диалог писателя (Claude) с напарником (Kimi) по задаче пилота (DP.SC.154). Ведёт turn-loop, обнаруживает CONSENSUS/ESCALATE, после консенсуса — Decision Gate (зафиксировать vs реализовать → ревью → проверить → задеплоить), синтезирует report.md через Agent tool.
Регистрация косяка агента в системе учёта WP-316 L1. Без LLM — детерминированный скрипт без WP Gate.
Аудит пользовательской инсталляции IWE. Запускает scripts/iwe-audit.sh + MCP healthcheck + smoke-test ритуала через sentinel-механику (контракт dry-run-contract.md), передаёт отчёт subagent'у в роли VR.R.002 Аудитор (context isolation) → verdict ✅/⚠️/❌ по 6 компонентам (Inventory, L1 drift, DS-strategy, L3 customizations, MCP, ритуал). Используй после restore из бэкапа, после update.sh, или при еженедельной сверке.
Протокол закрытия недели (Week Close). Ретро 7 дней + carry-over в новую неделю + платформенные шаги (бэкап, dirty repos).
Протокол закрытия дня (Day Close). Алиас для /run-protocol close day — симметрия с /day-open.
| 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 для домена: $ARGUMENTS
/ke + ручная работа по SPF §03-11Проверить существование 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.
Задать пользователю не более 3 вопросов (все сразу, одним сообщением):
Если ответ — «интересуюсь темой X», объяснить различение:
Тема = область интереса (нет собственных методов и артефактов). Домен = практика с методами, рабочими продуктами и failure modes.
Тест: «Есть ли люди, которые ДЕЛАЮТ это профессионально? Что они производят?»
Примеры: «машинное обучение» — тема. «Разработка ML-систем» — домен (есть: ML-инженеры, модели, метрики качества, failure modes). «Системное мышление» — тема. «Системный анализ» — домен.
Если пользователь затрудняется — помочь найти практиков и артефакты через уточняющие вопросы (до 2 дополнительных).
Источник принципа: FPF
E.4.DPF(source pack — шаг 2 из 11, до драфта паттернов) +G.2облегчённый вариант («1-page SoTA Sheet», informative). ПолныйG.2(CorpusLedger/ClaimSheets/BridgeMatrix) избыточен для личного Pack.
Прежде чем выбирать имя (Шаг 2), быстро проверить: как эту практику называют и описывают сами практики — не по памяти агента, а по одному внешнему источнику.
Задать пользователю (или найти самостоятельно, если пользователь не эксперт):
Это не полноценный research pass — цель узкая: проверить, что домен и будущее имя (Шаг 2) не оторваны от реальной практики. Опционально, если время есть: границы применимости источника (validity region), что явно отклонено, когда источник устареет (freshness).
Если пользователь говорит «источника под рукой нет» — не блокировать, идти дальше. Зафиксировать это явно на Шаге 4 (sota_sources: none в манифесте), не молчать.
Точка сверки: после Шага 3 (bounded context) — проверить, не изменилась ли граница домена настолько, что источник и тезисы нужно дополнить.
Имя Pack = существительное, узнаваемое практикам домена.
Критерии (все обязательны):
Предложить 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 (см. «Финализация имени» ниже).
Антипримеры кода:
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 не покрывает оба варианта)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}/<путь-из-списка>.
Порядок действий:
pack_candidate/pack_id_slug/pack_id_code или называет новые (независимо друг от друга — slug мог остаться, а код поменяться, и наоборот).pack_id_slug изменился: проверить, что PACK-{new_slug}/ ещё не существует (git mv в уже существующую директорию перенесёт файлы ВНУТРЬ неё вместо переименования) — при коллизии остановиться и попросить пилота другой slug. Иначе выполнить git mv PACK-{old_slug} PACK-{new_slug}.pack_id_code изменился или впервые фиксируется: проверить отсутствие коллизии с кодом другого Pack в IWE (см. антипример кода на Шаге 2). При коллизии — остановиться, попросить другой код.provisional_distinction_files, резолвя его как PACK-{new_slug}/<путь> (см. выше): посчитать вхождения {{PACK_ID}} ДО замены (grep -c '{{PACK_ID}}' <файл> = N), затем заменить все вхождения {{PACK_ID}} → {new_code} (короткий код, НЕ slug) в заголовках различений.grep -c '{{PACK_ID}}' <файл> после замены должен быть 0, а число заголовков ### {new_code}.D.NNN в файле должно равняться N. Расхождение (остались {{PACK_ID}} или число новых заголовков ≠ N) — не коммитить, показать диф пользователю.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), скилл это не делает автоматически.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 не перенесены) — заполнить сейчас.git add -A) — сообщением вида feat: finalize Pack name → PACK-{new_slug} (код {new_code}).Заполнить три поля вместе с пользователем:
| Поле | Содержание |
|---|---|
| Что входит | 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.
{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):
Все 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
Показать пользователю план — что делать дальше:
═══════════════════════════════════════════════════════
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.