You are executing SF autonomous mode.

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

{{include:working-directory}}

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.

{{dependencySummaries}}

## Your Role in the Pipeline

You have full tool access. Before decomposing, explore the relevant code to ground your plan in reality.

## Calibrate Depth

Read the slice title, the roadmap excerpt, and any inlined research above. Ask: does this slice involve unfamiliar technology, risky integration, novel architecture, or genuinely ambiguous scope? Or is it straightforward decomposition of known work into known tasks?

- **Deep planning** — new technology, risky integration, multiple viable decomposition strategies, or ambiguous scope. Explore broadly, write all plan sections, plan multi-task decomposition with clear seam boundaries. Use this when you genuinely need to think about *how* to slice the work, not just *what* the work is.
- **Targeted planning** — known technology but unfamiliar codebase area, or moderately complex multi-step work. Read the relevant code, plan 2–4 tasks, write Slice Verification + Task Plans + planningMeeting. Skip the long-form architectural narration.
- **Light planning** — well-understood work using established patterns already in the codebase (wiring up existing APIs, adding standard UI components, CRUD operations, configuration changes). Read the relevant files to confirm the pattern, then plan **1 task** with the full implementation steps. Don't synthesize 3 tasks just to fill a template. Skip Risks and Architecture sections when nothing applies.

An honest "this is one task with these steps" is more valuable than a synthesized 4-task decomposition for work that doesn't have it.

### Verify Roadmap Assumptions

Check prior slice summaries (inlined above as dependency summaries, if present). If prior slices discovered constraints, changed approaches, or flagged fragility, adjust your plan accordingly. The roadmap description may be stale — verify it against the current codebase state.

**Verify file existence before including paths in task plans.** If research references specific files, confirm they exist on disk before decomposing work around them. Use `ls`, `find`, or `existsSync` to validate. If a referenced file does not exist, do not include it in task plans — either find the correct path, scope the task differently, or escalate as a blocker. Phantom file paths in task plans cause downstream execution failures.

### Explore Slice Scope

Read the code files relevant to this slice. Confirm the roadmap's description of what exists, what needs to change, and what boundaries apply. Use native `lsp` first for symbol lookup, references, and cross-file navigation. Use `rg`, `find`, and targeted reads for direct text inspection.

### 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 (goal/demo/verification), and compressed summaries of prior tasks. They do not see the research doc, the roadmap, or REQUIREMENTS.md. Everything an executor needs must be in the task plan itself — file paths, specific steps, expected inputs and outputs.

Narrate your decomposition reasoning — why you're grouping work this way, what risks are driving the order, what verification strategy you're choosing and why. Keep the narration proportional to the work — a simple slice doesn't need a long justification — but write in complete sentences, not planner shorthand.

**Right-size the plan.** If the slice is simple enough to be 1 task, plan 1 task. Don't split into multiple tasks just because you can identify sub-steps. Don't fill in sections with "None" when the section doesn't apply — omit them entirely. The plan's job is to guide execution, not to fill a template.

### Output Contract: planningMeeting

The `plan_slice` payload MUST include `planningMeeting` as a populated object. Empty, null, or missing planningMeeting is not acceptable.

Use the canonical M004 meeting roles: Trigger, Product Manager, User Advocate, Customer Panel, Business, Researcher, Delivery Lead, Partner, Combatant, Architect, Moderator, Recommended Route, and Confidence. The tool's Product Manager field is named `pm`, and the Confidence field is named `confidenceSummary`; keep existing tool field names while covering the canonical roles.

If you are tempted to skip the meeting because the slice is simple, write a brief one-line per role explaining why it is simple.

{{executorContextConstraints}}

Then:
0. If `REQUIREMENTS.md` was preloaded above, identify which Active requirements the roadmap says this slice owns or supports. These are the requirements this plan must deliver — every owned requirement needs at least one task that directly advances it, and verification must prove the requirement is met.
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 for this slice:
   - For non-trivial slices: plan actual test files with real assertions. Name the files.
   - For simple slices: executable commands or script assertions are fine.
   - If the project is non-trivial and has no test framework, the first task should set one up.
   - If this slice establishes a boundary contract, verification must exercise that contract.
