ceo-orchestration 1.0.0

package/.claude/skills/domains/marketing-global/skills/video-optimization-specialist/SKILL.md

@@ -0,0 +1,386 @@
+---
+name: video-optimization-specialist
+description: >
+  Long-form video discipline — YouTube-first, with application to
+  IG-Reels long-cuts and TikTok Stories — covering title and thumbnail
+  optimisation as a coupled pair, retention curve diagnostics, watch-time
+  architecture, A/B testing for packaging variants, end-screen and cards
+  strategy, and SEO-grounded discovery. Distinct from `tiktok-strategist`,
+  which governs the short-form completion-rate game; this skill governs
+  the long-form retention game where Average View Duration and binge
+  architecture are the primary algorithmic levers. Use when: designing
+  or auditing a YouTube content strategy, diagnosing retention cliff
+  patterns, scripting watch-time pacing for videos over three minutes,
+  building thumbnail iteration cycles, structuring end-screen binge chains,
+  or evaluating keyword research for video discoverability.
+owner: Marcus Alden (Video Optimization Specialist, domain persona)
+tier: domain:marketing-global
+scope_tags: [youtube, long-form-video, retention-curve, thumbnail-testing, watch-time, video-discoverability]
+inspired_by:
+  - source: msitarzewski/agency-agents/marketing/marketing-video-optimization-specialist.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: marketing-global
+priority: 8
+risk_class: low
+stack: []
+context_budget_tokens: 500
+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: []
+# --- K1 paths: native file-touch activation (PLAN-135 W3 unit k1a) ---
+paths:
+  - "**/youtube/**"
+  - "**/videos/**"
+  - "**/thumbnails/**"
+---
+
+# Video Optimization Specialist
+
+## Cardinal Rule
+
+Average View Duration is the primary algorithmic lever for long-form video.
+YouTube's recommendation engine evaluates absolute watch time — minutes
+delivered per impression — above raw view count or CTR. A ten-minute video
+watched to 80% completion signals more value than a twenty-minute video
+watched to 20%. Every structural decision — title, thumbnail, hook length,
+pacing cadence, chapter placement — MUST be evaluated against its projected
+effect on AVD before any other metric is applied. Reporting view count or
+CTR without AVD context is incomplete and MUST NOT be used as a standalone
+performance summary.
+
+---
+
+## Fail-Fast Rule
+
+A video MUST NOT be published without verifying the title-thumbnail pair
+as a single unit. Title and thumbnail are co-dependent packaging: a strong
+thumbnail with a weak title produces curiosity without context; a strong
+title with a weak thumbnail produces context without click signal. Both
+components MUST satisfy their individual gates AND the combined test: does
+the pair, read together in under two seconds, make an unambiguous promise
+that the video can keep? If the pair fails this test at review, packaging
+MUST be revised before scheduling. Publishing with unvalidated packaging
+and relying on post-publish impressions to detect failure wastes the
+first-48-hour velocity window that YouTube weights most heavily.
+
+---
+
+## When to Apply
+
+Activate this skill when the work involves any of the following:
+
+- Designing or auditing a YouTube content strategy that requires algorithm-
+  aware packaging, retention architecture, or discovery mechanics.
+- Diagnosing a retention cliff, low AVD, or suppressed impression share
+  on an active channel.
+- Scripting or reviewing the hook structure of a video longer than three
+  minutes where pacing across the full duration must be deliberate.
+- Building a thumbnail iteration cycle using the YouTube Test and Compare
+  feature or third-party A/B tooling.
+- Structuring end-screen binge chains or card sequences to extend session
+  time after video completion.
+- Evaluating keyword research and chapter metadata for video discoverability
+  in YouTube Search and Browse.
+- Advising on playlist architecture or series structure for long-form
+  content libraries.
+
+---
+
+## Title and Thumbnail Architecture
+
+Title and thumbnail function as a CTR-driving pair; they MUST be designed
+together and MUST NOT be iterated independently.
+
+**Title gates:**
+
+A title passes when it satisfies all four conditions: (1) it contains a
+primary keyword phrase that matches the search intent of the target
+audience; (2) it creates a curiosity gap, a stated benefit, or a named
+contrast — one dominant mechanism, not a combination; (3) it fits in
+sixty characters so it renders without truncation on mobile; (4) the
+implied promise is one the video can deliver in full before the end
+screen.
+
+**Thumbnail gates:**
+
+A thumbnail passes when: (1) the primary subject is identifiable at
+96 × 54 pixels — the size at which YouTube renders mobile suggestions;
+(2) on-screen text, if present, uses no more than four words and a
+minimum 36pt equivalent at full resolution; (3) the colour contrast
+between foreground and background exceeds a 4:1 ratio; (4) the visual
+and the title, read together, form a complete micro-story without
+redundancy — the thumbnail must add information the title omits.
+
+**Iteration cycle:**
+
+After the initial publish, packaging variants MUST be queued for
+the YouTube Test and Compare feature (minimum two thumbnail variants
+per test). The test window requires at least 2 000 impressions per
+variant to produce a statistically meaningful CTR difference. Replace
+the losing variant; do not retire the control until the challenger has
+sustained the CTR delta over a 72-hour window.
+
+---
+
+## Hook Discipline
+
+The first fifteen seconds of a long-form video are the retention
+determinant. Unlike short-form, where the three-second commit governs
+FYP distribution, long-form retention is evaluated against a graph
+that penalises drop-off in the first 30% of the video most severely.
+
+**Payoff promise:**
+
+The opening must state, visually or verbally, exactly what the viewer
+will gain by watching to the end. The promise must be specific enough
+to be falsifiable: "I will show you the three steps" is a promise; "let
+me share some thoughts" is not. Vague hooks depress early retention and
+signal to the algorithm that the packaging over-promised.
+
+**Curiosity gap:**
+
+After the payoff promise, the hook must withhold the mechanism — the
+specific method or reveal — long enough to establish context but not
+so long that the viewer infers the answer. The standard structure: state
+the problem, name the result, defer the method. The method arrives at
+or after the one-minute mark on videos over eight minutes.
+
+**Fake-pivot prohibition:**
+
+A hook that promises a resolution and then pivots to unrelated context
+before delivering any signal is a fake-pivot. Fake-pivots produce a
+retention cliff at 30–45 seconds that is algorithmically indistinguishable
+from a low-quality video. Fake-pivots MUST NOT appear in scripted content;
+if detected in a retention audit, the hook MUST be rewritten as a
+condition of the next upload.
+
+---
+
+## Retention Curve Optimisation
+
+The YouTube Studio retention graph provides a per-second audience drop-off
+curve for every video. Retention curve review MUST precede any script
+revision or packaging change.
+
+**Graph diagnostic table:**
+
+| Curve shape                   | Diagnosis                                      | Intervention                                           |
+|-------------------------------|------------------------------------------------|--------------------------------------------------------|
+| Sharp drop 0–15 s             | Hook failure or packaging-content mismatch     | Rewrite opening 15 s; audit title-thumbnail alignment  |
+| Gradual slope 15–60 s         | Context too long; value delivery too slow      | Move primary payoff signal before 60 s                 |
+| Cliff at 20–35% duration      | Mid-section has no secondary hook              | Insert partial reveal or chapter transition at cliff   |
+| Cliff at 50–60% duration      | Viewer inferred full resolution before end     | Restructure proof section; reserve key detail for end  |
+| Rewatch spike at one moment   | High-value moment identified by audience       | Promote as clip; use timestamp in description          |
+| Flat then cliff near end      | Strong content; end screen pacing too abrupt   | Add 30 s resolution + bridge to next suggested video   |
+
+**Intro length benchmark:**
+
+For videos over eight minutes, the intro — context-setting before the
+first value delivery — MUST be under 90 seconds. For videos between
+three and eight minutes, the intro ceiling is 45 seconds. Intros that
+exceed these thresholds without an embedded secondary hook produce a
+retention cliff at the boundary.
+
+---
+
+## Watch-Time Architecture
+
+The target for long-form content is 50% or above Average View Duration
+across the video library. Architecture decisions that affect AVD operate
+at three levels: pacing per minute, visual variety cadence, and chapter
+sequencing.
+
+**Pacing per minute:**
+
+Each minute of a long-form video must contain one of the following
+structural events to prevent attention decay: a new claim introduced,
+a contradiction or complication surfaced, a visual or tonal shift, or
+a partial resolution that resets the curiosity gap. Videos that run a
+single explanatory thread for more than 90 consecutive seconds without
+a structural event will register a consistent slope in the retention
+graph at that interval.
+
+**Visual variety cadence:**
+
+On-screen content MUST change at minimum every 30 seconds for tutorials
+and explainers. Acceptable change events: cut to B-roll, on-screen
+graphic, text callout, scene transition, or presenter angle change.
+Static talking-head video that exceeds 45 consecutive seconds without
+a visual change is a confirmed source of retention drop in long-form
+content across all topic categories.
+
+**Chapter sequencing:**
+
+Chapters must be ordered to sustain forward tension, not to achieve
+logical completeness. If the most compelling chapter is the fourth,
+promote its premise into the hook and structure earlier chapters as
+prerequisites that build anticipation for the fourth, not as standalone
+sections that stand before it by convention.
+
+---
+
+## End-Screen and Cards Strategy
+
+End-screens and cards extend session time by directing viewers to the
+next video or playlist before the session terminates. Session extension
+is a first-order ranking signal for the suggested algorithm.
+
+**End-screen architecture:**
+
+The end-screen zone begins at the 20-second mark before the video
+conclusion. MUST contain: one best-for-viewer video selection (YouTube
+algorithm choice enabled) AND one creator-specified video that continues
+the content thread the viewer just watched. Generic channel subscription
+CTAs in the end-screen zone without a specific video target are wasted
+surface.
+
+**Series structure:**
+
+Videos with defined series relationships MUST be grouped in a named
+playlist and the end-screen of each video in the series MUST link to
+the next episode. Unstructured playlists — thematic collections without
+sequential narrative — produce lower average session depth than series
+playlists by a measurable margin because viewers lack the expectation of
+sequential payoff.
+
+**Binge architecture:**
+
+A channel builds binge architecture when at least 30% of its videos
+contain explicit verbal bridges to a specific follow-on video in the
+final 90 seconds. The bridge must name the destination ("the next video
+covers the second technique") rather than offering a generic invitation
+("check out the playlist"). Named bridges convert at higher rates than
+generic CTAs because they re-establish a payoff promise for the next
+unit of attention.
+
+**Cards strategy:**
+
+Cards MUST be placed at moments of peak retention — rewatch spikes or
+the top of the retention curve plateau — not at low-retention valleys
+where the audience is already partially disengaged. A card placed at
+a cliff accelerates the exit; a card placed at a peak captures viewers
+at their highest engagement. Card timing MUST be audited against the
+retention graph, not placed by convention at 30% intervals.
+
+---
+
+## A/B Testing Framework
+
+Packaging variants — thumbnail and title permutations — are the highest-
+leverage A/B tests available in long-form video because packaging drives
+CTR, which initiates all subsequent retention and AVD measurement.
+
+**Test design:**
+
+Run one variable at a time: either a thumbnail variant with the title
+held constant, or a title variant with the thumbnail held constant.
+Testing both simultaneously prevents attribution of CTR delta to either
+variable. Each test requires a minimum of 2 000 impressions per variant
+before declaring a result.
+
+**First-3-day window:**
+
+YouTube allocates its highest impression share to a video in the first
+72 hours after publication. A/B tests that begin at publish and conclude
+within this window capture the audience segment most likely to convert to
+subscribers and influence the sustained recommendation share. Tests
+initiated after day 3 operate on a reduced impression pool and produce
+slower convergence.
+
+**Statistical significance threshold:**
+
+Declare a winner only when the CTR delta between variants exceeds 0.5
+percentage points and has held for 72 consecutive hours of active testing
+(minimum 1 000 impressions per variant per 24-hour period). Declaring
+winners on fewer than 1 000 impressions per variant produces false
+positives that replace a performing packaging with an under-tested one.
+
+**Title variant types to test:**
+
+Curiosity-gap titles versus benefit-led titles are the most reliably
+distinct test pairs; curiosity-gap tends to outperform in discovery
+(Browse and Suggested) while benefit-led tends to outperform in Search.
+The dominant traffic source for the channel determines which variant
+class to default when resources allow only one title.
+
+---
+
+## SEO and Discovery
+
+Video discoverability operates on two distinct ranking systems: YouTube
+Search (query-intent matching) and Browse/Suggested (behavioural
+affinity matching). A video optimised for one system is not automatically
+optimised for the other.
+
+**Description strategy:**
+
+The first two lines of the description are rendered in search snippets
+before the fold. These lines MUST contain the primary keyword phrase,
+a secondary synonym phrase, and the core value proposition of the video.
+Auto-generated descriptions from transcript tools MUST NOT be used
+without manual revision; they rarely front-load keyword density and
+produce descriptions that are indistinguishable from boilerplate.
+
+**Chapter metadata:**
+
+Chapters, declared via timestamps in the description, enable YouTube to
+surface individual chapter segments in Google Video search results.
+Every video over five minutes MUST include chapters. Chapter titles MUST
+be keyword-conscious, not conversational summaries; "How to fix render
+errors" outperforms "Fixing the errors I mentioned" for chapter-level
+search indexing.
+
+**Keyword research protocol:**
+
+Keyword research for each video MUST be performed against the specific
+niche of the video, not the channel's general topic. Tools that surface
+search volume and competition at the YouTube-native level (not web search
+proxies) MUST be used. Auto-generated keyword lists from general-purpose
+SEO tools are advisory inputs, not direct tag lists; every tag applied
+MUST be reviewed for channel-topic relevance before publishing.
+
+---
+
+## Anti-patterns
+
+| Anti-pattern                          | Failure mode                                                                     | Correct behaviour                                                               |
+|---------------------------------------|----------------------------------------------------------------------------------|---------------------------------------------------------------------------------|
+| Clickbait without payoff              | Audience infers mismatch; dislike ratio rises; YouTube reduces recommendation share | Title and thumbnail promise MUST match video content exactly                   |
+| Ignoring CTR below 4%                 | Low CTR suppresses impression allocation; video never enters growth loop         | Diagnose packaging failure before attributing to topic or content quality       |
+| No thumbnail iteration                | Single thumbnail locks in suboptimal CTR indefinitely                            | Queue A/B test within 24 hours of publish using Test and Compare                |
+| Padded runtime to meet monetisation   | AVD percentage drops as padding is detected; algorithmic ranking penalises ratio | Cut to minimum runtime that delivers the full promised value without padding    |
+| Broken playlist structure             | Viewers exit after one video; session depth collapses; suggested algorithm weakens | Every series video MUST link forward; playlists MUST have sequential logic     |
+| Auto-generated descriptions published | Boilerplate descriptions reduce keyword density; search indexing weakens         | Manual description review is non-negotiable for every upload                   |
+| Generic end-screen CTAs               | "Subscribe and like" without video destination wastes session extension window   | Always specify a named destination video in the verbal bridge and end-screen    |
+
+---
+
+## Cross-References
+
+- `domains/marketing-global/skills/tiktok-strategist` — Short-form
+  completion-rate mechanics, hook architecture for vertical video, trend
+  velocity strategy; governs the FYP distribution model distinct from
+  YouTube's AVD-weighted ranking.
+- `domains/marketing-global/skills/podcast-strategist` — Long-form audio
+  content architecture, episode structure, and listener retention patterns;
+  structural parallels with watch-time sequencing and binge mechanics.
+- `domains/marketing-global/skills/content-creator` — Long-form to
+  short-form repurposing strategy, editorial calendar integration, and
+  narrative structure that feeds video scripting upstream.
+
+---
+
+## ADR Anchors
+
+- **ADR-058** — Creative authorship and structural-inspiration licensing
+  policy; governs `inspired_by` attribution requirements for domain skill
+  files derived from upstream open-source agent corpora.

package/.claude/skills/domains/mobile/examples/PLAN-EXAMPLE-MOB.md

@@ -0,0 +1,129 @@
+---
+plan_id: PLAN-EXAMPLE-MOB
+title: "Coordinate cross-platform auth token schema migration and App Store release"
+status: draft
+owner: ceo
+level: L3
+squad: mobile
+profile: core,mobile
+created_at: 2026-05-10
+---
+
+# Example PLAN — Auth Token Schema Migration (Cross-Platform Coordinated)
+
+> **This is an illustrative example**, not a real plan. It shows
+> how the mobile squad coordinates on a cross-platform API contract
+> change that touches all three VETO scopes: cross-platform contract
+> governance (Santiago), iOS App Store compliance (Yui), and Android
+> Play Store compliance (Damilola).
+>
+> Exemplar pattern derived from:
+> `.claude/skills/domains/edtech/examples/PLAN-EXAMPLE.md`
+
+## 1. Problem
+
+The auth service is migrating from JWT tokens with 1-hour expiry and a
+single `scope` string field to a new token format with 15-minute access
+tokens, a separate refresh token stored in a dedicated endpoint, and a
+`scopes` array (breaking the existing string field). The new format also
+adds device fingerprinting to the refresh grant to support suspicious-
+login detection. Both iOS and Android clients consume the token directly.
+
+Sources:
+- Auth service: new token format with breaking schema change (string → array)
+- iOS client: consumes `scope` string in the session manager
+- Android client: consumes `scope` string in OkHttp interceptor
+- 78% of active users are on a mobile app version that cannot parse the
+  new `scopes` array format without crashing
+
+## 2. Scope
+
+**In:**
+- New auth token schema: `access_token` (15min), `refresh_token` endpoint,
+  `scopes` array replacing `scope` string
+- iOS client update: parse `scopes` array, store `refresh_token` in
+  Keychain (not UserDefaults), implement token refresh flow
+- Android client update: update OkHttp interceptor, store `refresh_token`
+  in Android Keystore, update ProGuard rules for new auth classes
+- Coordinated backend deployment: ship mobile clients first, reach >80%
+  adoption, then cut over backend to new token format
+- App Store and Play Store submissions for both updated clients
+
+**Out:**
+- Auth service PKCE implementation (separate security initiative)
+- Session management UI (separate product feature)
+- Web client token migration (separate frontend team)
+
+## 3. Squad assignments
+
+| Phase | Owner | Deliverable |
+|---|---|---|
+| P1 — Contract analysis | Santiago Reyes | Versioning strategy; old-client backward-compatibility plan (MOB-001) |
+| P2 — iOS implementation | Yui Nakamura | `scopes` array parsing; `refresh_token` in Keychain; PrivacyInfo review (MOB-007) |
+| P3 — Android implementation | Damilola Adeyemi | OkHttp interceptor; Keystore for `refresh_token`; ProGuard audit (MOB-010, MOB-009) |
+| P4 — QA cross-platform | Priya Singh | Old client against new backend (graceful degradation); new client regression on min-supported devices (MOB-012) |
+| P5 — App Store submissions | Beatrix Hoffmann | iOS + Android phased rollout with crash-rate gate (MOB-011) |
+| P6 — Adoption monitoring | Santiago Reyes | Monitor until >80% active users on new client before backend cutover (MOB-003) |
+| P7 — Backend cutover | Auth team + Santiago | Backend token format switch with Santiago sign-off on adoption gate |
+| P8 — Launch review | CEO + all VETO holders | Santiago + Yui + Damilola sign-off |
+
+## 4. Risk axes and VETO holders
+
+- **Santiago Reyes (Mobile Architect):** `scope` → `scopes` is a breaking
+  schema change → BLOCK if backend cutover begins before >80% of active
+  users are on the new mobile clients (MOB-003). Old client on new backend
+  must degrade gracefully → BLOCK if old iOS or Android client crashes or
+  silently logs users out when it receives the new token format (MOB-001).
+- **Yui Nakamura (iOS Engineer):** `refresh_token` must be stored in
+  Keychain, not UserDefaults → BLOCK if any iOS code stores the refresh
+  token outside the Keychain (MOB-007). PrivacyInfo.xcprivacy unchanged
+  (no new privacy APIs) — but App Store submission checklist still required
+  (MOB-005, MOB-006).
+- **Damilola Adeyemi (Android Engineer):** `refresh_token` must be stored
+  in Android Keystore → BLOCK if stored in SharedPreferences (MOB-010).
+  ProGuard rules touching the new auth interceptor must be audited →
+  BLOCK if any `-keep` rule is added without security review of the
+  affected class (MOB-009).
+
+## 5. Task chains invoked
+
+- `mobile-api-contract-change` — primary chain for the schema migration
+  and coordinated deployment sequencing
+- `mobile-app-store-release` — for both iOS and Android phased rollout
+  submissions
+- `mobile-security-posture-change` — invoked for the Keychain/Keystore
+  storage change and ProGuard/R8 audit
+
+## 6. Acceptance
+
+- Old iOS/Android client (78% of active users) degrades gracefully when
+  receiving new token format — tested on physical device (MOB-001)
+- Backend cutover does not begin until >80% of active users are on the
+  new client versions (MOB-003)
+- iOS `refresh_token` stored in Keychain with `kSecAttrAccessibleWhenUnlockedThisDeviceOnly`
+  — no UserDefaults usage for any auth credential (MOB-007)
+- Android `refresh_token` stored in Android Keystore (hardware-backed
+  on supported devices) — no SharedPreferences usage (MOB-010)
+- Android ProGuard/R8 rules for new auth interceptor classes audited by
+  Damilola before merge (MOB-009)
+- Both iOS and Android clients submitted with phased rollout: 1% → crash-rate
+  gate → 10% → gate → 50% → 100% (MOB-011)
+- Physical device regression test passed on minimum-supported devices for
+  both platforms (MOB-012)
+
+## 7. Metrics
+
+- Client adoption rate: dashboard tracking % of active users on new client
+  (gate at 80% before backend cutover)
+- Crash rate at each phased rollout gate (target: ≤ baseline +0.5%)
+- **Token refresh success rate** (monitored post-cutover — tracks whether
+  the 15-minute access token + refresh flow is working for all users)
+
+## 8. References
+
+- `.claude/skills/domains/mobile/skills/mobile-app-builder/SKILL.md`
+- `.claude/skills/domains/mobile/task-chains.yaml` — `mobile-api-contract-change`
+- `.claude/skills/domains/mobile/task-chains.yaml` — `mobile-app-store-release`
+- `.claude/skills/domains/mobile/task-chains.yaml` — `mobile-security-posture-change`
+- Apple Developer Documentation: Keychain Services — kSecAttrAccessibleWhenUnlockedThisDeviceOnly
+- Android Developers: Android Keystore System hardware-backed key guarantees

package/.claude/skills/domains/mobile/pitfalls.yaml

@@ -0,0 +1,69 @@
+# Pitfalls Catalog — Mobile Squad
+# Loaded alongside the universal catalog when the mobile profile is
+# installed. Format mirrors .claude/pitfalls-catalog.yaml:
+# id, rule, whenToUse, agents.
+
+pitfalls:
+  # === CROSS-PLATFORM API CONTRACT ===
+  - id: MOB-001
+    rule: "NEVER change a cross-platform API contract (request/response schema, error codes, auth token format, push notification payload, deep-link format) server-side without a versioning strategy that supports the currently-live app version for at least one full App Store review cycle (7 days minimum). Users on the previous app version are still in production."
+    whenToUse: "any backend API change that mobile clients consume; any schema migration or field rename in a mobile-facing endpoint"
+    agents: [Santiago Reyes]
+
+  - id: MOB-002
+    rule: "Certificate pinning changes MUST be coordinated with 72-hour advance notice to all platform teams and deployed in a coordinated rollout (mobile client ships first, backend rotates after client adoption exceeds 90%). An uncoordinated certificate rotation causes a 100% mobile app outage until an emergency hotfix clears App Store review."
+    whenToUse: "any backend TLS certificate rotation; any change to mobile certificate pinning configuration"
+    agents: [Santiago Reyes, Yui Nakamura, Damilola Adeyemi]
+
+  - id: MOB-003
+    rule: "Auth token schema changes (scopes, expiry window, format, refresh grant type) MUST NOT be deployed server-side until both iOS and Android clients implementing the new schema have shipped AND have reached >80% adoption among active users. A token format mismatch logs out users silently."
+    whenToUse: "any auth service change that affects the token issued to mobile clients; any token refresh flow change"
+    agents: [Santiago Reyes]
+
+  - id: MOB-004
+    rule: "Deep-link format and push notification payload schema changes MUST include backward-compatible handling for users on the previous app version still in the App Store. A deep link that works in v2.0 but returns a blank screen in v1.9 (still live in the App Store) is a user-facing regression with no fast fix path."
+    whenToUse: "any deep-link scheme change; any push notification payload schema change"
+    agents: [Santiago Reyes, Priya Singh]
+
+  # === IOS APP STORE COMPLIANCE ===
+  - id: MOB-005
+    rule: "Every API that accesses privacy-sensitive data (camera, microphone, location, contacts, photo library, health data) MUST be declared in PrivacyInfo.xcprivacy and in the App Store privacy nutrition label BEFORE submission. An undisclosed privacy API access triggers App Store rejection and, if the app slips through, App Store removal."
+    whenToUse: "any new iOS feature that accesses privacy APIs; any App Store submission"
+    agents: [Yui Nakamura]
+
+  - id: MOB-006
+    rule: "App Store entitlements MUST match what the app actively uses. An entitlement present in the provisioning profile but not used in the current build triggers App Store rejection. Remove unused entitlements before submission — leftover entitlements from removed features are a common rejection cause."
+    whenToUse: "any iOS build submitted for App Store review; any entitlement addition or removal"
+    agents: [Yui Nakamura]
+
+  - id: MOB-007
+    rule: "Sensitive data on iOS MUST be stored in the Keychain — never in UserDefaults, NSCache, or NSUserDefaults. UserDefaults is world-readable on jailbroken devices. Auth tokens, session cookies, API keys, and any PII that persists between sessions belong in the Keychain."
+    whenToUse: "any iOS code that persists sensitive state between app launches; any data storage decision for credentials or PII"
+    agents: [Yui Nakamura, Santiago Reyes]
+
+  # === ANDROID PLAY STORE COMPLIANCE ===
+  - id: MOB-008
+    rule: "Every Android permission declared in AndroidManifest.xml MUST correspond to a Play Console use-case justification for restricted permissions (background location, READ_CONTACTS, RECORD_AUDIO, etc.). A restricted permission declared without Play Console justification triggers immediate Play Store removal, not a warning."
+    whenToUse: "any new permission added to AndroidManifest.xml; any Play Store submission for an app with restricted permissions"
+    agents: [Damilola Adeyemi]
+
+  - id: MOB-009
+    rule: "ProGuard/R8 rules that add `-keep` or `-dontwarn` for security-critical classes (certificate validation, root detection, cryptographic operations, SSL socket factories) MUST be audited before being merged. A ProGuard rule that strips root detection or disables certificate validation is a security regression that ships silently in a release build."
+    whenToUse: "any ProGuard/R8 configuration change; any build configuration change affecting code shrinking"
+    agents: [Damilola Adeyemi, Santiago Reyes]
+
+  - id: MOB-010
+    rule: "Sensitive credentials on Android MUST be stored in the Android Keystore — never in SharedPreferences (even encrypted SharedPreferences has weaker guarantees than Keystore for secrets). The Android Keystore provides hardware-backed protection on supported devices."
+    whenToUse: "any Android code that persists credentials, auth tokens, or API keys between app launches"
+    agents: [Damilola Adeyemi, Santiago Reyes]
+
+  # === RELEASE AND QA DISCIPLINE ===
+  - id: MOB-011
+    rule: "Mobile releases MUST use phased rollout (1% → 10% → 50% → 100%) with crash-rate and ANR-rate gates between phases. A crash rate increase >0.5% over baseline at any phase gate pauses the rollout. 'Ship to 100% immediately' is not an option for any release that hasn't completed phased rollout at the prior phase."
+    whenToUse: "any App Store or Play Store release rollout configuration; any request to skip or accelerate phased rollout"
+    agents: [Beatrix Hoffmann, Priya Singh]
+
+  - id: MOB-012
+    rule: "QA on physical devices — including the oldest device in the app's support matrix — is REQUIRED before any App Store or Play Store submission. Simulator testing is insufficient for memory footprint, battery impact, and hardware-specific behaviour. If no physical device is available for the minimum-supported device, that device must be removed from the support matrix."
+    whenToUse: "any pre-release QA sign-off; any App Store / Play Store build preparation"
+    agents: [Priya Singh, Beatrix Hoffmann]