h-reason

# h-reason — FPF reasoning umbrella

You are running the **haft umbrella reasoning workflow**. This skill replaces the old narrow `/h-fpf` (still aliased — same skill) with a complete reasoning palette: framing, exploration, comparison, verification, notes, plus key patterns from the slideument that don't have dedicated skills (Goldilocks problem selection, NQD discipline, BLP, Scaling-Law Lens).

**This is the manual entry point for FPF-style work** when the operator doesn't pre-pick a specific skill. Specialized skills (h-frame, h-diagnose, h-explore, h-compare, h-verify) still auto-fire on sharp signals and you SHOULD prefer them when the signal is clear — they carry deeper procedures. Use this umbrella when:

- The operator's signal is ambiguous between framing / exploration / comparison
- The operator explicitly types `/h-reason` or `/h-fpf`
- You want the whole palette of FPF wisdom (slideument patterns, FPF glossary) accessible in one place
- The work spans multiple workflow steps (frame → explore → compare in one session)

---

## The single most important rule: Description ≠ Work

This is the failure mode this umbrella is designed to NOT fall into.

When asked open-ended design questions, the default impulse is to produce a useful chat response — variants with weakest-links, a Pareto front, a comparison table — without going through the haft kernel. **Stop.** The visual shape of FPF output is not a substitute for invoking the kernel.

If you deliver an analysis without calling `mcp__haft__*` tools, the result is **ephemeral**: gone by tomorrow, no ProblemCard, no SolutionPortfolio, nothing to `/h-verify` in two weeks. The chat answer is wishlist, not work.

**Concrete failure patterns to catch in yourself:**

| About to do this in chat... | Stop and do this instead |
|---|---|
| Present 3+ alternative approaches | Call `haft_problem(action="frame")` then `haft_solution(action="explore")` |
| Compare two approaches with trade-offs | Frame first if needed, then `haft_solution(action="compare")` |
| State what the "real problem" is | Call `haft_problem(action="frame")` and persist it |
| Suggest "remember this" inline | Call `haft_note` |
| Verify a past decision claim | Call `haft_decision(action="evidence")` and `haft_refresh` |

**Friction tradeoff (honest).** Yes, calling kernel tools costs more in-the-moment than answering directly. The friction is the price for **durability and measurability**. Your job is not "best chat answer right now" — it is "leave the project with future-verifiable memory."

---

## Self-check before long responses

Before sending a long response, ask:

1. Is this response presenting **3+ alternatives**, a **comparison**, an **analysis with recommendation**, or **framing what the problem is**?
2. Did I call **any `mcp__haft__*` tool** in this turn?

If (1) = yes and (2) = no — STOP. Pick the right kernel action below and call it before responding.

---

## Maintenance check (FPF B.3.4) — before reasoning

When entering this umbrella, look at the most recent kernel response
for `Refresh reminder: N days since last stale scan`. If N > 30 —
call `mcp__haft__haft_refresh(action="scan")` BEFORE doing reasoning
work.

Reasoning on a stale graph is the same anti-pattern as reasoning on
stale code: variants you generate may rediscover what was already
decided, or contradict an already-decayed claim. Burn the
1-second scan first; reason against fresh state. If the scan finds
nothing new — mention briefly, proceed.

Same discipline for drift detected on files touched in this session:
re-baseline via `haft_decision(action="baseline", ...)` or surface
the drift explicitly. Do not silently proceed past a drift warning.

Surfacing the reminder is the kernel's job; acting on it is the
agent's job. See CLAUDE.md Critical Reminders.

---

## Quick triage — what is the operator actually asking?

Before doing anything, read the operator's signal carefully and classify:

| Signal | Workflow | Section below |
|---|---|---|
| Proposing a refactor/rewrite/redesign/migration without naming the problem | Framing | [Framing](#framing) |
| Concrete failure with unclear root cause (tests fail, X doesn't work) | Diagnosis | [Diagnosis](#diagnosis-failure-investigation) |
| Asking for options / variants / alternatives / "how could we" | Exploration | [Exploration](#exploration-nqd-variants) |
| Comparing 2+ approaches ("A or B", "which is better", "X vs Y") | Comparison | [Comparison](#comparison-parity-pareto) |
| Wants to commit to a specific variant (a binding choice) | Decision (manual) | [Decision is manual](#decision-is-manual) |
| Wants to check if a past decision still holds | Verification | [Verification](#verification) |
| Wants to record a micro-decision with rationale | Note | [Note](#note-micro-decision) |
| Wants situational awareness ("where are we", "what's stale") | Status | Call `haft_query(action="status")` directly |
| Repository has no `.haft/` yet | Onboarding | Delegate to `/h-onboard` |
| General FPF question ("what is FPF", "look up pattern E.9") | FPF spec lookup | Call `haft_query(action="fpf", query=...)` |

If the signal is **ambiguous** (spans multiple workflows) — start with framing. Without a framed problem, exploration / comparison float.

---

## Framing

Use when: a solution is proposed before the problem is stated, or scope/acceptance is unclear.

**Procedure (compressed; full version in /h-frame):**

1. **Stabilize the signal.** What's actually broken or wanted? In one sentence, what condition would make the operator say "solved"?
2. **Type the problem** — pick one:
   - `diagnosis` — something broke, root cause unknown
   - `optimization` — known target, want better numbers
   - `search` — looking for an unknown thing (e.g., a library, a pattern)
   - `synthesis` — building something new
3. **Umbrella-word repair** — if the signal uses overloaded terms ("service", "quality", "scalable", "готово"), unpack to specifics. Refuse to record a Problem