ci: auto-link release PR in prerelease GitHub Release notes (#225)

Prereleases (-rc.* / -beta.*) now get **Test plan & verification: #NNN**
prepended to the extracted release notes by the release workflow. The
testing plan itself lives in the PR body OUTSIDE the fenced markdown
block — checkboxes inside the fence render as code and lose
interactivity, so the convention is now: release notes inside the fence
(end-user audience), testing plan as plain markdown outside (clickable
checklist for the release engineer). The auto-link gives readers of the
GitHub Release one-click access to that checklist.

Updates the Releasing section of CLAUDE.md to spell out the split and
the auto-link behaviour so the next session doesn't re-derive it.

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

Author: psjostrom

.github/workflows/release.yml

@@ -55,10 +55,18 @@ jobs:
           # Look up the PR by the tagged commit SHA — the tag points to the squash-merge
           # commit on main, which maps to exactly one PR. Title-based search is too loose
           # (e.g. "Release v1.2.0" matches "Release v1.2.0-rc.2").
-          NOTES=$(gh api "repos/${{ github.repository }}/commits/${{ github.sha }}/pulls" \
-            -q '.[0].body' \
+          PR_DATA=$(gh api "repos/${{ github.repository }}/commits/${{ github.sha }}/pulls" --jq '.[0] // empty')
+          PR_NUMBER=$(echo "$PR_DATA" | jq -r '.number // empty')
+          NOTES=$(echo "$PR_DATA" | jq -r '.body // empty' \
           | sed -n '/^```markdown$/,/^```$/{ /^```/d; p; }')
 
+          # For prereleases, prepend a link to the release PR so the testing-plan
+          # checklist (which lives outside the fenced block) is one click away.
+          if [ -n "$NOTES" ] && [ -n "$PR_NUMBER" ] && [ -n "$PRERELEASE_FLAG" ]; then
+            NOTES=$(printf '**Test plan & verification:** [#%s](https://github.com/%s/pull/%s)\n\n---\n\n%s\n' \
+              "$PR_NUMBER" "${{ github.repository }}" "$PR_NUMBER" "$NOTES")
+          fi
+
           if [ -n "$NOTES" ]; then
             gh release create "${{ github.ref_name }}" \
               "$APK" \

CLAUDE.md

@@ -109,7 +109,10 @@ When a merge or push fails, ALWAYS check CI status (`gh pr checks`) and read the
 2. Create branch `release/vX.Y.Z` from main.
 3. Bump `versionName` in `app/build.gradle.kts`. Never bump `versionCode` (not on Google Play).
 4. Check docs for staleness against the changes (see Documentation Updates above).
-5. Create PR. Write release notes in the PR body inside a ` ```markdown ` fenced block — CI extracts this block and uses it as the GitHub Release body. If no fenced block is found, CI falls back to auto-generated notes from PR titles.
+5. Create PR with two distinct sections in the body:
+   - **Inside a ` ```markdown ` fenced block: release notes only** (end-user audience). CI extracts this block as the GitHub Release body. If no fenced block is found, CI falls back to auto-generated notes from PR titles.
+   - **Outside the fence: testing plan as plain markdown** (developer audience, lives in the PR forever). Checkboxes inside the fence render as code (uninteractive); putting the plan outside makes them clickable for tracking.
+   - For prereleases (`-rc.*` / `-beta.*`) CI auto-prepends `**Test plan & verification:** [#PR](url)` to the extracted release notes — don't add this manually.
 6. Merge PR, then tag: `git tag -a vX.Y.Z -m "vX.Y.Z" && git push origin vX.Y.Z`. CI builds the APK and creates the GitHub Release.
 7. Always create releases by pushing a version tag. Never use `gh release create` manually.