docs(design-thinking): add Design Thinking documentation and DT-to-RPI handoff (#789)

Added comprehensive Design Thinking documentation and unified the
DT-to-RPI handoff pipeline. This PR established a complete nine-method
framework reference under `docs/design-thinking/`, integrated DT into
the HVE Guide lifecycle, and routed all three exit points exclusively
through the Task Researcher agent. Across 35 files (17 new, 18
modified), the changes introduced 2463 lines and removed 200, closing a
major documentation gap for Design Thinking adoption in hve-core.

## Description

### Architectural Change: Unified Exit Point Routing

All three DT exit points now route exclusively through **Task
Researcher**, replacing the prior pattern where exits could target
different RPI agents. This unified the handoff contract and simplified
the integration surface.

- Updated *dt-coach.agent.md* to align agent configuration with unified
routing
- Revised *dt-rpi-handoff-contract.instructions.md* to route all three
exit points through Task Researcher
- Modified context instruction files (*dt-rpi-implement-context*,
*dt-rpi-planning-context*, *dt-rpi-research-context*) for consistency
with the new routing model
- Updated both handoff prompts
(*dt-handoff-implementation-space.prompt.md*,
*dt-handoff-solution-space.prompt.md*) to target Task Researcher
exclusively

### Design Thinking Documentation Suite

Established a complete framework reference with 17 new files covering
the three-space model (Problem, Solution, Validation) and all nine
methods.

- Added *docs/design-thinking/README.md* with framework overview,
nine-method summary table, and RPI integration entry points
- Created nine method guides (*method-01* through *method-09*) following
an identical structural template with activities, sample prompts,
expected outputs, quality checks, and RPI integration tables
- Added *dt-coach.md* and *dt-learning-tutor.md* tutorials with
invocation patterns, starter prompts, and manufacturing scenario
examples
- Created *dt-rpi-integration.md* covering exit point mapping,
confidence markers (`validated`, `assumed`, `unknown`, `conflicting`),
and per-agent input tables
- Added *tutorial-handoff-to-rpi.md* with step-by-step guidance for all
three exit points using practical manufacturing scenarios
- Created *using-together.md* with an end-to-end walkthrough
demonstrating how a dashboard request was reframed as a knowledge-loss
problem through DT, then transitioned to RPI
- Added *why-design-thinking.md* with a comparison table against
traditional requirements gathering and industry applicability

### HVE Guide Lifecycle Integration

Wove Design Thinking into the existing project lifecycle framework as an
optional entry point feeding into Stage 2 Discovery.

- Updated *docs/hve-guide/README.md* Mermaid lifecycle flowchart with a
DT optional-entry node and added UX Designer to the roles table
- Modified *docs/hve-guide/lifecycle/README.md* to insert "Design
Thinking to Stage 2" as transition rule 1, renumbering existing rules
- Expanded *discovery.md* Available Tools table to include `dt-coach`
and added a "Design Thinking as Pre-Research Methodology" callout
- Added a "Design Thinking for Product Concepts" section to
*product-definition.md*

### Role Guide Updates

- Added `dt-coach` to Key Agents tables in *business-program-manager.md*
and *tpm.md* with contextual paragraphs
- Created *ux-designer.md* role guide with recommended collections, five
lifecycle stages mapped to DT methods, starter prompts, and do/don't
tips

### Navigation and Discovery

- Added Design Thinking section with navigation links to
*docs/README.md*
- Added Design Thinking agent group entry to *docs/agents/README.md*
- Added "Design Thinking Path" section to
*docs/getting-started/README.md*
- Updated plugin README descriptions in
*plugins/design-thinking/README.md* and *plugins/hve-core-all/README.md*
to reflect Task Researcher routing

## Related Issue(s)

Closes #783

## Type of Change

Select all that apply:

**Code & Documentation:**

* [ ] Bug fix (non-breaking change fixing an issue)
* [ ] New feature (non-breaking change adding functionality)
* [ ] Breaking change (fix or feature causing existing functionality to
change)
* [x] Documentation update

**Infrastructure & Configuration:**

* [ ] GitHub Actions workflow
* [ ] Linting configuration (markdown, PowerShell, etc.)
* [ ] Security configuration
* [ ] DevContainer configuration
* [ ] Dependency update

**AI Artifacts:**

* [ ] Reviewed contribution with `prompt-builder` agent and addressed
all feedback
* [x] Copilot instructions (`.github/instructions/*.instructions.md`)
* [x] Copilot prompt (`.github/prompts/*.prompt.md`)
* [x] Copilot agent (`.github/agents/*.agent.md`)
* [ ] Copilot skill (`.github/skills/*/SKILL.md`)

> **Note for AI Artifact Contributors**:
>
> * **Agents**: Research, indexing/referencing other project (using
standard VS Code GitHub Copilot/MCP tools), planning, and general
implementation agents likely already exist. Review `.github/agents/`
before creating new ones.
> * **Skills**: Must include both bash and PowerShell scripts. See
[Skills](../docs/contributing/skills.md).
> * **Model Versions**: Only contributions targeting the **latest
Anthropic and OpenAI models** will be accepted. Older model versions
(e.g., GPT-3.5, Claude 3) will be rejected.
> * See [Agents Not
Accepted](../docs/contributing/custom-agents.md#agents-not-accepted) and
[Model Version
Requirements](../docs/contributing/ai-artifacts-common.md#model-version-requirements).

**Other:**

* [ ] Script/automation (`.ps1`, `.sh`, `.py`)
* [ ] Other (please describe):

## Sample Prompts (for AI Artifact Contributions)

**User Request:**

> "I have a manufacturing dashboard project. Help me run through Design
Thinking before building it."

Invoke the `dt-coach` agent from the agent picker, then provide your
project context. The coach guides you through the nine DT methods and
hands off to RPI through the Task Researcher when ready.

**Execution Flow:**

1. User selects `dt-coach` from the agent picker
2. Coach begins Method 1 (Scope Conversations) and guides through
Problem Space methods
3. Coach transitions through Solution Space methods (4-6) and Validation
Space methods (7-9)
4. At any exit point, coach produces a structured handoff artifact
5. User invokes a handoff prompt (*dt-handoff-solution-space.prompt.md*
or *dt-handoff-implementation-space.prompt.md*)
6. Task Researcher receives the handoff and begins RPI workflow with DT
context

**Output Artifacts:**

- DT coaching session state in `.copilot-tracking/dt/`
- Handoff artifact with confidence markers and method evidence
- RPI research document seeded with DT findings

**Success Indicators:**

- Coach navigates through DT methods with contextual prompts
- Handoff artifact contains validated findings with proper confidence
markers
- Task Researcher receives and processes the DT handoff without
requiring manual context transfer

## Testing

All changes were validated through the following checks:

- `npm run lint:md` — passed
- `npm run spell-check` — passed
- `npm run lint:frontmatter` — passed
- `npm run validate:skills` — passed
- `npm run lint:md-links` — passed
- `npm run lint:ps` — passed
- `npm run plugin:generate` — passed (table formatting applied to 2
files, committed separately)

Manual review confirmed consistent YAML frontmatter across all 17 new
files, identical structural templates across method guides 01-09,
accurate cross-references between documentation files, and correct exit
point routing through Task Researcher in all modified AI artifacts.

## Checklist

### Required Checks

* [x] Documentation is updated (if applicable)
* [x] Files follow existing naming conventions
* [ ] Changes are backwards compatible (if applicable)
* [ ] Tests added for new functionality (if applicable)

### AI Artifact Contributions
<!-- If contributing an agent, prompt, instruction, or skill, complete
these checks -->
* [ ] Used `/prompt-analyze` to review contribution
* [ ] Addressed all feedback from `prompt-builder` review
* [ ] Verified contribution follows common standards and type-specific
requirements

### Required Automated Checks

The following validation commands must pass before merging:

* [x] Markdown linting: `npm run lint:md`
* [x] Spell checking: `npm run spell-check`
* [x] Frontmatter validation: `npm run lint:frontmatter`
* [x] Skill structure validation: `npm run validate:skills`
* [x] Link validation: `npm run lint:md-links`
* [x] PowerShell analysis: `npm run lint:ps`
* [x] Plugin freshness: `npm run plugin:generate`

## Security Considerations
<!-- ⚠️ WARNING: Do not commit sensitive information such as API keys,
passwords, or personal data -->
* [x] This PR does not contain any sensitive or NDA information
* [x] Any new dependencies have been reviewed for security issues
* [x] Security-related scripts follow the principle of least privilege

## Additional Notes

- The unified exit point routing through Task Researcher is a **breaking
change** for any workflow that previously targeted Task Planner or Task
Implementor directly from DT exit points. Update any custom handoff
workflows accordingly.
- Plugin README files (*plugins/design-thinking/README.md*,
*plugins/hve-core-all/README.md*) were modified to reflect the routing
change. Run `npm run plugin:generate` to confirm freshness.
- Table reformatting in role guides (*business-program-manager.md*,
*tpm.md*) produced larger diffs due to column-width alignment changes;
only the `dt-coach` row and contextual paragraph were substantive
additions.

---------

Co-authored-by: Bill Berry <wbery@microsoft.com>

Author: WilliamBerryiii

.github/agents/design-thinking/dt-coach.agent.md

@@ -8,18 +8,10 @@ handoffs:
     agent: dt-coach
     prompt: /dt-method-next
     send: false
-  - label: "🔬 Research"
+  - label: "🔬 Hand off to RPI"
     agent: Task Researcher
     prompt: /task-research
     send: true
-  - label: "📋 Plan"
-    agent: Task Planner
-    prompt: /task-plan
-    send: true
-  - label: "🛠️ Implement"
-    agent: Task Implementor
-    prompt: /task-implement
-    send: true
 ---
 
 # Design Thinking Coach

.github/instructions/design-thinking/dt-rpi-handoff-contract.instructions.md

@@ -11,13 +11,15 @@ Defines the formal contract for lateral handoffs from Design Thinking coaching i
 
 Three exit points align with DT space boundaries. Each exit targets the RPI agent best suited to consume DT outputs at that stage.
 
-| Exit Point                 | DT Methods   | DT Space Boundary         | RPI Target  | What Transfers                                                                         |
-|----------------------------|--------------|---------------------------|-------------|----------------------------------------------------------------------------------------|
-| Problem Statement Complete | 1-3 complete | Problem → Solution        | Researcher  | Validated problem statement, synthesis themes, stakeholder map, constraint inventory   |
-| Concept Validated          | 4-6 complete | Solution → Implementation | Planner     | Tested concepts, lo-fi prototype feedback, constraint discoveries, narrowed directions |
-| Implementation Spec Ready  | 7-8 complete | Implementation exit       | Implementor | Hi-fi prototype specs, user testing results, architecture decisions, rollout criteria  |
+| Exit Point                 | DT Methods   | DT Space Boundary         | RPI Target | What Transfers                                                                         |
+|----------------------------|--------------|---------------------------|------------|----------------------------------------------------------------------------------------|
+| Problem Statement Complete | 1-3 complete | Problem → Solution        | Researcher | Validated problem statement, synthesis themes, stakeholder map, constraint inventory   |
+| Concept Validated          | 4-6 complete | Solution → Implementation | Researcher | Tested concepts, lo-fi prototype feedback, constraint discoveries, narrowed directions |
+| Implementation Spec Ready  | 7-9 complete | Implementation exit       | Researcher | Hi-fi prototype specs, user testing results, architecture decisions, rollout criteria  |
 
-Earlier exit points produce more RPI work. A Problem Statement Complete handoff requires full RPI research and planning. An Implementation Spec Ready handoff may skip directly to implementation.
+The exit tier describes the richness and completeness of artifacts provided to the Researcher, not which RPI phase to skip to. Later exits provide richer context that may reduce the Researcher's investigation scope, but the full RPI pipeline (Research → Plan → Implement) always executes.
+
+Every exit enters the RPI pipeline at Task Researcher. Earlier exit points provide leaner artifacts requiring broader research investigation. Later exit points provide richer, more validated artifacts that narrow the Researcher's scope but do not bypass any RPI phase.
 
 ## Exit-Point Artifact Schema
 
@@ -28,7 +30,7 @@ Record handoff artifacts in the coaching state `transition_log` using a lateral
 exit_point: "problem-statement-complete | concept-validated | implementation-spec-ready"
 dt_method: 3          # last completed DT method
 dt_space: "problem"   # space being exited
-handoff_target: "researcher | planner | implementor"
+handoff_target: "researcher"  # constant — all DT exits enter RPI at Researcher
 date: "YYYY-MM-DD"
 
 artifacts:
@@ -57,22 +59,22 @@ assumptions:
 
 Each RPI agent consumes different DT outputs. Provide artifacts matching the target agent's needs.
 
-| RPI Agent   | Required Inputs                                                           | Optional Inputs                                                             | Format                                                          |
-|-------------|---------------------------------------------------------------------------|-----------------------------------------------------------------------------|-----------------------------------------------------------------|
-| Researcher  | Problem statement, synthesis themes, constraint inventory                 | Stakeholder map, interview evidence, environmental context                  | Free-form topic referencing DT artifacts by path                |
-| Planner     | Validated concepts, constraint discoveries, user feedback from prototypes | Synthesis themes, stakeholder alignment status, frozen/fluid classification | Research file path (from RPI researcher) plus DT artifact paths |
-| Implementor | Hi-fi prototype specs, user testing results, architecture decisions       | Performance benchmarks, rollout criteria, trade-off documentation           | Plan file path (from RPI planner)                               |
+| RPI Agent   | DT Artifact Consumption                                                                                                                 | Format                                           |
+|-------------|-----------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------|
+| Researcher  | All DT exit artifacts: problem statements, tested concepts, hi-fi specs, stakeholder maps, constraint inventories, user testing results | Free-form topic referencing DT artifacts by path |
+| Planner     | Receives DT context indirectly through Researcher output                                                                                | Research file path (upstream from Researcher)    |
+| Implementor | Receives DT context indirectly through Researcher→Planner chain                                                                         | Plan file path (upstream from Planner)           |
 
-When handing off to the Researcher, frame the DT problem statement as the research topic and reference artifact paths so the researcher can read DT evidence directly rather than relying on summarized context.
+Frame the DT outputs as the research topic and reference artifact paths so the Researcher can read DT evidence directly rather than relying on summarized context. Planner and Implementor consume DT findings as they flow through the standard RPI pipeline.
 
 ## Graduation Awareness Behavior
 
 The DT coach monitors for handoff readiness at every space boundary using this four-step flow:
 
 1. **Detect**: At each method boundary, assess whether the team's work satisfies the space boundary readiness signals defined in the method sequencing protocol.
-2. **Surface**: When readiness signals are met, explicitly name the lateral handoff option alongside forward and backward options. State which exit point applies and which RPI agent would receive the work.
+2. **Surface**: When readiness signals are met, explicitly name the lateral handoff option alongside forward and backward options. State which exit point applies. All exits hand off to Task Researcher.
 3. **Prepare**: If the team chooses lateral handoff, create the handoff summary file. Tag each artifact and constraint with a confidence marker. Identify gaps where confidence is `unknown` or `conflicting`.
-4. **Transfer**: Record a lateral transition in the coaching state `transition_log` with rationale. Announce the handoff target and provide the handoff summary path for the RPI agent.
+4. **Transfer**: Record a lateral transition in the coaching state `transition_log` with rationale. Announce the handoff to Task Researcher and provide the handoff summary path.
 
 The coach remains available in an advisory capacity after handoff. If the RPI workflow surfaces questions that require DT methods, the team can resume coaching from the recorded state.
 
@@ -87,6 +89,6 @@ Every artifact, constraint, and assumption in the handoff summary carries a conf
 | `unknown`     | Gap identified but not yet investigated                  | Prioritize in RPI research scope                  |
 | `conflicting` | Multiple sources disagree                                | Resolve before planning; escalate if unresolvable |
 
-The RPI researcher treats `assumed`, `unknown`, and `conflicting` markers as investigation targets. The RPI planner distinguishes `validated` constraints from `assumed` ones when assessing implementation risk.
+The RPI researcher treats `assumed`, `unknown`, and `conflicting` markers as investigation targets. Downstream RPI agents (Planner, Implementor) encounter these markers through the pipeline chain rather than from direct DT handoff.
 
 * All DT coaching artifacts are scoped to `.copilot-tracking/dt/{project-slug}/`. Never write DT artifacts directly under `.copilot-tracking/dt/` without a project-slug directory.

.github/instructions/design-thinking/dt-rpi-implement-context.instructions.md

@@ -5,7 +5,7 @@ applyTo: '**/.copilot-tracking/dt/**'
 
 # DT Implementation Context
 
-When task-implementor operates on DT artifacts or executes a DT-originated plan, these adjustments augment standard implementation behavior. The plan originates from a Design Thinking process, so fidelity constraints, stakeholder validation, and iteration support shape implementation decisions.
+When task-implementor executes a plan that originated from a Design Thinking process, these adjustments augment standard implementation behavior. The Implementor does not receive direct DT handoffs; DT context arrives through the Researcher→Planner pipeline chain. The plan originates from a Design Thinking process, so fidelity constraints, stakeholder validation, and iteration support shape implementation decisions.
 
 ## Implementation Adjustments
 

.github/instructions/design-thinking/dt-rpi-planning-context.instructions.md

@@ -5,7 +5,7 @@ applyTo: '**/.copilot-tracking/dt/**'
 
 # DT Planning Context
 
-When task-planner operates on DT artifacts or receives a DT handoff, these adjustments augment standard planning behavior. The plan originates from a Design Thinking process, so fidelity constraints, stakeholder coverage, and iteration support shape planning decisions.
+When task-planner operates on artifacts that originated from a Design Thinking process, these adjustments augment standard planning behavior. The Planner does not receive direct DT handoffs; DT context arrives through the Researcher's output. The plan originates from a Design Thinking process, so fidelity constraints, stakeholder coverage, and iteration support shape planning decisions.
 
 ## Planning Adjustments
 

.github/instructions/design-thinking/dt-rpi-research-context.instructions.md

@@ -25,6 +25,22 @@ When task-researcher receives a handoff from the DT coach, these adjustments aug
 * Process qualitative data (interview themes, observation patterns) alongside quantitative data from the DT artifact paths.
 * When an industry context template was active during coaching, reference its vocabulary mapping and constraint inventory for domain-specific framing.
 
+## Tiered Artifact Handling
+
+All DT exits route to Task Researcher. The depth of completed DT methods determines what the researcher already knows and where investigation effort concentrates.
+
+### Problem Space Exit (Methods 1-3)
+
+Artifacts include scope conversations, design research, and input synthesis. Investigation is broad: validate the problem statement, verify stakeholder assumptions, and explore technical feasibility across the full solution landscape.
+
+### Solution Space Exit (Methods 4-6)
+
+Artifacts include brainstorming outputs, user concepts, and low-fidelity prototypes. Investigation narrows: the problem is well-defined and candidate solutions exist. Focus on concept feasibility, constraint validation, and gap analysis for the selected concepts.
+
+### Implementation Space Exit (Methods 7-9)
+
+Artifacts include high-fidelity prototypes, test results, and iteration-at-scale findings. Investigation is narrowest: validated implementations exist. Focus on production readiness, scaling constraints, and remaining unknowns that testing did not cover.
+
 ## Output Format Additions
 
 When producing research output in DT context, include these sections alongside the standard research document:

.github/prompts/design-thinking/dt-handoff-implementation-space.prompt.md

@@ -1,5 +1,5 @@
 ---
-description: 'Compiles DT Methods 7-9 outputs into RPI-ready handoff artifact with tiered routing'
+description: 'Compiles DT Methods 7-9 outputs into RPI-ready handoff artifact targeting task-researcher'
 agent: 'agent'
 tools: ['read_file', 'create_file', 'replace_string_in_file']
 argument-hint: "project-slug=..."
@@ -101,10 +101,7 @@ Tag each readiness signal with a quality marker:
 | `unknown`     | Identified gap not yet investigated                      |
 | `conflicting` | Multiple sources disagree                                |
 
-Routing decision:
-
-* Route to task-implementor when the prototype is near production-ready, the deployment plan is comprehensive, testing evidence is thorough, and architecture decisions are documented.
-* Route to task-planner when significant production architecture gaps remain, the scaling assessment reveals large unresolved needs, or the exit tier is tier 1 (guided).
+Readiness note: all Implementation Space exits hand off to Task Researcher regardless of tier or prototype maturity. The exit tier and readiness assessment provide context that shapes the Researcher's investigation scope. Higher tiers with more validated evidence typically narrow the research needed.
 
 If critical gaps exist (signals marked `unknown` or `conflicting`), present findings and ask whether to proceed with the handoff or return to address gaps first. If no user response is available, default to proceeding with the handoff and documenting gaps in the Investigation Targets section.
 
@@ -118,7 +115,7 @@ Include the YAML header. The `tier` field extends the base DT-RPI handoff contra
 exit_point: "implementation-spec-ready"
 dt_method: 9          # or 7/8 based on tier
 dt_space: "implementation"
-handoff_target: "implementor"  # or "planner" based on routing decision
+handoff_target: "researcher"
 date: "{today's date}"
 tier: "comprehensive"  # guided | structured | comprehensive
 ```
@@ -134,17 +131,17 @@ Record a lateral transition in the coaching state `transition_log`:
 ```yaml
 - type: lateral
   from_method: 9      # or 7/8 based on tier
-  to: "implementor"  # or "planner"
-  rationale: "Implementation Space complete: handoff to RPI pipeline"
+  to: "rpi-researcher"
+  rationale: "Implementation Space complete: handoff to RPI Researcher with validated implementation artifacts"
   date: "{today's date}"
   tier: "comprehensive"   # guided | structured | comprehensive
 ```
 
 ### Step 5: Generate RPI Entry
 
-Create a self-contained RPI handoff document at `.copilot-tracking/dt/{project-slug}/rpi-handoff-implementation-space.md` for the target RPI agent to consume directly.
+Create a self-contained RPI handoff document at `.copilot-tracking/research/{project-slug}-research-topic.md` for task-researcher to consume directly.
 
-Include YAML frontmatter with `description` set to a summary of the handoff context (for example, `description: 'RPI handoff from DT Implementation Space for {project name}'`).
+Include YAML frontmatter with `description` set to a summary of the handoff context (for example, `description: 'RPI research topic from DT Implementation Space for {project name}'`).
 
 Content sanitization: apply these rules before generating.
 
@@ -156,40 +153,32 @@ Content sanitization: apply these rules before generating.
 
 Structure the document with these sections:
 
-#### Implementation Summary
-
-Validated prototype description, architecture decisions, and key technical trade-offs from high-fidelity prototype validation.
-
-#### Testing Evidence (Tier 2+)
-
-User testing results, behavioral observations, severity-frequency findings, and iteration decisions from user testing.
-
-#### Deployment Readiness (Tier 3)
+#### Research Topic
 
-Scaling assessment, deployment plan, rollout strategy, business value metrics, and adoption indicators from iteration and scaling assessment.
+Frame the implementation artifacts as a research question. State the validated prototype, architecture decisions, and what the Researcher should investigate further (production readiness, scaling gaps, integration concerns).
 
-#### Problem Space Foundation (Lineage)
+#### Validated Implementation Evidence
 
-Validated problem statement, stakeholder map, and synthesis themes from Methods 1-3.
+Architecture decisions, technical trade-offs, and prototype validation results from high-fidelity prototype validation. Testing observations and severity-frequency findings from user testing. Scaling assessment and deployment readiness from iteration at scale (tier 3 only).
 
-#### Solution Space Refinement (Lineage)
+#### Problem and Solution Space Lineage
 
-Tested concepts, constraint discoveries, and narrowed directions from Methods 4-6.
+Validated problem statement, stakeholder map, synthesis themes from Problem Space. Tested concepts, constraint discoveries, narrowed directions from Solution Space. Include from prior handoff artifacts or compiled from coaching state.
 
-#### Constraints
+#### Known Constraints
 
-Validated and assumed constraints with sources.
+Validated and assumed constraints with sources, organized by type.
 
-#### Investigation Targets
+#### Investigation Priorities
 
-Items tagged `assumed`, `unknown`, or `conflicting` requiring further work.
+Items tagged `assumed`, `unknown`, or `conflicting` requiring Researcher investigation. Group by priority (blockers first, then high-impact, then lower-impact).
 
-#### Routing Rationale
+#### DT Artifact Paths
 
-Why task-implementor or task-planner was selected, with gap analysis summary.
+List all `.copilot-tracking/dt/{project-slug}/` artifact paths so the Researcher can read original DT evidence directly.
 
-Inline all content directly rather than referencing `.copilot-tracking/` paths.
-The document stands alone as complete context for the receiving RPI agent.
+Inline all content directly rather than referencing `.copilot-tracking/` paths (except in the DT Artifact Paths section).
+The document stands alone as complete context for the receiving task-researcher.
 
 ### Step 6: Completion Ceremony