[alexandre-vl]

Human comments

What was wrong

The automations plugin already stored why a run failed (automation_runs.error) and why an automation stopped (automations.last_error), but the app rendered neither for agent automations: RunRow showed run.error only for script runs, and only bb automation show read lastError. A run refused before it reached a thread, for example because its target thread had been archived, therefore showed a red ✕ and 0.0s with no thread to open, while bb silently paused the automation. The stored text was also vague (Target thread … is unavailable: missing, deleted, archived, or not runnable) although the plugin had already read which one applied, and other automations on the same thread were paused with target thread deleted even when it had been archived.

What changed

• Run rows (detail-view.tsx): a failed run shows its error in the existing detail block for every run mode, not only scripts. Agent runs that reached a thread stay clickable; that thread is the full log.
• Automation header and list row (detail-view.tsx, overview-view.tsx, metadata.tsx): an automation with a lastError shows it under the detail header and at the end of the list row's metadata. The list's red ✕ follows the same rule, so it never appears without its reason: it clears on Resume, which already cleared lastError, and hides while a run is in flight.
• Precise target-thread reasons (src/run.ts, src/data.ts): a refused target thread records Target thread <id> was archived, was deleted, no longer exists, or is <status>, and every automation paused on that thread gets the same message. The thread.deleted handler records Target thread <id> was deleted. The WHERE last_error = 'target thread deleted' marker query became UPDATE … RETURNING.
• Stories: a paused-by-failure list row and a Failure States detail story.
• Error text stays free text rendered verbatim; nothing parses it. No wire, schema, or CLI flag changes. Errors stored before this change keep their old wording.

How you verified

• pnpm exec turbo run typecheck lint test --filter=bb-plugin-automations: 141 tests pass; lint reports 0 errors (4 pre-existing set-state-in-effect warnings in untouched code).
• The new and updated tests fail against main's implementation (6 failed, 135 passed) and pass on this branch: archived and missing targets name their cause on the run and on both automations, the list ✕ appears only with its reason (including during a retry and after Resume), and the detail header and a failed agent run show the error.
• The screens below render the automations Ladle stories with main's components (before) and this branch's (after). Dark theme and 390px also checked. Not exercised in a full dev app.
• Found on a real install: two scheduled automations pointed at threads archived the evening before; each next run failed in under 40 ms, bb paused both, and the app showed only a red ✕.

Before: main at b143a2286 · After: 1a1d53ad8 · Ladle stories, light theme, 2×

Screen / state	Viewport	Before	After
Automation detail · paused after its target thread was archived	Desktop · 1100 wide
Installed list · one failing, one paused by a failure	Desktop · 1100 wide
Installed list · same rows	Compact · 390 wide

Refs #4166: this covers its visible reason and the vague wording; recovering a target thread left in error stays open there.

AGENT GENERATED

[alexandre-vl]

On structured error codes: this PR keeps failure reasons as free text on purpose. The UI renders lastError and run.error verbatim and never branches on their content; the server decides from structured fields (the thread's deletedAt, archivedAt and status, an HTTP 404, the SDK's project error code) and only writes the sentence at the end.

Add a stored errorCode once the UI needs a different action per cause, such as "Open the thread" for an archived target or "Retarget" for a deleted one: a column on automations and automation_runs, a field in the RPC response and the CLI --json. Not a parse of the message.

AGENT GENERATED