From 2d2ec2eb7ab8cd640fcae46946c0728968310d83 Mon Sep 17 00:00:00 2001 From: DIYgod Date: Fri, 29 May 2026 21:48:12 +0800 Subject: [PATCH] docs(release): clarify mobile OTA runtime selection --- .agents/skills/mobile-release/SKILL.md | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/.agents/skills/mobile-release/SKILL.md b/.agents/skills/mobile-release/SKILL.md index 8c30f1a72..e6ff53ad5 100644 --- a/.agents/skills/mobile-release/SKILL.md +++ b/.agents/skills/mobile-release/SKILL.md @@ -83,7 +83,17 @@ The CI release flow is file-driven: ### Determine the target runtime -If recommending `ota`, derive the target store binary version from recent `origin/mobile-main` releases and propose it as the `runtimeVersion`. +If recommending `ota`, derive the target runtime from the store binaries that users currently have installed, not from the new release version, latest mobile tag, or latest OTA release. + +1. Check the public store versions first: + ```bash + curl --fail --silent --show-error https://ota.folo.is/versions | jq '.store.mobile' + ``` +2. Cross-check the store runtime model in `apps/mobile/app.config.base.ts`. Today the mobile runtime defaults to the binary package version unless `OTA_RUNTIME_VERSION` is explicitly set during an OTA export. +3. Use the current App Store / Google Play binary version as the OTA `runtimeVersion`. Example: if the stores still show `0.5.0`, an OTA release for `0.5.4` must use `"runtimeVersion": "0.5.0"` so existing store users can receive it. +4. If iOS and Android store versions differ, or if the target installed runtime is not clear, stop and ask the user. The release plan supports only one OTA `runtimeVersion`; do not guess or silently pick the newest version. + +Never choose the previous OTA release version just because it is the latest working manifest. A runtime mismatch publishes valid assets that only newer binaries can see, leaving current store users stuck on the older OTA. If you cannot determine the runtime confidently, stop and ask the user to confirm it. @@ -190,6 +200,8 @@ Examples: - trigger OTA publish only - no store builds +Do not require live OTA manifest verification during release PR preparation. The user manually merges the PR later, so the OTA publish happens after this workflow finishes and there may be a time gap before the Worker syncs. If the user later asks to check the rollout, verify the workflow run, GitHub Release assets, and `/manifest` at that time. + ## References - Bump config: `apps/mobile/bump.config.ts`