Jean-Luc Makiola
ef48717e2c
Code review of the one-visibility-model fix (#75) found the reconciliation reaching further than it should and the read-only case falling through it. The migration switched calendars *on* to keep the upgrade invisible, but "not disabled in Calendula" is the default for every calendar, including ones the user deliberately hid in Google Calendar, Etar or DAVx5 — those would reappear there and start firing reminders from a switch the user never touched. Its sync_events guard didn't hold either: an ACCOUNT_TYPE_LOCAL calendar another app created can sit at sync_events=0 while holding real device-local events. The reconcile now only hides, and a one-time notice explains that visibility follows the device and where to change it, instead of quietly rewriting other apps' state. Only READ_CALENDAR gates the app, so a read-only install could not write the flag at all: every calendar it had switched off came back with its events and its reminders, and the switch couldn't undo it. Those switch-offs are kept app-side now (the retired disabled-set key, re-read under a new name), folded into the visibility every consumer reads, and drained into the provider entry by entry once WRITE_CALENDAR arrives — which also makes a part-applied run resumable without re-applying a switch the user has since flipped by hand. Also: restore the ReminderNotifier.post gate, the one path a snooze re-shown from our own alarm passes; move the whole reconcile inside its try/catch, so a damaged preferences file can't crash the process at launch; share one Calendars query per provider tick across the flows that need it; and give the reworded Settings hint new keys, so five locales stop rendering the retired app-only wording. Co-Authored-By: Claude Opus 5 (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 |
../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.