docs(site): /privacy tells the truth about engagement retention again #29

Merged
whitlocktech merged 1 commits from docs/engagement-retention into main 2026-09-01 20:57:28 +00:00
Member

The downstream half of ENGAGEMENT.md Phase 14, which is the phase that made the current text false.

Code: RunicGateway/website#182 · Docs: RunicGateway/docs#205

What was wrong

The deploy-engagement entry in src/data/collection.mjs said:

Kept until the operator removes them; nothing here expires on its own

and, in its detail, "the delivery log, the suppression list and the per-person rate limits have no retention sweep, so they are as long as the site is old."

That was the true answer right up until Phase 14 landed a sweep — and it is exactly the kind of sentence a Play reviewer reads. Phase 12 flagged this as a thing that becomes false the moment retention lands; this is that moment.

What it says now

What the code actually does: a nightly sweep with an operator-settable horizon per table (180 days for the delivery log, 30 for the queue and the rate limits), and the two things that deliberately do not expire

  • an item still waiting to be sent, however old, because it is a message the site still intends to deliver;
  • the suppression list, because ageing an entry out would mean mailing an address that already bounced or asked to be left alone. An operator can remove one deliberately, one at a time.

One inventory, so /privacy and the Play answers cannot drift apart.

PLAY_DATA_SAFETY.md is unchanged, and that is correct

Worth stating because the phase text expected otherwise: deploy-engagement is scope: 'deployment', and the Play answers are generated from the app-scoped entries only — Play asks what the app collects, not what a self-hosted deployment keeps. npm run play:datasafety rewrites the file byte-identically and check:datasafety stays green.

Proof

All ten checks green (facts, tokens, brand, links, datasafety, quickstart, reference, sidebar, a11y, csp) and 42/42 tests. checkFacts verified against main. The built /privacy page renders the new text.


  • AI-assisted: written with Claude Code (Claude Opus), reviewed by the author.
The downstream half of **ENGAGEMENT.md Phase 14**, which is the phase that made the current text false. Code: RunicGateway/website#182 · Docs: RunicGateway/docs#205 ## What was wrong The `deploy-engagement` entry in `src/data/collection.mjs` said: > Kept until the operator removes them; nothing here expires on its own and, in its detail, *"the delivery log, the suppression list and the per-person rate limits have no retention sweep, so they are as long as the site is old."* That was the **true** answer right up until Phase 14 landed a sweep — and it is exactly the kind of sentence a Play reviewer reads. Phase 12 flagged this as a thing that becomes false the moment retention lands; this is that moment. ## What it says now What the code actually does: a nightly sweep with an operator-settable horizon per table (180 days for the delivery log, 30 for the queue and the rate limits), **and the two things that deliberately do not expire** — - an item still waiting to be sent, however old, because it is a message the site still intends to deliver; - the suppression list, because ageing an entry out would mean mailing an address that already bounced or asked to be left alone. An operator can remove one deliberately, one at a time. One inventory, so `/privacy` and the Play answers cannot drift apart. ## `PLAY_DATA_SAFETY.md` is unchanged, and that is correct Worth stating because the phase text expected otherwise: `deploy-engagement` is `scope: 'deployment'`, and the Play answers are generated from the **app-scoped** entries only — Play asks what the *app* collects, not what a self-hosted deployment keeps. `npm run play:datasafety` rewrites the file byte-identically and `check:datasafety` stays green. ## Proof All ten checks green (`facts`, `tokens`, `brand`, `links`, `datasafety`, `quickstart`, `reference`, `sidebar`, `a11y`, `csp`) and 42/42 tests. `checkFacts` verified against `main`. The built `/privacy` page renders the new text. --- - [x] AI-assisted: written with Claude Code (Claude Opus), reviewed by the author.
wtclaude added 1 commit 2026-09-01 20:42:46 +00:00
docs(site): /privacy tells the truth about engagement retention again
All checks were successful
PR checks / checks (pull_request) Successful in 1m23s
82b55e3084
ENGAGEMENT.md Phase 14. The deploy-engagement entry in the collection
inventory said "Kept until the operator removes them; nothing here expires
on its own" and, in its detail, "the delivery log, the suppression list and
the per-person rate limits have no retention sweep, so they are as long as
the site is old". That was the true answer until Phase 14 landed a sweep,
and it is the kind of sentence a Play reviewer reads.

It now describes what the code does: a nightly sweep with an
operator-settable horizon per table (180 days for the delivery log, 30 for
the queue and the rate limits), and the two things that deliberately do NOT
expire — an item still waiting to be sent, because it is a message the site
still intends to deliver, and the suppression list, because ageing an entry
out would mean mailing an address that already bounced.

PLAY_DATA_SAFETY.md is unchanged and check:datasafety stays green:
deploy-engagement is deployment-scoped, and the Play answers are generated
from the app-scoped entries, because Play asks what the app collects rather
than what a self-hosted deployment keeps.

All ten checks green, 42 tests pass.

Co-Authored-By: Claude <noreply@anthropic.com>
whitlocktech merged commit 5f58a4cbf2 into main 2026-09-01 20:57:28 +00:00
whitlocktech deleted branch docs/engagement-retention 2026-09-01 20:57:30 +00:00
Sign in to join this conversation.
No description provided.