feat(cards): a refusal says refused; a crash still says failed

[lucy-wolfe]

A card headline for a caller refusal now reads refused; a genuine system fault keeps failed.

Hiring teammate refused · The root department id is 'executive' — 'acme-capital' names the company…
Hiring teammate failed  · chiefd returned an invalid outcome  (system fault)

Why the word matters

It is a claim about whose fault the failure was, and the two invite opposite recoveries. "Refused" invites a corrected call. "Failed" invites a retry. Using either for the other sends the reader to the wrong action — and calling a crash a refusal is the worse direction, because it sends somebody to fix a call that was never wrong.

This is only implementable because the classification already exists to follow. The verb reads that, rather than matching on message text, which this file explicitly bans.

The split follows the classification, not a list

One predicate, in one place. That matters more than it looks: three renderers build a failure title, and two of them are bespoke ones for the bench/recall and start/stop batches. Those would have gone on saying "failed" for a refusal, because they never reach the default path.

They were found by sweeping for the word rather than trusting the default renderer to be the only producer — the same both-arms property that has cost this codebase several rounds. A rule copied into three renderers is three rules waiting to disagree at the first bespoke card.

One case was not what the classification said it was

A partial hire carries status: "hire_partial" so the card can name the people already hired — a retry needs that, or it hires them twice and fails on the wrong person.

But that status is data a retry needs, not an assertion about fault, and the error it wraps may be either kind: a mid-batch caller refusal (an unknown department on person four), or a genuine crash. So "carries a status" and "is the caller's fault" are not the same property, and treating them as one would have labelled a real crash a refusal.

That path now asks the wrapped error's own type, exactly as every other site does. And a producer in the same position marks itself with fault: true rather than being enumerated in the renderer — a marker, not a list, because a list is where the next case is missed.

Pinned by a discriminating pair

Per the rule this codebase keeps re-learning: a test asserting only "a refusal says refused" is satisfiable by returning true for everything, which would relabel every crash a refusal and delete the distinction rather than use it.

• a classified refusal is refused;
• an unclassified failure is not;
• a status carried as context with fault: true is not.

Verified by mutation: making the predicate return true unconditionally fails both negative cases.

The collapsed card

"Refused" is one character longer than "failed". The 120-character window applies to the summary tag rather than the title, and the title is not what gets truncated, so no card's truncation point moves. Checked rather than assumed, since it was asked.

Scope note

The (system fault) tag keeps the rule it was given previously: it is driven by the absence of a status. A hire_partial result that wraps a real crash therefore says "failed" but does not carry the tag. That is pre-existing behaviour and not changed here — flagged as an observation rather than fixed silently, because it is a separate decision about what the tag means.

Checks

bun run typecheck, test, lint, lint:reactive, knip, all 98 repository guards, and CI.

[lucy-wolfe]

Superseded by #16, which merges this branch together with the other two changes so main takes one commit and mints one release. The review that happened here still stands; nothing was rewritten on the way in.