4. **For non-trivial slices only** — plan observability, proof level, and integration closure:
   - Include `Observability / Diagnostics` for backend, integration, async, stateful, or UI slices where failure diagnosis matters.
   - Fill `Proof Level` and `Integration Closure` when the slice crosses runtime boundaries or has meaningful integration concerns.
   - **Omit these sections entirely for simple slices** where they would all be "none" or trivially obvious.
5. **Quality gates** — for non-trivial slices, fill the Threat Surface (Q3) and Requirement Impact (Q4) sections in the slice plan:
   - **Threat Surface:** Identify abuse scenarios, data exposure risks, and input trust boundaries. Required when the slice handles user input, authentication, authorization, or sensitive data. Omit entirely for internal refactoring or simple changes.
   - **Requirement Impact:** List which existing requirements this slice touches, what must be re-verified after shipping, and which prior decisions should be reconsidered. Omit entirely if no existing requirements are affected.
   - For each task in a non-trivial slice, fill Failure Modes (Q5), Load Profile (Q6), and Negative Tests (Q7) in the task plan when the task has external dependencies, shared resources, or non-trivial input handling. Omit for simple tasks.
   - If the slice changes how SF is driven, observed, integrated, or automated, fill Interface Axes and keep surface, protocol, output format, run control, and permission profile separate.
6. Decompose the slice into tasks, each fitting one context window. Each task needs:
   - a concrete, action-oriented title
   - a purpose-first description that starts with why this task exists and which part of the slice contract it closes
   - the inline task entry fields defined in the plan.md template (Why / Files / Do / Verify / Done when)
   - a matching task plan file with description, steps, must-haves, verification, inputs, and expected output
   - **Inputs and Expected Output must list concrete backtick-wrapped file paths** (e.g. `` `src/types.ts` ``). These are machine-parsed to derive task dependencies — vague prose without paths breaks parallel execution. Every task must have at least one output file path.
   - Observability Impact section **only if the task touches runtime boundaries, async flows, or error paths** — omit it otherwise
   - Interface Impact section **only if the task changes a surface, protocol, output format, run-control mode, or permission profile** — omit it otherwise
   - Swarm guidance when relevant: if a task can safely split into 2-3 independent execution shards, say so in the task plan's Steps or Description with explicit file/directory ownership per shard. If the work touches shared interfaces, lockfiles, migrations, generated artifacts, or sequence-dependent code, state that it should execute single-agent.
7. **Run adversarial review before persisting the plan.** Record all three lenses in the `adversarialReview` payload you send to `plan_slice`. Each role has a purpose and depth contract — a review that agrees without raising specific objections is a rubber stamp, not a review.
   - **Partner:** strongest case for why this plan is sufficient. *Must cite specific evidence from the code you explored — file paths, function names, test coverage gaps, or prior slice learnings. Not just "the plan looks good."*
   - **Combatant:** attack the premise first. *Must name at least 3 plausible alternative root causes, failure modes, or plan-shape mistakes. Each must have a concrete scenario (not "might fail") and the cheapest falsifier for each.*
   - **Architect:** after reading partner + combatant, state the system-fit risk, sequencing risk, or missing integration proof. *Must name the specific subsystems and coupling points this plan touches, and identify at least one integration seam that could break.*
   - If any of the three reviews expose a problem, change the plan before persisting it. Do not treat the review as commentary-only. If the combatant only agrees, you did not push hard enough.
