@ktpartners/dgs-platform 3.0.4 → 3.3.0

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

@@ -8,7 +8,44 @@ This workflow is only valid for product-level quicks. If the user is working in
 
 <process>
 
-**Step 1: Validate and execute quick-complete**
+**Step 1: Generate inline review summary**
+
+Before rebase-and-merge, generate a review report while the quick branch still exists with original commits.
+
+```bash
+REVIEW_RESULT=$(node "$HOME/.claude/deliver-great-systems/bin/dgs-tools.cjs" quick generate-review --raw 2>&1)
+REVIEW_EXIT=$?
+```
+
+**If generation succeeds** (`REVIEW_EXIT` is 0):
+
+Parse JSON output for the summary:
+```bash
+REVIEW_PATH=$(echo "$REVIEW_RESULT" | jq -r '.relativePath // empty')
+REVIEW_COMMITS=$(echo "$REVIEW_RESULT" | jq -r '.stats.commits // 0')
+REVIEW_FILES=$(echo "$REVIEW_RESULT" | jq -r '.stats.filesChanged // 0')
+REVIEW_RISKS=$(echo "$REVIEW_RESULT" | jq -r '.stats.riskFlags // 0')
+```
+
+Display the stats banner:
+```
+Review: ${REVIEW_PATH} (${REVIEW_COMMITS} commits, ${REVIEW_FILES} files${REVIEW_RISKS > 0 ? ", ${REVIEW_RISKS} risk flags" : ""})
+```
+
+**If fast-forward detected** (output contains `"fastForward": true`):
+
+Display: `No code changes detected -- review not generated.`
+
+**If generation fails** (`REVIEW_EXIT` is non-zero):
+
+Log warning and continue -- do NOT block task completion:
+```
+Warning: Review generation failed. Continuing with completion.
+```
+
+Review generation failure is non-fatal. The quick task will still complete normally.
+
+**Step 2: Validate and execute quick-complete**
 
 Call the quick-complete CLI command which validates the active quick and executes the full flow:
 
@@ -43,7 +80,7 @@ After resolving conflicts manually, re-run:
 ```
 End workflow.
 
-**Step 2: Display success**
+**Step 3: Display success**
 
 Parse JSON result from RESULT.
 
@@ -59,6 +96,7 @@ Worktree cleaned up. Pushed to origin.
 </process>
 
 <success_criteria>
+- [ ] Review summary generated before rebase-and-merge (or warning logged on failure)
 - [ ] Active product-level quick validated
 - [ ] Rebase-before-merge flow executed via rebaseAndMerge()
 - [ ] Worktree and branch cleaned up

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

@@ -240,10 +240,132 @@ Switching to /dgs:quick...
 ```
 Then continue from Step 3 as normal quick mode (skip the rest of the fast path).
 
