gsdd-cli 0.18.0 → 0.18.2

package/distilled/workflows/new-milestone.md

@@ -14,19 +14,20 @@ If SPEC.md is missing, the project has not been initialized — run `/gsdd-new-p
 If MILESTONES.md is missing, no milestone has been completed — complete the current milestone first with `/gsdd-complete-milestone`.
 </prerequisites>
 
-<load_context>
-Before starting, read these files:
-
-1. `.planning/SPEC.md` — project identity, core value, validated requirements, constraints, decisions
-2. `.planning/MILESTONES.md` — what shipped previously, last milestone version and date
-3. `.planning/ROADMAP.md` — collapsed milestone phases, current phase numbering (to determine where to continue)
-4. `.planning/config.json` — `workflow.research`, `researchDepth`, `gitProtocol`
-</load_context>
+<load_context>
+Before starting, read these files:
+
+1. `.planning/SPEC.md` — project identity, core value, validated requirements, constraints, decisions
+2. `.planning/MILESTONES.md` — what shipped previously, last milestone version and date
+3. `.planning/ROADMAP.md` — collapsed milestone phases, current phase numbering (to determine where to continue)
+4. `.planning/config.json` — `workflow.research`, `researchDepth`, `gitProtocol`
+5. `.planning/brownfield-change/CHANGE.md`, `.planning/brownfield-change/HANDOFF.md`, and `.planning/brownfield-change/VERIFICATION.md` when an active bounded change is being widened into the next milestone
+</load_context>
 
 <lifecycle_preflight>
 Before presenting the last milestone or gathering new milestone goals, run:
 
-- `gsdd lifecycle-preflight new-milestone`
+- `node .planning/bin/gsdd.mjs lifecycle-preflight new-milestone`
 
 If the preflight result is `blocked`, STOP and report the blocker instead of inferring milestone-start eligibility from workflow-local prose.
 
@@ -36,15 +37,26 @@ Treat the preflight as an authorization seam over shared repo truth only:
 - owned writes remain the new milestone requirements, roadmap entries, and phase-directory scaffolding
 </lifecycle_preflight>
 
-<integration_surface_check>
+<integration_surface_check>
 Before mutating milestone truth, inspect the current branch/worktree as a separate provenance surface:
 - current branch
 - divergence from `main`
 - staged / unstaged / untracked local truth
 - whether the branch appears stale/spent or mixed-scope
 
-If milestone truth on disk is local-only or AI-generated draft truth, or if the checked-out branch is clearly not the intended integration surface, say so explicitly before continuing. Do not flatten local draft planning truth into committed repo truth.
-</integration_surface_check>
+If milestone truth on disk is local-only or AI-generated draft truth, or if the checked-out branch is clearly not the intended integration surface, say so explicitly before continuing. Do not flatten local draft planning truth into committed repo truth.
+</integration_surface_check>
+
+<brownfield_widening_inputs>
+If `.planning/brownfield-change/CHANGE.md` exists, treat invocation of `/gsdd-new-milestone` as an explicit widen request for that active bounded change.
+
+Before gathering new milestone goals, read and preserve:
+- `CHANGE.md` for the current goal, scope, done-when, next action, and declared write scope
+- `HANDOFF.md` for active constraints, unresolved uncertainty, decision posture, and anti-regression
+- `VERIFICATION.md` for proof already gathered, remaining gaps, and any partial validation that the new milestone should inherit honestly
+
+Do not force the user to rediscover this context and do not create a new promotion artifact before milestone setup.
+</brownfield_widening_inputs>
 
 <process>
 
@@ -61,13 +73,15 @@ Delivered:
 - [Accomplishment 3]
 ```
 
-## 2. Gather What to Build Next
+## 2. Gather What to Build Next
 
 Ask the user what the next milestone should focus on. Explore:
 - What problem does this milestone solve?
 - Who benefits?
-- What is explicitly out of scope for this milestone?
-- Any constraints (deadline, team size, dependencies)?
+- What is explicitly out of scope for this milestone?
+- Any constraints (deadline, team size, dependencies)?
+
+If widening from an active brownfield change, start by presenting the preserved brownfield goal/scope/proof context and ask what now needs milestone-owned lifecycle state beyond that bounded lane.
 
 If a `.planning/MILESTONE-BRIEF.md` exists, use it as the input instead of asking. Note any assumptions inferred from the brief.
 (MILESTONE-BRIEF.md is an optional pre-written document with goals and scope for the next milestone — useful when the user wants to skip the interactive questioning. Create it manually in `.planning/` before running this workflow.)
