@ktpartners/dgs-platform 2.9.0 → 3.3.0

package/deliver-great-systems/templates/project.md

@@ -1,186 +1,22 @@
 # PROJECT.md Template
 
-Template for `PROJECT.md` (in planning root) — the living project context document.
-
-> **Layout-agnostic:** Workflows access PROJECT.md via `${project_path}` from init output. Works in both standard and root layouts.
+Thin skeleton for `PROJECT.md` (in `${project_path}`). Projects are holders —
+product-level vision lives in `docs/product/PRODUCT-SUMMARY.md` (Tier 1), and
+product architecture lives in `docs/product/ARCHITECTURE.md` (Tier 2).
 
 <template>
 
 ```markdown
 # [Project Name]
 
-## What This Is
-
-[Current accurate description — 2-3 sentences. What does this product do and who is it for?
-Use the user's language and framing. Update whenever reality drifts from this description.]
-
-## Core Value
-
-[The ONE thing that matters most. If everything else fails, this must work.
-One sentence that drives prioritization when tradeoffs arise.]
-
-## Requirements
-
-### Validated
-
-<!-- Shipped and confirmed valuable. -->
-
-(None yet — ship to validate)
-
-### Active
-
-<!-- Current scope. Building toward these. -->
-
-- [ ] [Requirement 1]
-- [ ] [Requirement 2]
-- [ ] [Requirement 3]
-
-### Out of Scope
-
-<!-- Explicit boundaries. Includes reasoning to prevent re-adding. -->
-
-- [Exclusion 1] — [why]
-- [Exclusion 2] — [why]
-
-## Context
-
-[Background information that informs implementation:
-- Technical environment or ecosystem
-- Relevant prior work or experience
-- User research or feedback themes
-- Known issues to address]
-
-## Constraints
-
-- **[Type]**: [What] — [Why]
-- **[Type]**: [What] — [Why]
-
-Common types: Tech stack, Timeline, Budget, Dependencies, Compatibility, Performance, Security
-
-## Key Decisions
-
-<!-- Decisions that constrain future work. Add throughout project lifecycle. -->
-
-| Decision | Rationale | Outcome |
-|----------|-----------|---------|
-| [Choice] | [Why] | [✓ Good / ⚠️ Revisit / — Pending] |
-
----
-*Last updated: [date] after [trigger]*
+<One-line purpose — fill in to anchor this project.>
 ```
 
 </template>
 
-<guidelines>
-
-**What This Is:**
-- Current accurate description of the product
-- 2-3 sentences capturing what it does and who it's for
-- Use the user's words and framing
-- Update when the product evolves beyond this description
-
-**Core Value:**
-- The single most important thing
-- Everything else can fail; this cannot
-- Drives prioritization when tradeoffs arise
-- Rarely changes; if it does, it's a significant pivot
-
-**Requirements — Validated:**
-- Requirements that shipped and proved valuable
-- Format: `- ✓ [Requirement] — [version/phase]`
-- These are locked — changing them requires explicit discussion
-
-**Requirements — Active:**
-- Current scope being built toward
-- These are hypotheses until shipped and validated
-- Move to Validated when shipped, Out of Scope if invalidated
-
-**Requirements — Out of Scope:**
-- Explicit boundaries on what we're not building
-- Always include reasoning (prevents re-adding later)
-- Includes: considered and rejected, deferred to future, explicitly excluded
-
-**Context:**
-- Background that informs implementation decisions
-- Technical environment, prior work, user feedback
-- Known issues or technical debt to address
-- Update as new context emerges
-
-**Constraints:**
-- Hard limits on implementation choices
-- Tech stack, timeline, budget, compatibility, dependencies
-- Include the "why" — constraints without rationale get questioned
-
-**Key Decisions:**
-- Significant choices that affect future work
-- Add decisions as they're made throughout the project
-- Track outcome when known:
-  - ✓ Good — decision proved correct
-  - ⚠️ Revisit — decision may need reconsideration
-  - — Pending — too early to evaluate
-
-**Last Updated:**
-- Always note when and why the document was updated
-- Format: `after Phase 2` or `after v1.0 milestone`
-- Triggers review of whether content is still accurate
-
-</guidelines>
-
-<evolution>
-
-PROJECT.md evolves throughout the project lifecycle.
-
-**After each phase transition:**
-1. Requirements invalidated? → Move to Out of Scope with reason
-2. Requirements validated? → Move to Validated with phase reference
-3. New requirements emerged? → Add to Active
-4. Decisions to log? → Add to Key Decisions
-5. "What This Is" still accurate? → Update if drifted
-
-**After each milestone:**
-1. Full review of all sections
-2. Core Value check — still the right priority?
-3. Audit Out of Scope — reasons still valid?
-4. Update Context with current state (users, feedback, metrics)
-
-</evolution>
-
-<brownfield>
-
-For existing codebases:
-
-1. **Map codebase first** via `/dgs:map-codebase`
-
-2. **Infer Validated requirements** from existing code:
-   - What does the codebase actually do?
-   - What patterns are established?
-   - What's clearly working and relied upon?
-
-3. **Gather Active requirements** from user:
-   - Present inferred current state
-   - Ask what they want to build next
-
-4. **Initialize:**
-   - Validated = inferred from existing code
-   - Active = user's goals for this work
-   - Out of Scope = boundaries user specifies
-   - Context = includes current codebase state
-
-</brownfield>
-
 <state_reference>
 
