Appearance
Keryx go-to-market
This section coordinates adoption and public iPhone/iPad App Store and Google Play distribution of Keryx as SafeCall's first-party notification companion for SafeCall administrators. Keryx replaces the generic ntfy client in the administrator workflow; it is not independently marketed.
The program separates adoption strategy, launch readiness, application behavior, and release operations:
- Adoption strategy — fixed product model, installed-base rollout, SafeCall-led positioning, enablement, and measures.
- Go-to-market roadmap — audited baseline, decisions, phases, risks, launch gates, and GitLab work items.
- QR and ntfy threat model — P1-01 abuse cases, ratings, and treatment handoffs for provisioning and topic access.
- Authenticated provisioning protocol — P1-02 HTTPS-only, per-QR subscribe tokens, publish token, and v2 QR contract.
- Android delivery architecture — P1-03 FCM
poll_request+ authenticated poll; perpetualdataSyncFGS deprecated. - iOS APNs delivery architecture — P1-04 client-ntfy token registration; upstream APNs
poll_requestforcom.sourcectl.keryxapp. - Data classification and local storage — P1-05 SharedPreferences + full lock-screen launch policy; retention and offboarding.
- Legal drafts — P1-06 DRAFT privacy, terms, and support texts with planned public URL paths (not yet live).
- Apple privacy compliance — P1-07 manifests, purpose strings, nutrition-label draft, HTTPS-only export answer.
- Play Data Safety — P1-08 Data Safety draft, permissions, FGS posture, app-content checklist, reviewer-access plan.
- Dependency ownership — P1-09 direct-dep inventory, vendored ntfy ownership, privacy-manifest checklist, advisory cadence.
- Safety claims — P1-10 supplemental posture, delivery limits, no Critical Alerts at launch, prohibited claims, escalation.
- Visual identity — P2-01 mark, wordmark rules, palette, asset inventory, and store kit gaps.
- Store listing copy — P2-02 bilingual Apple/Google fields, reviewer notes, and release-note templates.
- Store screenshot kit — P2-03 device matrix, shot list, sample data, capture checklist, and captions.
- Public web pages — P2-04 URL map, landing copy, deployment checklist, and monitoring rules.
- Localization — P2-05 EN/CS policy, glossary, surface matrix, and release workflow.
- Android signing — P3-01 Play App Signing, upload-key custody, fail-closed Gradle wiring, AAB verification, recovery drill.
- iOS signing — P3-02 distribution signing, ExportOptions, IPA verification; App ID
com.sourcectl.keryxappregistered; primary signed IPA verified; recovery drill passed on MiniVan-3 (30 August 2026); ASC app record exists (CZ-only). Both Macs’ Distribution.p12files are on the NAS share (OA-110-cert-backup, 1 September 2026). - Internal TestFlight — Internal install of
1.0.0+3is done (OA-124-testflight, 10 September 2026). Next FCM candidate is GLaDOS1.2.0+7. Soak and App Review stay in the publishing runbook; do not close #124. - Client ntfy and push deployer checklist — P4-05 packet for #119 (closed 13 September 2026): topologies, TLS/auth/FCM, secret-free templates, acceptance-test table. Dual-run and first-device FCM proof are already done. Do not apply
deny-all. - Administrator provisioning handbook — P4-06 / #120 closed 13 September 2026: friendly categories, own-device QR, first test, replacement/revoke via the SafeCall channel, troubleshooting, escalation. Czech handbook stays on #108.
- Administrator app onboarding guide — P4-07 English phone-side how-to for #121: store/Internal install, permissions, Scan QR code, Active/Archive, pause, battery (no perpetual FGS), official-ntfy migration, offboarding. OA-121-app-walk done 19 September 2026. Live web, Czech, and screenshots remain. Do not close #121.
- ntfy auth dual-run and Play Internal — first Play Internal install of
1.0.0+3is done (OA-124-play-internal). ntfy auth dual-run Parts A–D are done on hetest2 +safecall.wantok.czTST000 (13 September 2026). Deny-anonymous cutover and production Play stay later. Do not close #124. - Firebase / FCM / APNs closed-app wake — Client files for
keryx-for-safecallare in repo. Notify-host Firebase (OA-119-ntfy-fcm) and first-device swipe-away proof on 1.2.1 (8) are done (13 September 2026). Do not close #117. Installed Internal1.0.0+3is superseded for FCM proof. - Store organization roles and EU trader — P3-06 how-to. #114 closed 13 September 2026 (org roles, 2FA, EU trader). Apple Account Recovery is later #158. Do not invent a second Account Holder. Do not paste listings. Release-record template: templates/release-record.md.
- Secret store — LAN NAS CT 500 (
nas,192.168.178.213): gocryptfs + File Browser / SFTP;secrets/keryx/andevidence/keryx/. OA-114-archive is done. After a NAS reboot, unlock gocryptfs before using the share. - NAS unlock after reboot — gocryptfs + File Browser after CT 500 restarts (passphrase not in git).
- Operator actions — human/portal/secret-store checklist (blocking vs later); keep in sync with GitLab close bars.
- Keryx operator close-out — sequenced sitting for remaining Keryx public-launch rows (next: OA-125-listings).
- Lab SafeCall host —
https://safecall-lab.sourcectl.com(Ariadne pairing; not Keryx{public_base}). - Versioning and compatibility — P3-05 semver/build/tag rules, changelog ownership, QR schema migration, downgrade and support window.
- CI (unsigned first slice) — P3-04 / #112 shared-Linux jobs (
keryx:dart,keryx:server,keryx:native-android). No secrets. Do not close #112; signed compile, SBOM, and Swift/macOS remain. - Accessibility (in-repo first slice) — P4-02 / #116 camera/notification Settings recovery UI and widget tests. #116 closed 20 September 2026 (trained hospital/admin audience; no WCAG claim).
- Reviewer environment (in-repo first slice) — P5-01 / #123 static-page topology, A1–A5 sample catalog, and Apple/Google steps. Do not close #123. Live ntfy ACL + HTTPS QR + off-LAN proof are OA-123-review-host done 20 September 2026. Store URL paste stays #125.
- Monitoring and support intake (in-repo first slice) — P6-05 / #132 host/ops signals, ticket redaction, and severity. Intake drill OA-132-intake-drill done. Do not close #132. No analytics/crash SDK.
- Hotfix, stop-rollout, and rejection (in-repo first slice) — P6-02 / #129 authority, no-downgrade, and console halt limits. Tabletop OA-129-hotfix-tabletop done. Do not close #129.
- Requirements-to-test traceability — P4-01 map of launch requirements to automated, native, device, soak, and pilot evidence; per-commit / per-release cadence. #115 closed 17 September 2026; QR goldens #159 and automated coverage #160 closed the same day.
- Keryx application — current product behavior and QR contract.
- Alert topics — staff ntfy categories, triggers, tags, and send cadence.
- Publishing Keryx — first release, routine update, hotfix, submission, and lifecycle runbook.
- GitLab issue workflow — SafeCall issue and commit conventions.
Fixed launch scope
- Public Apple App Store distribution for iPhone and iPad.
- Public Google Play distribution for Android.
- An included companion for administrators of a configured, contracted SafeCall deployment.
- Friendly SafeCall alert-category selection followed by scan-on-own-device QR provisioning; no ordinary administrator needs to configure ntfy or topics.
- A SafeCall-branded replacement for the generic ntfy app.
- Store distribution as a client installation path, not a standalone product, SKU, self-service sale, or demand-generation channel.
- No macOS, Windows, Linux, or web product launch.
The roadmap and GitLab backlog are planning artifacts. They do not authorize a store submission or claim that signing, privacy, push, security, or support gaps are already fixed.
GitLab program
- Parent work item #81
- Keryx public launch milestone
- P0 — Product and governance #82
- P1 — Trust, security, privacy, and delivery #83
- P2 — Brand, client enablement, and store content #84
- P3 — Build, signing, and release engineering #85
- P4 — Product and client readiness #86
- P5 — Store submission and launch #87
- P6 — Updates and post-launch operations #88
How to use this program
- Start with the fixed product model in the adoption strategy. P0 product and governance decisions are approved in the roadmap. Do not reopen the administrator-only, non-standalone relationship while executing later phases. Pick up ready P1, P2, or P3 work items next.
- Do not build public claims, legal pages, or release automation around an unresolved delivery architecture, privacy packet, or unverified support contact evidence.
- Pick up one actionable GitLab work item. Keep it in exactly one
workflow::*state and preserve its stated scope. - Use the strategy for adoption intent and message guardrails. Use the roadmap for rationale and gate criteria. Use GitLab for ownership, dependencies, implementation discussion, and execution state.
- Move an item to review only after its measurable acceptance criteria have evidence.
- Close a phase only when its exit gate passes or every remaining risk is explicitly accepted with an owner and review date.
- Use Publishing Keryx for each release candidate. A successful build alone is not launch approval.
Status rules
workflow::ready— scoped and queued.workflow::doing— actively owned.workflow::blocked— waiting on a documented dependency.workflow::review— acceptance evidence is ready for verification.- Closed work item — verified done.
Every open GTM work item also has gtm, product::keryx, a phase::pN, and a type::* label. priority::launch-blocker is removed only when the issue is closed or its risk is accepted in the roadmap by the launch authority.
Source-of-truth boundary
The adoption strategy records:
- the fixed SafeCall companion role and administrator audience;
- installed-base and active-prospect adoption plays;
- positioning, enablement, message guardrails, and adoption measures;
- hypotheses and decisions that do not contain client-sensitive data.
The roadmap records:
- product and architecture decisions;
- phase dependencies and go/no-go criteria;
- the current evidence-based gap status;
- accepted and deferred risks;
- links to GitLab execution.
GitLab records:
- work-item state, ownership, dependencies, and discussion;
- implementation acceptance evidence;
- follow-up defects and review outcomes.
Store consoles, signing vaults, production ntfy configuration, and client deployment records remain external systems. Their GitLab work items must link to durable evidence without copying secrets into the repository.