@@ -125,12 +139,13 @@ Present key findings before moving to requirements.
 
 Read SPEC.md Must Have section. Identify the requirement ID pattern in use (e.g., `[FLOW-01]`, `[PLAN-01]`).
 
-Based on milestone goals and research findings (if any), define the new Must Have requirements for this milestone:
+Based on milestone goals and research findings (if any), define the new Must Have requirements for this milestone:
 
-- Each requirement must be user-centric: "User can X"
-- Each must have a `[Done-When:]` completion criterion
-- IDs follow the existing category pattern or introduce a new category for new capability areas
-- Do NOT duplicate or restate requirements already in the Validated section
+- Each requirement must be user-centric: "User can X"
+- Each must have a `[Done-When:]` completion criterion
+- IDs follow the existing category pattern or introduce a new category for new capability areas
+- Do NOT duplicate or restate requirements already in the Validated section
+- If widening from an active brownfield change, convert the preserved `CHANGE.md` / `HANDOFF.md` / `VERIFICATION.md` context into milestone requirements instead of restating the work from scratch
 
 Present the full proposed requirements list:
 
@@ -154,10 +169,11 @@ Determine the starting phase number:
 - Check MILESTONES.md for the last phase range (e.g., "Phases 1–5")
 - New phases start from max + 1
 
-Design 2-5 phases that cover all new requirements:
-- Each phase has a goal (one sentence), requirement assignments, and 2-4 success criteria
-- All requirements must be assigned to exactly one phase
-- Verify 100% coverage before writing
+Design 2-5 phases that cover all new requirements:
+- Each phase has a goal (one sentence), requirement assignments, and 2-4 success criteria
+- All requirements must be assigned to exactly one phase
+- Verify 100% coverage before writing
+- If widening from an active brownfield change, make the phase design preserve the already-captured scope, decisions, and proof/gap context instead of inserting a rediscovery phase
 
 Present the proposed roadmap:
 

package/distilled/workflows/new-project.md

@@ -25,22 +25,23 @@ When `autoAdvance: true`, this workflow runs non-interactively:
 All other sections (`<detect_mode>`, `<codebase_context>`, `<research>`, `<spec_creation>`, `<roadmap_creation>`, `<success_criteria>`) execute normally. Auto mode bypasses: the `<questioning>` section, both `<approval_gate>` blocks, the user question in `<project_principles>`, and the user question in `<capability_gates>`. All other workflow logic executes normally.
 </auto_mode>
 
-<load_context>
-Before starting, read these files (if they exist):
-1. `AGENTS.md` (root) — understand the full SDD workflow and governance rules.
-2. `.planning/templates/spec.md` — template for creating SPEC.md
-3. `.planning/templates/roadmap.md` — template for creating ROADMAP.md
+<load_context>
+Before starting, read these files (if they exist):
+1. `AGENTS.md` (root) — understand the full SDD workflow and governance rules.
+2. `.planning/templates/spec.md` — template for creating SPEC.md
+3. `.planning/templates/roadmap.md` — template for creating ROADMAP.md
 4. Project root files: `package.json`, `README.md`, main entry point, `.gitignore`
 5. `.planning/config.json` — The deterministic project settings. Key fields:
    - `researchDepth`: balanced | fast | deep — controls research thoroughness
    - `parallelization`: true | false � whether to run delegate work in parallel when the platform supports it; when false, run the same delegates sequentially
    - `workflow.research`: true | false — whether to do SOTA research before spec
    - `workflow.planCheck`: true | false — whether plan-check agent runs later
-   - `workflow.verifier`: true | false — whether verifier runs after execution
-   - `modelProfile`: balanced | quality | budget — model selection hint
-   - `gitProtocol`: advisory git guidance only — follow repo/user conventions first and never invent phase/plan/task git naming by default
-6. Any existing `.planning/SPEC.md` or `.planning/ROADMAP.md` (if resuming)
-</load_context>
+   - `workflow.verifier`: true | false — whether verifier runs after execution
+   - `modelProfile`: balanced | quality | budget — model selection hint
+   - `gitProtocol`: advisory git guidance only — follow repo/user conventions first and never invent phase/plan/task git naming by default
+6. Any existing `.planning/SPEC.md` or `.planning/ROADMAP.md` (if resuming)
+7. `.planning/brownfield-change/CHANGE.md`, `HANDOFF.md`, and `VERIFICATION.md` (when present as the widening input from an active bounded change)
+</load_context>
 
 <project_principles>
 **(SOTA Insight: Derived from Spec-Kit)**
