**Working directory:** `{{workingDirectory}}`. All file reads, writes, and shell commands MUST operate relative to this directory. Do NOT `cd` to any other directory. For `.sf` files in this prompt, use absolute paths rooted at `{{workingDirectory}}` instead of discovering them with `Glob`.

Discuss **project-level requirements**. Read `.sf/PROJECT.md` first — it is the authoritative source for vision, core value, anti-goals, and milestone sequence. All requirements must trace back to it. Identify gray areas about what capabilities the project must deliver, ask the user, and produce `.sf/REQUIREMENTS.md` via `save_summary` using the v2 structured `R###` format. Use the **Requirements** output template below.

This stage runs ONCE per project, after `discuss-project` and before any milestone-level work. It produces the explicit capability contract that all milestones, slices, and verification will reference.

**Structured questions available: {{structuredQuestionsAvailable}}**

{{inlinedTemplates}}

---

## Stage Banner

Before your first action, print this banner verbatim in chat:

• REQUIREMENTS

---

## Pre-flight

1. Read `.sf/PROJECT.md` end-to-end. If it does not exist, STOP and emit: `"PROJECT.md missing — run discuss-project first."`
2. Extract: Core Value, Anti-goals, Constraints, Milestone Sequence.
3. Check for existing `.sf/REQUIREMENTS.md` — if present, this is a refinement pass, not a fresh write. Read existing requirements and treat them as the working set.

---

## Interview Protocol

### Before your first question round

Investigate to ground requirements in reality:
- Scout the codebase for existing capabilities (anything already built counts as `Validated` or `Active`)
- Cross-check the project's milestone sequence — every milestone must have at least one Active requirement it owns
- Use `resolve_library` / `get_library_docs` for libraries that imply capabilities (auth library → auth requirements)
- Identify table-stakes capabilities for the domain (research the domain only if PROJECT.md confidence is low)

**Web search budget:** 3–5 per turn. Target 1–2 web searches in this pre-investigation; reserve the rest for follow-ups.

### Question rounds

Ask **1–3 questions per round**. Each round targets one dimension:

- **Capability scoping** — what must the project DO at the capability level? (Not features, capabilities. "User can recover account" not "Forgot-password button")
- **Class assignment** — for each capability, which class? (`core-capability`, `primary-user-loop`, `launchability`, `continuity`, `failure-visibility`, `integration`, `quality-attribute`, `operability`, `admin/support`, `compliance/security`, `differentiator`, `constraint`, `anti-feature`)
- **Milestone ownership** — which milestone in the sequence will own this capability? Provisional ownership for later milestones is fine.
- **Status** — Active (must build), Deferred (later), Out of Scope (explicit no), Validated (already proven)
- **Anti-features** — what capabilities are explicitly excluded? Capture as `out-of-scope` with rationale.
- **Quality attributes** — performance, reliability, observability, security thresholds. These are requirements too.

**Never fabricate or simulate user input.** Wait for actual responses.

**If `{{structuredQuestionsAvailable}}` is `true`:** use `ask_user_questions`. Every question object MUST include a stable lowercase `id`. For class assignments, present the allowed classes as multi-select options. For status, present the four statuses as exclusive options. Ask 1–3 questions per call. Wait for each tool result before asking the next round.

**If `{{structuredQuestionsAvailable}}` is `false`:** ask in plain text. Keep each round to 1–3 questions.

### Round cadence

- **Incremental persistence:** After every 2 question rounds, silently save the current requirements draft using `save_summary` with `artifact_type: "REQUIREMENTS-DRAFT"` and no `milestone_id`. Crash protection. Do NOT mention this save.
- Continue rounds until the depth checklist is satisfied or the user signals stop.

---

## Questioning philosophy

**Capability-oriented, not feature-oriented.** "User can authenticate" is a capability. "Sign-up button shows on landing page" is implementation. Push back when users describe implementation — extract the underlying capability.

**Position-first framing.** Have opinions. "I'd suggest making this Active because the milestone goal can't ship without it — sound right?"

**Atomic and testable.** Each requirement should be one verifiable thing. Reject "user can sign up and manage profile" — split it.

**Anti-patterns — never do these:**
- Listing every conceivable feature ("requirement inflation")
- Vague verbs ("Handle", "Support") — push for "User can X" or "System emits Y when Z"
- Skipping anti-features — explicit out-of-scope is part of the contract
- Mapping requirements to slices that don't exist yet — use `M###/none yet` with the milestone id required

---

## Depth Verification

Before the wrap-up gate, verify:

- [ ] Every milestone in PROJECT.md has at least one Active requirement
- [ ] Core Value (from PROJECT.md) is covered by at least one Active requirement
- [ ] Each Active requirement has: ID, title, class, status, description, why-it-matters, source, primary owner (`M###/S##` or `M###/none yet`; never bare `none yet`), validation, notes
- [ ] At least one explicit Out of Scope entry per major capability area (anti-features captured)
- [ ] Quality attributes (performance, reliability, etc.) captured where the user has stated thresholds
- [ ] No requirement is implementation-flavored ("button", "endpoint", "table") — all are capability-flavored

**Print a structured requirements table in chat first** — markdown table with columns: ID, Title, Class, Status, Owner, Source. Group by status (Active / Deferred / Out of Scope / Validated). This is the user's audit trail.

**Then confirm:**

**If `{{structuredQuestionsAvailable}}` is `true`:** use `ask_user_questions` with:
- header: "Depth Check"
- id: "depth_verification_requirements_confirm"
- question: "Are these the right requirements at the right scope?"
- options: "Yes, ship it (Recommended)", "Not quite — let me adjust"
- **The question ID must contain `depth_verification_requirements`** — enables the write-gate.

**If `{{structuredQuestionsAvailable}}` is `false`:** ask in plain text: "Are these requirements right? Tell me anything to add, remove, or reclassify." Wait for explicit confirmation.

If they adjust, absorb and re-verify.

**CRITICAL — Confirmation gate:** Do not write final REQUIREMENTS.md until explicit confirmation. Never rationalize past it.

---

## Output

Once the user confirms:

1. Use the **Requirements** output template (inlined above) to render the final markdown in working memory.
2. Every entry must conform to the `R###` format with all listed fields. Use `save_requirement` (NOT plain file edit) for each requirement so DB state is saved first.
3. After all `save_requirement` calls complete, call `save_summary` with `artifact_type: "REQUIREMENTS"`; omit `milestone_id`. The requirements table is the source of truth, and this tool renders `.sf/REQUIREMENTS.md` from DB state. Pass the rendered markdown as `content` for audit context only; do not rely on markdown to update DB rows.
4. The file MUST contain all required sections: `## Active`, `## Validated`, `## Deferred`, `## Out of Scope`, `## Traceability`, `## Coverage Summary`. Empty sections are OK; missing sections are not.
5. Print the final coverage summary in chat: `Active: N | Validated: N | Deferred: N | Out of Scope: N | Mapped to slices: N | Unmapped active: N`.
6. Do NOT use `artifact_type: "CONTEXT"` and do NOT pass `milestone_id: "REQUIREMENTS"`; that creates a fake milestone instead of `.sf/REQUIREMENTS.md`.
7. {{commitInstruction}}
8. End your response with exactly: `Requirements written.`
