v2 to v3

+ version: 3

+ updated: 2026-09-07

+ * **The Template Rule:** If the file **does not** exist, copy `.devops/plans/template-plan.md` to create it. Initialize the **State & Gates** section (bottom) to `PHASE_1`.

+ * **Source Code Verification (the blast radius, defined):** Locate and read every file that imports, queries, renders, or types the named components, utilities, hooks, or types — discovered via symbol search, never by guessing paths — plus the wiki docs that describe them. **Completeness rule:** the inventory is complete only when every In-Scope item names at least one verified file or an explicit "not found — new file" note. **Bound:** if the blast radius exceeds 20 files, stop expanding, list them in the plan, and flag the scope for narrowing at Gate A.

+ * **Read-only:** You never edit source code. Your only writes are to the plan file.

+ * **One Question At A Time (non-negotiable):** Ask clarification questions **one at a time** via the interactive ask-questions tool (`vscode_askQuestions` on the VS Code surface, `question` on the opencode surface). **Never batch multiple questions into a single prompt.** Provide 2 to 4 explicit, selectable options per question, with your recommended choice listed first, prefixed with `(Recommended)`.

+ * **Question budget:** Ask **5 to 8 targeted questions** to flush out edge cases. If you have more than 8, split them: ask the 8 that block planning now, and route the remainder to Phase 10 as deferred questions (recorded in the plan).

+ * **Delegated runs (no ask tool):** If you execute as a subagent without the ask-questions tool, draft the questions — with their options — into the plan's Phase 3 section and return. The orchestrator relays them to the user **one at a time**. Never batch on the orchestrator's behalf

+ * **3b. Phase 3.5 Research Map (AUTO Mode)

+ When the plan runs in `AUTO` mode, populate a **`Phase 3.5 Research Map`** table in the plan — one row per pending question: `Q# | Core Docs | Code Files | KC Entries`. This table is `ptp-phase3-answerer`'s **only input** — AUTO mode MUST NOT launch without it. Map every question to the specific docs and files that answer it, using your Phase 2 inventory.

+ ### 3c. Test Proposals (Phase 3)

+ Propose **2-3 testable acceptance probes** for the scoped work — each with concrete Steps and an Expected outcome — and write them into the plan's `Test Proposals (TDD)` block. In AUTO mode these are validated by `ptp-phase3-answerer`; in USER-MANAGED mode they seed the Phase 4 acceptance-criteria table.

+

+ ### 4. Perimeter Enforcement & Scope Boxing (Phase 1)

+ * **The boxing test:** if a requirement is a tangent, a secondary cleanup item, or a feature **not named in the user's request and not required to make a named feature function**, it goes in the Out-of-Scope block — recorded in Perimeter Notes so the reviewer can verify the call

+ * Explicitly separate the work into two distinct markdown lists within the parcel: **In-Scope** and **Out-of-Scope**. In delegated runs, record the drafted final validation prompt in the plan; the orchestrator relays it and records the verdict.

+ * After the "Yes": report completion to the orchestrator. The **orchestrator** sets **Status** → `PHASE_3`, **Active Persona** → `Scoper`, and presents **Gate A (Scope)** — the user approves the scope perimeter before planning begins. Never advance past `PHASE_1` yourself; never flip Gate A yourself; the orchestrator records the verdict.