gsdd-cli 0.26.0 → 0.28.0

package/distilled/workflows/pause.md

@@ -7,17 +7,17 @@ Scope boundary: you write a checkpoint file. You do not route, present status, o
 </role>
 
 <prerequisites>
-`.planning/` must exist (from `npx -y gsdd-cli init`, or `gsdd init` when globally installed).
+`.work/` must exist (from `npx -y gsdd-cli init`, or `gsdd init` when globally installed).
 
-If `.planning/` does not exist, stop and tell the user to run `npx -y gsdd-cli init` first.
+If `.work/` does not exist, stop and tell the user to run `npx -y gsdd-cli init` first.
 </prerequisites>
 
 <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>
 
 <runtime_contract>
-Use the `Runtime` type from `.planning/SPEC.md`.
+Use the `Runtime` type 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`.
 Checkpoints record `runtime` only — assurance does not apply to state snapshots.
 </runtime_contract>
@@ -27,8 +27,8 @@ Checkpoints record `runtime` only — assurance does not apply to state snapshot
 <detect_work>
 Scan for active work in priority order:
 
-1. **Active phase work** — look in `.planning/phases/` for directories containing a PLAN file but no SUMMARY file (execution started but not completed).
-2. **Active quick task** — read `.planning/quick/LOG.md` if it exists. Check the last entry: if its status is not `done`/`passed`, there is an incomplete quick task.
+1. **Active phase work** — look in `.work/phases/` for directories containing a PLAN file but no SUMMARY file (execution started but not completed).
+2. **Active quick task** — read `.work/quick/LOG.md` if it exists. Check the last entry: if its status is not `done`/`passed`, there is an incomplete quick task.
 3. **Generic work** — if neither of the above, ask the user what they were working on.
 
 If no active work is detected and the user confirms nothing is in progress, inform them there is nothing to pause and exit.
@@ -39,7 +39,7 @@ Store the detected work type as `$WORK_TYPE` (one of: `phase`, `quick`, `generic
 <gather_state>
 Build a draft checkpoint from artifact truth before asking the user to restate work. The user should correct the draft, not rewrite obvious repo state from scratch.
 
-When available, run `node .planning/bin/gsdd.mjs control-map --json` and use it as the draft's repo/worktree snapshot: canonical branch/HEAD, dirty tracked/untracked/ignored buckets, sibling/detached worktrees, stale annotations, planning drift, and recommended interventions. Include only a compact summary or pointer in `.planning/.continue-here.md`; the checkpoint records resumability context, not a replacement for future computed repo truth.
+When available, run `node .work/bin/gsdd.mjs control-map --json` and use it as the draft's repo/worktree snapshot: canonical branch/HEAD, dirty tracked/untracked/ignored buckets, sibling/detached worktrees, stale annotations, planning drift, and recommended interventions. Include only a compact summary or pointer in `.work/.continue-here.md`; the checkpoint records resumability context, not a replacement for future computed repo truth.
 
 Ask the user conversationally to fill in the gaps the artifacts cannot answer:
 
@@ -63,11 +63,11 @@ Question budget:
 </gather_state>
 
 <write_checkpoint>
-Before writing the new checkpoint, run `node .planning/bin/gsdd.mjs file-op delete .planning/.continue-here.bak --missing ok` to clear the prior session backup. This is cleanup-only and should no-op safely if the backup is absent.
+Before writing the new checkpoint, run `node .work/bin/gsdd.mjs file-op delete .work/.continue-here.bak --missing ok` to clear the prior session backup. This is cleanup-only and should no-op safely if the backup is absent.
 
 When the current branch/worktree is known to be evidence-only, stale/spent, or otherwise not the next intended execution surface, say that explicitly in `<current_state>`, `<remaining_work>`, and `<anti_regression>`. Do not flatten evidence-only local state into the same continuity story as the next execution surface.
 
-Write `.planning/.continue-here.md` with the following structure:
+Write `.work/.continue-here.md` with the following structure:
 
 ```markdown
 ---
@@ -117,13 +117,13 @@ runtime: $INFERRED_RUNTIME
 </judgment>
 ```
 
-The checkpoint is project-scoped (lives at `.planning/.continue-here.md`, not inside a phase directory) so resume always knows where to look.
+The checkpoint is project-scoped (lives at `.work/.continue-here.md`, not inside a phase directory) so resume always knows where to look.
 </write_checkpoint>
 
-**MANDATORY: `.planning/.continue-here.md` must exist on disk after writing. If the file was not created, STOP and report the failure. The entire purpose of this workflow is to persist context — a failed write means the pause did nothing.**
+**MANDATORY: `.work/.continue-here.md` must exist on disk after writing. If the file was not created, STOP and report the failure. The entire purpose of this workflow is to persist context — a failed write means the pause did nothing.**
 
 <advisory_git>
-Read `.planning/config.json` for the `gitProtocol` section. If config.json cannot be read, skip git advice.
+Read `.work/config.json` for the `gitProtocol` section. If config.json cannot be read, skip git advice.
 
 Suggest a WIP commit following the project's git conventions. Do not mandate it — the user decides whether and how to commit.
 
@@ -132,7 +132,7 @@ Example suggestion: "You may want to commit your current changes as a WIP before
 
 <confirm>
 Report to the user:
-- Checkpoint location: `.planning/.continue-here.md`
+- Checkpoint location: `.work/.continue-here.md`
 - Work type captured (phase/quick/generic)
 - How to resume: run the `/gsdd-resume` workflow in the next session
 </confirm>
@@ -142,7 +142,7 @@ Report to the user:
 <success_criteria>
 - [ ] Active work context detected (phase, quick, or generic)
 - [ ] User provided missing context via conversation
-- [ ] `.planning/.continue-here.md` created with frontmatter, all 6 sections, and <judgment> block
+- [ ] `.work/.continue-here.md` created with frontmatter, all 6 sections, and <judgment> block
 - [ ] Advisory git suggestion presented (not mandated)
 - [ ] User informed of checkpoint location and resume instructions
 </success_criteria>
@@ -151,7 +151,7 @@ Report to the user:
 Report to the user what was accomplished, then present the next step:
 
 ---
-**Completed:** Session paused — created `.planning/.continue-here.md` (checkpoint file).
+**Completed:** Session paused — created `.work/.continue-here.md` (checkpoint file).
 
 **Next step (next session):** `/gsdd-resume` — restore context and continue where you left off
 

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,10 +116,19 @@ 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>
@@ -144,9 +140,11 @@ For live rendered UI proof, plan `agent-browser` as the default runtime evidence
 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)
@@ -299,7 +297,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
 ---
@@ -422,12 +420,12 @@ notes: [What the checker actually validated or why it was skipped]
 [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 +444,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 +467,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 +482,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>
@@ -514,15 +512,15 @@ After the planner produces a draft plan, an independent checker reviews it in fr
 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.
 ### 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
    {
@@ -608,12 +606,14 @@ 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 frontmatter records `runtime` and `assurance`
@@ -621,15 +621,15 @@ Planning is done when all of these are true:
 - [ ] 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
+- [ ] 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 `## Leverage Review` sections
-- [ ] Any git guidance stays repo-native and follows `.planning/config.json`
+- [ ] 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