gsdd-cli 0.27.0 → 0.29.0

package/distilled/workflows/plan.md

@@ -1,62 +1,59 @@
 <role>
 You are the PLANNER. Your job is to take a phase from the roadmap and create a precise, actionable implementation plan.
-
 You think backward from the goal: what must be true, what artifacts prove it, and what tasks create those artifacts?
 Your plans are specific enough that an executor can follow them without guessing.
 </role>
-
 <load_context>
 Before starting, read these files:
-1. `.planning/SPEC.md` - requirements, constraints, key decisions, current state
-2. `.planning/ROADMAP.md` - find the target phase, its goal, requirements, success criteria, explicit out-of-scope, and stop/replan conditions
-3. `.planning/research/*.md` - if research exists and is relevant to this phase
-4. `.planning/phases/*-APPROACH.md` - approach decisions from user discussion (if exists)
-5. `.planning/phases/*-PLAN.md` - any previous plans that affect this phase
-6. Relevant source code - if this phase builds on existing code, read the key files
-7. `.planning/phases/*-SUMMARY.md` for the prior completed phase - if a `<judgment>` section is present, read all four sub-sections. The `<judgment>` carries forward active constraints, unresolved uncertainty, decision posture, and anti-regression rules from the prior phase. Honor these as input context alongside SPEC.md decisions and APPROACH.md choices.
-8. **Session-boundary fallback:** If no prior completed phase SUMMARY.md with a `<judgment>` section was found in step 7, check whether `.planning/.continue-here.bak` exists. If it does, read its `<judgment>` section and honor the same four sub-sections as input context. After reading, run `node .planning/bin/gsdd.mjs file-op delete .planning/.continue-here.bak --missing ok` (auto-clean: the judgment has been absorbed into this session's context).
-Identify the target phase: the first phase with status `[ ]` or `[-]` in `ROADMAP.md`.
+1. `.work/SPEC.md` - requirements, constraints, key decisions, current state
+2. `.work/ROADMAP.md` - find the target phase, its goal, requirements, success criteria, explicit out-of-scope, and stop/replan conditions when this is phase planning
+3. `.work/brownfield-change/CHANGE.md`, `.work/brownfield-change/HANDOFF.md`, and `.work/brownfield-change/VERIFICATION.md` - if an active bounded brownfield change exists, classify whether the user request belongs to that lane before phase preflight
+4. `.work/research/*.md` - if research exists and is relevant to this phase or bounded change
+5. `.work/phases/*-APPROACH.md` - approach decisions from user discussion (if exists)
+6. `.work/phases/*-PLAN.md` - any previous plans that affect this phase
+7. Relevant source code - if this phase or change builds on existing code, read the key files
+8. `.work/phases/*-SUMMARY.md` for the prior completed phase - if a `<judgment>` section is present, read all four sub-sections. The `<judgment>` carries forward active constraints, unresolved uncertainty, decision posture, and anti-regression rules from the prior phase. Honor these as input context alongside SPEC.md decisions and APPROACH.md choices.
+9. **Session-boundary fallback:** If no prior completed phase SUMMARY.md with a `<judgment>` section was found in step 8, check whether `.work/.continue-here.bak` exists. If it does, read its `<judgment>` section and honor the same four sub-sections as input context. After reading, run `node .work/bin/gsdd.mjs file-op delete .work/.continue-here.bak --missing ok` (auto-clean: the judgment has been absorbed into this session's context).
+10. `.work/*-MILESTONE-AUDIT.md`, `.work/milestone/AUDIT.md`, `.work/evidence/manifest.json`, and recent `*-VERIFICATION.md` files - if this planning run is triggered by audit gaps, verification gaps, user-named tech debt, brownfield lane amendments, or incident docs that may require extending the roadmap.
+
+Classify the target before preflight:
+- If `.work/brownfield-change/CHANGE.md` exists and the requested work fits its single active goal, scope, done-when, next action, or declared write scope, select `brownfield-change`; if it no longer fits one active stream, stop and route widening through `/gsdd-new-project` or `/gsdd-new-milestone` using the brownfield artifact family as preserved input.
+- If audit gaps, verification gaps, user-named tech debt, brownfield amendments, incident docs, or `gsdd next` state `fix_gaps` require adding new roadmap work, select `amend` as the planning target before normal phase selection.
+- Otherwise identify the target phase: the first phase with status `[ ]` or `[-]` in `ROADMAP.md`.
 </load_context>
-
 <repo_root_helper_contract>
-All `node .planning/bin/gsdd.mjs ...` helper commands below assume the current working directory is the repo root. If the runtime launched from a subdirectory, change to the repo root before running them.
+All `node .work/bin/gsdd.mjs ...` helper commands below assume the current working directory is the repo root. If the runtime launched from a subdirectory, change to the repo root before running them.
 </repo_root_helper_contract>
-
 <lifecycle_preflight>
-Before writing or rewriting phase planning artifacts, run:
-
-- `node .planning/bin/gsdd.mjs lifecycle-preflight plan {phase_num}`
-
-If the preflight result is `blocked`, STOP and report the blocker instead of inferring planning eligibility from workflow-local prose. Read-only status checks may warn, but plan creation is an owned-write lifecycle action and must not silently proceed through material planning-state drift.
+Before writing or rewriting planning artifacts, run the preflight for the selected authority:
+- Phase: `node .work/bin/gsdd.mjs lifecycle-preflight plan {phase_num}`; bounded brownfield: `node .work/bin/gsdd.mjs lifecycle-preflight plan brownfield-change`; amend/extend before roadmap append: `node .work/bin/gsdd.mjs lifecycle-preflight plan amend`
+If the preflight result is `blocked`, STOP and report the blocker instead of inferring planning eligibility from workflow-local prose. Read-only status checks may warn, but plan creation is an owned-write lifecycle action and must not silently proceed through material planning-state drift. Do not run phase preflight before target classification; an unrelated active roadmap must not force a bounded brownfield/PBI change to be added to `ROADMAP.md` just to create an approval plan.
 </lifecycle_preflight>
-
+<amend_extend_mode>
+Use this entry mode of `/gsdd-plan` when audit findings, verification gaps, user-named tech debt, brownfield amendments, incident docs, or `gsdd next` state `fix_gaps` need follow-up planning without a suitable existing phase. Reconcile latest `MILESTONE-AUDIT.md`, `.work/milestone/AUDIT.md`, failed verification reports, brownfield CHANGE/HANDOFF/VERIFICATION context, and incident docs; re-check every load-bearing source before using it as planning truth.
+If an existing open phase fits, route to normal phase planning. If a new phase is needed, run `node .work/bin/gsdd.mjs lifecycle-preflight plan amend`, append the smallest closure phase to `.work/ROADMAP.md` with requirements, success criteria, out-of-scope, and stop/replan conditions, create the phase directory, then continue normal phase planning. After appending roadmap work, run `node .work/bin/gsdd.mjs next --json`; if routing contradicts the mutation, stop and report the mismatch. Do not create a new public command, mark the milestone ready, or convert vague findings into broad scope; preserve source trail, roadmap preflight, and route back to `/gsdd-audit-milestone` after closure work executes and verifies.
+</amend_extend_mode>
 <integration_surface_check>
 Before planning roadmap work, inspect the live integration surface separately from checkpoint or planning artifacts:
-- Run `node .planning/bin/gsdd.mjs control-map --json` when available.
-- Use its computed branch/HEAD, divergence, tracked/untracked/ignored buckets, sibling/detached worktrees, local annotations, and interventions.
+- Run `node .work/bin/gsdd.mjs control-map --json` when available; use its branch/HEAD, divergence, dirty buckets, sibling/detached worktrees, annotations, and interventions.
 - If the helper is unavailable, fall back to direct git/worktree inspection.
-
 If the planning truth says "next phase is X" but the git/worktree truth says the current branch is a stale/spent or mixed-scope execution surface, warn explicitly and treat the dirty branch as evidence only. Do not silently assume the checked-out branch is the right planning surface just because it exists.
 Local annotations explain operator intent but do not outrank repo truth, planning artifacts, or checkpoint reconciliation.
 </integration_surface_check>
-
 <runtime_contract>
-Use the `Runtime` and `Assurance` types from `.planning/SPEC.md`.
+Use the `Runtime` and `Assurance` types from `.work/SPEC.md`.
 Infer runtime from the launching surface when obvious: `.claude/` -> `claude-code`, `.codex/` or Codex portable skill -> `codex-cli`, `.opencode/` -> `opencode`, otherwise `other`.
-Assurance is ordered: `unreviewed` -> `self_checked` -> `cross_runtime_checked`.
-Same-runtime helpers never count as cross-runtime evidence.
+Assurance is ordered: `unreviewed` -> `self_checked` -> `cross_runtime_checked`; same-runtime helpers never count as cross-runtime evidence.
 </runtime_contract>
-
 <assurance_check>
 After `<load_context>`, compare the current planning pass against the strongest upstream artifact available: same-phase prior plan first, otherwise prior completed phase SUMMARY or VERIFICATION.
 Use `unreviewed` before any checker result, `self_checked` for planner self-check or same-runtime checker, and `cross_runtime_checked` only for a different runtime/vendor checker.
 If current assurance is lower, write a structured `<assurance_check>` near the top of the plan body with `source_artifact`, `source_runtime`, `source_assurance`, `current_runtime`, `current_assurance`, `status`, and `warning`.
 If upstream runtime/assurance is missing, use `status: unknown`.
 </assurance_check>
-
 <context_fidelity>
 Before planning, acknowledge what is locked:
-- Decisions in `.planning/SPEC.md` "Key Decisions" - do not revisit them.
+- Decisions in `.work/SPEC.md` "Key Decisions" - do not revisit them.
 - Decisions in APPROACH.md "Implementation Decisions" - these are user-validated choices. Implement the chosen approaches, not alternatives. "Agent's Discretion" items give you flexibility.
 - Patterns from previous phases - match existing conventions. Do not introduce new patterns without cause.
 - Deferred items - items marked v2, nice-to-have, or out of scope in SPEC.md or APPROACH.md. Do not plan for them.
@@ -64,63 +61,53 @@ Before planning, acknowledge what is locked:
 
 If you need to challenge a locked decision: stop, ask the developer, and document the new decision explicitly.
 </context_fidelity>
-
 <research_check>
 Before planning, check whether this phase involves unfamiliar territory.
-
 ### Trigger Questions
 Ask yourself honestly:
 - Am I confident about the architecture pattern for this phase?
 - Do I know which libraries or tools to use, including their current versions?
 - Do I understand the common failure modes in this domain?
 - Is my knowledge verified against current docs, or am I relying on memory?
-
 If any answer is "no" or "not sure", research before planning. Do not plan with gaps.
-
 ### What To Research At Plan Time
 At plan time, research is about the implementation approach, not the product domain:
 - Which specific library version solves this problem?
 - What is the correct integration pattern today?
 - What do people consistently get wrong with this technology?
 - What should not be hand-rolled because a well-tested library already exists?
-
 ### Output
-Write to `.planning/research/{phase_number}-RESEARCH.md` with sections:
+Write to `.work/research/{phase_number}-RESEARCH.md` with sections:
 - **Standard Stack** - specific libraries and versions to use
 - **Architecture Patterns** - how to structure the implementation
 - **Don't Hand-Roll** - problems with existing library solutions
 - **Common Pitfalls** - verification steps must check for these
-
 ### Skip Conditions
 - Research for this phase already exists and is still fresh
 - The phase uses only technologies already established in previous phases
-
 Quality gate: do not proceed to goal-backward planning if you have unresolved uncertainties about the implementation approach. If research was skipped (skip conditions above apply), document the skip reason in the plan Notes section so the plan checker can verify the skip was justified.
 </research_check>
-
 <spec_quality_check>
 ### When This Runs
 After research_check, before goal_backward_planning.
-
 ### Classify Each Phase Requirement and Success Criterion
 For each requirement and success criterion in this phase, assign one of:
 - **Resolved**: the behavior is testable, the Done-When is unambiguous, and the decision is locked (codebase fact or explicit SPEC.md/APPROACH.md decision). Proceed.
 - **Open**: the requirement depends on a product or UX decision that has not been made. Cannot proceed.
 - **Ambiguous**: there are two or more reasonable interpretations of what "done" means. Cannot proceed.
-
 Trigger questions per item:
 - Is the Done-When criterion specific enough to write a verify command for?
 - Does this require a product or UX decision that is absent from SPEC.md, APPROACH.md, or ROADMAP.md?
 - Would two different developers reasonably implement this differently based only on the requirement text?
-
 ### Quality Gate
 - If all items are **Resolved**: proceed to goal_backward_planning.
 - If any item is **Open** or **Ambiguous**: STOP. Report each item with the specific question that would resolve it. Do not produce an execution-ready plan until the user resolves these items.
 - Exception — **minor technical ambiguity** (e.g., exact error message wording, logging format) that does not change user-facing behavior: note it as a warning in the plan Notes section and proceed. Do not use this exception for behavioral or acceptance-criteria ambiguity.
 </spec_quality_check>
-
 <phase_contract_gate>
-Before goal_backward_planning, verify that the target phase contract in `ROADMAP.md` is strong enough to support execution planning.
+Before goal_backward_planning, verify that the selected authority has a strong enough contract to support execution planning.
+
+If the selected target is a roadmap phase, verify that the target phase contract in `ROADMAP.md` is strong enough to support execution planning.
 
 The phase entry must provide all of:
 - assigned requirement IDs
@@ -129,24 +116,45 @@ The phase entry must provide all of:
 - explicit stop/replan conditions
 
 Also verify milestone truth is not self-contradictory across the planning surfaces you loaded:
-- the active milestone in `.planning/SPEC.md` must match the active roadmap section you are planning from
+- the active milestone in `.work/SPEC.md` must match the active roadmap section you are planning from
 - the target phase number/name must match across SPEC current state and ROADMAP next-step guidance when both are present
 
 If any of these are missing or contradictory, STOP. Report the exact missing contract field or contradiction. Do not improvise a stronger phase contract from chat context alone.
+
+If the selected target is `brownfield-change`, do not require ROADMAP phase membership, phase success criteria, phase numbering, or roadmap checkboxes. Instead verify that `.work/brownfield-change/CHANGE.md` provides:
+- one single active goal
+- clear in-scope and out-of-scope boundaries
+- concrete Done When criteria
+- a current next action
+- a closeout path through `.work/brownfield-change/VERIFICATION.md`
+
+Also verify that `HANDOFF.md` is judgment-only context and does not contradict the operational status, scope, or next action in `CHANGE.md`. If any brownfield contract field is missing or contradictory, STOP and repair the brownfield contract before planning.
 </phase_contract_gate>
 
-<ui_proof_planning>
-For UI-sensitive work, include compact `ui_proof_slots` with `slot_id`, optional `requirement_id`, `claim`, `route_state`, fixed evidence kinds (`code`, `test`, `runtime`, `delivery`, `human`), `minimum_observations`, `expected_artifact_types`, `validation_command`, `environment`, `viewport`, `manual_acceptance_required`, and `claim_limit`; otherwise set `no_ui_proof_rationale`.
-Do not create slots for backend-only, CLI-only, docs-only, or refactor-only work unless the plan claims a visible UI outcome. Evidence must later match claim, route/state, observation, artifact path, evidence kind, privacy metadata, result, and claim limit; local-only or unsafe artifacts cannot support public, publication, tracked, delivery, or release proof claims. Human approval does not replace required `code`, `test`, `runtime`, or `delivery` evidence.
-For live rendered UI proof, plan `agent-browser` as the default runtime evidence path and existing Playwright/package-script browser tests as the repeatable regression path when the repo already has them. If the runtime does not provide `agent-browser`, require the plan to state that availability constraint and name the closest project-native interactive browser fallback before narrowing the claim. The planner chooses the viewport set, but each slot must explain why the chosen viewport(s) are enough for the claim or narrow the claim limit; responsive claims need desktop/mobile or equivalent state coverage. Do not plan new browser infrastructure by default, and use Playwright scripting only for checks `agent-browser` cannot cover cleanly, such as JS-disabled, structured console, or multi-context verification.
-</ui_proof_planning>
+<browser_proof_planning>
+For UI-sensitive work, set `browser_proof_required: true` and add a `## Browser Proof Plan` section. For backend-only, CLI-only, docs-only, or refactor-only work that claims no visible UI outcome, set `browser_proof_required: false` with a short `browser_proof_rationale`.
+
+The Browser Proof Plan is plain markdown, not a JSON slot schema. It must name:
+- `Routes/states:` exact route(s), screen(s), or UI states to inspect
+- `Viewports:` desktop and mobile for responsive or layout-sensitive claims, or a narrowed claim explaining why one viewport is enough
+- `Runtime path:` `agent-browser` preferred; Playwright or another project-native browser fallback must explain the availability constraint
+- `Evidence kind:` `runtime` for live browser observation or `test` for a repeatable browser-regression command
+- `Evidence command:` a runnable command that can reproduce or validate the browser proof, or `No-command rationale:` when the runtime path is manual/interactive only and the claim is narrowed accordingly
+- `Observations:` rendered DOM/behavior, interaction steps, and console/network observations when relevant
+- `Artifacts:` screenshot/report/log paths if produced, with local-only vs publishable privacy/safety note
+- `Claim limit:` the exact claim the observation can support
+
+Evidence must later match route/state, viewport, observation, artifact path, evidence kind, privacy/safety note, result, and claim limit. Human approval does not replace required `code`, `test`, `runtime`, or `delivery` evidence. Existing Playwright/package-script browser tests remain canonical repeatable regression evidence when present. Do not plan new browser infrastructure by default; use Playwright scripting only for checks `agent-browser` cannot cover cleanly, such as JS-disabled, structured console, or multi-context verification.
+</browser_proof_planning>
 <goal_backward_planning>
 Plan backward from success criteria.
 
 ### Step 1: State the must-haves
-From `ROADMAP.md`, list the success criteria for this phase. These are your non-negotiable targets.
+For a roadmap phase, list the success criteria from `ROADMAP.md`. These are your non-negotiable targets.
 Also list the phase out-of-scope boundaries and stop/replan conditions. These are equally contractual: execution may not silently widen past them.
 
+For `brownfield-change`, list the Done When criteria, in-scope boundaries, out-of-scope boundaries, current next action, and closeout path from `CHANGE.md`. These replace ROADMAP phase success criteria for this lane.
+
 ### Step 2: Derive artifacts
 For each success criterion, what concrete artifacts must exist?
 - Files (source code, config, tests)
@@ -197,18 +205,8 @@ anti_regression_targets:
   - Existing session middleware behavior remains unchanged for already-supported routes.
 known_unknowns:
   - Exact copy wording for auth errors may still need product confirmation.
-ui_proof_slots: []
-no_ui_proof_rationale: Not UI-sensitive; scoped work does not claim a visible UI outcome.
-high_leverage_surfaces: []
-second_pass_required: false
-closure_claim_limit: Do not claim phase completion until verification satisfies the evidence contract for the scoped truths.
-parallelism_budget:
-  max_concurrent_plans: 1
-  safe_parallelism: []
-leverage:
-  lost: Slightly more planning ceremony for this plan.
-  kept: Existing auth/session architecture and repo conventions.
-  gained: Explicit anti-drift boundaries and fail-closed escalation.
+browser_proof_required: false
+browser_proof_rationale: Not UI-sensitive; scoped work does not claim a visible UI outcome.
 must_haves:
   truths:
     - User can sign in with email and password.
@@ -227,11 +225,9 @@ Schema rules:
 - `requirements` must not be empty
 - `files-modified` should list the files this plan is expected to touch
 - `must_haves` must trace back to roadmap success criteria
-- `non_goals`, `hard_boundaries`, `escalation_triggers`, and `closure_claim_limit` must not be empty
-- include `ui_proof_slots` for UI-sensitive work or `no_ui_proof_rationale` otherwise
-- `leverage.lost`, `leverage.kept`, and `leverage.gained` must all be explicit
-- `second_pass_required: true` if `high_leverage_surfaces` is non-empty
-- `parallelism_budget.max_concurrent_plans` must stay `1` unless the plan proves disjoint write ownership
+- `non_goals`, `hard_boundaries`, `escalation_triggers`, and `approval_gates` must be explicit
+- include `browser_proof_required` and `browser_proof_rationale`
+- if `browser_proof_required: true`, include a `## Browser Proof Plan` section with route/state, viewport, runtime path, evidence kind, evidence command or no-command rationale, observations, artifacts, and claim limit
 </plan_schema>
 
 <task_format>
@@ -299,7 +295,7 @@ Split a task if:
 </task_sizing>
 
 <plan_structure>
-Create `.planning/phases/{phase_dir}/{plan_id}-PLAN.md` with this structure:
+Create `.work/phases/{phase_dir}/{plan_id}-PLAN.md` with this structure:
 
 ```markdown
 ---
@@ -328,16 +324,8 @@ anti_regression_targets:
   - Existing user route behavior outside the new list view remains unchanged.
 known_unknowns:
   - Final empty-state copy may still need product confirmation.
-high_leverage_surfaces: []
-second_pass_required: false
-closure_claim_limit: Do not claim phase completion until verification confirms the scoped truths with the required evidence.
-parallelism_budget:
-  max_concurrent_plans: 1
-  safe_parallelism: []
-leverage:
-  lost: Slightly more planning ceremony for stronger execution boundaries.
-  kept: Existing route/component conventions and repo-native workflow.
-  gained: Better anti-drift enforcement and more honest closure limits.
+browser_proof_required: true
+browser_proof_rationale: Visible route changes require rendered browser proof.
 must_haves:
   truths:
     - Users can view the list page.
@@ -384,6 +372,16 @@ must_haves:
 ## Approval Gates
 - [Decision or side-effect boundaries that require explicit user approval]
 
+## Browser Proof Plan
+Routes/states: [Exact routes or UI states to inspect, or `N/A` when not required]
+Viewports: [Desktop/mobile coverage or narrowed viewport claim]
+Runtime path: [agent-browser preferred; explain fallback availability constraints]
+Evidence kind: [runtime or test]
+Evidence command: [Runnable command, or use `No-command rationale:` for narrowed manual/interactive proof]
+Observations: [Rendered behavior, interaction steps, console/network observations]
+Artifacts: [Screenshot/report/log paths plus local-only or publishable safety note]
+Claim limit: [Exact claim this proof can support]
+
 <checks>
 <plan_check>
 checker: self | cross_runtime
@@ -410,24 +408,19 @@ notes: [What the checker actually validated or why it was skipped]
 ## Success Criteria
 - [What must be true when this plan is complete]
 
-## High-Leverage Review
-- [Which high-leverage surfaces are touched and whether a second pass is required]
-
-## Leverage Review
-- Lost: [What leverage this plan sacrifices]
-- Kept: [What existing leverage or conventions it preserves]
-- Gained: [What leverage this plan creates]
+## Second-Pass Review
+- [Shared/high-risk surfaces to re-check for contradictions, stale assumptions, and overclaims before closure]
 
 ## Notes
 [Gotchas, implementation notes, or explicit assumptions]
 ```
 
-**MANDATORY: You MUST write PLAN.md to disk at `.planning/phases/{phase_dir}/{plan_id}-PLAN.md`. Output to conversation alone is NOT sufficient. If this file is not written to disk, planning is NOT complete.**
+**MANDATORY: You MUST write PLAN.md to disk at `.work/phases/{phase_dir}/{plan_id}-PLAN.md`. Output to conversation alone is NOT sufficient. If this file is not written to disk, planning is NOT complete.**
 </plan_structure>
 
 <approach_exploration>
 ### When This Runs
-Check `.planning/config.json` for `workflow.discuss`:
+Check `.work/config.json` for `workflow.discuss`:
 - If `workflow.discuss: false` (or key missing): skip this section, go to `<goal_backward_planning>`. Note `reduced_alignment` in the orchestration summary.
 - If `workflow.discuss: true`: mandatory before planning.
 
@@ -446,12 +439,12 @@ Run the approach explorer.
 **Primary path — inline conversation with research subagents:**
 The conversation with the user runs inline in the main context. For each technical gray area, a read-only research subagent is spawned to isolate heavy codebase and documentation reads, returning only compressed summaries while full detail stays out of the orchestrator context.
 
-1. Load context: read ONLY locked decisions from `.planning/SPEC.md` and the target phase goal/requirements from `.planning/ROADMAP.md`.
+1. Load context: read ONLY locked decisions from `.work/SPEC.md` and the target phase goal/requirements from `.work/ROADMAP.md`.
 
 2. Identify 3-4 domain-specific gray areas. Classify each as **taste** (preference, no research needed), **technical** (trade-offs, research first), or **hybrid** (both).
 
 3. For each **technical or hybrid** gray area, spawn a read-only research subagent.
-   Use the prompt template from `.planning/templates/roles/approach-explorer.md` (`<research_subagent_prompt>` section), substituting the gray area name, classification, phase context, and relevant codebase files. Each subagent returns a structured summary and does not write implementation artifacts.
+   Use the prompt template from `.work/templates/roles/approach-explorer.md` (`<research_subagent_prompt>` section), substituting the gray area name, classification, phase context, and relevant codebase files. Each subagent returns a structured summary and does not write implementation artifacts.
 
 4. Present each gray area to the user individually:
    - For taste areas: ask directly
@@ -469,7 +462,7 @@ The conversation with the user runs inline in the main context. For each technic
 **Native agent optimization:**
 
 If your runtime provides an interactive `gsdd-approach-explorer` agent:
-- Invoke it with: target phase goal, requirement IDs, project config from `.planning/config.json` (especially `workflow.discuss`), locked decisions, phase research (if exists), relevant codebase files
+- Invoke it with: target phase goal, requirement IDs, project config from `.work/config.json` (especially `workflow.discuss`), locked decisions, phase research (if exists), relevant codebase files
 - The native agent runs the full exploration in its own context window
 - This is an optimization — the output (APPROACH.md) is identical to the primary path
 
@@ -484,14 +477,14 @@ If neither the primary path nor native agent is available (e.g., the runtime can
 ### Using APPROACH.md Decisions
 After approach exploration completes (or existing APPROACH.md is loaded):
 - If `workflow.discuss: true`, validate that APPROACH.md records `alignment_status: user_confirmed` or `alignment_status: approved_skip` with the canonical fields `alignment_method`, `user_confirmed_at`, `explicit_skip_approved`, `skip_scope`, `skip_rationale`, and `confirmed_decisions` before goal-backward planning begins. Stop and update the APPROACH artifact if proof is missing, unknown, agent-discretion-only, or based only on agent "No questions needed" judgment.
-- Treat decisions from APPROACH.md as locked constraints, same priority as `.planning/SPEC.md` decisions
+- Treat decisions from APPROACH.md as locked constraints, same priority as `.work/SPEC.md` decisions
 - "Agent's Discretion" items from APPROACH.md give the planner flexibility — do not treat them as locked
 - Thread the APPROACH.md file path to both the planner prompt and the plan-checker prompt
 - Deferred ideas from APPROACH.md must not appear in the plan
 
 ### Role Contract
 
-The approach explorer's full role contract is at `.planning/templates/roles/approach-explorer.md`. The portable workflow describes the orchestration; the role contract describes the agent's behavior.
+The approach explorer's full role contract is at `.work/templates/roles/approach-explorer.md`. The portable workflow describes the orchestration; the role contract describes the agent's behavior.
 </approach_exploration>
 
 <plan_check_orchestration>
@@ -507,22 +500,19 @@ After the planner produces a draft plan, an independent checker reviews it in fr
 6. `must_have_quality` - success criteria are specific, observable, and reflected in tasks
 7. `context_compliance` - locked decisions are honored and deferred ideas stay out of scope
 8. `goal_achievement` - the plan, if executed perfectly, actually achieves the stated phase goal: goal addressed (tasks deliver the goal), success criteria reachable (each criterion traceable to a task verify output), and outcome observable (a human or automated check can confirm the goal was met)
-9. `scope_boundaries` - anti-goals and hard boundaries are explicit, enforceable, and reflected in the task set
-10. `anti_regression_capture` - anti-regression targets are named and mapped to verification
-11. `escalation_integrity` - stop-and-challenge triggers and approval gates are present where side effects or ambiguity warrant them
-12. `closure_honesty` - closure claim limit prevents the plan from overclaiming what verification can prove
-13. `high_leverage_review` - high-leverage surfaces and second-pass obligations are recorded honestly
-14. `approach_alignment` - when APPROACH.md exists, plans implement the chosen approaches, not alternatives. Blocker if plan contradicts an explicit user choice. Warning if plan drifts from recommendation without justification. When `workflow.discuss: true`, missing, proofless, agent-discretion-only, or invalid APPROACH.md is a blocker before a plan can be accepted.
+9. `approach_alignment` - when APPROACH.md exists, plans implement the chosen approaches, not alternatives. Blocker if plan contradicts an explicit user choice. Warning if plan drifts from recommendation without justification. When `workflow.discuss: true`, missing, proofless, agent-discretion-only, or invalid APPROACH.md is a blocker before a plan can be accepted.
+
+The smaller dimension set still preserves the old failure coverage: scope boundaries are checked under `scope_sanity`, anti-regression and escalation under `context_compliance`, closure honesty and browser-proof specificity under `goal_achievement`, and second-pass review under the final shared-surface review before closure.
 ### Invoking the Checker
-1. If `.planning/config.json` has `workflow.planCheck: false`, skip the independent checker. Perform the planner self-check below and report `reduced_assurance`. This does not skip the earlier alignment-proof gate when `workflow.discuss: true`.
+1. If `.work/config.json` has `workflow.planCheck: false`, skip the independent checker. Perform the planner self-check below and report `reduced_assurance`. This does not skip the earlier alignment-proof gate when `workflow.discuss: true`.
 2. If plan checking is enabled, check if your runtime provides a `gsdd-plan-checker` agent.
 3. If a native checker agent is available, invoke it in a fresh context with only these explicit inputs:
    - target phase goal and requirement IDs
-   - relevant locked decisions / deferred items from `.planning/SPEC.md`
-   - project config from `.planning/config.json`, especially `workflow.discuss` and `workflow.planCheck`
-   - approach decisions from `.planning/phases/*-APPROACH.md` (if exists)
+   - relevant locked decisions / deferred items from `.work/SPEC.md`
+   - project config from `.work/config.json`, especially `workflow.discuss` and `workflow.planCheck`
+   - approach decisions from `.work/phases/*-APPROACH.md` (if exists)
    - relevant phase research file(s)
-   - produced `.planning/phases/*-PLAN.md` file(s)
+   - produced `.work/phases/*-PLAN.md` file(s)
 4. Require the checker to return a single JSON object:
    ```json
    {
@@ -530,7 +520,7 @@ After the planner produces a draft plan, an independent checker reviews it in fr
      "summary": "One sentence overall assessment",
      "issues": [
        {
-         "dimension": "requirement_coverage | task_completeness | dependency_correctness | key_link_completeness | scope_sanity | must_have_quality | context_compliance | goal_achievement | scope_boundaries | anti_regression_capture | escalation_integrity | closure_honesty | high_leverage_review | approach_alignment",
+         "dimension": "requirement_coverage | task_completeness | dependency_correctness | key_link_completeness | scope_sanity | must_have_quality | context_compliance | goal_achievement | approach_alignment",
          "severity": "blocker | warning",
          "description": "What is wrong",
          "plan": "01-PLAN",
@@ -589,9 +579,9 @@ For each task:
 - [ ] `escalation_triggers` force stop-and-challenge instead of silent interpretation
 - [ ] `approval_gates` appear anywhere side effects or irreversible choices could happen
 - [ ] `anti_regression_targets` are concrete enough for verification to check later
-- [ ] `closure_claim_limit` prevents the executor from claiming more than the evidence can support
-- [ ] `leverage.lost`, `leverage.kept`, and `leverage.gained` are explicit and defensible
-- [ ] If `high_leverage_surfaces` is non-empty, `second_pass_required` is true and named in the plan body
+- [ ] Evidence contract and claim limits prevent the executor from claiming more than verification can support
+- [ ] Browser-proof-required plans include route/state, viewport, runtime path, evidence kind, evidence command or no-command rationale, observations, artifacts/privacy-safety posture, and claim limit
+- [ ] Shared or high-risk surfaces are named for a second-pass contradiction/staleness review
 
 ### Red Flags
 - A success criterion has no task covering it
@@ -608,28 +598,30 @@ For each task:
 Planning is done when all of these are true:
 
 - [ ] Target phase identified from `ROADMAP.md`
+- [ ] Or selected target is `brownfield-change` and `CHANGE.md` provides goal, scope, done-when, next action, and closeout path without ROADMAP phase membership
 - [ ] Approach exploration completed or explicitly skipped with `reduced_alignment` reported
 - [ ] When `workflow.discuss: true`: user alignment confirmed via APPROACH.md before planning
 - [ ] Research check completed where needed
 - [ ] Roadmap phase contract includes requirements, success criteria, explicit out-of-scope, and explicit stop/replan conditions
+- [ ] Or brownfield contract includes in-scope, out-of-scope, concrete Done When criteria, current next action, and `VERIFICATION.md` closeout path
 - [ ] Plan self-check passed
-- [ ] Success criteria from `ROADMAP.md` are represented as must-haves
+- [ ] Success criteria from `ROADMAP.md`, or Done When criteria from `CHANGE.md`, are represented as must-haves
 - [ ] Goal-backward derivation from criteria to artifacts to key links to tasks is explicit
-- [ ] Every plan has frontmatter with `phase`, `plan`, `type`, `wave`, `depends_on`, `files-modified`, `autonomous`, `requirements`, `non_goals`, `hard_boundaries`, `escalation_triggers`, `approval_gates`, `anti_regression_targets`, `ui_proof_slots` or `no_ui_proof_rationale`, `closure_claim_limit`, `parallelism_budget`, `leverage`, and `must_haves`
+- [ ] Every plan has frontmatter with `phase`, `plan`, `type`, `wave`, `depends_on`, `files-modified`, `autonomous`, `requirements`, `non_goals`, `hard_boundaries`, `escalation_triggers`, `approval_gates`, `anti_regression_targets`, `known_unknowns`, `browser_proof_required`, `browser_proof_rationale`, and `must_haves`
 - [ ] Every plan frontmatter records `runtime` and `assurance`
 - [ ] Every plan records checker outcome in a structured `<checks>` block
 - [ ] Every task has XML structure with `id`, `type`, `files`, `action`, `verify`, and `done`
 - [ ] Every task has at least one runnable verify command
 - [ ] Plan sizing stays within 2-5 tasks, preferring 2-3
-- [ ] Locked decisions from `.planning/SPEC.md` and APPROACH.md are honored
-- [ ] Plan body includes explicit `## Anti-Goals`, `## Hard Boundaries`, `## Evidence Contract`, `## Common Pitfalls`, `## Stop-And-Challenge`, `## Approval Gates`, and `## Leverage Review` sections
-- [ ] Any git guidance stays repo-native and follows `.planning/config.json`
+- [ ] Locked decisions from `.work/SPEC.md` and APPROACH.md are honored
+- [ ] Plan body includes explicit `## Anti-Goals`, `## Hard Boundaries`, `## Evidence Contract`, `## Common Pitfalls`, `## Stop-And-Challenge`, `## Approval Gates`, and `## Second-Pass Review` sections; UI-sensitive plans also include `## Browser Proof Plan`
+- [ ] Any git guidance stays repo-native and follows `.work/config.json`
 </success_criteria>
 
 <completion>
 Report to the user what was accomplished, then present the next step:
 ---
-**Completed:** Phase planning — created `.planning/phases/{phase_dir}/{plan_id}-PLAN.md`.
+**Completed:** Phase planning — created `.work/phases/{phase_dir}/{plan_id}-PLAN.md`.
 **Planning stops here:** `gsdd-plan` ends after the plan artifact is written. Do not start implementation in this same run, and do not treat imperative handoff text as execution authorization.
 Installed generated runtime surfaces are trusted through rendering, not reviewer memory: `npx -y gsdd-cli health` compares any local generated skill/adapter surfaces against current render output, and `npx -y gsdd-cli update` regenerates them when they drift. Bare `gsdd health` / `gsdd update` are equivalent only when globally installed.
 **Next workflow:** `/gsdd-execute` — start execution in a separate run when the user explicitly wants implementation to begin