gsdd-cli 0.27.0 → 0.29.0

package/distilled/templates/approach.md

@@ -1,12 +1,12 @@
 # Phase Approach Template
 
-Template for `.planning/phases/XX-name/{phase_num}-APPROACH.md` — captures implementation decisions and validated assumptions for a phase.
+Template for `.work/phases/XX-name/{phase_num}-APPROACH.md` — captures implementation decisions and validated assumptions for a phase.
 
 **Purpose:** Document decisions that downstream agents need. Planner uses this to know WHAT choices are locked vs flexible. Plan-checker verifies plans honor these decisions.
 
 **Key principle:** The top-level structure (`<domain>`, `<decisions>`, `<assumptions>`, `<deferred>`) is fixed. Section names WITHIN `<decisions>` emerge from what was actually discussed for THIS phase — a CLI phase has CLI-relevant sections, a UI phase has UI-relevant sections.
 
-**Alignment proof:** When `.planning/config.json` has `workflow.discuss: true`, every APPROACH artifact must include an `## Alignment Proof` section before `<domain>`. It must record the canonical fields `alignment_status`, `alignment_method`, `user_confirmed_at`, `explicit_skip_approved`, `skip_scope`, `skip_rationale`, and `confirmed_decisions`. `Agent's Discretion` and agent-only "No questions needed" are not valid proof.
+**Alignment proof:** When `.work/config.json` has `workflow.discuss: true`, every APPROACH artifact must include an `## Alignment Proof` section before `<domain>`. It must record the canonical fields `alignment_status`, `alignment_method`, `user_confirmed_at`, `explicit_skip_approved`, `skip_scope`, `skip_rationale`, and `confirmed_decisions`. `Agent's Discretion` and agent-only "No questions needed" are not valid proof.
 
 **Downstream consumers:**
 - `planner` — Reads decisions to constrain implementation choices. Locked decisions must be implemented. Agent's Discretion items allow planner flexibility.
@@ -266,7 +266,7 @@ Users can register and log in with email/password. Session management via JWT. O
 The output should answer: "What choices are locked for the planner? Where does the planner have discretion?"
 
 **After creation:**
-- File lives in phase directory: `.planning/phases/XX-name/{phase_num}-APPROACH.md`
+- File lives in phase directory: `.work/phases/XX-name/{phase_num}-APPROACH.md`
 - Planner reads decisions to constrain implementation tasks
 - Plan-checker verifies approach_alignment: plans must implement chosen approaches
 - Downstream agents should NOT need to ask the user again about captured decisions

package/distilled/templates/auth-matrix.md

@@ -1,7 +1,7 @@
 # Authorization Matrix Template
 
 > OWASP-style authorization matrix for systematic auth verification.
-> Create `.planning/AUTH_MATRIX.md` using this template when your project has multiple user roles or protected resources.
+> Create `.work/AUTH_MATRIX.md` using this template when your project has multiple user roles or protected resources.
 
 ## When to Create This Matrix
 
@@ -73,6 +73,6 @@ The narrative auth check (Step 4) always runs regardless of whether this matrix
 
 ## File Location
 
-Save your project's authorization matrix as `.planning/AUTH_MATRIX.md`.
+Save your project's authorization matrix as `.work/AUTH_MATRIX.md`.
 
 The integration checker will automatically detect and consume it when present. No configuration needed.

package/distilled/templates/brownfield-change/CHANGE.md

@@ -9,7 +9,7 @@ type: medium_scope_brownfield
 > This folder is the bounded medium-scope lane.
 > It represents one active medium-scope change only.
 > Do not add phase numbering, roadmap checkboxes, or milestone state here.
-> Instantiate the live operational artifact at `.planning/brownfield-change/CHANGE.md`.
+> Instantiate the live operational artifact at `.work/brownfield-change/CHANGE.md`.
 > `progress` and `resume` read this file first for status, scope, integration surface, and the authoritative next action.
 > If this lane no longer fits one active stream, widen explicitly through `/gsdd-new-project` (first milestone) or `/gsdd-new-milestone` (subsequent milestone) using this folder as the preserved input surface. Do not invent a separate promotion artifact.
 

package/distilled/templates/delegates/approach-explorer.md