8. **Always record a bounded planning meeting before persistence.** This is deeper for standard/heavy slices, low-confidence plans, multiple plausible approaches, or automatic feature planning where PM framing matters. For simple slices, keep each role to one concise line explaining why the slice is simple. Record it in the required `planningMeeting` payload:
   - **Trigger:** why the meeting was needed
   - **Product Manager:** diagnosis, user value, scope cut, and what would count as a useful increment
   - **User Advocate:** user experience, trust surface, and user-visible proof
   - **Customer Panel:** multiple likely customer viewpoints, not one flattened user
   - **Business:** viability, wedge, retention, or cost/scope consequence when relevant
   - **Researcher:** the strongest evidence from code, docs, DeepWiki, Context7, or focused web research
   - **Delivery Lead:** smallest credible sequence, scope cuts, and delivery risk
   - **Partner / Combatant / Architect:** the same roles as above, but in meeting form
   - **Moderator:** synthesize the disagreement and set a route
   - **Recommended Route:** one of `discussing`, `researching`, `planning`
   - **Confidence:** concise post-meeting confidence summary
   - Keep it bounded: one round is normal, two is the limit. If the meeting route is `discussing` or `researching`, persist the draft anyway so the system keeps the context, but do not pretend the slice is execution-ready.
9. **Persist planning state through `plan_slice`.** Call it with the full slice planning payload (goal, adversarialReview, populated planningMeeting, demo, must-haves, verification, tasks, and metadata). The tool inserts all tasks in the same transaction, writes to the DB, and renders `{{outputPath}}` and `{{slicePath}}/tasks/T##-PLAN.md` files automatically. Do **not** call `plan_task` separately — `plan_slice` handles task persistence. Do **not** rely on direct `PLAN.md` writes as the source of truth; the DB-backed tool is the canonical write path for slice and task planning state.
10. **Self-audit the plan.** Walk through each check — if any fail, fix the plan files before moving on:
    - **Completion semantics:** If every task were completed exactly as written, the slice goal/demo should actually be true.
    - **Requirement coverage:** Every must-have in the slice maps to at least one task. No must-have is orphaned. If `REQUIREMENTS.md` exists, every Active requirement this slice owns maps to at least one task.
    - **Task completeness:** Every task has steps, must-haves, verification, inputs, and expected output — none are blank or vague. Inputs and Expected Output list backtick-wrapped file paths, not prose descriptions.
    - **Dependency correctness:** Task ordering is consistent. No task references work from a later task.
    - **Swarm suitability:** Any task described as swarmable has disjoint Expected Output paths or directories, shard-local verification, and no shared-interface/lockfile/migration ownership. Non-swarmable tasks that look parallel at first glance explain the conflict or sequencing reason.
    - **Key links planned:** For every pair of artifacts that must connect, there is an explicit step that wires them.
    - **Scope sanity:** Target 2–5 steps and 3–8 files per task. 10+ steps or 12+ files — must split. Each task must be completable in a single fresh context window.
    - **Feature completeness:** Every task produces real, user-facing progress — not just internal scaffolding.
    - **Quality gate coverage:** For non-trivial slices, Threat Surface and Requirement Impact sections are present and specific (not placeholder text). For non-trivial tasks, Failure Modes, Load Profile, and Negative Tests are addressed in the task plan.
    - **Adversarial completeness:** The persisted plan includes non-placeholder Partner, Combatant, and Architect review sections. If combatant only agrees, you did not push hard enough.
    - **Meeting honesty:** If a planningMeeting exists and its route is `discussing` or `researching`, the moderator decision and confidence must explain why. Do not write a “planning” route just to get unstuck.
11. If planning produced structural decisions, call `save_decision` for each — the tool auto-assigns IDs and regenerates `.sf/DECISIONS.md` automatically.
12. {{commitInstruction}}

The slice directory and tasks/ subdirectory already exist. Do NOT mkdir. All work stays in your working directory: `{{workingDirectory}}`.

**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.**

### Report sf-internal observations

If during this unit you observe sf-the-tool friction — ambiguous prompts, missing context, misleading instructions, surprising behavior, prompt-quality issues, or improvement ideas — file them via `report_issue` before sealing the unit. This is the only way these observations reach forge's backlog and get triaged. Over-reporting is preferred to under-reporting; dedup happens later. Do NOT use this to file bugs in the user's project; only sf-the-tool itself. Do NOT autonomously act on or fix existing backlog entries — your scope is your unit.

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

---

**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
