ceo-orchestration 1.0.0

package/.claude/skills/domains/mobile/skills/mobile-app-builder/SKILL.md

@@ -0,0 +1,446 @@
+---
+name: mobile-app-builder
+description: Mobile application development discipline covering iOS native (Swift /
+  SwiftUI), Android native (Kotlin / Jetpack Compose), React Native, and Flutter
+  cross-platform approaches. Covers app architecture (MVVM, MVI, Clean, TCA),
+  state management per platform, navigation and deep-link semantics, offline-first
+  local-DB selection and sync conflict resolution, push and local notification
+  compliance (APNs / FCM), accessibility (VoiceOver, TalkBack, WCAG 2.2 AA mobile),
+  and App Store / Play Console store compliance including privacy manifests. Use when
+  designing or reviewing any mobile feature, architecture decision, platform selection,
+  or store-submission readiness. Pair with security-and-auth for token storage and
+  biometric auth flows.
+owner: Priya Menon (Mobile App Builder, domain persona)
+tier: domain:mobile
+scope_tags: [mobile, ios, android, react-native, flutter, mobile-architecture, offline-first]
+# --- native path activation (PLAN-135 W3 K8; K1 mechanism) ---
+paths: ["**/*.swift", "**/Package.swift"]
+inspired_by:
+  - source: msitarzewski/agency-agents/engineering/engineering-mobile-app-builder.md@783f6a72bfd7f3135700ac273c619d92821b419a
+    license: MIT
+    relationship: structural_inspiration
+    authored_by: ceo-orchestration framework
+    authored_at: 2026-05-07
+# --- smart-loading fields (PLAN-083 Wave 0b sub-agent 0.7c) ---
+domain: mobile
+priority: 8
+risk_class: medium
+stack: [swift, kotlin, react-native]
+context_budget_tokens: 600
+inactive_but_retained: true
+repo_profile_binding:
+  frontend: {active: false, priority: 10}
+  engine: {active: false, priority: 10}
+  fintech: {active: false, priority: 10}
+  trading-readonly: {active: false, priority: 10}
+  generic: {active: false, priority: 10}
+activation_triggers:
+  - {event: help-me-invoked, regex: "(?i)foundation.?models|apple.?intelligence"}
+---
+
+# Mobile App Builder
+
+## Cardinal Rule
+
+**Platform behavior is a contract, not a suggestion.** Platform-specific memory
+pressure, background execution limits, and review policy rules are not edge cases
+— they are the invariants the entire runtime assumes. Every architecture decision
+must be defensible against App Store Review and Play Console policies before any
+line of implementation is written.
+
+## Fail-Fast Rule
+
+Stop and surface a structured error when:
+
+- A proposed token or credential storage location is not the platform keychain or
+  Keystore (see Cross-References: security-and-auth).
+- A navigation change breaks the back-stack contract, universal-link routing, or
+  accessibility traversal order.
+- An offline-first sync operation has no conflict-resolution strategy defined.
+- A notification payload exceeds the platform limit (APNs: 4 KB; FCM: 4 KB data,
+  up to 4 KB notification) or lacks the required permission-request trigger.
+- A store-submission target uses a deprecated API or missing privacy-manifest
+  declaration.
+- A Claude integration via Apple Foundation Models uses `.apiKey` auth in a
+  release configuration (see Apple Foundation Models: three mandates).
+
+Never silently default, guess, or smooth over these conditions.
+
+## When to Apply
+
+Load this skill when:
+
+- Selecting or revisiting the native vs. cross-platform platform strategy.
+- Designing or reviewing app architecture, module boundaries, or state-management
+  approach.
+- Implementing navigation, deep links, universal links, or app links.
+- Adding or modifying offline persistence, sync, or conflict resolution.
+- Integrating push notifications (APNs / FCM) or local notification scheduling.
+- Reviewing accessibility compliance (VoiceOver, TalkBack, dynamic type, touch
+  targets).
+- Preparing a build for App Store or Play Console submission.
+- Adding biometric authentication or platform keychain/Keystore integration
+  (always pair with `core/security-and-auth`).
+- Integrating Claude through Apple's Foundation Models framework
+  (`ClaudeForFoundationModels`), or routing between the on-device model and
+  Claude.
+
+## Platform Strategy
+
+### Selection matrix
+
+| Criterion | Native iOS + Android | React Native | Flutter |
+|---|---|---|---|
+| Team skill fit | iOS (Swift) / Android (Kotlin) specialists | TypeScript / JavaScript teams | Dart-capable or greenfield |
+| Platform fidelity | Highest — full API surface, no bridge | High with native modules; bridge overhead | High; own rendering engine, not system widgets |
+| Performance ceiling | Best (Metal, Vulkan direct) | Good; JS bridge latency on high-frequency events | Good; Impeller/Skia rendering; no JS bridge |
+| Time-to-market (both platforms) | Slowest (two codebases) | Faster; ~60-80% code share realistic | Fastest; ~70-90% code share realistic |
+| Third-party SDK availability | All SDKs have native variants | Most SDKs; gaps require native modules | Growing; some SDKs absent or community-only |
+| Maintenance burden | Two separate release trains | One JS layer + two native shells | One Dart layer + two shells; Dart FFI for native |
+| Store compliance risk | Lowest; no interpretation layer | Low; React Native well-precedented | Low; Flutter well-precedented |
+
+**Decision rule:** choose native when the feature set requires deep platform API
+access (ARKit, Core NFC, on-device ML, Bluetooth LE central mode) or when the
+existing team has platform specialization. Choose React Native when a JS/TS web
+team is the primary mobile team and third-party SDK coverage is sufficient. Choose
+Flutter when both platforms are greenfield, delivery velocity is the constraint, and
+Dart adoption is feasible.
+
+**Never choose a framework to avoid learning platform conventions.** Platform
+conventions must be understood regardless of framework — they define the contract
+that governs review and runtime behavior.
+
+## Apple Foundation Models (Claude integration)
+
+> Beta surface: targets the server-side language model API introduced in the
+> OS 27 betas (iOS / iPadOS / macOS / visionOS / watchOS 27, Xcode 27). APIs
+> may change before GA.
+
+`ClaudeForFoundationModels` is Anthropic's Swift package
+(`https://github.com/anthropics/ClaudeForFoundationModels.git`, SPM) that
+conforms Claude to Apple's `LanguageModel` protocol. The same
+`LanguageModelSession` API that drives Apple's on-device model drives Claude —
+`respond(to:)`, streaming via `streamResponse(to:)`, guided generation, and
+tool calling work unchanged; you switch providers by swapping the `model:`
+argument. Requests go directly from the app to the Claude API (Apple is not in
+the request path) and are billed to the adopter's Anthropic account at standard
+API pricing.
+
+```swift
+// Package.swift
+.package(url: "https://github.com/anthropics/ClaudeForFoundationModels.git", from: "0.1.0")
+```
+
+```swift
+import FoundationModels
+import ClaudeForFoundationModels
+
+let claude = ClaudeLanguageModel(name: .sonnet4_6, auth: auth)
+let session = LanguageModelSession(model: claude)
+let response = try await session.respond(to: prompt)
+```
+
+### On-device <-> Claude routing doctrine
+
+Same tiering logic as the CEO routing table: route every request to the
+cheapest tier that is capable, escalate only on demonstrated capability demand.
+
+| Tier | Route here when | Cost profile |
+|---|---|---|
+| Apple on-device model (`SystemLanguageModel`) | Lightweight tasks, privacy-sensitive content, offline paths | Free, private, offline-capable; sized for lightweight tasks |
+| Claude (`ClaudeLanguageModel`) | Larger context, frontier reasoning, server-side tools (web search, code execution via `serverTools:`) | Billed per request to the adopter's account; network required |
+
+- Routing is the `model:` argument — both tiers share `LanguageModelSession`,
+  so there are no dual code paths to maintain.
+- Escalation is a product decision the app makes per session; make it explicit
+  in code (a named routing function), never implicit in scattered call sites.
+- Degrade gracefully downward: catch `LanguageModelError.rateLimited` (or
+  timeout) from Claude and fall back to `SystemLanguageModel` for that turn,
+  queue the request, or surface a retry affordance.
+
+### Structured output (`@Generable`)
+
+Annotate a type with `@Generable` (with `@Guide` per field) and request it with
+`generating:` — the package maps it onto Claude structured outputs. If the
+chosen model's declared capabilities do not include structured output, the
+package throws `LanguageModelError.unsupportedGenerationGuide` rather than
+silently degrading — surface it, never swallow it.
+
+### Three mandates (fail-fast — do not ship without all three)
+
+1. **`.proxied(headers:)` is the ONLY production auth.** `.apiKey` is
+   development-only: a key bundled into a shipping binary is extractable, and
+   anyone who extracts it can make requests billed to the adopter's account.
+   Production routes through the adopter's own backend via
+   `auth: .proxied(headers:)` plus `baseURL:` — the relay attaches the Claude
+   credential (`x-api-key`) server-side, the app ships no key, and the supplied
+   headers let the proxy authorize the caller. A release build with `.apiKey`
+   is a Fail-Fast condition (see Fail-Fast Rule).
+2. **`fixedEffort:` for `.xhigh` / `.max`.** The framework's per-request
+   reasoning hints stop at high. `fixedEffort:` pins a Claude effort level for
+   every request, takes precedence over the framework's hints, and is the only
+   way to request `.xhigh` or `.max`. The level must be one the model's
+   declared capabilities accept; the API defaults to high when no effort is
+   sent.
+3. **Capability declaration for unknown model IDs.** Compiled-in `ClaudeModel`
+   constants (e.g. `.opus4_8` = `claude-opus-4-8`) carry each model's
+   capabilities — sampling parameters, effort levels, adaptive thinking,
+   structured output, image input — and the package uses them to decide which
+   request fields to send, because sending a field a model rejects is a hard
+   error. For an ID that is not compiled in, declare what it accepts
+   explicitly via `ClaudeModel(id:capabilities:)`; there is deliberately no
+   shorthand that guesses. This is the framework-side mirror of ADR-149's
+   model-id allowlist doctrine: never assume what an unverified model ID
+   supports.
+
+## App Architecture
+
+### Architecture pattern selection
+
+| Pattern | When it wins | When to avoid |
+|---|---|---|
+| MVVM (iOS: SwiftUI/Combine; Android: ViewModel/StateFlow) | Declarative UI, clear View/ViewModel boundary, reactive bindings | Deep side-effect chains where unidirectional flow is essential |
+| MVI (Model-View-Intent) | Complex state with explicit intent dispatch; Android Compose is well-suited | Simple screens — ceremony overhead is not justified |
+| Clean Architecture (Use Cases + Repositories) | Large codebases, testability priority, CI gate coverage requirements | Small apps; over-engineers the data layer unnecessarily |
+| TCA (The Composable Architecture — iOS/Swift) | Pure unidirectional state machine; composable feature trees; SwiftUI teams already familiar | Non-Swift targets; Kotlin/RN/Flutter teams lack first-class TCA equivalents |
+
+### Module boundaries
+
+- **Feature modules** are independently compilable. Circular dependencies between
+  feature modules are a build error, not a warning.
+- **Core modules** (networking, persistence, analytics, auth) have no dependency on
+  any feature module.
+- **Platform modules** (camera, biometrics, push) expose a protocol/interface
+  boundary to feature modules; no direct SDK import from feature code.
+- No UI code in domain or data layers. Domain layer has zero UIKit / SwiftUI /
+  Compose import.
+
+### Testability
+
+- ViewModels / Presenters are plain objects with no platform import.
+- Repository layer takes protocol/interface arguments; real implementations are
+  injected at the composition root, stubs at test time.
+- Snapshot tests (iOS: swift-snapshot-testing; Android: Paparazzi) cover each
+  distinct UI state, not every permutation.
+
+## State Management
+
+State management is platform-specific. Cross-platform frameworks add their own layer.
+
+**iOS — SwiftUI + Combine:**
+- `@StateObject` owns lifecycle; `@ObservedObject` observes. Mixing them causes
+  phantom resets.
+- `@Published` properties trigger re-render; expensive computations belong in
+  `receive(on:)` pipelines, not body closures.
+- Global shared state lives in `@EnvironmentObject`; over-use creates invisible
+  coupling — prefer scoped `@StateObject` trees.
+
+**Android — Jetpack Compose + Kotlin Flow:**
+- `ViewModel` survives configuration changes; `rememberSaveable` survives process
+  death for lightweight UI state only.
+- `collectAsStateWithLifecycle` (not `collectAsState`) prevents background
+  collection and battery drain.
+- `StateFlow` for UI state; `SharedFlow` for events (navigation, one-shot errors).
+  Never emit UI state through `SharedFlow` — it has no replay guarantee on
+  recomposition.
+
+**React Native — Redux / MobX / Zustand:**
+- Zustand preferred for small-to-medium apps; Redux + Redux Toolkit for
+  complex async flows.
+- All async side effects belong in middleware (Redux Thunk / Saga) or Zustand
+  actions; never inside component effects.
+- Component re-render surface must be minimized via selector memoization
+  (`useSelector`, `useMemo`).
+
+**Flutter — Riverpod / Bloc:**
+- Riverpod `AsyncNotifier` for async data; `Notifier` for synchronous state.
+- Bloc pattern for complex event-state machines; avoid it for simple CRUD screens.
+- `StateProvider` in Riverpod is a code smell for complex state — migrate to
+  `Notifier` before the first code review.
+
+## Navigation Discipline
+
+- **Route as URL.** Every screen has a deterministic path segment. Deep links,
+  universal links (iOS), and app links (Android) must resolve to the same code
+  path as in-app navigation — no dual routing tables.
+- **Back-stack semantics are explicit.** `popBackStack`, `replaceTop`, and
+  `clearAndReplace` have distinct semantics; the wrong choice corrupts the user's
+  navigation history.
+- **Universal links (iOS):** `apple-app-site-association` file must be hosted at
+  `https://<domain>/.well-known/apple-app-site-association` with correct
+  `applinks` entries. AASA changes propagate with up to 24-hour CDN delay.
+- **App links (Android):** Digital Asset Links JSON at
+  `https://<domain>/.well-known/assetlinks.json`. Verification must pass before
+  release; test via `adb shell pm get-app-links`.
+- **Gesture handling:** swipe-back (iOS edge-pan) and predictive-back (Android 13+)
+  must not trigger unsaved-data loss without a confirmation dialog. Modal sheets
+  must handle the dismiss gesture identically to the dismiss button.
+
+## Offline-First Patterns
+
+### Local DB selection
+
+| Database | iOS fit | Android fit | RN fit | Flutter fit | When to choose |
+|---|---|---|---|---|---|
+| SQLite (raw) | Core Data wrapper | Room wrapper | `expo-sqlite` / `react-native-quick-sqlite` | `sqflite` | Full SQL control; complex queries |
+| Core Data | Native | — | — | — | iOS-only; tight SwiftUI integration; migration tooling |
+| Room | — | Native | — | — | Android-only; Kotlin-first; Flow integration |
+| Realm | Native SDK | Native SDK | `realm-js` | `realm-dart` | Reactive queries; sync with MongoDB Atlas |
+| WatermelonDB | — | — | React Native | — | RN-specific; lazy loading; Observable architecture |
+| Drift (formerly Moor) | — | — | — | Native | Flutter-native; type-safe SQL with code generation |
+
+### Sync conflict resolution
+
+Conflict resolution strategy must be documented in the architecture before
+implementation. Accepted strategies:
+
+- **Last-write-wins (LWW):** simplest; requires server-authoritative timestamps;
+  correct only when concurrent writes to the same field are rare and low-stakes.
+- **Server-wins:** client changes are local optimistic UI only; server state
+  replaces on sync. Correct for externally driven data (e.g. order status).
+- **CRDT (Conflict-free Replicated Data Types):** mathematically merge-safe;
+  appropriate for collaborative or append-only structures (notes, checklists).
+- **Three-way merge (ancestor + local + remote):** requires ancestor record storage;
+  appropriate for complex entities where partial merges are valid.
+
+**No silent discard.** If a conflict is resolved in a way that discards user
+input, the resolution must be surfaced to the user.
+
+### Optimistic UI
+
+Minimum structure for an optimistic mutation (pseudocode — applies to all platforms):
+
+```
+function submitOptimistic(item):
+    previousState = store.snapshot()
+    store.applyOptimistic(item)           // local immediate update
+    try:
+        result = await api.post(item)
+        store.commit(result)              // replace optimistic with confirmed
+    catch SyncError as e:
+        store.rollback(previousState)     // restore prior state
+        retryQueue.enqueue(item, e)       // dead-letter; never silent drop
+        ui.showConflictBanner(e)
+```
+
+Optimistic mutations must be paired with:
+
+1. A rollback path on sync failure (restore previous local state).
+2. A visual diff signal so the user can distinguish committed from optimistic state.
+3. A retry queue with exponential backoff and dead-letter storage (not silent drop).
+
+## Push + Local Notifications
+
+### APNs (iOS)
+
+- Register via `UNUserNotificationCenter.requestAuthorization` at a justified
+  moment — not on first app launch. Prompt timing must be validated against
+  provisioning profile entitlements.
+- Payload limit: 4 KB total. Exceed it and the notification is silently dropped.
+- Use `mutable-content: 1` for notification service extension processing only when
+  needed (media attachments, decryption). The extension has 30 seconds.
+- Silent push (`content-available: 1`, no alert/sound/badge) is rate-limited by
+  iOS at discretion. Never rely on silent push for time-sensitive delivery.
+
+### FCM (Android / cross-platform)
+
+- Notification messages (display by FCM SDK) vs. data messages (handled by app):
+  choose data messages for all custom handling; notification messages bypass
+  `onMessageReceived` when the app is in background.
+- `HIGH` vs. `NORMAL` priority: `HIGH` wakes the device from Doze; use only for
+  user-facing alerts. Background data sync must use `NORMAL`.
+- Android 13+ requires `POST_NOTIFICATIONS` permission; request at the appropriate
+  user-action moment, not at app start.
+
+### Delivery diagnostics
+
+- Log device token registration, token refresh, and delivery receipt (FCM
+  delivery receipt API / APNs feedback service) at the analytics plane.
+- Silent-push budget exhaustion (iOS) and Doze-mode delivery latency (Android)
+  must be documented in the system's SLA.
+
+## Accessibility Compliance
+
+- **VoiceOver (iOS) / TalkBack (Android):** every interactive element has a
+  descriptive `accessibilityLabel` (iOS) / `contentDescription` (Android). Never
+  expose implementation strings ("ic_btn_close_24") as accessibility labels.
+- **Dynamic type (iOS) / font scale (Android):** layouts must not overflow or
+  truncate at the system's largest accessibility font size. Test at 200% scale.
+- **Touch target floor:** minimum 44 × 44 pt (iOS HIG) / 48 × 48 dp (Material
+  Design). Elements below the floor must have a tap-area inset applied without
+  changing visual size.
+- **WCAG 2.2 AA mobile profile:**
+  - Contrast ratio ≥ 4.5:1 for body text; ≥ 3:1 for large text (18pt regular /
+    14pt bold) and UI components.
+  - Focus indicators visible at ≥ 3:1 contrast against adjacent colors.
+  - No information conveyed by color alone; use shape or label redundancy.
+  - Motion: respect `prefers-reduced-motion` (iOS) / `ANIMATOR_DURATION_SCALE = 0`
+    (Android) — provide non-animated state transitions.
+
+## Store Compliance
+
+### App Store (iOS)
+
+- **Privacy manifest (PrivacyInfo.xcprivacy):** required for all third-party SDKs
+  in the required reasons API list since 2024. Missing or incomplete manifests
+  cause automated rejection.
+- **Tracking permission (ATT):** `NSUserTrackingUsageDescription` required; present
+  the `requestTrackingAuthorization` prompt only after a pre-permission dialog
+  explaining value. Cross-app tracking without permission is a Review guideline 5.1.2
+  violation.
+- **Age rating:** accurately declare content; incorrect rating triggers removal.
+- **Export compliance:** encryption usage requires annual self-classification or
+  the `ITSAppUsesNonExemptEncryption = NO` plist key when only standard
+  platform APIs (HTTPS, Keychain) are used.
+- **Review guideline 4.2 (Minimum Functionality):** content-only apps without
+  native functionality will be rejected.
+
+### Play Console (Android)
+
+- **Data safety section:** every data type collected or shared must be declared;
+  inconsistency with actual behavior triggers enforcement action.
+- **Target API level:** must target the current year's required API level within
+  the grace period. Apps targeting older levels are hidden from new installations.
+- **Background location:** requires `ACCESS_BACKGROUND_LOCATION` permission with a
+  policy URL and a specific use-case justification in the declaration.
+- **Exact alarms (Android 12+):** `USE_EXACT_ALARM` or `SCHEDULE_EXACT_ALARM`
+  requires justification; calendar and reminder apps qualify; background sync
+  does not.
+
+## Anti-patterns
+
+| Anti-pattern | Why it fails |
+|---|---|
+| Blocking the main thread (UI thread) with I/O or CPU work | Causes ANR (Android) / watchdog kills (iOS); 5-second main-thread block is observable by App Store Review automated tools |
+| Ignoring memory pressure signals (`applicationDidReceiveMemoryWarning` / `onTrimMemory`) | Image caches grow unbounded; app is killed by the OS in background; users blame "battery drain" |
+| Storing credentials, tokens, or PII in `UserDefaults`, `SharedPreferences`, or unprotected files | Accessible to any other app on jailbroken / rooted devices; violates App Store guideline 5.1.1 |
+| Shipping `.apiKey` Claude auth in a release binary (`ClaudeForFoundationModels`) | The key is extractable from the shipped binary; anyone who extracts it makes requests billed to the adopter's Anthropic account. `.proxied(headers:)` through the adopter's backend is the only production auth |
+| No offline handling — assuming network is always available | Crashes or blank screens on airplane mode; fails Review on unreliable test networks; breaks accessibility (assistive tech users rely on cached content) |
+| Requesting sensitive permissions (location, camera, notifications) at app launch with no context | Permission denial rate is highest at launch; iOS 14+ enforces notification permission timing heuristics |
+| Using deprecated API without fallback | App is rejected or removed from store on next review cycle; no graceful runtime degradation |
+
+## Cross-References
+
+- `.claude/skills/core/security-and-auth/SKILL.md` — Keychain / Keystore token
+  storage, biometric auth, OAuth / PKCE flows, certificate pinning.
+- `.claude/skills/core/code-review-checklist/SKILL.md` — apply mobile-specific
+  checklist items during PR review: thread safety, memory leaks, permission
+  handling, test coverage floor.
+- `.claude/skills/frontend/accessibility-and-wcag/SKILL.md` — WCAG 2.2 detailed
+  compliance criteria and testing methodology applicable to web views embedded in
+  mobile apps.
+- `.claude/skills/core/llm-routing-and-finops/SKILL.md` — the CEO tiering table
+  that the on-device <-> Claude routing doctrine mirrors (cheapest capable tier
+  first, escalate on capability demand).
+
+## ADR Anchors
+
+- **ADR-058** (Brainstorm gate + two-pass adversarial review): mobile architecture
+  and platform-strategy decisions are L3+ and require the brainstorm gate before
+  plan execution. Two-pass adversarial review applies to any change touching the
+  offline-sync contract, store compliance declarations, or notification permission
+  surfaces.
+- **ADR-149** (model-id allowlist): `ClaudeModel(id:capabilities:)` explicit
+  capability declaration for model IDs not compiled into
+  `ClaudeForFoundationModels` is the in-app mirror of the framework's allowlist
+  doctrine — never guess what an unverified model ID accepts.