+**F1.5-pre. Pre-edit dirt check (REL-06; runs only when `$FAST_MODE` is true)**
+
+Before any F2 edits, run a dirty-tree check across the planning root and all registered sub-repos. Pre-existing dirt that the user didn't initiate inside this fast-task would otherwise be swept into the F5 commit under a misleading message (the original idea-#27 footgun). Fail loudly with `pre-existing-dirt` exit-code label in non-interactive mode; ask to confirm in interactive mode.
+
+```bash
+DIRT_JSON=$(node "$HOME/.claude/deliver-great-systems/bin/dgs-tools.cjs" fast-route 2>/dev/null)
+PRE_DIRTY=$(echo "$DIRT_JSON" | jq -r '
+  ((.survey.planningRoot.dirty // false) as $pr |
+   ([.survey.subRepos[]? | select(.dirty == true) | .path] | length) as $sr |
+   if ($pr or ($sr > 0)) then "true" else "false" end)
+')
+```
+
+If `$PRE_DIRTY == "true"`:
+
+- **Non-interactive mode (no TTY):** Print the dirty paths from `$DIRT_JSON` and exit non-zero with label `pre-existing-dirt`:
+  ```
+  ╔══════════════════════════════════════════════════════════════╗
+  ║  PRE-EXISTING DIRT DETECTED                                  ║
+  ╚══════════════════════════════════════════════════════════════╝
+
+  /dgs:fast cannot proceed — the following repos have uncommitted changes
+  that pre-date this invocation:
+    - <planning root>: <paths>
+    - <sub-repo>: <paths>
+
+  Commit, stash, or `git restore` the listed paths and re-run, or use
+  /dgs:quick if these changes are part of the same intent.
+
+  exit-code label: pre-existing-dirt
+  ```
+  End workflow. Do NOT proceed to F1.5.
+
+- **Interactive mode:** Surface the dirty paths and prompt:
+  ```
+  AskUserQuestion(
+    header: "Pre-existing dirt",
+    question: "The following repos are dirty before this fast invocation: <paths>. Proceed anyway, or stop?",
+    options: [
+      { label: "Proceed", description: "Continue with /dgs:fast — dirty paths will NOT be included in this commit (only $FAST_EDITED_FILES will be staged)" },
+      { label: "Stop", description: "Exit /dgs:fast — manually clean the working tree first" }
+    ]
+  )
+  ```
+  If "Stop": exit non-zero with label `pre-existing-dirt`. If "Proceed": continue to F1.5. Submodule warnings (per `decision.warnings`) are surfaced but do NOT block in either mode.
+
+After F1.5-pre passes (clean state, OR user confirmed "Proceed"), continue to F1.5 cross-repo rejection guard.
+
+**F1.5. Cross-repo rejection guard (product fast only)**
+
+This guard is a pre-edit fail-fast check that prevents ambiguous multi-repo
+fast invocations from reaching F2/F5. Since v23.2 / REL-05, F5 invokes
+`dgs-tools fast-route` to pick the correct `--repo-cwd` post-edit, and F2
+passes the tracked file list via the explicit `--files` argument so the
+commit is scoped to the paths actually edited rather than a tree sweep.
+That means a /dgs:fast edit confined to a single sibling repo (with
+planning-root clean) is now safe and supported — F5 will route to that
+repo via `--repo-cwd`. What's NOT safe is an edit that spans multiple
+buckets: planning-root + a sibling, or two distinct siblings. Those would
+fail at F5 with `multi-repo-dirt` anyway; F1.5 catches them earlier with
+a clearer, edit-source-aware message before any disk writes happen.
+
+**Activation condition:** this guard runs **only** when `$QUICK_CONTEXT == 'product'` AND `$FAST_MODE` is true. Skip it entirely (early return, no side effects) in any other combination:
+- Milestone-context fast routes commits through `$QUICK_REPO_CWD` via `--repo-cwd`, which is already correct — guard not needed.
+- Non-fast paths use worktrees and planner/executor discipline — guard not needed.
+
+When the activation condition holds (`$QUICK_CONTEXT == 'product'` and `$FAST_MODE` is true), run the guard **before** any Read/Edit/Write in F2:
+
+1. **Enumerate sibling repo roots** from both sources (deduplicate by absolute path):
+
+   a. `config.local.json` → `projects.${current_project}.worktrees.*.repos` is a map of `repoName -> absolute worktree path`. Every value in every worktree's `repos` map is a sibling repo root.
+
+   b. `REPOS.md` → the markdown table has a `Path` column (typically relative like `../repo-name`). For each entry, resolve the path relative to planning-root cwd to get the absolute sibling repo root.
+
+2. **Determine the absolute path(s) you are about to edit.** Analyze `$DESCRIPTION` plus any codebase exploration needed to locate the target. For each intended edit, build the absolute path.
+
+3. **Check each intended edit against the sibling roots.** Normalize paths (resolve symlinks, strip trailing slashes) and test whether the edit path starts with any sibling repo root. Edits whose absolute path lies under the planning-root cwd itself are always allowed — only flag paths that live under a *registered sibling* repo root.
+
+4. **Partition intended edits into buckets.** For the set of intended-edit absolute paths from step 2:
+   - **planning-root bucket:** paths under the planning-root cwd that do NOT lie under any registered sibling root.
+   - **sibling-repo bucket(s):** paths whose absolute path starts with a sibling repo root (one bucket per matched sibling root, keyed by absolute root path).
+
+   Count the non-empty buckets:
+
+   - **0 non-empty buckets** (no edits inferred yet): proceed to F2; the guard re-checks via F5's post-edit `fast-route` if anything unexpected lands.
+   - **1 non-empty bucket** = planning-root only: ALLOWED. Continue to F2.
+   - **1 non-empty bucket** = exactly one sibling repo: ALLOWED. Continue to F2. F5's `fast-route` will route the commit through that sibling via `--repo-cwd`. Note in your edit plan which sibling you're targeting so RELATIVE_FILES computation in F5 uses the right STAGE_DIR.
+   - **2 or more non-empty buckets** (planning-root + sibling, OR sibling + sibling): BLOCKED. Fail fast with the error block below; do NOT proceed to F2.
+
+```
+╔══════════════════════════════════════════════════════════════╗
+║  AMBIGUOUS MULTI-REPO FAST                                   ║
+╚══════════════════════════════════════════════════════════════╝
+
+/dgs:quick --fast in product context supports edits confined to a single
+bucket (planning-root only, OR exactly one sibling repo). The intended
+edits span multiple buckets, which fast-mode cannot auto-route:
+
+  planning-root edits:
+${planning_root_paths_or_"(none)"}
+
+  sibling-repo edits:
+${for each non-empty sibling bucket: "  - ${matched_sibling_root}: ${paths}"}
+
+Options:
+  1. Split into separate /dgs:fast invocations, one per bucket. Run them
+     sequentially; each invocation auto-routes to the correct cwd.
+  2. If this multi-repo work is part of an active milestone, re-invoke
+     under milestone-context (the milestone worktree routes via
+     --repo-cwd against the registered repo).
+  3. Use /dgs:quick (full planner+executor) for genuinely cross-repo work
+     that must commit atomically across repos.
+
+End workflow. Do not proceed to F2.
+```
+
+5. If exactly one bucket is non-empty (or none yet), continue to F2.
+
 **F2. Make edits**
 