@@ -1,4 +1,4 @@
-**Role contract:** Read `.planning/templates/roles/approach-explorer.md` before starting. Follow its algorithm, scope, anti-patterns, and quality standards.
+**Role contract:** Read `.work/templates/roles/approach-explorer.md` before starting. Follow its algorithm, scope, anti-patterns, and quality standards.
 
 You are the approach explorer delegate for the plan workflow.
 
@@ -7,12 +7,12 @@ You are the approach explorer delegate for the plan workflow.
 When `workflow.discuss: true`, APPROACH.md must prove user alignment before planning: use `alignment_status: user_confirmed` for real user-confirmed decisions or `alignment_status: approved_skip` only when the user explicitly approves skipping discussion. Record the canonical fields `alignment_method`, `user_confirmed_at`, `explicit_skip_approved`, `skip_scope`, `skip_rationale`, and `confirmed_decisions`. `Agent's Discretion` and agent-only "No questions needed" are not valid alignment proof.
 
 Read only the explicit inputs provided by the orchestrator:
-- target phase goal and requirement IDs from `.planning/ROADMAP.md`
-- project config from `.planning/config.json`, especially `workflow.discuss`
-- locked decisions and deferred items from `.planning/SPEC.md`
+- target phase goal and requirement IDs from `.work/ROADMAP.md`
+- project config from `.work/config.json`, especially `workflow.discuss`
+- locked decisions and deferred items from `.work/SPEC.md`
 - phase research file (if exists)
 - relevant codebase files (existing patterns and conventions)
-- approach template at `.planning/templates/approach.md`
+- approach template at `.work/templates/approach.md`
 
 ## Gray Area Classification
 

package/distilled/templates/delegates/mapper-arch.md

@@ -1,8 +1,8 @@
-**Role contract:** Read `.planning/templates/roles/mapper.md` before starting. Follow its algorithm, quality guarantees, and anti-patterns.
+**Role contract:** Read `.work/templates/roles/mapper.md` before starting. Follow its algorithm, quality guarantees, and anti-patterns.
 
 Map the architecture and structure of this codebase. Read key source files to understand component boundaries, data flow, and patterns.
 
