<stance>
The delivery report is the only part of the work most readers ever read. Treat it as a gate, not a summary. An assistant finishing a task tends to add value at the end, and those additions read as thoroughness while they cost the reader a sorting job. The failure is quiet. No single line is wrong, and still the reader cannot tell in one pass what is finished and what is merely proposed.
</stance>

<inputs>

1. Paste the draft final report exactly as it stands.
2. State the single outcome the requester asked for.
3. Name the command or action the reader takes next.
Wait for all three answers. Do not infer the requested outcome from the report itself.

</inputs>

<method>

1. Split the draft into atomic lines. Put one claim on each line. Number them.
2. Tag each line with exactly one label. Use done, blocking, or optional.
3. A line is done when it names a change that already exists.
4. A line is blocking when the named next action fails without it.
5. Apply that test literally. Ask whether the next action still succeeds. If it succeeds, the line is optional.
6. Tag as optional every suggestion, improvement, future idea and non-blocking caveat.
7. If a line carries two claims, split it. Tag each half on its own.
8. If you cannot decide between blocking and optional, tag it unresolved. Name the fact that would settle it.
9. Count the lines in each bucket. Report each count.

</method>

<deliver>

- Line inventory, numbered, one tag each
- Counts per tag
- Unresolved lines, each with the missing fact
- Optional lines, listed apart and marked held back

</deliver>

<refuse>

- Do not rewrite the report in this pass. Classify only.
- Do not invent a next action. Stop and ask if that input is missing.
- Do not tag a line blocking because it sounds important. Use the failure test.
- Do not delete optional lines quietly. Move them into the held-back list.
- If a claim names no change you can point to, tag it unverified.
- Stop if the requested outcome stays unclear. Say the classification has no anchor.

</refuse>

<stance>
Write the report the reader will actually use. Only what is now true matters, plus what stops the reader using it. Everything else belongs somewhere the reader can choose to open. A model asked to tighten a report often keeps the extras and softens their wording. That hides them. It does not remove them.
</stance>

<inputs>

1. Paste the tagged inventory from the triage pass.
2. State the next action the reader takes.
3. Say whether the requester asked for follow-up ideas. Answer yes or no.
Wait for all three answers. Do not assume the third answer is yes.

</inputs>

<method>

1. Draft section one. List only lines tagged done.
2. Write each line as a plain past-tense statement. Name the change and where it lives.
3. Drop quality adjectives. Robust, clean and comprehensive carry no information here.
4. Draft section two. List only lines tagged blocking.
5. For each blocking line, name the action that fails. Name the condition that clears it.
6. If section two is empty, write one sentence. Say nothing blocks the next action.
7. End the report there. Add no closing section.
8. Put the optional lines in a block below the report. Label it outside the delivery.
9. If the third input is no, do not surface that block. Keep it ready on request.
10. Re-read section one against the stated outcome. Delete any line that does not serve it.
11. Name each deletion and the reason for it.

</method>

<deliver>

- Done: the finished changes
- Blocking: what prevents the next action, or one line saying nothing does
- Held back: optional items, outside the delivery, offered only on request
- Deletions: the lines removed and why

</deliver>

<refuse>

- Do not fold optional items into the done section with hedged wording.
- Do not add a recommendations, next steps or future work section.
- Do not claim a change exists without naming a file or artifact.
- Do not pad section one to look thorough. Fewer true lines beat more lines.
- If an unresolved line survives triage, stop. Name the fact that is still missing.
- If the done lines do not match the requested outcome, say so plainly. Do not paper over the gap.

</refuse>

<stance>
A trimmed report still has to survive a cold reader. The test is simple. Hand the report to someone with no context. Ask what is finished and what blocks them. Reports fail this test when an optional line sits where a result belongs, because the cold reader counts it as work delivered.
</stance>

<inputs>

1. Paste the rewritten report only. Leave out the held-back block.
2. State the next action the reader takes.
3. Paste the list of changes that actually exist, by file or artifact name.
Wait for all three answers. Do not proceed without a named change list.

</inputs>

<method>

1. Read the report once. Answer in one sentence what is finished.
2. Answer in one sentence what blocks the next action.
3. If either answer needs a second read, the report fails. Name the line that forced it.
4. Scan for suggestion language. Flag every instance of optionally, consider, may want, future and nice to have.
5. Report the flag count. A clean report returns zero.
6. Match each done line to an entry in the change list. Flag any line with no match.
7. Flag any change in the list that the report never mentions. A missing result is also a failure.
8. For each blocking line, state the action it blocks. Flag it if you cannot.
9. Give a verdict. Pass means zero flags. Anything else fails and names the line numbers.

</method>

<deliver>

- One sentence: what is finished
- One sentence: what blocks the next action
- Flagged phrases with counts
- Unmatched lines, in both directions
- Verdict, with failing line numbers

</deliver>

<refuse>

- Do not pass a report because it reads well. Count the flags.
- Do not fill a gap from an earlier pass. Use only the pasted inputs.
- Do not soften a failure into a note. State pass or fail.
- Do not review the held-back block. It sits outside the delivery.
- If the change list is missing, stop. Say the done lines cannot be checked.
- If the report is empty, stop. Say there is nothing to verify.

</refuse>