+By the time F2 runs, the F1.5 cross-repo guard has already passed (in product-fast) or been skipped (in milestone-context fast / non-fast) — every path you touch below is guaranteed to land in the correct repo.
+
 Read the relevant file(s) based on `$DESCRIPTION`, make the requested changes directly using Read/Edit/Write tools. No planner, no executor — the orchestrator acts as the implementer.
 
+Track every file you edit in a shell array `$FAST_EDITED_FILES` (absolute paths as used with Read/Edit/Write). Initialize to empty before the first edit. Append each path exactly once (deduplicate before F5). This array is the authoritative file list for F5's commit — it replaces the default fallback behaviour of `cmdCommit` (which would otherwise stage `['.']` in `gitCwd` and sweep unrelated dirty state).
+
 If `$QUICK_CONTEXT` is `'milestone-context'`, relevant files live under `$QUICK_REPO_CWD` (the milestone worktree). Prefix Read/Edit/Write absolute paths with that directory — the main-checkout paths will be on `base_branch` and miss in-progress milestone work.
 
 If `$DRY_RUN`:
@@ -311,21 +433,68 @@ Analyze the description and the actual changes (`git diff`) to infer a conventio
 
 Commit message is NOT shown to user before committing — just commit silently.
 
-**F5. Commit**
+**F5. Commit (REL-05 routing-aware)**
 
 When `$QUICK_REPO_CWD` is set (milestone-context), route git operations through the worktree via `--repo-cwd`. Config (commit_docs, sync_push, current_project, worktree map) is still loaded from the planning-root cwd.
 
