64 lines
2.7 KiB
Markdown
64 lines
2.7 KiB
Markdown
# 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
|