-Write ARCHITECTURE.md to `.planning/codebase/` using the template at `.planning/templates/codebase/architecture.md`.
+Write ARCHITECTURE.md to `.work/codebase/` using the template at `.work/templates/codebase/architecture.md`.
 
 Include:
 - Major components and their responsibilities (what belongs in each, what doesn't)
@@ -21,6 +21,6 @@ Include:
 - [ ] Golden files table populated with at least one file per major layer
 </quality_gate>
 
-Write to: `.planning/codebase/ARCHITECTURE.md`
+Write to: `.work/codebase/ARCHITECTURE.md`
 Return: Routing summary to the Orchestrator (100-200 tokens) when done.
 Guardrails: Max Agent Hops = 3. No static directory dumps.

package/distilled/templates/delegates/mapper-concerns.md

@@ -1,10 +1,10 @@
-**Role contract:** Read `.planning/templates/roles/mapper.md` before starting. Follow its algorithm, quality guarantees, and anti-patterns.
+**Role contract:** Read `.work/templates/roles/mapper.md` before starting. Follow its algorithm, quality guarantees, and anti-patterns.
 
 Map the technical debt, security concerns, and risks in this codebase.
 
-**Security check first (hard stop):** Follow the Hard stop directive in `.planning/templates/roles/mapper.md` — grep for secrets before writing anything. If found: STOP and report to Orchestrator immediately.
+**Security check first (hard stop):** Follow the Hard stop directive in `.work/templates/roles/mapper.md` — grep for secrets before writing anything. If found: STOP and report to Orchestrator immediately.
 
-If no secrets found, write CONCERNS.md to `.planning/codebase/` using the template at `.planning/templates/codebase/concerns.md`.
+If no secrets found, write CONCERNS.md to `.work/codebase/` using the template at `.work/templates/codebase/concerns.md`.
 
 Include:
 - Known bugs or fragile areas (with file references where possible)
@@ -22,6 +22,6 @@ Include:
 - [ ] Downstream impact table ranks at least top 3 concerns with Blocks column populated
 </quality_gate>
 
-Write to: `.planning/codebase/CONCERNS.md`
+Write to: `.work/codebase/CONCERNS.md`
 Return: Routing summary to the Orchestrator (100-200 tokens) when done. If secrets found, STOP and report immediately.
 Guardrails: Max Agent Hops = 3. Hard stop on secrets.

package/distilled/templates/delegates/mapper-quality.md

@@ -1,8 +1,8 @@
-**Role contract:** Read `.planning/templates/roles/mapper.md` before starting. Follow its algorithm, quality guarantees, and anti-patterns.
+**Role contract:** Read `.work/templates/roles/mapper.md` before starting. Follow its algorithm, quality guarantees, and anti-patterns.
 
 Map the conventions and quality patterns of this codebase. Read existing tests, lint config, and code samples.
 
-Write CONVENTIONS.md to `.planning/codebase/` using the template at `.planning/templates/codebase/conventions.md`.
+Write CONVENTIONS.md to `.work/codebase/` using the template at `.work/templates/codebase/conventions.md`.
 
 Include:
 - Naming patterns (files, functions, variables, exports)
@@ -23,6 +23,6 @@ Include:
 - [ ] Golden files section lists at least 2 files with rationale
 </quality_gate>
 
-Write to: `.planning/codebase/CONVENTIONS.md`
+Write to: `.work/codebase/CONVENTIONS.md`
 Return: Routing summary to the Orchestrator (100-200 tokens) when done.
 Guardrails: Max Agent Hops = 3. Rules not inventories.

package/distilled/templates/delegates/mapper-tech.md

@@ -1,8 +1,8 @@
-**Role contract:** Read `.planning/templates/roles/mapper.md` before starting. Follow its algorithm, quality guarantees, and anti-patterns.
+**Role contract:** Read `.work/templates/roles/mapper.md` before starting. Follow its algorithm, quality guarantees, and anti-patterns.
 
 Map the technology stack of this codebase. Read package manifests, lockfiles, and entry points.
 
-Write STACK.md to `.planning/codebase/` using the template at `.planning/templates/codebase/stack.md`.
+Write STACK.md to `.work/codebase/` using the template at `.work/templates/codebase/stack.md`.
 
 Include:
 - Languages and runtimes (with versions)
@@ -20,6 +20,6 @@ Include:
 - [ ] Must-know packages section identifies at least 3 packages with risk index (low/medium/high)
 </quality_gate>
 
-Write to: `.planning/codebase/STACK.md`
+Write to: `.work/codebase/STACK.md`
 Return: Routing summary to the Orchestrator (100-200 tokens) when done.
 Guardrails: Max Agent Hops = 3. No static dependency dumps.

package/distilled/templates/delegates/plan-checker.md

@@ -1,43 +1,42 @@
-**Role contract:** Read `.planning/templates/roles/planner.md` before starting. Reuse its planning vocabulary and quality standards, but this wrapper overrides your objective: you are reviewing plans, not authoring them.
+**Role contract:** Read `.work/templates/roles/planner.md` before starting. Reuse its planning vocabulary and quality standards, but this wrapper overrides your objective: you are reviewing plans, not authoring them.
 
 You are the fresh-context plan checker for `/gsdd-plan`. This is a read-only review delegate: return the JSON finding summary only, and do not edit plan artifacts yourself.
 
 Read only the explicit inputs provided by the orchestrator:
 - target phase goal and requirement IDs
-- relevant locked decisions or 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 provided)
+- relevant locked decisions or 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 provided)
 - any relevant phase research file
-- the produced `.planning/phases/*-PLAN.md` file(s)
+- the produced `.work/phases/*-PLAN.md` file(s)
 
 Do NOT inherit the planner's hidden reasoning. Treat the current plans as untrusted drafts that must prove they will achieve the phase goal before execution.
 
 Verify these dimensions:
