Approve an application from Telegram

Steps

1. 1 None Offstage: a promoter fills in the public form and is asked to confirm their email 0:01
2. 2 None Offstage: they confirm — the application files itself 0:02
3. 3 Venue Manager It lands on the intake board 0:30 ▣

   Submitting also emailed the host and pushed a staff card to Telegram — neither of which anyone had to ask for.

4. 4 Administrator Open the Telegram console 0:49 ▣

   Adapter mode MOCK: offline, deterministic, and every call recorded in `outbound_calls`. The live adapter records exactly the same rows — the console cannot tell you a comfortable lie about what was sent.

5. 5 Administrator The card that went out, on the wire log 0:51 ▣

   One `send_message`, three buttons, and the chat it was addressed to. The recorded request is what actually went on the wire, so in live mode this row shows the RESOLVED chat id and any rewritten button URL.

6. 6 Administrator Offstage: reading the recorded card off the wire log 0:52
7. 7 Administrator The ✅ button carries a single-use token, not an application id. 0:59

   `intake:a:<token>` — 72-hour TTL, hashed at rest (only the recorded Telegram payload ever holds the plaintext), and burned by the first press. Approving and declining are different tokens.

8. 8 Venue Manager The manager is still looking at the application 1:12 ▣

   Status `new_submission`. Nothing on this page is about to be clicked.

9. 9 Venue Manager Telegram delivers the button press to /webhooks/telegram 1:14

   Secret header checked with hmac.compare_digest, `update_id` claimed in its own committed transaction, then the SAME handler registry the simulator uses. Fails closed: no secret configured means no row, no dispatch, no answer.

10. 10 Venue Manager Reload: approved, and nobody touched this screen 1:17 ▣
11. 11 Venue Manager Telegram retries the same update 1:18

    Telegram retries until it gets a 2xx, so the same press arrives more than once. The `update_id` is already claimed, so this answers 200 with the ORIGINAL result and runs nothing — the token is not double-spent and the state machine is never asked for approved → approved.

12. 12 Administrator Back on the console 1:23

    Approving edited the original card to `— ✅ ACCEPTED via Telegram` and swapped its dead accept/decline buttons for whatever is actionable next, so the chat never shows a button that no longer does anything.

13. 13 Administrator Every delivery, with what it did 1:24 ▣

    `telegram_inbound_updates` is what says a press came off the WIRE: `inbound_webhooks.source` is `simulated` for both a real delivery and a replay, so provenance lives here and in the payload's `delivery: telegram_webhook`. The retry is absent — it was refused before it could become a second row.