Files
agendula/docs
makiolaj b4a7fcb46e sync: what the on-device round found
Everything here came from running the account flow against a real
Nextcloud rather than from reading the code.

Discovery
- A typed bare origin now gets the RFC 6764 well-known probe. It was
  returned as the only candidate, so `https://cloud.example.com` — what
  people actually type — was PROPFIND'd against the web UI, answered 405,
  and a working Nextcloud reported as "not a CalDAV server".
- A same-host HTTPS→HTTP redirect is put back on TLS instead of refused
  (`dav` change 7). A Nextcloud behind a TLS-terminating proxy without
  `overwriteprotocol` builds every redirect with http://, including the
  /.well-known/caldav hop discovery depends on. Cross-host still throws.
- Outcomes carry a `Cause` the UI translates, not the server's own words.
  "HTTP 405 Method Not Allowed" told someone entering an address nothing,
  in a language they may not read, from outside strings.xml.
- An IPv6 origin keeps its brackets: `HttpUrl.host` returns "fd00::1", so
  the rebuilt origin did not parse and a homelab address came back as
  "not an address".

Login Flow v2
- The poll response's scheme is coerced, never refused. Nextcloud returns
  the app password exactly once, so throwing there burned a live
  credential and left it dangling in the user's device list. The host
  mismatch already worked this way; the scheme now matches it.

Accounts
- The accounts screen observes Room and the sign-in state instead of
  taking a snapshot, so a sync landing — or a 401 stopping an account —
  reaches a screen that is already open.
- A per-account detail screen, and provider identity (`CalDavProvider`)
  shared with the quirk table so one list drives both the icon and the
  warning.
- The password field masks: floret-kit's `InlineTextField` gained a
  visual transformation, since `KeyboardType.Password` only tells the IME
  to drop suggestions.
2026-09-07 18:41:45 +02:00
..

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.