gsdd-cli 0.27.0 → 0.28.0

package/distilled/workflows/audit-milestone.md

@@ -6,28 +6,28 @@ Core mindset: individual phases can pass while the milestone fails. Integration
 
 <load_context>
 Before starting, read these files:
-1. `.planning/ROADMAP.md` - milestone phases, definitions of done, requirement assignments
-2. `.planning/SPEC.md` - requirement IDs, descriptions, and checkbox status
-3. All phase VERIFICATION.md files (from `.planning/phases/`)
-4. All phase SUMMARY.md files (from `.planning/phases/`)
-5. `.planning/AUTH_MATRIX.md` (if it exists) — authorization matrix for matrix-driven auth verification
+1. `.work/ROADMAP.md` - milestone phases, definitions of done, requirement assignments
+2. `.work/SPEC.md` - requirement IDs, descriptions, and checkbox status
+3. All phase VERIFICATION.md files (from `.work/phases/`)
+4. All phase SUMMARY.md files (from `.work/phases/`)
+5. `.work/AUTH_MATRIX.md` (if it exists) — authorization matrix for matrix-driven auth verification
 </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 determining milestone scope or spawning the integration checker, run:
 
-- `node .planning/bin/gsdd.mjs lifecycle-preflight audit-milestone`
+- `node .work/bin/gsdd.mjs lifecycle-preflight audit-milestone`
 
 If the preflight result is `blocked`, STOP and report the blocker instead of inferring milestone eligibility from workflow-local prose.
 
 Treat the preflight as an authorization seam over shared repo truth only:
 - it may authorize or reject milestone audit
 - it does not archive or mutate milestone state
-- the owned write for this workflow remains `.planning/v{version}-MILESTONE-AUDIT.md`
+- the owned write for this workflow remains `.work/v{version}-MILESTONE-AUDIT.md`
 </lifecycle_preflight>
 
 <evidence_contract>
@@ -64,25 +64,25 @@ Rules:
 - deferrals must name the unsupported claim, missing evidence kind(s), and later workflow or milestone candidate when known
 - contradiction checks must cover evidence, public-surface, runtime, delivery, planning-drift, and generated-surface contradictions; stop or downgrade when the claim outruns the evidence
 - `delivery_posture` and `release_claim_posture` must remain compatible: `repo_closeout` and `runtime_validated_closeout` pair with `repo_only`; `delivery_supported_closeout` pairs with `delivery_sensitive`
-- local-only `.planning/` proof may support `repo_closeout`, but public-facing release/support claims need tracked public or repo-visible evidence when intended for external readers
+- local-only `.work/` proof may support `repo_closeout`, but public-facing release/support claims need tracked public or repo-visible evidence when intended for external readers
 </evidence_contract>
 
 <process>
 
 ## 1. Determine Milestone Scope
 
-Parse `.planning/ROADMAP.md` for:
+Parse `.work/ROADMAP.md` for:
 - All phases in the current milestone (sorted numerically)
 - Milestone definition of done
 - Phase-to-requirement mappings (the Requirements field in each phase detail)
 
-Parse `.planning/SPEC.md` for:
+Parse `.work/SPEC.md` for:
 - All requirement IDs with descriptions
 - Current checkbox status (`[x]` vs `[ ]`)
 
 ## 2. Read All Phase Verifications
 
-For each phase directory in `.planning/phases/`, read the VERIFICATION.md.
+For each phase directory in `.work/phases/`, read the VERIFICATION.md.
 
 From each VERIFICATION.md, extract:
 - **Status:** passed | gaps_found | human_needed
@@ -99,14 +99,14 @@ With phase context collected, delegate cross-phase integration checking:
 
 <delegate>
 **Identity:** Integration Checker
-**Instruction:** Read `.planning/templates/roles/integration-checker.md`, then check cross-phase integration.
+**Instruction:** Read `.work/templates/roles/integration-checker.md`, then check cross-phase integration.
 
 **Context to provide:**
 - Phase directories in milestone scope
 - Key exports from each phase (extracted from SUMMARYs)
 - API routes and endpoints created
 - Milestone requirement IDs with descriptions and assigned phases
