makiolaj
3150781376
The branch's documents describe a world where the vendored provider reached users. It never did, and several claims follow from that mistake. `ROADMAP.md`: - Phase 5's "**Breaking:** the authority and both custom permissions no longer exist — anyone who pointed DAVx5 at that authority loses it, and the release notes have to say so" is wrong in the way that *removes* work: they were added and deleted inside this unreleased cycle, so nobody could have pointed anything at them. The release notes must not warn about losing something that never shipped. The per-locale release-notes item went with it. - "Run the instrumented suite on a device … none has ever executed" was stale: 52 tests, 0 failures, Pixel 10 / API 36, 13 Aug. What is genuinely open is a re-run against the tip, since the 4 Sep commits reworked the store and added instrumented cases that have never run. Both now say so, with the ARM64 aapt exit-code trap noted where someone will hit it. - The device-verification item described upgrading from a v0.3.2 APK with seeded data, which cannot be the real path. Replaced with the four cases that matter, including the one that only exists on a device that side-loaded a dev build of this branch. - M6's Glance item claimed "deps present in build.gradle.kts" — not any more. Translations and the language picker shipped in 0.4.0 and are marked done. `OWN-STORE.md` gets a correction banner over "Migrating existing users" saying the premise is wrong, and a section for the copy that replaces it. `STORAGE-AND-SYNC.md`'s banner said the vendored-provider decision was "made, shipped, and then costed properly" — built, not shipped. `PRIVACY.md` had the opposite problem: it describes CalDAV sync, Nextcloud Login Flow v2, RFC 6764 discovery and a Keystore-held password, none of which exist in 1.0.0 — the app holds no `INTERNET` permission at all. The permissions section listed six it does not declare. Since it is a legal document users are sent to from Settings → About, section 4 is now marked as describing a planned feature, section 9 lists exactly what the manifest declares (and says what is *not* there), and the backup and crash-report sections no longer assume network access or sync bookkeeping. Kept forward-looking rather than cut, so it does not have to change underneath anyone when sync lands. **Worth a read before merging** — it is the one change here with legal weight. `fastlane/.../full_description.txt` still opened with "It works directly on an existing tasks provider (OpenTasks / tasks.org) … no own account, no own sync" as the app's premise. That is the F-Droid listing for a release whose headline is that it needs nothing installed. Rewritten, with the feature list and the no-internet-permission point that is now literally true. `README.md` and `ExportWriter`'s "ships in eleven locales" (it is three) follow.
Agendula — documentation
Agendula is a Material 3 Expressive task app for Android. It carries its
own task store — the dmfs task provider vendored under our own authority — so
it is complete and local-first with nothing else installed; an external provider
(OpenTasks / tasks.org, synced by DAVx5 / SmoothSync / DecSync) is a user choice
rather than a requirement, and our own CalDAV sync is the 1.x arc. Sibling to
Calendula. See the
top-level ../README.md for the project pitch.
Index
| Doc | What it covers |
|---|---|
ARCHITECTURE.md |
How Agendula is built today — layers, the data seam, provider resolution, the reminder engine, DI, build/tooling, manifest. Start here to work on the code. |
ROADMAP.md |
Status and what's next — milestones (M0–M6 + Posture B), what's done, open decisions, how to build/verify. |
STORAGE-AND-SYNC.md |
Where task data lives — the decision to ship our own provider, the storage modes, permissions, distribution, and the dead ends. Supersedes PLAN.md on storage. |
SYNC.md |
How data reaches a server — the CalDAV sync adapter: the VTODO ↔ TaskContract mapper, Nextcloud sign-in, the engine, libraries and their licenses. Step 5 of STORAGE-AND-SYNC.md. |
STORAGE-DECISION.md |
Keep the vendored provider, or build our own? The measured cost of both. Decided: build our own. |
OWN-STORE.md |
Agendula's own Room store — the schema, recurrence design, migration off the vendored provider, and the six-phase plan that deletes :provider. Supersedes the "keep the provider" position in STORAGE-AND-SYNC.md. |
PLAN.md |
The original implementation plan and design rationale — the A-now-B-later thesis, what transfers from Calendula, the locked decisions. The "why". |
RELEASING.md |
How to cut a release — the git-tag-as-source-of-truth flow, CI jobs, F-Droid repo, required secrets. |
../provider/PROVENANCE.md |
What the vendored :provider module is, where it came from, and every deviation from upstream dmfs. |
Also: ../CHANGELOG.md (Keep a Changelog format; tag sections
feed the release notes).
How the docs relate
- PLAN is the original design decisions (the "why"), left as the historical record. On storage it is superseded by STORAGE-AND-SYNC.
- STORAGE-AND-SYNC and SYNC are the standing decision documents: the first settles where data lives, the second how it syncs. Both record rejected alternatives on purpose, so decisions don't get relitigated.
- ARCHITECTURE is the current shape of the code (kept in sync with the source as it grows).
- ROADMAP is the moving status layer (update as milestones land).
- RELEASING is the operational runbook.