[Feature]: Qualify DeepSeek Harness for portable HTML report rendering

[Cobb04]

Preflight

• I searched existing issues for a similar request.

No active owner was found for DeepSeek Harness portable report rendering or durable output. This request follows the shared-analysis work completed in Issue #104 and PR #110.

What problem are you trying to solve?

DeepSeek Harness can now discover Better Harness, collect Session and configured evidence, enter shared Asset Practices/Harness analysis, and produce the Evidence Bundle used to reconcile canonical findings. It is still capability-gated out of durable report rendering, so /better-harness must remain inline/no-files for DSH even though the existing portable renderer accepts the same shared report-data contract.

DSH users can receive the analysis, but not the normal durable Better Harness report artifacts.

What would success look like?

• Add REPORT_RENDERING to DSH without adding CHECKUP.
• Route DSH through the existing portable html mode and shared HTML/Markdown renderer.
• Publish the standard findings.json, report.md, and self-contained report.html artifact set.
• Use <target>/.dsh/better-harness as the Better Harness-derived root under the existing generic .<provider>/better-harness convention.
• Preserve explicit no-files behavior and all existing portable and Canvas host routes.
• Reuse the current report-data schema, staging, validation, atomic publication, rollback, and artifact validation behavior.
• Add deterministic privacy, Windows/cross-platform, publication-failure, and packaging qualification.
• Add or retain a credential-free native DSH receipt proving the report directory remains inert to native discovery.

Where would this be used?

When /better-harness runs inside a qualified DeepSeek Harness environment and the user wants durable report output rather than inline/no-files analysis.

The currently researched native baseline is DeepSeek Harness 0.1.1-rc.2 at b150a551b8d465e31e418e1b2eaf5e79bbb7d28e. Better Harness owns rendering and publication; this does not depend on a native DSH rendering API.

Examples or evidence

• Issue #104 / PR #110 landed shared DSH analysis and deliberately left rendering independently capability-gated.
• Existing portable hosts including Grok, Kimi, WorkBuddy, and Codex reuse the shared HTML/Markdown renderer.
• Current DSH shared analysis supplies the generic evidence needed to draft canonical reviewed findings.json; Evidence Bundle itself is not direct renderer input.
• Source audit and credential-free native probes against DSH 0.1.1-rc.2 established that .dsh/better-harness is not interpreted as a Skill, Instruction, profile, preset, plugin, Session, setting, credential, or attachment root.
• Current open Issues, open PRs, and recent DSH/rendering history contain no overlapping owner for this bounded capability.

Anything else?

Non-goals:

• no DSH-specific renderer or report-data schema;
• no Session adapter or DSH configured-assets semantic changes;
• no Evidence Bundle v3 or Asset Baseline v2 changes;
• no CHECKUP, Canvas, or Studio integration;
• no native DSH modification;
• no new dependency, renderer, template, or static asset;
• no claim of full DSH support and no broad Quickstart/launch work;
• no reopening of the shared Session request-summary privacy policy.

Rendering must preserve configured-not-observed: it must not imply that currently configured Skills or Instructions existed during or influenced historical Sessions. Windows/output-path qualification should cover the existing generic publication contract, including drive, UNC, root, and run-directory behavior, without redesigning the renderer.

If this bounded capability/routing qualification matches the intended direction, I can follow with the implementation PR.

[phodal]

@Cobb04 Welcome to PR.