# Harness audit

Score evidence, not intention. A score of five means the subsystem works
repeatedly and is checked for drift.

| Subsystem | Score | Evidence | First improvement |
| --- | ---: | --- | --- |
| Instructions | /5 | | |
| Tools | /5 | | |
| Environment | /5 | | |
| State | /5 | | |
| Feedback | /5 | | |

## Scoring guide

### Instructions

- 1: rules live in prompts, chat, or memory.
- 3: a root instruction file describes the stack, commands, and boundaries.
- 5: concise instructions route to maintained documents and executable rules.

### Tools

- 1: the agent can only propose text changes.
- 3: the agent can inspect files and run the main project commands.
- 5: least-privilege tools expose the real interfaces and diagnostic evidence.

### Environment

- 1: setup depends on undocumented local state.
- 3: runtime versions and dependencies are pinned.
- 5: setup is reproducible, isolated, and checked before implementation.

### State

- 1: each session reconstructs previous work.
- 3: progress, decisions, and incomplete work are written to the repository.
- 5: handoffs are current, structured, and verified against git and tests.

### Feedback

- 1: completion is based on the agent's confidence.
- 3: lint, types, tests, and build commands are explicit.
- 5: the full user flow, runtime evidence, and failure paths are repeatable.

## Failure attribution

- Observed failure:
- Subsystem responsible:
- Evidence supporting that attribution:
- Smallest change to test:
- Result with the same model and task: