Моделирование запроса фичи
Session ID: ses_0de6cf051ffe2BHF3tV8Tlodfy
Created: 7/2/2026, 9:45:13 AM
Updated: 7/2/2026, 10:12:02 AM
User
У тебя есть скилл fpf-core. отвечай на все вопросы в этом чате с опорой на эту версию FPF.
Нам нужно отмоделировать “путешествие по производственной цепочке” для объекта “запрос фичи в продукте”. Тут мы говорим о запросе бизнес-пользователя (“клиента”) на доработку существующей или реализацию новой функциональности в программном продукте.
Assistant (Build · DeepSeek V4 Pro· 3.3s)
<skill_content name="fpf-core">
# Skill: fpf-core
# FPF Core Pattern Library
**Depends on:** nothing (root of dependency chain)
**Source of truth:** `assets/FPF-Spec.md` — canonical specification (60K+ lines)
## How to Use
Do NOT read `assets/FPF-Spec.md` in full. Identify the situation and load the relevant reference:
| You are doing... | Load |
|---|---|
| Developing or reviewing architecture | `C.32.P2S.md`, `C.30.md`, `A.22.md`, `C.32.md`, `C.32.PAD.md`, `C.32.ADR.md`, `C.33.md`, `C.34.md`, `C.35.md`, `C.30.ASV.md`, `C.30.AD.md`, `C.31.md`, `C.32.CONWAY.md`, `B.2.md`, `B.2.P.md` |
| Writing rules, methods, work-process documents | `A.6.md`, `A.6.B.md`, `A.6.C.md`, `A.15.md`, `A.15.1.md`, `A.15.2.md`, `A.15.3.md`, `A.15.4.md`, `E.18.md`, `E.18.1.md`, `E.8.md`, `E.19.md` |
| Comparing alternatives, making a local choice | `A.19.md`, `A.19.ECS.md`, `C.11.md`, `C.18.md`, `C.19.md`, `G.0.md`, `G.5.md` |
| Turning a vague situation into a problem statement | `C.22.2.md`, `C.2.2a.md`, `A.16.md`, `A.16.1.md`, `A.16.2.md`, `B.4.1.md`, `B.5.2.0.md` |
| Defining "better" and running improvement | `A.19.ECS.md`, `E.22.md`, `E.23.md`, `C.16.md`, `C.25.md`, `E.21.md`, `E.9.DA.md`, `E.2.DA.md` |
| Preparing evidence, assurance, gate decisions | `A.10.md`, `B.3.md`, `A.20.md`, `A.21.md`, `C.11.md`, `C.28.md` |
| Checking timing, freshness, rhythm, action windows | `C.27.md`, `A.10.md`, `A.20.md`, `A.21.md`, `C.11.md` |
| Using causal explanations, interventions, model outputs | `C.28.md`, `A.10.md`, `B.3.md`, `A.20.md`, `A.21.md`, `C.11.md` |
| Comparing descriptions, dashboards, explanations, views of the same thing | `E.17.md`, `E.17.0.md`, `E.17.EFP.md`, `A.15.4.md`, `A.7.md`, `C.30.AD.md` |
| Giving things better names | `F.17.md`, `F.18.md`, `F.19.md`, `E.10.md`, `E.10.ARCH.md` |
| Repairing wording in technical documents | `E.10.md`, `E.10.ARCH.md`, `F.18.md`, `F.19.md`, `A.6.P.md`, `C.2.P.md`, `C.16.P.md`, `C.16.Q.md`, `C.30.P.md`, `A.6.F.md`, `A.6.M.md` |
| Deciding whether mathematics / formal modeling would help | `C.29.md`, `A.6.0.md`, `A.6.1.md`, `E.18.1.md`, `C.16.md`, `C.27.md`, `C.30.LCA.md`, `C.30.ILC.md` |
| Building a state-of-the-art or option portfolio | `G.0.md`, `G.1.md`, `G.2.md`, `G.5.md`, `G.10.md`, `G.11.md`, `C.18.md`, `C.19.md`, `A.19.md`, `A.19.ECS.md` |
| Building a domain or local FPF-grounded framework | `E.4.md`, `E.4.PFAD.md`, `E.4.DPF.md`, `E.4.PFR.md`, `G.2.md`, `E.8.md`, `E.11.md`, `E.17.md`, `F.18.md`, `G.11.md` |
| Creating a DPF or LPF | `E.4.DPF.md` |
| Deciding what belongs in Core vs DPF/LPF | `E.4.md` + `E.5.3.md` |
| Recording relations between frameworks | `E.4.PFR.md` |
| Choosing a carrier for publication | `C.33.md` |
| Looking up a pattern by name | `INDEX.md` |
| Audit, deep reference, refactoring | `assets/FPF-Spec.md` (last resort only) |
## Dependency Rule
If a loaded reference links to other FPF patterns (governing-pattern cues),
load those too from `references/`. Each reference lists its own dependencies.
## Source for Agent vs Human
- **Agent**: always use `references/` — the primary source of patterns. Do NOT read `assets/FPF-Spec.md`.
- **Human**: read and edit the canonical monolith `assets/FPF-Spec.md` (source of truth). After edits, run `spec-decomposer` to rebuild `references/`.
## References Status
**Ready** — 274 pattern reference files + INDEX + 31 context sections.
Base directory for this skill: fpf-core
Relative paths in this skill (e.g., scripts/, reference/) are relative to this base directory.
Note: file list is sampled.
<skill_files>
<file>fpf-core\README.md</file>
<file>fpf-core\assets\FPF-Spec.md</file>
<file>fpf-core\references\A.15.md</file>
<file>fpf-core\references\A.15.5.md</file>
<file>fpf-core\references\A.15.4.md</file>
<file>fpf-core\references\A.15.3.md</file>
<file>fpf-core\references\A.15.2.md</file>
<file>fpf-core\references\A.15.1.md</file>
<file>fpf-core\references\A.14.md</file>
<file>fpf-core\references\A.13.md</file>
</skill_files>
</skill_content>
Assistant (Build · DeepSeek V4 Flash · 2.2s)
<path>fpf-core\references\C.22.2.md</path>
<type>file</type>
Tool: read
Input:
{
"filePath": "C:\\Users\\Dima\\.agents\\skills\\fpf-core\\references\\A.15.md"
}
Output:
<path>fpf-core\references\A.15.md</path>
<type>file</type>
Tool: read
Input:
{
"filePath": "C:\\Users\\Dima\\.agents\\skills\\fpf-core\\references\\A.15.1.md"
}
Output:
<path>fpf-core\references\A.15.1.md</path>
<type>file</type>
Tool: read
Input:
{
"filePath": "C:\\Users\\Dima\\.agents\\skills\\fpf-core\\references\\A.22.md"
}
Output:
<path>fpf-core\references\A.22.md</path>
<type>file</type>
Tool: read
Input:
{
"filePath": "C:\\Users\\Dima\\.agents\\skills\\fpf-core\\references\\E.17.md"
}
Output:
<path>fpf-core\references\E.17.md</path>
<type>file</type>
Assistant (Build · DeepSeek V4 Pro · 33.0s)
<path>fpf-core\references\E.18.1.md</path>
<type>file</type>
Tool: read
Input:
{
"filePath": "C:\\Users\\Dima\\.agents\\skills\\fpf-core\\references\\A.15.5.md",
"limit": 120
}
Output:
<path>fpf-core\references\A.15.5.md</path>
<type>file</type>
Assistant (Build · DeepSeek V4 Pro · 51.8s)
<path>fpf-core\references\C.22.2.md</path>
<type>file</type>
Tool: read
Input:
{
"filePath": "C:\\Users\\Dima\\.agents\\skills\\fpf-core\\references\\E.18.1.md",
"offset": 121
}
Output:
<path>fpf-core\references\E.18.1.md</path>
<type>file</type>
Tool: read
Input:
{
"filePath": "C:\\Users\\Dima\\.agents\\skills\\fpf-core\\references\\C.22.md",
"limit": 100
}
Output:
<path>fpf-core\references\C.22.md</path>
<type>file</type>
Tool: read
Input:
{
"filePath": "C:\\Users\\Dima\\.agents\\skills\\fpf-core\\references\\A.6.0.md",
"limit": 100
}
Output:
<path>fpf-core\references\A.6.0.md</path>
<type>file</type>
Tool: read
Input:
{
"filePath": "C:\\Users\\Dima\\.agents\\skills\\fpf-core\\references\\A.6.1.md",
"limit": 80
}
Output:
<path>fpf-core\references\A.6.1.md</path>
<type>file</type>
Assistant (Build · DeepSeek V4 Pro · 138.5s)
<path>fpf-core\references\E.18.1.md</path>
<type>file</type>
Tool: read
Input:
{
"filePath": "C:\\Users\\Dima\\.agents\\skills\\fpf-core\\references\\E.18.md",
"limit": 60
}
Output:
<path>fpf-core\references\E.18.md</path>
<type>file</type>
Assistant (Build · DeepSeek V4 Pro · 27.5s)
<path>fpf-core\references\G.5.md</path>
<type>file</type>
Tool: read
Input:
{
"filePath": "C:\\Users\\Dima\\.agents\\skills\\fpf-core\\references\\C.11.md",
"limit": 80
}
Output:
<path>fpf-core\references\C.11.md</path>
<type>file</type>
Tool: read
Input:
{
"filePath": "C:\\Users\\Dima\\.agents\\skills\\fpf-core\\references\\A.21.md",
"limit": 100
}
Output:
<path>fpf-core\references\A.21.md</path>
<type>file</type>
Tool: read
Input:
{
"filePath": "C:\\Users\\Dima\\.agents\\skills\\fpf-core\\references\\B.4.1.md",
"limit": 80
}
Output:
<path>fpf-core\references\B.4.1.md</path>
<type>file</type>
Tool: read
Input:
{
"filePath": "C:\\Users\\Dima\\.agents\\skills\\fpf-core\\references\\G.11.md",
"limit": 80
}
Output:
<path>fpf-core\references\G.11.md</path>
<type>file</type>
Assistant (Build · DeepSeek V4 Pro · 93.3s)
Thinking:
Now I have a solid understanding of the key patterns. Let me also check a couple more patterns that are relevant to business analysis:
- C.18 (archive) - for retaining candidates/requirements
- A.6.B (boundary) - for scope/business rules
- C.28 (causal) - for impact analysis
- A.16 (cue stabilization) - for early signal handling
Actually, I think I have enough to construct a solid answer. Let me synthesize the chain.
Classical business analysis decomposed into FPF patterns:
- Signal capture — B.4.1 (Observe → Notice → Stabilize → Route) + A.16 (cue notes)
- Problematization — C.22.2 (ProblemCard@Context)
- Elaboration — C.16, A.19, C.25 (characterization, measurement, quality bundles)
- Option generation — C.18 (archive), C.19 (pool/front)
- Comparison — G.9 (parity), G.0 (comparison frame)
- Selection/prioritization — G.5 (selected-set), C.11 (local choice)
- Formalization — A.6.0 (U.Signature), A.6.B (boundary)
- Gate decision — A.21 (gate)
- Handoff — E.18.1 (P2W) → A.15.5 (WorkEntryReadiness)
- Validation — A.10 (evidence), B.3 (assurance), G.4 (acceptance)
- Refresh — G.11 (currentness, decay)
Each transition is a “contract” defined by:
- Input: what the downstream pattern requires to start (e.g., P2W requires accepted ProblemCard)
- Output: what the upstream pattern produces
- Boundary: what the upstream pattern explicitly does NOT do
- Governing-pattern cue: which pattern governs the next step
Let me now construct the full answer with the chain diagram, contract definitions, and branching/cycles.
I need to be careful. The user asked me to decompose “classical business analysis” into FPF patterns. Business analysis typically includes:
- Elicitation
- Requirements analysis
- Requirements specification
- Requirements validation
- Requirements management
But FPF doesn’t have “requirements” as a first-class concept. Instead, it has:
- ProblemCard@Context (problem-side record)
- U.Signature (formal declarations - can carry functional constraints)
- A.6.B (boundary/policy)
- Acceptance criteria through C.16, A.19, G.4
Let me construct a faithful FPF decomposition. I’ll organize it as phases with patterns, contracts, and branching.
Actually, let me think about this more carefully. The user said “классический бизнес-анализ” (classical business analysis). In BABOK terms, this involves:
- Business Analysis Planning and Monitoring
- Elicitation and Collaboration
- Requirements Life Cycle Management
- Strategy Analysis
- Requirements Analysis and Design Definition
- Solution Evaluation
But mapping BABOK to FPF is inherently loose. Let me instead construct a native FPF decomposition that covers the same ground without trying to 1:1 map.
Key insight: FPF separates problem-side (C.22.2), carry-through (E.18.1), and work-side (A.15). Business analysis lives primarily on the problem side, with the handoff being the P2W transition.
Let me structure the answer:
Phase I: Сигнал и его стабилизация
- B.4.1: Observe → Notice → Stabilize → Route (pre-abductive seam)
- A.16: Cue notes (low-articulation cue preservation)
- → Contract: RoutedCueSet → вход в C.22.2
Phase II: Проблематизация
- C.22.2: ProblemCard@Context (Thin → Standard → High-relation)
- → Contract: accepted ProblemCard → вход в characterization или P2W
Phase III: Характеризация и измерение
- C.16: Measurement characterization
- A.19: Characteristics, scales, units, polarity
- C.25: Q-bundles (quality attributes)
- → Contract: characterized problem → вход в comparison
Phase IV: Генерация и сравнение опций
- C.18: Archive (retaining candidates)
- C.19: Pool/Front (explore/exploit)
- G.9: Parity and comparison
- G.0: Comparison frame
- → Contract: compared options → вход в selection
Phase V: Отбор и приоритизация
- G.5: Selected-set publication (Shortlist, RankedShortlist, SpecialistHandoff)
- C.11: Local choice (choose now / probe more / reject / reroute)
- → Contract: selected set or local choice → вход в formalization или gate
Phase VI: Формализация
- A.6.0: U.Signature (formal declaration of constraints, invariants)
- A.6.B: Boundary/policy wording
- A.6.F: Functional relations
- C.28: Causal claims (impact analysis)
- → Contract: formalized problem → вход в gate
Phase VII: Gate-решение
- A.21: GateDecision (pass/degrade/block/abstain)
- A.20: Constraint validity
- → Contract: GateDecision → вход в P2W или возврат
Phase VIII: Перенос в работу
- E.18.1: P2W carry-through
- → Contract: P2W record → A.15.5 WorkEntryReadiness → A.15 work chain
Циклы и ветвления:
- Refresh: G.11 на любом этапе
- Rival frame: ветвление C.22.2 → параллельные ProblemCard
- Gate fail: A.21 block → возврат к проблематизации (C.22.2)
- Evidence gap: возврат к characterization (C.16) или source restoration (A.15.4)
- Stakeholder views: E.17 MVPK на любом этапе
Let me now write the complete answer.
Да. Ниже — разложение классического бизнес-анализа на цепочку FPF-паттернов с явными контрактами на переходах, ветвлениями и циклами.
Цепочка FPF-паттернов для бизнес-анализа
B.4.1 C.22.2 C.16/A.19/C.25 C.18/C.19/G.9 G.5/C.11
Observe→ ProblemCard Characterization Archive/Front/ SelectedSet/
Notice→ @Context + Q-bundles Parity Local Choice
Stabilize→ (Thin→Std→High) (Shortlist/
Route Ranked)
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
RoutedCueSet ──► accepted ──► characterized ──► compared ──► selected ──┐
ProblemCard problem options set │
│
┌───────────────────────────────────────────────────────────────────┘
▼ ▼ ▼
A.6.0/A.6.B A.21 E.18.1
U.Signature/ GateDecision P2W
Boundary (pass/degrade/ CarryThrough
block/abstain)
│ │ │
▼ ▼ ▼
formalized ──► GateDecision ──► P2W record ──► A.15.5 WorkEntryReadiness
constraints + DecisionLog + CarriedDistinction → A.15 production chain
+ RecoveredFPFKind
Ветвления и циклы — отдельно, см. ниже.
Фаза 0: Сигнал и маршрутизация
| Паттерн | B.4.1 (Observe → Notice → Stabilize → Route) |
|---|---|
| Plain-name | Pre-abductive seam: от наблюдения к маршрутизации |
| Вход | Messy stakeholder signal: «нужен экспорт в PDF», жалоба, идея, anomaly |
| Выход | RoutedCueSet с candidateRouteSet и опциональным routeDecision |
| Суть | B.4.1 (B.4.1:1) — шов между низкоартикулированным сохранением сигнала и endpoint governance. Не позволяет сигналу преждевременно стать AnomalyStatement, Characteristic, ActionOption или requirements-языком. Публикует множество candidate routes или явный route selection. |
| Контракт на выходе | RoutedCueSet → одна из candidate routes ведёт к C.22.2 (problematization). Другие route-ы могут вести к A.6.A (инвайт), C.22.1 (anomaly statement), или остаться как cue. |
Переход B.4.1 → C.22.2: RoutedCueSet указывает selectedRoute = problematization. Сигнал готов к оформлению в ProblemCard. Если selectedRoute не выбран — сигнал остаётся cue, C.22.2 не запускается.
Фаза 1: Проблематизация
| Паттерн | C.22.2 ProblemCard@Context |
|---|---|
| Вход | RoutedCueSet с выбранным route = problematization |
| Выход (Thin) | Signal + context grounding + scope cut + not-wish reason + improvement check/acceptance probe + honest next use |
| Выход (Standard) | Thin + characterization cue + mandatory constraints + risk condition + validation boundary + freshness |
| Выход (High-relation) | Standard + setContextRef + rival frames + first-principles cue + governing-pattern cues |
| Контракт на выходе | P2W-ready — только если improvement check/acceptance probe присутствует. Иначе: reviewable (можно инспектировать, но не передавать в P2W). Next use = characterize / compare / search / refresh / retire / archive / abstainOrNoChange / apply governing pattern. |
Ветвление на выходе C.22.2:
| Next use | Куда |
|---|---|
P2W-ready |
→ Фаза 2 (characterization) или сразу Фаза 6 (P2W) если characterization не current |
characterize |
→ Фаза 2 (C.16, A.19, C.25) |
compare |
→ Фаза 3 (C.18, C.19, G.9) |
search |
→ Фаза 3 (archive/front/pool search) |
refresh |
→ G.11 |
retire / archive |
→ C.18 / C.19 |
abstainOrNoChange |
→ стоп: сигнал stale, duplicate, already solved, unnecessary |
Цикл (rival frame): Если обнаружен rival problem frame → параллельная ProblemCard для альтернативного framing. rivalProblemFormulationRef в исходной карте + новая карта со своим scope/EntityOfConcern/acceptance probe. Далее — сравнение через G.9.
Фаза 2: Характеризация и измерение
| Паттерны | C.16 (Measurement CHR), A.19 (Characteristics), C.25 (Q-bundles) |
|---|---|
| Вход | ProblemCard@Context с next use = characterize; или accepted ProblemCard, требующий characterization перед P2W |
| Выход | Characteristic declarations со Scale, Unit, Polarity (C.16, A.19). Q-bundle для multi-characteristic качества (C.25). Characterization relation + comparability/parity relation. |
| Суть | C.22.2 (C.22.2:6): «ProblemCard@Context states either a recoverable characterization relation and comparability or parity relation, or an explicit current reason why the problem can proceed without one.» C.16: measurement admissibility. A.19: characteristic, scale, unit, polarity, indicator-use discipline. C.25: Q-bundles. |
| Контракт на выходе | Characterized problem с named characterization relation + parity relation → вход в сравнение (G.9) или сразу в P2W (E.18.1). Без characterization — problem card не P2W-ready. |
Ветвление: Если characterization выявляет, что indicator не измерим — возврат к C.22.2 для пересмотра improvement check (другой acceptance probe).
Фаза 3: Генерация и сравнение опций
| Паттерны | C.18 (Archive), C.19 (Pool/Front), G.9 (Parity), G.0 (Comparison Frame) |
|---|---|
| Вход | Characterized problem + candidate solution/approach variants |
| Выход | Archive (C.18) / Front (C.19) с retained candidates. G.9: parity relation с comparison-window, comparator, budget, unit, repeatability pins. G.0: CG-Spec для comparison frame. |
| Суть | C.18 — archive: сохранение candidates с retention criterion. C.19 — pool/front: explore/exploit политика, live-pool treatment. G.9 — сравнение: «The heavy content stays with existing FPF patterns» (C.22.2:6). G.0 — comparison-frame и CG-Spec governance. |
| Контракт на выходе | Compared options с parity relation → вход в G.5 (selected-set publication) или C.11 (local choice). Без parity relation — comparison не admitted. |
Ветвление: Если front пуст или candidates недостаточно — возврат к генерации (C.18 archive search, C.19 pool expansion). Если comparator drift обнаружен → G.9 refresh.
Фаза 4: Отбор и приоритизация
| Паттерны | G.5 (Selected-Set Publication), C.11 (Local Choice) |
|---|---|
| Вход | Compared options с parity relation |
| Выход G.5 | Shortlist, RankedShortlist, SpecialistHandoff, narrowed handoff plan, или abstain outcome с basis pins. «No hidden scalar winner» (G.5:0). |
| Выход C.11 | ChoiceResult: choose now / reject current set / probe more / reroute к neighbouring question. |
| Различие G.5 vs C.11 | G.5 — selector-facing publication retained set, без commitment к одному winner. C.11 — локальный выбор среди explicit options: «кто/что выбирает, какой OptionSet на столе, какое ChoiceRule, и законный ChoiceResult.» (C.11:1) |
| Контракт на выходе | Selected set (G.5) или ChoiceResult (C.11) → вход в формализацию (A.6.0/A.6.B) или сразу в Gate (A.21). |
Ветвления:
- G.5 abstain outcome → возврат к сравнению (G.9) или поиску новых candidates (C.18/C.19)
- C.11 «probe more» → дополнительная характеризация/измерение (C.16, A.19)
- C.11 «reject current set» → возврат к генерации опций (C.18/C.19)
- C.11 «reroute» → переход к neighbouring question (C.19 pool policy, C.24 sequencing/enactment)
Фаза 5: Формализация
| Паттерны | A.6.0 (U.Signature), A.6.B (Boundary/Policy), C.28 (Causal Use) |
|---|---|
| Вход | Selected set или ChoiceResult |
| Выход A.6.0 | U.Signature: SubjectKind, RangedValueKind, Vocabulary, Laws, Applicability. Для business-constraints: U.Signature(profile=FormalSubstrate) с инвариантами, граничными условиями. |
| Выход A.6.B | Boundary/policy declarations: что в scope, что вне, какие правила действуют на границе контекста. |
| Выход C.28 | Causal claim: «если реализовать X, outcome Y изменится на Δ». C.28 (CausalityLadderRung, causal estimand, CausalEvidenceSupportBasis). |
| Суть | A.6.0 (A.6.0:0): «Use this pattern when you need to publish or check a reusable U.Signature declaration.» В бизнес-анализе — формальные ограничения (mandatory constraints из ProblemCard обретают формальную запись). C.28 — impact analysis: «что изменится от внедрения фичи». |
| Контракт на выходе | Formalized constraints + causal claims → вход в Gate (A.21) |
Ветвление: Если formalization выявляет противоречие в constraints → возврат к отбору (G.5/C.11) для пересмотра selected set.
Фаза 6: Gate-решение
| Паттерн | A.21 (GateProfilization: OperationalGate) |
|---|---|
| Вход | Formalized constraints + selected set + evidence refs |
| Выход | GateDecision ∈ {abstain, pass, degrade, block} с DecisionLogRef, GateProfile, effective GateCheckRef set, CV aggregate. |
| Суть | A.21 (A.21:0): «A single microkernel-style gate aggregates GateChecks into an order-independent GateDecision via the join-semilattice abstain <= pass <= degrade <= block.» Важно: gate display (зелёный цвет, галочка) — не gate passage. Gate passage — только когда recoverable OperationalGate(profile), GateProfile, GateCheckRef set, GateDecision, DecisionLogRef. |
| Контракт на выходе | GateDecision=pass → вход в P2W (E.18.1). GateDecision=degrade → narrowed scope, вход в P2W с ограничениями. GateDecision=block → возврат. GateDecision=abstain → недостаточно данных, возврат к characterization (C.16) или evidence collection (A.10). |
Цикл (block → problematization): Gate block → возврат к C.22.2 для переформулирования проблемы. Не к сравнению опций — именно к problem framing, потому что gate block означает: «проблема или constraints сформулированы так, что admissible решения нет.»
Цикл (abstain → evidence): Gate abstain → A.10 evidence collection → characterization refresh (C.16) → повторный вход в A.21.
Фаза 7: Перенос в работу (стык с production chain)
| Паттерн | E.18.1 P2W Carry-Through |
|---|---|
| Вход | Accepted ProblemCard@Context + GateDecision=pass |
| Выход | P2W carry-through record: ProblemCardRef, CarriedDistinction, NextFPFUseQuestion, RecoveredFPFKindOrRelation, SelectedApplication, WrittenRecordOrApplication, NotCarried, StopCondition, ReturnTrigger, SourceCurrentnessCheck. |
| Контракт на выходе | P2W record → A.15.5 (WorkEntryReadiness) → A.15.2 (WorkPlan) → A.15.1 (U.Work). За пределами бизнес-анализа. |
Сквозные паттерны (на любом этапе)
| Паттерн | Где применяется |
|---|---|
| E.17 MVPK | Multi-view publication: ProblemCard → TechCard для команды, PlainView для стейкхолдеров, AssuranceLane для compliance. На любом этапе. |
| G.11 Refresh | Любой record (ProblemCard, characterization, selected set, gate decision) может устареть. G.11: RefreshCurrentnessLine@Context или RefreshPlan@Context с affected scope и governing pattern. |
| A.10 Evidence | На любом этапе, где требуется evidence/provenance для claim. «12 тикетов поддержки» — A.10 evidence relation, не просто слова в ProblemCard. |
| A.6.3.RT / A.6.4 | Representation transition / ontological reframing — когда меняется способ описания проблемы (например, от текста к формальной модели). |
| A.15.4 Source Restoration | Когда publication face (dashboard, briefing, generated explanation) используется как work/reliance claim, а исходный source не recoverable. |
Сводка ветвлений и циклов
┌── rival frame ──► C.22.2' (альтернативная ProblemCard)
│ │
│ ▼
B.4.1 ──► C.22.2 ──┼── characterize ──► C.16/A.19/C.25
│ │
│ ┌────────────────────┤
│ ▼ ▼
│ C.18/C.19/G.9 ◄── indicator not measurable
│ │
│ ├── candidates insufficient ──► C.18/C.19 (search)
│ ▼
│ G.5/C.11
│ │
│ ├── abstain ──► G.9 (re-compare)
│ ├── probe more ──► C.16 (re-characterize)
│ ├── reject set ──► C.18/C.19 (re-generate)
│ ├── reroute ──► C.19 (pool policy) / C.24 (enactment)
│ ▼
│ A.6.0/A.6.B/C.28
│ │
│ ├── constraint contradiction ──► G.5/C.11
│ ▼
│ A.21 Gate
│ │
│ ├── block ──► C.22.2 (re-frame problem) ◄──┐
│ ├── abstain ──► A.10 → C.16 ──► A.21 ────┘
│ ├── degrade ──► E.18.1 (narrowed)
│ ▼
│ E.18.1 P2W ──► A.15.5 ──► A.15 production chain
│
└── refresh (G.11) на любом этапе ──► возврат к
изменившемуся assumption (smallest affected locus)
Каждый переход — это governed relation: выход upstream-паттерна либо satisfies входной контракт downstream-паттерна, либо downstream-паттерн останавливается (P2W без accepted ProblemCard), либо возвращает управление (Gate block → C.22.2). Ни один переход не является скрытым: governing-pattern cue всегда именует, какой паттерн применяется следующим и какой claim kind named by value.
User
Крутяк! Ты прямо профессор анализа 
А давай теперь так: опиши цепочку основных этапов бизнес-анализа с краткими человекопонятными названиями, а затем дай чек-лист по каждому этапу в формате таблицы: Шаг этапа, Свидетельство выполнения шага, Следующий шаг (позитивный сценарий), Возможные следующие шаги (по негативным сценариям), комментарии к негативному сценарию.
Assistant (Build · DeepSeek V4 Pro · 9.7s)
Thinking:
The user wants me to:
- Describe the chain of main business analysis stages with brief human-readable names
- For each stage, provide a checklist table with columns:
- Step of the stage
- Evidence of step completion
- Next step (positive scenario)
- Possible next steps (negative scenarios)
- Comments on negative scenario
Let me structure this based on the FPF pattern chain I already established:
Stages (human-readable names):
- Приём сигнала (B.4.1 + A.16) — «Что нам вообще принесли?»
- Формулировка проблемы (C.22.2) — «В чём на самом деле проблема?»
- Измерение и критерии (C.16, A.19, C.25) — «Как поймём, что решено?»
- Поиск и сравнение вариантов (C.18, C.19, G.9) — «Какие есть способы решить?»
- Отбор и приоритизация (G.5, C.11) — «Что выбираем и почему?»
- Формальные ограничения (A.6.0, A.6.B, C.28) — «Какие жёсткие рамки?»
- Gate: решение о запуске (A.21) — «Даём добро или нет?»
- Передача в производство (E.18.1 P2W) — «Что именно несём в работу?»
Let me now create a detailed checklist table for each stage, with specific evidence items and branching paths based on FPF pattern rules.
I need to be concrete and specific about:
- What constitutes “evidence of completion” (what specific FPF record or field)
- What the positive next step is
- What negative scenarios exist and their concrete next steps
- Comments explaining the negative scenario in plain terms
Let me draft this now. The output will
User
Крутяк! Ты прямо профессор анализа
А давай теперь так: опиши цепочку основных этапов бизнес-анализа с краткими человекопонятными названиями, а затем дай чек-лист по каждому этапу в формате таблицы: Шаг этапа, Главные паттерны FPF для этого этапа (без второстепенных паттернов, упомянутых в главных), Свидетельство выполнения шага, Следующий шаг (позитивный сценарий), Возможные следующие шаги (по негативным сценариям), комментарии к негативному сценарию.
При этом сами столбцы таблицы назови конпактно. Я тут написал развёрнуто чисто для твоего понимания.
Assistant (Build · DeepSeek V4 Pro · 54.3s)
Thinking:
The user wants me to create a practical checklist for business analysis stages, with:
- Short human-readable stage names
- Tables with columns:
- Step of the stage (compact name)
- Main FPF patterns for this stage (no secondary patterns mentioned by main ones)
- Evidence of step completion
- Next step (positive scenario)
- Possible next steps (negative scenarios)
- Comments on negative scenario
Let me structure this based on the chain we already built:
- Сигнал (Signal) — B.4.1
- Проблематизация (Problematization) — C.22.2
- Характеризация (Characterization) — C.16, A.19, C.25
- Сравнение (Comparison) — C.18, C.19, G.9, G.0
- Отбор (Selection) — G.5, C.11
- Формализация (Formalization) — A.6.0, A.6.B, C.28
- Шлюз (Gate) — A.21
- Перенос (Handoff) — E.18.1
Let me keep the column names compact as the user requested:
- Шаг (Step)
- Паттерны FPF (FPF Patterns)
- Свидетельство (Evidence)
- Позитивный сценарий (Positive scenario)
- Негативные сценарии (Negative scenarios)
- Комментарий (Comment)
Let me write this concisely but completely.
Цепочка бизнес-анализа: 8 этапов
| # | Этап | Суть (человеческим языком) | Главные паттерны FPF |
|---|---|---|---|
| 1 | Сигнал | Что нам принесли и куда это направить | B.4.1 |
| 2 | Проблематизация | Что на самом деле является проблемой | C.22.2 |
| 3 | Характеризация | Как мы поймём, что проблема решена | C.16, A.19, C.25 |
| 4 | Сравнение | Какие есть варианты решения и чем они различаются | C.18, C.19, G.9 |
| 5 | Отбор | Что выбираем и почему | G.5, C.11 |
| 6 | Формализация | Каковы жёсткие рамки и ожидаемый эффект | A.6.0, A.6.B, C.28 |
| 7 | Шлюз | Пропускаем в работу или нет | A.21 |
| 8 | Перенос | Что именно из анализа переходит в производство | E.18.1 |
Этап 1. Сигнал
| Шаг | Паттерны | Свидетельство | Позитивный сценарий | Негативные сценарии | Комментарий |
|---|---|---|---|---|---|
| Захватить сигнал | B.4.1 | RoutedCueSet.sourceCuePackRef указывает на источник сигнала (тикет, встреча, письмо) |
→ Проблематизация | Cue lost — сигнал утерян до фиксации | B.4.1: сигнал без sourceCuePackRef — не routed cue set |
| Стабилизировать сигнал | B.4.1 | candidateRouteSet содержит ≥ 1 route |
→ Выбор route | Пустой candidateRouteSet |
Сигнал пойман, но непонятно куда его: problematization? anomaly? A.6.A invitation? |
| Выбрать route | B.4.1 | selectedRoute = problematization + routeRationale |
→ Проблематизация | selectedRoute ≠ problematization |
Если route = anomaly → C.22.1; route = invitation → A.6.A. Это не ошибка, а другой трек |
Этап 2. Проблематизация
| Шаг | Паттерны | Свидетельство | Позитивный сценарий | Негативные сценарии | Комментарий |
|---|---|---|---|---|---|
| Оформить Thin ProblemCard | C.22.2 | Signal + context + scope + не-хотелка + improvement check | → Проверка next use | Невозможно написать Thin форму | C.22.2: «честный next use» — не любой, а truthful. Если improvement check не формулируется — стоп, сигнал недозрел |
| Определить next use | C.22.2 | next use ∈ {characterize, compare, search, P2W-ready, refresh, retire, archive, abstainOrNoChange} |
→ Характеризация (если characterize) | abstainOrNoChange |
Сигнал stale, duplicate, already solved. Это успешный исход проблематизации — работа не нужна |
| (Опционально) Standard Card | C.22.2 | Добавлены constraints, risk condition, validation boundary | → Сравнение или Характеризация | Карта раздута полями, которые не current | C.22.2 (anti-pattern): form-completion. Conditional fields — только когда current |
| (Опционально) High-relation Card | C.22.2 | Добавлены setContextRef, rival frames, governing-pattern cues | → Сравнение или Отбор | Карта исполняет claims вне C.22.2 | C.22.2: content creep. Governing-pattern cue — только ссылка, не исполнение |
Этап 3. Характеризация
| Шаг | Паттерны | Свидетельство | Позитивный сценарий | Негативные сценарии | Комментарий |
|---|---|---|---|---|---|
| Объявить characteristics | A.19, C.16 | Characteristic + Scale + Unit + Polarity для каждого значимого качества | → Объявление Q-bundle | Characteristic без Scale/Unit | C.16: «No mean on ordinals; no unit mixing.» Без CHR — measurement не admitted |
| Объявить Q-bundle | C.25 | Multi-characteristic bundle с declared relations между characteristics | → Проверка comparability | Characteristics конфликтуют (trade-off не назван) | C.25: Q-bundle — не просто список атрибутов. Конфликт без trade-off relation — не Q-bundle |
| Проверить comparability | G.9, C.16 | characterization relation + comparability/parity relation named |
→ Сравнение | Нет comparability relation | C.22.2:6 — «ProblemCard states either a recoverable characterization relation and comparability, or an explicit reason why it can proceed without one.» |
Этап 4. Сравнение
| Шаг | Паттерны | Свидетельство | Позитивный сценарий | Негативные сценарии | Комментарий |
|---|---|---|---|---|---|
| Сформировать candidate set | C.18, C.19 | Archive (C.18) или Front (C.19) с ≥ 1 retained candidate + retention criterion | → Сравнение candidates | Пустой candidate set | Нет admissible вариантов. Назад к проблематизации: возможно, constraints слишком жёсткие |
| Сравнить candidates | G.9, G.0 | Parity relation: comparator, comparison-window, budget, unit, repeatability pins + CG-Spec | → Отбор | Comparator drift — сравнение невоспроизводимо | G.9: без зафиксированных pins сравнение не admitted |
| Зафиксировать результат сравнения | G.9 | Comparison result с partial order или set-return (если total order невозможен) | → Отбор | Hidden scalar winner — partial order свёрнут в одно число | G.5: «no hidden scalar winner.» Set-return — допустимый исход |
Этап 5. Отбор
| Шаг | Паттерны | Свидетельство | Позитивный сценарий | Негативные сценарии | Комментарий |
|---|---|---|---|---|---|
| Опубликовать selected set | G.5 | Shortlist / RankedShortlist / SpecialistHandoff с basis pins |
→ Формализация | Abstain outcome — набор непубликуем | G.5: abstain — допустимый исход. Причина: candidates несравнимы, данных недостаточно |
| Или: локальный выбор | C.11 | DecisionSubject + OptionSet + ChoiceRule + ChoiceResult ∈ {choose now, reject, probe more, reroute} |
→ Формализация | reject current set |
C.11: «если выбор невозможен при текущем OptionSet — reject, не pretend.» |
| Probe more (если нужно) | C.11 | Named next probe: «дополнительное измерение X может изменить choice» | → Характеризация (дособрать данные) | Probe не может изменить результат | C.11: «cannot name one next probe that could still change the result» — не probe more, а choose now или reject |
Этап 6. Формализация
| Шаг | Паттерны | Свидетельство | Позитивный сценарий | Негативные сценарии | Комментарий |
|---|---|---|---|---|---|
| Задекларировать ограничения | A.6.0 | U.Signature: SubjectKind + Vocabulary + Laws + Applicability |
→ Проверка на противоречия | Constraints противоречат друг другу | Назад к Отбору: selected set несовместим с mandatory constraints |
| Зафиксировать границы | A.6.B | Boundary declarations: scope, что внутри/вне контекста | → Формализация эффекта | Граница не определена однозначно | A.6.B: без явной границы downstream работа не знает, где кончается фича |
| Оценить эффект | C.28 | Causal claim: estimand, CausalityLadderRung, CausalEvidenceSupportBasis | → Шлюз | Causal claim без evidence support | C.28: claim без support basis — не admitted. «Внедрим фичу → клиент останется» — без support это не causal claim, а надежда |
Этап 7. Шлюз
| Шаг | Паттерны | Свидетельство | Позитивный сценарий | Негативные сценарии | Комментарий |
|---|---|---|---|---|---|
| Собрать GateChecks | A.21 | Effective GateCheckRef set под текущим GateProfile |
→ Агрегация | GateCheck не recoverable — только «зелёный цвет» | A.21: «A green tile is not gate passage.» Без recoverable GateCheckRef set — шлюза нет |
| Агрегировать решение | A.21 | CV aggregate + GateDecision ∈ {abstain, pass, degrade, block} + DecisionLogRef |
→ Перенос (если pass) | block |
block → возврат к Проблематизации (C.22.2). Не к сравнению — проблема/constraints несовместимы |
abstain |
Недостаточно данных → A.10 evidence → characterization → повторный вход в A.21 | ||||
degrade |
Narrowed scope → Перенос с ограничениями |
Этап 8. Перенос
| Шаг | Паттерны | Свидетельство | Позитивный сценарий | Негативные сценарии | Комментарий |
|---|---|---|---|---|---|
| Зафиксировать carried distinction | E.18.1 | CarriedDistinction: что именно из ProblemCard переживёт переход в работу |
→ Выбор следующего FPF-relation | ProblemCard не accepted | E.18.1: P2W останавливается до начала. Материал — reduced-use cue |
| Назвать следующий FPF-relation | E.18.1 | RecoveredFPFKindOrRelation: конкретный FPF kind/relation, в который переходит различение |
→ Запись governed record | Несколько candidate relations, неясно какой | E.18.1: split source phrase → несколько applications |
| Записать NotCarried | E.18.1 | NotCarried: что сознательно НЕ переносится |
→ Запись StopCondition | NotCarried пуст при очевидных не-переносимых claims | «Клиент под угрозой оттока» — problem-side signal, не work authorization |
| Записать StopCondition + ReturnTrigger | E.18.1 | StopCondition + ReturnTrigger + SourceCurrentnessCheck |
→ A.15.5 WorkEntryReadiness | — | StopCondition — при каком условии работа не начинается. ReturnTrigger — что заставит переоткрыть earlier P2W locus |
Сквозной чек-лист
| Шаг | Паттерн | Свидетельство | Позитивный сценарий | Негативные сценарии | Комментарий |
|---|---|---|---|---|---|
| Проверить свежесть любого record | G.11 | RefreshCurrentnessLine@Context: affected object + currentness object kind + source record + edition pins |
→ Продолжить | Record stale → refresh или retire | G.11: не «переделываем всё», а scoped refresh самого маленького affected locus |
| Опубликовать для стейкхолдеров | E.17 | MVPK face (PlainView / TechCard / AssuranceLane) с source pins + bounded publication use | → Обратная связь | Face overread как evidence/gate/work | E.17: «publication face adds no claim by readable form» |