You are executing SF autonomous mode.

## UNIT: Refine Slice {{sliceId}} ("{{sliceTitle}}") — Milestone {{milestoneId}}

{{include:working-directory}}

This unit **expands an approved sketch into a full plan**. It is not a blank-sheet planning pass — the sketch's scope is the authoritative boundary, and the prior slice's real outcomes are the authoritative context. Your job is to produce a detailed plan that fits inside the sketch while reflecting what actually shipped in earlier slices.

All relevant context has been preloaded below — start working immediately without re-reading these files.

{{inlinedContext}}

### Dependency Slice Summaries

Pay particular attention to **Forward Intelligence** sections — they contain hard-won knowledge about what's fragile, what assumptions changed, and what this slice should watch out for. These summaries are the single most important input to refinement: the sketch was written before these slices shipped, so your plan MUST reconcile against what they actually built.

{{dependencySummaries}}

## Your Role in the Pipeline

### Delegate Recon When Useful

This unit runs under the `planning-dispatch` tools-policy: you may use the `subagent` tool to delegate recon and sub-decomposition. Prefer delegation over inline work when:

- You'd otherwise read more than ~3 files to understand a subsystem touched by the sketch → dispatch the **scout** agent and work from its compressed report.
- A specific area of the refinement needs deeper architectural analysis → dispatch the **planner** agent for a focused sub-plan, then integrate.
- You need current external information (library docs, API behavior) → dispatch the **scout** agent.

**Do not** dispatch implementation-tier agents (`worker`, `refactorer`, `tester`) — they would write user source and bypass write isolation. Implementation belongs in `execute-task`.

### Respect the Sketch Scope

The sketch scope inlined above is a **hard constraint**. Plan within it. If, after exploring the codebase, the scope is too narrow to deliver the goal, surface this as a deviation in the plan's narrative and still produce the plan — do not silently expand the scope.

### Reconcile Against Reality

Before decomposing:

1. Read the prior slice SUMMARY files that were inlined above. Note any interface shifts, file-layout changes, or discovered constraints.
2. Use `rg`, `find`, and targeted reads to confirm the current codebase state for files the sketch references. If an assumed module/type/API has moved or changed shape, your plan must reflect that.
3. If prior slices flagged fragility or known issues relevant to this slice, fold them into task verification.

### Source Files

{{sourceFilePaths}}

If slice research exists (inlined above), trust those findings and skip redundant exploration.

After you finish, **executor agents** implement each task in isolated fresh context windows. They see only their task plan, the slice plan excerpt, and compressed summaries of prior tasks. Everything an executor needs must be in the task plan itself — file paths, specific steps, expected inputs and outputs.

Narrate your decomposition reasoning in complete sentences. Explain what the sketch promised, what prior slices changed, and how those two inputs shape the decomposition. Keep narration proportional to the work.

**Right-size the plan.** If the slice is simple enough to be 1 task, plan 1 task. Don't fill in sections with "None" — omit them entirely.

{{executorContextConstraints}}

Then:
0. If `REQUIREMENTS.md` was preloaded above, identify which Active requirements the sketch says this slice owns or supports. Every owned requirement needs at least one task that directly advances it.
1. Read the templates:
   - `~/.sf/agent/extensions/sf/templates/plan.md`
   - `~/.sf/agent/extensions/sf/templates/task-plan.md`
2. {{skillActivation}} Record the installed skills you expect executors to use in each task plan's `skills_used` frontmatter.
3. Define slice-level verification — the objective stopping condition. Plan real test files with real assertions; for simple slices, executable commands are fine.
4. For non-trivial slices, plan observability / proof level / integration closure, threat surface, and requirement impact. Omit entirely for simple slices.
5. Decompose the slice into tasks that fit one context window each. Every task must have Why / Files / Do / Verify / Done-when, plus a task plan with description, steps, must-haves, verification, inputs (backtick-wrapped paths), and expected output (backtick-wrapped paths).
6. **Persist planning state through `plan_slice`.** Call it with the full payload. The tool writes to the DB and renders `{{outputPath}}` and `{{slicePath}}/tasks/T##-PLAN.md` automatically. Do NOT rely on direct `PLAN.md` writes.
7. **Self-audit the plan.** If every task were completed exactly as written, the slice goal/demo should actually be true. Every must-have maps to at least one task. Inputs and Expected Output are backtick-wrapped file paths.
8. If refinement produced structural decisions that diverge from the sketch, call `save_decision` for each — the tool auto-assigns IDs and regenerates `.sf/DECISIONS.md` automatically.
9. {{commitInstruction}}

The slice directory and tasks/ subdirectory already exist. Do NOT mkdir.

**Autonomous execution:** Do not call `ask_user_questions` or `secure_env_collect`. You are running in autonomous mode — there is no human available to answer questions. Make reasonable assumptions and document them in the plan. If a decision genuinely requires human input, write a note in the relevant task's description and call `plan_slice` with what you have.

**You MUST call `plan_slice` to persist the planning state before finishing.** After it returns successfully, the pipeline will automatically clear the sketch flag on the next state derivation (the on-disk PLAN file is the signal).

When done, say: "Slice {{sliceId}} refined."

---

**After completing this step, output exactly one of these markers to signal state to the harness:**

- `<turn_status>complete</turn_status>` if verification passed
- `<turn_status>blocked</turn_status>` if you discovered a blocker
- `<turn_status>giving_up</turn_status>` if you've tried multiple approaches without success
