A held text's heading names who receives it
The hold approval page said "Text to a resident" for every held text, so the work-order page to the handyman told the approver a renter would get it. The heading now comes off the recipient role the hold already carries. Before and after are two dev servers on propflow-stage, against synthetic holds on the stage test building.
27 Oct 2026 · branch held-message-recipient-label · captured against propflow-stage · at b490db2eb38+local
Data note. Every name and balance below comes from propflow-stage, which is anonymized by construction (ADR-0097/0110 — phones in the impossible +1000 NPA, emails @example.test). The identical capture against prod would carry real tenants' names and balances and is not safe to attach anywhere, which is why the generator refuses to run against one.
1 · BEFORE, on main — the handyman page says "a resident"
The automatic work-order page to the handyman, held because Maintenance is supervised here (source: 'maintenance_vendor_sms'). A held text has no subject line, so this heading is the only thing saying who receives it — and on main it is the literal 'Text to a resident', whatever the hold is. Read it against the draft below: those words are for whoever fixes the faucet.
Asserted in the captured DOM — Text to a resident · Would go to. The old literal is asserted on main, so the before is a measurement and not a recollection.
Sections 2–4 and notes
2 · AFTER, on the branch — the same hold names the handyman
Same hold, same draft. The heading now comes off the hold's own source, through the one source-to-audience table the approval queue's "to" column already read.
"a handyman or vendor", not "the handyman", on purpose: source records only that the text is not for the resident, and the assigned tech is the company's own handyman on a page and an outside vendor's on a relay. Naming one would be a fabricated fact half the time.
Asserted in the captured DOM — Text to a handyman or vendor · Would go to. The new heading is in the captured DOM in the state the screenshot shows — not just in the diff.
3 · CONTROL — the resident twin of the same sender still reads "a resident"
The resident-facing half of the same work order is unchanged — right before, right now. Only the holds whose recipient was being misnamed moved.
Asserted in the captured DOM — Text to a resident · Would go to. A resident hold is untouched by the change, asserted on the branch.
4 · At phone width — the longer heading still sits on one line
The old heading was 19 characters; the longest this change can produce is about 30 (Text to the renewals reviewers). At 390px the widest realistic label holds one line and nothing below it moves.
Asserted in the captured DOM — Text to a handyman or vendor · Would go to. The same heading, asserted again at 390px — a responsive claim nobody has to take on trust.
What the captures prove, and what they do not
Before and after are the same route against the same stage row on two servers, so the heading is the only thing that moved, and the before section would have failed the run if main had not actually said "a resident".
Not reached here: the eight other roles, and the hold whose stored source this build cannot place — which renders the neutral "Text message" instead of falling back to "a resident". Those are covered by HeldMessageView.heading.test.tsx, which renders the real view per role and fails on main.
Both holds are synthetic fixtures on the stage test building, phones in the impossible +1000 area code. Nothing here can reach a person.