+For product-context fast (`$QUICK_CONTEXT == 'product'`, `$QUICK_REPO_CWD` empty), invoke the routing-decision helper to determine the correct `--repo-cwd`:
+
 ```bash
+DIRT_JSON=$(node "$HOME/.claude/deliver-great-systems/bin/dgs-tools.cjs" fast-route 2>/dev/null)
+ROUTE_ACTION=$(echo "$DIRT_JSON" | jq -r '.decision.action')
+ROUTE_REPO=$(echo "$DIRT_JSON" | jq -r '.decision.repoCwd // empty')
+ROUTE_EXIT=$(echo "$DIRT_JSON" | jq -r '.decision.exitCode // empty')
+ROUTE_MSG=$(echo "$DIRT_JSON" | jq -r '.decision.message // empty')
+```
+
+Cases:
+
+- `$ROUTE_ACTION == 'fail'` AND `$ROUTE_EXIT == 'multi-repo-dirt'`:
+  ```
+  ╔══════════════════════════════════════════════════════════════╗
+  ║  MULTI-REPO DIRT DETECTED                                    ║
+  ╚══════════════════════════════════════════════════════════════╝
+
+  $ROUTE_MSG
+
+  exit-code label: multi-repo-dirt
+  ```
+  End workflow with non-zero exit; do NOT commit.
+
+- `$ROUTE_ACTION == 'route-to-sub-repo'`: commit with `--repo-cwd $ROUTE_REPO`.
+- `$ROUTE_ACTION == 'route-to-planning-root'`: commit in planning-root cwd (existing behaviour).
+
+Pass the tracked file list via `--files` so `cmdCommit` does not fall back to its `['.']` default (which would stage the entire `gitCwd` tree and sweep in unrelated dirty state — see the 260422-q7f incident). Surface any submodule warnings from `decision.warnings` to the user (display, do NOT block).
+
+```bash
+# Convert $FAST_EDITED_FILES (absolute paths) to paths relative to the
+# routed staging directory. Paths outside the staging directory should not appear
+# — the F1.5 cross-repo guard rejects them before F2.
+if [ -n "$QUICK_REPO_CWD" ]; then
+  STAGE_DIR="$QUICK_REPO_CWD"
+elif [ "$ROUTE_ACTION" = "route-to-sub-repo" ]; then
+  STAGE_DIR="$ROUTE_REPO"
+else
+  STAGE_DIR="$(pwd)"
+fi
+RELATIVE_FILES=()
+for f in "${FAST_EDITED_FILES[@]}"; do
+  # Strip STAGE_DIR prefix + leading slash to get the repo-relative path
+  RELATIVE_FILES+=( "${f#${STAGE_DIR}/}" )
+done
+
 if [ -n "$QUICK_REPO_CWD" ]; then
-  node "$HOME/.claude/deliver-great-systems/bin/dgs-tools.cjs" commit "${commit_message}" --push --repo-cwd "$QUICK_REPO_CWD"
+  node "$HOME/.claude/deliver-great-systems/bin/dgs-tools.cjs" commit "${commit_message}" --push --repo-cwd "$QUICK_REPO_CWD" --files "${RELATIVE_FILES[@]}"
+elif [ "$ROUTE_ACTION" = "route-to-sub-repo" ]; then
+  node "$HOME/.claude/deliver-great-systems/bin/dgs-tools.cjs" commit "${commit_message}" --push --repo-cwd "$ROUTE_REPO" --files "${RELATIVE_FILES[@]}"
 else
-  node "$HOME/.claude/deliver-great-systems/bin/dgs-tools.cjs" commit "${commit_message}" --push
+  node "$HOME/.claude/deliver-great-systems/bin/dgs-tools.cjs" commit "${commit_message}" --push --files "${RELATIVE_FILES[@]}"
 fi
 ```
 
-Get the short hash (from the same directory the commit landed in):
+Get the short hash (from the routed staging directory):
 ```bash
-git -C "${QUICK_REPO_CWD:-.}" rev-parse --short HEAD
+git -C "${STAGE_DIR}" rev-parse --short HEAD
 ```
 
 Store as `$COMMIT_HASH`.
