h-explore

# h-explore — Generate distinct variants with NQD discipline

You are running the FPF exploration workflow. The point is rivalrous candidate generation: 3-5 variants that differ in KIND, each with a named weakest_link, and at least one stepping-stone (or an explicit rationale for not having one).

## Step 1 — Ensure the problem is framed (agent infers first, asks only on real ambiguity)

If no `problem_ref` is in the operator's request:
- **First**: call `mcp__haft__haft_query(action="status")` and read recent active problems. If exactly one matches the operator's current topic, use it and tell the operator "exploring against prob-XXX (the recent X problem) — say so if you meant a different one."
- **Second**: if multiple plausible matches exist, surface 2-3 candidates and ask which one (legitimate ambiguity).
- **Third**: if the operator describes a problem inline and no recent match exists, call `mcp__haft__haft_problem(action="frame", ...)` first per the h-frame procedure — the agent does the framing, then proceeds to explore.

Without a problem reference the exploration floats. But asking the operator to pick from a list before trying inference is delegation back; default is infer-then-act.

## Step 2 — Generate variants in parallel for diversity (optional but recommended)

For genuine diversity force the candidates to come from distinct directions. Spawn 3-5 Agent subagents IN THE SAME MESSAGE, each instructed to produce ONE variant from a different conceptual direction:

```
Agent(
  description="Generate variant #1 (data-flow restructure direction)",
  prompt="
    Problem: <stabilized signal + acceptance from the ProblemCard>

    Your direction (assigned, distinct from siblings): <data flow restructure>
    Other agents are producing variants from other directions
    (caching, batching, infrastructure swap, etc.). Do NOT step on their
    territory — give the operator the variant that comes from YOUR
    direction.

    Return EXACTLY:
    title: <short variant name>
    description: <2-3 sentence sketch of the approach>
    novelty_marker: <what makes this different from typical AI suggestions>
    weakest_link: <what bounds this option's quality if pursued — the
      Achilles' heel, NOT the title repeated>
    stepping_stone: true | false
    stepping_stone_basis: <if true, what future search space this opens>
    risks: [<risk>, ...]
    strengths: [<strength>, ...]
  "
)
```

Parallel directions to consider (pick 3-5 that fit the problem):
- Data-flow restructure (avoid the need for the current operation)
- Algorithmic alternative (same operation, different algorithm)
- Infrastructure swap (different runtime/service/library)
- Caching/batching/queuing (smooth load patterns)
- Architectural extraction (move responsibility to different layer)
- Workflow restructure (change when/how operation is triggered)
- Stepping stone (suboptimal now but opens novel future path)

## Step 3 — Alternative: serial generation (when parallel overkill)

For lightweight exploration (tactical mode, <5 minute task) you can generate variants directly without subagents. Still enforce:
- ≥2 variants (kernel rejects fewer)
- Each variant has weakest_link (kernel rejects empty)
- Each variant has novelty_marker (kernel rejects empty)
- Variants differ in KIND, not degree (your judgment; kernel emits soft warning if titles look similar)

## Step 4 — Call kernel

```
mcp__haft__haft_solution(
  action="explore",
  problem_ref="<prob-...>",
  variants=[
    {
      "title": "<variant 1 name>",
      "description": "<approach>",
      "novelty_marker": "<distinct from siblings>",
      "weakest_link": "<what bounds quality>",
      "stepping_stone": false,
      "risks": ["<risk>"],
      "strengths": ["<strength>"]
    },
    // ... 3-5 variants
  ],
  no_stepping_stone_rationale="<required if no variant has stepping_stone=true>",
  mode="<inherit from problem; tactical OK for low-stakes>"
)
```

The kernel returns the SolutionPortfolio ID. Soft warnings may flag disguised duplicates (titles too similar), missing parity_rules for 3+ variants, or weakest_links that just repeat titles — read and self-correct if needed.

## Step 5 — Present to operator

Surface:
- Each variant with its weakest_link and novelty_marker
- Identify any that look weak on the surface but might be stepping stones
- Recommend next step:
  - `/h-compare` to evaluate variants against declared dimensions and pick a Pareto front
  - More exploration if variants converge too tightly (operator may want a wider net)

**Re-grounding discipline (FPF A.7).** Every bare variant label and
artifact ID in your operator-facing text (`V1`, `V2`, `sol-...`, returned
portfolio refs) MUST be paired with its human-readable title or key
claim on first mention in any paragraph/table/summary. Bare `V3 dominates
V1` is opaque after a long session; `V3 (data-flow restructure) dominates
V1 (algorithmic alternative)` restores the object behind the carrier.
Keep IDs — they are needed for traceability — but never let them stand
alone. See CLAUDE.md Critical Reminders for the project-wide rule.

## Curation gate — flag uncertain reasoning (dec-20260603-732219b6)

Your drafted rationale (weakest-links, risks, strengths, novelty markers) is
broad-but-noisy — most points help, a small fraction mislead. When you present
it, do not give the operator a flat wall to over-read or rubber-stamp. Bucket
each argument by your confidence and lead with the doubtful ones:

- **⚠ Uncertain — scrutinize** — arguments you are NOT sure are correct or
  load-bearing. Surface FIRST and prominently.
- **Helpful (secondary)** / **overlaps the obvious** — list compactly, skim-only.

Honesty rule (an invariant of this decision): never down-rank a low-confidence
argument into "helpful" to look tidy, and never hide it — false tidiness makes
the operator curate LESS carefully than a flat list would. If nothing is
genuinely uncertain, say so; do not invent an uncertain item to fill the bu