-STATE.md references PROJECT.md:
-
-```markdown
-## Project Reference
-
-See: PROJECT.md (updated [date])
-
-**Core value:** [One-liner from Core Value section]
-**Current focus:** [Current phase name]
-```
-
-This ensures Claude reads current PROJECT.md context.
+STATE.md references PROJECT.md by path; the thin skeleton still satisfies
+`dgs-tools health` Check 2 (file exists + top-level heading).
 
 </state_reference>

package/deliver-great-systems/templates/summary.md

@@ -40,7 +40,9 @@ patterns-established:
   - "Pattern 1: description"
   - "Pattern 2: description"
 
-requirements-completed: []  # REQUIRED — Copy ALL requirement IDs from this plan's `requirements` frontmatter field.
+requirements_completed: []  # MANDATORY — Copy ALL requirement IDs from this plan's `requirements` frontmatter field VERBATIM. Empty array allowed only when PLAN's `requirements:` is also empty. Pre-commit precondition (REL-08) aborts the executor with `summary-frontmatter-mismatch` if non-empty PLAN paired with empty `requirements_completed`.
+# Canonical key: `requirements_completed` (underscore — pinned by Phase 157 / 157-Q2-FINDINGS.md).
+# The legacy hyphen variant is still readable by `cmdSummaryExtract` for backwards-compat with archived v23.1 SUMMARYs (REL-10 dual-read), but MUST NOT be used for new SUMMARYs.
 
 # Metrics
 duration: Xmin

package/deliver-great-systems/workflows/abandon-quick.md

