fix(m0e): one dialect — CLI strings, docs, and distilled README match shipped reality

README.md

@@ -129,7 +129,7 @@ Use `--auto` for non-interactive install into detected local agent homes. Use `-
 | Codex CLI | `~/.agents/skills`, `~/.codex/agents` |
 | GitHub Copilot CLI | `~/.agents/skills`, `~/.copilot/agents` |
 
-Install availability is not a parity claim. Claude Code, OpenCode, and Codex CLI remain the directly validated runtimes; GitHub Copilot CLI is available as a qualified global target.
+Install availability is not a parity claim. Repo proof currently covers Claude Code, OpenCode, and Codex CLI paths; GitHub Copilot CLI is available as a qualified global target.
 
 OpenCode honors `OPENCODE_CONFIG_DIR` for commands and agents; Workspine installs portable skills once in the shared agent-compatible global root.
 

agents/DISTILLATION.md

@@ -135,12 +135,12 @@ Evidence map from each of the 10 canonical GSDD roles to their GSD sources, with
 - Checklist-driven completion
 
 **Stripped from GSD:**
-- Template-path references (output lives in `.planning/ROADMAP.md`)
+- Template-path references (output lives in `.work/ROADMAP.md`)
 - Commit steps (GSDD handles git separately)
 - Vendor-specific file conventions
 
 **Gained in GSDD (PR #15 hardening):**
-- Explicit `.planning/ROADMAP.md` ownership contract
+- Explicit `.work/ROADMAP.md` ownership contract
 - Explicit `[ ]` / `[-]` / `[x]` status grammar
 - Concrete `ROADMAP CREATED` artifact example
 - Hard boundary: "this role does not settle the separate ROADMAP/STATE lifecycle seam"

agents/README.md

@@ -17,7 +17,7 @@ Workspine uses subagents when isolation earns its cost: research, review, mappin
 
 Subagents must not become hidden implementation orchestration. Implementation remains plan-scoped and write-set constrained; overlapping implementation writes require explicit write-set ownership in the approved plan before any parallelism is safe.
 
-Roadmapper is intentionally role-only/direct invocation in the current catalog. There is no roadmapper delegate because roadmap creation is sequential, coverage-sensitive, and writes `.planning/ROADMAP.md`; a future delegate would need a proven thin-wrapper use case before it is added.
+Roadmapper is intentionally role-only/direct invocation in the current catalog. There is no roadmapper delegate because roadmap creation is sequential, coverage-sensitive, and writes `.work/ROADMAP.md` in default workspaces; a future delegate would need a proven thin-wrapper use case before it is added.
 
 Leverage record: lost flexibility to add delegates by symmetry; kept the two-layer role/delegate architecture and summaries-up/documents-to-disk model; gained a conservative boundary that prevents subagents from implying agent teams, parallel PR orchestration, or runtime parity claims.
 
@@ -50,11 +50,11 @@ The catalog contains 10 canonical roles across lifecycle, audit, and utility res
 
 ## Runtime Distribution
 
-`gsdd init` copies all role contracts (excluding this README) from `agents/` into `.planning/templates/roles/` in the consumer project. This gives consumer projects a portable, self-contained copy of the role library with no hard dependency on the GSDD framework repo at runtime.
+`gsdd init` copies all role contracts (excluding this README) from `agents/` into `.work/templates/roles/` in the consumer project. Legacy `.planning/` workspaces receive localized `.planning/templates/roles/` paths. This gives consumer projects a portable, self-contained copy of the role library with no hard dependency on the GSDD framework repo at runtime.
 
 - **Single source of truth:** `agents/*.md` in this repo. Consumer copies are generated, not edited.
-- **Delegates reference the local copy:** `distilled/templates/delegates/*.md` point to `.planning/templates/roles/<role>.md`, not back to this repo.
-- **Idempotent:** `gsdd init` skips the copy if `.planning/templates/roles/` already exists.
+- **Delegates reference the local copy:** `distilled/templates/delegates/*.md` point to `.work/templates/roles/<role>.md`, not back to this repo; legacy installs localize those paths to `.planning/templates/roles/<role>.md`.
+- **Idempotent:** `gsdd init` skips the copy if `.work/templates/roles/` already exists.
 - **Updates:** `gsdd update --templates` re-copies from latest framework sources with hash-based modification detection.
 
 Verifier note:

agents/approach-explorer.md

@@ -46,12 +46,12 @@ Do NOT:
 <input_contract>
 Read only the explicit inputs provided. Extract only what you need:
 
-- **From `.planning/SPEC.md`:** locked decisions and deferred items ONLY (skip project description, requirements prose)
-- **From `.planning/ROADMAP.md`:** target phase goal, requirements, and success criteria ONLY (skip other phases)
+- **From `.work/SPEC.md`:** locked decisions and deferred items ONLY (skip project description, requirements prose)
+- **From `.work/ROADMAP.md`:** target phase goal, requirements, and success criteria ONLY (skip other phases)
 - **Phase research** (if exists): skim for findings relevant to gray area identification
 - **Codebase files** (if provided): existing patterns and conventions that inform approach choices
 - **Existing APPROACH.md** (if updating): load current decisions as starting point
-- **Project config** (if provided from `.planning/config.json`): check `workflow.discuss` to decide whether alignment proof is mandatory
+- **Project config** (if provided from `.work/config.json`): check `workflow.discuss` to decide whether alignment proof is mandatory
 </input_contract>
 
 <output_contract>
@@ -178,7 +178,7 @@ If any check fails, address it with the user before proceeding.
 
 ## Step 8: Write APPROACH.md
 
-Write `{padded_phase}-APPROACH.md` to the phase directory using the approach template at `.planning/templates/approach.md`.
+Write `{padded_phase}-APPROACH.md` to the phase directory using the approach template at `.work/templates/approach.md`.
 
 Structure sections by what was actually discussed — section names match gray areas, not a generic template.
 

agents/executor.md

@@ -11,7 +11,7 @@ You DO NOT freelance. You DO NOT add features outside the plan.
 CRITICAL: Tiered context intake
 
 - `mandatory_now`: read the PLAN.md contract, current task, bounded SPEC current state/requirements/constraints, ROADMAP phase goal/status/success criteria, and the applicable `<judgment>` handoff before mutating files or lifecycle state.
-- If no prior SUMMARY `<judgment>` exists, check for `.planning/.continue-here.bak` before mutation; if present, read its `<judgment>`, honor the same constraints, then run `node .planning/bin/gsdd.mjs file-op delete .planning/.continue-here.bak --missing ok`.
+- If no prior SUMMARY `<judgment>` exists, check for `.work/.continue-here.bak` before mutation; if present, read its `<judgment>`, honor the same constraints, then run `node .work/bin/gsdd.mjs file-op delete .work/.continue-here.bak --missing ok`.
 - `task_scoped`: read files and focused references for the current task before editing that task. Do not preload every file from every task just because it appears in `<files_to_read>`.
 - `reference_only`: consult deeper SPEC, ROADMAP, codebase maps, or project conventions only for the specific decision or invariant being validated.
 - `deferred_or_conditional`: read broader history only when the current task or deviation requires it.
@@ -45,7 +45,7 @@ The executor is plan-scoped:
 ## Core Algorithm
 
 1. **Load plan.** Parse frontmatter (`phase`, `plan`, `type`, `wave`, `depends_on`, `files-modified`, `autonomous`, `requirements`, `must_haves`), objective, context references, and tasks. Treat any prompt-provided `<files_to_read>` block as task_scoped unless it explicitly labels entries as mandatory_now.
-2. **Run lifecycle preflight.** Before mutating lifecycle artifacts, run `node .planning/bin/gsdd.mjs lifecycle-preflight execute {phase_num} --expects-mutation phase-status`. If blocked, stop and surface the blocker.
+2. **Run lifecycle preflight.** Before mutating lifecycle artifacts, run `node .work/bin/gsdd.mjs lifecycle-preflight execute {phase_num} --expects-mutation phase-status`. If blocked, stop and surface the blocker.
 3. **For each task:**
    a. If `type="auto"`: Confirm mandatory_now context is loaded, read the task_scoped files and focused references needed for the current task, execute the task, apply deviation rules as needed, run verification, confirm done criteria, and handle any git actions using repo/user conventions.
    b. If `type="checkpoint:*"`: STOP immediately. Return structured checkpoint message with all progress so far. A fresh agent will continue.
@@ -187,7 +187,7 @@ 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.
+- 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 backup judgment auto-clean.
 
 ### Change-Impact Discipline
@@ -379,7 +379,7 @@ Summary-driven progress tracking avoids silent drift between the plan contract a
 <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
@@ -393,14 +393,14 @@ Keep the update factual and compact:
 ### 2. Update ROADMAP.md Phase Status
 Do not hand-edit ROADMAP status. Use the status-aware helper:
 
-- `node .planning/bin/gsdd.mjs phase-status {phase_num} in_progress`
+- `node .work/bin/gsdd.mjs phase-status {phase_num} in_progress`
 
-Do NOT run `node .planning/bin/gsdd.mjs phase-status {phase_num} done` from execute. Execute marks implementation progress only; phase verification owns final `[x]` closure.
+Do NOT run `node .work/bin/gsdd.mjs phase-status {phase_num} done` from execute. Execute marks implementation progress only; phase verification owns final `[x]` closure.
 
-### 3. Rebaseline Reviewed Planning State
+### 3. Confirm Reviewed Planning State
 After SPEC and ROADMAP status updates are reviewed as intentional, run:
 
-- `node .planning/bin/gsdd.mjs session-fingerprint write`
+- `node .work/bin/gsdd.mjs next --json`
 
 </state_updates>
 
@@ -413,10 +413,10 @@ For each completed task:
   [ ] Local verification passed
 
 For state updates:
-  [ ] .planning/SPEC.md "Current State" is accurate
+  [ ] .work/SPEC.md "Current State" is accurate
    [ ] `phase-status` helper ran instead of direct ROADMAP status editing
    [ ] ROADMAP.md status remains open (`[-]` if status was updated) until verification passes
-   [ ] `session-fingerprint write` ran after reviewed planning-state updates
+   [ ] `next --json` ran after reviewed planning-state updates
    [ ] SUMMARY.md exists, records `runtime` and `assurance`, and reflects the actual work
    [ ] SUMMARY.md includes structured `<checks>`, `<handoff>`, `<deltas>`, and `<judgment>` sections
 
@@ -439,7 +439,7 @@ After each task (verification passed, done criteria met):
 
 Git rules:
 - Repo and user conventions win first.
-- `.planning/config.json -> gitProtocol` is advisory only.
+- `.work/config.json -> gitProtocol` is advisory only.
 - Do not force one commit per task unless the repo or user asked for that.
 
 <quality_guarantees>
@@ -471,13 +471,13 @@ Execution is done when all of these are true:
 - [ ] Any checkpoint task caused an explicit stop and handoff instead of silent continuation
 - [ ] Deviation rules were followed (Rules 1-3 auto-fixed, Rule 4 stopped)
 - [ ] Authentication gates handled with the auth-gate protocol, not as bugs
-- [ ] `.planning/SPEC.md` current state is updated accurately
+- [ ] `.work/SPEC.md` current state is updated accurately
 - [ ] `ROADMAP.md` progress was updated through `phase-status`, not hand-edited
-- [ ] `session-fingerprint write` ran after reviewed planning-state updates
+- [ ] `next --json` ran after reviewed planning-state updates
 - [ ] `SUMMARY.md` is written with substantive one-liner, typed frontmatter, `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>
 
 <vendor_hints>

agents/integration-checker.md

@@ -45,7 +45,7 @@ Optional but useful context:
 
 - expected cross-phase dependencies from the roadmap
 - likely sensitive routes, pages, or flows that should enforce auth
-- `.planning/AUTH_MATRIX.md` (if it exists — enables matrix-driven auth verification in Step 4a)
+- `.work/AUTH_MATRIX.md` (if it exists — enables matrix-driven auth verification in Step 4a)
 
 Rules:
 
@@ -130,7 +130,7 @@ If a route or flow touches account, billing, admin, profile, or user-scoped data
 
 ## Step 4a: Matrix-Driven Auth Verification
 
-If `.planning/AUTH_MATRIX.md` does not exist, skip this sub-step. Step 4 narrative checking always runs regardless.
+If `.work/AUTH_MATRIX.md` does not exist, skip this sub-step. Step 4 narrative checking always runs regardless.
 
 When the matrix exists:
 

agents/researcher.md

@@ -10,8 +10,8 @@ Accountable for producing verified, confidence-rated research about technologies
 
 | Scope | Trigger | Focus | Output Location |
 |-------|---------|-------|-----------------|
-| **Project** | New project initialization | Domain ecosystem: stack, features, architecture, pitfalls | Research directory (e.g., `.planning/research/`) |
-| **Phase** | Phase planning | Implementation approach: standard stack, patterns, don't-hand-roll, pitfalls | Phase directory (e.g., `.planning/phases/XX-name/`) |
+| **Project** | New project initialization | Domain ecosystem: stack, features, architecture, pitfalls | Research directory (e.g., `.work/research/`) |
+| **Phase** | Phase planning | Implementation approach: standard stack, patterns, don't-hand-roll, pitfalls | Phase directory (e.g., `.work/phases/XX-name/`) |
 
 Same algorithm, different scope. The scope is a context input, not a different role.
 

agents/roadmapper.md

@@ -5,7 +5,7 @@
 <role>
 You are a roadmapper. You turn requirements into a phased delivery plan that downstream planners can execute without guessing.
 
-Roadmapper is role-only/direct invocation in the current Workspine contract, not a delegate. Roadmap creation is sequential, coverage-sensitive, and owns `.planning/ROADMAP.md`; do not route it through a hidden subagent wrapper unless a future plan explicitly adds that delegate.
+Roadmapper is role-only/direct invocation in the current Workspine contract, not a delegate. Roadmap creation is sequential, coverage-sensitive, and owns `.work/ROADMAP.md`; do not route it through a hidden subagent wrapper unless a future plan explicitly adds that delegate.
 
 Your job:
 - derive phases from requirements instead of imposing a template
@@ -117,7 +117,7 @@ Every criterion must be verifiable by a human using the product.
 </goal_backward_phases>
 
 <output>
-Write `.planning/ROADMAP.md`.
+Write `.work/ROADMAP.md`.
 
 Write or update the roadmap artifact before returning your summary. Do not leave the roadmap only in the return text.
 
@@ -177,7 +177,7 @@ Presentation expectations:
 
 <scope_boundary>
 This role owns roadmap structure only:
-- writes or revises `.planning/ROADMAP.md`
+- writes or revises `.work/ROADMAP.md`
 - preserves requirement ownership and phase status inside that artifact
 - does not create or redefine separate state artifacts such as `STATE.md`
 - does not decompose phases into executable tasks
@@ -202,7 +202,7 @@ When the roadmap is first written successfully, return:
 ```markdown
 ## ROADMAP CREATED
 
-**Artifact written:** .planning/ROADMAP.md
+**Artifact written:** .work/ROADMAP.md
 **Phases:** 3
 **Coverage:** 9/9 requirements mapped
 
@@ -286,13 +286,13 @@ If a section does not improve requirement coverage, dependency order, or observa
 - [ ] Phases derived from natural delivery boundaries
 - [ ] Every in-scope requirement mapped to exactly one phase
 - [ ] Every phase has observable success criteria
-- [ ] `.planning/ROADMAP.md` contract preserved with summary checklist and detail sections
+- [ ] `.work/ROADMAP.md` contract preserved with summary checklist and detail sections
 - [ ] Parse-critical phase headers, status markers, and requirement ownership lines preserved
 - [ ] Structured draft/revised/blocked return provided with explicit coverage status
 </success_criteria>
 
 ## Vendor Hints
 
 - **Tools required:** file read, file write, content search
-- **Parallelizable:** No - roadmapping is sequential, coverage-sensitive, and writes `.planning/ROADMAP.md` directly
+- **Parallelizable:** No - roadmapping is sequential, coverage-sensitive, and writes `.work/ROADMAP.md` directly
 - **Context budget:** Moderate - the reasoning work is heavier than the I/O