test(mobile): verify notification integration and document deployment #205

Closure decision (2026-10-17)

Closed under the maintainer-approved reduced acceptance scope. The implementation and ordinary physical-device notification flows are accepted for this delivery.

Implementation is merged in #206, with the separate legacy APNs TLS fix in #217 and the automated/Simulator acceptance record in #218. Existing automated evidence is retained below; it was not rerun for this closure.

Physical-device follow-up used the source at 1709ac5cd56ebc97eaf6d47aeae4b36cf7dd56f7, installed in place on an iPhone 17 Pro Max running iOS 27.0. The installed Debug build was 2.0.0 (1), signed for APNs sandbox. Observed checks passed:

• Existing login and live data continued to work after installation and ordinary relaunch. This establishes observed login continuity, not complete signed content-key upgrade continuity.
• Phone software-keyboard input, server search, notification registration, disable/re-enable and registration recovery worked.
• Current-installation synthetic test notifications displayed decrypted content. The app UI reported APNs acceptance; raw APNs HTTP traces were not independently captured.
• Tapping a foreground banner from Servers switched to Settings. Tapping a banner on Home resumed ServerBee into Settings. The existing Settings navigation page was retained as designed. These were ordinary notification taps, not cold-launch observations.
• Refreshing test status preserved the accepted result. No duplicate banner was seen during the brief checks; strict exactly-once counting was not measured.

The current-installation notification master switch was restored to its initial disabled state, with all four business-category subscriptions off and system notification permission retained. No confirmed functional defect was found in the exercised paths.

Explicitly skipped acceptance

The maintainer requested simple, commonly reachable checks and explicitly accepted skipping cumbersome or rarely reached scenarios. The remaining full live matrix is not required for this closure. Production APNs, strict foreground duplicate counting and background/terminated arrival timing, cold notification launch, actual business-category delivery/isolation, permission/identity/revocation/fault recovery matrices and complete signed-upgrade key continuity remain unverified. The original unchecked items below are preserved as unrun evidence, not converted into passing checks or treated as outstanding blockers under the reduced scope.

All dated status and verification checkpoints below are historical. This closure decision supersedes their previous OPEN/full-acceptance requirement while preserving their evidence limits.

Historical status (2026-10-16)

OPEN: implementation and automated integration are established; full live acceptance remains incomplete. #197-#204 are implementation tickets whose remaining live observations are explicitly retained below. Their completion does not satisfy this issue's physical-device gates.

Evidence: implementation merged in #206; acceptance checkpoint merged in #218. Candidate Server CI passed 90 mobile-push integration and 95 mobile-router tests. iOS CI passed 473 tests, zero skipped, including all three actual Rust ciphertext consumers. The unchanged Worker has 73 workerd plus one native ingress test; unchanged bilingual guidance has passing documentation CI. Local zh-Hans verification passed 64/64 and all six native redirect-boundary checks passed. Earlier-SHA Worker/docs results are reused evidence, not a fresh candidate-wide run.

The dedicated ServerBee Worker is deployed. One authorized real APNs sandbox test reached a dedicated Simulator: registration revision 2, persisted Server receipt accepted/Accepted, NSE-decrypted background presentation, and opening the existing notification from a terminated app into Settings. No simctl push injection was used. The system required side-swipe to open; earlier failed harness attempts remain recorded. Initial enqueue and raw APNs HTTP responses were not separately captured; the Server receipt reports the Relay/APNs verdict and still correctly says presentation=unobserved. The dedicated session was revoked and confirmed absent. This is not physical-device or production evidence.

The original cross-category criterion remains unchecked because the physical foreground-banner observation and complete live matrix are incomplete. The other checked criteria describe completed tooling/documentation work or observance of authorization boundaries; they do not mark the outstanding live scenarios complete. Public issue status is being synchronized under explicit maintainer authorization, not automatically from a documentation change.

Remaining live acceptance checklist

• fix(mobile): preserve push registration across authentication refresh #197: Physical login/refresh/logout behavior and signed-upgrade continuity.
• feat(ios): opt in to verified mobile notification registration #198: Physical permission recovery and production registration.
• feat(mobile): deliver an encrypted test notification to one installation #199: Production, physical presentation/navigation, foreground banner count and arrival while terminated.
• feat(mobile): retry queued notifications for up to 30 minutes #200: Authorized isolated outage/restart/recovery and expiry observation.
• feat(ios): receive subscribed alert trigger and recovery notifications #201: Actual alert trigger/recovery presentation, late taps and missing-cycle fallback.
• feat(ios): notify administrators of matching security rules #202: Actual administrator delivery, member silence and security-detail navigation.
• feat(ios): notify task owners of final run failures #203: Actual final-failure notification, owner isolation and task-run navigation.
• feat(ios): opt in to successful scheduled-task run notifications #204: Actual success subscription, default/opt-out silence and task-run navigation.
• Record sandbox and production independently on physical devices: foreground (one banner), background, arrival while terminated, decryption and authenticated cold/warm navigation.
• Verify account/deployment replacement, old-notification navigation rejection, subscription changes, offline logout/revocation and multi-installation isolation with actual devices.
• Verify an in-place signed upgrade preserves installation, login, registration and content keys; retain the existing installed-app baseline before installing anything.

Remaining prerequisites: an available unlocked physical iPhone, identified installed build and prior signed-upgrade baseline, development/distribution builds for the respective APNs environments, and an authorized isolated setup for business-event and failure/recovery tests. The prior shared-demo authorization was used for one directed synthetic test with business subscriptions disabled; it is not evidence for those remaining scenarios. No speculative implementation gap is established by these missing observations.

