docs(troubleshooting): suppression and bounces (engagement Phase 9) #25

wtclaude · 2026-08-31T15:50:38Z

wtclaude commented

2026-08-31 15:50:38 +00:00

The operator-facing half of engagement Phase 9 (RunicGateway/website#176 + RunicGateway/docs#191), which ENGAGEMENT.md §6.0b assigns to this repo.

Two new sections in troubleshooting.mdx, split along the line that actually matters when somebody reports it.

"One person stopped receiving email"

The suppression case, and the three things an operator gets wrong about it:

They can still reset their password. Suppression scopes to engagement rules only, so "no notifications but resets work" is the expected shape of this problem rather than a contradiction that sends someone hunting elsewhere.
Not sent / Bounced / Failed mean three different things, and only one of them is about your configuration.
No row at all means they were excluded before anything was queued — an opt-in, or the verification gate.

It also explains that lifting a suppression asks for the full address because addresses are stored one way, so that reads as the privacy design rather than a missing feature.

"Everyone stopped receiving email at once"

This one exists to stop the wrong reflex. A whole-deployment stop is never the suppression list — a wrong password never suppresses anybody, only the receiving server naming a specific dead mailbox does — and it says so before an operator starts clearing rows.

Checks

checkLinks, checkSidebar, checkQuickstart, checkReference, checkA11y, checkCsp, checkBrand, checkFacts and npm test (42 pass) all green. The three token-gated checks were run with GITEA_TOKEN set.

checkFacts is green because it reads main, which is the sequencing trap Phase 12 owns — nothing here changes that.

AI disclosure

Written with Claude Code (Claude Opus 5); the commit carries Co-Authored-By: Claude.

The operator-facing half of engagement **Phase 9** (RunicGateway/website#176 + RunicGateway/docs#191), which `ENGAGEMENT.md` §6.0b assigns to this repo. Two new sections in `troubleshooting.mdx`, split along the line that actually matters when somebody reports it. ## "One person stopped receiving email" The suppression case, and the three things an operator gets wrong about it: - **They can still reset their password.** Suppression scopes to engagement rules only, so "no notifications but resets work" is the *expected shape* of this problem rather than a contradiction that sends someone hunting elsewhere. - **Not sent / Bounced / Failed mean three different things**, and only one of them is about your configuration. - **No row at all** means they were excluded before anything was queued — an opt-in, or the verification gate. It also explains that lifting a suppression asks for the full address because addresses are stored one way, so that reads as the privacy design rather than a missing feature. ## "Everyone stopped receiving email at once" This one exists to stop the wrong reflex. A whole-deployment stop is **never** the suppression list — a wrong password never suppresses anybody, only the receiving server naming a specific dead mailbox does — and it says so *before* an operator starts clearing rows. ## Checks `checkLinks`, `checkSidebar`, `checkQuickstart`, `checkReference`, `checkA11y`, `checkCsp`, `checkBrand`, `checkFacts` and `npm test` (42 pass) all green. The three token-gated checks were run with `GITEA_TOKEN` set. `checkFacts` is green because it reads `main`, which is the sequencing trap Phase 12 owns — nothing here changes that. ## AI disclosure Written with **Claude Code** (Claude Opus 5); the commit carries `Co-Authored-By: Claude`.

wtclaude added 1 commit 2026-08-31 15:50:40 +00:00

docs(troubleshooting): suppression and bounces (engagement Phase 9) 7709b055a4

ENGAGEMENT.md §6.0b assigns this repo the operator-facing half of Phase 9
(website#176 + docs#191). Two new sections, split along the line that actually
matters when somebody reports it.

"One person stopped receiving email" is the suppression case, and the three
things an operator gets wrong about it: they can still reset their password
(suppression scopes to engagement rules only, so that is the expected shape of
the problem rather than a contradiction); Not sent, Bounced and Failed in the
Send Log mean three different things and only one of them is about your
configuration; and no row at all means they were excluded before anything was
queued, by an opt-in or by the verification gate.

"Everyone stopped receiving email at once" exists to stop the wrong reflex. A
whole-deployment stop is never the suppression list — a wrong password never
suppresses anybody, only the receiving server naming a specific dead mailbox
does — and it says so before an operator starts clearing rows.

Also notes that lifting a suppression asks for the full address because
addresses are stored one way, so it reads as the privacy design rather than a
missing feature.

Co-Authored-By: Claude <noreply@anthropic.com>

whitlocktech merged commit 916921551f into edge

2026-08-31 15:53:26 +00:00

whitlocktech deleted branch docs/engagement-deliverability

2026-08-31 15:53:27 +00:00

whitlocktech referenced this issue from a commit

2026-08-31 15:53:28 +00:00

Merge pull request 'docs(troubleshooting): suppression and bounces (engagement Phase 9)' (#25) from docs/engagement-deliverability into edge

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/runicgateway.com#25