Jean-Luc Makiola
8c3cbcf928
Reviewed the plan against the code it describes. Two design holes and five errors. Instance identity was the real one. The plan deleted the materialised instances table without saying what replaces the instance row id, which TasksRepositoryImpl.updateTask passes to updateInstance and which ListsScreen keys a lazy list by. Two occurrences of one series can appear in the same list, so taskId alone is not unique and a hash of (taskId, start) can collide - as a Compose key that is a visible bug. Task.id is dropped for occurrenceStart, updateInstance takes (taskId, occurrenceStart, form), and External mode maps back to a real instance row with one query. This is the single seam change, and the plan's "TasksDataSource unchanged" claim was wrong. Local lists had no account name. TaskList.accountName is non-null, ListsViewModel groups by it and ListsScreen renders it as a section header, so a null account_id must still report "Local". The unique index was wrong: overrides share their master's UID, so unique (list_id, uid) would reject the rows the recurrence design depends on. It needs recurrence_id in the key. Phase 0 broke background reminders. It dropped our authority from ProviderChangeReceiver's manifest filter while the provider was still the store, and renamed StorageMode.LOCAL to OWN four phases before OWN meant Room. Both moved to phase 5. Parity against the provider was overclaimed: the provider materialises one occurrence, so multi-occurrence expansion has nothing to compare against and is tested against RFC 5545 directly. The phases sum to 6.5-7 weeks, not the 6-6.5 stated, and the difference from STORAGE-DECISION.md's 4.5-6 is now explained rather than left as a contradiction. Gaps closed: WAL vs Auto Backup (checkpoint on ON_STOP, sidecars in the backup rules, tested in phase 6), cascade rules for master_id and parent_id, Instant type converters, a rollback path that re-runs the import from tasks.db.imported, the release note for dropping the authority and its permissions, and ICalendarWriter.uidFor's synthesis branch becoming External-only. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
5.7 KiB
On-device work (USB-connected phone)
A physical phone is connected over USB. Rules:
- Install when asked — if the user says to install/deploy on device, do it
(build +
adb install). That's the one action you may take on your own. - Do nothing else on the device unprompted. Do not launch the app, take screenshots, dump/read logcat, poke UI, or otherwise "test" or verify on the device on your own initiative — even to confirm a change works.
- Read logs, capture screenshots, and inspect on-device behaviour only when the user explicitly asks for it, each time. The user drives when it's time to look; wait for that instruction.
UI / design conventions
- Material 3 Expressive throughout. Consult the
material-3skill before designing anything new; prefer M3 tokens/components over hardcoded colours. - Selection pickers are full-screen — browse-style "choose one" surfaces
(visibility, reminder, recurrence rule, colour, calendar, add-field, plus the
Settings pickers) use floret-kit's
FullScreenPicker/OptionPicker(a full-bleed sheet with a pinned title bar and connected grouped rows); a picker that needs a commit/extra action passes it via the picker'sactionsslot. The exception is the recurring scope choosers — the "this / this & following / all" prompts shown when you save an edit to, drag or delete a recurring event — which stay compactOptionCard-in-AlertDialogpopups (a quick 2–3 option decision reads better as a popup than a near-empty full screen).AlertDialogis otherwise only for plain confirmations. Radio/text-list dialogs are banned.
Releases
The committed versionCode / versionName in app/build.gradle.kts are the
release trigger: merging a bumped versionName into main runs
.gitea/workflows/release.yaml, which builds, signs, publishes to the
self-hosted F-Droid repo, then mints the vX.Y.Z tag + release. versionCode is
pinned to MAJOR*10000 + MINOR*100 + PATCH (e.g. 2.13.0 → 21300). Full process
in docs/RELEASING.md. Never tag/release UI changes before on-device review
and explicit go-ahead.
Release builds are kept F-Droid reproducible — vcsInfo, dependenciesInfo,
and the AGP metadata block are deliberately disabled in build.gradle.kts; don't
re-enable them. Use the releaseTest build type (R8-shrunk twin, debug-signed,
own applicationId suffix) to smoke-test a release candidate on-device.
Per-version changelogs are written by hand, in every locale
fastlane/metadata/android/<locale>/changelogs/<versionCode>.txt is the
"What's New" both F-Droid and Play publish. There is no auto-translation
layer — Weblate owns values-*/strings.xml only, not the fastlane tree — so
when cutting a release you write these files yourself, one per locale, each a
short summary under 500 characters (Play's hard cap, applied per locale;
F-Droid truncates in-client).
Write one for every language the app ships (app/src/main/res/values-*),
using store locale codes: en-US, en-GB, de-DE, es-ES, fr-FR, it-IT,
pl-PL, pt-PT, ru-RU, zh-CN, ar. Missing locales aren't fatal — both
stores fall back — but see the en-GB trap below.
en-GB is the Play Console's default language. Play's fallback is the
default locale, not en-US, so a release with only an en-US changelog ships
with no "What's New" at all — this is why the latest release had none.
en-GB must exist.
The rest of the plumbing is already locale-agnostic: sync_changelog_to_fastlane.sh
seeds en-US only and never overwrites a committed file, while
fastlane_to_fdroid_localized.sh and supply pick up every locale that has a
changelogs/ dir. So the files are the whole job.
Forge / tea CLI
Codeberg is canonical (codeberg.org/jlmakiola/calendula) for git, issues,
PRs, tags and releases — including the floret-kit submodule. The self-hosted
Gitea instance is build infrastructure only: signing key, F-Droid publishing,
release pipeline.
Use the tea CLI for forge interaction — not raw API calls. Note the flag is
a subcommand flag, not global: tea pulls list --login codeberg, never
tea --login codeberg pulls list. Two accounts, neither default:
- Everything →
codeberg(userjlmakiola). PRs, issues, releases, repo settings.tea pulls create --login codeberg ... - Build infra only →
jeanluc(gitea.jeanlucmakiola.de, usermakiolaj). Release-pipeline runs, Actions secrets.tea ... --login jeanluc
Workflows are split by directory and this is load-bearing — Forgejo's lookup is
first-match-wins across .forgejo/ → .gitea/ → .github/:
.forgejo/workflows/runs on Codeberg (ci.yaml,translations.yaml) and must reference no secrets — that's what makes fork PRs safe..gitea/workflows/runs on Gitea (release.yaml,renovate.yml) and is where every secret lives.
Don't add a workflow without deciding which side it belongs on.
Translations
Community translations are managed on a self-hosted Weblate, which owns all
values-* files (including German — API only, never hand-edit). Partial
translations are expected (MissingTranslation is informational, not fatal);
extra/stale keys stay fatal.
Git Operations
Use a commit format which references the issues, dont add any Co-Authered by Claude lines, and don't write extensive commit and merge messages, simple human ones suffice, for prs, stuff like testing etc, isnt interesting write what has chnaged, and if deviated from the underling issues pls explain why, add a closes issue line at the end of all prs.
Comments
Don't add extensive code comments, methode discription, so as a Java Doc is fine, but no extensive explanbanitory conmments