app: accept display polish — feed sentence (do now) + row-ladder rung (deferred)

[orveth]

Display follow-ups from #329 (merged at 17e850c), which split ACCEPT onto kind 3406. Neither item produces wrong output — that is why neither blocked the merge.

Item 1 — DO NOW: the feed sentence for an accept is just a pubkey

web/app/js/app.js:141 — feedLine(e) switches on e.stage and has no case "accept", so an accept falls to default: return who and its activity line renders as a bare truncated pubkey. Every other stage has a sentence: "claimed a job", "awarded a claim", "delivered", "paid · receipt co-signed".

Cosmetic, not invisible: the row does render and carries a visible accept tag from KIND_LABELS[3406] (app.js:166), so a reader can see an accept happened — they just get no sentence saying what it was.

One line beside case "award":

case "accept": return `${who} accepted the delivery`;

"accepted the delivery" rather than "authorised payment": the feed ladder reads claimed → awarded → delivered → ? → paid · receipt co-signed, so a line about authorising payment sits directly above "paid" and reads as the settlement itself. "accepted the delivery" names what the buyer did and pairs with "delivered" one rung up.

Item 2 — DEFERRED, by design: no accept rung in the trade row ladder

web/app/js/app.js:215 decides a trade row's displayed stage:

const stage = tr.at.receipt ? "paid" : tr.at.result ? "delivered" : tr.at.award ? "awarded" : tr.at.claim ? "claimed" : …

There is no tr.at.accept rung. An accept follows a delivery, so a trade carrying one already reads "delivered" — correct, just not distinct. A buyer who has verified the work and bound payment to it looks identical to one who has not yet looked at it.

Whether that deserves a rung is a product call, not a correctness one: the ladder is coarse on purpose. If it gets one, it belongs between result and receipt.

Three classes, not two — worth keeping straight

#329 fixed one genuine silent degradation: parseEvent dropped a 3406 to null (model.js:106, default: return null), so the event vanished from the feed entirely and a trade appeared to stall at award with no error.

Neither item above is that. Both render, both are tagged, both emit true output — item 1's sentence is uninformative, item 2's rung is coarse. The distinction is worth writing down because item 1 was initially misclassified as silent degradation and nearly held up a verified money-path PR. The accept tag at app.js:166 is what makes item 1 legible, and that fact sat in the same site enumeration that argued it was invisible. Two true facts in one report are not a join.

The render set, swept — so nobody sweeps it again

Every app site branching on kind or stage, and its status after #329:

• model.js:106 parseEvent — fixed in feat(protocol): split ACCEPT onto kind 3406, so a pay-bind is not an award #329.
• app.js:143 feedLine — item 1 above, still open.
• app.js:215 row ladder — item 2 above, deferred.
• app.js:166 feed row tag, KIND_LABELS[e.kind] + data-s="${e.stage}" — correct, because feat(protocol): split ACCEPT onto kind 3406, so a pay-bind is not an award #329 added KIND_LABELS[ACCEPT]. styles.css has per-stage rules for offer/receipt/feedback only, so an accept tag renders with default styling exactly as award, claim and result already do — matching the baseline, not a gap.
• app.js:297 / :316 event sheet, KIND_LABELS[raw.kind] || "?" — correct, label present. Note this is where a missing label would have rendered a bare ?.
• participants.js:140-158 — branches on HEARTBEAT / HANDLER / RESULT only; about seller participants, so accept does not apply.
• trades.js:39-42 — stage-specific field extraction for offer / receipt / feedback; an accept carries no extra fields to pull.
• trades.js:36, :63, :82 — stage-keyed, and funnel / conversionRates have no accept bucket at all, so an accept cannot inflate awarded.

🤖 Generated with Claude Code