Files
clockula/docs
makiolaj b1a45db54a feat(alarms): schedule an alarm on a date, pause a repeating one
A one-shot alarm can now ring on a chosen date, and a repeating alarm
can be paused for a range of days. Both are local dates: the date is a
floor and the pause a hole in the occurrence sequence, so DST and zone
changes resolve as for any other alarm. A missed date behaves like a
missed one-shot, and each clears itself once it can no longer change a
candidate. Picking a repeat day clears the date, as in Google Clock;
"skip next" stays the quick version of a pause.

The editor uses the M3 date and date-range pickers, which offer no past
day. The list, the next-alarm widget and the self-check read the
resolver, so they follow. The schema goes to v4 with a migration, and
the backup format to v2, which still imports v1 files. SET_ALARM no
longer re-uses an alarm that carries a date or a pause.

Fixes #21
2026-10-21 20:16:34 +02:00
..

Clockula — documentation

Clockula is a Material 3 Expressive clock app for Android: alarms, timers, stopwatch and world clock. Third floret of the bloom, after Calendula (calendar) and Agendula (tasks). See the top-level ../README.md for the pitch.

Unlike its siblings, Clockula owns its storage, because there is no open provider behind a clock. What that costs and how the open-standards commitment is honoured anyway is the first section of PLAN.md.

Index

Doc What it covers
PLAN.md The spec. Thesis, locked decisions, the alarm engine, data model, system interop, identity, pipeline, and how ClockMaster is used. The "why".
ROADMAP.md Status and the work queue: milestones M0–M11 and post-v1. What the build loop works through.
ARCHITECTURE.md How Clockula is built today: layers, the data seam, the alarm engine, DI, build/tooling, manifest. Written from M2 onward.
RELEASING.md How to cut a release. Written at M0 alongside the pipeline.
PROVENANCE.md Third-party code and assets carried in-tree, and under what licence (PLAN.md §11).

Also: ../CHANGELOG.md (Keep a Changelog format; tag sections feed the release notes).

How the docs relate

  • PLAN is the design decisions (stable; the "why").
  • ARCHITECTURE is the current shape of the code (kept in sync as it grows).
  • ROADMAP is the moving status layer (updated as milestones land).
  • RELEASING is the operational runbook.