RunicGateway/docs
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(engagement): Phase 14 as built — retention #205

Merged
whitlocktech merged 2 commits from docs/engagement-phase-14 into main 2026-09-01 20:56:26 +00:00
Conversation 0 Commits 2 Files Changed 2 +139 -10
wtclaude commented 2026-09-01 20:42:27 +00:00
Member
Copy Link

The documentation half of ENGAGEMENT.md Phase 14 — the last phase of the workstream.

Code: RunicGateway/website#182 · Site: RunicGateway/runicgateway.com#TBD

website/ENGAGEMENT.md

  • Phase 14's status goes from scoped, not started to BUILT, and the document header from "the workstream is BUILT, CUT OVER and ACCEPTED" to COMPLETE.
  • A new Phase 14 as built subsection: the six org-lead decisions (and which two of them widened the phase), what was built, three findings, the acceptance line discharged item by item, and one rig trap.
  • The header's "and that still holds for Phase 14" now records that its decisions were settled on 2026-09-01 before any code.

website/BACKEND_DESIGN.md

A new Engagement retention section carrying the reference: the horizon table for all four tables, why the outbox sweep is terminal-only, why each floor is a correctness bound rather than a UI nicety, why suppressions do not expire, why this retention worker got a screen when team_activity's and user_notifications' did not, and the reclaimStale defect the sweep depended on. Plus the three new routes in the admin table and the address_hash reversal on GET /suppressions.

Three findings worth not re-deriving

  1. The per-row purge could not be built without reversing a Phase 9 decision. The suppressions list deliberately stripped address_hash, so the row had no handle and the only way out was a prompt asking the operator to retype an address the screen has never shown them.
  2. reclaimStale could not give up, so an interrupted send never reached a terminal status and no retention sweep could ever have bounded the outbox. The bound depended on fixing it.
  3. The cooldown warning is unreachable through the UI by construction (MAX_COOLDOWN_SECONDS is smaller than the horizon's floor). It is not dead code: it catches a hand-edited row and a future raise of that ceiling.

And one the phase text had wrong in the other direction: the Play Data Safety answers correctly did not move, because deploy-engagement is deployment-scoped and PLAY_DATA_SAFETY.md is generated from the app-scoped entries only — Play asks what the app collects, not what a self-hosted deployment keeps.

  • AI-assisted: written with Claude Code (Claude Opus), reviewed by the author.
The documentation half of **ENGAGEMENT.md Phase 14 — the last phase of the workstream**. Code: RunicGateway/website#182 · Site: RunicGateway/runicgateway.com#TBD ## `website/ENGAGEMENT.md` - Phase 14's status goes from *scoped, not started* to **BUILT**, and the document header from *"the workstream is BUILT, CUT OVER and ACCEPTED"* to **COMPLETE**. - A new **Phase 14 as built** subsection: the six org-lead decisions (and which two of them widened the phase), what was built, three findings, the acceptance line discharged item by item, and one rig trap. - The header's *"and that still holds for Phase 14"* now records that its decisions were settled on 2026-09-01 before any code. ## `website/BACKEND_DESIGN.md` A new **Engagement retention** section carrying the reference: the horizon table for all four tables, why the outbox sweep is terminal-only, why each floor is a correctness bound rather than a UI nicety, why suppressions do not expire, why *this* retention worker got a screen when `team_activity`'s and `user_notifications`' did not, and the `reclaimStale` defect the sweep depended on. Plus the three new routes in the admin table and the `address_hash` reversal on `GET /suppressions`. ## Three findings worth not re-deriving 1. **The per-row purge could not be built without reversing a Phase 9 decision.** The suppressions list deliberately stripped `address_hash`, so the row had no handle and the only way out was a prompt asking the operator to retype an address the screen has never shown them. 2. **`reclaimStale` could not give up**, so an interrupted send never reached a terminal status and *no* retention sweep could ever have bounded the outbox. The bound depended on fixing it. 3. **The cooldown warning is unreachable through the UI by construction** (`MAX_COOLDOWN_SECONDS` is smaller than the horizon's floor). It is not dead code: it catches a hand-edited row and a future raise of that ceiling. And one the phase text had wrong in the other direction: the **Play Data Safety answers correctly did not move**, because `deploy-engagement` is deployment-scoped and `PLAY_DATA_SAFETY.md` is generated from the app-scoped entries only — Play asks what the *app* collects, not what a self-hosted deployment keeps. --- - [x] AI-assisted: written with Claude Code (Claude Opus), reviewed by the author.
wtclaude added 1 commit 2026-09-01 20:42:29 +00:00
docs(engagement): Phase 14 as built — retention fdd5bf36f7 
The last phase of the workstream. ENGAGEMENT.md gets Phase 14's as-built
(the six org-lead decisions, three findings, the acceptance line discharged
and one rig trap), and its header now reads COMPLETE rather than "Phase 14
is scoped and not started".

BACKEND_DESIGN.md gets the reference: a new "Engagement retention" section
with the horizon table, why the outbox sweep is terminal-only, why each
floor is a correctness bound rather than a UI nicety, why suppressions do
not expire, and why this one got a screen when team_activity and
user_notifications did not. Plus the three new routes in the admin table and
the address_hash reversal on GET /suppressions.

Three findings worth not re-deriving:

  * the per-row purge could not be built without reversing Phase 9's
    decision to strip address_hash — the row had no handle, and the existing
    lift asks for an address the screen has never shown.
  * reclaimStale could not give up, so an interrupted send never became
    terminal and no retention sweep could ever have bounded the outbox.
  * the cooldown warning is unreachable through the UI by construction
    (MAX_COOLDOWN_SECONDS is smaller than the horizon's floor). It is not
    dead: it catches a hand-edited row, and a future raise of that ceiling.

And one the phase text got wrong in the other direction: the Play Data
Safety answers correctly did NOT move, because deploy-engagement is
deployment-scoped and PLAY_DATA_SAFETY.md is generated from the app-scoped
entries only.

Code: website#TBD.

Co-Authored-By: Claude <noreply@anthropic.com>
wtclaude added 1 commit 2026-09-01 20:43:05 +00:00
docs(engagement): name Phase 14's three PRs 5069218c14 
Co-Authored-By: Claude <noreply@anthropic.com>
whitlocktech merged commit bebf64376e into main 2026-09-01 20:56:26 +00:00
whitlocktech deleted branch docs/engagement-phase-14 2026-09-01 20:56:26 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
bug
Something is not working
duplicate
This issue or pull request already exists
enhancement
New feature
help wanted
Need some help
invalid
Something is wrong
question
More information is needed
wontfix
This won't be fixed
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
ksfixitman whitlocktech wtclaude
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: RunicGateway/docs#205
No description provided.
Delete Branch "docs/engagement-phase-14"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?