@@ -377,14 +546,14 @@ Commit STATE.md and HISTORY.md together so archival data is persisted. Uses `dgs
 ```bash
 if [ -n "$QUICK_REPO_CWD" ]; then
   node "$HOME/.claude/deliver-great-systems/bin/dgs-tools.cjs" quick finalize ${quick_id} \
-    --quick-dir "${project_root}/quick" \
+    --quick-dir "${quick_dir}" \
     --state-path "${state_path}" \
     --fast \
     --push \
     --repo-cwd "$QUICK_REPO_CWD" 2>/dev/null || true
 else
   node "$HOME/.claude/deliver-great-systems/bin/dgs-tools.cjs" quick finalize ${quick_id} \
-    --quick-dir "${project_root}/quick" \
+    --quick-dir "${quick_dir}" \
     --state-path "${state_path}" \
     --fast \
     --push 2>/dev/null || true
@@ -422,10 +591,10 @@ mkdir -p "${task_dir}"
 
 **Step 4: Create quick task directory**
 
-Create the directory for this quick task:
+Use `task_dir` from init output — do NOT build the path manually:
 
 ```bash
-QUICK_DIR="${project_root}/quick/${quick_id}-${slug}"
+QUICK_DIR="${task_dir}"
 mkdir -p "$QUICK_DIR"
 ```
 
@@ -899,7 +1068,7 @@ Commit all quick task artifacts atomically via `dgs-tools quick finalize`. This
 
 ```bash
 node "$HOME/.claude/deliver-great-systems/bin/dgs-tools.cjs" quick finalize ${quick_id} \
-  --quick-dir "${project_root}/quick" \
+  --quick-dir "${quick_dir}" \
   --state-path "${state_path}" \
   --description "${DESCRIPTION}" \
   --push
@@ -970,4 +1139,8 @@ Ready for next task: /dgs:quick
 - [ ] (--fast) Scope warning shown when >3 files or >30 lines affected
 - [ ] (--fast) (--dry-run) Changes shown as diff, user asked to apply or discard
 - [ ] (--fast) Minimal output: "Done: {message} [{hash}]"
+- [ ] (--fast) F5 commit passes `--files` with the exact list of paths edited during F2 (no fallback to `cmdCommit`'s `['.']` default)
+- [ ] (--fast) Product-context fast rejects edits targeting sibling repos registered in `config.local.json` worktrees or `REPOS.md`, with an actionable error before F2 begins
+- [ ] (--fast) F1.5-pre pre-edit dirt check runs BEFORE F1.5; pre-existing dirt fails with `pre-existing-dirt` exit-code label in non-interactive mode (REL-06)
+- [ ] (--fast) F5 commit routes via fast-route decision: single-sub-repo dirty → `--repo-cwd <sub>`; multi-dirty → fails with `multi-repo-dirt` exit-code label; submodule warnings surface but don't block (REL-05)
 </success_criteria>

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

@@ -1,9 +1,9 @@
 <purpose>
-Subagent-driven research workflow that investigates an idea's feasibility and technical landscape across five adaptive dimensions. Claude acts as an analyst -- purposeful and efficient, adapting depth to what the idea actually needs rather than running a checklist.
+Subagent-driven research workflow that investigates an idea's feasibility and technical landscape. The orchestrator parses arguments, loads idea context (body, discussion log, prior research, supporting docs, REPOS.md), spawns a dedicated `dgs-idea-researcher` subagent for the five adaptive research dimensions, then handles the Research Log entry, git commit, and next-step suggestion. The orchestrator keeps its own context clean — dimension prose and retrieved web/codebase content stay inside the subagent.
 
-Produces a structured research document at `${project_root}/docs/ideas/{slug}-research.md` and appends a Research Log entry to the idea file. Commits both files together and suggests the next step based on findings.
+Produces a structured research document at `${project_root}/docs/ideas/pending/{slug}-research.md` and appends a Research Log entry to the idea file. Commits both files together and suggests the next step based on findings.
 
-When re-researching a previously-researched idea, the document is overwritten with a "Changes from Prior Research" section highlighting what shifted. Each re-research appends a fresh Research Log entry.
+When re-researching a previously-researched idea, the subagent overwrites the document and emits a "Changes from Prior Research" section only when meaningful differences exist. Each re-research appends a fresh Research Log entry.
 </purpose>
 
 <context_tier>planning</context_tier>
@@ -84,9 +84,9 @@ Also check for prior research document:
 ```bash
 # Derive slug from filename (strip id prefix and .md suffix)
 SLUG=$(echo "${filename}" | sed 's/^[0-9]*-//' | sed 's/\.md$//')