-- `.planning/AUTH_MATRIX.md` path (if it exists)
+- `.work/AUTH_MATRIX.md` path (if it exists)
 
 **Task:** Verify cross-phase wiring, API coverage, auth protection, and E2E user flows. Return structured integration report with wiring summary, API coverage, auth protection, E2E flow status, and Requirements Integration Map.
 
@@ -134,12 +134,12 @@ Cross-reference three independent sources for each requirement to determine sati
 
 ### 5a. Parse SPEC.md Requirements
 
-Extract all requirement IDs from `.planning/SPEC.md`:
+Extract all requirement IDs from `.work/SPEC.md`:
 - Requirement ID, description, checkbox status (`[x]` vs `[ ]`)
 
 ### 5b. Parse ROADMAP.md Phase-to-Requirement Mapping
 
-For each phase in `.planning/ROADMAP.md`, extract the Requirements field:
+For each phase in `.work/ROADMAP.md`, extract the Requirements field:
 - Which requirements are assigned to which phase
 
 ### 5c. Parse Phase VERIFICATION.md Requirements Tables
@@ -170,11 +170,11 @@ For each requirement, determine status using all available sources:
 
 **FAIL gate:** Any `unsatisfied` requirement forces `gaps_found` status on the milestone audit. No exceptions.
 
-**Orphan detection:** Requirements in `.planning/SPEC.md` that are mapped to phases in `.planning/ROADMAP.md` but absent from ALL phase VERIFICATION.md files are orphaned. Orphaned requirements are treated as `unsatisfied` - they were assigned but never verified by any phase.
+**Orphan detection:** Requirements in `.work/SPEC.md` that are mapped to phases in `.work/ROADMAP.md` but absent from ALL phase VERIFICATION.md files are orphaned. Orphaned requirements are treated as `unsatisfied` - they were assigned but never verified by any phase.
 
 ## 6. Write Milestone Audit Report
 
