floret-kit/docs/ROADMAP.md

floret-kit — roadmap

What's extracted, what's deferred, and what's deliberately not shared. The defer/skip calls come from a cross-app survey of both Calendula and Agendula — the guiding rule is to share only what is genuinely common, and to keep divergent or app-specific code where it lives.

---

Extracted (done)

Module	Type	Consumers
core-time	JVM	Agendula (and Calendula's pending branch)
core-reminders	JVM	Agendula (and Calendula's pending branch)
core-crash	Android	Agendula
identity	Android	Agendula
components	Android	Agendula

See ../CHANGELOG.md for the contents of each.

---

Deferred / not yet worth it

• core-prefs (DataStore base: ThemeMode, dynamicColor, the typed wrapper, toEnum()) and core-di (@IoDispatcher + provider) — genuinely shared but low value: pure relocation, no new capability, the shared surface is tiny once the store name and bindings stay app-local. Sensible to defer until a third app makes the duplication hurt.
• ReminderFormatting (ReminderUnit + reminderLeadTimeLabel + decomposeReminder) — the labels are @Composable over app-specific R.plurals, and the presets differ per app. Extract later behind a label/preset callback API, not before.

Deferred — needs migration first

• core-provider (the ContentProvider seam: ColumnReader, failures, observer→Flow) — the two apps' ColumnReaders diverged (Calendula index-based, Agendula name-based + null-safe). True sharing means migrating Calendula to the better name-based design first (~a few hundred LOC), so it waits until Calendula is actively on the kit.

Not shared (by design)

• A generic Settings scaffold — the two apps' settings domains are too divergent for a config-driven SettingsScaffold to stay readable. The win is captured instead at the component level (shared GroupedRow/section primitives + CollapsingScaffold + OptionPicker); each app composes its own settings from those.
• The reminder scheduler — the shared core-reminders module is the app-agnostic override model only (ReminderOverride + codec + unit model, now multi-value). The delivery stays app-local: Agendula self-schedules alarms (pull), Calendula is provider-event-driven (push) — opposite architectures over incompatible data models, so forcing a shared scheduler abstraction would be leaky. A tiny core-notification (idempotent channel setup, POST_NOTIFICATIONS checks) might land later; schedulers stay app-local.
• Domain-specific UI (date/time fields tied to a domain, calendar/timeline widgets, recurrence text, domain pickers) and all string wording — these encode each app's model and resist parameterization.

---

Consumers & cadence

• Agendula consumes the kit on main (active development).
• Calendula (ships via official F-Droid reproducible builds) has a pending adoption branch. Bringing it onto the kit is where the canonical-GroupedSurface convergence becomes visible, and where the F-Droid reproducibility checklist (submodules: true in the recipe; the repro guard scanning the submodule) applies — see ARCHITECTURE.md §2 and §5.