# Harness Health Scoring Rubric

Use this when asked to audit or score a repository's harness quality.

## Dimensions

### 1. Project map clarity
- strong: key directories, entrypoints, and subsystem boundaries are documented and current
- partial: some structure is documented but stale, shallow, or incomplete
- weak: little or no useful repo map exists

### 2. Validation commands
- strong: build, test, lint, typecheck, or equivalent validation commands are clear and runnable
- partial: some commands exist but are incomplete, stale, or ambiguous
- weak: commands are missing, misleading, or unverified

### 3. Fast feedback
- strong: targeted package-, crate-, app-, or feature-scoped checks exist
- partial: only slower validation paths exist, or quick checks are incomplete
- weak: no obvious fast validation path exists

### 4. Task contract quality
- strong: reusable task contracts or templates define scope, constraints, validation, and acceptance criteria
- partial: ad hoc task instructions exist but are inconsistent or underspecified
- weak: every task must be reinvented from scratch

### 5. Guardrails
- strong: high-risk areas, forbidden changes, generated-file boundaries, and slow validations are explicit
- partial: some constraints exist but are vague or fragmented
- weak: almost no meaningful constraints are documented

### 6. Architecture decision durability
- strong: durable decisions are easy to find in ADRs, accepted docs, or equivalent records
- partial: some decisions are documented but scattered, stale, or inconsistently applied
- weak: important architecture or workflow decisions must be rediscovered from chat or code archaeology

### 7. Failure feedback loop quality
- strong: repeated AI or implementation failures are converted into durable harness, validation, or CI improvements
- partial: some failures are documented, but fixes remain mostly conversational or one-off
- weak: the same classes of failure recur without system updates

### 8. Doc-code alignment
- strong: harness docs match the current repo layout, commands, and constraints
- partial: mixed accuracy with some stale sections
- weak: obviously stale or misleading guidance dominates

## Output format

Keep the score compact. Example:

- project map clarity: partial
- validation commands: strong
- fast feedback: weak
- task contract quality: weak
- guardrails: partial
- architecture decision durability: weak
- failure feedback loop quality: weak
- doc-code alignment: partial

Top priorities:
1. Add a targeted validation command for the touched package or crate
2. Record one durable architecture decision in an ADR or accepted design note
3. Turn the most common repeated failure into a task-contract, guardrail, or CI rule