-RESEARCH_DOC="${project_root}/docs/ideas/${SLUG}-research.md"
+RESEARCH_DOC="${project_root}/docs/ideas/pending/${SLUG}-research.md"
 ```
-If the research document file exists, read it for prior research context.
+If the research document file exists, note its path so the subagent can read it for re-research diffing.
 
 **Load idea supporting documents:**
 
@@ -126,161 +126,99 @@ cat ${project_root}/REPOS.md 2>/dev/null
 If REPOS.md exists and has entries, this is a multi-repo project -- research should be partitioned by repo where relevant.
 </step>
 
-<step name="research_context">
-Assess the idea and decide research strategy:
+<step name="spawn_researcher">
+Resolve the model for the idea-researcher subagent. The `resolve-model` CLI subcommand on `dgs-tools.cjs` emits JSON (`{"model": "...", "profile": "..."}`) — pipe through `jq -r .model` to extract the bare model string:
 
-1. **Announce focus**: Print one line explaining which dimensions matter most for this idea and why. E.g.: "Focusing on landscape survey and codebase analysis -- this idea involves integrating with existing patterns."
-
-2. **Read Discussion Log** if present -- use discussion insights (refined problem, approach, open questions) to guide research focus areas.
-
-3. **Read prior research** if present -- note what was found before. On re-research, Claude will overwrite the document but should note what changed.
-
-4. **Read supporting documents** if `ideaDocs` is not empty -- review loaded text files, diagrams, and other supporting materials. These may reveal additional context about the idea's scope, architecture requirements, or prior art that inform the research focus areas.
-
-5. **Determine repo scope**: If REPOS.md exists, identify which repos are relevant to this idea. If no REPOS.md, treat as single-repo research.
-</step>
-
-<step name="web_search">
-**Dimension 1: Web Search**
-
-Announce: "Searching web for prior art and technical landscape..."
-
-Use WebSearch and WebFetch to investigate:
-- How others have solved similar problems
-- Existing libraries, tools, or frameworks relevant to the idea
-- Common patterns and anti-patterns
-- Recent discussions or blog posts
-
-Adapt depth to what the idea needs -- a well-understood problem gets a quick scan, a novel idea gets broader exploration. If web search yields little, note the gap and move on.
-
-Web search is best-effort -- search what's findable, note gaps, move on. Don't burn time on thin topics.
-</step>
-
-<step name="codebase_analysis">
-**Dimension 2: Codebase Analysis**
-
-Announce: "Analyzing codebase for related implementations..."
-
-Use Grep and Glob to examine:
-- Existing code that relates to the idea's domain
-- Patterns already established that would apply
-- Potential conflicts or integration points
-- Code that would need to change
-
-For multi-repo projects: analyze each relevant repo separately, noting repo-specific patterns and concerns.
-</step>
-
-<step name="landscape_survey">
-**Dimension 3: Landscape Survey**
-
-Announce: "Surveying technical landscape..."
-
-Build comparison information for relevant tools/libraries/approaches:
-- For obvious choices (one clear winner): brief verdict with reasoning
-- For genuine tradeoffs: table with pros, cons, license, maintenance status, compatibility
-- Per repo stack for multi-repo projects
-
-Recommend when clear -- strong recommendation when one option is clearly better, present options neutrally when it's genuinely a toss-up.
-</step>
-
-<step name="approaches">
-**Dimension 4: Approaches & Patterns**
-
-Announce: "Identifying approaches and patterns..."
-
-Identify how similar problems have been solved:
-- Architectural patterns that apply
-- Implementation strategies
-- Sequencing (what to build first)
-- What to avoid and why
-</step>
-
-<step name="feasibility">
-**Dimension 5: Feasibility Assessment**
-
-Announce: "Assessing feasibility..."
-
-Assess:
-- **Stack fit**: How well does this fit the existing technology stack?
-- **Effort estimate**: T-shirt size (S/M/L/XL) + approximate phase count
-- **Key risks**: What could go wrong? What are the unknowns?
-- **New dependencies**: Any new libraries, services, or external integrations needed?
-- **Recommendation**: Overall go/no-go/conditional assessment
-</step>
-
-<step name="write_document">
-Create (or overwrite) the research document.
-
-Ensure directory exists:
 ```bash