@@ -0,0 +1,89 @@
+<purpose>
+Abandon the active product-level quick task: remove worktree and branch without merging. All committed and uncommitted changes in the worktree are discarded.
+
+Requires explicit confirmation before proceeding. This is destructive and cannot be undone.
+</purpose>
+
+<context_tier>none</context_tier>
+
+<process>
+
+**Step 1: Validate active quick**
+
+Check for active product-level quick:
+```bash
+ACTIVE=$(node -e "
+  const q = require('$HOME/.claude/deliver-great-systems/bin/lib/quick.cjs');
+  const a = q.getActiveQuick(process.cwd());
+  process.stdout.write(JSON.stringify(a || { none: true }));
+")
+```
+
+Parse result. If `none` is true:
+```
+╔══════════════════════════════════════════════════════════════╗
+║  ERROR                                                       ║
+╚══════════════════════════════════════════════════════════════╝
+
+No active product-level quick to abandon.
+
+If working in a milestone context, changes are part of the milestone.
+```
+End workflow.
+
+Extract `$SLUG` from result.
+
+**Step 2: Confirm abandonment**
+
+```
+AskUserQuestion(
+  header: "Abandon Quick",
+  question: "Abandon quick '${SLUG}'? All uncommitted and committed changes will be lost.",
+  options: [
+    { label: "Yes, abandon", description: "Remove worktree and branch — changes are lost" },
+    { label: "No, keep", description: "Cancel — quick remains active" }
+  ]
+)
+```
+
+If "No, keep": Display `Quick '${SLUG}' remains active.` End workflow.
+
+**Step 3: Execute abandonment**
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+ DGS ► ABANDONING QUICK
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+◆ Removing worktree and branch...
+```
+
+```bash
+RESULT=$(node "$HOME/.claude/deliver-great-systems/bin/dgs-tools.cjs" abandon-quick --confirmed 2>&1)
+EXIT_CODE=$?
+```
+
+**Step 4: Display result**
+
+**If exit code is 0 (success):**
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+ DGS ► QUICK ABANDONED ✓
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Quick '${SLUG}' abandoned. Worktree removed.
+No changes merged to main.
+```
+
+**If error:**
+Display the error message from RESULT.
+
+</process>
+
+<success_criteria>
+- [ ] Active product-level quick validated
+- [ ] Confirmation required before abandonment
+- [ ] Worktree and branch removed without merging
+- [ ] active_context cleared
+- [ ] No commits from quick branch appear on base_branch
+</success_criteria>

package/deliver-great-systems/workflows/add-idea.md