-Create `.planning/v{version}-MILESTONE-AUDIT.md` with structured frontmatter:
+Create `.work/v{version}-MILESTONE-AUDIT.md` with structured frontmatter:
 
 ```yaml
 ---
@@ -240,10 +240,10 @@ Evidence gate:
 - `repo_only` audits cannot be downgraded merely because `runtime` or `delivery` evidence was never relevant
 - a `passed` audit must have no unsupported stronger release claims unless they are explicitly downgraded or deferred in `release_claim_contract`
 - invalid waivers are blockers: human approval cannot replace missing `code`, `test`, `runtime`, or `delivery` evidence for a stronger claim
-- public/support wording must be scoped to tracked public or repo-visible evidence; local-only `.planning/` artifacts cannot carry public release claims by themselves
+- public/support wording must be scoped to tracked public or repo-visible evidence; local-only `.work/` artifacts cannot carry public release claims by themselves
 - generated-surface freshness is claim-scoped: W11-style drift blocks only claims that depend on generated runtime/helper freshness, not unrelated repo-only closeout
 
-**MANDATORY: The milestone audit report must exist at `.planning/v{version}-MILESTONE-AUDIT.md` on disk before presenting results. If the file was not written, STOP and report the write failure. Do NOT present audit results from conversation context alone — this is the highest-cost artifact to regenerate. Do NOT downgrade a write failure into "results shown inline anyway."**
+**MANDATORY: The milestone audit report must exist at `.work/v{version}-MILESTONE-AUDIT.md` on disk before presenting results. If the file was not written, STOP and report the write failure. Do NOT present audit results from conversation context alone — this is the highest-cost artifact to regenerate. Do NOT downgrade a write failure into "results shown inline anyway."**
 
 ## 7. Present Results
 
@@ -285,13 +285,13 @@ Audit is complete when all of these are true:
 Report the audit result to the user, then present the next step:
 
 ---
-**Completed:** Milestone audit — created `.planning/v{version}-MILESTONE-AUDIT.md`.
+**Completed:** Milestone audit — created `.work/v{version}-MILESTONE-AUDIT.md`.
 
 If status is `passed`:
 **Next step:** `/gsdd-complete-milestone` — archive the milestone and prepare for the next
 
 If status is `gaps_found`:
-**Next step:** `/gsdd-plan-milestone-gaps` — create gap-closure phases for the unsatisfied requirements
+**Next step:** `/gsdd-plan` amend/extend mode — create gap-closure phases for the unsatisfied requirements
 
 If status is `tech_debt`:
 **Next step:** Either `/gsdd-complete-milestone` (accept debt) or `/gsdd-plan` (cleanup phase)

package/distilled/workflows/complete-milestone.md

@@ -7,39 +7,39 @@ Scope boundary: you archive the current milestone. You do not start the next one
 </role>
 
 <prerequisites>
-`.planning/ROADMAP.md` must exist with phases.
-`.planning/SPEC.md` must exist.
-If `.planning/MILESTONES.md` does not exist, create it now (this is the first milestone completion — Step 8 will write the first entry).
+`.work/ROADMAP.md` must exist with phases.
+`.work/SPEC.md` must exist.
+If `.work/MILESTONES.md` does not exist, create it now (this is the first milestone completion — Step 8 will write the first entry).
 
-If `.planning/milestones/` does not exist, create it before writing archive files.
+If `.work/milestones/` does not exist, create it before writing archive files.
 </prerequisites>
 
 <load_context>
 Before starting, read these files:
 
-1. `.planning/ROADMAP.md` — phase statuses, milestone name, phase range
-2. `.planning/SPEC.md` — requirements, validated capabilities, current state section
-3. `.planning/MILESTONES.md` — previous milestone entries (for format reference); if this is the first milestone, skip — no previous entries exist yet
-4. `.planning/config.json` — `gitProtocol`, `mode` (for STOP gate behavior)
-5. All phase SUMMARY.md files in `.planning/phases/` — accomplishments, task counts
-6. Most recent `.planning/v*-MILESTONE-AUDIT.md` — audit status (passed / gaps_found)
+1. `.work/ROADMAP.md` — phase statuses, milestone name, phase range
+2. `.work/SPEC.md` — requirements, validated capabilities, current state section
+3. `.work/MILESTONES.md` — previous milestone entries (for format reference); if this is the first milestone, skip — no previous entries exist yet
+4. `.work/config.json` — `gitProtocol`, `mode` (for STOP gate behavior)
+5. All phase SUMMARY.md files in `.work/phases/` — accomplishments, task counts
+6. Most recent `.work/v*-MILESTONE-AUDIT.md` — audit status (passed / gaps_found)
 </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 verifying readiness or gathering archive stats, run:
 
-- `node .planning/bin/gsdd.mjs lifecycle-preflight complete-milestone`
+- `node .work/bin/gsdd.mjs lifecycle-preflight complete-milestone`
 
 If the preflight result is `blocked`, STOP and report the blocker instead of inferring milestone-close eligibility from workflow-local prose.
 
 Treat the preflight as an authorization seam over shared repo truth only:
 - it may authorize or reject milestone completion
 - it does not mutate lifecycle state by itself
-- owned writes remain the archive artifacts, `MILESTONES.md`, `.planning/SPEC.md`, and the retained `ROADMAP.md` collapse
+- owned writes remain the archive artifacts, `MILESTONES.md`, `.work/SPEC.md`, and the retained `ROADMAP.md` collapse
 </lifecycle_preflight>
 
 <evidence_contract>
@@ -66,7 +66,7 @@ Read the audit frontmatter and preserve:
 Shared closure rules:
 - `repo_only` completion may proceed with repo-local closure evidence only; do not invent `runtime` or `delivery` proof
 - `delivery_sensitive` completion must not proceed on code/prose-only evidence; the audit must already show required `code`, `test`, `runtime`, and `delivery` evidence with no missing required kinds
-- if the audit omits the evidence contract or still has missing required kinds, STOP and route back to `/gsdd-audit-milestone` or `/gsdd-plan-milestone-gaps` instead of silently closing the milestone
+- if the audit omits the evidence contract or still has missing required kinds, STOP and route back to `/gsdd-audit-milestone` or `/gsdd-plan` amend/extend mode instead of silently closing the milestone
 - release claim postures are inherited from audit:
   - `repo_closeout` permits repo-local milestone closure only and must not imply public support, delivery, runtime validation, generated-surface freshness, package publication, tags, or GitHub Releases
   - `runtime_validated_closeout` may name only the runtime or surface with explicit `runtime` evidence
@@ -74,7 +74,7 @@ Shared closure rules:
 - inherited `delivery_posture` and `release_claim_posture` must be compatible: `repo_closeout` and `runtime_validated_closeout` use `repo_only`; `delivery_supported_closeout` uses `delivery_sensitive`
 - waivers are valid only when they narrow the release claim or defer an unsupported claim. Deferrals must name the unsupported claim, missing evidence kind(s), and later workflow or milestone candidate when known. STOP if a waiver preserves a stronger claim while required evidence is missing.
 - STOP if `release_claim_contract.unsupported_claims` remain without downgrade or deferral, if unsupported claims, invalid waivers, or failed contradiction checks remain, or if completion wording would claim more than the audit evidence supports. Failed contradiction checks are claim-scoped: generated-surface failures block only runtime/generated freshness claims, not unrelated `repo_closeout` completion.
-- local-only `.planning/` proof can support repo closeout, but cannot become public release proof by itself.
+- local-only `.work/` proof can support repo closeout, but cannot become public release proof by itself.
 </evidence_contract>
 
 <process>
@@ -93,7 +93,7 @@ Check:
 
 STOP without archiving. Route to the narrowest corrective workflow instead:
 1. **Run audit first** — `/gsdd-audit-milestone` if audit is missing, stale, or missing required release-claim schema.
-2. **Close gaps first** — `/gsdd-plan-milestone-gaps` if audit found gaps or the release claim outruns available evidence.
+2. **Close gaps first** — `/gsdd-plan` amend/extend mode if audit found gaps or the release claim outruns available evidence.
 3. **Abort** — stop without archiving if the user does not want corrective work now.
 
 **If all phases complete, audit passed, the audit evidence contract is satisfied, and the inherited release claim contract has no unsupported stronger claims:** Proceed.
@@ -122,7 +122,7 @@ Present 4-8 accomplishments for review. Trim or adjust with user before writing
 
 ## 5. Archive Roadmap
 
-Create `.planning/milestones/v[X.Y]-ROADMAP.md` with full milestone details:
+Create `.work/milestones/v[X.Y]-ROADMAP.md` with full milestone details:
 
 ```markdown
 # Milestone v[X.Y]: [Name]