package/.claude/skills/domains/mobile/task-chains.yaml

@@ -0,0 +1,126 @@
+# Task chains — Mobile Squad
+# Domain-specific workflows that extend the universal .claude/task-chains.yaml.
+
+task_chains:
+  - id: mobile-api-contract-change
+    title: "Deploy a cross-platform API contract change (schema, auth, deep-links)"
+    whenToUse: |
+      A backend API endpoint that mobile clients consume is being changed in
+      a way that affects the contract: request or response schema change,
+      field rename, error code change, auth token format change, push
+      notification payload change, or deep-link format change. This chain
+      is triggered even for "minor" contract changes — a nullable field
+      becoming required breaks every older mobile client version still in
+      the App Store.
+    steps:
+      - id: 1
+        owner: "Santiago Reyes (Mobile Architect)"
+        action: "Contract change analysis: document exactly what is changing in the API contract and which mobile client versions are affected. Determine the minimum mobile client version that can handle the new contract. Assess how many active users are on older versions (MOB-001)."
+      - id: 2
+        owner: "Santiago Reyes"
+        action: "Versioning strategy: choose an approach — API versioning (new endpoint, old endpoint deprecated), field addition only (backward-compatible), or flag-gated rollout. Document the strategy. If the old app version will break, a new mobile release MUST ship first (MOB-001)."
+      - id: 3
+        owner: "Yui Nakamura (iOS Engineer)"
+        action: "iOS impact assessment: which iOS code paths consume the affected contract? Are there backward-compatibility shims needed? Does a new mobile client need to ship before the backend change? Set an iOS release timeline if required."
+      - id: 4
+        owner: "Damilola Adeyemi (Android Engineer)"
+        action: "Android impact assessment: mirror Yui's iOS assessment for Android. Are there ProGuard rules that affect the impacted code paths? Confirm Android release timeline if a new client must ship first (MOB-009)."
+      - id: 5
+        owner: "Santiago Reyes"
+        action: "Coordinated deployment plan: sequence the deployments. If both platforms need a new client first: (a) ship iOS and Android clients → (b) monitor adoption until >80% active users on new client (MOB-003) → (c) deploy backend contract change. Document go/no-go adoption criteria."
+      - id: 6
+        owner: "Priya Singh (Mobile QA Engineer)"
+        action: "Cross-platform contract test: test the new contract against the new mobile client AND the old mobile client. Old client behavior on new contract must be graceful degradation — not a crash or silent data loss (MOB-004)."
+      - id: 7
+        owner: "Santiago Reyes"
+        action: "Deep-link and push backward-compatibility check: if deep links or push payloads are affected, verify that the previous app version (still in App Store) handles the new format gracefully — either processes it correctly or ignores it safely (MOB-004)."
+      - id: 8
+        owner: "Staff Code Reviewer"
+        action: "Merge check: versioning strategy documented (MOB-001), old client tested against new contract (MOB-004), adoption gate defined if phased rollout required (MOB-003), certificate pinning coordination confirmed if TLS-related (MOB-002)."
+    verification: |
+      - API versioning strategy documented and approved by Santiago (MOB-001)
+      - Old mobile client version tested against new API contract (MOB-004)
+      - Adoption gate defined (>80%) if phased client rollout required (MOB-003)
+      - Both platforms have iOS and Android release timelines aligned
+      - Certificate pinning coordination plan if TLS-related (MOB-002)
+      - Graceful degradation confirmed for old app versions
+
+  - id: mobile-app-store-release
+    title: "Prepare and submit a mobile app release (iOS App Store + Android Play Store)"
+    whenToUse: |
+      A new version of the mobile app is being submitted to the App Store
+      and/or Play Store. Covers pre-submission checklist, build verification,
+      privacy and permission compliance, phased rollout configuration, and
+      post-release monitoring gate. Triggered for every production release,
+      including hotfixes.
+    steps:
+      - id: 1
+        owner: "Yui Nakamura (iOS Engineer)"
+        action: "iOS pre-submission checklist: verify PrivacyInfo.xcprivacy matches all privacy APIs used in the build (MOB-005); confirm all entitlements are actively used in this build (MOB-006); verify no sensitive data in UserDefaults (MOB-007); confirm NSUsageDescription strings are accurate for all permissions."
+      - id: 2
+        owner: "Damilola Adeyemi (Android Engineer)"
+        action: "Android pre-submission checklist: verify all AndroidManifest permissions have corresponding Play Console justifications (MOB-008); review ProGuard/R8 changes since last release (MOB-009); confirm no credentials in SharedPreferences (MOB-010); update Play Store data safety section if new data flows added."
+      - id: 3
+        owner: "Santiago Reyes (Mobile Architect)"
+        action: "Cross-platform parity check: confirm that the feature set and behaviour of this release is parity across iOS and Android. Any intentional asymmetry must be documented with a timeline for the other platform. Confirm no API contract changes were shipped without the coordinated rollout plan (MOB-001)."
+      - id: 4
+        owner: "Priya Singh (Mobile QA Engineer)"
+        action: "Physical device regression test: run the regression suite on the minimum-supported iOS device and minimum-supported Android device (MOB-012). Test accessibility (VoiceOver, TalkBack, Dynamic Type large), network degradation (offline, 3G), and cold start time. Sign off only on physical device results."
+      - id: 5
+        owner: "Beatrix Hoffmann (Mobile Release Manager)"
+        action: "Build preparation: confirm build number monotonicity (App Store rejects if build number ≤ previous submission), code signing configuration, release notes authored (don't skip — blank notes attract reviewer attention), and TestFlight / Internal Testing track verified."
+      - id: 6
+        owner: "Beatrix Hoffmann"
+        action: "Phased rollout configuration: configure App Store Connect and Play Console for phased rollout (1% first, auto-advance gates based on crash rate threshold). Define the crash-rate and ANR-rate gate criteria and monitoring responsibility (MOB-011)."
+      - id: 7
+        owner: "Priya Singh"
+        action: "Post-release monitoring (first 48 hours at 1% rollout): monitor crash rate, ANR rate (Android), and App Store review sentiment. If crash rate exceeds baseline +0.5%, halt rollout and notify Santiago (MOB-011)."
+      - id: 8
+        owner: "Staff Code Reviewer"
+        action: "Release gate sign-off: iOS checklist complete (MOB-005, MOB-006, MOB-007), Android checklist complete (MOB-008, MOB-009, MOB-010), physical device QA signed off (MOB-012), phased rollout configured (MOB-011), Santiago cross-platform parity confirmed."
+    verification: |
+      - iOS PrivacyInfo.xcprivacy updated for all privacy APIs (MOB-005)
+      - All iOS entitlements confirmed as actively used (MOB-006)
+      - Android restricted permissions have Play Console justifications (MOB-008)
+      - ProGuard/R8 changes audited for security-critical class impact (MOB-009)
+      - Physical device regression test passed on minimum-supported devices (MOB-012)
+      - Phased rollout configured with crash-rate gate (MOB-011)
+      - Cross-platform parity confirmed by Santiago
+
+  - id: mobile-security-posture-change
+    title: "Change mobile security configuration (certificate pinning, detection, Keychain/Keystore)"
+    whenToUse: |
+      Any change to the mobile security posture: certificate pinning
+      configuration, jailbreak/root detection logic, Keychain/Keystore
+      usage, auth token storage, or any security-relevant ProGuard/R8 rule.
+      High-risk: security regressions ship in a signed binary that cannot
+      be changed without going through App Store review.
+    steps:
+      - id: 1
+        owner: "Santiago Reyes (Mobile Architect)"
+        action: "Security change classification: document exactly what security control is changing and why. For any reduction in security posture (e.g. disabling a detection control), a formal security risk acceptance signed by the Owner is required before proceeding."
+      - id: 2
+        owner: "Santiago Reyes"
+        action: "Certificate pinning coordination (if applicable): issue 72-hour advance notice to iOS and Android teams. Draft the coordinated deployment plan (mobile client ships first, backend rotates after >90% adoption) (MOB-002)."
+      - id: 3
+        owner: "Yui Nakamura (iOS Engineer)"
+        action: "iOS Keychain review: if storage or retrieval of sensitive data is changing, confirm data is routed to Keychain with the correct accessibility level (kSecAttrAccessibleWhenUnlockedThisDeviceOnly for session-bound data). Audit any UserDefaults usage for sensitive keys (MOB-007)."
+      - id: 4
+        owner: "Damilola Adeyemi (Android Engineer)"
+        action: "Android Keystore review: if storage or retrieval of sensitive data is changing, confirm Android Keystore is used with appropriate hardware-backed flag. Review ProGuard/R8 rules for any rule that touches the affected security code path (MOB-009, MOB-010)."
+      - id: 5
+        owner: "Priya Singh (Mobile QA Engineer)"
+        action: "Security regression test: verify on a physical jailbroken/rooted device (or emulator with root detection test harness) that the security control functions as intended after the change. For certificate pinning changes, verify the old certificate is rejected after the rotation window."
+      - id: 6
+        owner: "Santiago Reyes"
+        action: "Final security review: confirm the change achieves the intended security outcome without introducing a regression in another control. If the change reduces security posture, confirm Owner sign-off is on record."
+      - id: 7
+        owner: "Staff Code Reviewer"
+        action: "Security merge gate: Santiago risk classification documented, certificate coordination plan if applicable (MOB-002), Keychain/Keystore usage confirmed for all sensitive data (MOB-007, MOB-010), ProGuard/R8 changes audited (MOB-009), Priya security regression test passed."
+    verification: |
+      - Security change documented with rationale
+      - Owner sign-off on file if security posture is being reduced
+      - Certificate pinning 72h notice issued and coordination plan executed (MOB-002)
+      - Keychain (iOS) / Keystore (Android) confirmed for all sensitive data (MOB-007, MOB-010)
+      - ProGuard/R8 changes audited for security-critical class paths (MOB-009)
+      - Physical device security regression test passed