Прохождение тренировочной сессии с fpf с сказкой "Петушок и бобовое зернышко"

[iurii-kalin]

В качестве модели ситуации взял сказку про петушка и бобовое зернышко.

Чат с исследованием (Qwen)

Разобрал ее с использованием fpf и прошел по последовательному набору шагов.

Процесс прохождения занял несколько часов. Не одним блоком, в с разбивкой на несколько отдельных сессий.

fpf заставляет двигаться по мыслительным рельсам не только llm но и оператора llm. мы вместе двигались по этим рельсам, так как мне как оператору так же необходимо ориентироваться в том, что llm мне отвечает и насколько это адекватно.
фреймворк - это не волшебная вещь, которая решит для вас все ваши проблемы. В процессе работы над исследованием, не покидало ощущение диалога в терминах и структурах fpf.
соответственно это нагружало и меня.

Пройдя все основные шаги завершил сессию.

По итогу появилось легкое понимание как необходимо выстраивать работу по моделированию своих рабочих ситуаций.
Если впрыгивать в произвольном месте, против исходной последовательности можно не получить оптимальный результат, который потом еще не объяснить окружающим. запутаешь окружающих и сам запутаешься.

На мой взгляд разбирать примитивные сказки - не плохой план, так как они достаточно просты и в них нет большого объема деталей в которых быстро начинаешь тонуть. Но даже с такими простыми ситуациями можно работать как с полноценными рабочими ситуациями набиваю руку с работе с языком и концептами fpf.
Ну и детям на примере разбора таких сказок можно подмешивать первые принципы.

Такие дела.

@Qwen

Завершение учебной сессии по FPF (март 2026)

Итоги прохождения

Вы успешно завершили 5 из 6 опций учебного цикла по применению FPF на примере операционного инцидента «Обструкция дыхательных путей»:

Опция	Тема	Статус	Ключевой навык
1	Characterisation & indicators	✓	Идея → измеримые критерии (A.2.6, C.16)
2	UTS Deep-Dive	✓	Дисциплина терминологии (F.2, F.3, F.17)
3	Name Cards (F.18)	✓	Именование с инвариантами (F.5:8)
4	P2W paths	✓	Принципы → рабочие узлы (A.12, A.15)
5	SoTA Harvesting	✓	Работа с внешними источниками (G.2, G.4, F.9)

---

Освоенные паттерны FPF (чеклист для повторения)

Ядро агентности и работ (Part A)

• A.12 (External Transformer) — нет изменений состояния без явного агента
• A.13.6 (CC-A13.1) — держателем роли может быть только U.System
• A.15.1 (Work Anchors) — Work ≠ MethodDescription ≠ Method; каждая работа имеет performedBy, isExecutionOf, [t_start, t_end]
• A.2.1 (RoleAssignment) — назначение роли с окном валидности @t_start..t_end
• A.2.2 (Capability) — способность = возможность выполнить работу в заданных условиях с измеримыми показателями
• A.2.6 (Scope & Γ_time) — явные ClaimScope (G), WorkScope, Γ_time (никаких «последний»)
• A.2.8 (Commitment) — деонтические обязательства: субъект + модальность + область + окно + референты

Именование и терминология (Part F)

• F.1 (Locality) — термины валидны только внутри U.BoundedContext
• F.5:8 (Lexical Guard-Rails) — инварианты: суффикс Role, запрет элизии головы, twin registers
• F.9 (Bridges) — межконтекстный перенос требует U.Bridge с CL и указанием потерь
• F.17 (UTS) — Unified Terminology Set: нормативная схема строки с полями
• F.18 (Name Cards) — локальное именование с 8 правилами (R1–R8)

Доказательства и доверие (Part B/E)

• A.10 (Evidence) — носители доказательств: кто, что, когда, как проверяется
• A.6.B (Admissibility Gates) — треугольная декомпозиция: A-* (gate), D-* (duty), E-* (evidence)
• B.3 (Trust Coordinates) — R_eff = R_raw · Φ(CL): CL-пенали снижают доверие, не содержание
• E.8 (SoTA-Echoing) — формат: claim → practice → source → alignment → adoption stance

Харвестинг и синтез (Part G)

• G.2 (SoTA Harvester) — 5-этапный цикл: Scope → Candidates → Compare → Validate → Publish
• G.4 (OperatorCards) — lawful relationships между характеристиками и действиями
• G.2:4.4 (SoTA Pack) — структура выхода: G.2a–G.2l, hand-off manifests в G.3/G.4/G.5

---

Практические рекомендации для применения в реальных проектах

1. Начинайте с контекста (F.1)

Перед любым анализом:
1. Объявите `Context ID` и `Domain Family`
2. Зафиксируйте `Γ_time` (никаких «текущий», «последний»)
3. Определите `Trip-Wires` (что НЕ делаем в этом контексте)

