Jean-Luc Makiola
df203c0b6b
Reworks the pipeline so a change is built once and a release is driven by the merge, not a manual tag push. - ci.yaml now runs on pull_request (one gate per PR) instead of every branch push, so there's no CI-on-push + CI-on-merge double run. A single `ci` job with a docs-only fast-path keeps the required "CI" check always reporting (docs/metadata-only PRs skip the Android build but still go green). - release.yaml triggers on push to main. A cheap `detect` job reads versionName from build.gradle; only when no tag for it exists does the `release` job run: tests on the merged commit, build + sign, publish to F-Droid, then create the vX.Y.Z tag + Gitea release via the API (target_commitish = the merged sha). The tag is now an OUTPUT of a successful release, not its trigger — a failure before publish leaves no tag, so re-running safely retries. No more separate tag-triggered run or duplicate ci job. - The committed versionName/versionCode are now the source of truth (pipeline pins versionCode from versionName); updated the build.gradle comment. - translations.yaml switched to pull_request (same path filter). - docs/RELEASING.md: release-by-merge flow, no manual git tag. 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.