Dated checkpoints below are historical. This status supersedes earlier statements that the Worker is undeployed or that all live APNs checks are unrun; production and physical-device gates remain pending.

Parent

#196

Architecture decision update (2026-10-03)

The current scope follows the approved public, stateless Cloudflare Workers Relay decision in #196 and #206. The earlier App Attest/challenge/device-grant requirements are superseded, without a replacement authorization service. Server login, installation ownership, key lifecycle, exact-target offline session revocation and account isolation remain required. Implementation and automated verification are recorded in #206 at 22c828c4517734b0814240ca4bbe751d126ffa3d. Acceptance checkboxes remain unchanged; live-device acceptance remains separate and pending.

What to build

A maintainer can validate the complete subscribed notification experience and follow an English/Chinese setup and troubleshooting workflow, with automated evidence separated from live APNs and signed physical-device observations.

Acceptance criteria

• Exercise cross-category interactions through the complete integration pipeline, including category isolation, permission recovery, refresh, logout/account change, role downgrade, multiple installations, legacy migration and one foreground banner.
• Run the relevant Server, Relay, iOS, generated-contract, localization and documentation checks, recording actual test counts and fixing integration defects exposed by the combined feature.
• Keep Server integration and real persistence as the primary seam; mock only Apple/network/system boundaries. Avoid repeating already passing isolated tests without new changes or unresolved concerns.
• Update bilingual mobile/configuration and privacy guidance for explicit opt-in, encrypted content, visible Relay metadata, authenticated Server registration, accepted public-endpoint abuse risks and best-effort per-instance limit scope, 30-minute expiry, test/status interpretation and troubleshooting.
• Provide an isolated Cloudflare Worker/APNs/App/NSE signing and deployment runbook and a repeatable real-device checklist covering authenticated registration, sandbox/production APNs environments, foreground/background/terminated presentation, decryption, taps, refresh, and account/device revocation. App Attest, strict app-version/distribution gates, challenges, grants and Relay SQLite are superseded and must not remain current prerequisites.
• Run live checks only against an explicitly authorized configured environment. Record observations or concrete missing prerequisites separately; do not claim real APNs delivery from simulator, fixture or build success.
• Publish neither infrastructure nor code automatically, install no secrets, change no Apple account settings, and do not modify Heeler's Relay. Preserve the parent specification's out-of-scope boundaries.
• Reconcile implementation and documentation with the revised relay ADR and public PR/issue descriptions; complete any needed agent-navigation checks. Do not close issues or imply that documentation synchronization establishes implementation or live-device acceptance.

Blocked by

• feat(ios): receive subscribed alert trigger and recovery notifications #201: feat(ios): receive subscribed alert trigger and recovery notifications
• feat(ios): notify administrators of matching security rules #202: feat(ios): notify administrators of matching security rules
• feat(ios): opt in to successful scheduled-task run notifications #204: feat(ios): opt in to successful scheduled-task run notifications

Current verification boundary (2026-10-03)

The simplification is implemented in PR #206 at 22c828c4517734b0814240ca4bbe751d126ffa3d. All 17 current PR checks are green, with no pending or failed checks:

• Main CI: all nine jobs passed, including 88/88 mobile push integration tests with none ignored; generated API/client zero-drift checks passed
• Rust-to-Worker and iOS: two real Rust trace producers passed; 424 iOS tests passed with zero failures and no XCTest skips, including all three formerly skipped actual extension/cold-tap ciphertext consumers
• Worker: 61 workerd tests and one native HTTP/TCP-reset cancellation regression passed, including the production request-signal flag and flag-off negative control; type checks and Wrangler production dry-run passed
• Bilingual documentation build, route and browser contracts and commit attribution passed

The identity correction aligns the app/NSE/test bundle identifiers and APNs topic with the official app. The official main app, Notification Service Extension and test bundle identifiers are app.serverbee, app.serverbee.notifications and app.serverbee.tests. Private/shared Keychain groups use $(AppIdentifierPrefix)app.serverbee and $(AppIdentifierPrefix)app.serverbee.push. Historical com.serverbee.mobile / com.serverbee.mobile.push Keychain service labels are intentionally retained for stored-credential compatibility; they are not bundle identifiers. Static identity-drift checks and testOfficialIdentityReadsHistoricalServiceInDefaultPrivateGroup passed. Signed-device upgrade continuity remains unverified.

Historical checks for the App Attest/grant implementation remain historical only.

Deployment/configuration checkpoint (2026-10-03, 19:48 UTC): The existing Worker deployment is active. APNS_TOPIC is now app.serverbee; the optional APNS_ENVIRONMENTS override was removed, so the configured default permits sandbox and production. Existing encrypted credential bindings were retained. A safe empty-object POST now returns 400 InvalidRequest instead of 503 RelayNotConfigured. This establishes accepted configuration shape only, not signing-key validity or APNs provider acceptance. No request to Apple's APNs provider was made. The Worker runtime bundle is byte-identical between ae5add3 and 22c828c, so no code redeploy was needed.

Live APNs sandbox/production provider acceptance and delivery, signed-device upgrade continuity, and signed physical-device presentation/taps remain NOT RUN. They still require verified signing credentials and the authorized end-to-end Server/device environment. No issue was closed and no acceptance checkbox was marked complete by this evidence update.