docs(engagement): widen Phase 10 to three wire enrichments and Phase 11 to the full trigger catalogue

Two scope decisions taken by the org lead on 2026-08-31, before any Phase 10 code,
plus the three factual corrections that finding them out produced.

Phase 10 — the protocol bump now carries three enrichments, not one. The argument is
specific to this phase: a bump costs a sidecar release, a republished bundle and an
operator update on every shard, so a field left out does not cost a follow-up commit,
it costs a second bump with the same lead time and a split operator population. The
two additions:

  * player-vendor fee state on vendor.listing (ownerAcct, holdGold, chargePerDay,
    daysRemaining), because uo.vendor.expiring is the same "owned asset at risk with
    a deadline" shape as the flagship and today has neither an address nor a deadline;
  * a post-decision account.login.result, because EventSink.AccountLogin is a veto
    hook that fires BEFORE the auth decision.

Moving vendor.sale out of the opt-in patch tier was explicitly declined.

Phase 11 — ships every checked row of 8.6 rather than a single rule, carving out
uo.market.item_listed (a saved search; no per-user query store exists). ~23 triggers
grouped by the audience kind each family exercises, since exercising the ceiling
lattice at scale is the point rather than volume of mail. Every rule still ships
enabled = 0 per Q3. Notes that the phase will likely want an 11a/11b split on the
4a/4b precedent, to confirm at its start.

Three corrections to 8.6, each verified against the emitters rather than the table:

  * uo.vendor.sale is real and does carry ownerAcct, but lives in servuo-plugins/
    patches/ (opt-in, verified only against ServUO 57.4) — dormant, not broken, on a
    shard that declined the tier;
  * uo.vendor.expiring had no data at all, not merely no mapper — vendor.listing
    carries ownerSerial/ownerName and nothing carries held gold or daily charge;
  * uo.account.login_attempt could not have been built as described — it would have
    mailed "someone tried to log into your account" on every successful login.
    Renamed uo.account.login_failed so the id cannot be misread again.

Also amended: the status header, scope decision 3, and 6.0b's documentation
assignment for rows 10 and 11 (v5.md now earned; the patch-tier caveat is an
operator-facing doc obligation; runicgateway.com's capability claim changes when
"one rule" becomes "the catalogue").

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

android/PLAN.md

@@ -759,6 +759,18 @@ Mirrors the website's "degrade gracefully" invariant:
   loading/error/retry states; it does **not** ship a Room cache in v1. Cached read-only content can be
   added later without reworking the repository layer (its typed results already isolate the UI from the
   data source). No `Room` dependency in the initial build.
+- **Amended 2026-08-31 (engagement Phase 8): one named exception, and still no Room.** The in-app
+  inbox keeps an offline snapshot - `core/inbox/InboxCache`, one JSON blob in the DataStore the push
+  code already uses, capped at the server's own default page size. An inbox is a short, read-only,
+  newest-first list with a server-side cursor and no joins, so what "works offline" needs is the
+  newest page and the badge, not a database. **Every snapshot is scoped to (base URL, user id)** and
+  handed back only to that pair, which is what stops one account's notifications surfacing under
+  another's session on the teardown paths that never reach a logout (a dead refresh token, a server
+  switch); the clear-on-logout beside the push deregistration is the tidy-up, not the safeguard.
+  **The known limit: this serves a running app, not a cold start.** `MainActivity` gates the whole of
+  `RunicApp` on loading the site's appearance, so an offline launch still shows the shell's "Can't
+  reach the site / Retry" and never reaches the drawer. Changing that is a change to the shell's
+  startup model, and it was left for the org lead rather than widened into Phase 8.
 
 ---
 
@@ -1307,9 +1319,48 @@ Four properties the UI should be built on rather than around:
 `ceiling` is `staff` is not offered to a non-staff caller — it can never reach them, and listing it
 would disclose that the event exists. `GET /notifications/streams` is unfiltered and unchanged.
 