-- `requirement_coverage`: every phase requirement is covered by at least one concrete task
+- `requirement_coverage`: every phase requirement is covered by at least one concrete task.
 - `task_completeness`: every executable task has files, action, verify, and done fields. Additionally check verify quality:
   - **Runnable?** Does `<verify>` contain at least one command that an executor can run programmatically (e.g., a shell command, test runner invocation, curl request)? If ALL verify items are observational text with no runnable command -> `blocker`.
   - **Fast?** Do verify commands complete quickly? Flag full E2E suites (playwright, cypress, selenium) without a faster smoke test -> `warning`. Flag watch-mode flags (`--watchAll`, `--watch`) -> `blocker`. Flag arbitrary delays > 30s -> `warning`.
   - **Ordered?** If a verify command references a test file, does an earlier task in the plan create that file? If the referenced file has no prior task producing it -> `blocker`.
-- `dependency_correctness`: ordering, dependencies, and plan structure are coherent
-- `key_link_completeness`: important wiring/integration links are planned, not just isolated artifacts
-- `scope_sanity`: plans are sized so an executor can complete them without context collapse
-- `must_have_quality`: success criteria and must-haves are specific, observable, and reflected in tasks
+  - **Browser proof command?** If the plan requires browser proof, the Browser Proof Plan names a runnable evidence command or an explicit narrowed no-command rationale. A rendered-UI claim with neither is a `blocker`.
+- `dependency_correctness`: ordering, dependencies, and plan structure are coherent.
+- `key_link_completeness`: important wiring/integration links are planned, not just isolated artifacts.
+- `scope_sanity`: plans are sized so an executor can complete them without context collapse, and hard boundaries, anti-goals, and explicit out-of-scope items are preserved in task scope.
+- `must_have_quality`: success criteria and must-haves are specific, observable, and reflected in tasks.
 - `context_compliance`: locked decisions are honored and deferred ideas stay out of scope. Additionally check scope consistency:
   - **Must-have coverage?** Every must-have requirement mapped to this phase in SPEC.md must appear in at least one plan task. A must-have that silently disappears from the plan is a `blocker`.
   - **Deferred exclusion?** Items marked "Nice to Have", "Deferred", or "Out of Scope" in SPEC.md must not appear as plan tasks. Present → `blocker`.
   - **Cross-surface consistency?** If SPEC.md marks an item as must-have but APPROACH.md marks it as deferred (or vice versa), surface the contradiction → `blocker`. Include a `fix_hint` asking the planner to resolve the conflict with the user before proceeding.
+  - **Anti-regression captured?** Known prior failures, compatibility risks, and behavior that must not regress are represented in tasks or verification.
+  - **Escalation preserved?** Tasks include checkpoints or escalation when evidence, permissions, user decisions, or risky ambiguity are required.
+  - **Abstraction justified?** Reject a task or refactor whose only rationale is "cleaner code" without reducing risk, removing meaningful duplication, simplifying a consumer path, or matching an existing repo pattern.
 - `goal_achievement`: does the plan, if executed perfectly, actually achieve the stated phase goal? Check:
   - **Goal addressed?** Compare the phase goal statement to the plan's collective task outputs. Would successful completion of all tasks deliver the goal? If the goal says "users can authenticate" but tasks only set up database schema → `blocker`.
   - **Success criteria reachable?** Are the phase success criteria from ROADMAP.md achievable through the planned tasks? Each success criterion should be traceable to at least one task's verify output → `blocker` if unreachable.
   - **Outcome observable?** After execution, could a human or automated check confirm the goal was met? Plans that produce only internal artifacts with no user-visible or testable outcome → `warning`.
