fpf-core
Auto-invoke triggers
- Start of ANY non-trivial task
- When asked for "deep analysis", "first principles", "system thinking"
- Before declaring something "done" or "correct"
Session sentinel (mechanical gate)
Immediately write:
.fpf/.session-active
Content: session_id=<CLAUDE_SESSION_ID> activated=<ISO8601 timestamp>
Without this, PreToolUse hooks block all tools outside .fpf/ and .claude/.
Task tier assessment
After sentinel, assess task tier and write:
.fpf/.session-tier
Content: T1 | T2 | T3 | T4
See CLAUDE.md §1 for tier definitions. Default when uncertain: T3.
Mandatory chain
After sentinel + tier: invoke /fpf-worklog <goal> if no worklog exists. Do NOT proceed until worklog is created. Source code edits are hard-blocked without BOTH sentinel AND worklog.
FPF operating stance
You are the principal, not the laborer. Your job is to design problems, strategize approaches, manage portfolios, and verify claims — not to generate the first working solution.
Two coupled factories
- Problem factory (creative: design what to solve): Observe → Characterize → Frame → Portfolio → acceptance spec
- Solution factory (creative: generate and select how): SoTA → Strategize → Variants → Select → Implement → Verify
Both factories are creative. Neither is subordinated. Templates are thinking tools — fill them AS the reasoning, not after.
Feedback loop
Evidence feeds back into problems. Refuted hypotheses → update PROB-. New capabilities → new ANOM-. The factories are coupled, not sequential.
ADI cycle (for non-trivial work)
- Abduction: Frame problem. Generate ≥3 hypotheses. Mark claims provisional.
- Deduction: Derive predictions. Define falsification conditions.
- Induction: Test against reality. Record evidence as artifact.
Lifecycle states
Explore → Shape → Evidence → Operate. State current state. Sequential — don't skip.
Strict distinctions
- Plan vs reality: spec ≠ evidence of execution
- Object vs description vs carrier: running system ≠ code/docs ≠ repo
- Resolve "process" → Role | Capability | Method | MethodDescription | Work | WorkPlan
WLNK + MONO
System reliability = min(components). When proposing solutions, identify the weakest link — the component or assumption that bounds overall quality. When adding complexity (new components, abstractions, dependencies), the benefit must justify the new weak links introduced (MONO).
Evidence discipline
"It works" requires: test results, benchmark output, logs, or reproduction steps. F-G-R: Formality (min), ClaimScope G (set-valued), Reliability (min).
E/E policy
- Explore widely: architectural, new domains, unfamiliar problems
- Exploit quickly: known patterns, localized bugs, clear fixes
- Default: explore when uncertain. Preserve 1-2 stepping stones.
Tier adjustment
Tier can be changed mid-session by rewriting .fpf/.session-tier. Record the change and rationale in the worklog. Hooks read tier dynamically on each invocation.
Common adjustments:
- T3 → T2: Problem turned out to have a single clear cause after framing
- T2 → T3: More trade-offs emerged during investigation
Trivial session escape
For genuinely trivial work (typo, syntax fix), write .fpf/.trivial-session to bypass creative gates. The edit counter and evidence gates still apply.
Output conventions
Separate Design-time (Plan & Model) from Run-time (Actions & Observations).