honest-closeout

Honest Closeout

A closeout is read by someone deciding whether to trust the work without redoing it, and that decision runs on evidence — a path they can open, a number they can compare, a command they can re-run. Claims that arrive without evidence make the reviewer redo the work, which is the cost the report existed to save.

A result that failed, closed out with its full trail, is a good closeout: the trail is the deliverable in that case.

1. Reporting vocabulary

This is where the pack's reporting conventions are defined; other skills point here rather than restate them.

• Status first. Every message to the human opens with one word from a fixed set, so the state of the task is readable before the second word:

  Word	The task is
  WORKING	running; nothing needed from you
  GATE-HOLD	stopped at a review gate, waiting on your judgment
  STOPPED	stopped short — the two-strike rule handed the next move back to you
  DONE	every acceptance line passed with evidence and the report records independent functional verification outside the work's control
  CLOSED-FAILED	every acceptance line has evidence or a recorded blocking reason, but the target was not achieved

  Choose from these five. Use DONE when every acceptance line passed and the report records at least one independent functional verification outside the work's control: a rerun in an environment this task does not control, an independent test process, an integration or contract check, or a post-deployment smoke test. Artifact hashes and environment-and-commit identity belong in a separate integrity-and-identity record: they establish which bytes and execution context were reviewed, not whether the result is functionally correct, and they never satisfy the DONE verification requirement. If all four functional verification forms are unavailable, report why each form is unavailable and use CLOSED-FAILED rather than DONE. Use CLOSED-FAILED when the trail is complete but the target was not achieved, and STOPPED when the two-strike rule ends the run. A state that fits none of them is STOPPED, with the reason on the next line.

• The wait token. A message that needs the human to act ends with one fixed token alone on the final line — WAITING_FOR_HUMAN. It is reserved for exactly that case, which is what keeps it meaning something when it appears.

• Codes for state, sentences for claims. The status word and the wait token compress state — what this task is doing right now — and compression suits state, because it has a fixed set of values and gets read on every message. A claim about the world is the opposite case: this dependency is unmaintained, that bug is fixed, the upstream project has a design flaw. Claims go in full sentences in the report body, however long the sentence needs to be. Compressed into a field — severity: high, A1: read-side absent — a claim loses the one property a reviewer reads it for: how much it is asserting. A reader can tell that "the upstream project has a structural hole" deserves a second look before anyone acts on it; nobody can tell that from a severity value. The audacity of a claim lives in its wording, and the wording is exactly what a code throws away.

• [UNVERIFIED] marks the unchecked. Version numbers, licence terms, quota limits, "this is fixed" — anything not confirmed at its source this session carries the tag inline, so a reviewer can tell a checked statement from a confident one.

• Classification tags mark what a fix actually was. root-fix, patch, workaround for what kind of change it was; one-shot, recurring for how often it has to run to keep working. Defined in full at §2, item 2, because they attach to acceptance lines the same way evidence does.