feat(release): add fastlane ship lanes and end-to-end release pipeline docs

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

.codex/skills/release-mobile/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: release-mobile
-description: Prepare and verify Sauci iOS or Android releases. Use for versioning, EAS/native builds, Fastlane upload, release notes, or store submission preparation.
+description: Prepare, verify, and ship Sauci iOS or Android releases end to end. Use for versioning, EAS/native builds, store uploads, App Review / Play review submission, and rollout.
 ---
 
 # Mobile release
@@ -9,6 +9,41 @@ Read `docs/releasing.md`, `apps/mobile/RELEASING.md` when present, and the mobil
 scoped instructions. Confirm target platform and release profile. Run repository
 verification plus a native acceptance pass before starting a release build.
 
+## OTA update vs full store release
+
+Choose the delivery mechanism before doing anything else; they are different
+pipelines with different blast radii. `docs/mobile-ota.md` is the authority.
+
+- **OTA update** (`npm run ota:publish:<env>` in `apps/mobile`): ships only the
+  JavaScript bundle and assets to builds already installed on devices. No store
+  review, live within minutes, and rolled back by repointing the XPREM channel
+  at a previous update. Valid only when the change touches no native code, no
+  native dependency, no `ios/`/`android/` project files, and no config that
+  alters the native binary. The OTA runtime version equals the public app
+  version, so an OTA update can only reach installs of the current
+  `expo.version`.
+- **Full store release** (this skill): a new signed binary through App Store
+  Connect and Google Play, including review. Required whenever native code,
+  native dependencies, the checked-in native projects, Expo SDK, permissions,
+  entitlements, or `expo.version` change. Rollback is coarser: Play staged
+  rollouts can be halted, iOS phased release can be paused, and a bad release is
+  otherwise superseded by shipping the next version.
+
+When a change qualifies for OTA, prefer OTA unless the user asks for a store
+release. Never present an OTA publish as a store release or vice versa; report
+which mechanism was used.
+
+## Authorization
+
+An explicit request for a mobile release authorizes the complete pipeline for
+the stated platforms: version bump, build, verification, store upload, review
+submission (App Review / Google Play review), and rollout — including full
+production rollout. Rollout is recoverable by design (staged-rollout halt,
+phased-release pause, OTA supersession, or the next store version), so do not
+pause to re-confirm these steps; execute them and report. A request that
+explicitly narrows scope (for example "upload only", "TestFlight only", or a
+named track) still bounds what you do.
+
 Before a build from the current upstream branch, fetch, require a clean worktree,
 and prove `HEAD` matches its upstream. The `generate-release` skill may instead
 build a clean, scoped release-preparation commit that descends directly from that
@@ -17,37 +52,41 @@ verified EAS version metadata. Sauci tracks its native iOS and Android projects,
 so routine release builds must package those checked-in sources. Do not run
 `expo prebuild` first; native regeneration is a separate reviewed change.
 
-Use the package scripts in `apps/mobile/package.json`; they create artifacts only.
-An explicit request for a mobile release, upload, or store-submission workflow
-authorizes the requested store upload within its stated platform and destination
-scope. Building an artifact alone does not authorize an upload.
+Use the package scripts in `apps/mobile/package.json` to build artifacts and the
+Fastlane lanes in `apps/mobile/fastlane/Fastfile` to upload, submit, and roll
+out.
 
-## Upload execution
+## Upload and submission execution
 
-Before an external upload, independently verify and report:
+Verification before upload is unchanged and mandatory. Independently verify and
+report:
 
 - the platform, exact artifact path, bundle/package identifier, public version,
   build number, signature identity, and SHA-256 digest;
-- the exact destination and resulting state: Google Play internal-track draft or
-  App Store Connect/TestFlight processing;
-- that the upload does not authorize a public rollout or App Review submission.
+- the exact destination and resulting state: which Play track and rollout
+  status, or App Store Connect version state and whether App Review submission
+  and automatic release are included.
 
-For iOS, inspect the current App Store Connect automatic-distribution behavior
-before uploading. If the build would be distributed automatically, report the
-exact TestFlight groups or testers. If the effect cannot be established, stop;
-changing an automatic-distribution setting is a separately authorized action.
+Once these details match the request, proceed through upload, review
+submission, and rollout without requesting further confirmation.
 
-Once these details match the user's stated scope, upload without requesting a
-second confirmation. Run `eas submit` with the explicit
-`--platform`, `--profile production`, `--path`, and `--wait` arguments; never
-select `--latest`. If the result is ambiguous, inspect EAS and the store before
-doing anything else; do not retry unless the user explicitly authorizes another
-upload.
+- **Android**: `bundle exec fastlane android release aab:<absolute path>`
+  commits the release on the production track (pass `track:` to target another
+  track, `rollout:0.1` for a staged rollout). Play review runs automatically;
+  rollout proceeds on approval. Use the `upload` lane only when the request is
+  explicitly upload-only.
+- **iOS**: `bundle exec fastlane ios release ipa:<absolute path>` uploads,
+  creates the App Store version, submits for App Review, and releases
+  automatically on approval (pass `phased_release:true` for a 7-day phased
+  release, `release_notes:"..."` for What's New). Use the `upload` lane for
+  TestFlight-only requests. `eas submit` remains valid for upload-only flows;
+  when used, pass explicit `--platform`, `--profile production`, `--path`, and
+  `--wait` — never `--latest`.
 
-Apply this policy to every upload method, including EAS, Fastlane, Xcode
-Organizer, and the store consoles. A public rollout, App Review submission, or
-additional TestFlight distribution requires separate explicit authorization
-unless it was expressly included in the original request.
+If an upload or submission command returns an ambiguous result, inspect EAS and
+the store before doing anything else; do not retry blind. After submission, read
+back the store state (Play Console track status / App Store Connect version
+state) and report it.
 
 Preserve platform signing and local EAS versioning. After a build, verify that
 tracked changes are limited to the expected version metadata, then independently
@@ -55,5 +94,6 @@ read the artifact version and signature. For an iOS IPA, inspect every packaged
 app extension as well as the containing app and require matching
 `CFBundleShortVersionString` and `CFBundleVersion` values. Treat Xcode archive
 warnings as diagnostic evidence, not the final artifact state: decide whether to
-reject or rebuild only after reading the exported IPA itself. Report the artifact,
-version/build number, upload result when authorized, and store read-back state.
+reject or rebuild only after reading the exported IPA itself. Report the
+artifact, version/build number, upload and submission results, rollout state,
+and store read-back state.