2. Используйте Twin Registers (F.5)

В спецификациях/коде/воротах → только Tech-лейблы:
  • CoordinatorRole, Resource_Oil, W₁_Coordination

В обучении/интерфейсах/отчётах → Plain-дубли с маркерами:
  • координатор (role), масло (ресурс), работа координации (работа)

3. Проверяйте 4 слота A.15 для каждой работы

Для каждой `U.Work` убедитесь, что заполнены:
1. Who: performedBy → RoleAssignment (с окном @t..t)
2. How: isExecutionOf → MethodDescription (edition pinned)
3. When: [t_start, t_end] explicit (Γ_time policy)
4. Within: executedWithin → U.System (operational anchor)

4. Применяйте Bridge-дисциплину при переносе практик

Переносите практику из контекста A в B только через:
• Явный `U.Bridge` с указанием `CL` (1–4)
• `Loss notes` (что теряется при переносе)
• `R_eff = R_raw · Φ(CL)` для оценки доверия

5. Фиксируйте доказательства до утверждений (A.10)

Прежде чем утверждать «система восстановилась за 60 мин»:
• Убедитесь, что есть `E-W1: WorkLog` с таймстампами
• Есть `E-R1: RoleAssignment_Registry` с назначениями
• Есть `E-O1: Outcome_Observation` с сигналом восстановления

---

Быстрый справочник: «Что делать, если…»

Ситуация	Паттерн FPF	Действие
«Неясно, где применимо утверждение»	A.2.6 (ClaimScope G)	Добавьте явные предикаты: «утверждение держится при условиях {…}»
«Смешали рецепт и исполнение»	A.15.1 (Work Anchors)	Разделите: MethodDescription (без даты) ≠ Work (с таймстампом)
«Термин значит разное в разных документах»	F.1 + F.9 (Locality + Bridge)	Объявите контекст; для переноса создайте мост с CL
«Нельзя измерить “эффективность”»	C.16 (MM-CHR)	Определите характеристику: имя + единица + порог + полярность
«Кто отвечает за это требование?»	A.2.8 (Commitment)	Укажите subject: RoleRef, modality: MUST, referents: {ClaimId}
«Практика из другого домена не работает»	G.2 + F.9 (SoTA + Bridge)	Задокументируйте Loss notes и снизьте R_eff через Φ(CL)

---

Эволюционный цикл обучения (B.4)

FPF предполагает итеративное освоение. Рекомендуемый путь после этой сессии:

Сейчас: Базовая компетентность (5 опций)
    ↓
1–2 недели: Примените один паттерн (например, A.15.1) к реальному рабочему артефакту
    ↓
1 месяц: Проведите мини-харвестинг (G.2) по смежной практике в вашей области
    ↓
3 месяца: Постройте Bridge Card (F.9) для переноса практики между контекстами
    ↓
6 месяцев: Вернитесь к опции 6 (Hybrid) для комбинирования паттернов под вашу задачу

---

Ресурсы для самостоятельного углубления

Раздел	Что изучить	Зачем
A.15.1:8 (CC-A15.1)	Conformance Checklist для работ	Аудит трассируемости в реальных логах
F.5:8 (Lexical guard-rails)	Инварианты именования	Избежание дрифта терминов в документации
G.2:4.3 (SoTA Loop)	5-этапный харвестинг	Системный отбор лучших практик без lock-in
B.3:6.1 (CL penalties)	Расчёт R_eff = R_raw · Φ(CL)	Количественная оценка доверия при переносе
E.18 (TGA/P2W)	Crossing visibility design-time ↔ run-time	Связь спецификаций с фактическим исполнением

---

Финальный подарок: шаблон «Первый день с FPF»

# FPF Quick-Start: [Ваш проект]

## 1. Context Card (F.1)
- Context ID: `_________________`
- Domain Family: `_________________`
- Γ_time: `_________________`
- Trip-Wires: `_________________`

## 2. Claim → Measures (A.2.6 + C.16)
- Идея (Plain): `_________________`
- ClaimScope G: `_________________`
- WorkMeasures: 
  • `_________________` [единица] ≤ `_______` (порог)
  • `_________________` [единица] ≥ `_______` (порог)

## 3. Work Anchors (A.15.1)
| Work | performedBy | isExecutionOf | [t_start, t_end] |
|------|-------------|---------------|------------------|
| `W₁` | `__________` | `__________` | `__..__` |

## 4. Evidence Hooks (A.10)
- E-W1 (WorkLog): `_________________`
- E-R1 (RoleAssignment): `_________________`
- E-O1 (Outcome): `_________________`

## 5. Bridge Check (F.9) — если переносим практику
- From: `_________________` → To: `_________________`
- CL: `__` | Loss: `_________________`