@@ -173,19 +173,19 @@ Plans:
 
 ---
 
-*For current project status, see `.planning/ROADMAP.md`*
+*For current project status, see `.work/ROADMAP.md`*
 ```
 
 ## 6. Archive Requirements
 
-Create `.planning/milestones/v[X.Y]-REQUIREMENTS.md`:
+Create `.work/milestones/v[X.Y]-REQUIREMENTS.md`:
 
 ```markdown
 # Requirements Archive: v[X.Y] Milestone
 
 **Archived:** [date]
 **Milestone:** [name]
-**Source:** `.planning/SPEC.md` requirements section at milestone completion
+**Source:** `.work/SPEC.md` requirements section at milestone completion
 
 ---
 
@@ -211,17 +211,17 @@ Create `.planning/milestones/v[X.Y]-REQUIREMENTS.md`:
 
 ---
 
-*Source: `.planning/SPEC.md` as of [date]*
+*Source: `.work/SPEC.md` as of [date]*
 *Next milestone requirements: defined via `/gsdd-new-milestone`*
 ```
 
 ## 7. Move Audit File
 
-If `.planning/v[X.Y]-MILESTONE-AUDIT.md` exists, note its location in the MILESTONES.md entry. (Leave the file in `.planning/` — it is already in the gitignored planning directory. No move required unless you prefer to co-locate it with the other archives.)
+If `.work/v[X.Y]-MILESTONE-AUDIT.md` exists, note its location in the MILESTONES.md entry. (Leave the file in `.work/` — it is already in the gitignored planning directory. No move required unless you prefer to co-locate it with the other archives.)
 
 ## 8. Update MILESTONES.md
 
-Append an entry to `.planning/MILESTONES.md`:
+Append an entry to `.work/MILESTONES.md`:
 
 ```markdown
 ## ✅ v[X.Y] — [Name] ([date])
