# Better Harness evidence lanes as DSH skill bundles

## Traceability

- Spec ID: better-harness-lane-extraction
- Status: Implemented
- DSH baseline: `0.1.0-rc.6`

## Intent

Better Harness separates an agent-project review into three independent evidence
concerns. Preserve Better Harness as the upstream product while carrying those
three boundaries to the DeepSeek Harness as skill bundles that can be installed
one at a time.

A user who wants only a repository readiness review should not have to install a
session analyzer, a scoring engine, and a report renderer.

## Acceptance criteria

- AC-1: `packages/` carries the Session, Project, and Agent Asset evidence
  concerns as three independent bundles, so each can be installed alone.
- AC-2: Every bundle registers exactly one DSH runtime skill, ships a matching
  `cordis.patch.yml` whose identity equals the package name, stays inside the
  portable skill frontmatter contract, and packs the files needed at runtime.
- AC-3: Every bundle ships zero runtime dependencies.
- AC-4: Every skill description states both when to use the skill and when not
  to, because the three lanes are adjacent enough to misroute into each other.
- AC-5: The repository documents attribution, installation, composition,
  validation, and the boundary between these packages and the upstream product.

## Non-goals

- Porting the Better Harness collectors, reconciliation engine, scoring, Canvas,
  report renderer, or host adapters.
- Hosting plugins with a different origin. Qoderian-derived work and the
  DeepSeek Web session sync were moved out of this repository for exactly this
  reason: a repository named after Better Harness should contain the Better
  Harness port and nothing else.
- Claiming npm package-name ownership or automating publication. Registry
  credentials, release tags, and community submission stay manual.
- Modifying the Better Harness upstream working tree.

## Design decisions

**One skill per package.** A DSH profile composes bundles explicitly, so the
unit of installation should equal the unit of decision. Bundling three evidence
lanes together would force the composition choice back onto the user — which is
the exact property being ported away from.

**The negative clause in each description is load-bearing.** Three adjacent
review skills in one profile is a routing hazard: a question about a session can
easily pull in the asset auditor. Stating what each skill must *not* be used for
suppresses that better than sharpening the positive half.

**Bundles never claim an upstream collector ran.** These packages expose Better
Harness's evidence *boundaries* as prompt-level skills. They contain no
collectors, so the skill text returns evidence candidates rather than final
severities or repository-wide scores, and reports missing evidence as missing.

**`parseCanonicalSkill` is duplicated in every package, deliberately.** A shared
helper package would make three independently publishable bundles share a
version-coupled runtime dependency for roughly thirty lines of parsing, and cost
the zero-dependency property that makes a single-lane install cheap. The
duplication is the cheaper trade, and `scripts/validate-packages.mjs` asserts
that every copy still produces an identical skill shape.

**The validator imports the real plugin entry.** It does not lint the manifest
in isolation; it loads `index.js`, captures the registered skill, and checks
bundle identity, frontmatter, resource paths, description limits, and teardown.
A package that passes structural review but fails to register is caught here.

## Validation

```bash
node scripts/validate-packages.mjs
node scripts/pack-dry-run.mjs
```

## Known risk

DSH is pre-release. The `0.1.0-rc.6` baseline is stated explicitly in every
package's `peerDependencies`; re-run the bundle checks before claiming support
for a newer DSH.