Menu
Create a new Pack — guided flow through SPF: choose domain, name Pack, scaffold structure, fill roadmap.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional 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.