-**Phase 8** (`ENGAGEMENT.md`) is where the app grows the in-app inbox and this screen gains the
-per-channel toggles. Until then the existing per-stream screen keeps working against
-`/notifications/subscriptions` unmodified.
+### The inbox and the per-channel screen - as built (engagement Phase 8, 2026-08-31)
+
+**The drawer's "Notifications" is the INBOX now**, and the preferences are one tap away behind its
+gear - the arrangement Phase 7 shipped on the web (`/account/notifications` is the content,
+`.../settings` the preferences), and what a person means when they tap the word. `Routes.NOTIFICATIONS`
+is unchanged and `Routes.NOTIFICATIONS_SETTINGS` is new, so an admin's nav override pointing at the
+old route still lands somewhere sensible.
+
+**The inbox** (`ui/notifications/InboxScreen` + `InboxViewModel`) reads the four routes Phase 7
+shipped: a keyset page on `before` (never an offset - the list gains rows at the top while it is being
+read), the unread count that rides along on every page, and the two mark-read writes. Reads are
+optimistic and deliberately not rolled back on failure; a local read also rewrites the snapshot, or
+going offline right after reading everything would bring the badge back on the next cold open. The
+drawer badge has its own view model on `/notifications/unread-count`, refreshed on resume rather than
+on a timer - the tickle is what says "something happened", so polling would be a second, worse copy
+of push.
+
+**Two things the app has to do that the backend contract does not state:**
+
+- **Resolve the item's `url`.** Phase 7 specifies it is **relative-only** (`/guilds/.../forum/403`),
+  which is right for a browser already on the site and a dead link on a phone.
+  `InboxViewModel.linkFor` resolves it against the configured base with OkHttp's `HttpUrl.resolve`,
+  which absolutises the path *and* returns null for anything that would not end up http(s) - so a
+  `javascript:` or `intent:` url in a notification body opens nothing. The live rig is what caught
+  this: the first cut only opened `http(s)`-prefixed strings, so every link in the inbox did nothing
+  at all.
+- **Route the tickle on its `ref`, not its stream.** An engagement rule's tickle carries the TRIGGER
+  id as `stream` (ENGAGEMENT.md section 7.2's one namespace) and `PushStreams` knows only the eight
+  push streams, so `team.forum.post` would have landed on Home. `Routes.forTickle(stream, ref)` sends
+  anything whose ref starts with `notification:` to the inbox and leaves every other tickle on the
+  route it has always had. The ref is never decoded past that prefix and never rendered - it is a hint
+  that a row exists, and the contract stays wake-and-pull.
+
+**The settings screen** (`NotificationSettingsScreen` + `NotificationSettingsViewModel`) moved off
+`/notifications/subscriptions` onto `/notifications/channels`. Controls are rendered from the wire:
+one row per subscribable id, a control per channel in **that item's** `channels`, and its shape from
+**that channel's** `modes` - a switch for two modes, chips for three, so email's `digest` reaches the
+app and a fourth channel would too, without a release. A trigger-only id shows no push control rather
+than a dead switch, and on a shard with no push relay the push controls are absent with the reason in
+a note beside the list (email and on-site preferences are still worth setting there). Each change is
+one sparse PUT of one pair, and the screen re-renders from the response, so an entry the server drops
+shows up as the control springing back.
 
 ## 12. Build & CI (Gitea Actions)
 

website/TEAMS.md

@@ -1595,8 +1595,13 @@ function in `model/teams/teamNotify.db.js` that returns an unfiltered recipient
 would be a refactor away from being used.
 
 **As built**, the column is `email_mode ENUM('off','digest','immediate') NOT NULL DEFAULT 'off'` plus
-a `last_digest_at DATETIME NULL` (the digest's only state, see §6.4), and it is surfaced in two
-places:
+a `last_digest_at DATETIME NULL`, and it is surfaced in two places:
+
+> **`last_digest_at` is no longer read** (engagement Phase 6). The digest's state moved to
+> `engagement_digest_state`, keyed `(user_id, channel, scope_key)` so a second digest needs no second
+> column here; `schema.sql` backfills it once. The column stays as the backfill's source and as the
+> record of what a row meant before the migration. **The two preference columns are unchanged and are
+> still the authority for Team notifications** — the engine reads them rather than replacing them.
 
 - **`/account/notifications`**, a new core page in the player portal — stream subscriptions, the
   per-Team mute list, and the email mode per Team. `GET|PUT /auth/me/notifications/teams`; the `teams`
@@ -1608,7 +1613,7 @@ places:
   which is a privacy property and not a tidiness one: whether a preference *exists* for a Team answers
   "is this person in it", and the guild page is public.
 
-### 6.4 Email — the third sink, already built and unused
+### 6.4 Email — the third sink
 
 Push needs the Android app. The Discord bridge (§7.2) needs Discord. **A web-only user on a deployment
 running neither currently gets no notification that someone replied to their own thread** — which is
@@ -1618,47 +1623,120 @@ Core already has `utils/mailer.js` and an admin-configured `email_config`. The e
 notifications is computing the recipient set, and §6.2 builds it; email is a **third consumer of the
 same event**, not a fourth pipeline.
 
-- Same recipient computation, same per-Team mute, same suppression while `teams_forums_enabled` is off.
-- **Unlike a push tickle, an email carries content** — the same reasoning as the Discord bridge
-  (§7.2): the recipient's mailbox is a destination they chose, not an untrusted relay reached by an
-  unguessable topic. It carries the thread title, an excerpt and a link; never the full post.
+> **Rewritten 2026-08-29 — the engagement system's Phase 6 took this sink over.** Everything below the
+> line still describes what a recipient receives; what changed is who decides to send it. The design of
+> record for the mechanism is now `docs/website/ENGAGEMENT.md` (Phase 6 as built), and this section is
+> the Teams-shaped view of it. **Do not re-specify the engine here** — the same rule §6.0b applies to
+> every other doc that touches a contract it does not own.
+
+#### What moved, and what did not
+
+`teamNotify.js` had three sinks. **One moved:**
+
+| Sink | Where it lives now |
+| --- | --- |
+| The content-free push tickle | still `teamNotify.js`, unchanged. Its `deliver` on the engine is the engagement Phase 7's, with the in-app inbox that gives a tickle a `ref` worth deep-linking |
+| The Discord bridge (§7.2) | still `teamNotify.js`, unchanged. A bridge is a *leg* — one-shot, to whoever can read a channel — and not a per-recipient *channel*; `ENGAGEMENT.md` §3.1 argues that distinction and it holds here |
+| **Email** | **the engagement engine.** `teamNotify.forumPost` emits `team.forum.post` / `team.announcement`; a rule decides who is mailed, through which template, how often at most |
+
+`mailer.sendTeamNotification` and `teamNotify.emailImmediate` no longer exist. The mail body is an
+`engagement_templates` row an operator can edit (`notify.team-post` for a post, `notify.digest` for the
+digest, `notify.event` for the two roster events and for announcements).
+
+#### The four properties this section always claimed, and where each one lives now
+
+- **Same recipient computation, same per-Team mute, same suppression while `teams_forums_enabled` is
+  off.** All three still hold, and the first is now explicit rather than incidental:
+  `teamNotify.recipientIds` computes the access-checked set and it travels on the event envelope as
+  `recipientUserIds`. A rule whose audience is `members` resolves to exactly that set — still filtered
+  for `users.status = 'active'`, still under the trigger's ceiling. Core does not learn what a Team is;
+  the event says who it is about.
+- **Unlike a push tickle, an email carries content** — the same reasoning as the Discord bridge (§7.2):
+  the recipient's mailbox is a destination they chose, not an untrusted relay reached by an unguessable
+  topic. It carries the thread title, an excerpt and a link; never the full post.
+- **The per-Team preference is unchanged and is still the authority.** `team_notification_prefs` stays
+  exactly where it is, with exactly the meaning §6.3 gives it. The engine reads it through a
+  **scoped-preference** adapter: for a Team-scoped event that table *is* the preference, `muted`
+  silences every channel, and `email_mode` decides email and says nothing about the others. The
+  alternative — intersecting it with the newer per-stream preference — would have silenced every
+  existing subscriber on the migrating deploy, because nobody has ever expressed a stream-level opinion
+  about a Team trigger. The argument in full is in ENGAGEMENT.md Phase 6.
+- **Off unless email is configured.** No usable `email_config` means the sink is absent, not broken —
+  and as of Phase 6 there is a second gate above it, below.
+
+#### **Team email is OFF until an operator turns it on**
+
+This is the one live behaviour change and it is deliberate. An engagement rule arrives `enabled = 0` so
+that no import, restore or upgrade can start mailing on its own, and core seeds four Team rules under
+that same rule. **On upgrade, Team notification emails stop until somebody opens Admin → Engagement →
+Rules and switches one on.** The screen carries a banner saying so for as long as every Team rule is
+off; the release note says it too. Push and the Discord bridge are unaffected.
+
+#### The digest
+
+**Computes at send time and keeps no queue.** The worker asks what arrived after the last stamp and
+re-runs the access resolver. Three properties fall out, and the third is why it was chosen over a
+pending-items table — and, in Phase 6, over the engine's own outbox:
+
+1. a deployment down for two days sends **one** correct digest rather than replaying a backlog;
+2. a post a moderator hid after it was written is simply not in the query;
+3. **a user who lost forum access between the post and the send is no longer in the recipient set**, so
+   they are not emailed content they can no longer read.
+
+`since` is clamped to at most seven days so a long outage cannot produce one enormous mail, and the
+stamp is written **only on a successful send** — stamping first would quietly eat a day of somebody's
+notifications every time the mail provider had a bad minute.
+
+**What Phase 6 changed is the state, not the design.** The stamp moved from
+`team_notification_prefs.last_digest_at` into `engagement_digest_state`, keyed
+`(user_id, channel, scope_key)`, backfilled once by `schema.sql`. A digest-mode recipient gets **no
+outbox row** — a row would carry a snapshot taken at publish time and would have none of the three
+properties above. The worker is also gated on an enabled email rule, so switching Team email off
+switches off both halves of it rather than the instant half only.
+
 - **Digest, not per-event, when email is on at all.** A busy Team forum sending one email per reply is
   how a notification feature gets marked as spam. `email_mode ENUM('off','digest','immediate')` in
   `team_notification_prefs`.
   > **As built, the default is `off` and not `digest`** (org lead, 2026-08-18): digest-by-default
-  > would start mailing every member of every Team the moment an operator connects Gmail. Email is
-  > the one opt-IN sink here. Push stays opt-out, because a mute silences something the user already
-  > has.
-- **The digest computes at send time and keeps no queue** (as built). The only state is
-  `last_digest_at`; the worker asks what arrived after it and re-runs the access resolver. Three
-  properties fall out, and the third is why it was chosen over a pending-items table: a deployment
-  down for two days sends **one** correct digest rather than replaying a backlog; a post a moderator
-  hid after it was written is simply not in the query; and **a user who lost forum access between the
-  post and the send is no longer in the recipient set**, so they are not emailed content they can no
-  longer read. `since` is clamped to at most seven days so a long outage cannot produce one enormous
-  mail, and `last_digest_at` is stamped **only on a successful send** — stamping first would quietly
-  eat a day of somebody's notifications every time the mail provider had a bad minute.
-- **Roster events do not email** (as built). `team.member.joined` and `team.leadership.changed`
-  tickle and stop there; only `team.forum.post` and `team.announcement` reach this sink.
-- **Off unless email is configured.** No `email_config` row means the sink is absent, not broken.
-- One-click unsubscribe link honouring the same per-Team mute, so an unsubscribe from the mail client
-  writes the preference the site shows.
-  > **As built: a stateless HMAC over `(version, userId, teamId)`, not a token table.** Every property
-  > that makes a password-reset token a row is absent here — the link sits in a mailbox for months so
-  > it has no useful expiry, and clicking it twice must mean what clicking it once meant. The
-  > capability it carries is deliberately the narrowest that does the job: set `muted` for **one**
-  > (user, Team) pair. It reads nothing, cannot un-mute, and names no other Team. `version` is the
-  > only revocation a stateless design can offer — bumping it invalidates every outstanding link at
-  > once — and it exists before it is needed rather than after.
-  >
-  > **Two URLs come out of one token, and they are not interchangeable.** The mail *body* carries the
-  > site's own `/unsubscribe/:token` page, which POSTs once a human is looking at it. The
-  > `List-Unsubscribe` *header* carries `POST /api/v1/public/teams/unsubscribe/:token`, because RFC
-  > 8058 lets a client POST to it without rendering anything. **A GET on the API path redirects and
-  > does not act** — a mail client's link scanner would otherwise silently mute Teams nobody asked to
-  > leave. The endpoint answers `200` whatever the token was: a response that distinguished a valid
-  > token from a forgery would be an oracle for which (user, Team) pairs exist, on a surface with no
-  > session behind it.
+  > would start mailing every member of every Team the moment an operator connects a mail transport.
+  > Email is the one opt-IN sink here. Push stays opt-out, because a mute silences something the user
+  > already has.
+- **Roster events do not email by default** (as built, restated by Phase 6). `team.member.joined` and
+  `team.leadership.changed` do now *emit*, so an operator who wants that mail can have it — but the
+  rules that would send it are seeded disabled and carry an hour-long cooldown, so §6.4's original
+  argument survives as the default rather than as a sink the code declines to call.
+
+#### One-click unsubscribe
+
+A link honouring the same per-Team preference, so an unsubscribe from the mail client writes what the
+site shows.
+
+> **A stateless HMAC, not a token table.** Every property that makes a password-reset token a row is
+> absent here — the link sits in a mailbox for months so it has no useful expiry, and clicking it twice
+> must mean what clicking it once meant. The capability is deliberately the narrowest that does the
+> job: turn **one channel** off for **one scope** for one account. It reads nothing, cannot turn
+> anything back on, and names no other scope. `version` is the only revocation a stateless design can
+> offer — retiring one invalidates every outstanding link of it at once — and it exists before it is
+> needed rather than after.
+>
+> **Phase 6 generalized the token from `(userId, teamId)` to `(userId, channel, scopeKey)`, and
+> narrowed what it does.** A v1 token set `muted`, which silenced that Team's *push* as well as its
+> email — a link labelled "stop these emails" quietly stopping notifications on somebody's phone. A
+> token now turns off the channel it names and nothing else. **Old tokens still verify, permanently**,
+> and read as the email channel for that Team, which is a reading of what they always meant.
+>
+> **Two URLs come out of one token, and they are not interchangeable.** The mail *body* carries the
+> site's own `/unsubscribe/:token` page, which POSTs once a human is looking at it. The
+> `List-Unsubscribe` *header* carries `POST /api/v1/public/engagement/unsubscribe/:token`, because RFC
+> 8058 lets a client POST to it without rendering anything. **A GET on the API path redirects and does
+> not act** — a mail client's link scanner would otherwise silently unsubscribe people who asked for
+> nothing. The endpoint answers `200` whatever the token was: a response that distinguished a valid
+> token from a forgery would be an oracle for which (user, scope) pairs exist, on a surface with no
+> session behind it.
+>
+> **`POST|GET /api/v1/public/teams/unsubscribe/:token` still exists and always will.** It hands
+> straight to the same handlers. Mail sent before Phase 6 carries that path in its header and in its
+> body, mail is not editable once sent, and a route that moves is a person who cannot unsubscribe.
 
 Folded into **Phase 6** rather than getting a phase of its own: the recipient set is the work, and it
 is already being built there.