max / makenotwork

Alerts that repeat until someone confirms they read them Some messages must be seen, not merely sent. A single email that landed in spam is indistinguishable from one that landed and was ignored, and for a few alerts that difference is the whole point. The first case, and the one that prompted this: a creator's Stripe account changes settlement currency. Every price they have already set is stored as a plain number, so a price that was 10 GBP is now 10 EUR. Nothing here converts it, because guessing an exchange rate on someone's behalf is not ours to do, and only they can decide the new numbers. Until now that fired a wam ticket and said nothing at all to the creator, on the grounds that no mechanism existed for a message that keeps asking. The shape: a caller opens a row, the scheduler sends it and keeps sending it weekly, and pressing the button on the linked page stops it. Nothing sends from the opening call, so the first message and the repeats travel one path and cannot drift apart, and a caller that forgets to send still gets the alert delivered. Four things worth knowing about the design: Acknowledging takes a POST. Email verification gets away with acting on a bare GET; this must not. The entire value of the row is evidence a person read the message, and prefetchers and corporate mail scanners follow GETs. A bare GET would record attention that never happened, which is worse than recording nothing: it would silence exactly the alerts nobody read. The link token is derived, not stored. An alert is mailed up to four times over a month and every copy should keep working. A random token would have to be re-minted per send, killing last month's link, or held in plaintext so later sends could reproduce it. An HMAC over the row's own identity avoids both, and it is the same construction the unsubscribe links already use. It escalates rather than nagging forever. After four unanswered messages the sending stops and a wam ticket asks a person to make contact. A loop that runs for a year unattended is not an alert, it is a filter rule. It runs every tick, not daily. The weekly cadence is in the query's WHERE; how often the job wakes decides only how long something waits before the first message about it, and a day of that is too long when the alert is that a catalogue is mispriced right now. The mail is a new OperationalKind. Unopt-outable by definition, and the narrowest kind of that, because the recipient ends it themselves. Verified against a scratch database with every migration applied: open is idempotent while unacknowledged, an acknowledged row stops being due and stops blocking a fresh occurrence of the same thing, the week boundary is where it should be, and the kind constraint rejects what the enum cannot name.