-- `scope_boundaries`: hard boundaries, anti-goals, and explicit out-of-scope items are preserved in task scope.
-- `anti_regression_capture`: known prior failures, compatibility risks, and behavior that must not regress are represented in tasks or verification.
-- `escalation_integrity`: tasks include checkpoints or escalation when evidence, permissions, user decisions, or risky ambiguity are required.
-- `closure_honesty`: the plan's done criteria and evidence limits support only claims that execution can actually prove.
-- `closure_honesty`: for UI proof, reject agent-only `looks good` closure, artifact-count proof, unsupported evidence kinds, and human acceptance that converts missing/mismatched non-human evidence into `satisfied` proof. Waiver, deferment, proof debt, or narrowed-claim language is acceptable only when the stronger UI claim is not treated as proven.
-- `closure_honesty`: for UI proof planning, reject weak slots that omit a specific route/state, viewport rationale or narrowed viewport claim limit, minimum observations, expected artifact types, runnable validation, or a way to compare observed proof back to the planned claim. Treat under-specified viewport coverage as a blocker for responsive or layout-sensitive claims. `agent-browser` is the default live runtime evidence path; do not block a slot solely for using another project-native browser path, but require the plan to explain the `agent-browser` availability constraint and fallback choice.
-- `closure_honesty`: for UI proof privacy, require artifact `visibility`, `retention`, `sensitivity`, and `safe_to_publish`, require `gsdd ui-proof validate` or `gsdd health` when bundle metadata exists, and reject public/tracked/delivery/publication proof claims backed by local-only or `safe_to_publish: false` artifacts.
-- `high_leverage_review`: high-leverage surfaces have a second-pass review or equivalent contradiction/staleness check before completion.
+  - **Claim honest?** Done criteria and evidence limits support only claims that execution can actually prove. For browser proof, reject agent-only "looks good" closure, artifact-count proof, unsupported evidence kinds, and human acceptance that replaces required code, test, runtime, or delivery evidence.
+  - **Browser proof specific?** Required browser proof names exact route/state, viewport coverage or a narrowed viewport claim, runtime path, evidence kind, rendered observations, artifacts/privacy notes, and claim limit. Under-specified viewport coverage is a blocker for responsive or layout-sensitive claims, and fallback browser tooling must state the `agent-browser` availability constraint.
+  - **Second pass present?** Shared or high-leverage surfaces have a final contradiction/staleness review before completion.
 - `approach_alignment`: when APPROACH.md is provided, verify that plan tasks implement the chosen approaches from the user's decisions. Check:
   - **Alignment proof valid?** When `workflow.discuss` is `true`, APPROACH.md must record `alignment_status: user_confirmed` or `alignment_status: approved_skip`. Missing alignment proof, unknown status, or agent-discretion-only proof -> `blocker` with `fix_hint` telling the planner to revise APPROACH.md through real user alignment or an explicit user-approved skip.
   - **Canonical proof fields present?** APPROACH.md must include all canonical proof fields: `alignment_status`, `alignment_method`, `user_confirmed_at`, `explicit_skip_approved`, `skip_scope`, `skip_rationale`, and `confirmed_decisions`. Missing fields -> `blocker`.
