feat(skills):Add continuous customer-discovery and running-artifact skills to DT Coach

Nobody has claimed this yet.

### Skill Name

dt-running-artifacts

### Programming Language

Python

### Purpose

A Frontier Company team is preparing for a customer Design Thinking workshop. Before the team can co-create solutions or build a prototype, it needs to understand the customer: the people involved, their current operating landscape, the problems they experience, the vision they are pursuing, and the outcomes that matter to them.

That understanding develops one interaction at a time. A sponsor may clarify the strategic vision in one meeting. An operational user may expose a workflow constraint in the next. An architect may reveal a system boundary, while a program lead may challenge an assumption the team has carried since the first conversation. Each interaction changes what the team knows and what it still needs to learn.

Today, the team combines HVE Core capabilities to do this work. The DT Coach guides discovery and Design Thinking methods. The RPI Agent helps turn sufficiently mature opportunities into prototypes. Other agents support research, planning, and artifact development. These capabilities are useful individually, but the team still has to determine manually how each new transcript, note, or customer document should update the project understanding.

There is no consistent, resumable workflow for creating the discovery structure, ingesting new context, reconciling it with prior evidence, refining the running understanding of the opportunity, and surfacing current drafts of the five canonical Design Thinking artifact types: vision statements, problem statements, scenarios, use cases, and personas. The result can vary by practitioner and session. Knowledge may be duplicated, valid context may be accidentally displaced, assumptions can appear as facts, and discovery guides or artifact drafts can become stale or drift away from their supporting evidence before the workshop.

This feature would augment the existing HVE Core Design Thinking capabilities with a repeatable continuous-discovery workflow. DT Coach would remain the conversational orchestrator, while bounded skills would scaffold the project, process explicitly supplied customer context, update only the affected understanding and artifact drafts, independently audit their grounding, and prepare an optional human-mediated handoff to Word Copilot.

The purpose is to give the team an evidence-grounded learning loop from its earliest customer conversations through workshop preparation and eventual prototyping. After every customer interaction, the team should be able to see what it now knows, what remains assumed, what changed, and what still needs validation, alongside continuously refined working drafts of the five Design Thinking artifact types. Markdown remains the source of truth throughout that loop.

### Prerequisites

* Visual Studio Code with GitHub Copilot Chat and agent mode
* HVE Core with the DT Coach and RPI Agent available
* A Git repository for the discovery workspace
* Python 3 using the version supported by the HVE Core repository
* Bash on macOS or Linux
* PowerShell on Windows using the version supported by the HVE Core repository
* Access to Word Copilot only when the optional Word handoff is used
* Permission to process and attach the applicable customer material in the selected tools and destination

No Microsoft Work IQ MCP server, Docker, FFmpeg, or `jq` installation should be required.

### Requirements

## HVE-Core Research and Plan artifacts