@@ -52,13 +53,25 @@ Ask the user: "What are the core principles for this project regarding code qual
 Capture these directly at the top of the upcoming `SPEC.md` to guide all future agent execution.
 </project_principles>
 
-<detect_mode>
-Determine the situation:
-
-- **Greenfield**: No existing code. Empty or minimal project. Skip codebase audit, go to questioning.
-- **Brownfield**: Existing codebase. You MUST audit before questioning.
-- **Resuming**: `.planning/SPEC.md` already exists. Read it, confirm current state with developer, continue from where things left off.
-</detect_mode>
+<detect_mode>
+Determine the situation:
+
+- **Greenfield**: No existing code. Empty or minimal project. Skip codebase audit, go to questioning.
+- **Brownfield**: Existing codebase. You MUST audit before questioning.
+- **Resuming**: `.planning/SPEC.md` already exists. Read it, confirm current state with developer, continue from where things left off.
+- **Concrete brownfield continuity already exists**: if `.planning/brownfield-change/CHANGE.md` exists, treat `/gsdd-new-project` as an explicit widen path into full milestone setup, not as the default resume route for that bounded change. Preserve the current bounded context unless the user clearly wants to widen scope.
+</detect_mode>
+
+<brownfield_widening_context>
+If `.planning/brownfield-change/CHANGE.md` exists, treat it as an explicit widening input rather than as noise to rediscover:
+
+1. Read `CHANGE.md` for the active goal, in-scope/out-of-scope, done-when, next action, and declared write scope.
+2. Read `HANDOFF.md` for preserved constraints, unresolved uncertainty, decision posture, and anti-regression rules.
+3. Read `VERIFICATION.md` for existing proof, open gaps, and any partial validation that the first milestone should inherit honestly.
+
+Do not create a new promotion artifact. Reuse the existing brownfield folder directly when widening into milestone setup.
+If `.planning/MILESTONES.md` already contains shipped milestone history, stop and route this widen request to `/gsdd-new-milestone` instead of reopening first-milestone initialization here.
+</brownfield_widening_context>
 
 <milestone_context>
 Determine research context before spawning researchers. Check if `.planning/SPEC.md` has existing Validated requirements:
@@ -83,9 +96,11 @@ Check whether `.planning/codebase/STACK.md`, `.planning/codebase/ARCHITECTURE.md
 
 Inform the user: "No codebase maps found. Running codebase mapping before continuing."
 
-This is an internal prerequisite of `new-project`, not a user-facing routing requirement. If the user started with `/gsdd-new-project` on a brownfield repo, do not bounce them out and tell them to restart with `/gsdd-map-codebase`. Run the mapping dependency, then continue this workflow.
-
-Read and follow `.agents/skills/gsdd-map-codebase/SKILL.md` now. Execute its full flow (check existing, spawn mappers, validate, secrets scan). When map-codebase completes, return here and continue from Brownfield Validated Requirements Inference below.
+This is an internal prerequisite of `new-project`, not a user-facing routing requirement. If the user started with `/gsdd-new-project` on a brownfield repo, do not bounce them out and tell them to restart with `/gsdd-map-codebase`. Run the mapping dependency, then continue this workflow.
+
+If `.planning/brownfield-change/CHANGE.md` exists, keep it as the current bounded continuity anchor while you do this work. Do not treat its presence as evidence that the user should have used another command instead. The only question is whether they intentionally want to widen that bounded brownfield change into full milestone planning.
+
+Read and follow `.agents/skills/gsdd-map-codebase/SKILL.md` now. Execute its full flow (check existing, spawn mappers, validate, secrets scan). When map-codebase completes, return here and continue from Brownfield Validated Requirements Inference below.
 
 ### Brownfield Validated Requirements Inference
 
@@ -105,12 +120,14 @@ Example format (for SPEC.md requirements section):
 Brief the developer with a 4-5 sentence summary before starting the questioning phase.
 </codebase_context>
 
-<questioning>
-This is the most important step. You are NOT filling out a form. You are having a CONVERSATION.
-You are extracting a vision, not gathering requirements.
-
-**Start immediately by asking the user: "What do you want to build?"**
-(Wait for their response before continuing).
+<questioning>
+This is the most important step. You are NOT filling out a form. You are having a CONVERSATION.
+You are extracting a vision, not gathering requirements.
+
+If you are widening from active brownfield continuity, begin by summarizing what `CHANGE.md`, `HANDOFF.md`, and `VERIFICATION.md` already establish. Ask only for the delta needed to justify full milestone scope; do not make the user rediscover context already preserved on disk.
+
+**Start immediately by asking the user: "What do you want to build?"**
+(Wait for their response before continuing).
 
 ### What Downstream Phases Need From You
 Every phase reads what you produce. If you're vague, the cost compounds:

package/distilled/workflows/pause.md

@@ -57,7 +57,7 @@ Question budget:
 </gather_state>
 
 <write_checkpoint>
-Before writing the new checkpoint, run `gsdd 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 .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.
 
 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.
 