@@ -56,7 +55,7 @@ Return JSON only as a single finding summary object with this shape:
   "summary": "One sentence overall assessment",
   "issues": [
     {
-      "dimension": "requirement_coverage | task_completeness | dependency_correctness | key_link_completeness | scope_sanity | must_have_quality | context_compliance | goal_achievement | scope_boundaries | anti_regression_capture | escalation_integrity | closure_honesty | high_leverage_review | approach_alignment",
+      "dimension": "requirement_coverage | task_completeness | dependency_correctness | key_link_completeness | scope_sanity | must_have_quality | context_compliance | goal_achievement | approach_alignment",
       "severity": "blocker | warning",
       "description": "What is wrong",
       "plan": "01-PLAN",

package/distilled/templates/delegates/researcher-architecture.md

@@ -1,4 +1,4 @@
-**Role contract:** Read `.planning/templates/roles/researcher.md` before starting. Follow its algorithm, quality guarantees, and anti-patterns.
+**Role contract:** Read `.work/templates/roles/researcher.md` before starting. Follow its algorithm, quality guarantees, and anti-patterns.
 
 You are researching ONE dimension: how systems in this domain are typically structured.
 
@@ -24,7 +24,7 @@ Your output informs phase structure in ROADMAP.md. Include:
 - [ ] Hard-to-reverse decisions flagged explicitly
 </quality_gate>
 
-Write to: `.planning/research/ARCHITECTURE.md`
-Use template: `.planning/templates/research/architecture.md` (if it exists)
+Write to: `.work/research/ARCHITECTURE.md`
+Use template: `.work/templates/research/architecture.md` (if it exists)
 Return: Human-read structured summary to the Orchestrator (300-500 tokens) when done.
 Guardrails: Max Agent Hops = 3.

package/distilled/templates/delegates/researcher-features.md

@@ -1,4 +1,4 @@
-**Role contract:** Read `.planning/templates/roles/researcher.md` before starting. Follow its algorithm, quality guarantees, and anti-patterns.
+**Role contract:** Read `.work/templates/roles/researcher.md` before starting. Follow its algorithm, quality guarantees, and anti-patterns.
 
 You are researching ONE dimension: what features exist in this domain.
 
@@ -24,7 +24,7 @@ Your output feeds SPEC requirements. Categorize explicitly:
 - [ ] v1 vs v2 recommendation for differentiators
 </quality_gate>
 
-Write to: `.planning/research/FEATURES.md`
-Use template: `.planning/templates/research/features.md` (if it exists)
+Write to: `.work/research/FEATURES.md`
+Use template: `.work/templates/research/features.md` (if it exists)
 Return: Human-read structured summary to the Orchestrator (300-500 tokens) when done.
 Guardrails: Max Agent Hops = 3.

package/distilled/templates/delegates/researcher-pitfalls.md

@@ -1,4 +1,4 @@
-**Role contract:** Read `.planning/templates/roles/researcher.md` before starting. Follow its algorithm, quality guarantees, and anti-patterns.
+**Role contract:** Read `.work/templates/roles/researcher.md` before starting. Follow its algorithm, quality guarantees, and anti-patterns.
 
 You are researching ONE dimension: what goes wrong in projects in this domain.
 
@@ -24,7 +24,7 @@ Your output prevents mistakes in roadmap and planning. For each pitfall:
 - [ ] Sources cited for non-obvious claims
 </quality_gate>
 
-Write to: `.planning/research/PITFALLS.md`
-Use template: `.planning/templates/research/pitfalls.md` (if it exists)
+Write to: `.work/research/PITFALLS.md`
+Use template: `.work/templates/research/pitfalls.md` (if it exists)
 Return: Human-read structured summary to the Orchestrator (300-500 tokens) when done.
 Guardrails: Max Agent Hops = 3.

package/distilled/templates/delegates/researcher-stack.md

@@ -1,4 +1,4 @@
-**Role contract:** Read `.planning/templates/roles/researcher.md` before starting. Follow its algorithm, quality guarantees, and anti-patterns.
+**Role contract:** Read `.work/templates/roles/researcher.md` before starting. Follow its algorithm, quality guarantees, and anti-patterns.
 
 You are researching ONE dimension: the technology stack for the project domain.
 
@@ -24,7 +24,7 @@ Your output feeds the roadmapper. Be prescriptive:
 - [ ] Confidence level assigned to each recommendation
 </quality_gate>
 
-Write to: `.planning/research/STACK.md`
-Use template: `.planning/templates/research/stack.md` (if it exists)
+Write to: `.work/research/STACK.md`
+Use template: `.work/templates/research/stack.md` (if it exists)
 Return: Human-read structured summary to the Orchestrator (300-500 tokens) when done.
 Guardrails: Max Agent Hops = 3.

package/distilled/templates/delegates/researcher-synthesizer.md

@@ -1,12 +1,12 @@
-**Role contract:** Read `.planning/templates/roles/synthesizer.md` before starting. Follow its algorithm, quality guarantees, and anti-patterns.
+**Role contract:** Read `.work/templates/roles/synthesizer.md` before starting. Follow its algorithm, quality guarantees, and anti-patterns.
 
 Synthesize the 4 research files into a single actionable SUMMARY.md.
 
 Read these files (all should exist):
-- `.planning/research/STACK.md`
-- `.planning/research/FEATURES.md`
-- `.planning/research/ARCHITECTURE.md`
-- `.planning/research/PITFALLS.md`
+- `.work/research/STACK.md`
+- `.work/research/FEATURES.md`
+- `.work/research/ARCHITECTURE.md`
+- `.work/research/PITFALLS.md`
 
 Cross-reference them. Surface conflicts and dependencies between findings. Do NOT do new research — synthesize what exists.
 
@@ -17,7 +17,7 @@ SUMMARY.md MUST include:
 4. **Confidence Assessment** — per domain: stack / features / architecture / pitfalls
 5. **Sources** — all sources cited across the 4 research files, deduplicated
 
-Use template: `.planning/templates/research/summary.md` (if it exists)
+Use template: `.work/templates/research/summary.md` (if it exists)
 
 <quality_gate>
 - [ ] "Implications for Roadmap" section populated with phase suggestions
@@ -26,6 +26,6 @@ Use template: `.planning/templates/research/summary.md` (if it exists)
 - [ ] No new claims introduced (only synthesis)
 </quality_gate>
 
-Write to: `.planning/research/SUMMARY.md`
+Write to: `.work/research/SUMMARY.md`
 Return: Agent-mediated structured summary to the Orchestrator (500-800 tokens) when done.
 Guardrails: Max Agent Hops = 2. Do not do new research — synthesize only.

package/distilled/templates/research/architecture.md

@@ -2,7 +2,7 @@
 
 Use when researching system structure and patterns for a project or phase.
 
-Write to: `.planning/research/ARCHITECTURE.md`
+Write to: `.work/research/ARCHITECTURE.md`
 
 ---
 

package/distilled/templates/research/pitfalls.md

@@ -2,7 +2,7 @@
 
 Use when researching common mistakes and gotchas for a domain or technology.
 
-Write to: `.planning/research/PITFALLS.md`
+Write to: `.work/research/PITFALLS.md`
 
 ---
 

package/distilled/templates/research/stack.md

@@ -2,7 +2,7 @@
 
 Use when researching the technology stack for a project or phase.
 
-Write to: `.planning/research/STACK.md`
+Write to: `.work/research/STACK.md`
 
 ---
 

package/distilled/templates/roadmap.md

@@ -1,6 +1,6 @@
 # ROADMAP.md Template
 
-Use this template when creating `.planning/ROADMAP.md` (phase breakdown + progress tracker).
+Use this template when creating `.work/ROADMAP.md` (phase breakdown + progress tracker).
 
 ```markdown
 # Roadmap: [Project Name]
@@ -21,7 +21,7 @@ Use this template when creating `.planning/ROADMAP.md` (phase breakdown + progre
 
 **Goal**: [What this phase delivers]
 **Status**: [ ]
-**Requirements**: [REQ-IDs from `.planning/SPEC.md`]
+**Requirements**: [REQ-IDs from `.work/SPEC.md`]
 **Success Criteria** (must be TRUE when done):
 1. [Observable behavior]
 2. [Observable behavior]
@@ -53,7 +53,7 @@ Use this template when creating `.planning/ROADMAP.md` (phase breakdown + progre
 ## Guidelines
 
 - Prefer 3-8 phases for most projects.
-- Every v1 requirement in `.planning/SPEC.md` must map to exactly one phase (no orphans).
+- Every v1 requirement in `.work/SPEC.md` must map to exactly one phase (no orphans).
 - Success criteria are 2-5 observable behaviors per phase.
 - No time estimates: focus on verifiable outcomes.
 - These status markers are the portable source of truth. Workflow files and summaries should use `[ ]`, `[-]`, and `[x]` consistently.
@@ -64,7 +64,7 @@ Use this template when creating `.planning/ROADMAP.md` (phase breakdown + progre
 
 After creating the roadmap, verify:
 ```
-For each v1 requirement in .planning/SPEC.md:
+For each v1 requirement in .work/SPEC.md:
   [ ] Requirement appears in exactly one phase's "Requirements" list
   [ ] The phase's success criteria would prove the requirement is met
 ```

package/distilled/templates/spec.md

@@ -1,6 +1,6 @@
 # SPEC.md Template
 
-Use this template when creating `.planning/SPEC.md` - the project's single source of truth.
+Use this template when creating `.work/SPEC.md` - the project's single source of truth.
 
 > **Agentic PRD Constraint:** Do not write narrative prose or fluff. Use strict checklists, dense tables, and typed schemas. There is no artificial line limit, but every single line must be highly deterministic and actionable for a downstream Subagent.
 
@@ -105,5 +105,5 @@ If auditing an existing codebase during `init`:
 
 When a major milestone completes:
 1. The SPEC.md "Current State" section reflects the new state
-2. Completed phases have summaries in `.planning/phases/{N}-SUMMARY.md`
+2. Completed phases have summaries in `.work/phases/{N}-SUMMARY.md`
 3. SPEC.md itself stays lean - don't accumulate history here