[design-thinking-running-artifacts-workflow-plan.md](https://github.com/user-attachments/files/32251759/design-thinking-running-artifacts-workflow-plan.md)

[dt-method-1-scaffolding-requirements-research.md](https://github.com/user-attachments/files/32251792/dt-method-1-scaffolding-requirements-research.md)

## Project Scaffolding

* [ ] After DT Coach initializes its base project state, and the Method 1 directory. While the workflow creates any missing context, updates the Method 1 scope , running-artifacts of the design thinking artifacts, audit, and handoff directories.
* [ ] The Method 1 scope contains project understanding, stakeholder map, scope boundaries, assumptions log, and open questions artifacts.
* [ ] The running-artifacts directory contains drafts for vision statements, problem statements, scenarios, use cases, and personas.
* [ ] Scaffolding preserves every nonempty existing file and does not create duplicate artifact registrations or state entries when rerun.

## Incremental Customer Context

* [ ] The first ingestion can establish a baseline from an explicit user-selected set of context files.
* [ ] Later ingestions process only explicitly supplied new or changed sources and record a deterministic SHA-256 fingerprint for each source.
* [ ] Source documents are treated as untrusted data. Instructions embedded in a transcript, note, or document cannot redirect the workflow or expand its write boundary.
* [ ] The workflow updates project understanding, stakeholder map, scope boundaries, assumptions log, and open questions before evaluating downstream artifact changes.
* [ ] Existing supported knowledge remains in place unless new evidence directly contradicts it. Contradictions remain visible rather than being silently deleted.
* [ ] Repeated runs against unchanged inputs produce no semantic changes, duplicate content, or duplicate lifecycle records.
* [ ] When new evidence affects a registered customer-session discovery guide, the workflow updates only that guide or reports it as stale with a named manual owner. Unrelated guides remain unchanged.

## Running Design Thinking Artifacts

* [ ] Only artifact drafts affected by the reconciled evidence are updated.
* [ ] Observed, reported, assumed, and unresolved information remain distinguishable, and a single customer report is not promoted into validated research.
* [ ] New missing-information fields use `` and include targeted questions. Existing legacy tokens remain recognizable during migration.
* [ ] Running drafts remain separate from opt-in canonical snapshots. Draft candidates are never promoted to canonical content implicitly.
* [ ] Vision, problem, scenario, use-case, and persona content follows the shared entity model while preserving the distinct cardinality and completeness rules of running drafts and canonical snapshots.

## Grounding, Remediation, and Approval

* [ ] An independent read-only assessor audits all five running artifacts against frozen Method 1 evidence and source fingerprints.
* [ ] Audit findings identify the artifact, section, claim, evidence, severity, rationale, and proposed disposition without modifying project content.
* [ ] Remediation refuses stale audits, changes only explicitly authorized artifacts, preserves unresolved evidence conflicts, and produces a new audit record after content changes.
* [ ] Audit, approval, and handoff history is append-only. Later transitions never modify prior evidence records, and replaying the same operation does not create a duplicate transition.
* [ ] DT Coach records an explicit human approval or decline for the exact five-file aggregate fingerprint and current audit lineage. Approval is never inferred from audit success or from a request to prepare a Word prompt.

## Commit Suggestion

* [ ] DT Coach presents a suggested Git commit message only after a complete, current-fingerprint assurance pass with no unresolved blocking findings.
* [ ] Partial or blocked ingestion, failed or stale assurance, and unresolved blocking findings suppress the suggestion.
* [ ] The optional Word handoff does not control commit eligibility, and the workflow never stages, commits, or pushes changes for the user.

## Word Copilot Handoff

* [ ] The handoff requires a current human approval, a user-confirmed Word target label, and confirmation that the customer material may be attached.
* [ ] The output instructs the user to attach the entire running-artifacts directory to Word Copilot when directory context is supported.
* [ ] When directory context is unavailable, the output lists all five required files individually and refuses to prepare an incomplete handoff.
* [ ] The generated prompt tells Word Copilot to replace only the five matching sections, preserve wording, order, evidence, qualifiers, questions, and uncertainty, and stop when an attachment or target section is missing or ambiguous.
* [ ] The generated prompt tells Word Copilot to retain top-level section headings, render nested Markdown headings as bold labels, and format all supported missing-information tokens as bold red text.
* [ ] The skill reports only `blocked` or `prepared`. It never claims that Word was updated, synchronized, published, or verified. A later completion state can only record what the user reports.

## Cross-Platform and Compatibility

* [ ] Each user-invocable skill exposes equivalent Bash and PowerShell entry scripts for deterministic operations and uses one shared Python implementation for business rules.
* [ ] Cross-platform tests prove equivalent inputs, outputs, exit codes, path handling, fingerprinting, and failure behavior on Windows, macOS, and Linux runners.
* [ ] Existing DT Coach initialization, resume, disclaimer, method transition, canonical snapshot, and customer-card workflows continue to behave as before.
* [ ] Applicable HVE Core frontmatter, Markdown, skill, plugin, documentation, extension, and behavior validations pass before release.

Start with the existing DT Coach initialization and the linked running-artifacts workflow plan and scaffolding research. Trace how DT Coach and the RPI Agent currently manage project state, skills, and artifacts before defining the shared Python implementation and Bash and PowerShell entry points. Done requires the listed ingestion, grounding, approval, handoff, compatibility, and regression behaviors to be covered.

Written by the indexing model from the issue text.