@@ -33,7 +33,7 @@ Use `TIER_FILES` JSON `files` array for project context (PROJECT.md, STATE.md, c
 
 <step name="ensure_directories">
 ```bash
-mkdir -p ${project_root}/ideas/pending ${project_root}/ideas/done ${project_root}/ideas/rejected
+mkdir -p ${project_root}/ideas
 ```
 </step>
 
@@ -72,7 +72,7 @@ Parse the JSON result to get `id`, `filename`, `path`.
 
 <step name="git_commit">
 ```bash
-node ~/.claude/deliver-great-systems/bin/dgs-tools.cjs commit "ideas: add #${id} - ${title}" --push --files ${project_root}/ideas/pending/${filename} ${project_root}/ideas/manifest.json
+node ~/.claude/deliver-great-systems/bin/dgs-tools.cjs commit "ideas: add #${id} - ${title}" --push --files ${project_root}/ideas/${filename} ${project_root}/ideas/manifest.json
 ```
 </step>
 
@@ -89,7 +89,7 @@ Nothing else -- no file path, no tags display, no next steps.
 </process>
 
 <success_criteria>
-- [ ] Idea file exists in `ideas/pending/` with correct frontmatter
+- [ ] Idea file exists in `ideas/` with correct frontmatter
 - [ ] Manifest updated with incremented next_id
 - [ ] Git commit created
 - [ ] Minimal confirmation displayed

package/deliver-great-systems/workflows/add-phase.md

@@ -76,6 +76,11 @@ Update STATE.md to reflect the new phase:
    ```
 
 If "Roadmap Evolution" section doesn't exist, create it.
+
+3. Commit both ROADMAP.md and STATE.md:
+   ```bash
+   node "$HOME/.claude/deliver-great-systems/bin/dgs-tools.cjs" commit "docs: add phase {N} to roadmap" --push --files ${roadmap_path} ${state_path}
+   ```
 </step>
 
 <step name="completion">

package/deliver-great-systems/workflows/add-tests.md

@@ -66,6 +66,20 @@ This command works on completed phases. Run /dgs:execute-phase first.
 ```
 Exit.
 
+**Worktree-aware code directory resolution (resolveCodeContext):**
+
+For each registered code repo, resolve the correct working directory. When a milestone or quick worktree is active, test generation must target the worktree directory, not the main checkout, so generated test files land in the correct location.
+
+```javascript
+// In the agent's execution context, use resolveCodeContext to determine the code directory:
+const { resolveCodeContext } = require('./bin/lib/context.cjs');
+const ctx = resolveCodeContext(planningRoot, repoName);
+// ctx.type: 'main' | 'milestone' | 'quick'
+// ctx.directory: absolute path to the correct working directory
+```
+
+Use `ctx.directory` for all file operations within code repos.
+
 Present banner:
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

package/deliver-great-systems/workflows/add-todo.md

@@ -95,6 +95,7 @@ Write to `${pending_dir}/${date}-${slug}.md`:
 
 ```markdown
 ---
+status: pending
 created: [timestamp]
 title: [title]
 area: [area]

package/deliver-great-systems/workflows/approve-spec.md

@@ -143,16 +143,36 @@ Perform the approval state transition and audit trail update.
    node ~/.claude/deliver-great-systems/bin/dgs-tools.cjs specs set-status --id "$SPEC_SLUG" --status final
    ```
 
-2. Run `add-log-entry` to record the approval in the Refinement Log:
+2. Mark source ideas as done (if any):
+   Read the spec file to extract `source_ideas` from frontmatter (array of idea filenames).
+   If `source_ideas` exists and is non-empty:
+   ```bash
+   # For each source idea in the array:
+   for IDEA_FILE in ${SOURCE_IDEAS[@]}; do
+     node ~/.claude/deliver-great-systems/bin/dgs-tools.cjs ideas set-status --id "$IDEA_FILE" --status done 2>/dev/null || true
+   done
+   ```
+   The `|| true` ensures silent skip if an idea is already done, consolidated, or not found (idempotent).
+   Track the idea file paths for inclusion in the commit.
+
+3. Run `add-log-entry` to record the approval in the Refinement Log:
    ```bash
    node ~/.claude/deliver-great-systems/bin/dgs-tools.cjs specs add-log-entry --id "$SPEC_SLUG" --date "$(date +%Y-%m-%d)" --version "$VERSION" --action Approved --summary "Spec approved after completeness validation"
    ```
 
-3. Determine the spec filename from the validate output or Read step.
+4. Determine the spec filename from the validate output or Read step.
 
-4. Commit the changes:
+5. Commit the changes (include modified idea files):
    ```bash
-   node ~/.claude/deliver-great-systems/bin/dgs-tools.cjs commit "specs: approve $SPEC_ID v$VERSION" --push --files "$SPEC_FILE_PATH"
+   # Build files list: spec + any modified idea files
+   COMMIT_FILES="$SPEC_FILE_PATH"
+   if [ -n "$SOURCE_IDEAS" ]; then
+     for IDEA_FILE in ${SOURCE_IDEAS[@]}; do
+       IDEA_PATH=$(node ~/.claude/deliver-great-systems/bin/dgs-tools.cjs ideas find --id "$IDEA_FILE" --raw 2>/dev/null | jq -r '.path // empty')
+       [ -n "$IDEA_PATH" ] && COMMIT_FILES="$COMMIT_FILES ${project_root}/${IDEA_PATH}"
+     done
+   fi
+   node ~/.claude/deliver-great-systems/bin/dgs-tools.cjs commit "specs: approve $SPEC_ID v$VERSION" --push --files $COMMIT_FILES
    ```
 </step>
 
@@ -180,5 +200,6 @@ Next steps:
 - [ ] Validation errors block approval with clear messages
 - [ ] Validation warnings allow user confirmation before proceeding
 - [ ] Blocking open questions are detected and treated as errors
+- [ ] Source ideas marked as done when spec has source_ideas in frontmatter
 - [ ] Changes committed to git
 </success_criteria>

package/deliver-great-systems/workflows/audit-milestone.md

@@ -45,6 +45,19 @@ node "$HOME/.claude/deliver-great-systems/bin/dgs-tools.cjs" phases list
 - Extract milestone definition of done from ROADMAP.md
 - Extract requirements mapped to this milestone from REQUIREMENTS.md
 
+### Parse `--strict-audit` flag (REL-10)
+
+```bash
+STRICT_AUDIT=$(echo "$ARGUMENTS" | grep -oE -- '--strict-audit' | head -1)
+if [ -n "$STRICT_AUDIT" ]; then
+  STRICT_AUDIT=true
+else
+  STRICT_AUDIT=false
+fi
+```
+
+When `STRICT_AUDIT=true`, the cross-reference matrix in Section 5d preserves the OLD strict behaviour: empty `requirements_completed` → `partial` regardless of VERIFICATION state. When `STRICT_AUDIT=false` (default), Section 5d applies the soft-tolerance via `bin/lib/audit-tolerance.cjs::applyMatrix` and logs the `summary-frontmatter-empty-but-verified` warning under a separate channel (`soft_warnings`) — distinct from real partials.
+
 ## 2. Read All Phase Verifications
 
 For each phase directory, read the VERIFICATION.md:
@@ -143,21 +156,30 @@ done
 
 ### 5d. Status Determination Matrix
 
-For each REQ-ID, determine status using all three sources:
+For each REQ-ID, determine status using all three sources, routed through `bin/lib/audit-tolerance.cjs::applyMatrix(input)` (REL-10):
+
+| VERIFICATION.md Status | SUMMARY Frontmatter | requirements_claimed in VERIFICATION | --strict-audit | → Final Status |
+|------------------------|---------------------|--------------------------------------|----------------|----------------|
+| passed                 | listed              | any                                  | any            | **satisfied** |
+| passed                 | empty               | lists ID                             | false (default) | **satisfied** + soft-warning `summary-frontmatter-empty-but-verified` |
+| passed                 | empty               | lists ID                             | true            | **partial** (preserves old strict behaviour; opt-in via `--strict-audit`) |
+| passed                 | empty               | does NOT list ID                     | any            | **partial** (real partial — tolerance must NOT mask this) |
+| gaps_found             | any                 | any                                  | any            | **unsatisfied** |
+| missing                | listed              | any                                  | any            | **partial** (verification gap) |
+| missing                | missing             | any                                  | any            | **unsatisfied** |
+
+**Soft-warning channel:** Entries with status `satisfied` AND `softWarning: 'summary-frontmatter-empty-but-verified'` are collected in a SEPARATE list under `soft_warnings.summary_frontmatter_empty_but_verified` in the audit JSON output. They are NOT included under `gaps.requirements` — that channel is reserved for real `unsatisfied` and real `partial`. The soft-warning channel is shown as an info-level note in the markdown report.
 
-| VERIFICATION.md Status | SUMMARY Frontmatter | REQUIREMENTS.md | → Final Status |
-|------------------------|---------------------|-----------------|----------------|
-| passed                 | listed              | `[x]`           | **satisfied**  |
-| passed                 | listed              | `[ ]`           | **satisfied** (update checkbox) |
-| passed                 | missing             | any             | **partial** (verify manually) |
-| gaps_found             | any                 | any             | **unsatisfied** |
-| missing                | listed              | any             | **partial** (verification gap) |
-| missing                | missing             | any             | **unsatisfied** |
+**Implementation:** Section 5d invokes `applyMatrix({ verificationStatus, requirementsClaimed, summaryRequirementsCompleted, reqId, strictAudit })` for each REQ-ID. The output `{ status, softWarning }` populates the per-requirement row.
+
+**Removal trigger (REL-10 band-aid):** When 3 consecutive milestones ship with zero `summary-frontmatter-empty-but-verified` warnings, this row should be removed from the matrix and the strict behaviour restored as default.
 
 ### 5e. FAIL Gate and Orphan Detection
 
 **REQUIRED:** Any `unsatisfied` requirement MUST force `gaps_found` status on the milestone audit.
 
+**Soft-warning entries (`softWarning: 'summary-frontmatter-empty-but-verified'`) MUST NOT force `gaps_found`** — they are `satisfied` with a recoverable provenance gap. They surface in `soft_warnings.summary_frontmatter_empty_but_verified` and in the markdown info-level notes only.
+
 **Orphan detection:** Requirements present in REQUIREMENTS.md traceability table but absent from ALL phase VERIFICATION.md files MUST be flagged as orphaned. Orphaned requirements are treated as `unsatisfied` — they were assigned but never verified by any phase.
 
 ## 5.5. Nyquist Compliance Discovery
@@ -207,6 +229,11 @@ gaps:  # Critical blockers
       completed_by_plans: ["{plan files whose SUMMARY marks it complete}"]
       verification_status: "passed | gaps_found | missing | orphaned"
       evidence: "{specific evidence or lack thereof}"
+soft_warnings:  # REL-10: recoverable provenance issues — NOT blockers
+  summary_frontmatter_empty_but_verified:
+    - id: "{REQ-ID}"
+      phase: "{phase}"
+      reason: "VERIFICATION.md status: passed and requirements_claimed lists ID; SUMMARY.md requirements_completed is empty"
   integration: [...]
   flows: [...]
 tech_debt:  # Non-critical, deferred
@@ -227,7 +254,35 @@ Plus full markdown report with tables for requirements, phases, integration, tec
 - `gaps_found` — critical blockers exist
 - `tech_debt` — no blockers but accumulated deferred items need review
 
-## 7. Present Results
+## 7. Generate REVIEW.md
+
+After audit scoring completes, generate the milestone review report so it is available before reviewers run complete-milestone.
+
+```bash
+# Generate REVIEW.md using the CLI command — always regenerates even if prior version exists
+REVIEW_RESULT=$(node "$HOME/.claude/deliver-great-systems/bin/dgs-tools.cjs" jobs generate-review "${milestone_version}" --raw 2>&1)
+REVIEW_EXIT=$?
+```
+
+**If generation succeeds** (`REVIEW_EXIT` is 0):
+
+Parse the JSON output to get the file path:
+```bash
+REVIEW_PATH=$(echo "$REVIEW_RESULT" | node -e "const d=require('fs').readFileSync('/dev/stdin','utf-8');try{const j=JSON.parse(d);console.log(j.relativePath||'')}catch{console.log('')}")
+```
+
+Display: `Review report: ${REVIEW_PATH}`
+
+**If generation fails** (`REVIEW_EXIT` is non-zero):
+
+Log warning and continue — do NOT block the audit:
+```
+Warning: Review generation failed: ${REVIEW_RESULT}
+```
+
+The audit report is complete regardless of review generation status. The review report is supplementary context for four-eyes reviewers.
+
+## 8. Present Results
 
 Route by status (see `<offer_next>`).
 
@@ -360,5 +415,6 @@ All requirements met. No critical blockers. Accumulated tech debt needs review.
 - [ ] FAIL gate enforced — any unsatisfied requirement forces gaps_found status
 - [ ] Nyquist compliance scanned for all milestone phases (if enabled)
 - [ ] Missing VALIDATION.md phases flagged with validate-phase suggestion
+- [ ] REVIEW.md generated as final step (or warning logged on failure)
 - [ ] Results presented with actionable next steps
 </success_criteria>

package/deliver-great-systems/workflows/audit-phase.md

@@ -51,15 +51,25 @@ REPOS_MD=$(node ~/.claude/deliver-great-systems/bin/dgs-tools.cjs repos list --r
 
 Parse JSON for the list of registered repos with paths.
 
-**Resolve test execution directory (v2 only):**
+**Resolve test execution directory with resolveCodeContext (v2 only):**
 
 If `dgs_mode` is `v2` and repos were detected from REPOS_MD:
 
 1. Parse REPOS_MD JSON for the list of repos (each has `name` and `path`)
-2. If exactly 1 repo registered: use its `path` as `TEST_CWD`
-3. If multiple repos: check PLAN.md files in the phase for `<repos>` tags. Use the first repo name found, look up its path from REPOS_MD. If no `<repos>` tag found, use the first registered repo's path.
-4. Resolve `TEST_CWD` to an absolute path: if the repo path is relative (starts with `../`), resolve it relative to `process.cwd()` / the current working directory.
-5. Set `CWD_FLAG` to `--cwd "${TEST_CWD}"` if TEST_CWD was determined, otherwise set to empty string.
+2. Determine the target repo name:
+   - If exactly 1 repo registered: use its name
+   - If multiple repos: check PLAN.md files in the phase for `<repos>` tags. Use the first repo name found. If no `<repos>` tag found, use the first registered repo's name.
+3. **Resolve code context (worktree-aware):** Use resolveCodeContext to determine the correct working directory. When a milestone or quick worktree is active, the audit must examine code in the worktree directory, not the main checkout.
+   ```javascript
+   const { resolveCodeContext } = require('./bin/lib/context.cjs');
+   const ctx = resolveCodeContext(planningRoot, repoName);
+   // ctx.type: 'main' | 'milestone' | 'quick'
+   // ctx.directory: absolute path to the correct working directory
+   ```
+   Use `ctx.directory` as `TEST_CWD`.
+4. If resolveCodeContext returns main type, fall back to resolving the repo path from REPOS_MD as before.
+5. Resolve `TEST_CWD` to an absolute path: if the repo path is relative (starts with `../`), resolve it relative to `process.cwd()` / the current working directory.
+6. Set `CWD_FLAG` to `--cwd "${TEST_CWD}"` if TEST_CWD was determined, otherwise set to empty string.
 
 If `dgs_mode` is NOT `v2` or no repos detected: set `CWD_FLAG` to empty string (single-repo, no override needed).
 

package/deliver-great-systems/workflows/cancel-job.md

@@ -46,7 +46,7 @@ Parse the JSON result. The response contains:
   "cancelled": true,
   "version": "v6.0",
   "steps_reset": 2,
-  "path": "jobs/pending/milestone-v6.0.md"
+  "path": "jobs/milestone-v6.0.md"
 }
 ```
 
@@ -65,7 +65,7 @@ Display the result based on the response:
 
 **If `cancelled: true`:**
 ```
-Job {version} cancelled. {steps_reset} in-progress step(s) reset. Job moved to pending/ -- re-run with /dgs:run-job {version}
+Job {version} cancelled. {steps_reset} in-progress step(s) reset. Job status set to pending -- re-run with /dgs:run-job {version}
 ```
 
 **If `reason: 'not_found'`:**

package/deliver-great-systems/workflows/check-todos.md

@@ -130,7 +130,7 @@ Use AskUserQuestion:
 <step name="execute_action">
 **Work on it now:**
 ```bash
-mv "${pending_dir}/[filename]" "${project_root}/todos/done/"
+node "$HOME/.claude/deliver-great-systems/bin/dgs-tools.cjs" todos set-status --id "[filename]" --status done
 ```
 Update STATE.md todo count. Present problem/solution context. Begin work or ask how to proceed.
 
@@ -158,8 +158,7 @@ Re-run `init todos` to get updated count, then update STATE.md "### Pending Todo
 If todo was moved to done/, commit the change:
 
 ```bash
-git rm --cached ${pending_dir}/[filename] 2>/dev/null || true
-node "$HOME/.claude/deliver-great-systems/bin/dgs-tools.cjs" commit "docs: start work on todo - [title]" --files ${project_root}/todos/done/[filename] ${state_path}
+node "$HOME/.claude/deliver-great-systems/bin/dgs-tools.cjs" commit "docs: start work on todo - [title]" --files ${project_root}/todos/[filename] ${state_path}
 ```
 
 Tool respects `commit_docs` config and gitignore automatically.