Best possible solution:

Merge the docs correction after normal docs review so release operators see the Android opt-in in RELEASING alongside the existing CI docs.

Do we have a high-confidence way to reproduce the issue?

Not applicable as a docs-only PR. The source mismatch is verifiable by comparing ci.yml's include_android default false with current RELEASING wording that says Android runs by default.

Is this the best way to solve the issue?

Yes. Updating RELEASING is the narrowest maintainable fix because the workflow source and docs/ci.md already define the include_android contract.

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 257b251e2690.

Label changes:

• add P3: This is a low-risk documentation correction for release operator guidance with no runtime or config change.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: Real behavior proof is not required because this PR only changes files under docs/.

Label justifications:

• P3: This is a low-risk documentation correction for release operator guidance with no runtime or config change.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: Real behavior proof is not required because this PR only changes files under docs/.

PR surface:

Docs +7. Total +7 across 1 file.

What I checked:

• PR diff is focused on release docs: The PR changes only docs/reference/RELEASING.md, replacing Android-by-default wording with include_android=true guidance in the manual CI sections. Public docs: docs/reference/RELEASING.md. (docs/reference/RELEASING.md:209, 4a0e90c303be)
• Current release guide still has the mismatch: Current main says manual CI forces Android and shows a direct CI example without include_android=true, so the PR is not already implemented on main. Public docs: docs/reference/RELEASING.md. (docs/reference/RELEASING.md:212, 257b251e2690)
• CI input default is false: ci.yml defines workflow_dispatch include_android with default false, supporting the PR's correction that standalone manual CI does not run Android by default. (.github/workflows/ci.yml:11, 257b251e2690)
• CI manifest gates Android on include_android: The manual CI manifest sets OPENCLAW_CI_RUN_ANDROID from inputs.include_android for workflow_dispatch, then uses that value to create the Android job matrix. (.github/workflows/ci.yml:162, 257b251e2690)
• Full Release Validation passes the Android opt-in: The umbrella workflow dispatches ci.yml with -f include_android=true, matching the PR's statement that the umbrella includes Android coverage. (.github/workflows/full-release-validation.yml:399, 257b251e2690)
• Sibling CI docs already state the same contract: docs/ci.md already says standalone manual CI uses Android only with include_android=true and the full release umbrella enables Android, so the PR aligns RELEASING with existing docs. Public docs: docs/ci.md. (docs/ci.md:114, 257b251e2690)

Likely related people:

• steipete: GitHub commit history shows @steipete authored the include_android CI change and multiple recent release workflow/docs changes around this surface. (role: release CI behavior owner; confidence: high; commits: 6a4c866b6a8b, ed283490b542, a355c8897d1a; files: .github/workflows/ci.yml, .github/workflows/full-release-validation.yml, docs/ci.md)
• vincentkoc: GitHub path history shows recent release-guide and release-CI commits by @vincentkoc, including updates to docs/reference/RELEASING.md. (role: recent release docs and CI contributor; confidence: medium; commits: e74d98bd656a, f5a7f613ee4d, c38b5033e64b; files: docs/reference/RELEASING.md, .github/workflows/full-release-validation.yml)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.