ManagementReader and DashboardSession retain their existing operations.
Server composition
Use the same authorized project for the page, management client, and push reader. Create these clients inside the authenticated host request. Keep the executor and management key on the server. Browser navigation opens the host page. This single-project example assumes the host has authenticated its operator before callingcampaignPage. Supply the configured self-host origin and management key
from the host’s server configuration.
@galinum/dashboard/tokens.css and include the dashboard package in the
host’s Tailwind source scan. Preserve the host’s existing safety actions through
renderActions and its approval/review context through renderContext.
renderMessage handles only email and web in-app content. Push always uses the
public stored-content view; destinations, images, data, and action labels remain
inert escaped text.
Inspection contract
PushSupervisionReader.inspectPushCampaign(id, { page, perPage }) returns the
generated PushInspection type. PushContent, PushSettings, and
PushInspection are also exported from @galinum/core/contract.
Push campaign summaries require push: PushSettings; push details retain
CampaignVariant<PushContent>[]. Other variants keep CampaignMessageContent.
createPushSupervisionClient uses the existing executor and
ManagementClientError. Non-success responses, including 404, remain
request_failed errors. Invalid JSON or generated-schema failures become
invalid_response. Invalid pagination throws RangeError before transport:
page and perPage must be positive safe integers, perPage must be at most 100,
and their offset must be safe.
The page selects exactly one feed. Push loads inspection; email and in-app load
their existing deliveries. An inspection failure leaves stored campaign content
and safety context visible, shows an error and retry link, and shows no invented
zero totals. The host must authenticate the page before rendering any content.
pushKind defaults to outcomes; pushPage defaults to 1. Invalid, fractional,
or nonfinite pages reset to 1. Valid UI pages are capped at 10,000. Changing the
collection resets the page. The URL builder must preserve unrelated parameters.
The page requests 25 records per collection and renders only the selected array.
One response contains at most 175 records across seven independent collections.
Each collection uses its own records count and pageCounts. An out-of-range
page keeps the totals and links to the last available page without refetching.
Unique-user totals, logical device slots, attempts, and submission facts use
different units. The page uses canonical campaign totals directly. Provider
acceptance does not confirm receipt. Receipt unknown means acceptance or possible
submission without receipt evidence. Confirmed submissions can include rejection.
Provider results and submission certainty appear separately.
Test work can appear in record pages while production totals exclude it. Related
records can reside on different pages. No joins, missing outcomes, variant totals,
CTR, or receipt conclusions are inferred from a selected page. Push list rows
link to supervision without per-row inspection requests or legacy delivery counts.