[Feature]: Add DSH shared Harness analysis with frozen-cwd Evidence Bundle support

[Cobb04]

Preflight

• I searched existing issues for a similar request.

What problem are you trying to solve?

Better Harness can separately analyze persisted DeepSeek Harness (dsh) Sessions and inventory DSH filesystem Skills plus cwd-sensitive Instructions. However, the canonical /better-harness Skill invokes harness evidence-bundle, and DSH is rejected at Evidence Bundle admission before those sources can participate together in shared Harness analysis.

As a result, a DSH user cannot produce one shared analysis context containing Session Evidence, Project Harness evidence, Agent Customize/configured-asset evidence, and neutral Harness lead analysis. This is the remaining gap; the individual Session and Configured Assets slices already exist.

ASSET_PRACTICES, HARNESS_REPORT, and EVIDENCE_BUNDLE belong in one bounded Story because the bundle needs both truthful configured/practice evidence and neutral shared analysis. They cannot be enabled as flags alone. DSH Instructions change with cwd, while the current bundle freezes workspace but not cwd, so the same workspace can otherwise collect a different Instruction set across lanes.

What would success look like?

Better Harness can run a normal DSH Evidence Bundle under one versioned frozen parameter context and, when ordinary source/topology requirements are complete, return status: complete with:

• Session Evidence;
• Project Harness evidence;
• Agent Customize / Asset Baseline evidence; and
• neutral Harness lead analysis.

The versioned Evidence Bundle contract explicitly freezes canonical cwd because cwd changes which DSH Instructions are applicable. That cwd is forwarded consistently to Agent Customize / Asset Baseline, Harness analysis/task-loop inputs, and any shared configured-asset collection involved in the Story; it is never derived from Session Analysis. A schema v3 is the likely compatibility direction, but the implementation can use another versioned mechanism after maintainer alignment.

Qualification for the three new capabilities preserves these boundaries:

• generic DSH Skills and Rules remain visible in practice coverage without a DSH-only duplicate collector;
• compact provenance distinguishes a current configured snapshot from historical Session evidence and retains configured-not-observed plus relevant DSH qualification/runtime-resolution limits;
• bundle-facing lint findings sanitize external/project-root and authorized user-home absolute paths using existing path-bounding conventions, while direct provider evidence remains useful and user-home stays default-closed;
• configured/current evidence is not presented as runtime use or as proof that an asset existed during a historical Session; and
• existing credential sanitization and the maintainer-aligned Session request-summary policy remain enforced.

After qualification, DSH advertises ASSET_PRACTICES, HARNESS_REPORT, and EVIDENCE_BUNDLE in addition to its existing capabilities. The canonical /better-harness flow can then proceed past its current Step 1 rejection for inline/no-files analysis. HARNESS_REPORT means neutral shared analysis evidence here, not rendered HTML or Markdown.

Where would this be used?

The primary surface is canonical Better Harness /better-harness → harness evidence-bundle → shared Harness analysis for DSH. It also affects direct Asset Practices, neutral Harness analysis, and Evidence Bundle admission. It does not add final rendered report support.

Examples or evidence

• Issue #93, PR #94, PR #97, and PR #98 established and hardened DSH Session Analysis / Session Evidence.
• Issue #99 and PR #100 established verified canonical Skill discovery and explicit /better-harness invocation.
• Issue #101 and PR #102 established DSH configured-assets / AGENT_CUSTOMIZE; PR feat(dsh): add configured asset inventory #102 deliberately excluded Asset Practices, Harness Report, and Evidence Bundle.
• Current source shows that Project Harness is generic and DSH-compatible, Asset Practices is structurally compatible but needs the qualifications above, and generic Harness analysis works below the current capability gate.
• A temporary gate-only feasibility simulation made all four Evidence Bundle lanes available and produced an overall complete bundle. This demonstrates cohesion and feasibility, not production qualification.
• Report rendering remains independently capability-gated.

Anything else?

Capability boundary: DSH already has SESSION_ANALYSIS and AGENT_CUSTOMIZE. This Story adds only ASSET_PRACTICES, HARNESS_REPORT, and EVIDENCE_BUNDLE. REPORT_RENDERING and CHECKUP remain absent; capability promotion does not imply full host parity.

Temporal boundary: if a Session happened on August 1 and configured Skills are collected on August 24, Better Harness must not infer that a current Skill existed on August 1, influenced that Session, or was used in it. This Story retains enough compact provenance to communicate the current configured snapshot and configured-not-observed semantics without inventing a runtime-use evidence model.

Out of scope are report rendering; HTML/Markdown and Canvas/report-file routing; final durable output; CHECKUP; lifecycle integration; Quickstart or the complete default durable /better-harness loop; full Cordis, Profile, or Preset resolution; runtime/scoped Skill enumeration; MCP, Plugin, Profile, Hook, or Custom Agent completeness; atomic filesystem snapshotting across all analysis owners; upstream DSH changes; and any claim that current configured assets existed in or influenced historical Sessions.

Should Evidence Bundle v3 inherit the existing bounded, credential-sanitized Session request-summary policy, or should v3 remove arbitrary user request prose from bundle evidence entirely?

I'd be happy to take this implementation after scope alignment.

[phodal]

Welcome to PR