@@ -239,8 +239,8 @@ Append an entry to `.planning/MILESTONES.md`:
 3. [Accomplishment 3]
 4. [Accomplishment 4]
 
-**Archive:** `.planning/milestones/v[X.Y]-ROADMAP.md`
-**Requirements:** `.planning/milestones/v[X.Y]-REQUIREMENTS.md`
+**Archive:** `.work/milestones/v[X.Y]-ROADMAP.md`
+**Requirements:** `.work/milestones/v[X.Y]-REQUIREMENTS.md`
 **Suggested tag:** `v[X.Y]` (advisory; omit or mark not created unless git confirms it exists)
 ```
 
@@ -259,7 +259,7 @@ Update SPEC.md to reflect the completed milestone:
 
 - **Milestone:** v[X.Y] [Name] — COMPLETED [date]
 - **Phases:** [N]–[M] complete, all requirements verified ([N]/[N]), [test count] tests passing
-- **Archive:** `.planning/milestones/v[X.Y]-ROADMAP.md`
+- **Archive:** `.work/milestones/v[X.Y]-ROADMAP.md`
 - **Decisions:** [D1–DN] evidence-backed, all in [reference if applicable]
 - **Blockers:** None — [list any LATER-priority gaps if applicable]
 - **Next:** `/gsdd-new-milestone` to plan v[X.next] work
@@ -288,7 +288,7 @@ Replace the active milestone phases in ROADMAP.md with a collapsed `<details>` b
 - [x] **Phase [N+1]: [Name]** — completed [date]
 [...]
 
-Full details: [`.planning/milestones/v[X.Y]-ROADMAP.md`](milestones/v[X.Y]-ROADMAP.md)
+Full details: [`.work/milestones/v[X.Y]-ROADMAP.md`](milestones/v[X.Y]-ROADMAP.md)
 
 </details>
 
@@ -315,9 +315,9 @@ Advisory: Tag this milestone in git:
 - [ ] Version confirmed
 - [ ] Stats gathered from SUMMARY.md files and git
 - [ ] Accomplishments extracted and reviewed
-- [ ] `.planning/milestones/v[X.Y]-ROADMAP.md` created with full phase details
-- [ ] `.planning/milestones/v[X.Y]-REQUIREMENTS.md` created with all requirement statuses
-- [ ] `.planning/MILESTONES.md` updated with new entry
+- [ ] `.work/milestones/v[X.Y]-ROADMAP.md` created with full phase details
+- [ ] `.work/milestones/v[X.Y]-REQUIREMENTS.md` created with all requirement statuses
+- [ ] `.work/MILESTONES.md` updated with new entry
 - [ ] SPEC.md Must Have requirements moved to Validated section
 - [ ] SPEC.md Current State updated to reflect completed status
 - [ ] ROADMAP.md collapsed with `<details>` block pointing to archive
@@ -333,11 +333,11 @@ Report to the user what was archived, then present the next step:
 **Completed:** Milestone v[X.Y] [Name] archived.
 
 Archived:
-- `.planning/milestones/v[X.Y]-ROADMAP.md` — full phase details
-- `.planning/milestones/v[X.Y]-REQUIREMENTS.md` — requirements at milestone completion
-- `.planning/MILESTONES.md` — updated milestone history
-- `.planning/SPEC.md` — requirements evolved, current state updated
-- `.planning/ROADMAP.md` — active phases collapsed to `<details>`
+- `.work/milestones/v[X.Y]-ROADMAP.md` — full phase details
+- `.work/milestones/v[X.Y]-REQUIREMENTS.md` — requirements at milestone completion
+- `.work/MILESTONES.md` — updated milestone history
+- `.work/SPEC.md` — requirements evolved, current state updated
+- `.work/ROADMAP.md` — active phases collapsed to `<details>`
 
 **Next step:** `/gsdd-new-milestone` — start the next milestone cycle
 

package/distilled/workflows/execute.md

@@ -8,34 +8,34 @@ You follow the plan, verify before reporting completion, document deviations, an
 Load only the context needed for the next safe action. Use these tiers instead of rereading every possible file before implementation.
 
 ### mandatory_now
-Read before mutation: target `PLAN.md` frontmatter/current task/boundaries; bounded `.planning/SPEC.md` current state, active requirement IDs, and relevant constraints; `.planning/ROADMAP.md` phase goal/status/success criteria; immediately prior `.planning/phases/*-SUMMARY.md` `<judgment>` when present; and the preflight result from `<lifecycle_preflight>`.
-If no immediately prior SUMMARY `<judgment>` exists, check whether `.planning/.continue-here.bak` exists before mutation. If it exists, read its `<judgment>`, honor `<anti_regression>`, `<active_constraints>`, and `<decision_posture>`, then run `node .planning/bin/gsdd.mjs file-op delete .planning/.continue-here.bak --missing ok` (workflow-owned auto-clean).
+Read before mutation: target `PLAN.md` frontmatter/current task/boundaries; bounded `.work/SPEC.md` current state, active requirement IDs, and relevant constraints; `.work/ROADMAP.md` phase goal/status/success criteria; immediately prior `.work/phases/*-SUMMARY.md` `<judgment>` when present; and the preflight result from `<lifecycle_preflight>`.
+If no immediately prior SUMMARY `<judgment>` exists, check whether `.work/.continue-here.bak` exists before mutation. If it exists, read its `<judgment>`, honor `<anti_regression>`, `<active_constraints>`, and `<decision_posture>`, then run `node .work/bin/gsdd.mjs file-op delete .work/.continue-here.bak --missing ok` (workflow-owned auto-clean).
 
 ### task_scoped
 Read before editing each task, not all at startup: current task `<files>` entries, relevant source needed for current symbols/callers/tests/generated surfaces, and focused neighboring references found by targeted search.
 
 ### reference_only
-Consult deeper `.planning/SPEC.md` and `.planning/ROADMAP.md` sections only for the specific decision, requirement, or status being validated.
+Consult deeper `.work/SPEC.md` and `.work/ROADMAP.md` sections only for the specific decision, requirement, or status being validated.
 
 ### deferred_or_conditional
 Read only when the current task or a deviation needs them: older phase summaries and broader historical context beyond the mandatory-now handoff.
 </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 implementing or mutating any lifecycle artifact, run:
-- `node .planning/bin/gsdd.mjs lifecycle-preflight execute {phase_num} --expects-mutation phase-status`
+- `node .work/bin/gsdd.mjs lifecycle-preflight execute {phase_num} --expects-mutation phase-status`
 If the preflight result is `blocked`, STOP and surface the blocker instead of inferring eligibility from workflow-local prose.
 
 Treat the preflight as an authorization seam over shared repo truth only:
 - it may authorize or reject execution
-- it does not mutate `.planning/ROADMAP.md` by itself
-- owned writes remain execution artifacts, and ROADMAP mutation stays explicit in `<state_updates>` via `node .planning/bin/gsdd.mjs phase-status`
+- it does not mutate `.work/ROADMAP.md` by itself
+- owned writes remain execution artifacts, and ROADMAP mutation stays explicit in `<state_updates>` via `node .work/bin/gsdd.mjs phase-status`
 </lifecycle_preflight>
-<control_map_check>Before code mutation, run `node .planning/bin/gsdd.mjs control-map --json` when available. Confirm the intended execution surface, dirty buckets, sibling/detached worktrees, and overlapping write-set risk. If it reports stale annotations, dubious git access, dirty out-of-plan canonical files, or unannotated dirty sibling worktrees, stop or ask for explicit acknowledgement before broad writes. Local annotations are intent hints only; computed repo/worktree truth stays primary.
+<control_map_check>Before code mutation, run `node .work/bin/gsdd.mjs control-map --json` when available. Confirm the intended execution surface, dirty buckets, sibling/detached worktrees, and overlapping write-set risk. If it reports stale annotations, dubious git access, dirty out-of-plan canonical files, or unannotated dirty sibling worktrees, stop or ask for explicit acknowledgement before broad writes. Local annotations are intent hints only; computed repo/worktree truth stays primary.
 </control_map_check>
 <runtime_contract>
 Execution uses the same `Runtime` and `Assurance` types as planning and verification.
@@ -55,7 +55,7 @@ If plan runtime/assurance is missing, use `status: unknown`.
 A phase often contains multiple plans. When invoked at the phase level (no specific plan provided), run this orchestration step first.
 
 ### Discover Plans and Group by Wave
-1. Scan `.planning/phases/{phase_dir}/` for all `*-PLAN.md` files.
+1. Scan `.work/phases/{phase_dir}/` for all `*-PLAN.md` files.
 2. For each plan, read its frontmatter `wave` field (default: `wave: 1` if absent).
 3. Group plans by wave number. Collect the set of distinct wave numbers and sort them ascending.
 4. Check for `*-SUMMARY.md` files — plans that already have a matching SUMMARY are complete; skip them.
@@ -119,8 +119,8 @@ Checkpoint tasks are contract boundaries. Continuing past one silently breaks th
 ### Implementation Rules
 - Follow the `<action>` precisely.
 - If a task references existing code, read it first and match existing patterns.
-- If you are unsure about something, check `.planning/SPEC.md` decisions first, then ask if still unclear.
-- Do not run destructive git, broad cleanup, or file deletion actions without explicit human approval, except explicitly named workflow-owned housekeeping commands such as `.planning/.continue-here.bak` auto-clean.
+- If you are unsure about something, check `.work/SPEC.md` decisions first, then ask if still unclear.
+- Do not run destructive git, broad cleanup, or file deletion actions without explicit human approval, except explicitly named workflow-owned housekeeping commands such as `.work/.continue-here.bak` auto-clean.
 
 ### Change-Impact Discipline
 Before modifying any existing behavior, run a targeted ripple check for the current task:
@@ -195,7 +195,7 @@ git commit -m "feat: wire users page to real route"
 
 Git rules:
 - **Repo and user conventions win first.** This table is a reference, not a mandate.
-- `.planning/config.json -> gitProtocol` is advisory only.
+- `.work/config.json -> gitProtocol` is advisory only.
 - **Stage only files listed in the plan's `files-modified` frontmatter.** Never use `git add .` or `git add -A`. If you need to stage a file not in `files-modified`, record it as a deviation.
 - **Wrong-branch check:** Before significant implementation begins, verify HEAD is not `main` or `master` if repo convention expects a feature branch; if it is, STOP and hard-warn the user before proceeding.
 - **Transition-safety warning pass:** Before significant implementation begins, inspect staged, unstaged, untracked, unpushed, PR-less, stale/spent, and mixed-scope branch signals. Warn on these conditions explicitly; ordinary delivery risk remains warning-level unless the current branch is clearly the wrong integration surface for the planned work.
@@ -279,7 +279,7 @@ If a task fails verification 3 times after fixes, STOP and report the failure to
 <state_updates>
 After completing all tasks in the plan:
 
-### 1. Update `.planning/SPEC.md` "Current State"
+### 1. Update `.work/SPEC.md` "Current State"
 Keep the update factual and compact:
 
 ```markdown
@@ -292,18 +292,18 @@ Keep the update factual and compact:
 
 ### 2. Update ROADMAP.md Phase Status
 Do not hand-edit the ROADMAP checkbox line. Use the status-aware helper instead:
-- Run `node .planning/bin/gsdd.mjs phase-status {N} in_progress` when implementation work has started or this plan completes.
-- Do NOT run `node .planning/bin/gsdd.mjs phase-status {N} done` from execute. Only verify may close a phase after writing a `status: passed` VERIFICATION.md.
+- Run `node .work/bin/gsdd.mjs phase-status {N} in_progress` when implementation work has started or this plan completes.
+- Do NOT run `node .work/bin/gsdd.mjs phase-status {N} done` from execute. Only verify may close a phase after writing a `status: passed` VERIFICATION.md.
 
-The helper owns the `[ ]` / `[-]` / `[x]` mutation for `.planning/ROADMAP.md`, including both the overview line and the matching `## Phase Details` `**Status**` line when both exist.
+The helper owns the `[ ]` / `[-]` / `[x]` mutation for `.work/ROADMAP.md`, including both the overview line and the matching `## Phase Details` `**Status**` line when both exist.
 
-### 3. Rebaseline Reviewed Planning State
-After `.planning/SPEC.md` and `phase-status` updates are complete and reviewed as intentional, run:
-- `node .planning/bin/gsdd.mjs session-fingerprint write`
-This is the explicit planning-state handoff. Do not rely on a no-op `phase-status` command to rebaseline SPEC drift.
+### 3. Confirm Reviewed Planning State
+After `.work/SPEC.md` and `phase-status` updates are complete and reviewed as intentional, run:
+- `node .work/bin/gsdd.mjs next --json`
+This is the explicit routing-state handoff. Do not rely on a no-op `phase-status` command to prove the next action reflects reviewed SPEC or ROADMAP changes.
 
 ### 4. Write Phase Summary
-Create `.planning/phases/{phase_dir}/{plan_id}-SUMMARY.md` with:
+Create `.work/phases/{phase_dir}/{plan_id}-SUMMARY.md` with:
 
 ```markdown
 ---
@@ -377,7 +377,7 @@ Write the structured sections honestly:
 Do not invent an inline PLAN task-state mutation scheme if the plan does not define one.
 Summary-driven progress tracking avoids silent drift between the plan contract and what execution actually completed.
 
-**MANDATORY: You MUST write SUMMARY.md to disk at `.planning/phases/{phase_dir}/{plan_id}-SUMMARY.md`. Output to conversation alone is NOT sufficient. If this file is not written to disk, execution is NOT complete.**
+**MANDATORY: You MUST write SUMMARY.md to disk at `.work/phases/{phase_dir}/{plan_id}-SUMMARY.md`. Output to conversation alone is NOT sufficient. If this file is not written to disk, execution is NOT complete.**
 </state_updates>
 
 <checkpoint_protocol>
@@ -414,9 +414,9 @@ For each completed task:
   [ ] Local verification passed
 
 For state updates:
-  [ ] .planning/SPEC.md "Current State" is accurate
+  [ ] .work/SPEC.md "Current State" is accurate
   [ ] ROADMAP.md status remains open (`[-]` if status was updated) until verification passes
-  [ ] `node .planning/bin/gsdd.mjs session-fingerprint write` ran after reviewed SPEC and phase-status updates
+  [ ] `node .work/bin/gsdd.mjs next --json` ran after reviewed SPEC and phase-status updates
   [ ] SUMMARY.md exists with `<checks>`, `<handoff>`, `<deltas>`, and `<judgment>` and reflects the actual work
 
 Overall:
@@ -435,21 +435,21 @@ Execution is done when all of these are true:
 - [ ] Deviation rules were followed
 - [ ] Mandatory-now context and task-scoped files read at the correct execution point
 - [ ] Authentication gates handled with the auth-gate protocol
-- [ ] `.planning/SPEC.md` current state is updated accurately
+- [ ] `.work/SPEC.md` current state is updated accurately
 - [ ] `ROADMAP.md` uses `[ ]`, `[-]`, `[x]` consistently and is not marked `[x]` by execute
-- [ ] `node .planning/bin/gsdd.mjs session-fingerprint write` was run after reviewed planning-state updates
+- [ ] `node .work/bin/gsdd.mjs next --json` was run after reviewed planning-state updates
 - [ ] `SUMMARY.md` is written
 - [ ] `SUMMARY.md` frontmatter records `runtime` and `assurance`
 - [ ] `SUMMARY.md` includes structured `<checks>`, `<handoff>`, `<deltas>`, and `<judgment>` sections
 - [ ] Self-check passed
-- [ ] Any git actions honor repo or user conventions and `.planning/config.json`
+- [ ] Any git actions honor repo or user conventions and `.work/config.json`
 </success_criteria>
 
 <completion>
 Report what was accomplished, then present the next step:
 ---
-**Completed:** Plan execution — created `.planning/phases/{phase_dir}/{plan_id}-SUMMARY.md`.
-**Next step:** Check `.planning/config.json` → `workflow.verifier`:
+**Completed:** Plan execution — created `.work/phases/{phase_dir}/{plan_id}-SUMMARY.md`.
+**Next step:** Check `.work/config.json` → `workflow.verifier`:
 - If `true`: run `/gsdd-verify` — verify that the phase goal was achieved
 - If `false` (or key missing): run `/gsdd-progress` — check status and route to the next phase