# Model-Ready Verification Contract

Use this contract whenever you change code, configuration, behavior, context
assembly, service lifecycle, or a user-visible UI path.

## Before editing

Write or hold this compact plan:

```text
Goal: <requested outcome>
Current evidence: <source/runtime fact>
Change claim: <what the edit should make true>
Negative risk: <what must not regress>
Proof check: <smallest meaningful test/inspection>
```

Do not make up a test command. Use existing project scripts, existing tests,
or a small focused harness that exercises the real changed behavior.

## During editing

After each substantial mutation:

1. Mark previous relevant verification as stale.
2. Run the focused proof check when the change is ready to observe.
3. Read the real output.
4. Attach the result to the claim it proves or disproves.

Do not turn a missing check into a blocked tool call. Missing proof means
`planned` or `unknown`, not a synthetic failure.

## Result ledger

Keep this shape visible to the agent and operator:

```text
[DEVELOPMENT VERIFICATION v1]
Goal: <current user outcome>

C1 <claim>
  proof: <observable>
  check: <command/tool/test>
  status: passed | failed | stale | planned | unknown
  evidence: <exact tool-result id/path/summary>

Open gaps:
- <only claims that lack current proof>
```

Rules for the ledger:

- A passing build proves buildability only.
- A passing test proves only the behavior that test observes.
- A later mutation stales only checks affected by that mutation.
- A failed test remains evidence until a later relevant pass resolves it.
- Keep the exact transcript or durable reference outside ordinary prompt
  history so it can be inspected without flooding context.

## What to test

Prefer this order:

1. A regression fixture that reproduces the reported failure.
2. A behavioral harness that crosses the changed boundary.
3. A focused unit/integration test for the changed component.
4. A project build/typecheck/test command required by repository policy.
5. A manual UI/service observation when automation cannot reach the path.

For context engineering, test what the parent model actually receives. Do not
test only internal labels or metadata. Example:

```text
Bad proof: evidence.fidelity equals "full".
Good proof: the next parent request contains the required source sentinel.
```

## When the test fails

Do this:

1. Quote the smallest useful failure fact.
2. Identify the claim it disproves.
3. Inspect the implicated source/runtime boundary.
4. Change code or revise the claim.
5. Rerun the focused check.

Do not do this:

- repeat the same failed action without a changed input, source state, or
  hypothesis;
- add a controller block to hide the failure;
- declare a test advisory merely because it is inconvenient;
- broaden into unrelated edits before understanding the failure.

## Completion check

Before reporting completion, answer:

```text
What changed?
Which current checks support each requested behavior?
What changed after those checks ran?
What remains unproven or intentionally deferred?
```

If the answer contains an unresolved claim, report it plainly. Do not invent a
pass and do not force the model into an unrelated repair loop.