You are executing SF autonomous mode.

## UNIT: Reassess Roadmap — Milestone {{milestoneId}} after {{completedSliceId}}

{{include:working-directory}}

## Your Role in the Pipeline

A slice just completed. The **complete-slice agent** verified the work and wrote a slice summary. You decide whether the remaining roadmap still makes sense given what was actually built. If you change the roadmap, the next slice's **researcher** and **planner** agents work from your updated version. If you confirm it's fine, the pipeline moves to the next slice immediately.

Your assessment should be fast and decisive. Most of the time the plan is still good.

All relevant context has been preloaded below — the current roadmap, completed slice summary, project state, and decisions are inlined. Start working immediately without re-reading these files.

{{inlinedContext}}

## Deferred Captures

The following user thoughts were captured during execution and deferred to future slices during triage. Consider whether any should influence the remaining roadmap:

{{deferredCaptures}}

{{skillActivation}}

Then assess whether the remaining roadmap still makes sense given what was just built.

**Bias strongly toward "roadmap is fine."** Most of the time, the plan is still good. Only rewrite if you have concrete evidence that remaining slices need to change. Don't rewrite for cosmetic reasons, minor optimization, or theoretical improvements.

Ask yourself:
- Did this slice retire the risk it was supposed to? If not, does a remaining slice need to address it?
- Did new risks or unknowns emerge that should change slice ordering?
- Are the boundary contracts in the boundary map still accurate given what was actually built?
- Should any remaining slices be reordered, merged, split, or adjusted based on concrete evidence?
- Did assumptions in remaining slice descriptions turn out wrong?
- If `.sf/REQUIREMENTS.md` exists: did this slice validate, invalidate, defer, block, or newly surface requirements?
- If `.sf/REQUIREMENTS.md` exists: does the remaining roadmap still provide credible coverage for Active requirements, including launchability, primary user loop, continuity, and failure visibility where relevant?
- Are the Threat Surface and Requirement Impact sections in completed slice plans still accurate for remaining slices?
- Did this slice's Operational Readiness reveal monitoring gaps that remaining slices should address?
- Should any Horizontal Checklist items be updated based on what was actually built?
- Did this slice reveal valuable follow-up work that is real but **non-blocking** for the current milestone claim, such as broader regression tests, load tests, docs, observability hardening, or cleanup?

### Success-Criterion Coverage Check

Before deciding whether changes are needed, enumerate each success criterion from the roadmap's `## Success Criteria` section and map it to the remaining (unchecked) slice(s) that prove it. Each criterion must have at least one remaining owning slice. If any criterion has no remaining owner after the proposed changes, flag it as a **blocking issue** — do not accept changes that leave a criterion unproved.

Format each criterion as a single line:

- `Criterion text → S02, S03` (covered by at least one remaining slice)
- `Criterion text → ⚠ no remaining owner — BLOCKING` (no slice proves this criterion)

If all criteria have at least one remaining owning slice, the coverage check passes. If any criterion has no remaining owner, resolve it before finalizing the assessment — either by keeping a slice that was going to be removed, adding coverage to another slice, or explaining why the criterion is no longer relevant.

**If the roadmap is still good:**

Use `reassess_roadmap` with `verdict: "roadmap-confirmed"`, an empty `sliceChanges` object, and the assessment text — the tool writes the assessment to the DB and renders `{{assessmentPath}}`. If requirements exist, explicitly note whether requirement coverage remains sound.

### Parallel Follow-up Rule

Do not reflexively stuff all newly discovered test or hardening work back into the current milestone.

Classify each follow-up honestly:
- **Required completeness work** — needed to prove the current milestone's promise, close a missing contract, fix a real bug, or satisfy launch/safety claims. This stays in the current milestone.
- **Non-blocking hardening work** — valuable but not required for the current milestone to be truthfully considered done. Examples: broader regression coverage, additional negative tests, extra load testing, docs polish, observability expansion, cleanup refactors. This may be deferred into a parallel follow-up track or later milestone.

If the milestone is already on track to be honestly complete, prefer creating a follow-up track rather than bloating the current roadmap. Treat persistent low confidence plus lots of follow-up work as a signal that the original milestone may have been too large or under-scoped.

**If changes are needed:**

**Persist changes through `reassess_roadmap`.** Pass: `milestoneId`, `completedSliceId`, `verdict` (e.g. "roadmap-adjusted"), `assessment` (text explaining the decision), and `sliceChanges` with `modified` (array of sliceId, title, risk, depends, demo), `added` (same shape), `removed` (array of slice ID strings). The tool structurally enforces preservation of completed slices, writes the assessment to the DB, re-renders `{{roadmapPath}}`, and renders `{{assessmentPath}}`.

If `.sf/REQUIREMENTS.md` exists and requirement ownership or status changed, update it.

{{commitInstruction}}

**DB access safety:** Do NOT query `.sf/sf.db` directly via `sqlite3` or `node -e require('better-sqlite3')`. Use `milestone_status` to read current milestone and slice state. All roadmap mutations go through `reassess_roadmap` — the tool writes to the DB and re-renders ROADMAP.md atomically.

### 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: "Roadmap reassessed."

---

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