Decide the generator's empty-response behaviour

[NathanTarbert]

packages/outpost/ai/src/generator.ts was changed on #170's branch to throw when the model returns no usable text:

const responseText = extractResponseText(message.content);
if (!responseText.trim()) {
    throw new Error('Model response contained no usable text');
}

Previously it returned an empty string. The change came in alongside a genuine fix — the generator only read message.content[0], so a multi-block response silently lost every block after the first — but the throw is a separate, unrequested behaviour change and deserves its own decision.

What it changes

Every caller of the generator is affected, not just the support-response path. An empty or tool-only model response now becomes a thrown error, which becomes a failed job, which after MAX_JOB_ATTEMPTS walks to DEAD_LETTER.

The case for it

Fail-loud is usually right. Publishing an empty response to a customer is worse than failing visibly, and an empty completion nearly always means something upstream is wrong — a bad prompt, a refusal, a truncated stream, a tool-only turn being treated as final.

The case against it

• It converts a recoverable oddity into a terminal job failure. Retrying an empty completion is often the right move, and three retries then dead-letter is a heavy response.
• A tool-only response is legitimately empty of text. If any pipeline path uses tool calls, this throws on a correct response.
• The blast radius is every generator caller, decided in a PR about something else.

What to decide

1. Is throwing correct, or should an empty response be retried, or returned and handled by the caller?
2. If it throws, should it be a distinct error type so the queue can classify it as retryable rather than dead-lettering?
3. Should the check be !responseText.trim(), or narrower — e.g. only when there are no content blocks at all, so a tool-only turn passes through?

Small change, real reach. Worth an explicit call rather than inheriting it from a multi-block bug fix.

[NathanTarbert]

Resolved in substance by #223 (merged 825d0981), though not closed by it — worth recording which of the three questions here actually got answered.

Q1, is throwing correct: yes, and it shipped. generate() now throws 'Model response contained no usable text' on empty.

Q2, distinct error type so the queue can classify it as retryable: no, and the concern that motivated this issue turned out not to apply. The throw is caught by the never-crash fallback at generator.ts:163, ~30 lines below, so the job returns success and never reaches MAX_JOB_ATTEMPTS or DEAD_LETTER. The blast radius this issue worried about doesn't exist. The inverse problem does: an empty completion is archetypally transient and now permanently burns the ticket's one AI response with no retry. That is tracked as the retry-ladder item in #231.

Q3, !responseText.trim() or narrower: .trim() shipped, and it's pinned by a whitespace-only test. The tool-only-turn scenario this issue raised isn't reachable through this call shape — generate() passes no tools and no thinking, so the API returns exactly one text block.

What's left of the original question is the higher-yield check #223 deliberately didn't take: stop_reason !== 'end_turn', which covers the unusable modes that actually happen today (max_tokens truncation publishing mid-sentence, refusals publishing as ordinary text). That is #231.

Suggest closing this in favour of #231 + #237 unless the stop_reason decision should be recorded here instead.