Release New Version

Phase 4 — Execute (main repo)

Confirm once more before anything irreversible. Then:

1. Update the code-line badge so it lands in the release commit:

   bash scripts/update-code-badge.sh   # relative to the skill directory; the script cd's to the repo root itself

   It recounts production Kotlin + Python lines (excluding tests / build / generated) and rewrites the kotlin-XX.Xk badge in both READMEs. Include the README changes in the release commit.
2. Update versionCode = <new code>, versionName = "<new name>" in app/build.gradle.kts, plus any other files from the approved list. Do not touch any other build config.
3. Update module structure in both READMEs (README.md and README_CN.md) and AGENTS.md if modules were refactored or new modules were added.
4. Audit and complete multilingual string parity across all modules. Daily development only implements English, leaving other locales incomplete. Inspect the actual supported locales across modules (e.g. via ls on res/values-*) and fill in missing strings. Translate contextually based on UI placement and function; avoid blind machine translation.
5. Commit: release: bump to <new name>, push to origin main.
6. Tag and push:

   git tag v<code>-<name>
   git push origin v<code>-<name>

   Tag push triggers CI: build → sign → create Release. CI reads signing config from GitHub Secrets; do not expect signing to work anywhere else.
7. Wait for CI:

   gh run list --workflow=release.yml --limit=1    # find the latest run
   gh run watch <run-id> --exit-status             # wait for it to finish
   gh run view <run-id> --log-failed               # on failure, read only the failed steps
   gh run rerun <run-id>                           # rerun after fixing

8. Replace CI-generated release notes (they are a PR list) with the approved draft:

   gh release edit <tag> -R niki914/zafiro --title "Release - <name>" --notes "<approved notes>"

   CI generates the release title as the raw tag name (e.g. v9-1.2.0); the historical format is Release - <name> — pass --title explicitly or the wrong title stays.

Release notes format

Historical releases follow this format strictly (no deviations):

• English first, Chinese after, separated by a single --- line. Never reverse the order.
• No language headers (no **English** / **中文** labels) — the notes start directly with the numbered list. Blank line separates the --- from the lists.
• The --title "Release - <name>" from step 8 is part of the format, not optional. Set the title via --title, never inside the release note body.

Phase 5 — Xposed repo (optional, ask first)

Ask: "这次要发 Xposed 仓库吗？" If no, state clearly "本次未发 Xposed 仓库" and stop. If yes:

# download the APK from the main repo release
gh release download <main-tag> -R niki914/zafiro -p "*.apk" --dir /tmp/

# create the Xposed release
gh release create <code>-<name> /tmp/<apk> \
  -R Xposed-Modules-Repo/com.niki914.nexus.agentic \
  --title "Release - <name>" \
  --notes "<approved notes>"

gh operates on the current repo's remote by default — external repos always need -R owner/repo, and the token must have write access there.

The Xposed notes use the same feature entries, but the closing line is 项目已开源：https://github.com/niki914/zafiro (and its English counterpart) instead of a contribution invitation.

Known pitfalls

• CI build failure: Aliyun Maven mirror 502. Overseas GitHub Actions runners intermittently fail on the Aliyun mirror if it is ordered before mavenCentral() / gradlePluginPortal() in settings.gradle.kts. Standard sources go first, Aliyun after. If CI fails on dependency resolution, check the mirror order.
• Tag already exists / CI failed and needs a re-trigger. The same tag cannot be pushed twice:

  git push origin :v<code>-<name>   # delete remote tag
  git tag -d v<code>-<name>         # delete local tag
  git tag v<code>-<name>            # re-tag at latest commit
  git push origin v<code>-<name>

Hard rules

• Never build locally. CI builds everything.
• Never modify versionName without explicit user approval.
• Never push a tag without showing the user the exact tag and target commit first.
• If any state is ambiguous (local ≠ remote, tag exists, CI red), stop and ask.