wtclaude
285db0baa7
Registers the engagement set R7 put in v1: thirteen triggers, four push streams, three audiences, four bodies (two triggers, email and in-app) and thirteen disabled rules in seven groups (PLAN.md §25, D59-D68). The raid alert goes to everyone authorised on the tool cupboard, one emit per linked person with ownerUserId, so the owner ceiling holds per emit. It covers doors and walls (protocol 7), never names the raider, alerts nobody when there is no cupboard, and carries ownerOnline so "offline only" is the seeded rule's condition rather than code. The fan-out runs off ingest before a frame is applied, since applying a disband deletes the roster the notice is sent to. A replayed event is told only while it is news: 15 minutes for broadcasts, 24 hours for personal and staff events. Dedupe keys come from the event, not the sidecar's row id. Server online/offline and a new kills leader are in-memory transitions, never on first sight, and a tie is not a lead. A login with no approval within a minute becomes a staff notice via a query, so a restart loses nothing. Also fixes a phase-4 gap (D68): the refresh now asks /health, so a game that hung, or whose bridge was unloaded, while the sidecar stayed up no longer reads as online. It stops naming players as online, and a stale board no longer moves "last seen". engagement-triggers.json is the committed freeze of all of it, checked in CI with line endings normalised. The check was verified by breaking it both ways. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
54 lines
2.1 KiB
JavaScript
54 lines
2.1 KiB
JavaScript
// ── The push facet: which triggers may reach a phone ──────────────────────
|
|
//
|
|
// `registerNotificationStreams` (MODULE_API.md §2.4). A stream is what a device
|
|
// subscribes to, and **core delivers an engagement rule's push only to devices
|
|
// subscribed to a stream whose id IS the trigger id** (`pushChannel.deliver` ->
|
|
// `publishToUsers(row.trigger_id)`). So a trigger with no stream here can never
|
|
// buzz a phone, however its rule is set — which is exactly how the families
|
|
// that should not are kept off it (D65).
|
|
//
|
|
// Every id here is ALSO a trigger in `triggers.js`. That is the one namespace
|
|
// core enforces across both facets: one event, with a payload contract and a
|
|
// subscription toggle, owned by one module. An id that appeared only here would
|
|
// be a toggle nothing could ever fire.
|
|
//
|
|
// **The tickle carries nothing.** A push is `{ stream, ref }` and the app pulls
|
|
// the real item over the authenticated inbox API, so a leaked relay topic says
|
|
// that something happened and not what. That is core's guarantee and it is why
|
|
// a raid alert may be a push at all.
|
|
|
|
const STREAMS = Object.freeze([
|
|
{
|
|
id: 'rust.base.destroyed',
|
|
label: 'Your base was raided',
|
|
description: 'Part of a base you are authorised on was destroyed by another player.',
|
|
// Delivered only to the owner's devices, never fanned out: `owner` ceiling,
|
|
// one emit per authorised person (D59).
|
|
personal: true,
|
|
requiresLinkedAccount: true,
|
|
},
|
|
{
|
|
id: 'rust.server.online',
|
|
label: 'A server came online',
|
|
description: 'A Rust server started or came back.',
|
|
personal: false,
|
|
requiresLinkedAccount: false,
|
|
},
|
|
{
|
|
id: 'rust.server.offline',
|
|
label: 'A server went offline',
|
|
description: 'A Rust server stopped or stopped answering.',
|
|
personal: false,
|
|
requiresLinkedAccount: false,
|
|
},
|
|
{
|
|
id: 'rust.wipe.started',
|
|
label: 'A server wiped',
|
|
description: 'A Rust server started a new wipe.',
|
|
personal: false,
|
|
requiresLinkedAccount: false,
|
|
},
|
|
])
|
|
|
|
module.exports = { STREAMS }
|