Block mobile GA on monitoring-first product value

docs/release-control/v6/internal/records/mobile-product-purpose-ga-blocker-2026-04-24.md

@@ -10,15 +10,20 @@
 
 During physical iPad proof review on 2026-04-24, the product owner stated that the actual Pulse Mobile experience does not make clear what the app brings to a normal self-hosted Pulse user or what the app is for.
 
+The product owner further clarified that normal self-hosted users are unlikely to think of Pulse Mobile as a control center for approving commands. Pulse is understood first as a monitoring application, so a mobile app that does not lead with monitoring will confuse users even if approval and recovery flows are technically useful.
+
 ## Judgment
 
 The current mobile candidate may be technically release-capable, including physical-device pairing, APNs delivery, tap-through routing, approval actions, reconnect, and store configuration evidence, but that does not make it product GA-ready.
 
-Pulse Mobile public rollout is blocked until the in-app experience itself explains and proves the companion-app value for self-hosted operators. The target product shape should make the primary jobs obvious without internal explanation: away-from-desk infrastructure alert triage, quick status orientation, safe approval handling, and recovery from notification or deep-link context.
+Pulse Mobile public rollout is blocked until the in-app experience itself explains and proves the companion-app value for self-hosted operators. The target product shape must be monitoring-first: current estate status, live/stale/offline signal, active alerts or findings, and clear "nothing needs attention" states should be the visible center of gravity. Approval handling and recovery from notification or deep-link context are valuable secondary jobs, but the app must not read as a command-approval console or internal control center.
 
 ## Exit Criteria
 
 - The app has an explicit product role rather than feeling like a thin or unexplained subset of desktop Pulse.
+- Monitoring is the primary visible mobile value: a paired self-hosted user can quickly see current Pulse health, attention state, and whether the phone's view is fresh enough to trust.
+- Approval, command, and recovery surfaces are positioned as secondary actions that follow from monitoring context rather than as the apparent reason the app exists.
+- Empty and all-clear states still feel useful as monitoring states, not like dead tabs waiting for approvals or commands.
 - First-run, unpaired, paired, empty, alert, approval, and recovery states make the next useful action obvious to a normal self-hosted operator.
 - The first screen after pairing communicates current estate state and why opening mobile is useful.
 - A physical-device walkthrough demonstrates that a user can understand the app purpose and primary jobs without release-team narration.

docs/release-control/v6/internal/status.json

@@ -2650,7 +2650,7 @@
       "status": "partial",
       "completion": {
         "state": "bounded-residual",
-        "summary": "Mobile is technically release-capable at the RC usefulness floor, but product GA is blocked: the current iPad experience does not yet make the normal self-hosted Pulse user value clear enough to justify public rollout. Store-capable work stays draft/TestFlight/internal-only until the mobile product purpose, first-run story, and primary operator jobs are explicit in the app and revalidated on device.",
+        "summary": "Mobile is technically release-capable at the RC usefulness floor, but product GA is blocked: the current iPad experience does not yet make the normal self-hosted Pulse user value clear enough to justify public rollout and does not establish monitoring as the primary mobile value normal self-hosted users expect. Store-capable work stays draft/TestFlight/internal-only until the mobile product purpose, first-run story, monitoring-first home experience, and secondary approval/recovery jobs are explicit in the app and revalidated on device.",
         "tracking": [
           {
             "kind": "lane-followup",
@@ -3715,7 +3715,7 @@
     },
     {
       "id": "mobile-product-purpose-and-first-run-clarity",
-      "summary": "Confirm Pulse Mobile communicates a clear self-hosted operator purpose in the actual app experience: a normal user should understand why the companion app exists, what jobs it handles away from the desktop, and how pairing, alerts, approvals, and recovery surfaces fit together before public rollout.",
+      "summary": "Confirm Pulse Mobile communicates a clear monitoring-first self-hosted operator purpose in the actual app experience: a normal user should understand that the companion app exists primarily to monitor Pulse away from the desktop, see current state and alerts, and only secondarily handle approvals or recovery actions before public rollout.",
       "owner": "project-owner",
       "blocking_level": "release-ready",
       "minimum_evidence_tier": "local-rehearsal",