Jean-Luc Makiola
9697b56404
Adds Play as a third channel alongside the F-Droid repo and the Codeberg download. It gets its own artifact: bundleRelease produces an AAB from the same source and signing config as the published APK, which is left untouched so the F-Droid reproducibility guarantee is unaffected. The upload runs as a separate trailing job rather than more steps in 'release'. Play is the only channel that can reject a good build for reasons the pipeline cannot see — listing rules, policy review, a track needing manual promotion — and that must surface as one red job beside a release that already shipped, not as a failure of the workflow that shipped it. It also skips cleanly until PLAY_SERVICE_ACCOUNT_JSON exists, so the pipeline keeps working during Play Console setup. fastlane is scoped deliberately to 'supply'. Build and signing stay on Gradle: interposing fastlane there would add a layer able to inject flags into the one build a third party verifies byte-for-byte. What fastlane buys is that fastlane/metadata/android — already the source F-Droid harvests — is exactly what supply consumes, so 'What's New' comes from CHANGELOG.md via the existing sync script for both stores. Listing text is not pushed per release (an accidental overwrite of a live listing is a policy-review event, not a revert), and images are skipped because the committed assets satisfy F-Droid but not Play: the screenshots are 1280x2856 with alpha where Play caps the long edge at 2x the short edge and wants 24-bit, and no 1024x500 featureGraphic exists. The job runs without a container image despite fastlane publishing one: act_runner provides no node inside custom job containers, so checkout and download-artifact cannot run there. Uploads default to the internal track — promotion to production stays a human action, matching the rule that UI releases wait for on-device review. Note that Play App Signing means Play installs and F-Droid installs carry different signatures and cannot update each other; the release key is registered only as the upload key. Documented in docs/RELEASING.md.
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 |
../fastlane/metadata/android/ |
Store metadata (single source of truth): descriptions, title, icon, screenshots (DE + EN). Harvested directly by the official F-Droid repo; transformed into the self-hosted repo layout at release time by ../scripts/fastlane_to_fdroid_localized.sh |
../fdroid-metadata/ |
App-level F-Droid control file (*.yml: Categories, License, links) for the self-hosted repo's fdroid update |
fdroid-official/ |
Draft recipe + notes for publishing to the official F-Droid repo (reproducible build + developer-signed binary) |
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.