# Quality Review and Handback Contract

## Self-review questions

Before handing off code, ask:

### Intent

- Did I solve the current user request rather than an older or easier task?
- Did I preserve explicit constraints such as “do not publish” or “do not
  restart”?
- Did I avoid silently expanding scope?

### Evidence

- What exact source/runtime evidence established the original issue?
- What exact behavior does each new/changed test prove?
- Did I mistake a compile/build pass for a behavior pass?
- Did any later mutation stale the proof?

### Simplicity

- Did I add a policy layer where a natural tool/runtime result would be better?
- Did I create a cache/pointer that claims source visibility without body text?
- Did I add prompt/controller prose that could compete with current evidence?
- Can a capable model simply inspect, edit, test, and converge?

### Safety

- Did I preserve unrelated user work?
- Did I avoid destructive commands and unrequested external changes?
- Did I verify live service/process/hardware identity rather than assuming it?

### Communication

- Is the result reported as observed fact rather than aspiration?
- Are unverified or unperformed actions named plainly?
- Is the final response concise enough to be useful and complete enough to
  audit?

## Quality anti-patterns

Reject these patterns:

| Anti-pattern | Why it fails | Preferred behavior |
| --- | --- | --- |
| “Build passed, so fixed” | Build does not prove runtime behavior | Run focused behavior proof |
| “Cache says read” | Cache identity is not source visibility | Track body/range visibility |
| “Block tool until recovery” | Hides natural evidence and creates loops | Show advisory; let tool report truth |
| “Test changed, weaken assertion” | Can preserve regression | Update only when product contract changed |
| “Old failure repeated in context” | Biases model toward stale recovery | Retain one current result and audit rest |
| “Service restarted” | Does not prove new code runs | Verify immutable boot identity |
| “Task complete” with unknown proof | Misstates delivery truth | Report incomplete verification/gap |

## Handoff evidence template

```text
Implemented: <user-visible behavior>
Evidence: <focused test/build/runtime result>
Files: <changed files>
Not performed: <publish/restart/deployment/manual check, if applicable>
Residual risk: <only real unresolved risk>
```

Use this template as a final truth check, not as boilerplate. Omit empty
sections rather than filling them with vague reassurance.