Adds a mandatory pre-tag step to the release process: build the R8-shrunk release candidate and smoke-test it on a real device, including a first-run / permission-not-granted state. The v2.7.0 launch crash (calendar observer registered before the permission gate) reached users because it only manifests in the minified release build on a device without the permission already granted — the debug build and an already-permissioned phone both hid it. - New `releaseTest` build type: same R8 shrinking + obfuscation as `release`, but debug-signed with a `.releasetest` applicationId suffix so it installs alongside the production and debug apps. Never published; CI only ever builds the real `release` variant from the tag. - scripts/verify-release.sh: builds + installs `releaseTest` and resets it to a first-run state, with an on-device checklist. - docs/RELEASING.md: formalize the release/vX.Y.Z branch flow and the on-device verification gate before tagging. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Documentation map
Where to look for what:
| Document | What it is |
|---|---|
ARCHITECTURE.md |
Orientation tour: principles, layers, navigation, recurring-write / conflict / reminder pipelines, testing |
../CHANGELOG.md |
Release history (Keep a Changelog, SemVer) |
../.planning/ROADMAP.md |
Living roadmap: shipped milestones, current scope, idea backlog |
../.planning/PROJECT.md |
What the project is, stack, naming, infrastructure |
../.planning/REQUIREMENTS.md |
Requirement checklist per milestone |
../.planning/STATE.md |
Snapshot of where development currently stands |
superpowers/specs/ |
The original design spec (2026-06-08) — historical record, not updated |
superpowers/plans/ |
Per-milestone implementation plans with task checklists — historical record of how each slice was built, including provider lessons learned |
../fdroid-metadata/ |
F-Droid/fastlane store metadata: descriptions, icon, screenshots (DE + EN) |
Conventions: plans and specs under superpowers/ are point-in-time
artifacts of the agentic workflow that built each milestone — they get
status updates but are never rewritten. The .planning/ files are living
documents and should stay current.