package/distilled/workflows/plan.md

@@ -8,13 +8,13 @@ Your plans are specific enough that an executor can follow them without guessing
 <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, and success criteria
+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 `gsdd file-op delete .planning/.continue-here.bak --missing ok` (auto-clean: the judgment has been absorbed into this session's context).
+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`.
 </load_context>
 
@@ -105,13 +105,30 @@ Trigger questions per item:
 - 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>
-
-<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.
+</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.
+
+The phase entry must provide all of:
+- assigned requirement IDs
+- explicit success criteria
+- explicit out-of-scope or anti-goals
+- 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 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.
+</phase_contract_gate>
+
+<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.
+Also list the phase out-of-scope boundaries and stop/replan conditions. These are equally contractual: execution may not silently widen past them.
 
 ### Step 2: Derive artifacts
 For each success criterion, what concrete artifacts must exist?
@@ -149,11 +166,33 @@ files-modified:
   - src/lib/auth.ts
   - src/routes/session.ts
 autonomous: true
-requirements:
-  - REQ-AUTH-01
-must_haves:
-  truths:
-    - User can sign in with email and password.
+requirements:
+  - REQ-AUTH-01
+non_goals:
+  - Do not redesign auth UX beyond the scoped sign-in flow.
+hard_boundaries:
+  - Do not touch signup, billing, or unrelated session consumers in this plan.
+escalation_triggers:
+  - Stop if the request requires changing scoped success criteria or touching a forbidden surface.
+approval_gates:
+  - Ask before any destructive data migration or external delivery action.
+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.
+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.
+must_haves:
+  truths:
+    - User can sign in with email and password.
   artifacts:
     - path: src/routes/session.ts
       provides: Session route handlers
@@ -164,12 +203,16 @@ must_haves:
 ---
 ```
 
-Schema rules:
-- `autonomous: false` if any task uses `checkpoint:*`
-- `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
-</plan_schema>
+Schema rules:
+- `autonomous: false` if any task uses `checkpoint:*`
+- `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
+- `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
+</plan_schema>
 
 <task_format>
 Each executable task must use this XML structure:
@@ -251,11 +294,33 @@ files-modified:
   - src/routes/users.ts
   - src/app/users/page.tsx
 autonomous: true
-requirements:
-  - REQ-USER-01
-must_haves:
-  truths:
-    - Users can view the list page.
+requirements:
+  - REQ-USER-01
+non_goals:
+  - Do not redesign adjacent user-management surfaces outside the scoped list page.
+hard_boundaries:
+  - Do not touch billing, permissions, or unrelated dashboard routes in this plan.
+escalation_triggers:
+  - Stop if the requested work expands beyond the phase success criteria or crosses a forbidden surface.
+approval_gates:
+  - Ask before destructive migrations, external release actions, or rewriting approved product decisions.
+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.
+must_haves:
+  truths:
+    - Users can view the list page.
   artifacts:
     - path: src/routes/users.ts
       provides: Users route handlers
@@ -274,12 +339,30 @@ must_haves:
 - [Relevant context file or source path]
 - [Relevant prior summary only if genuinely needed]
 
-## Requirements Covered
-- [REQ-ID]
-
-## Must-Haves
-1. [Observable truth from ROADMAP.md]
-2. [Observable truth from ROADMAP.md]
+## Requirements Covered
+- [REQ-ID]
+
+## Must-Haves
+1. [Observable truth from ROADMAP.md]
+2. [Observable truth from ROADMAP.md]
+
+## Anti-Goals
+- [What this plan must not expand into]
+
+## Hard Boundaries
+- [Files, modules, workflows, or delivery surfaces that stay out of scope]
+
+## Evidence Contract
+- [Which tests, runtime checks, docs, or artifacts must exist before this plan can be claimed complete]
+
+## Common Pitfalls
+- [Typical ways this work drifts, overclaims, or breaks neighboring behavior]
+
+## Stop-And-Challenge
+- [Trigger condition that must pause execution and force clarification]
+
+## Approval Gates
+- [Decision or side-effect boundaries that require explicit user approval]
 
 <checks>
 <plan_check>
@@ -301,15 +384,23 @@ notes: [What the checker actually validated or why it was skipped]
   ...
 </task>
 
-## Verification
-- [Overall plan-level verification or smoke checks]
-
-## Success Criteria
-- [What must be true when this plan is complete]
-
-## Notes
-[Gotchas, implementation notes, or explicit assumptions]
-```
+## Verification
+- [Overall plan-level verification or smoke checks]
+
+## 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]
+
+## 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.**
 </plan_structure>
@@ -400,10 +491,15 @@ After the planner produces a draft plan, an independent checker reviews it in fr
 3. `dependency_correctness` - ordering, dependencies, and plan structure are coherent
 4. `key_link_completeness` - important wiring links are planned, not just isolated artifacts
 5. `scope_sanity` - plans are sized so an executor can complete them without context collapse
-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. `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. Skipped when no APPROACH.md is provided.
+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. Skipped when no APPROACH.md is provided.
 ### 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`.
 2. If plan checking is enabled, check if your runtime provides a `gsdd-plan-checker` agent.
@@ -420,7 +516,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 | approach_alignment",
+         "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",
          "severity": "blocker | warning",
          "description": "What is wrong",
          "plan": "01-PLAN",
@@ -464,22 +560,35 @@ For every success criterion from `ROADMAP.md`:
 - [ ] At least one task produces an artifact that satisfies it
 - [ ] The task's `<verify>` section checks it specifically
 - [ ] The criterion is covered explicitly, not only implied
-### Check Task Completeness
-For each task:
-- [ ] The `<files>` section lists every file to create or modify
-- [ ] The `<action>` is specific enough that an executor will not need to guess
-- [ ] The `<verify>` steps include at least one runnable command
+### Check Task Completeness
+For each task:
+- [ ] The `<files>` section lists every file to create or modify
+- [ ] The `<action>` is specific enough that an executor will not need to guess
+- [ ] The `<verify>` steps include at least one runnable command
 - [ ] If a `<verify>` step references a test file, an earlier task creates that file
-- [ ] The `<done>` description matches the must-have or success criterion it covers
-- [ ] `checkpoint:*` usage is consistent with `autonomous`
-
-### Red Flags
-- A success criterion has no task covering it
-- A task has no corresponding success criterion
-- Two tasks modify the same file in contradictory ways
-- A task depends on output from a later task
-- All verify steps are observational text with no runnable commands
-</plan_self_check>
+- [ ] The `<done>` description matches the must-have or success criterion it covers
+- [ ] `checkpoint:*` usage is consistent with `autonomous`
+
+### Check The Anti-Drift Contract
+- [ ] `non_goals` are explicit and would stop adjacent cleanup or feature widening
+- [ ] `hard_boundaries` identify the main no-touch surfaces
+- [ ] `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
+
+### Red Flags
+- A success criterion has no task covering it
+- A task has no corresponding success criterion
+- Two tasks modify the same file in contradictory ways
+- A task depends on output from a later task
+- All verify steps are observational text with no runnable commands
+- The plan can drift into adjacent cleanup because the anti-goals or hard boundaries are vague
+- The executor could cross a risky boundary without tripping a stop-and-challenge condition
+- The plan claims phase completion more broadly than its own evidence contract can prove
+</plan_self_check>
 
 <success_criteria>
 Planning is done when all of these are true:
@@ -487,19 +596,21 @@ Planning is done when all of these are true:
 - [ ] Target phase identified from `ROADMAP.md`
 - [ ] 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
-- [ ] Plan self-check passed
-- [ ] Success criteria from `ROADMAP.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`, 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
-- [ ] Any git guidance stays repo-native and follows `.planning/config.json`
-</success_criteria>
+- [ ] Research check completed where needed
+- [ ] Roadmap phase contract includes requirements, success criteria, explicit out-of-scope, and explicit stop/replan conditions
+- [ ] Plan self-check passed
+- [ ] Success criteria from `ROADMAP.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`, `closure_claim_limit`, `parallelism_budget`, `leverage`, 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`
+</success_criteria>
 
 <completion>
 Report to the user what was accomplished, then present the next step: