feat(pipeline): consolidate cycle recon, add fieldtest probe tier, enforce assumption economy

Implements the three efficiency findings from the #310 pipeline
measurement (refs #35): ~691k subagent tokens / ~3.5 h for a
deliberately small cycle, with recon duplication as the single
biggest obligatory per-cycle cost.

1. Cycle recon (pipeline.md § Cycle recon; specify, planner,
   brainstorm, boss, plan-recon): recon fan-out is budgeted per
   cycle, not per phase. One full plan-recon dispatch — normally
   specify Step 1, in a new pre-spec sources/recon_scope carrier
   form — serves both the spec's concrete code shapes and the
   plan's file-map. planner Step 2 becomes reuse-first (freshness /
   quotability / coverage conditions) with narrowly-bounded delta
   dispatches (new Delta dispatch contract in plan-recon.md);
   broad Explore-type grounding sweeps are banned in every mode.
   Field evidence: 151k (Explore) + 99k (plan-recon) with ~40 %
   overlap in one bounded cycle.

2. Fieldtest probe tier (fieldtest, fieldtester, pipeline.md,
   agent-template.md § model rule 2): a cycle whose user-visible
   delta is a single narrow axis dispatches the per-cycle
   fieldtest at tier: probe — 1-2 examples on exactly that axis,
   ~200-word report, explicit model:sonnet dispatch override (no
   dispatch-level effort override exists; frontmatter effort
   applies). Probe is a tier, not a skip; the milestone fieldtest
   always runs full tier on the frontmatter model, keeping the
   milestone-close gate's >=2-example floor unconditional.

3. Assumption economy (specify Step 3 + self-review item 6):
   grounding-check cost scales with the spec's assumption count,
   so specs state current-behaviour claims only where the change
   relies on them (the gate's own falsity test), demote
   context-only mentions to ledger citations, and keep iteration
   scope tight — fewer restatements, never fewer reliances. The
   gate itself is unchanged.

Design reviewed pre-implementation (opus plan review); diff
adversarially verified by a 3-lens review workflow (consistency,
operability, cross-reference), confirmed findings folded in.

refs #35

planner/SKILL.md

@@ -80,20 +80,37 @@ of one iteration's worth of work onto a task list.
 
 ### Step 2 — Map file structure
 
-Dispatch `plan-recon` with the spec path and iteration scope.
-Read the returned file-map. Lift the relevant entries into
-the plan's "Files this plan creates or modifies" section; the
+The file-map normally already exists: the **cycle recon** report
+(`../docs/pipeline.md` § Cycle recon), dispatched during `specify`
+Step 1 or ad-hoc by `brainstorm`. Reuse it while that section's
+reuse conditions — freshness, quotability, coverage — hold. Lift
+the relevant entries
+into the plan's "Files this plan creates or modifies" section; the
 orchestrator may add or amend entries that recon missed.
 
-Dispatch carrier: see the **Carrier contract** table in
-`agents/plan-recon.md` (single source for `spec_path`,
-`iteration_scope`, `focus_hint`).
+Dispatch `plan-recon` only:
 
-Recon does NOT decide decomposition. Two recon dispatches per
-planner run is unusual but legitimate (e.g. one for the main
-spec sections, one with a sharper `focus_hint` for a tricky
-subsystem). Three or more is a smell — re-read the spec; the
-iteration scope is probably too broad.
+- as a **delta**, on the § Cycle recon delta triggers — a narrow
+  dispatch whose `focus_hint` names the gap, bounded by the
+  **Delta dispatch** contract in `agents/plan-recon.md`;
+- in **full**, when no valid cycle recon exists (a direct tidy
+  dispatch that skipped `specify`, a session break, or a reuse
+  condition failed).
+
+Either way the orchestrator does NOT do recon in-context: reuse
+means reusing a prior *dispatch's* report, never the
+orchestrator's own tree-walking.
+
+Dispatch carrier: see the **Carrier contract** tables in
+`agents/plan-recon.md` (single source for `spec_path`,
+`iteration_scope`, `focus_hint`; the pre-spec `sources` form is
+`specify`'s dispatch, not planner's).
+
+Recon does NOT decide decomposition. Two *delta* dispatches in
+one planner run is the smell that the iteration scope is too
+broad — re-read the spec. A second *full* dispatch in a cycle
+that already has a valid cycle recon is a § Cycle recon budget
+violation, not a judgement call.
 
 The plan's "Files this plan creates or modifies" section
 keeps the same shape:
@@ -282,5 +299,8 @@ shell-`rm`'d alongside the spec at cycle close by `audit` (see
   task-by-task.
 - **Agents dispatched:**
   - `agents/plan-recon.md` — Step 2, file-structure mapping
-    (read-only). Mandatory; the orchestrator does NOT do
-    recon in-context.
+    (read-only). Normally reused from the cycle recon
+    (`../docs/pipeline.md` § Cycle recon); dispatched here only
+    for deltas, or in full when no valid cycle recon exists. The
+    file-map always comes from a dispatch's report; the
+    orchestrator does NOT do recon in-context.