-mkdir -p ${project_root}/docs/ideas
+IDEA_RESEARCHER_MODEL=$(node ~/.claude/deliver-great-systems/bin/dgs-tools.cjs resolve-model dgs-idea-researcher | jq -r .model)
 ```
 
-Write the research document to `${project_root}/docs/ideas/${SLUG}-research.md` using the Write tool.
-
-**Document structure:**
-```markdown
----
-type: research
-idea_id: {id}
-idea_title: "{title}"
-date: "{YYYY-MM-DD}"
-repos_analysed: ["{repo1}", "{repo2}"]
----
-
-# Research: {title}
-
-{If re-research and meaningful changes exist:}
-## Changes from Prior Research
-
-{Bullet list of what's new, updated, or contradicted vs prior findings. Include when there are meaningful differences from prior research, skip when findings are similar.}
+The MODEL_PROFILES entry resolves to `inherit` (quality profile), `sonnet` (balanced), or `haiku` (budget) based on the project's `model_profile` config. (Note: wiring `idea_researcher_model` directly into init.cjs — so the orchestrator could read it from init JSON, mirroring `researcher_model` in plan-phase — is a follow-up. The CLI invocation above is the canonical resolution path here.)
 
-## Web Search Findings
+Build the research prompt with all loaded context. Inline the idea content; pass paths for files the subagent should Read itself:
 
-{Findings from Dimension 1}
-
-## Codebase Analysis
-
-{Findings from Dimension 2. For multi-repo: subsections per repo.}
-
-## Landscape Survey
-
-{Findings from Dimension 3. Comparison tables where applicable.}
-
-## Approaches & Patterns
-
-{Findings from Dimension 4}
-
-## Feasibility Assessment
+```markdown
+<objective>
+Research idea #${id}: ${title}
+Answer: "Is this idea feasible? What's the technical landscape and recommended approach?"
+</objective>
+
+<files_to_read>
+{If prior research exists:} ${RESEARCH_DOC}
+{If discussion log file exists separately, pass its path; otherwise the discussion log is inlined in <idea_content> below.}
+{For each ideaDoc loaded: pass its path}
+{If REPOS.md exists:} ${project_root}/REPOS.md
+</files_to_read>
+
+<idea_content>
+**Title:** ${title}
+**Tags:** ${tags}
+**Body:**
+${body}
+
+{If notes:} **Notes:** ${notes}
+
+{If discussionLog:} **Discussion Log:**
+${discussionLog}
+</idea_content>
+
+<prior_research>
+{If prior research doc exists:}
+Prior research at `${RESEARCH_DOC}` — read it before researching, then include a `## Changes from Prior Research` section in the new doc ONLY when meaningful differences exist. Omit the section when findings are substantially the same.
+{Otherwise:}
+No prior research.
+</prior_research>
+
+<supporting_docs>
+{If ideaDocs non-empty:}
+The following per-idea supporting documents were loaded by the orchestrator; their paths are listed in <files_to_read>. Brief summaries: {list path + 1-line summary per doc}.
+{Otherwise:}
+None
+</supporting_docs>
+
+<repos>
+{If REPOS.md exists:}
+Multi-repo project. Repos: {list repo names from REPOS.md}. Partition Codebase Analysis (Dimension 2) by repo, and provide per-repo stack recommendations in the Landscape Survey (Dimension 3) where relevant.
+{Otherwise:}
+Single-repo project — no partitioning needed.
+</repos>
+
+<output>
+Write the research document to: ${project_root}/docs/ideas/pending/${SLUG}-research.md
+
+`mkdir -p ${project_root}/docs/ideas/pending` first if the directory doesn't exist.
+
+Return a `## RESEARCH COMPLETE` block with: key findings (3-5 bullets), recommendation, document path, outcome (one of: "Ready for spec" / "Needs more discussion" / "Not feasible" / "Other: {short label}").
+</output>
+```
 
-**Stack Fit:** {assessment}
-**Effort:** {T-shirt size} -- {phase count estimate}
-**Key Risks:**
-{bullet list}
-**New Dependencies:**
-{bullet list or "None"}
-**Recommendation:** {go / no-go / conditional with conditions}
+Spawn the subagent:
 
----
-*Researched: {YYYY-MM-DD}*
+```
+Task(
+  prompt=research_prompt,
+  subagent_type="dgs-idea-researcher",
+  model="${IDEA_RESEARCHER_MODEL}",
+  description="Research idea #${id}"
+)
 ```
 
-For multi-repo projects, the Codebase Analysis and Landscape Survey sections should have `### {repo-name}` subsections.
-
-If repos_analysed is empty (no REPOS.md), omit the field from frontmatter or use an empty array.
+Handle the return:
+- **`## RESEARCH COMPLETE`**: extract `keyFindings`, `recommendation`, `outcome`, and the document path from the structured return. These flow into `save_research_log` as the entry JSON fields.
+- **`## RESEARCH BLOCKED`**: display the blocker to the user, offer the options the subagent surfaced (provide context / abort). Do NOT proceed to `save_research_log` or `git_commit` until the blocker is resolved.
 </step>
 
 <step name="save_research_log">
 Save the Research Log entry to the idea file via the CLI command.
 
-Build the entry JSON:
+Build the entry JSON from the subagent's structured return:
 ```json
 {
   "date": "YYYY-MM-DD",
   "summary": "{Actionable summary paragraph -- findings, recommendation, key risks. Enough to act on without opening the full document.}",
   "keyFindings": "- {finding 1}\n- {finding 2}\n- {finding 3}",
   "recommendation": "{Strong recommendation or neutral options presentation}",
-  "documentLink": "${project_root}/docs/ideas/${SLUG}-research.md",
+  "documentLink": "${project_root}/docs/ideas/pending/${SLUG}-research.md",
   "outcome": "{Recommended next step: 'Ready for spec', 'Needs more discussion', 'Not feasible', etc.}"
 }
 ```
@@ -296,7 +234,7 @@ Parse the JSON result to confirm success.
 <step name="git_commit">
 Commit both the research document and the updated idea file:
 ```bash
-node ~/.claude/deliver-great-systems/bin/dgs-tools.cjs commit "docs: research idea #${id} -- ${title}" --files ${project_root}/docs/ideas/${SLUG}-research.md ${project_root}/ideas/${filename}
+node ~/.claude/deliver-great-systems/bin/dgs-tools.cjs commit "docs: research idea #${id} -- ${title}" --files ${project_root}/docs/ideas/pending/${SLUG}-research.md ${project_root}/ideas/${filename}
 ```
 </step>
 
@@ -317,8 +255,8 @@ Suggest next step based on outcome:
 
 <success_criteria>
 - [ ] Idea loaded with full context (body, tags, notes, discussion log, research log)
-- [ ] Research dimensions executed with progress announcements
-- [ ] Research document created at `${project_root}/docs/ideas/{slug}-research.md` with frontmatter
+- [ ] `dgs-idea-researcher` subagent spawned with resolved model and a complete research prompt
+- [ ] Research document created at `${project_root}/docs/ideas/pending/{slug}-research.md` with frontmatter
 - [ ] Research Log entry saved to idea file via research-save CLI
 - [ ] Both files committed together
 - [ ] Key finding + recommendation + next step displayed