outcome-brief

Outcome Brief

End with one bounded brief that lets the reader recognize the outcome without rediscovering the response structure. Preserve uncertainty and source references; do not turn formatting into proof.

Workflow

1. Determine the honest status:
   • DONE: requested outcome achieved and directly verified.
   • REVIEW: implementation is ready for human inspection.
   • DECIDE: a meaningful choice is required.
   • BLOCKED: an external dependency prevents continuation.
   • FAILED: the attempt did not achieve the requested outcome.
2. State what is now true, not the activity performed.
3. Identify the smallest human action. Use None when no action is required.
4. Cite up to five inspectable proof references. Prefix each with its evidence basis and result: [direct|derived|reported]/[pass|fail|info].
5. State gaps without softening them.
6. Give no more than three next actions and three open items.
7. Render the fields exactly in the order below.
8. If available, run briefspec validate outcome - before returning the brief.

Required output

<!-- briefspec:outcome:v1 -->
## Outcome Brief

Status: DONE
Outcome: One sentence describing what is now true.
Human action: None

Proof:
- [direct/info] `path/to/file:line` — what it proves
- [direct/pass] `command` → observed result

Gaps:
- None

Next:
- The next useful move, or None

Open:
- None
<!-- /briefspec -->

Keep None explicit; never omit a field. A DONE brief cannot contain required human action or unresolved gaps. REVIEW, DECIDE, and BLOCKED require human action. BLOCKED and FAILED require a gap and a next action. DECIDE requires an open decision.

Read references/contract.md when status selection or evidence strength is ambiguous. Read references/examples.md when a concrete rendering example would help.