The built-in `## Result` prompt describes the file instead of asking for it — measure the miss rate, then decide the wording

[vjovanov]

The problem

The built-in ## Result prompt section tells an agent that a file exists. It never tells it to write one:

## Result

A transition from this state can finish this task. The finished task's result is read from this file.

- `runtime/results/<task-id>.md`

That is description, not obligation, and agents read it as description. It is the direct cause of #105: an agent worked for twelve minutes, made three commits, published its declared export, and did not write the result — because nothing asked it to.

The wording is deliberate. render_terminal_result in crates/rhei-cli/src/cli/run_prompt_sections.rs says so:

The section names the fact and the path and stops there — "write it, then exit" is completion prose, and completion is enforced by the completion condition, not by prompt wording.

That reasoning was sound in principle and false in practice. The completion condition was not enforcing it: the scheduling filter asked a weaker question than the post-exit check, so a state that failed the condition was reclassified as finished on the next pass. #106 closed that hole, so the enforcement the comment defers to now genuinely exists.

Why it still matters after #106

#106 makes a missed result a halt, not a false completion. That is correct, and it is not free. The recovery is to re-spawn, bounded by the new attempts: budget, default 2. So an agent that misses the result on attempt 1 costs a second full invocation, and if it misses again the ticket halts and a human is needed.

If the descriptive wording makes attempt 1 miss routinely, the default budget means every affected ticket pays for two full agent runs and then stops. The budget bounds the tail; it does nothing to the rate. Reducing the rate is what this issue is about.

What to decide

Whether the first attempt's prompt should state the obligation, and how far.

• The narrow version. Ask the whole completion condition before a pass skips an agent invocation #106 already writes a stronger sentence on a retry — it names the artifact the previous attempt left unwritten. Nothing says the first attempt cannot be told the same thing before it fails. This is a one-section change with no new mechanism.
• The objection to answer. The comment's concern is real: prompt prose is not enforcement, and a prompt that says "write it, then exit" invites an agent to treat writing the file as the goal rather than the account of work actually done. A result written to satisfy a sentence is worse than no result. Any rewording has to add the obligation without turning the file into a checkbox.
• The supervising case already carries a qualifier saying to write the result only on the visit that finishes the subtree (§FS-rhei-supervision.4.1). Whatever wording lands must not weaken that — a supervisor writing a result on every visit is its own defect.

Measure first

The honest sequence is to let #106 run and count. The spawn record it introduced makes this directly answerable: every re-spawn is on disk with the reason the previous attempt did not finish.

• Report how often a ticket spends more than one attempt, and how often it exhausts the budget, across real runs.
• Split that by agent — six built-ins are supported, and the miss rate is unlikely to be uniform across them. If one agent accounts for most of it, the fix may be that agent's profile rather than the shared prompt.
• Only then decide the wording, with the numbers in hand.

If the budget is routinely spent 2-of-2, the prompt is the bug and the cap is paying for it twice. If it is almost never spent, the current wording is fine and this issue closes with the data recorded.

Raised from #105 / #106. Related: #107, which bounds the spend rather than the rate.