From e870918a03cef099cd9c51bac9951bc7e6dd0de0 Mon Sep 17 00:00:00 2001
From: Jean-Luc Makiola <business@jeanlucmakiola.de>
Date: Tue, 6 Oct 2026 19:14:11 +0200
Subject: [PATCH] docs: plain-language pass over every doc

Removes AI-writing patterns across the docs, store listing and
templates: dash-heavy rhythm, not-X-but-Y contrasts, one-line kickers
and decorative bold. Facts, code, links and headings are unchanged.

Also fixes leftovers copied from the sibling apps: the crash report
template promised "no calendar content", and CONTRIBUTING described
Agendula's task-provider layout, test seams and commit style.
---
 .forgejo/ISSUE_TEMPLATE/config.yml            |  15 +-
 .forgejo/ISSUE_TEMPLATE/crash_report.md       |   8 +-
 .forgejo/ISSUE_TEMPLATE/feature_request.md    |   2 +-
 .forgejo/PULL_REQUEST_TEMPLATE.md             |   6 +-
 CONTRIBUTING.md                               |  51 +-
 docs/ARCHITECTURE.md                          | 788 +++++++++---------
 docs/BACKUP.md                                |  28 +-
 docs/PLAN.md                                  |  68 +-
 docs/README.md                                |   8 +-
 docs/ROADMAP.md                               | 414 ++++-----
 .../android/en-US/full_description.txt        |   6 +-
 11 files changed, 697 insertions(+), 697 deletions(-)

diff --git a/.forgejo/ISSUE_TEMPLATE/config.yml b/.forgejo/ISSUE_TEMPLATE/config.yml
index 05abff8..46d414f 100644
--- a/.forgejo/ISSUE_TEMPLATE/config.yml
+++ b/.forgejo/ISSUE_TEMPLATE/config.yml
@@ -6,8 +6,8 @@ contact_links:
   - name: Translate Clockula
     url: https://weblate.dev.jeanlucmakiola.de/engage/clockula/
     about: >-
-      Translations are managed on Weblate, not here — it owns every values-*
-      file, so a hand-edited translation gets overwritten on the next sync.
+      Translations are managed on Weblate, which owns every values-* file, so
+      a translation edited by hand here gets overwritten on the next sync.
       No coding needed: pick or request a language and translate in the browser.
 
   - name: Contributing guide
@@ -20,13 +20,12 @@ contact_links:
     url: https://codeberg.org/jlmakiola/clockula/src/branch/main/README.md
     about: >-
       Open the app's own self-check first (Settings → Why might my alarm not
-      ring?). It reports what your device is actually doing — battery
-      optimisation, notification and full-screen-intent permissions, the next
-      alarm as the system sees it — and that report is what makes such an issue
-      actionable.
+      ring?). It reports what your device is doing (battery optimisation,
+      notification and full-screen-intent permissions, the next alarm as the
+      system sees it). Include that report so the issue can be acted on.
 
   - name: Scope and roadmap
     url: https://codeberg.org/jlmakiola/clockula/src/branch/main/docs/ROADMAP.md
     about: >-
-      What's built, what's planned, and what's deliberately out of scope —
-      check here before requesting a feature.
+      What's built, what's planned, and what's deliberately out of scope.
+      Check here before requesting a feature.
diff --git a/.forgejo/ISSUE_TEMPLATE/crash_report.md b/.forgejo/ISSUE_TEMPLATE/crash_report.md
index 6acf2ce..d478d19 100644
--- a/.forgejo/ISSUE_TEMPLATE/crash_report.md
+++ b/.forgejo/ISSUE_TEMPLATE/crash_report.md
@@ -1,6 +1,6 @@
 ---
 name: Crash report
-about: Report a crash. Clockula can capture this for you (Settings → Report a problem, or the prompt after a crash) — it copies the report to your clipboard and prefills this form.
+about: Report a crash. Clockula can capture this for you (Settings → Report a problem, or the prompt after a crash). It copies the report to your clipboard and prefills this form.
 title: "Crash: "
 labels:
   - bug
@@ -11,10 +11,10 @@ labels:
 <!--
 Thanks for reporting a crash in Clockula!
 
-If the app prefilled this for you, the crash report is already below — just add
-what you were doing and submit. Otherwise, paste the report from your clipboard
+If the app prefilled this for you, the crash report is already below. Add what
+you were doing and submit. Otherwise, paste the report from your clipboard
 into the code block. The report contains only app/Android/device versions and the
-stack trace — no personal data or calendar content.
+stack trace, with no personal data and none of your alarms, timers or clocks.
 -->
 
 ### What happened
diff --git a/.forgejo/ISSUE_TEMPLATE/feature_request.md b/.forgejo/ISSUE_TEMPLATE/feature_request.md
index 588fccc..f0b0d63 100644
--- a/.forgejo/ISSUE_TEMPLATE/feature_request.md
+++ b/.forgejo/ISSUE_TEMPLATE/feature_request.md
@@ -9,7 +9,7 @@ labels:
 ### What would you like Clockula to do?
 
 
-### Why — what problem does it solve?
+### What problem would it solve?
 
 
 ### Anything else
diff --git a/.forgejo/PULL_REQUEST_TEMPLATE.md b/.forgejo/PULL_REQUEST_TEMPLATE.md
index 79959c1..08c427e 100644
--- a/.forgejo/PULL_REQUEST_TEMPLATE.md
+++ b/.forgejo/PULL_REQUEST_TEMPLATE.md
@@ -5,7 +5,7 @@ Please skim CONTRIBUTING.md if you haven't:
 https://codeberg.org/jlmakiola/clockula/src/branch/main/CONTRIBUTING.md
 
 Two things it's easy to get wrong:
-  • The one architectural rule — Room entities, DAOs and `@Query` strings never
+  • The one architectural rule: Room entities, DAOs and `@Query` strings never
     leak above the data layer. Everything else talks to a repository.
   • Don't bump `versionName` / `versionCode`. That bump reaching `main` is what
     cuts a release, so it belongs only in a release PR.
@@ -16,7 +16,7 @@ Two things it's easy to get wrong:
 
 ### Why
 
-<!-- Closes #123 — link the issue this implements or fixes. -->
+<!-- Link the issue this implements or fixes, e.g. Closes #123. -->
 
 
 ### How it was tested
@@ -24,7 +24,7 @@ Two things it's easy to get wrong:
 <!--
 Which of these ran green, and anything you exercised by hand. On-device notes
 are especially useful for UI changes, and essential for anything touching the
-alarm engine — an alarm that doesn't ring is the one bug that matters most, and
+alarm engine. An alarm that doesn't ring is the one bug that matters most, and
 it only ever reproduces on a real device overnight.
 
   ./gradlew lintDebug :app:testDebugUnitTest :app:assembleDebug
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index c4b65d0..26cbf75 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,8 +1,8 @@
 # Contributing to Clockula
 
-Thanks for your interest in Clockula — a Material 3 Expressive clock app:
+Thanks for your interest in Clockula, a Material 3 Expressive clock app for
 alarms, timers, stopwatch and world clock. Unlike its siblings it owns its
-storage, because there is no open provider behind a clock. Before diving in, skim [`docs/ARCHITECTURE.md`](docs/ARCHITECTURE.md)
+storage, because there is no open provider behind a clock. Before you start, skim [`docs/ARCHITECTURE.md`](docs/ARCHITECTURE.md)
 (how it's built), [`docs/ROADMAP.md`](docs/ROADMAP.md) (what's next), and
 [`docs/PLAN.md`](docs/PLAN.md) (the design rationale). This file covers the
 practical how.
@@ -15,14 +15,14 @@ layer.** Clockula owns its storage, which makes this rule more important here
 than in the siblings, not less: it is the only thing keeping the schema a
 private implementation detail rather than the app's de-facto domain model. If a
 change would expose a Room type to a ViewModel or the UI, it's in the wrong
-layer — see [`docs/PLAN.md`](docs/PLAN.md) §0.
+layer; see [`docs/PLAN.md`](docs/PLAN.md) §0.
 
 ## Prerequisites
 
 - JDK 17
 - Android SDK: compileSdk 37, build-tools 36.0.0 (the Gradle wrapper handles AGP/Kotlin)
 - A real device for anything touching the alarm engine. An emulator will not
-  tell you whether an alarm survives doze, a reboot, or an OEM battery-saver —
+  tell you whether an alarm survives doze, a reboot, or an OEM battery-saver,
   and that is the only question that matters about an alarm.
 
 ## Build, test, lint
@@ -43,11 +43,11 @@ before opening a PR. Keep CI green.
 owned by a self-hosted Weblate that writes to this repository directly, and a
 hand-edit is overwritten on the next sync.
 
-→ **[Translate Clockula on Weblate](https://weblate.dev.jeanlucmakiola.de/engage/clockula/)**
+**[Translate Clockula on Weblate](https://weblate.dev.jeanlucmakiola.de/engage/clockula/)**
 
 Adding a *new* English string to `values/strings.xml` is normal PR work; Weblate
 picks it up and offers it to translators. Partial translations are expected and
-fine — missing keys are informational. Stale and orphaned keys are not, so run
+fine; missing keys are informational. Stale and orphaned keys are not, so run
 
 ```sh
 python3 scripts/check_translations.py
@@ -57,64 +57,67 @@ before pushing. It reports those more clearly than lint's `MissingTranslation`
 does, and it's what the `Translations` check runs on every PR.
 
 A new language also needs one `<locale>` line in
-`app/src/main/res/xml/locales_config.xml` — that file is the single source of
+`app/src/main/res/xml/locales_config.xml`. That file is the single source of
 truth for both the in-app picker and the Android 13+ per-app language setting.
 
 ## Where to put code
 
 | Layer | Lives in | Rule of thumb |
 |---|---|---|
-| Pure logic (models, filtering, sorting, form validation, date maths) | `domain/` | No Android imports — must be JVM-unit-testable. |
-| Provider access | `data/tasks/` | The only place that knows about the provider. New provider work goes through `TasksDataSource`. |
-| Reminders, prefs, DI, demo data | `data/reminders/`, `data/prefs/`, `data/di/`, `data/demo/` | |
+| Pure logic (models, scheduling and ring policies, formatting, the self-check rules) | `domain/` | No Android imports; must be JVM-unit-testable. |
+| Storage | `data/` (`db/`, `alarms/`, `timers/`, `stopwatch/`, `worldclocks/`, `prefs/`, `backup/`) | The only place that knows Room or DataStore exists. Everything above it goes through a repository interface. |
+| Engines and their Android seams | `alarm/`, `timer/`, `stopwatch/`, `ring/`, `interop/`, `widget/` | The engine is plain Kotlin; AlarmManager, services and receivers sit behind seams in its `android/`, `receiver/` and `service/` subpackages. |
 | Screens | `ui/<area>/` | One ViewModel + immutable `UiState` per area; Compose for the screen. |
 
+[`docs/ARCHITECTURE.md`](docs/ARCHITECTURE.md) §3 lists every package.
+
 ## Code style & conventions
 
 - **Kotlin**, 4-space indent, LF line endings, final newline, no trailing
-  whitespace — all enforced by `.editorconfig` (2-space for yaml/toml/json/md).
+  whitespace, all enforced by `.editorconfig` (2-space for yaml/toml/json/md).
   Match the surrounding code.
 - **Material 3 Expressive** for all UI: use `MaterialExpressiveTheme`, the
   colour-scheme tokens (never hardcoded colours), and canonical M3 components
   (e.g. `ListItem` for rows). Consult the `material-3` skill before designing a
   new screen or component.
-- Prefer the domain layer for anything testable; keep `AndroidTasksDataSource`
-  the only Android-coupled data implementation so the rest stays JVM-testable.
+- Prefer the domain layer for anything testable; keep Android APIs behind the
+  seams in each engine's `android/` subpackage so the rest stays JVM-testable.
 
 ## Tests
 
-- New domain logic (mappers, filters, sorting, forms, value mapping) **must**
-  come with JVM unit tests under `app/src/test/`. The data source is the
-  JVM-testable seam — mock or fake it rather than reaching for instrumentation.
-- Add an instrumented test only when a path genuinely needs a real
-  `ContentResolver`.
+- New domain logic (scheduling, ring policies, formatting, mappers) **must**
+  come with JVM unit tests under `app/src/test/`. Repositories and engine seams
+  are the JVM-testable boundary: fake them rather than reaching for
+  instrumentation.
+- Add an instrumented test only when a path genuinely needs a real device
+  (Room migrations, AlarmManager, a foreground service).
 
 ## Commits & PRs
 
 - Write focused commits with clear messages (the existing history uses short,
-  scoped subjects like `UI: ...` / `M1 ...`).
+  conventional subjects like `feat(widgets): ...` / `fix(ringtones): ...`).
 - Update [`CHANGELOG.md`](CHANGELOG.md) under `[Unreleased]` for any
-  user-visible change — its sections feed the release notes and F-Droid "What's
+  user-visible change. Its sections feed the release notes and F-Droid "What's
   New" (see [`docs/RELEASING.md`](docs/RELEASING.md)).
 - If your change shifts the architecture or completes a milestone, update
   [`docs/ARCHITECTURE.md`](docs/ARCHITECTURE.md) / [`docs/ROADMAP.md`](docs/ROADMAP.md)
   in the same PR.
-- Don't bump `versionName` / `versionCode` in a regular PR — the committed
+- Don't bump `versionName` / `versionCode` in a regular PR. The committed
   `versionName` is bumped only when **cutting a release** (that bump reaching
   `main` is what triggers the release; the pipeline then mints the tag). See
   [`docs/RELEASING.md`](docs/RELEASING.md).
 
 ## Scope
 
-v1 is four surfaces — alarms, timers, stopwatch, world clock — done properly,
+v1 is four surfaces (alarms, timers, stopwatch, world clock) done properly,
 and nothing else. Widgets, a Quick Settings tile, screensaver mode and a bedtime
 schedule are all wanted, and all deliberately deferred until v1 is finished; see
 [`docs/ROADMAP.md`](docs/ROADMAP.md).
 
-Two things are out of scope by design. **A sync stack of our own** — your alarms
+Two things are out of scope by design. **A sync stack of our own**: your alarms
 export to a documented JSON file, and syncing them is a job for something that
 already does syncing well. **Anything that makes an alarm less reliable in
-exchange for a feature** — if a change trades away the certainty that an alarm
+exchange for a feature**: if a change trades away the certainty that an alarm
 rings, it loses, however nice the feature is.
 
 ## License
diff --git a/docs/ARCHITECTURE.md b/docs/ARCHITECTURE.md
index d00b8c4..97ef4e8 100644
--- a/docs/ARCHITECTURE.md
+++ b/docs/ARCHITECTURE.md
@@ -11,8 +11,8 @@ describing a plan as though it were code. `PLAN.md` is the "why"; this is the
 
 **Clockula owns its storage, and pays for that privilege with a hard seam.**
 
-Its siblings read a platform provider — Calendula the calendar, Agendula
-tasks — so their data is open by construction. There is no open provider behind
+Its siblings read a platform provider (Calendula the calendar, Agendula
+tasks), so their data is open by construction. There is no open provider behind
 a clock (`PLAN.md` §0), so Clockula keeps its own SQLite database. The honest
 asterisk is that "open data" here has to be *earned* rather than inherited: by a
 committed, reviewable schema; by a JSON export the user can actually take with
@@ -55,14 +55,14 @@ through.
 ```
 
 One seam sits **beside** the repositories rather than under them:
-`data/zones/`'s `ZoneNames` and `ZoneDirectory` (M8). They read the *platform* —
-the device's tzdata through `ZoneProvider.available()` and ICU's localised names
-through `android.icu` — not storage, so they have no entity, no DAO and no
+`data/zones/`'s `ZoneNames` and `ZoneDirectory` (M8). They read the *platform*
+(the device's tzdata through `ZoneProvider.available()` and ICU's localised names
+through `android.icu`), not storage, so they have no entity, no DAO and no
 migration. They live in `data/` for the same reason `data/ringtones/` does: the
 thing behind them is an Android API the rest of the app must not name.
 
 The seam is the repository interface list. Above it there is no `AlarmEntity`,
-no `@Query`, no `androidx.room` import and no `ClockulaDatabase` reference —
+no `@Query`, no `androidx.room` import and no `ClockulaDatabase` reference.
 `ArchitectureRulesTest` greps the whole main source set for exactly those names
 and for `import android.`/`import androidx.` inside `domain/`, and fails with
 the offending paths listed. A grep is a blunter tool than a compiler, but it is
@@ -81,65 +81,65 @@ class of build failures.
 One app module, `:app`, plus floret-kit as a git submodule wired in as a Gradle
 composite build (`includeBuild("floret-kit")`, consumed as
 `de.jeanlucmakiola.floret:<module>`). M3 added no Gradle module and touched no
-kit module — the kit's roadmap keeps schedulers app-local.
+kit module: the kit's roadmap keeps schedulers app-local.
 
 | Package | Holds |
 |---|---|
-| `domain/` | `Alarm.kt`, `Timer.kt`, `WorldClock.kt`, `Stopwatch.kt`, `ClockDefaults.kt`, `Ringtone.kt` (the silent sentinel), `RepeatSummary.kt`, `AlarmDefaults.kt` — plain Kotlin, no Android |
+| `domain/` | `Alarm.kt`, `Timer.kt`, `WorldClock.kt`, `Stopwatch.kt`, `ClockDefaults.kt`, `Ringtone.kt` (the silent sentinel), `RepeatSummary.kt`, `AlarmDefaults.kt`. Plain Kotlin, no Android |
 | `domain/alarm/` | the alarm engine's pure half: occurrences, the resolver, the ring state, the presentation and scheduling policies, the challenge gate. The *shared* ring vocabulary moved out to `domain/ring/` in M6 |
 | `domain/ring/` | what both ring paths share: `RingAudio` (the ramp tick, the volume floor), `VolumeRamp`, `AudioSourcePolicy`/`RingtoneSourceKind`, `RingFallbackPolicy`, `VibrationPattern` |
 | `domain/stopwatch/` | the stopwatch path's pure half: `StopwatchReadings` (the one reading the pill, the shade and the tab share), `LapStats` (best and worst), `StopwatchLaps` (the lap cap), `StopwatchNotificationPolicy` |
 | `domain/timer/` | the timer path's pure half: `TimerReadings` (the app's one timer precedence), `TimerExpiry` (the sweep and the slot's value), `TimerRingPolicy`, `TimerNotificationPolicy`, `TimerPresets`, `TimerDurationEntry`, `TimerSettings`, `TimerRing` |
-| `domain/time/` | `WallClock`, `ElapsedRealtimeClock`, `ZoneProvider` (`current()` and, since M8, `available()` — the device's tzdata), `BootId`, `Ticker` |
+| `domain/time/` | `WallClock`, `ElapsedRealtimeClock`, `ZoneProvider` (`current()` and, since M8, `available()`, the device's tzdata), `BootId`, `Ticker` |
 | `domain/worldclock/` | the world clock's pure half (M8): `ZoneCatalog` (`ZoneEntry`, the pickable-id filter, the city fallback, the sort), `ZoneSearch` (folding and word-prefix matching), `ZoneComparison` (the offset and day arithmetic, `OffsetLabel`/`DayLabel`, `ZoneOffsetFormat`), `WorldClocks` (`MAX`, the move arithmetic) + `HomeZone`, `AnalogFace` (hand and tick angles) + `DayNight` (the day fraction) |
-| `domain/interop/` | the `android.provider.AlarmClock` boundary's pure half (M9): `AlarmClockContract` (the platform's vocabulary as literals — the **only** file in `src/main` that may hold them), `IntentExtras` (a Bundle modelled honestly), `InteropLimits`, `InteropText` (the label and ringtone sanitisers), `InteropDeepLinks`, `AlarmClockRequest`/`AlarmSpec`/`AlarmSearch`/`InteropOutcome`, `AlarmClockRequests` (the validator) and `AlarmMatching` (which alarms a search names) |
-| `domain/text/` | `TextFolding` (M9) — NFD-fold, strip combining marks, lowercase through `Locale.ROOT`, `containsFolded`. One copy, shared by the zone search and the label search |
-| `domain/live/` | `LivePillSelector` and its state — which running thing the live pill is about, as a pure function |
-| `domain/format/` | `ClockFormat` — `M:SS` / `H:MM:SS`, countdowns rounded up, elapsed truncated — `NextFire` (`NextFireLabel` + `NextFireFormat`), the alarm row's "in 9h 12m" as data, and `StopwatchFormat` — the hundredths readout, split into a major field and two digits so the fraction can be drawn smaller |
-| `domain/backup/` | `BackupContent` (M10) — the plain Kotlin model between `data/backup`'s JSON codec and the repository/engine; decoupled from the wire DTOs the same way the data layer is decoupled from Room |
-| `domain/selfcheck/` | `SelfCheck` (M10) — the "why might my alarm not ring?" rule table: pure functions over a `DeviceState` snapshot, each producing a `CheckResult` with a status and an optional deep-link `SelfCheckFix` |
-| `domain/widget/` | the three widget presenters (M10) — `NextAlarmWidgetModel`/`TimerWidgetModel`/`ClockWidgetModel`: selection and formatting only, so a widget's content is unit-tested without Glance |
-| `data/db/` | `ClockulaDatabase` — `@Database` v3, `exportSchema = true` — and `Migrations` |
+| `domain/interop/` | the `android.provider.AlarmClock` boundary's pure half (M9): `AlarmClockContract` (the platform's vocabulary as literals; the only file in `src/main` that may hold them), `IntentExtras` (a Bundle modelled honestly), `InteropLimits`, `InteropText` (the label and ringtone sanitisers), `InteropDeepLinks`, `AlarmClockRequest`/`AlarmSpec`/`AlarmSearch`/`InteropOutcome`, `AlarmClockRequests` (the validator) and `AlarmMatching` (which alarms a search names) |
+| `domain/text/` | `TextFolding` (M9): NFD-fold, strip combining marks, lowercase through `Locale.ROOT`, `containsFolded`. One copy, shared by the zone search and the label search |
+| `domain/live/` | `LivePillSelector` and its state: which running thing the live pill is about, as a pure function |
+| `domain/format/` | `ClockFormat` (`M:SS` / `H:MM:SS`, countdowns rounded up, elapsed truncated), `NextFire` (`NextFireLabel` + `NextFireFormat`), the alarm row's "in 9h 12m" as data, and `StopwatchFormat`, the hundredths readout, split into a major field and two digits so the fraction can be drawn smaller |
+| `domain/backup/` | `BackupContent` (M10): the plain Kotlin model between `data/backup`'s JSON codec and the repository/engine; decoupled from the wire DTOs the same way the data layer is decoupled from Room |
+| `domain/selfcheck/` | `SelfCheck` (M10): the "why might my alarm not ring?" rule table: pure functions over a `DeviceState` snapshot, each producing a `CheckResult` with a status and an optional deep-link `SelfCheckFix` |
+| `domain/widget/` | the three widget presenters (M10), `NextAlarmWidgetModel`/`TimerWidgetModel`/`ClockWidgetModel`: selection and formatting only, so a widget's content is unit-tested without Glance |
+| `data/db/` | `ClockulaDatabase` (`@Database` v3, `exportSchema = true`) and `Migrations` |
 | `data/alarms/` | the alarm and ring-state entities, DAOs, mappers and repositories |
 | `data/timers/` | `TimerEntity`, `TimerDao`, `TimerMapper`, `TimerRepository(+Impl)`, `TimerRingStateStore` (the ring session's one DataStore record) |
-| `data/worldclocks/` | `WorldClockEntity`, `WorldClockDao`, `WorldClockMapper`, `WorldClockRepository(+Impl)` — unchanged since M2; M8 is the milestone that finally calls all of it |
-| `data/zones/` | the ICU seam (M8): `ZoneNames`, `IcuZoneNames` (the only `android.icu` file in the app) and `ZoneDirectory` — the locale-keyed catalog cache and the DST-keyed display-name memo |
+| `data/worldclocks/` | `WorldClockEntity`, `WorldClockDao`, `WorldClockMapper`, `WorldClockRepository(+Impl)`, unchanged since M2; M8 is the milestone that finally calls all of it |
+| `data/zones/` | the ICU seam (M8): `ZoneNames`, `IcuZoneNames` (the only `android.icu` file in the app) and `ZoneDirectory`, the locale-keyed catalog cache and the DST-keyed display-name memo |
 | `data/stopwatch/` | `LapEntity`, `LapDao` (one `COUNT(*)` added in M7), `LapMapper`, `StopwatchStateStore`, `StopwatchRepository(+Impl)` |
 | `data/prefs/` | `SettingsPrefs`, `ClockPrefs`, `StopwatchPrefs`, `TimerPrefs`, `UiPrefs` |
-| `data/ringtones/` | the two ringtone seams — `RingtoneCatalog` (the device's alarm sounds, titles, playability, a SAF grant) and `RingtonePreviewer` — plus their `System*` implementations, and `MediaLibrary`/`SystemMediaLibrary`, the picker's view of other apps' `MediaBrowserService` libraries |
+| `data/ringtones/` | the two ringtone seams, `RingtoneCatalog` (the device's alarm sounds, titles, playability, a SAF grant) and `RingtonePreviewer`, plus their `System*` implementations, and `MediaLibrary`/`SystemMediaLibrary`, the picker's view of other apps' `MediaBrowserService` libraries |
 | `data/time/` | `SystemWallClock`, `SystemElapsedRealtimeClock`, `SystemZoneProvider`, `AndroidBootIdProvider`, `RealTicker` |
-| `data/di/` | `DataModule`, `DatabaseModule`, `RepositoryModule`, `TimeModule`, `RingtoneModule`, `ZoneModule` (M8 — one `@Binds`, `ZoneNames → IcuZoneNames`), `BackupModule` (M10) |
-| `data/backup/` | the backup's data-layer half (M10): `BackupDto`/`BackupCodec` (the pure JSON wire format, `ignoreUnknownKeys`, strict on known fields), `BackupDao` (one `@Transaction` replace-all over alarms/timers/world clocks — no schema or version change), `BackupRepository(+Impl)` — mapping through the existing `AlarmMapper`/`TimerMapper`/`WorldClockMapper`, never a second copy |
-| `alarm/` | `AlarmEngine` and the four seams it talks to — `AlarmScheduler`, `AlarmCapabilities`, `RingCoordinator`, `AlarmNotifier` — plus `AlarmIntents` |
+| `data/di/` | `DataModule`, `DatabaseModule`, `RepositoryModule`, `TimeModule`, `RingtoneModule`, `ZoneModule` (M8; one `@Binds`, `ZoneNames → IcuZoneNames`), `BackupModule` (M10) |
+| `data/backup/` | the backup's data-layer half (M10): `BackupDto`/`BackupCodec` (the pure JSON wire format, `ignoreUnknownKeys`, strict on known fields), `BackupDao` (one `@Transaction` replace-all over alarms/timers/world clocks; no schema or version change), `BackupRepository(+Impl)`, mapping through the existing `AlarmMapper`/`TimerMapper`/`WorldClockMapper`, never a second copy |
+| `alarm/` | `AlarmEngine` and the four seams it talks to (`AlarmScheduler`, `AlarmCapabilities`, `RingCoordinator`, `AlarmNotifier`), plus `AlarmIntents` |
 | `alarm/android/` | the seams' Android implementations: AlarmManager, the capability reads, the service handle, the snoozed notification |
 | `alarm/receiver/` | `AlarmFireReceiver`, `AlarmActionReceiver`, `SystemEventReceiver` |
 | `alarm/ring/` | the alarm's ringing foreground service and its notifications. Its audio player and vibrator moved to `ring/` in M6, shared with the timer's ring |
-| `alarm/di/` | `AlarmModule` — `@Binds` for the four seams |
-| `ring/` | `RingAudioPlayer` and `RingVibrator` — one `MediaPlayer` wrapper and one vibrator for both ring paths. A build rule fails on a second one |
-| `timer/` | `TimerEngine` and the three seams it talks to — `TimerScheduler`, `TimerServiceHandle`, `AlarmRingStatus` (+ `AlarmStateRingStatus`) — plus `TimerIntents` |
+| `alarm/di/` | `AlarmModule`: `@Binds` for the four seams |
+| `ring/` | `RingAudioPlayer` and `RingVibrator`: one `MediaPlayer` wrapper and one vibrator for both ring paths. A build rule fails on a second one |
+| `timer/` | `TimerEngine` and the three seams it talks to (`TimerScheduler`, `TimerServiceHandle`, `AlarmRingStatus` + `AlarmStateRingStatus`), plus `TimerIntents` |
 | `timer/android/` | the seams' Android implementations: the one elapsed-realtime AlarmManager slot, the service handle |
 | `timer/receiver/` | `TimerExpiryReceiver` (the slot arriving), `TimerActionReceiver` (the notification's buttons) |
-| `timer/service/` | `TimerService` — one foreground service for the countdown and the ring — and `TimerNotifications` |
-| `timer/di/` | `TimerModule` — `@Binds` for the three seams |
-| `stopwatch/` | `StopwatchEngine` and the one seam it talks to — `StopwatchServiceHandle` — plus `StopwatchIntents` |
+| `timer/service/` | `TimerService` (one foreground service for the countdown and the ring) and `TimerNotifications` |
+| `timer/di/` | `TimerModule`: `@Binds` for the three seams |
+| `stopwatch/` | `StopwatchEngine` and the one seam it talks to, `StopwatchServiceHandle`, plus `StopwatchIntents` |
 | `stopwatch/android/` | `ServiceStopwatchHandle`, the seam's Android implementation |
 | `stopwatch/receiver/` | `StopwatchActionReceiver` (the notification's buttons; no extras, because there is one stopwatch) |
-| `stopwatch/service/` | `StopwatchService` — the `specialUse` foreground service — and `StopwatchNotifications` |
-| `stopwatch/di/` | `StopwatchModule` — `@Binds` for the one seam |
-| `interop/` | the `AlarmClock` boundary's Android half (M9): `AlarmClockActivity` (the one exported, permission-guarded, window-less door), `IntentExtrasReader` (`Bundle` → `IntentExtras`), `AlarmClockHandler` (the orchestrator — **no `android.*` import, ever**), `InteropIntents` (the internal transport to `MainActivity`) and `InteropLaunch` |
-| `system/` | `RebootRepair` — the boot-id gate |
-| `backup/` | `BackupEngine` (M10) — the orchestrator: a ringing alarm dismissed and running timers deleted before a replace, `AlarmEngine.reschedule()`/`TimerEngine.resync()` after it — plus `BackupFiles`, the SAF seam, with its Android implementation in `backup/android/` |
-| `widget/` | the three `GlanceAppWidget`/`GlanceAppWidgetReceiver` pairs (M10) and `WidgetSync` — the event-driven collector, started from `ClockulaApp.onCreate`, that redraws all three on any change to the state they mirror. `widget/di/` holds the `@EntryPoint` Glance needs, since a `GlanceAppWidgetReceiver` is never `@AndroidEntryPoint`-constructed |
+| `stopwatch/service/` | `StopwatchService` (the `specialUse` foreground service) and `StopwatchNotifications` |
+| `stopwatch/di/` | `StopwatchModule`: `@Binds` for the one seam |
+| `interop/` | the `AlarmClock` boundary's Android half (M9): `AlarmClockActivity` (the one exported, permission-guarded, window-less door), `IntentExtrasReader` (`Bundle` → `IntentExtras`), `AlarmClockHandler` (the orchestrator; no `android.*` import, ever), `InteropIntents` (the internal transport to `MainActivity`) and `InteropLaunch` |
+| `system/` | `RebootRepair`, the boot-id gate |
+| `backup/` | `BackupEngine` (M10), the orchestrator (a ringing alarm dismissed and running timers deleted before a replace, `AlarmEngine.reschedule()`/`TimerEngine.resync()` after it), plus `BackupFiles`, the SAF seam, with its Android implementation in `backup/android/` |
+| `widget/` | the three `GlanceAppWidget`/`GlanceAppWidgetReceiver` pairs (M10) and `WidgetSync`, the event-driven collector (started from `ClockulaApp.onCreate`) that redraws all three on any change to the state they mirror. `widget/di/` holds the `@EntryPoint` Glance needs, since a `GlanceAppWidgetReceiver` is never `@AndroidEntryPoint`-constructed |
 | `ui/theme/`, `ui/crash/` | the M0/M1 theme and the crash-report surface |
-| `ui/shell/` | the navigation policy (`ShellNavigation`), the adaptive shell, the live pill and its source/ViewModel, the notification-permission ask. `EmptyTabScreen` is **gone**: its KDoc said it existed only until each of M5–M8 replaced its own tab, and the world clock was its last caller |
-| `ui/common/` | `rememberLocalTimeFormatter` — the app's **one** 12/24-hour formatter, over a `java.time.LocalTime`, with `rememberAlarmTimeFormatter` delegating to it (M8 D17) — and, since M6, the ringtone picker (`RingtonePickerState`, `RingtonePickerScreen`), which both editors need |
-| `ui/alarms/` | the real Alarms tab (M5): the routes, the list's pure row builder and its source, the two ViewModels, the list, the editor, the M3 time-picker host, the repeat-day selector and the override pickers (the ringtone picker moved to `ui/common/` in M6), and M9's `DismissChooser`/`DismissAlarmDialog` — the "which alarm should I dismiss?" question |
+| `ui/shell/` | the navigation policy (`ShellNavigation`), the adaptive shell, the live pill and its source/ViewModel, the notification-permission ask. `EmptyTabScreen` is gone: its KDoc said it existed only until each of M5–M8 replaced its own tab, and the world clock was its last caller |
+| `ui/common/` | `rememberLocalTimeFormatter`, the app's one 12/24-hour formatter, over a `java.time.LocalTime`, with `rememberAlarmTimeFormatter` delegating to it (M8 D17); and, since M6, the ringtone picker (`RingtonePickerState`, `RingtonePickerScreen`), which both editors need |
+| `ui/alarms/` | the real Alarms tab (M5): the routes, the list's pure row builder and its source, the two ViewModels, the list, the editor, the M3 time-picker host, the repeat-day selector and the override pickers (the ringtone picker moved to `ui/common/` in M6), and M9's `DismissChooser`/`DismissAlarmDialog`, the "which alarm should I dismiss?" question |
 | `ui/timers/` | the real Timers tab (M6): the routes, the pure row builder and its source, the two ViewModels, the list, the row, the setup panel and its keypad, the editor |
 | `ui/stopwatch/` | the real Stopwatch tab (M7): the pure row builder (`StopwatchRows`) and its source, the ViewModel, the readout panel with its controls, the lap table and its column header, `StopwatchDefaults` |
 | `ui/worldclock/` | the real World clock tab (M8): the pure row builders (`WorldClockRows`, `ZonePickerRows`) and their state, `WorldClockSource`, the ViewModel, the tab, the analog face, the row and the zone picker, `WorldClockDefaults` |
 | `ui/ring/` | `AlarmRingActivity`, its ViewModel, `RingScreen` and the dismiss-challenge controls |
-| `ui/settings/` | the settings hub (M10): `SettingsScreen`/`SettingsViewModel` (appearance, alarm/timer/clock defaults, reliability, data, help), `SelfCheckScreen`/`SelfCheckViewModel`, `BackupScreen`/`BackupViewModel` — all reachable from a gear icon on every tab, with no owning tab of their own |
-| `ui/widget/` | the three widgets' `@Composable` Glance content (M10) — the only Compose this milestone adds outside a tab; the `GlanceAppWidget`/`GlanceAppWidgetReceiver` classes themselves live in `widget/`, since they are manifest components, not UI. `ui/widget/config/` holds each widget's config activity; every widget has one, if only for its per-instance colours (`domain/widget/WidgetColors.kt`: System/Light/Dark and, on API 31+, wallpaper colours on/off). Glance content takes those through `WidgetTheme`; the plain-`RemoteViews` faces, readouts and chronometers through `WidgetPalette.kt`, which resolves the `widget_*` palette under a forced day/night (the app's own tones are `widget_app_*`) and sets concrete colours, or day/night pairs, on the views. The analog and digital clocks are re-coloured on API 31+ only, since below that `AnalogClock`'s hands and a shape's background tint can't be set through `RemoteViews` |
+| `ui/settings/` | the settings hub (M10): `SettingsScreen`/`SettingsViewModel` (appearance, alarm/timer/clock defaults, reliability, data, help), `SelfCheckScreen`/`SelfCheckViewModel`, `BackupScreen`/`BackupViewModel`, all reachable from a gear icon on every tab, with no owning tab of their own |
+| `ui/widget/` | the three widgets' `@Composable` Glance content (M10), the only Compose this milestone adds outside a tab; the `GlanceAppWidget`/`GlanceAppWidgetReceiver` classes themselves live in `widget/`, since they are manifest components, not UI. `ui/widget/config/` holds each widget's config activity; every widget has one, if only for its per-instance colours (`domain/widget/WidgetColors.kt`: System/Light/Dark and, on API 31+, wallpaper colours on/off). Glance content takes those through `WidgetTheme`; the plain-`RemoteViews` faces, readouts and chronometers through `WidgetPalette.kt`, which resolves the `widget_*` palette under a forced day/night (the app's own tones are `widget_app_*`) and sets concrete colours, or day/night pairs, on the views. The analog and digital clocks are re-coloured on API 31+ only, since below that `AnalogClock`'s hands and a shape's background tint can't be set through `RemoteViews` |
 
 ---
 
@@ -147,12 +147,12 @@ kit module — the kit's roadmap keeps schedulers app-local.
 
 `ClockulaDatabase` is at **version 3** with five tables. Every column is a
 primitive: `Long`, `Int`, `String` or `Boolean`. There are **no Room
-`TypeConverter`s** — enums are stored as `Enum.name` in a `TEXT` column,
+`TypeConverter`s**. Enums are stored as `Enum.name` in a `TEXT` column,
 instants and durations as milliseconds, the repeat set as an `INTEGER` bitmask.
 That puts the whole entity↔domain translation inside the mappers, which are
 plain JVM objects that a unit test can feed a corrupt row. A converter would
 move the same translation into generated code, where an unknown enum name throws
-*inside a cursor read* — which is a crashed list, not a degraded row.
+*inside a cursor read*, and the result is a crashed list instead of a degraded row.
 
 Column names are snake_case via `@ColumnInfo`, so the SQL, the exported schema
 JSON and M10's JSON backup all read the same vocabulary in a diff.
@@ -164,7 +164,7 @@ JSON and M10's JSON backup all read the same vocabulary in a diff.
 | `id` | INTEGER pk | autogenerated |
 | `hour`, `minute` | INTEGER | read back through `TimeOfDay.clamped` |
 | `label` | TEXT | |
-| `enabled` | INTEGER | indexed — `enabled()` filters on it |
+| `enabled` | INTEGER | indexed; `enabled()` filters on it |
 | `repeat_days` | INTEGER | 7-bit mask, see below |
 | `skip_next_occurrence` | INTEGER | |
 | `ringtone_uri`, `vibrate`, `snooze_minutes`, `snooze_limit`, `volume_ramp_seconds`, `dismiss_challenge` | nullable | **overrides**; `NULL` = inherit `ClockDefaults`. For `ringtone_uri`: `NULL` = inherit, `clockula://silent` = deliberate silence (§13), anything else a content URI |
@@ -173,19 +173,19 @@ JSON and M10's JSON backup all read the same vocabulary in a diff.
 
 Per-alarm settings are nullable *overrides*, never concrete copies of the
 defaults. Storing concrete values would mean a later change to a default
-silently failed to reach alarms the user never customised — the opposite of what
+silently failed to reach alarms the user never customised, which is the opposite of what
 "default" means. `Alarm.resolveSettings(defaults)` is the pure function that
 collapses the two, and it uses `?:` throughout: a stored `false` for `vibrate`
 is a choice, not an absent value.
 
 `AlarmDao` is an **`abstract class`** rather than an interface, so it can carry
-a `@Transaction open suspend fun updateWithin(id, transform)` — a read, a
+a `@Transaction open suspend fun updateWithin(id, transform)`: a read, a
 transform and a write as one unit, mirroring `TimerDao.updateWithin`.
 `AlarmRepository.edit(id, transform)` is its domain face: it stamps `updated_at`
 from the wall clock and forces the id, so a transform can change a field but
 never move a row. The editor writes through it exclusively, because the engine
 can call `setEnabled(id, false)` underneath an open editor when a one-shot
-alarm's cycle closes — and a whole-row write from a stale read would re-enable
+alarm's cycle closes, and a whole-row write from a stale read would re-enable
 an alarm that had just rung. **M5 changes no schema**: no column was added, no
 version bumped, no migration written; a DAO becoming an abstract class changes
 no SQL.
@@ -209,7 +209,7 @@ must take its ring state with it (hence the cascade), and the alarm mapper's
 tests stay about alarms.
 
 **A missing row is not an error.** `AlarmStateRepository.state(id)` returns
-`AlarmRingState.initial(id)` — every instant null, count 0 — and nothing is
+`AlarmRingState.initial(id)` (every instant null, count 0), and nothing is
 written until there is something to write. `upcoming()` therefore resolves every
 alarm without creating a single row.
 
@@ -231,8 +231,7 @@ candidate is suppressed **iff** `candidate <= handledOccurrence` **and**
 `candidate <= now`. The second half is load-bearing: without it, a user who set
 the clock forward, let an alarm fire, then set it back would have every future
 occurrence suppressed forever. With it, only a past-or-present candidate can be
-suppressed — the watermark can silence a re-fire, but it can never silence the
-future.
+suppressed. The watermark can silence a re-fire, but never a future occurrence.
 
 One column, three bugs: "do not ring the same occurrence twice", "a backwards
 `TIME_SET` must not re-ring a dismissed alarm" and "a snoozed alarm's natural
@@ -243,8 +242,8 @@ occurrence must stay quiet" are the same rule.
 `alarms.skip_next_occurrence` is the user-facing boolean;
 `alarm_states.skipped_occurrence` is the concrete instant the skip is armed on.
 The flag alone is unusable: resolve at 06:00 on Monday for a daily 07:00 alarm
-and you correctly get Tuesday, but resolve again at 08:00 — after the skipped
-occurrence has gone by — and a naive "drop the first candidate" gives Wednesday,
+and you correctly get Tuesday, but resolve again at 08:00, after the skipped
+occurrence has gone by, and a naive "drop the first candidate" gives Wednesday,
 so the skip eats a second alarm. With the watermark:
 
 - flag set, no watermark ⇒ arm it on the first eligible candidate and fire the
@@ -269,8 +268,8 @@ occurrence, so skipping it is dismissing it in advance.
 | `state` | TEXT | `IDLE`/`RUNNING`/`PAUSED`/`EXPIRED`; unknown degrades to `IDLE` |
 | `remaining_millis` | INTEGER | authoritative when not `RUNNING` |
 | `started_at_elapsed_realtime_millis` | INTEGER? | `RUNNING` only |
-| `ends_at_elapsed_realtime_millis` | INTEGER? | `RUNNING` only — **authoritative** |
-| `ends_at_wall_clock_millis` | INTEGER? | `RUNNING` only — **post-reboot fallback only** |
+| `ends_at_elapsed_realtime_millis` | INTEGER? | `RUNNING` only; **authoritative** |
+| `ends_at_wall_clock_millis` | INTEGER? | `RUNNING` only; **post-reboot fallback only** |
 | `ringtone_uri` | TEXT? | `NULL` = inherit `ClockDefaults.timerRingtoneUri` |
 | `sort_order` | INTEGER | indexed |
 | `delete_after_use` | INTEGER | v3 (M9): a transient timer the contract asked for. Deleted rather than returned to IDLE when it is dismissed (§17) |
@@ -284,7 +283,7 @@ which §5 of `docs/PLAN.md` sends to DataStore rather than to Room. It is not a
 state must not appear in M10's JSON backup of a timer, it must not survive the
 timer's deletion, and the timer mapper's tests should stay about timers. It is
 not a `timer_states` table either, because at most one timer ring sounds at a
-time — so it is `timer_ring_sounding_since_millis` behind `TimerRingStateStore`
+time, so it is `timer_ring_sounding_since_millis` behind `TimerRingStateStore`
 (§6).
 
 ### `world_clocks`
@@ -300,11 +299,11 @@ time — so it is `timer_ring_sounding_since_millis` behind `TimerRingStateStore
 trims the id, rejects a blank or non-IANA one with `IllegalArgumentException`,
 and returns the *existing* row's id when the zone is already there. The lookup,
 the sort-order read and the insert happen in one transaction
-(`WorldClockDao.addIfAbsent`), so no other writer can slip a row in — or delete
-the row that won — between them, and the id handed back is always a row that
+(`WorldClockDao.addIfAbsent`), so no other writer can slip a row in between them
+(or delete the row that won), and the id handed back is always a row that
 exists rather than the insert's `-1` sentinel. Validity
 means membership of `java.time.ZoneId.getAvailableZoneIds()`, so `UTC` is
-accepted and fixed offsets like `+02:00` are not — IANA zone ids, not a bespoke
+accepted and fixed offsets like `+02:00` are not. The ids are IANA zone ids, not a bespoke
 city table (`PLAN.md` §5). A zone the device's tzdata later drops is **kept**,
 not blanked; `WorldClock.isKnownZone` reports it and the UI can show it as
 broken. Losing the user's row silently would be worse.
@@ -330,7 +329,7 @@ and drawn with no time, no offset and no day (§16).
 | `split_millis`, `cumulative_millis` | INTEGER | |
 
 `LapDao.appendLap` is `@Transaction`: it reads the previous lap, derives the
-index and the split, and inserts — so two concurrent laps cannot collide on the
+index and the split, and inserts, so two concurrent laps cannot collide on the
 unique index.
 
 **M7 changes no schema here.** The table already had every column the tab
@@ -349,7 +348,7 @@ valid bits.
 
 The platform `AlarmClock.EXTRA_DAYS` contract speaks `java.util.Calendar`
 constants (Sunday = 1 … Saturday = 7). **That translation happens at the intent
-boundary and never in storage** — M9 put it in one private function,
+boundary and never in storage**. M9 put it in one private function,
 `AlarmClockRequests.dayOfWeek`, which hands its `Set<DayOfWeek>` to
 `RepeatDays.of` so the 7-bit mask is never built by hand.
 
@@ -366,7 +365,7 @@ The exported JSON lives at
 `app/schemas/de.jeanlucmakiola.clockula.data.db.ClockulaDatabase/`, one file per
 version, all committed, and the directory is also wired in as an `androidTest`
 asset directory so `MigrationTestHelper` can open a v1 database on device.
-`SchemaExportTest` fails the JVM test run if a version goes missing — the
+`SchemaExportTest` fails the JVM test run if a version goes missing, so the
 previous one is never regenerated away. There is **no
 `fallbackToDestructiveMigration`**: `PLAN.md` §12 requires tested migrations
 from v1, and a destructive fallback would quietly eat a user's alarms.
@@ -374,8 +373,8 @@ from v1, and a destructive fallback would quietly eat a user's alarms.
 `Migrations.ALL` is the single list the database builder is handed and the list
 the tests assert on. `MIGRATION_1_2` is one `CREATE TABLE alarm_states`, copied
 verbatim from the exported schema's `createSql`, and the instrumentation test
-runs it against a real v1 database and *validates* the result against `2.json` —
-a migration that fails eats the user's alarms, so it is proved rather than
+runs it against a real v1 database and *validates* the result against `2.json`.
+A migration that fails eats the user's alarms, so it is proved rather than
 eyeballed.
 
 **v2 → v3 (M9).** `MIGRATION_2_3` is two `ALTER TABLE … ADD COLUMN
@@ -384,7 +383,7 @@ delete_after_use INTEGER NOT NULL DEFAULT 0`, one on `alarms` and one on
 `SKIP_UI` alarm or timer "should be removed after it has been dismissed";
 without it, a user who talks to their assistant every morning accumulates a list
 of dead 06:30 rows (§17). Both entity columns declare
-`defaultValue = "0"` — load-bearing, because without it the exported schema
+`defaultValue = "0"`. That is load-bearing: without it the exported schema
 records no default, `runMigrationsAndValidate` compares it against a migrated
 table that *has* one, and the migration test fails for a reason nobody enjoys
 finding. Every row written before M9 therefore reads as the permanent alarm or
@@ -403,7 +402,7 @@ interface WallClock          { fun now(): Instant }
 interface ElapsedRealtimeClock { fun elapsedRealtime(): Duration }
 ```
 
-Both are **injected everywhere and never called statically** — that is the only
+Both are **injected everywhere and never called statically**. That is the only
 reason the distinction can be tested from both sides. Their Android
 implementations are two one-line classes in `data/time/`
 (`System.currentTimeMillis()` and `SystemClock.elapsedRealtime()`). Any new API
@@ -430,7 +429,7 @@ clock and is a **fallback only**.
 > because `elapsedRealtime()` never decreases within one boot.
 
 So a user moving the system clock cannot make the anchor look stale and cannot
-warp a running timer — forwards or backwards. The wall-clock value is read
+warp a running timer, forwards or backwards. The wall-clock value is read
 *only* when that monotonic test says "different boot", and then only to answer
 "approximately how much is left", with `TimerSnapshot.anchorIsStale = true` so
 the UI can say so. Without it, a reboot would strand every running timer.
@@ -439,21 +438,21 @@ the UI can say so. Without it, a reboot would strand every running timer.
 the *new* boot's uptime is still below the old `startedAtElapsedRealtime`. Once
 the device has been up longer than that, the same comparison says "same boot"
 and the row is resolved against a dead pre-reboot anchor, reading as **live and
-not stale** — `endsAtWallClock` is never consulted.
+not stale**, and `endsAtWallClock` is never consulted.
 
 This window opens sooner than "after it would have expired". A timer started two
 minutes into a boot re-enters it about two minutes into the *next* boot: a
 30-minute timer started at uptime 2 min, with the device rebooted ten minutes
 later, reads as live and non-stale from uptime 2 min of the new boot onwards, and
 counts down from a number that means nothing. So: **a stale anchor can read as
-live, well before expiry.** The cost is accepted here because the alternative —
-consulting the wall clock to decide staleness — would let a user moving the
+live, well before expiry.** The cost is accepted here because the alternative
+(consulting the wall clock to decide staleness) would let a user moving the
 system clock warp a running timer, which `PLAN.md` §5 forbids outright.
 
 Closing it properly needs a persisted boot identifier, and **M3 added one**.
-`RebootRepair` runs at the top of every boot — from `SystemEventReceiver`'s
+`RebootRepair` runs at the top of every boot (from `SystemEventReceiver`'s
 `BOOT_COMPLETED` and again from `ClockulaApp.onCreate`, so a broadcast the
-system never delivered is still caught — and rewrites every running timer from
+system never delivered is still caught) and rewrites every running timer from
 `endsAtWallClock` before the new uptime can climb past any stored anchor. A
 timer already past its wall-clock end becomes `EXPIRED`; one with no wall-clock
 fallback is paused at what it banked.
@@ -461,20 +460,20 @@ fallback is paused at what it banked.
 The gate is the boot id, not a flag in memory: `BootId` is
 `Settings.Global.BOOT_COUNT` (API 24+, no permission), and two ids that both
 have a count are the same boot exactly when the counts match. When either side
-has no count — a device that will not give `BOOT_COUNT` up — it falls back to
+has no count (a device that will not give `BOOT_COUNT` up), it falls back to
 comparing `wallClock.now() - elapsedRealtime()`, the instant the device booted,
 within one minute. That fallback is **best-effort and documented as such**: the
 derived instant drifts under NTP correction, which is what the tolerance
 absorbs. It costs nine lines and means an unreadable `BOOT_COUNT` degrades to
 approximately-right rather than to never noticing a reboot. The id is stored as
-one DataStore string, `last_boot_id`, and decoding is strict — anything
+one DataStore string, `last_boot_id`, and decoding is strict: anything
 malformed reads as "no known previous boot", i.e. "repair".
 
 The mirror image of the reboot repair is the **clock change**. A reboot kills
 the monotonic anchors and leaves `endsAtWallClock` standing;
-`ACTION_TIME_CHANGED`/`ACTION_TIMEZONE_CHANGED` does the opposite — the
+`ACTION_TIME_CHANGED`/`ACTION_TIMEZONE_CHANGED` does the opposite: the
 monotonic anchors still hold and the wall-clock one has just become a lie. That
-value is not decoration: it is the countdown notification's chronometer base and
+value is the countdown notification's chronometer base and
 the reboot fallback, so a stale one makes a running timer's notification read
 *finished* and a reboot after the change ring the timer at the wrong minute. So
 `TimerEngine.onSystemTimeOrZoneChanged` calls `reanchorWallClocks`, which
@@ -490,7 +489,7 @@ result written back before another writer can interleave. The ringing service
 marking a timer expired and the user adding a minute to it therefore cannot
 swallow each other's edit.
 
-`addTime` — "+1 min" — is one rule over all four states, and the extra is
+`addTime` ("+1 min") is one rule over all four states, and the extra is
 measured **from the tap, never from an anchor that has gone by**:
 
 | Before | After |
@@ -501,20 +500,20 @@ measured **from the tap, never from an anchor that has gone by**:
 | `IDLE` | nothing. A stale notification button is a silent no-op |
 
 `duration_millis` is never moved on any branch, so `reset` still returns the
-timer to the length the user configured — which is what makes a `timers` row its
+timer to the length the user configured, which is what makes a `timers` row its
 own preset.
 
 M6 rewrote the `EXPIRED` branch, which M2 left "paused, not running: the user
 still has to press start". "+1 min" on a timer that has just rung is the single
 most common gesture in a timer app, and a second tap on Start is a papercut.
 Resuming in the same transaction is also the only way to avoid emitting an
-intermediate `PAUSED` frame to the live pill and to the row — and the reasoning
+intermediate `PAUSED` frame to the live pill and to the row. The reasoning
 is M2's own, generalised: *the user asked for `extra` more than zero, not
 `extra` more than an anchor that has gone by.*
 
 A `RUNNING` row missing either elapsed anchor is treated as corrupt, not as
 stale-by-reboot: it reads back whatever it last banked, flagged stale. It never
-throws — a throw inside a list read is a crashed screen.
+throws, because a throw inside a list read is a crashed screen.
 
 ### The stopwatch has no fallback, on purpose
 
@@ -530,7 +529,7 @@ displayed to two decimal places.
 timer, and had the same blind spot: once the new boot's uptime passes the stored
 `startedAtElapsedRealtime`, the reboot goes unnoticed and the run reports
 `accumulated + (elapsedRealtime - startedAtElapsedRealtime)` as **live and not
-stale** — a segment it never actually ran.
+stale**, counting a segment it never actually ran.
 
 **M3 closes it.** The same boot gate that repairs timers also calls
 `StopwatchRepository.pauseAfterReboot()`: a `RUNNING` run is written back
@@ -551,7 +550,7 @@ three surfaces at once.
 
 One honest consequence, recorded rather than papered over. A lap recorded inside
 a segment the repair later discarded keeps its own cumulative, which can exceed
-the run's banked `accumulated` — a stopwatch that ran forty seconds and lapped
+the run's banked `accumulated`: a stopwatch that ran forty seconds and lapped
 twice, then met a reboot, has `accumulated = 0` and `lastLapCumulative = 40s`.
 The reading is therefore **floored at the last lap's total** as well as at zero:
 a readout sitting below a lap the same run printed is not one anyone can
@@ -564,7 +563,7 @@ The floor is **banked, not only displayed**. Resuming such a run writes
 bank the same floored reading rather than the raw snapshot. Without that the
 record would tick from below its own last lap: the tab would sit frozen at the
 floored value for as long as the discarded segment lasted while the shade's
-chronometer — derived from the floored reading once and then free-running —
+chronometer (derived from the floored reading once and then free-running)
 counted on without it, and the next lap would record a cumulative *below* the
 previous one and drag every readout backwards. `pauseAfterReboot` itself is
 still untouched; the banking happens on the way back out, in
@@ -578,11 +577,10 @@ repair would have) instead of hitting a silent "already running" no-op, while
 Lap is refused rather than recorded below the last one.
 
 **M8 adds a wall-clock surface.** The world clock is a calendar fact about
-somewhere else, so it reads `WallClock.now()` and never `ElapsedRealtimeClock` —
-the same column of the table above that alarms sit in. What is worth writing
-down is the *cadence*: **both the instant and the device zone are re-read on
-every tick**, from the injected `WallClock` and `ZoneProvider`. That is what
-makes `TIME_SET` and `TIMEZONE_CHANGED` free for this tab — it self-heals
+somewhere else, so it reads `WallClock.now()` and never `ElapsedRealtimeClock`,
+the same column of the table above that alarms sit in. **Both the instant and the
+device zone are re-read on every tick**, from the injected `WallClock` and `ZoneProvider`. That is what
+makes `TIME_SET` and `TIMEZONE_CHANGED` free for this tab: it self-heals
 within one tick, and `SystemEventReceiver` needs no new branch. The zone never
 comes from `ZoneId.systemDefault()` at a call site; a build rule (§8) fails on
 one anywhere under `domain/` or `ui/`.
@@ -596,19 +594,19 @@ Four slices:
 
 | Slice | Keys | Owner |
 |---|---|---|
-| Appearance (M1) | `theme_mode`, `dynamic_color` | `AppearancePrefs` in `core-prefs` — the family's shared key names |
+| Appearance (M1) | `theme_mode`, `dynamic_color` | `AppearancePrefs` in `core-prefs`, the family's shared key names |
 | Clock defaults (M2) | `default_snooze_minutes`, `default_snooze_limit`, `default_vibrate`, `default_volume_ramp_seconds`, `default_alarm_ringtone_uri`, `default_timer_ringtone_uri`, `default_dismiss_challenge`, `home_zone_id` | `ClockPrefs`, surfaced as `SettingsPrefs.defaults: Flow<ClockDefaults>` |
-| Stopwatch run record (M2) | `stopwatch_state`, `stopwatch_started_elapsed_millis`, `stopwatch_accumulated_millis`, `stopwatch_last_lap_cumulative_millis` — the last of which M7 is the first caller of, for the in-progress lap's split | `StopwatchPrefs`, behind `StopwatchStateStore` |
-| System facts (M3) | `last_boot_id` | `SystemPrefs`, behind `BootStateStore` — the persisted half of the reboot gate |
-| Timers (M6) | `timer_presets`, `timer_ring_sounding_since_millis` | `TimerPrefs` — the presets surfaced as `SettingsPrefs.timerPresets`, the ring session's anchor behind `TimerRingStateStore` |
+| Stopwatch run record (M2) | `stopwatch_state`, `stopwatch_started_elapsed_millis`, `stopwatch_accumulated_millis`, `stopwatch_last_lap_cumulative_millis` (M7 is the first caller of the last, for the in-progress lap's split) | `StopwatchPrefs`, behind `StopwatchStateStore` |
+| System facts (M3) | `last_boot_id` | `SystemPrefs`, behind `BootStateStore`, the persisted half of the reboot gate |
+| Timers (M6) | `timer_presets`, `timer_ring_sounding_since_millis` | `TimerPrefs`: the presets surfaced as `SettingsPrefs.timerPresets`, the ring session's anchor behind `TimerRingStateStore` |
 
 The stopwatch's *run* is a single record, so it lives in DataStore rather than
 as a one-row table (`PLAN.md` §5); its *laps* are a list, so they live in Room.
 It is also read and written as a *record*: `StopwatchPrefs.read`/`write` map all
 four keys in one snapshot and one `PrefStore.edit` transaction, and
 `StopwatchStateStore.run` maps that snapshot rather than combining four key
-flows. A state and its anchor only mean anything together, so no reader — and no
-process killed mid-write — ever sees `RUNNING` without its start anchor.
+flows. A state and its anchor only mean anything together, so no reader, and no
+process killed mid-write, ever sees `RUNNING` without its start anchor.
 
 **Clamp on read as well as on write.** Every bounded value goes through
 `Pref.map`, which applies the same clamp in both directions: snooze 1–60
@@ -620,15 +618,15 @@ absent; blank strings read back as `null`.
 
 `home_zone_id` got its **first reader and its first writer in M8**, two
 milestones after the key was added. The reader is `HomeZone.resolve(stored,
-deviceZone)`, which is the whole home-zone rule in one pure function — the
-stored zone when the device still knows it, else the device's own — and the
+deviceZone)`, which is the whole home-zone rule in one pure function (the
+stored zone when the device still knows it, else the device's own), and the
 writer is the World clock tab's top-bar action, which also clears it so home
 follows the device again. Nothing is seeded: a fresh install has no stored home
 zone and no world clock row, and the hero face simply shows the device's zone
 (§16).
 
 `timer_presets` is the same discipline over a *list*: one comma-joined string of
-millis, sanitised both ways through `TimerPresets.sanitise` — non-numeric
+millis, sanitised both ways through `TimerPresets.sanitise`: non-numeric
 entries dropped, anything outside 1 s…24 h **dropped rather than clamped**
 (a clamp would silently turn one preset into another, possibly a duplicate),
 de-duplicated, sorted ascending, capped at twelve. An **absent** key means the
@@ -639,7 +637,7 @@ means the user removed them all, and is honoured. Adds and removes go through
 `timer_ring_sounding_since_millis` is wall clock, deliberately: "how long has
 this been making noise" is a question a reboot must not reset, which is why
 `alarm_states.ringing_since` is wall clock too. §5's elapsed-realtime rule
-governs the *countdown*, not the ring's age. Null — the key absent — means no
+governs the *countdown*, not the ring's age. Null (the key absent) means no
 session, and the engine writes it only when the value changed.
 
 `SettingsPrefs.defaults` and `StopwatchStateStore.run` are each built **once**
@@ -650,7 +648,7 @@ composed from the individual key flows, so writing an unrelated preference never
 re-emits them.
 
 A corrupt `preferences_pb` is replaced with empty preferences rather than
-throwing `CorruptionException` out of every launch — these values feed the theme
+throwing `CorruptionException` out of every launch. These values feed the theme
 before the first frame, and the alternative is an app only "clear data" can fix.
 
 ---
@@ -667,7 +665,7 @@ Hilt, `SingletonComponent` throughout. Nine app modules plus the kit's:
 | `TimeModule` | `@Binds` for `WallClock`, `ElapsedRealtimeClock`, `ZoneProvider` and `BootIdProvider` |
 | `AlarmModule` | `@Binds` for the alarm engine's four seams: `AlarmScheduler`, `AlarmCapabilities`, `RingCoordinator`, `AlarmNotifier` |
 | `RingtoneModule` | `@Binds` for the two ringtone seams, `RingtoneCatalog` and `RingtonePreviewer`, and for `MediaLibrary` |
-| `ZoneModule` | `@Binds` for the one ICU seam: `ZoneNames → IcuZoneNames` (M8). `ZoneDirectory` needs no binding — it is a `@Singleton` `@Inject` class |
+| `ZoneModule` | `@Binds` for the one ICU seam: `ZoneNames → IcuZoneNames` (M8). `ZoneDirectory` needs no binding; it is a `@Singleton` `@Inject` class |
 | `StopwatchModule` | `@Binds` for the stopwatch engine's one seam: `StopwatchServiceHandle` (the foreground service). It has no scheduler, because nothing the stopwatch does has a deadline |
 | `TimerModule` | `@Binds` for the timer engine's three seams: `TimerScheduler` (the one elapsed-realtime slot), `TimerServiceHandle` (the foreground service), `AlarmRingStatus` (read-only: "is an alarm ringing") |
 
@@ -676,7 +674,7 @@ process-lifetime `@ApplicationScope` the receivers launch on, and `core-prefs`
 supplies `PrefStore`, `Pref` and the appearance keys.
 
 `BroadcastReceiver.onReceive` is abstract, so a Kotlin subclass cannot call
-`super.onReceive(...)` — which is exactly where Hilt injects. All five
+`super.onReceive(...)`, which is exactly where Hilt injects. All five
 receivers therefore extend one concrete no-op base, `HiltBroadcastReceiver`; the
 Hilt plugin rewrites each receiver's superclass to its generated `Hilt_…` class
 and the `super` call lands on the injecting one.
@@ -687,15 +685,15 @@ queries onto its own executor and runs Flow queries off the main thread, so a
 half already runs on `@IoDispatcher`, wired once in `DataModule`.
 
 `SystemRingtoneCatalog` is the first documented exception: it takes
-`@IoDispatcher`, because a raw `ContentResolver` query — and
-`RingtoneManager`'s cursor, and `MediaPlayer.prepare` in
-`SystemRingtonePreviewer` — dispatches nothing of its own and would otherwise
-block whichever thread asked.
+`@IoDispatcher`, because a raw `ContentResolver` query dispatches nothing
+of its own and would otherwise block whichever thread asked. The same goes for
+`RingtoneManager`'s cursor and for `MediaPlayer.prepare` in
+`SystemRingtonePreviewer`.
 
 `ZoneDirectory` (M8) is the **second**, for the same reason: building the zone
 catalog is ~450 ids times three ICU calls, ICU dispatches nothing of its own,
 and the build happens the first time a picker opens. It is also cached on the
-locale tag — AppCompat's per-app language can change under a running activity —
+locale tag (AppCompat's per-app language can change under a running activity)
 and guarded by one `Mutex`, so two collectors opening the picker at once build
 once.
 
@@ -739,8 +737,8 @@ and a TalkBack-shaped accessibility click completing the hold challenge.
   `FakeBootIdProvider` complete the set.
 - **A real DataStore on a temp file.** The preference and stopwatch tests write
   an actual `preferences_pb` under a JUnit 5 `@TempDir`, which is what makes
-  "the run survives process death" a real assertion — a second repository is
-  constructed over the same file — rather than a fake's memory.
+  "the run survives process death" a real assertion rather than a fake's memory:
+  a second repository is constructed over the same file.
 - **Injected fake clocks.** `FakeWallClock` moves by hand, including backwards,
   as a user can; `FakeElapsedRealtimeClock` has an explicit `reboot()`. The
   headline test starts a timer, jumps the wall clock three hours each way, and
@@ -749,7 +747,7 @@ and a TalkBack-shaped accessibility click completing the hold challenge.
 - **Pure functions carry the hard parts.** DST, the resolver's precedence, the
   volume ramp and the "never to silence" policies are all `object`s with no
   collaborators, so the milestone's riskiest behaviour is asserted a hundred
-  times over with hand-built inputs — including all 128 repeat masks and four
+  times over with hand-built inputs, including all 128 repeat masks and four
   zones with awkward transitions.
 - **Instrumentation-only** is the half a fake cannot prove: generated SQL,
   unique indices, real `@Transaction` behaviour, the foreign key cascading, the
@@ -757,8 +755,8 @@ and a TalkBack-shaped accessibility click completing the hold challenge.
   database opening at its current version.
 - **`ArchitectureRulesTest`** greps the main source set for Room leakage above
   `data/` and Android imports inside `domain/`, `alarm/AlarmEngine.kt` and
-  `system/`. It is the boundary of §2 made mechanical — and the engine's
-  testability is a build-gate fact rather than a habit.
+  `system/`. It is the boundary of §2 made mechanical, and it turns the engine's
+  testability into a build-gate fact rather than a habit.
 
 **M5 kept the posture for a whole form**, which is where a screen usually
 reaches for Robolectric. Everything a tap decides was pushed out of the
@@ -770,14 +768,14 @@ chosen), `RingtonePicker` (which rows exist and which is checked),
 `AudioSourcePolicy` (the fallback order, silence included) and `AlarmRoutes`
 (the route strings). Every write, every reschedule and every preview is a method
 on one of the two ViewModels, which the tests build over the **real**
-`AlarmEngine` across the fake DAOs and fake seams — the arrangement
+`AlarmEngine` across the fake DAOs and fake seams, the arrangement
 `testing/AlarmEngineHarness.kt` now lifts out of `AlarmRingViewModelTest`. What
 is left in the composables is `Text(...)`, `Switch(...)` and `stringResource`.
 
 Three `ArchitectureRulesTest` rules pin that mechanically: no `*ViewModel.kt`,
 `*UiState.kt` or `*Source.kt` imports `androidx.compose.`; the same files import
 no `android.`; and no file under `ui/` names `AlarmResolver` or
-`AlarmOccurrences` — the screen takes the engine's resolution and re-derives
+`AlarmOccurrences`: the screen takes the engine's resolution and re-derives
 none of its time arithmetic. All three held retroactively for M4's files, so
 they pin existing discipline rather than an aspiration.
 
@@ -790,7 +788,7 @@ removing the row. **They have not been run**: no device is attached to the
 machine this milestone was built on, so the gate compiles them and this
 paragraph says so.
 
-**M6 kept it for a second screen — and for a foreground service**, which is the
+**M6 kept it for a second screen and for a foreground service**, which is the
 other place a project usually gives in. Every decision left the composables and
 the service: `TimerReadings` (the app's one timer precedence, extracted from
 M4's pill so the pill, the notification and the ring cannot disagree),
@@ -800,7 +798,7 @@ M4's pill so the pill, the notification and the ring cannot disagree),
 `TimerDurationEntry` (the keypad, as a state machine over a digit string) and
 `TimerListRows`. `TimerService` holds **no policy and no state** beyond one
 `alreadyAlerted` flag: it asks `TimerEngine.serviceState(...)` and actuates the
-answer, and even the two `delay` amounts come from the engine — so the timings
+answer, and even the two `delay` amounts come from the engine, so the timings
 are asserted in a JVM test.
 
 Three new fakes complete the seam set in M3's shape: `FakeTimerScheduler` holds
@@ -811,13 +809,13 @@ engine a `true` instead of building alarm state.
 `testing/TimerEngineHarness.kt` is `AlarmEngineHarness`'s arrangement for the
 other engine: the **real** `TimerEngine` over the real `TimerRepositoryImpl`,
 the fake DAO, the three fake seams, the real `RebootRepair` and a real DataStore
-under a `@TempDir` — with a counting `DataStore` wrapper, so "the session anchor
+under a `@TempDir`, with a counting `DataStore` wrapper, so "the session anchor
 is persisted **once** across three reads" is assertable without reaching into
 the store.
 
 Three more `ArchitectureRulesTest` rules: `timer/TimerEngine.kt` joins the
 Android-free list; no file under `ui/` *uses* `TimerScheduler`, `TimerService`,
-`TimerRingPolicy` or `AlarmManager` (the mirror of the alarm rule — the screen
+`TimerRingPolicy` or `AlarmManager` (the mirror of the alarm rule: the screen
 schedules nothing and decides no ring); and `MediaPlayer` appears only under
 `ring/` and `data/ringtones/`, which makes "reuses M3's audio path" mechanical:
 a third audio path cannot be added without the build failing.
@@ -834,7 +832,7 @@ attached to the machine this milestone was built on.
 break it, because ICU and `Canvas` both look like they need a device. They do
 not. Everything ICU answers is behind `ZoneNames`, faked in a unit test.
 Everything the face *draws* is `DrawScope` calls over angles from `AnalogFace`
-and a fraction from `DayNight` — two pure objects with no collaborators, so the
+and a fraction from `DayNight`, two pure objects with no collaborators, so the
 geometry is asserted at every minute of the day without a pixel. Everything the
 list and the picker *decide* is pure too: `WorldClockRows`, `ZonePickerRows`,
 `ZoneSearch`, `ZoneComparisons`, `ZoneCatalog` and `WorldClocks`. And everything
@@ -843,8 +841,8 @@ the tab *writes* is a `WorldClockViewModel` method, tested over the **real**
 `SettingsPrefs` over a real DataStore under a `@TempDir`.
 
 One new fake and one new harness. `FakeZoneNames` is settable per method, counts
-calls per method — which is what makes "the catalog is built once" and "the
-display name is asked for once per DST phase" assertable — and carries a
+calls per method (which is what makes "the catalog is built once" and "the
+display name is asked for once per DST phase" assertable), and carries a
 `failEverything` flag that makes every call throw, which is what makes "the
 directory never propagates an ICU failure" assertable. `WorldClockHarness` is
 `StopwatchEngineHarness`'s arrangement for a tab with no engine.
@@ -855,37 +853,37 @@ Three more `ArchitectureRulesTest` rules: `android.icu` is named only under
 `PLAN.md` §8's "not sprinkled everywhere" mechanical (the ring screen and timer
 progress are sanctioned too, so widening the allowlist is a deliberate edit
 rather than a drift); and no file under `domain/` or `ui/` uses
-`ZoneId.systemDefault()` or `TimeZone.getDefault()` in code — the zone is a
+`ZoneId.systemDefault()` or `TimeZone.getDefault()` in code; the zone is a
 parameter, from `ZoneProvider`. All three held retroactively for M0–M7's files.
 
 Four more instrumentation tests: the hero face really composing and its
 semantics really reaching TalkBack, the picker's real `Dialog` and real IME
 really adding a city, and the **Remove** and **Move up** accessibility actions
-really working the way TalkBack would drive them. **They have not been run** —
+really working the way TalkBack would drive them. **They have not been run**:
 no device is attached to the machine this milestone was built on.
 
 **M9 kept it for a boundary**, which is the last place a project usually gives
 in, because "it is an `Intent`" sounds like it needs a device. It does not. The
 door is split so that everything which *decides* is pure Kotlin under
-`domain/interop/` — `AlarmClockRequests` (every range, type and sentinel rule),
-`AlarmMatching` (which alarms a search names), `IntentExtras`, `InteropText`,
-`InteropDeepLinks` — and the Android half is two files that carry no policy:
+`domain/interop/` (`AlarmClockRequests` for every range, type and sentinel rule,
+`AlarmMatching` for which alarms a search names, `IntentExtras`, `InteropText`,
+`InteropDeepLinks`), and the Android half is two files that carry no policy:
 one turns a `Bundle` into a `Map<String, Any?>`, one turns an outcome into an
 `Intent`. `AlarmClockHandler` is the orchestrator and, like the three engines,
 contains no `android.*` import, so the whole contract is asserted from a plain
-JUnit test with hand-built inputs — including an intent hostile in every extra
+JUnit test with hand-built inputs, including an intent hostile in every extra
 at once.
 
 One new harness, and it is deliberately **not** a composition of the existing
 ones. `AlarmEngineHarness`, `TimerEngineHarness`, `StopwatchEngineHarness` and
 `WorldClockHarness` each build a DataStore over the *same* file name under the
-test's `@TempDir`, and DataStore refuses a second instance over a live file — so
+test's `@TempDir`, and DataStore refuses a second instance over a live file, so
 composing two of them throws. `InteropHarness` builds **one** `PrefStore`, one
 `SettingsPrefs`, the fake DAOs, the fake seams, the **real** `AlarmEngine`, the
 **real** `TimerEngine` and the real repositories over them, and exposes the
 handler built from those. `FakeAlarmDao` also grew an `onDeleted` hook the
 harnesses wire to `alarm_states`, because a fake cannot infer `ON DELETE
-CASCADE` from a schema it does not have — and M9 is the first milestone that
+CASCADE` from a schema it does not have, and M9 is the first milestone that
 deletes an alarm from inside the engine.
 
 Four more `ArchitectureRulesTest` rules: `interop/AlarmClockHandler.kt` joins
@@ -894,23 +892,23 @@ the Android-free list; the platform's `AlarmClock` literals appear only in
 `"android.intent.action.SET_ALARM"` and drift; `alarm/android/AndroidAlarmScheduler.kt`
 never names `AlarmRingActivity` in code, which pins the show-intent fix (§11);
 and no file under `ui/` uses `AlarmClockHandler`, `AlarmClockRequests` or
-`IntentExtras` — the screen parses no intent from another app.
+`IntentExtras`: the screen parses no intent from another app.
 
 And one new **`ManifestRulesTest`**, which reads `app/src/main/AndroidManifest.xml`
 as a file the way `ArchitectureRulesTest` reads sources: exactly two exported
 components, the permission on the door and **not** on `MainActivity`, all seven
 actions present, both intent-filters present (one without a `<data>` element and
 one with the `clockula` scheme), the door's recents/history/affinity attributes,
-every receiver still unexported, and the requested-permission set unchanged. The
-manifest is where this milestone could be silently wrong — none of it fails a
-compiler — so it fails here.
+every receiver still unexported, and the requested-permission set unchanged. None of
+the manifest fails a compiler, so it is where this milestone could be silently
+wrong, and the test makes it fail here instead.
 
 Five more instrumentation tests: our literals really being the platform's own
 `android.provider.AlarmClock` constants (the one comparison only a device can
 make), each of the seven actions really resolving to the door, a deeplinked
 `DISMISS_ALARM` really matching the second filter, the chooser dialog really
 composing and a tap really dismissing, and the door really reaching `DESTROYED`
-without showing a window — plus two migration cases for v2 → v3. **They have
+without showing a window, plus two migration cases for v2 → v3. **They have
 not been run**: no device is attached to the machine this milestone was built
 on.
 
@@ -933,7 +931,7 @@ directory is added as an `androidTest` assets source dir. It is written during
 
 Reproducibility rules, checked by `scripts/check_reproducible_release.sh`:
 `vcsInfo { include = false }` on release, `dependenciesInfo` out of the APK and
-bundle, and **no foojay toolchain resolver anywhere** — not in this repo, not in
+bundle, and **no foojay toolchain resolver anywhere**: not in this repo, not in
 floret-kit, not in a comment.
 
 floret-kit is a git submodule consumed as a composite build; it needs a
@@ -950,7 +948,7 @@ M8 adds **one** dependency coordinate: `androidx.graphics:graphics-shapes`,
 pinned at `1.0.1`, the version that already resolved transitively through
 `androidx.compose.material3`. `MaterialShapes` lives in material3, but `Morph`
 and `RoundedPolygon` are `androidx.graphics.shapes`, and the world clock's face
-imports that package directly — a direct import on an undeclared transitive
+imports that package directly. A direct import on an undeclared transitive
 dependency is how a Renovate bump breaks a build nobody declared. Pinning to
 what already resolved means the dependency graph does not move in this
 milestone.
@@ -958,28 +956,28 @@ milestone.
 ### Manifest
 
 Clockula's permission set is the alarm engine's, and nothing more. Each one is
-declared because a specific path would otherwise fail — silently, at 07:00.
+declared because a specific path would otherwise fail, silently, at 07:00.
 
 | Permission | Why |
 |---|---|
 | `USE_EXACT_ALARM` | install-granted from API 33 for an app whose core function is alarms; no dialog, nothing to revoke |
-| `SCHEDULE_EXACT_ALARM` `android:maxSdkVersion="32"` | covers 31–32, where it is pre-granted. Bounded at 32 so it never overlaps the one above — that is the documented pattern and it keeps the store listing's story clean. Below 31 an exact alarm needs no permission at all |
+| `SCHEDULE_EXACT_ALARM` `android:maxSdkVersion="32"` | covers 31–32, where it is pre-granted. Bounded at 32 so it never overlaps the one above; that is the documented pattern and it keeps the store listing's story clean. Below 31 an exact alarm needs no permission at all |
 | `RECEIVE_BOOT_COMPLETED` | AlarmManager keeps nothing across a reboot |
 | `USE_FULL_SCREEN_INTENT` | the ring screen over the lock screen |
 | `POST_NOTIFICATIONS` | the ring and snoozed notifications |
-| `FOREGROUND_SERVICE`, `FOREGROUND_SERVICE_SYSTEM_EXEMPTED` | the two ringing services — the alarm's, and (since M6) the timers' |
+| `FOREGROUND_SERVICE`, `FOREGROUND_SERVICE_SYSTEM_EXEMPTED` | the two ringing services: the alarm's, and (since M6) the timers' |
 | `WAKE_LOCK` | keep the CPU up for the length of a ring |
 | `VIBRATE` | an alarm and a timer both vibrate, and vibrate alone when no audio source opens |
 
-**M6 adds no permission at all.** A timer never takes over the screen — no
-full-screen intent, no ring activity, no `showWhenLocked` — because its user set
+**M6 adds no permission at all.** A timer never takes over the screen (no
+full-screen intent, no ring activity, no `showWhenLocked`), because its user set
 it minutes ago and is in the room, so the heads-up notification, the audio, the
 pill's expired state and the tab's expired row are four ways to notice and none
 of them seizes the device. The foreground-service, wake-lock, vibrate and
 notification set above already covers the rest.
 
 Neither of the two revocable ones can silence an alarm. A denied
-`POST_NOTIFICATIONS` costs the user the notification and nothing else — the
+`POST_NOTIFICATIONS` costs the user the notification and nothing else, because the
 audio belongs to the foreground service. A denied `USE_FULL_SCREEN_INTENT`
 degrades to a `PRIORITY_MAX`, `CATEGORY_ALARM` heads-up notification on the same
 HIGH-importance channel, which still rings. M3 declares them; M4 asks for them
@@ -988,15 +986,15 @@ and M10's self-check screen explains them.
 Both ringing services' `android:foregroundServiceType` is **`systemExempted`**,
 which is the case Android's own `fgs-types-required` guidance names: an app
 holding `SCHEDULE_EXACT_ALARM` or `USE_EXACT_ALARM` and using a foreground
-service to continue alarms in the background. Not `mediaPlayback` — an alarm is
-not the user's media session, and it would owe the store a media justification —
-and emphatically not `shortService`, which caps at about three minutes against a
+service to continue alarms in the background. It is not `mediaPlayback`, because an alarm
+is not the user's media session and it would owe the store a media justification,
+and it is emphatically not `shortService`, which caps at about three minutes against a
 ten-minute ring window.
 
 All five receivers are `android:exported="false"`: a protected system broadcast
 is delivered to an unexported receiver anyway (this is how `androidx.work`
 declares its own `RescheduleReceiver`), and a `PendingIntent` the app created is
-delivered regardless — so nothing else can fake a fire.
+delivered regardless, so nothing else can fake a fire.
 `ACTION_LOCKED_BOOT_COMPLETED` is deliberately not handled: it needs
 `directBootAware`, and the database and DataStore live in credential-encrypted
 storage that is unreadable before the first unlock.
@@ -1006,7 +1004,7 @@ Compose drawing need none: the world clock schedules nothing, wakes nothing,
 rings nothing and posts no notification.
 
 **M9 adds no `<uses-permission>` either.** Its one new permission string is
-`android:permission` **on the new activity** — a requirement the *caller* must
+`android:permission` **on the new activity**: a requirement the *caller* must
 hold, never one Clockula requests. `com.android.alarm.permission.SET_ALARM` is
 what `AlarmClock`'s own documentation asks an implementation to demand; it is
 protection-level `normal`, so any app that declares it is granted it at install,
@@ -1019,8 +1017,8 @@ from an app that never declared an interest in alarms out.
 would mean either dropping the permission or making the app unlaunchable.
 `MainActivity`'s filter set is still exactly `MAIN`/`LAUNCHER`.
 
-The door declares **two** `<intent-filter>` blocks, and this is the detail that
-is silently wrong otherwise: a filter with no `<data>` element matches only
+The door declares **two** `<intent-filter>` blocks, because with one the matching
+is silently wrong: a filter with no `<data>` element matches only
 intents whose data is null, and a filter that declares a scheme matches only
 intents that *have* data. `DISMISS_ALARM` and `DISMISS_TIMER` may arrive either
 way, so filter A carries all seven actions with no data element, and filter B
@@ -1028,19 +1026,19 @@ carries those two plus `<data android:scheme="clockula"/>`.
 `android.intent.category.VOICE` is deliberately **not** declared: it advertises
 the `VoiceInteractor` follow-on flows, which v1 does not implement (§10). The
 activity is `excludeFromRecents`, `noHistory`, `taskAffinity=""` and themed
-`Theme.Clockula.Invisible` (translucent, no title) — it has no content view, so
+`Theme.Clockula.Invisible` (translucent, no title). It has no content view, so
 nothing flashes on the way through.
 
 Components: `MainActivity`, the exported and permission-guarded
 `interop.AlarmClockActivity`, the non-exported `CrashReportActivity` and
 `AlarmRingActivity`, three foreground services (`AlarmRingService`, M6's
-`TimerService`, M7's `StopwatchService`), five non-widget receivers —
-`AlarmFireReceiver`, `AlarmActionReceiver`, `SystemEventReceiver`,
-`TimerExpiryReceiver`, `TimerActionReceiver` — AppCompat's locale metadata
+`TimerService`, M7's `StopwatchService`), five non-widget receivers
+(`AlarmFireReceiver`, `AlarmActionReceiver`, `SystemEventReceiver`,
+`TimerExpiryReceiver`, `TimerActionReceiver`), AppCompat's locale metadata
 holder service, and, since M10, three `GlanceAppWidgetReceiver`s
 (`NextAlarmWidgetReceiver`, `TimerWidgetReceiver`, `ClockWidgetReceiver`).
 `ManifestRulesTest` pins the exported set exactly: the two above, plus the
-three widget receivers — each with **only** the platform-required
+three widget receivers, each with **only** the platform-required
 `APPWIDGET_UPDATE` filter and no permission, since `APPWIDGET_UPDATE` is a
 platform-delivered broadcast no other app can trigger by naming the action.
 M10 adds no `<uses-permission>`.
@@ -1053,7 +1051,7 @@ M10 adds no `<uses-permission>`.
 |---|---|
 | Reordering alarms by hand. The list is ordered by time of day (§13) and `alarms` has no `sort_order` column, so this would be a schema change for a preference the time order already answers | not planned for v1 |
 | A per-alarm auto-silence duration. Every other per-alarm setting became an override picker in M5; this one is still global and still `AlarmRing.AUTO_SILENCE_AFTER` | not planned for v1 |
-| Voice-interaction follow-on flows: `Activity.isVoiceInteraction`, `VoiceInteractor.CompleteVoiceRequest` (publishing a deeplink to the alarm just created) and `PickOptionRequest` (disambiguating by voice). `android.intent.category.VOICE` is therefore not declared — advertising it while answering with a touch dialog would be a promise the app does not keep. Clockula *accepts* a `clockula://` deeplink and publishes none | not planned for v1 |
+| Voice-interaction follow-on flows: `Activity.isVoiceInteraction`, `VoiceInteractor.CompleteVoiceRequest` (publishing a deeplink to the alarm just created) and `PickOptionRequest` (disambiguating by voice). `android.intent.category.VOICE` is therefore not declared: advertising it while answering with a touch dialog would be a promise the app does not keep. Clockula *accepts* a `clockula://` deeplink and publishes none | not planned for v1 |
 | A "most closely matched" time search for `DISMISS_ALARM`. `ALARM_SEARCH_MODE_TIME` matches **exactly**: dismissing an alarm the caller did not name is a missed alarm, and there is no distance at which that becomes a good trade | not planned for v1 |
 | A toast or any other confirmation on a `SKIP_UI` write. `SKIP_UI` means "bypass any intermediate UI", a voice assistant speaks its own confirmation, and the status-bar alarm icon `setAlarmClock` lights is the platform's own receipt (§17) | not planned for v1 |
 | Surfacing `delete_after_use` in either editor. It is a property the contract sets, not a setting; an alarm the user edits keeps it, and that consequence is documented (§17) rather than papered over with a checkbox | not planned for v1 |
@@ -1068,21 +1066,21 @@ M10 adds no `<uses-permission>`.
 | Surfacing `TimerSnapshot.anchorIsStale` in the UI. The boot repair makes it vanishingly rare and the value is already honest; a row does not say "estimated" in v1 | not planned for v1 |
 | Lap export, sharing, deletion or editing, and any "previous run" history. A run's laps belong to the run that produced them; keeping old runs is a different feature with its own table | not planned for v1 |
 | A Lap button on the live pill. The pill has two controls by design, and a third would rewrite a contract M4 asserted | not planned for v1 |
-| A user-configurable lap cap or readout precision. Both are constants with reasons — 999 laps, hundredths — and M10's settings screen is not asked to carry them | not planned for v1 |
+| A user-configurable lap cap or readout precision. Both are constants with reasons (999 laps, hundredths), and M10's settings screen is not asked to carry them | not planned for v1 |
 | Reordering, grouping or filtering laps. The list is index order, newest first, and that is the whole of it | not planned for v1 |
 | A countdown-to-start, split-lap alarms, or any sound or vibration from the stopwatch. It is silent, and a build rule says so (§8) | not planned for v1 |
 | An analog stopwatch face or a `MaterialShapes` showpiece on the Stopwatch tab. `PLAN.md` §8 sanctions the showpiece for the analog world-clock face, the ring screen and timer progress; a stopwatch has no progress to be a fraction of | not planned for v1 |
 | Surfacing `StopwatchReading.anchorIsStale` in the UI, for the same reason the timers' is not: the repair makes it momentary, and the value displayed is already honest | not planned for v1 |
-| A rename UI for `world_clocks.label`. The column is honoured on **read** — a row shows the label when it has one — and M10's backup now carries it on export/import, but there is still no way to *write* a label in-app | not planned for v1 |
+| A rename UI for `world_clocks.label`. The column is honoured on **read** (a row shows the label when it has one), and M10's backup now carries it on export/import, but there is still no way to *write* a label in-app | not planned for v1 |
 | An automatic "home" row while travelling. Google Clock's automatic home clock is a separate feature with its own preference and its own edge cases; M8's answer to "where am I" is the hero face, which already follows the device when no home zone is stored | not planned for v1 |
 | A per-city detail screen, a map, sunrise/sunset times or a day-length bar. `DayNight` is a stated convention for a shape morph, not an ephemeris (§16) | not planned for v1 |
 | Live times or long zone names in the zone picker. 450 rows of ICU long names is real work for a list the user scrolls past, and a ticking picker is a ticking picker | not planned for v1 |
-| Reordering world clocks by anything but `sort_order` — no grouping by continent, no sort-by-offset, no pinning. The list is the order the user put it in | not planned for v1 |
+| Reordering world clocks by anything but `sort_order`: no grouping by continent, no sort-by-offset, no pinning. The list is the order the user put it in | not planned for v1 |
 | `MaterialShapes` on the ring screen or timer progress. `PLAN.md` §8 sanctions both; neither is rebuilt in M8, and the build rule (§8) makes widening the allowlist a deliberate edit | not planned for v1 |
 | Screenshots and store listing polish | M11 |
 
-Also absent by design: any seeded default data — no starter alarm and no home
-world clock on first run, so the empty states are real empty states.
+Also absent by design: any seeded default data. There is no starter alarm and no
+home world clock on first run, so the empty states are real empty states.
 
 Four more deliberate gaps the alarm engine leaves open:
 
@@ -1091,7 +1089,7 @@ Four more deliberate gaps the alarm engine leaves open:
 - **No upcoming-alarm notification.** `getNextAlarmClock()` already draws the
   status-bar icon, which is the platform's answer.
 - **No direct-boot awareness**, so an alarm cannot ring in the window between a
-  reboot and the first unlock — see §9.
+  reboot and the first unlock (see §9).
 - **No bundled fallback ringtone.** The audio chain ends in forced vibration
   (§11), which makes a shipped asset a path a real device cannot reach.
 
@@ -1114,14 +1112,14 @@ callable from a plain JUnit test with hand-built inputs and no fakes at all.
 `AlarmEngine` owns every write the resolver asks for and every call into the
 four seams. It is **never driven by a Flow**: resolution writes state, so an
 engine that rescheduled on each repository emission would re-trigger itself on
-its own writes. `reschedule()` is called explicitly — from `ClockulaApp`, from
+its own writes. `reschedule()` is called explicitly: from `ClockulaApp`, from
 the receivers, and from the alarm editor. `upcoming()` runs the same resolver in
 preview mode and *discards* the state it returns; a read must not write, and a
 test asserts the store recorded nothing across a full collection.
 
 `upcoming(refresh: Flow<Unit>)` takes its **re-read cadence as a parameter**.
 The resolver needs a `now`, and `upcoming` reads one inside a `combine` of the
-two repository flows — so a countdown built on it would freeze until the next
+two repository flows, so a countdown built on it would freeze until the next
 database write. Making the cadence a parameter keeps `PLAN.md` §5's discipline
 (time is a parameter, never an ambient read) without giving the engine a
 `Ticker` and an Android-shaped dependency: the default, `flowOf(Unit)`, means
@@ -1131,8 +1129,8 @@ read-only, and a test collects several refreshes and asserts `alarm_states`
 recorded nothing.
 
 Every entry point is a read-modify-write over `alarm_states`, and they arrive
-from threads that know nothing about each other — a broadcast on
-`Dispatchers.Default`, `ClockulaApp`'s launch-time re-sync, the ring screen — so
+from threads that know nothing about each other (a broadcast on
+`Dispatchers.Default`, `ClockulaApp`'s launch-time re-sync, the ring screen), so
 they are **serialised on one `Mutex`**. Without it, a cold start *caused by* the
 fire broadcast can read the pre-ring state and write it back over `ringingSince`
 or the handled-occurrence watermark, which either silences the alarm or lets it
@@ -1147,7 +1145,7 @@ repair, resume and reschedule one by one, so its whole pass is inside the lock.
 2. **Ringing** within `AUTO_SILENCE_AFTER` ⇒ `RESUMED_RING`, nothing scheduled:
    it is not an alarm to come, it is one that is happening. A clock moved
    *backwards* under a ringing alarm reads as a negative age, which is inside the
-   window — so it keeps ringing. Beyond the window it is auto-dismissed as
+   window, so it keeps ringing. Beyond the window it is auto-dismissed as
    missed and the resolution falls through.
 3. **Snoozed** in the future ⇒ the snooze is the next fire, unless the natural
    occurrence is earlier (defined so the function is total). Due-but-past by less
@@ -1162,11 +1160,11 @@ A cycle opens when the alarm fires and closes on dismiss, on the snooze limit
 being reached, or on auto-silence after `AUTO_SILENCE_AFTER` = **10 minutes**
 (AOSP DeskClock's default; not user-configurable in v1). Snoozing keeps it open.
 
-A **non-repeating alarm is disabled when its cycle closes, never when it opens** —
-disabling it at the start would clear its own snooze and the alarm would vanish
+A **non-repeating alarm is disabled when its cycle closes, never when it opens**.
+Disabling it at the start would clear its own snooze and the alarm would vanish
 mid-snooze. Since M9 there is one branch on top of that: a **transient** alarm
 (`delete_after_use`, set only on the contract's `SKIP_UI` create path) is
-**deleted** rather than disabled, wherever a permanent one would be disabled —
+**deleted** rather than disabled, wherever a permanent one would be disabled.
 `persist`'s `disableAlarm` and `closeCycleLocked` both route through one private
 `disableOrDeleteLocked`. The `alarm_states` foreign key cascades, so the ring
 state goes with the row, and the existing `!isRepeating` guard means an alarm the
@@ -1179,13 +1177,13 @@ the read-only `upcoming`. M9 added the last of the dismissals and the snooze's
 parameter: `dismissUpcoming(id)` is the `AlarmClock` contract's dismissal *and*
 the chooser dialog's, so the user's dismissal and an assistant's are the same
 code. It closes a ring, or arms a repeating alarm's skip, or disables (or
-deletes) a one-shot, and it takes the lock **once** — a caller doing `find` →
+deletes) a one-shot, and it takes the lock **once**. A caller doing `find` →
 `setEnabled` → `reschedule` would race a fire broadcast between the read and the
 write, which is the exact bug the lock exists for. `minutesOverride` is a
 one-off, clamped to 1..60 and written **nowhere**: the contract says setting
 `EXTRA_ALARM_SNOOZE_DURATION` does not change the default snooze duration, and a
 test asserts both the stored row and the preferences file are untouched. It buys
-no extra snooze either — a refused snooze still dismisses.
+no extra snooze either: a refused snooze still dismisses.
 
 Closing a cycle only touches the ring service and the auto-silence registration
 **when that alarm is the one actually ringing**. Both are single, global slots
@@ -1198,7 +1196,7 @@ at once is not a feature, and queueing invents a state machine nobody can debug
 at 07:00. The alarm that is displaced keeps its watermark, so it does not come
 back the moment the slot is re-resolved.
 
-`snoozeLimit == 0` means **snoozing is disabled**, not unlimited — v1 offers no
+`snoozeLimit == 0` means **snoozing is disabled**, not unlimited; v1 offers no
 unlimited, and "0 means infinite" is a trap. A refused snooze *dismisses*; it
 never leaves the user with a ringing alarm they cannot silence.
 
@@ -1212,7 +1210,7 @@ never leaves the user with a ringing alarm they cannot silence.
 They are separate because `getNextAlarmClock()` is what draws the status-bar icon
 and the lockscreen line: a backstop sharing that slot would overwrite the user's
 07:00 with an internal 07:10. Two `PendingIntent`s, two request codes, two
-independent cancels — and a test asserts no two request codes collide, because
+independent cancels. A test asserts no two request codes collide, because
 that collision is exactly how a backstop eats a user's alarm. A **snooze does**
 go through the next-alarm slot: a snoozed alarm *is* the next alarm.
 
@@ -1222,7 +1220,7 @@ not.
 
 **The `showIntent` was wrong until M9.** It is what the system opens when the
 user taps the status-bar alarm icon or the lockscreen's next-alarm line, and it
-pointed at the ring screen with `FLAG_ACTIVITY_CLEAR_TASK` — so tapping "my next
+pointed at the ring screen with `FLAG_ACTIVITY_CLEAR_TASK`, so tapping "my next
 alarm" opened a ring screen for an alarm that was **not ringing**, which resolved
 to `Finished` and closed itself. It now opens `MainActivity` with
 `AlarmIntents.ACTION_SHOW_ALARMS` and `NEW_TASK` only: `MainActivity` is
@@ -1233,14 +1231,14 @@ build if `AndroidAlarmScheduler` ever names `AlarmRingActivity` again (§8).
 ### DST
 
 `AlarmOccurrences` walks *local dates* forward and maps each to an instant with
-one `ZonedDateTime.of(date, time, zone)` call — the only DST-aware call in the
+one `ZonedDateTime.of(date, time, zone)` call, the only DST-aware call in the
 app. Adding 24 hours to yesterday's fire time is the bug this milestone exists
 not to have.
 
 | Transition | java.time's default resolver | What the user sees |
 |---|---|---|
-| **Gap** (spring forward) — the local time does not exist | shifts forward by the gap's own length | a 02:30 alarm on a Berlin spring-forward night rings at **03:30** local. It rings; it is never skipped. A 30-minute gap moves it by 30 minutes, not an hour |
-| **Overlap** (fall back) — the local time happens twice | takes the **earlier** offset | a 02:30 alarm on a fall-back night rings **once**, at the first 02:30. Never late, never twice |
+| **Gap** (spring forward): the local time does not exist | shifts forward by the gap's own length | a 02:30 alarm on a Berlin spring-forward night rings at **03:30** local. It rings; it is never skipped. A 30-minute gap moves it by 30 minutes, not an hour |
+| **Overlap** (fall back): the local time happens twice | takes the **earlier** offset | a 02:30 alarm on a fall-back night rings **once**, at the first 02:30. Never late, never twice |
 
 These are AOSP DeskClock's behaviours, they are the two answers a user would
 defend ("I still got woken", "I only got woken once"), and they come free from
@@ -1253,35 +1251,35 @@ A snooze, by contrast, is an **absolute instant**: no transition can move it.
 
 ### Never to silence
 
-The one non-negotiable, and it is a chain of fallbacks rather than a hope. It
+The one non-negotiable, built as a chain of fallbacks. It
 begins at `AudioSourcePolicy.sourcesFor(ringtoneUri)`, a pure function a JVM
 test can enumerate, and the silent sentinel resolves there to an **empty source
-list** — which is precisely what makes step 4 fire, so "silent" means "vibration
+list**, which is what makes step 4 fire, so "silent" means "vibration
 only" rather than "nothing at all":
 
 1. the alarm's own ringtone URI, else
 2. the device's default alarm URI, else
 3. `RingtoneManager.getDefaultUri(TYPE_ALARM)`, else
-4. **forced vibration** — `RingFallbackPolicy.vibrationRequired` turns vibration
+4. **forced vibration**: `RingFallbackPolicy.vibrationRequired` turns vibration
    on even for an alarm the user set not to vibrate, because with no audio source
    the alternative is silence.
 
 The audio is the foreground service's, played over `USAGE_ALARM` /
 `CONTENT_TYPE_SONIFICATION` so Do Not Disturb's alarm exemption applies, with
-`AUDIOFOCUS_GAIN_TRANSIENT` — an alarm interrupts; it does not duck. The volume
+`AUDIOFOCUS_GAIN_TRANSIENT`: an alarm interrupts, it does not duck. The volume
 ramp is a pure function, `MIN + (1 - MIN) · progress²`, stepped every 200 ms into
 `MediaPlayer.setVolume` and **never** into `AudioManager.setStreamVolume`, which
 would edit the user's own alarm volume and leave it edited.
 
 `RingPresentationPolicy` decides how the ring is *presented*, and its
-`soundsAnyway` is true in all eight capability combinations — asserted
+`soundsAnyway` is true in all eight capability combinations, asserted
 exhaustively, because that is the invariant the app lives on.
 
 **M6 shares this chain with the timer path.** The `MediaPlayer` wrapper, the
 `USAGE_ALARM` attributes, the transient focus request, the prepare-and-release
 loop, the ramp stepper, the looped waveform, `AudioSourcePolicy`,
 `RingFallbackPolicy` and `VolumeRamp` all moved to `ring/` and `domain/ring/`
-and are used verbatim by both — so "silent" still means "vibration only" for a
+and are used verbatim by both, so "silent" still means "vibration only" for a
 timer too. What the alarm **keeps to itself** is the full-screen intent, the
 ring activity, the dismiss challenge and the snooze; what the timer
 parameterises is its own ringtone, a ramp of **zero seconds** (a timer is set by
@@ -1301,7 +1299,7 @@ Four tabs, one host, and one surface that follows whatever is running.
 default `navigationSuiteType`: the M3 Expressive **short navigation bar** on a
 compact width and the **wide rail** on medium and expanded ones. Taking the
 default rather than writing `if (compact) NavigationBar else NavigationRail` is
-the point — the default also answers the tabletop posture and the compact-*height*
+deliberate: the default also answers the tabletop posture and the compact-*height*
 case a hand-rolled branch quietly gets wrong.
 
 **The tabs are pages of one `HorizontalPager` (#2).** Until then each tab was
@@ -1311,36 +1309,36 @@ route, `ShellNavigation.TABS_ROUTE`, and the **pager** is the single source of
 truth for the selected tab: its state is saveable, hoisted above the `NavHost`
 so a tap from an editor can still move it, and the tab survives rotation and
 process death with no mirror of ours to drift. The `NavHost` keeps only what is
-pushed over the tabs — the two editors, the timer setup page, Settings. Each tab
+pushed over the tabs: the two editors, the timer setup page, Settings. Each tab
 is composed only while it is on screen (`beyondViewportPageCount` stays 0), keeps
 its saveable state under its page key while off screen, and its ViewModel in the
 tabs route's store.
 
 Swiping is on only under a navigation **bar**: the bar is a horizontal row of
-the same four tabs, so a sideways swipe maps onto it one to one. Beside a rail —
-tablets, unfolded foldables — the tabs are stacked vertically and a sideways
+the same four tabs, so a sideways swipe maps onto it one to one. Beside a rail
+(tablets, unfolded foldables) the tabs are stacked vertically and a sideways
 swipe has no counterpart the user can see, so there the pager is tap-only. The
 shell computes `NavigationSuiteScaffoldDefaults.navigationSuiteType` itself and
 hands the same value to the scaffold, so the two cannot disagree.
 
 The policy the shell follows is a pure function, `ShellNavigation`:
 
-- a tab tap on the tabs slides the pager there — from the neighbouring page, so
+- a tab tap on the tabs slides the pager there from the neighbouring page, so
   a jump across two tabs does not compose and flash past the ones in between;
 - a tab tap over a nested screen pops back to the tabs first and jumps, and
-  re-selecting the tab under an editor closes the editor — the contract M5's
+  re-selecting the tab under an editor closes the editor, which is the contract M5's
   editor relies on. A nested screen is no longer kept per tab and restored when
   its tab is re-selected: every one writes as the user goes (M5 D22), so popping
   one loses nothing;
 - a tab an intent asks for (a notification, a widget, the exported door) is the
-  same pop and a jump — it always lands on the tab itself, never on whatever
+  same pop and a jump: it always lands on the tab itself, never on whatever
   nested screen was last open there. Widgets build that intent in one place,
   `openAppIntent`, with `CLEAR_TOP` + `SINGLE_TOP` beside `NEW_TASK`, so an
   activity left on top of `MainActivity` in its task (a picker the editor
   opened) is finished and the intent reaches `onNewIntent` rather than the
   task merely being brought forward. The two clock widgets open the tab picked
   per instance in their config screen (`ClockWidgetTapTarget`, stored next to
-  the style; Alarms when unset — #8);
+  the style; Alarms when unset, #8);
 - back from any of the other three tabs returns to **Alarms**; back from Alarms
   and from a null route leaves the app, and a nested screen's back belongs to
   the `NavController`, not to us.
@@ -1348,7 +1346,7 @@ The policy the shell follows is a pure function, `ShellNavigation`:
 Predictive back is the kit's `Modifier.predictiveBack`, gated on exactly that
 policy: on Alarms the handler is *off*, so the gesture falls through to the
 system and previews leaving the app, which is the truthful preview. Nested
-screens use the kit's `fadeThrough()` — they have no spatial relationship to the
+screens use the kit's `fadeThrough()`, because they have no spatial relationship to the
 tabs, and a slide would claim one.
 
 ### The live pill
@@ -1356,9 +1354,9 @@ tabs, and a slide would claim one.
 `PLAN.md` §9 asks for a running-state surface reachable from every tab. Its real
 predicate is **active, not running**: pausing from the pill must not make the
 pill vanish under the thumb that pressed it, or there is no way to resume or
-stop from another tab — which is the flaw the pill exists to fix. So it shows for
-`RUNNING`, `PAUSED` *and* `EXPIRED`, and its own Stop — which is `reset()`,
-never `delete()` — is what removes it.
+stop from another tab, which is the flaw the pill exists to fix. So it shows for
+`RUNNING`, `PAUSED` *and* `EXPIRED`, and its own Stop (which is `reset()`,
+never `delete()`) is what removes it.
 
 Precedence is total; first match wins:
 
@@ -1370,14 +1368,14 @@ Precedence is total; first match wins:
 | 4 | the **stopwatch**, when its state is not `IDLE` |
 | 5 | otherwise no pill |
 
-Ties inside a timer bucket break on `sortOrder` then `id` — the same "lower id
+Ties inside a timer bucket break on `sortOrder` then `id`, the same "lower id
 wins" rule the alarm engine's precedence already uses, so the app has one rule.
 Timers outrank the stopwatch because a timer has a deadline: a missed timer costs
 something, a missed stopwatch tick costs nothing.
 
 **M6 moved rows 1–3 into `TimerReadings` and rewrote `LivePillSelector` to call
-it.** The notification and the ring need the same answer — "which of several
-running timers is this about" — and three copies of one comparator is how three
+it.** The notification and the ring need the same answer ("which of several
+running timers is this about"), and three copies of one comparator is how three
 surfaces start disagreeing. `LivePillSelectorTest` passing **unmodified** is the
 proof the extraction changed no behaviour; `LivePillSelectorPrecedenceTest`
 cross-checks the two callers against each other. The pill keeps its own
@@ -1388,20 +1386,20 @@ from `TimerMode` in one total `when`.
 `TimerRepository.pause/start/reset` directly; after M6 there is an AlarmManager
 registration and a foreground service that have to move with the state, so
 pausing from the pill would otherwise leave the expiry slot pointing at a dead
-deadline and the service posting a stale notification. Self-healing — the next
-sweep would find nothing due — but wasteful and wrong.
+deadline and the service posting a stale notification. That would self-heal,
+since the next sweep would find nothing due, but it is wasteful and wrong.
 
 **M7 did the same for the stopwatch branches**, for the same reason: after M7
 there is a foreground service that has to move with the state, so pausing from
 the pill would otherwise leave the shade showing a running stopwatch, and Stop
 would leave the service up with nothing to show. The pill's own contract is
-unchanged — it shows for RUNNING and PAUSED, never IDLE; Stop is `reset()` and
+unchanged: it shows for RUNNING and PAUSED, never IDLE; Stop is `reset()` and
 never `delete()`; and it gets **no Lap button**, because the pill has two
 controls by design.
 
 The mode and value come from `TimerReadings` / `StopwatchReadings`, both of them
-over the stored row's *snapshot* rather than over the row — so §5's whole elapsed-realtime-versus-wall-clock story,
-stale anchor and all, is honoured once. The consequence that matters: a running
+over the stored row's *snapshot* rather than over the row, so §5's whole elapsed-realtime-versus-wall-clock story,
+stale anchor and all, is honoured once. As a result, a running
 timer that reaches zero flips the pill to `EXPIRED` immediately, without waiting
 for the expiry sweep to write `markExpired`. The pill never counts into
 negative time, and never reads `0:00` while claiming to run.
@@ -1421,8 +1419,8 @@ description instead, read when focused and never announced unprompted.
 `domain/time/`. A readout has to advance without a repository write, and the
 discipline of §5 is that time is a *parameter*: so "re-read the clocks now"
 became an injected flow rather than a `delay` at a call site. It emits once
-immediately and then every period — one second for the pill, since the pill
-formats to whole seconds — so a fresh subscriber is never blank. `RealTicker` is
+immediately and then every period (one second for the pill, since the pill
+formats to whole seconds), so a fresh subscriber is never blank. `RealTicker` is
 nothing but `delay`, which makes it testable under `runTest`'s virtual clock.
 
 ### The dismiss challenge, and why it cannot strand anyone
@@ -1431,19 +1429,19 @@ nothing but `delay`, which makes it testable under `runTest`'s virtual clock.
 "dismissing is permitted now". `PLAN.md` §4's "must never be able to strand the
 user" is made executable rather than promised: the escape hatch becomes
 available on **either** three wrong answers **or** sixty seconds of ringing,
-whichever comes first, for every challenge kind — asserted as a parameterised
+whichever comes first, for every challenge kind, asserted as a parameterised
 invariant over `DismissChallenge`, not as three happy paths.
 
 Three more guarantees hold alongside it. Snooze is never gated: the gate protects
 dismissal only. Auto-silence still ends the ring at ten minutes regardless of the
 gate, because that is the engine's, and the screen only follows the session to
-`Finished`. And a wrong answer carries no lockout and no penalty timer — it
+`Finished`. And a wrong answer carries no lockout and no penalty timer; it
 replaces the problem and that is all.
 
 A completed hold *is* the dismissal, and a correct answer *is* the dismissal: no
 "solve it, then press Dismiss again", because a half-awake person should not have
 to discover a second step. The hold target also carries an accessibility
-`onClick` that completes it outright — TalkBack cannot perform a press-and-hold,
+`onClick` that completes it outright: TalkBack cannot perform a press-and-hold,
 and a challenge a screen reader cannot answer is precisely the stranding the
 requirement forbids.
 
@@ -1469,8 +1467,8 @@ instead, and the same three properties hold through the pager: it keeps Alarms
 selected under the editor, the shell stands aside on a nested route's back, and
 a tab tap over the editor pops it.
 
-There is **no "new alarm" sentinel id**. The FAB creates the alarm — enabled,
-non-repeating, at the next whole hour, every override null — and then navigates
+There is **no "new alarm" sentinel id**. The FAB creates the alarm (enabled,
+non-repeating, at the next whole hour, every override null) and then navigates
 to its id. One route shape, one load path, and no branch in the ViewModel for
 "the thing I am editing does not exist yet".
 
@@ -1478,8 +1476,8 @@ That decision is what settles a wording in `PLAN.md` §6 that would otherwise be
 read too literally. §6 says a malformed `SET_ALARM` intent "opens the editor
 pre-filled **rather than writing anything**". An editor that opens on nothing
 does not exist in this app, and inventing one for M9 would overturn the rule
-above. The sentence's force is **"`SKIP_UI` never means skip validation" — the
-user must see the alarm rather than have one written behind their back** — and
+above. The sentence's force is **"`SKIP_UI` never means skip validation": the
+user must see the alarm rather than have one written behind their back**, and
 that is honoured exactly: an incomplete or malformed `SET_ALARM` creates the row
 from the extras that *were* valid, at `AlarmDefaults.nextWholeHour`, enabled,
 never transient, and lands the user in its editor with a time picker, a day
@@ -1491,15 +1489,15 @@ which is what §6 forbids (§17).
 The `AlarmClock` contract says a `DISMISS_ALARM` search returning two or more
 matches should show the results and let the user pick. M3's canonical component
 for "pick one of a short list, or cancel" is a **basic dialog containing a
-list**: `AlertDialog` at its defaults — `surfaceContainerHigh`, the 28dp corner,
-`headlineSmall` title, tonal elevation 3 — not a full-screen dialog (that is for
+list**: `AlertDialog` at its defaults (`surfaceContainerHigh`, the 28dp corner,
+`headlineSmall` title, tonal elevation 3), not a full-screen dialog (that is for
 a whole task) and not a bottom sheet (this is a question, not a surface).
 
 Rows are canonical M3 `ListItem`s in a `Column` with `verticalScroll`, each
-carrying the same three facts the Alarms row shows — the formatted time through
+carrying the same three facts the Alarms row shows: the formatted time through
 `rememberAlarmTimeFormatter` (the app's one formatter), the label as supporting
-content and the repeat summary as the overline — so the dialog and the list
-behind it agree. Each row sets
+content and the repeat summary as the overline. The dialog and the list
+behind it therefore agree. Each row sets
 `ListItemDefaults.colors(containerColor = Color.Transparent)`, because a
 `ListItem`'s default container is `surface`, which sits *lower* than the
 dialog's own `surfaceContainerHigh` and would draw a visible lighter block per
@@ -1510,8 +1508,8 @@ naming the time, the label and what tapping does, and the 48dp target comes free
 with `ListItem`.
 
 `DismissChooser.rowsFor(rows, ids)` is pure and filters `AlarmsViewModel`'s
-existing `AlarmRowState` list, in **its** order — so there is no second source
-and no second ticker — and the answer goes to
+existing `AlarmRowState` list, in **its** order (so there is no second source
+and no second ticker), and the answer goes to
 `AlarmsViewModel.onDismissUpcoming(id)`, which is `AlarmEngine.dismissUpcoming`
 (§11).
 
@@ -1520,7 +1518,7 @@ and no second ticker — and the answer goes to
 A canonical two-line M3 `ListItem` through the kit's `GroupedRow`: the formatted
 time with the label beside it in `onSurfaceVariant`, a summary of
 `repeat · next fire · skipping next`, and a `Switch`. A **disabled** alarm is
-`dimmed` — the kit's own answer for "present but switched off", which fades the
+`dimmed`, the kit's own answer for "present but switched off", which fades the
 text to the M3 disabled emphasis and leaves the switch at full opacity. The
 **next** alarm is marked with `colorScheme.primary` on its next-fire clause and
 nothing else: `PLAN.md` §8's "Expressive ≠ big or bold", so the emphasis is a
@@ -1537,7 +1535,7 @@ bottom-centre and the FAB bottom-end.
 `AlarmEngine.upcoming()` sorts by next fire, because its job is "which alarm is
 earliest to register". That is the wrong order for a list: an 07:00 and a 22:00
 alarm would **swap places at 07:00**, reordering rows under a thumb. So
-`AlarmListRows.from` re-sorts by `time.minutesOfDay` then id — which is also
+`AlarmListRows.from` re-sorts by `time.minutesOfDay` then id, which is also
 exactly what `AlarmDao.observeAll` emits, so the screen's order re-asserts the
 storage order rather than inventing one. A disabled alarm keeps its place: it is
 already dimmed, and sinking it would say the same thing twice while moving a row
@@ -1545,8 +1543,8 @@ the user did not move.
 
 ### The next-fire line
 
-`NextFireFormat.labelFor(nextFire, now)` returns data, not a string —
-`NotScheduled`, `Imminent`, `InMinutes`, `InHoursMinutes`, `InDaysHours` — and
+`NextFireFormat.labelFor(nextFire, now)` returns data, not a string
+(`NotScheduled`, `Imminent`, `InMinutes`, `InHoursMinutes`, `InDaysHours`), and
 the wording lives in `strings.xml`, following `RingUiState`'s precedent. Whole
 units round **up**, the direction `ClockFormat.countdown` already rounds: "in 9h
 12m" must mean *at least* nine hours and eleven-and-a-bit minutes, and an alarm
@@ -1556,20 +1554,20 @@ exists because a weekly alarm can be six days out.
 The cadence is 30 seconds (`AlarmsDefaults.NextFireTick`): the readout's unit is
 a minute, so half a unit bounds the displayed error, and the one-second cadence
 the live pill needs would re-resolve every alarm sixty times for a readout that
-can change once. "Ringing now" does not wait for a tick — it arrives as an
+can change once. "Ringing now" does not wait for a tick: it arrives as an
 `alarm_states` write, which re-emits at once.
 
 ### Every override is a picker, and its first option is "App default"
 
 A per-alarm setting is a nullable override (§4), so the stored value is
 **ternary**: absent, or a choice that happens to be `false` or `0`. A `Switch`
-cannot say "I have not chosen" — toggling one would silently turn "follows your
+cannot say "I have not chosen": toggling one would silently turn "follows your
 default" into "explicitly on", with no way back. So all five overrides (vibrate,
 gradual volume, snooze length, snooze limit, dismiss challenge) use the kit's
 `OptionPicker`, whose first row is "App default (On)" and names what the default
 currently is. Every option offered is inside `ClockPrefs`' clamps, so nothing
 chosen can be clamped away on the next read, and `snoozeLimit == 0` is labelled
-"No snoozing", never "unlimited" — §11's "0 means infinite is a trap".
+"No snoozing", never "unlimited" (§11's "0 means infinite is a trap").
 
 Each row's summary shows the effective value, prefixed while inherited, so the
 inheritance is visible without opening anything. There is no tri-state hack and
@@ -1581,14 +1579,14 @@ Bespoke over `FullScreenPicker(scrollable = false)` rather than `OptionPicker`,
 because a device's tone list can be hundreds of rows. `RingtonePicker.optionsFor`
 is pure and yields four kinds of row, de-duplicated by URI:
 
-1. **App default** — summarised with what it currently resolves to, or "Device
+1. **App default**, summarised with what it currently resolves to, or "Device
    default alarm sound" when the app default is itself null;
-2. **Silent** — `Ringtones.SILENT_URI`, `clockula://silent`. `null` already
+2. **Silent**: `Ringtones.SILENT_URI`, `clockula://silent`. `null` already
    means *inherit*, so silence needs a value of its own, and a private scheme is
    one no ContentProvider URI can collide with. It resolves to an empty audio
-   source list, which forces vibration (§11) — the label is "Silent" with the
+   source list, which forces vibration (§11); the label is "Silent" with the
    summary "Vibration only", so it is not a lie;
-3. **the alarm's own sound when the device does not list it** — a SAF-picked
+3. **the alarm's own sound when the device does not list it**: a SAF-picked
    file, or a URI another app wrote. Without this row the user's own selection
    would be invisible, and so uncheckable, in the picker that chose it;
 4. the device's alarm tones, title-sorted.
@@ -1598,7 +1596,7 @@ a list of selectable states. A picked document's read grant is made persistent
 through `RingtoneCatalog.persistPickedDocument`; if that fails the URI is
 **still stored** (the fallback chain protects the ring) and the row discloses
 "Clockula may lose access to this file later". A stored sound the catalog cannot
-open right now is likewise **reported, never rewritten** — "unreadable now" and
+open right now is likewise **reported, never rewritten**: "unreadable now" and
 "gone forever" are indistinguishable, an unmounted card comes back, and
 discarding the user's choice silently would be the worse failure.
 
@@ -1679,7 +1677,7 @@ URI.
 or deleted.**
 
 `AlarmResolver`'s disabled branch clears `ringingSince` and the engine persists
-that — but nothing in that path stops the ring service. The service and the
+that, but nothing in that path stops the ring service. The service and the
 auto-silence backstop are single *global* slots (§11), touched only by
 `closeCycleLocked`, and `onAutoSilence` returns early once `ringingSince` is
 null. So switching off or deleting a ringing alarm from this screen would clear
@@ -1700,8 +1698,8 @@ merely *snoozed* alarm's pending snooze, which is wrong for a label edit.
 There is no Save button, no dirty state and no discard dialog: `PLAN.md` §11
 names Google Clock as the interaction reference, and this is its model. The
 editor edits a persisted row and every control writes at once. The label is
-written on every keystroke through one conflating `MutableStateFlow` — which
-writes the first value and the latest, in order, never interleaved — and
+written on every keystroke through one conflating `MutableStateFlow` (which
+writes the first value and the latest, in order, never interleaved), and
 `onCleared()` re-launches the last value on the kit's `@ApplicationScope`, so
 leaving the editor mid-word cannot lose the word. `reschedule()` is called only
 after a change that can move a fire time (create, delete, enabled, time, repeat
@@ -1709,7 +1707,7 @@ days, skip-next), so fiddling with sound settings costs no AlarmManager traffic;
 a snooze *length* cannot move a pending snooze, which is stored as an absolute
 instant.
 
-Skip-next-occurrence, built in M3 with no caller, is the editor's — and only for
+Skip-next-occurrence, built in M3 with no caller, is the editor's, and only for
 a **repeating** alarm. The resolver answers a one-shot-with-skip by disabling the
 alarm, and a switch labelled "skip" that silently switched the alarm off would
 be a lie; the user who wants that has the enable switch.
@@ -1717,7 +1715,7 @@ be a lie; the user who wants that has the enable switch.
 Delete lives in the editor behind a confirmation that names the alarm, and there
 is deliberately no undo chip: the delete happens on the editor, so an undo chip
 would have to live on the list, and an accidentally deleted alarm is discovered
-at 07:00 rather than now — the cheap moment to ask is before.
+at 07:00 rather than now; the cheap moment to ask is before.
 
 ---
 
@@ -1731,7 +1729,7 @@ share is one read-only question (below).
 
 `TimerEngine` is the timers' analogue of §11's engine: plain Kotlin, no
 `android.*` import ever, reaching the platform through three seams it does not
-implement — `TimerScheduler` (one AlarmManager slot), `TimerServiceHandle` (the
+implement: `TimerScheduler` (one AlarmManager slot), `TimerServiceHandle` (the
 foreground service) and `AlarmRingStatus` (read-only: "is an alarm ringing").
 It owns every write the pure policies ask for, and every public entry point is
 serialised on one non-reentrant `Mutex`, because they arrive from threads that
@@ -1742,9 +1740,9 @@ It is **not** driven by a Flow, for the same reason the alarm engine is not:
 resolution writes state, so an engine that resynced on every repository emission
 would re-trigger itself on its own writes. `resync()` is called explicitly.
 
-The engine owns the **lifecycle** verbs — `start`, `pause`, `reset`, `addTime`,
+The engine owns the **lifecycle** verbs (`start`, `pause`, `reset`, `addTime`,
 `delete`, M9's `dismissAllExpired`/`dismissExpired`, plus
-`onExpiryDue`/`resync`/`onBootCompleted` — because each of them
+`onExpiryDue`/`resync`/`onBootCompleted`) because each of them
 can move the slot, the service or the ring session, and every one of them is
 reachable from a notification button with no ViewModel in sight. `delete` is on
 the engine and not on a ViewModel-plus-`resync` path deliberately: deleting a
@@ -1769,31 +1767,31 @@ each is a test:
 - a fire delivered **late** still expires everything that came due while it was
   delayed;
 - a fire delivered **early**, or for a timer the user has since stopped, finds
-  nothing due and writes nothing — so the trigger needs no grace window and no
+  nothing due and writes nothing, so the trigger needs no grace window and no
   watermark of its own: the anchors *are* the watermark;
-- two timers expiring in the same second are **one pass**, not a race.
+- two timers expiring in the same second are handled in one pass, with no race.
 
 The base is **`ELAPSED_REALTIME_WAKEUP`**, mirroring the clock the domain
 anchors on: **alarms are `RTC_WAKEUP`, timers are `ELAPSED_REALTIME_WAKEUP`.**
-That is not tidiness, it is the requirement — a wall-clock registration moves
-when the user changes the system time, so a `TIME_SET` would warp a running
-timer's expiry, which §5 forbids. With this base a `TIME_SET` needs no
+The match is required: a wall-clock registration moves when the user changes
+the system time, so a `TIME_SET` would warp a running timer's expiry, which §5
+forbids. With this base a `TIME_SET` needs no
 re-registration at all, and a test asserts the slot's value and every stored row
 are unchanged across a three-hour clock jump in each direction.
 
 `setExactAndAllowWhileIdle` is tried first and `setAndAllowWhileIdle` is the
 fallback. It does **not** go through `SchedulingPolicy`, whose
-`EXACT_ALARM_CLOCK` branch names `setAlarmClock` — and **a timer must never
+`EXACT_ALARM_CLOCK` branch names `setAlarmClock`, and **a timer must never
 populate `getNextAlarmClock()`**, because that slot draws the status-bar alarm
-icon and the lockscreen line and belongs to the user's next *alarm*. Late is
-survivable; silent is not, so there is no third branch.
+icon and the lockscreen line and belongs to the user's next *alarm*. A late
+timer is survivable and a silent one is not, so there is no third branch.
 
 *Known limitation, recorded rather than glossed:* `*AllowWhileIdle` alarms are
 rate-limited per app while the device is idle. Clockula holds `USE_EXACT_ALARM`,
 which exempts it, but a device that refuses the grant could deliver a
 back-to-back sequence of short timers late. The idempotent sweep is one
 mitigation; the second is that **the service, while alive, `delay`s to the same
-deadline and calls the same `onExpiryDue()`**. Neither trigger has to be
+deadline and calls the same `onExpiryDue()`**, so neither trigger has to be
 reliable alone.
 
 Both `delay` amounts come **from the engine** (`TimerServiceState.expiresIn` and
@@ -1804,14 +1802,14 @@ rounding error cannot spin the loop.
 ### One foreground service, alive exactly while something is active
 
 `TimerService` is a single `systemExempted` foreground service covering both
-phases — the countdown and the ring. Its lifetime predicate is the live pill's:
-**active, not running.** It is up while any timer is `RUNNING`, `PAUSED` or
+phases, the countdown and the ring. Its lifetime predicate is the live pill's
+"active" (which is wider than "running"): it is up while any timer is `RUNNING`, `PAUSED` or
 `EXPIRED` and down when every timer is `IDLE` or gone. `PAUSED` is in the
 predicate for §12's reason: dropping the notification on pause would leave a
 user who paused from the shade with no way to resume without opening the app.
-One "active" predicate in the whole app.
+The whole app has one "active" predicate.
 
-One service and not two, because a timer expiring while another runs must not
+There is one service because a timer expiring while another runs must not
 need a second one, and because the ring phase needs nothing the countdown phase
 does not already have.
 
@@ -1820,8 +1818,8 @@ awake is a battery bug; the AlarmManager slot is what wakes the device. The
 *ring* holds one, with a fifteen-minute timeout, exactly as `AlarmRingService`
 does.
 
-The service is a **readout and a control surface, never the timekeeper** — the
-stored anchors and the AlarmManager slot are, and both survive its absence. So
+The service is a readout and a control surface. The stored anchors and the
+AlarmManager slot keep the time, and both survive the service's absence. So
 `TimerServiceHandle.sync` wraps both the start and the stop in `runCatching`,
 and the service holds no policy and no state of its own beyond one
 `alreadyAlerted` flag. Its trigger flow is
@@ -1831,10 +1829,10 @@ collector that caused it.
 
 ### The audio arbitration: an alarm wins, and the timer's ring is deferred, not lost
 
-Two `USAGE_ALARM` streams at once is not a feature, and §11's ring service and
-auto-silence backstop are single global slots. So a timer that expires while an
-alarm is ringing **is still marked `EXPIRED`** — its data is truthful and the
-user must learn the pasta is done — and its notification says so, but it **does
+Clockula never plays two `USAGE_ALARM` streams at once, and §11's ring service
+and auto-silence backstop are single global slots. So a timer that expires while
+an alarm is ringing **is still marked `EXPIRED`** (its data is truthful and the
+user must learn the pasta is done) and its notification says so, but it **does
 not open audio**. When the alarm's cycle closes, the timer starts sounding, and
 *nothing re-arms it*: the decision is a pure function of current state rather
 than an event.
@@ -1846,7 +1844,7 @@ TimerRingPolicy.decide(expired, defaults, alarmIsRinging, soundingSince, now)
 `alarmIsRinging` arrives through one read-only seam, `AlarmRingStatus`, backed
 by `AlarmStateRepository.states()`. The timer engine therefore never reaches
 into `alarm_states` itself, never calls `AlarmEngine`, and never touches the
-alarm's ring slot or its auto-silence registration — asserted. A test hands the
+alarm's ring slot or its auto-silence registration; tests assert all of this. A test hands the
 engine a boolean instead of building alarm state.
 
 The reverse case is free and symmetric: an alarm firing over a sounding timer
@@ -1863,25 +1861,25 @@ sound.
   another expired timer remains, the ring continues for the next subject. Each
   timer is a separate thing the user set, and silently resetting all of them
   because one was acknowledged destroys the information "which ones finished".
-  Two timers cost two taps, which is correct — there is still no "stop all"
-  **in the UI**, and M9 added no button. What M9 did add is
+  Two timers cost two taps, which is correct: there is still no "stop all"
+  **in the UI**, and M9 added no button. M9 did add
   `TimerEngine.dismissAllExpired()`, reachable only from
   `ACTION_DISMISS_TIMER` with no data URI: the rule above is about a *thumb* on
   a *ring*, where silently resetting both destroys the information "which one
   finished", while an app saying "dismiss all expired timers" has stated exactly
   which information it is discarding. Its sibling `dismissExpired(id)` answers a
   `clockula://timer/{id}` deeplink and resets the timer **only if it reads
-  EXPIRED**, a silent `false` otherwise — dismissing a running countdown because
-  a caller referenced it would destroy a measurement. Both route through the
+  EXPIRED** and returns a silent `false` otherwise, since dismissing a running
+  countdown because a caller referenced it would destroy a measurement. Both route through the
   same private reset, so both honour `delete_after_use` (§17), and both take the
   engine's lock so the expiry slot, the service and the ring session move with
   the state.
 - **A session is one window.** It opens when the audio *actually starts
   sounding* and closes when the expired set returns to empty. A second timer
   expiring mid-session inherits the session's remaining window rather than
-  buying a fresh ten minutes — the conservative direction, and the same rule as
+  buying a fresh ten minutes. That is the conservative direction, and the same rule as
   §11's "a reboot does not buy the alarm another ten minutes". The anchor is the
-  instant the audio *opened*, not the instant of expiry, so a long alarm ring in
+  instant the audio *opened* rather than the instant of expiry, so a long alarm ring in
   front of it does not eat the timer's whole window.
 - **A lapsed window does not silence the next timer.** A window that has run out
   belongs to the timers the user chose to leave `EXPIRED`; a timer reaching zero
@@ -1891,9 +1889,9 @@ sound.
   opens a fresh window with its own heads-up. Inheriting stays the rule for a
   timer expiring *inside* a live window.
 
-`TimerRing.AUTO_SILENCE_AFTER` is **ten minutes** — its own constant with the
+`TimerRing.AUTO_SILENCE_AFTER` is **ten minutes**: its own constant with the
 same value as the alarm's, free to diverge, because coupling the two would make
-one number answer two questions. The load-bearing difference from an alarm:
+one number answer two questions. Unlike an alarm's, a timer's
 **auto-silence stops the noise and leaves the row `EXPIRED`.** An auto-silenced
 alarm is a *missed* alarm and its cycle closes; an auto-silenced timer has still
 finished, and the user coming back must be able to see that and add a minute
@@ -1902,9 +1900,9 @@ a window that has run out cannot hand it a fresh one.
 
 `TimerRing.RAMP_SECONDS` is **0**. The volume ramp exists so an alarm does not
 jolt a sleeping person awake; a timer is set by someone awake who wants to know
-*now*, and a gentle start is just a quiet start. `VolumeRamp.levelAt(_, 0s)`
-already returns `1f`, so "parameterised" means literally one different argument
-to the same player.
+*now*, and for them a gentle start is a quiet start. `VolumeRamp.levelAt(_, 0s)`
+already returns `1f`, so "parameterised" means one different argument to the
+same player.
 
 ### The notification: one channel, one id, alert once
 
@@ -1917,10 +1915,10 @@ The subject is §12's; the rest are a count.
 | `EXPIRED` | the label | "Finished" | Stop · +1 min |
 
 plus "+2 more timers" when other active timers exist. Two actions at most, and
-they are the *same pair* the row offers for that mode — one vocabulary, two
-surfaces. What this gives up knowingly: per-timer controls in the shade for the
-timers that are not the subject. Those are one tap away in the app, and the
-alternative — a notification group with one entry per timer — multiplies ids,
+they are the *same pair* the row offers for that mode, so the shade and the row
+share one vocabulary. This knowingly gives up per-timer controls in the shade for
+the timers that are not the subject. Those are one tap away in the app, and the
+alternative (a notification group with one entry per timer) multiplies ids,
 request codes and orphan-on-kill cases for a rare case.
 
 `setUsesChronometer(true)` + `setChronometerCountDown(true)` + `setWhen(base)`
@@ -1928,22 +1926,22 @@ means the **system** renders the ticking, so the service posts once per state
 change instead of once per second for forty-five minutes. The base is
 `timers.ends_at_wall_clock_millis`, which makes it the single wall-clock value
 in the whole timer path, with one honest consequence: a user changing the system
-clock while a timer runs leaves that stored base — and so the notification's
-readout — pointing at the wrong instant, while the timer itself does not move at
+clock while a timer runs leaves that stored base (and so the notification's
+readout) pointing at the wrong instant, while the timer itself does not move at
 all. So `SystemEventReceiver`'s `TIME_SET`/`TIMEZONE_CHANGED` branch calls
-`timerEngine.onSystemTimeOrZoneChanged()` — **not to reschedule anything**, but
-to re-anchor `ends_at_wall_clock_millis` from the monotonic anchor (§5) and
-re-post with a base that is true again. A running row with no wall-clock end (a
+`timerEngine.onSystemTimeOrZoneChanged()`. It reschedules nothing; it only
+re-anchors `ends_at_wall_clock_millis` from the monotonic anchor (§5) and
+re-posts with a base that is true again. A running row with no wall-clock end (a
 corrupt row) falls back to a static readout rather than a chronometer counting
 to a wrong instant.
 
-One channel (`timers`, `IMPORTANCE_HIGH`, sound and vibration off — the service
-owns both), one id, and **only the first post of a ring session may alert**. So a
+One channel (`timers`, `IMPORTANCE_HIGH`, sound and vibration off because the
+service owns both), one id, and **only the first post of a ring session may alert**. So a
 countdown update never heads-ups and never buzzes, an expiry heads-ups exactly
 once, and there is no channel gymnastics and no second notification. Every
 non-alerting post carries `setSilent(true)` as well as `setOnlyAlertOnce(true)`,
 because `setOnlyAlertOnce` speaks only about *updates* to a notification already
-on screen — on a high-importance channel the first post of a countdown, and the
+on screen. On a high-importance channel the first post of a countdown, and the
 placeholder the service goes foreground with, would otherwise pop a banner. The
 rule is a pure function (`TimerNotificationState.alertOnce`); the service owns
 the flag that spends it and scopes it to the session's window, so it resets both
@@ -1954,7 +1952,7 @@ the shape `AlarmActionReceiver` already has: `goAsync()`, `@ApplicationScope`,
 one call into the engine, `finish()`. Deliberately **not**
 `PendingIntent.getService` (a background foreground-service start can be
 refused; a broadcast cannot) and not an activity (a control should not have to
-open the app). Nothing is carried across but the timer id, which can be stale —
+open the app). Nothing is carried across but the timer id, which can be stale,
 so **every engine verb is guarded by the state it makes sense for**, a mismatch
 is a silent no-op, and the notification is re-posted from the truth afterwards.
 Request codes use the `base * 100_000 + (id % 100_000)` stride
@@ -1966,17 +1964,17 @@ Tapping the notification opens the **Timers tab**, through the smallest honest
 deep link: the content intent carries `TimerIntents.ACTION_SHOW_TIMERS`,
 `MainActivity` reads it in `onCreate` **and** `onNewIntent` into one
 `mutableStateOf`, and `ClockulaShell` consumes it once by replaying
-`ShellNavigation.onTabSelected` — the same command a tab tap produces.
+`ShellNavigation.onTabSelected`, the same command a tab tap produces.
 `startDestination` stays **Alarms**: it is the `popUpTo` anchor and the root of
 M4's asserted back policy, so changing it for a notification tap would rewrite
 that policy. (Since #2 the shell replays `ShellNavigation.onTabRequested`
 instead: a tap's pop, but a jump rather than a slide, onto the pager whose start
-page is still Alarms — §12.)
+page is still Alarms; see §12.)
 
 M9 finished that surface and widened it by one step. `tabForAction` gained
 exactly **one** action, `AlarmIntents.ACTION_SHOW_ALARMS`: the platform's own
-`AlarmClock` strings never reach `MainActivity` — the exported door translates
-them into internal ones — so mapping them here would be dead code that looks
+`AlarmClock` strings never reach `MainActivity` (the exported door translates
+them into internal ones), so mapping them here would be dead code that looks
 like a contract. And because three of the contract's outcomes are not "select a
 tab", the shell's intent parameter grew from `openTab: ClockulaDestination?` to
 `openRequest: ShellRequest?`, built by the pure
@@ -1984,20 +1982,20 @@ tab", the shell's intent parameter grew from `openTab: ClockulaDestination?` to
 
 | `ShellRequest` | What the shell does |
 |---|---|
-| `OpenTab(destination)` | the tab command a tab tap produces — unchanged |
-| `OpenAlarmEditor(id)` | the Alarms tab command, then `navigate(AlarmRoutes.editor(id))` — the same two steps the FAB takes, so the back stack is the one M5 asserted |
+| `OpenTab(destination)` | the tab command a tab tap produces, unchanged |
+| `OpenAlarmEditor(id)` | the Alarms tab command, then `navigate(AlarmRoutes.editor(id))`: the same two steps the FAB takes, so the back stack is the one M5 asserted |
 | `ComposeTimer` | the Timers tab command, then the setup panel: the `ModalBottomSheet` over a non-empty list, and nothing extra over an empty one, where the panel is already the empty state |
 | `ChooseAlarmToDismiss(ids)` | the Alarms tab command, then the chooser dialog (§13) |
 
 The launching intent is read **once**: `onCreate` derives a request only when
 `savedInstanceState` is null. `setIntent` keeps the intent, so re-deriving it
-on every configuration change would replay *stateful* navigation — a rotation
+on every configuration change would replay *stateful* navigation: a rotation
 would force the user back into the editor, re-open the timer setup sheet, or
 re-ask the dismiss question they had just answered. A genuinely new intent
 arrives through `onNewIntent` instead. Every extra is read inside a
 `runCatching`, for the same reason `IntentExtrasReader` does: `MainActivity` is
 exported, reading any extra unparcels the whole `Bundle`, and a Parcelable whose
-class is not in our classloader would otherwise throw inside `onCreate` — a
+class is not in our classloader would otherwise throw inside `onCreate`, a
 launch crash that also feeds `CrashReporter.isCrashLoop`. The action itself
 never unparcels, so an intent we cannot unpack still selects its tab.
 
@@ -2006,8 +2004,8 @@ or an empty id list, falls back to `OpenTab(ALARMS)`, because an intent that
 reaches `MainActivity` malformed must still put the user somewhere sensible. An
 unknown action is `null` and is never rescued by its extras. The chooser's
 candidate ids live in `ClockulaShell` as a `rememberSaveable { LongArray }`, so
-a rotation mid-question does not lose it; a process death does, which is
-correct — the intent that asked has been consumed.
+a rotation mid-question does not lose it. A process death does, which is
+correct, because the intent that asked has been consumed.
 
 ### Process death and reboot
 
@@ -2018,7 +2016,7 @@ correct — the intent that asked has been consumed.
   If the service itself was killed, the expiry broadcast starts it again.
 - **Reboot** is §5's `RebootRepair`, and M6 gave it a caller that *rings*:
   `TimerEngine.onBootCompleted()` calls `repairIfRebooted()` inside its own
-  lock, then sweeps — so a timer whose end passed during the reboot is expired
+  lock, then sweeps, so a timer whose end passed during the reboot is expired
   by the repair and **sounds when the device comes back**. The boot-id gate
   makes the second call of a boot a no-op, so neither engine depends on the
   other's ordering.
@@ -2026,7 +2024,7 @@ correct — the intent that asked has been consumed.
 
 ### The tab
 
-A `LazyColumn` in storage order — `sortOrder`, then `id`, which is exactly what
+A `LazyColumn` in storage order (`sortOrder`, then `id`), which is exactly what
 the repository emits, so the screen re-asserts the order rather than inventing
 one. **An expired timer does not jump to the top**: a row that moves under a
 thumb is worse than a row the user has to look for, which is the answer M5 gave
@@ -2034,10 +2032,10 @@ for alarms. The pill and the notification pick a subject; the list does not
 reorder for it.
 
 Setting a timer is a keypad, a row of preset chips, the readout and one
-**Start** — and the same panel is hosted in a `ModalBottomSheet` over a
+**Start**. The same panel is hosted in a `ModalBottomSheet` over a
 non-empty list and *inline* on an empty one, where it **is** the empty state, so
-there is no "no timers yet" card to look at and then dismiss. Deliberately not
-M5's create-then-navigate: an alarm is live the moment it exists, so creating it
+there is no "no timers yet" card to look at and then dismiss. This deliberately
+departs from M5's create-then-navigate: an alarm is live the moment it exists, so creating it
 first is honest, while a timer has a natural commit point and a row created by
 an accidental FAB tap would be litter. There is still no sentinel id, because
 the panel is not bound to a row at all.
@@ -2047,14 +2045,14 @@ The typed digits and the sheet's open flag live in the **composable** as
 death; the pure `TimerDurationEntry` is derived from the saved digit string, and
 `Start` is guarded by a ViewModel re-entrancy flag. `TimerDurationEntry` shifts
 digits in from the right and reads them as `h*3600 + m*60 + s` **without
-clamping minutes or seconds to 59**, so `0:00:99` is 99 seconds — Google Clock's
-forgiving behaviour, and a pure function with obvious tests. `canStart` is false
+clamping minutes or seconds to 59**, so `0:00:99` is 99 seconds. That matches
+Google Clock's forgiving behaviour, and it is a pure function with obvious tests. `canStart` is false
 outside 1 s…24 h.
 
 Presets are **app-wide** quick-start durations in DataStore (§6), not a property
 of one row: a `timers` row already *is* its own preset, because it persists and
 `reset` returns it to its configured duration. The whole management surface is
-two gestures on the setup panel — a Save chip when the typed duration is not
+two gestures on the setup panel: a Save chip when the typed duration is not
 already one, and each chip's own remove affordance. The keypad starts empty;
 there is no default timer length. (M2 built a `default_timer_duration_millis`
 preference and M10 gave it a settings row, but nothing that creates a timer
@@ -2069,13 +2067,13 @@ as an explicit sentinel that forces vibration, a SAF-picked file that is still
 stored when its grant cannot be made persistent, and an unreadable sound
 **reported, never rewritten**.
 
-The expressive parts are `LinearWavyProgressIndicator` across each card — whose
+The expressive parts are `LinearWavyProgressIndicator` across each card (its
 **amplitude is the state**: the default wave while running, flat while paused or
-finished — a kit `GroupedSurface` per card with `positionOf(index, count)`, a
+finished), a kit `GroupedSurface` per card with `positionOf(index, count)`, a
 `ButtonGroup` of `FilledTonalButton`s with the press-widening `animateWidth`,
 and `tertiaryContainer` for an expired card, which is *exactly* the token the
 live pill already uses for an expired timer, so the two surfaces agree. The
-readout is `headlineLarge` and the setup panel's entry is `displayMedium` —
+readout is `headlineLarge` and the setup panel's entry is `displayMedium`,
 plain scale roles, because `ui/theme/Type.kt` says the big-readout ramp gets
 settled against a working stopwatch in M7, not guessed at in the scaffolding.
 
@@ -2091,15 +2089,15 @@ Read this before changing anything stopwatch-shaped.
 **no `android.*` import ever** (a build rule), reaching the platform through
 **one** seam it does not implement, `StopwatchServiceHandle`. Every public entry
 point is serialised on one non-reentrant `Mutex`, because they arrive from
-threads that know nothing about each other — a notification-button broadcast,
+threads that know nothing about each other: a notification-button broadcast,
 the service's own collector, the tab's ViewModel, the shell's pill,
 `ClockulaApp`'s launch pass.
 
 It is deliberately much smaller than `TimerEngine`, because the stopwatch has
 less to own: **no AlarmManager registration at all** (nothing has a deadline),
 **no ring** (nothing expires), **no arbitration** (it makes no sound), and one
-record rather than N rows. What it does have is four verbs — `start`, `pause`,
-`lap`, `reset` — reachable from the shade with no ViewModel in sight, which is
+record rather than N rows. It does have four verbs (`start`, `pause`,
+`lap`, `reset`) reachable from the shade with no ViewModel in sight, which is
 why they live on the engine and not on a screen. `StopwatchRepository` stays the
 storage face and gained exactly one method, `lapCount()`; nothing above the
 engine calls its lifecycle verbs any more, including `ShellViewModel` (§12).
@@ -2109,19 +2107,19 @@ Like the other two it is not driven by a Flow: `resync()` is called explicitly.
 ### The service type, and why not `systemExempted`
 
 `specialUse`, with a `stopwatch` subtype, and one new permission. The reasoning
-is in §9 and is the decision in this milestone worth looking at hardest: the
+is in §9. Of this milestone's decisions, it deserves the hardest look: the
 easy answer would have the app tell the platform it is continuing alarm
 functionality, which it is not.
 
 The service is up while the run is `RUNNING` **or** `PAUSED`, and down when it
-is `IDLE` — exactly the live pill's predicate and exactly
+is `IDLE`. That is exactly the live pill's predicate and exactly
 `StopwatchReadings.isActive`, so the shade, the pill and the tab cannot disagree
 about whether there is a stopwatch. `PAUSED` is in it so a user who paused from
 the shade still has a Resume there.
 
 One consequence, accepted: after a reboot the repair leaves a running stopwatch
 paused, so the service comes back up with a paused notification nobody asked
-for. It is truthful — the stopwatch *is* paused and its laps are intact — and
+for. It is truthful (the stopwatch *is* paused and its laps are intact), and
 its own Reset clears it in one tap. Resetting automatically would destroy laps
 the user recorded, which is worse.
 
@@ -2131,7 +2129,7 @@ The running notification is the **platform chronometer counting up**:
 `setUsesChronometer(true)` + `setChronometerCountDown(false)` + `setWhen(base)`,
 so the system renders the ticking and the service posts once per state change
 rather than sixty times a second. The base is `wallClock.now() - elapsed`,
-computed at post time and **never written anywhere** — which is how the
+computed at post time and **never written anywhere**. That is how the
 notification gets a wall-clock base without breaking §5's "`StopwatchRun`
 carries no wall-clock field whatsoever", a rule a test asserts on the stored
 bytes. The timer's equivalent base *is* a stored column and therefore needs
@@ -2139,8 +2137,8 @@ re-anchoring on a clock change; the stopwatch's needs nothing but a re-post,
 which is all `onSystemTimeChanged()` does.
 
 The shade's readout is therefore whole seconds. A *paused* body is frozen, so it
-shows the full `StopwatchFormat.precise` value — it is stable, and the precision
-is the point of having stopped. The channel is its own, `stopwatch`, at
+shows the full `StopwatchFormat.precise` value, since it is stable and the
+precision is the point of having stopped. The channel is its own, `stopwatch`, at
 `IMPORTANCE_LOW` with sound and vibration off: nothing here ever needs to
 heads-up, because nothing here ever finishes. That is why there is no
 alert-once rule, no `alreadyAlerted` flag and no session window anywhere in this
@@ -2169,9 +2167,9 @@ noise at 60 Hz).
 
 `StopwatchReadings.of(run, elapsedRealtime)` is the single pure reading, and
 `LivePillSelector`, `StopwatchNotificationPolicy` and `StopwatchRows` all call
-it — the same extraction M6 made for `TimerReadings`, and for the same reason:
+it. That is the same extraction M6 made for `TimerReadings`, for the same reason:
 three copies of "what does this read right now" is how three surfaces start
-disagreeing. `LivePillSelectorTest` passing **unmodified** is the proof the
+disagreeing. `LivePillSelectorTest` passes **unmodified**, which shows the
 extraction changed no behaviour. Its two rules are in §5: the mode comes from
 the snapshot, and the value is floored at the last lap's total.
 
@@ -2183,7 +2181,7 @@ Decided in `LapStats`, because the roadmap left them open:
   asserted as a constant so a change is deliberate). With one lap there is
   nothing to compare; with two, "best" and "worst" mark every row and say the
   same thing twice.
-- **Ties go to the lowest lap index** — "first to achieve it" is the defensible
+- **Ties go to the lowest lap index.** "First to achieve it" is the defensible
   reading and it is deterministic.
 - **If the fastest and the slowest split are equal, neither exists.** Every lap
   identical is not a run with a best and a worst in it.
@@ -2191,22 +2189,22 @@ Decided in `LapStats`, because the roadmap left them open:
   it has not finished, so it cannot be the fastest. A lap can therefore never be
   both, which falls out of the rules rather than needing a guard.
 
-Best is `colorScheme.primary` and worst is `colorScheme.tertiary` — both scheme
-tokens, and `error` is deliberately not used, because a slow lap is not a
+Best is `colorScheme.primary` and worst is `colorScheme.tertiary`, both scheme
+tokens. `error` is deliberately not used, because a slow lap is not a
 failure. Colour is not the only channel: each row carries a content description
 naming what it is, since a distinction a screen reader cannot hear is not a
 distinction.
 
 ### The tab
 
-A fixed readout and its controls **above** a lap list — scrolling a long list
-must not put Lap out of reach mid-run — and the list runs **newest first**,
+A fixed readout and its controls sit **above** a lap list, so scrolling a long
+list cannot put Lap out of reach mid-run, and the list runs **newest first**,
 which is Google Clock's order (`PLAN.md` §11). A lap row is a three-column table
 (index · split · total) and therefore a bespoke `Row` rather than a
 `GroupedRow`: `ListItem` has one trailing slot and a table has two figures.
 
 The first row is the **lap in progress**: index `laps.size + 1`, cumulative the
-current reading, split `elapsed - lastLapCumulative` floored at zero — which is
+current reading, split `elapsed - lastLapCumulative` floored at zero. That is
 what `stopwatch_last_lap_cumulative_millis` has existed for since M2 with no
 caller. It appears **only once at least one lap has been recorded**: with none,
 its split *and* its cumulative equal the hero figure, so the tab would print the
@@ -2215,14 +2213,14 @@ stopped mid-lap and that is true.
 
 The vocabulary is **Start · Pause/Lap · Resume/Reset**. An idle stopwatch offers
 one button: a Lap with nothing to lap and a Reset with nothing to reset are dead
-controls. Reset is not offered while running — the user pauses first, which is
-Google Clock again; the pill's Stop still resets from any state, which is M4's
+controls. Reset is not offered while running: the user pauses first, which is
+Google Clock again. The pill's Stop still resets from any state, which is M4's
 contract and unchanged. The word "Stop" is deliberately absent from this tab: in
 Clockula "Stop" already means "reset", and a Stop that paused would be the one
 inconsistency in the app's verbs.
 
-The cadence is `StopwatchDefaults.ReadoutTick` — 16 ms, about 60 Hz, the
-display's own cadence — and the ticker is subscribed **only while the stored
+The cadence is `StopwatchDefaults.ReadoutTick` (16 ms, about 60 Hz, the
+display's own cadence), and the ticker is subscribed **only while the stored
 state is RUNNING**. A paused or idle stopwatch therefore costs nothing, and the
 flow is distinct-until-changed, which absorbs the one case where the record says
 running and the reading does not move. The cadence is a `Ticker` parameter, never
@@ -2231,13 +2229,13 @@ a `delay` at a call site.
 `StopwatchLaps.MAX = 999`. Beyond it the Lap button is disabled (carrying "Lap
 limit reached" as its description) and `StopwatchEngine.lap()` returns null. An
 unbounded table behind a button that can be held down is a storage leak the user
-cannot see or clear except by resetting — and 999 keeps the index column three
+cannot see or clear except by resetting, and 999 keeps the index column three
 digits wide, which is a layout fact as well as a limit. The guard is the
 engine's, under its lock, over `lapCount()`.
 
-Deliberately no `MaterialShapes` morph and no wavy progress: a stopwatch has no
-progress — there is nothing to be a fraction of — and a decorative arc would be
-a lie drawn to two decimal places.
+There is deliberately no `MaterialShapes` morph and no wavy progress. A stopwatch
+has no progress (there is nothing to be a fraction of), and a decorative arc
+would be a lie drawn to two decimal places.
 
 ### The typography, settled here for the whole app
 
@@ -2246,8 +2244,8 @@ as two things.
 
 `ClockulaTypography` applies **tabular figures** (`fontFeatureSettings = "tnum"`)
 to the display, headline and title roles of the M3 default. That is the app-wide
-half: every existing readout — `TimerRow`'s `headlineLarge`, `TimerSetupPanel`'s
-`displayMedium`, the live pill's `titleMedium` — stops jittering as its digits
+half: every existing readout (`TimerRow`'s `headlineLarge`, `TimerSetupPanel`'s
+`displayMedium`, the live pill's `titleMedium`) stops jittering as its digits
 change, with **no call-site change anywhere**. Body and label roles keep
 proportional figures, because prose is not a column of numbers.
 
@@ -2255,7 +2253,7 @@ proportional figures, because prose is not a column of numbers.
 `*Defaults` shape (composable getters over `MaterialTheme.typography`, so a
 theme change still flows): `Hero` (`displayLarge`, `FontWeight.Medium`),
 `HeroFraction` (`headlineMedium`, about half the hero's size) and `Figure`
-(`bodyLarge` with tabular figures — a figure inside a table row, the one place
+(`bodyLarge` with tabular figures, for a figure inside a table row, the one place
 body-scale text *is* a column of numbers). No new font, no size outside the M3
 scale, and no weight above Medium: `PLAN.md` §8's "Expressive ≠ big or bold"
 applies hardest to the one screen most tempted to break it. A build rule keeps
@@ -2270,7 +2268,7 @@ The section to read before changing anything zone-shaped.
 ### There is no engine, and there must not be one
 
 `AlarmEngine`, `TimerEngine` and `StopwatchEngine` exist because each owns a
-platform registration that has to move with stored state — an AlarmManager slot,
+platform registration that has to move with stored state: an AlarmManager slot,
 a foreground service, a ring session. **A world clock owns none of them.** It
 schedules nothing, wakes nothing, rings nothing and posts no notification, so a
 fourth engine would be three empty seams and a `Mutex` guarding nothing.
@@ -2278,8 +2276,8 @@ fourth engine would be three empty seams and a `Mutex` guarding nothing.
 M8's shape is therefore the one §13/§14 describe for a *screen*: a pure state
 builder (`WorldClockRows`), a `Source` that combines the repository, the prefs,
 the directory, the clocks and the ticker into it, and a ViewModel that calls the
-repository and `SettingsPrefs` directly. Every verb the tab has — `add`,
-`remove`, `reorder`, `setHomeZone` — is a plain write with nothing to actuate
+repository and `SettingsPrefs` directly. Every verb the tab has (`add`,
+`remove`, `reorder`, `setHomeZone`) is a plain write with nothing to actuate
 afterwards.
 
 ### The ICU seam, and which half of tzdata is pure
@@ -2287,13 +2285,13 @@ afterwards.
 The device's tzdata gives two different things, and they belong on two different
 sides of the boundary.
 
-**The ids** are `java.time.ZoneId.getAvailableZoneIds()` — plain JVM, and
+**The ids** are `java.time.ZoneId.getAvailableZoneIds()`: plain JVM, and
 therefore assertable in a unit test with no fake at all. They arrive through the
 existing `ZoneProvider` seam as `available(): Set<String>`, because a static
 `getAvailableZoneIds()` at a call site is the same ambient read `PLAN.md` §5
 bans for `now()`, and a test needs to hand over a small set.
 
-**The names** — the exemplar city, the country and the long zone name — are
+**The names** (the exemplar city, the country and the long zone name) are
 `android.icu`, which does not exist on the JVM test classpath. They go behind
 **`ZoneNames`** in `data/zones/`, in exactly the shape `RingtoneCatalog` already
 has. Every method is **total and never throws**: ICU on an unusual OEM build
@@ -2303,7 +2301,7 @@ must degrade a caption, not crash a tab, so `IcuZoneNames` wraps every body in
 
 `ZoneDirectory` is the `@Singleton` that joins the two. It runs on
 `@IoDispatcher` (§7), caches the catalog on the **locale tag** under one
-`Mutex`, and builds **lazily** — the tab resolves one entry per stored clock
+`Mutex`, and builds **lazily**: the tab resolves one entry per stored clock
 through `entryFor`, and only the picker ever calls `entries()`. Those entries
 are memoised here too, on the same locale tag, so a per-app language change
 re-resolves the cities; a cache above this seam would keep the rows in the old
@@ -2318,12 +2316,12 @@ two per row.
 
 `ZoneCatalog.pickableIds` keeps an id iff its first segment is one of the ten
 IANA regions **and** it is its own canonical id. The first rule drops
-`Etc/GMT+5`, `US/Pacific`, `SystemV/AST4` and `EST5EDT` — not city ids, and a
-user picking "GMT+5" is picking a fixed offset that will be wrong in six months.
+`Etc/GMT+5`, `US/Pacific`, `SystemV/AST4` and `EST5EDT`, which are not city
+ids, and a user picking "GMT+5" is picking a fixed offset that will be wrong in six months.
 The second drops the `backward` aliases, so the picker offers **Asia/Kolkata**
 and not also Asia/Calcutta, and the answer comes from the tzdata's own
-canonicalisation through ICU rather than from a table of ours that would rot —
-`PLAN.md` §0's second commitment, applied. An alias is only dropped when its
+canonicalisation through ICU rather than from a table of ours that would rot.
+That applies `PLAN.md` §0's second commitment. An alias is only dropped when its
 canonical id is itself available: ICU (`com.android.i18n`) and tzdata
 (`com.android.tzdata`) are separately updatable APEX modules, and a device whose
 tzdata still says `Europe/Kiev` while ICU already says `Europe/Kyiv` must not be
@@ -2338,7 +2336,7 @@ Search is **word-prefix over folded text**, not substring: NFD, combining marks
 stripped, lowercased through `Locale.ROOT`, split on anything that is not a
 letter or a digit. So "São Paulo" folds to "sao paulo", "york" and "new yor" and
 "yor new" all find New York, "germany" finds Berlin through the country, and
-**"erl" does not find Berlin** — a three-letter query must not turn into forty
+**"erl" does not find Berlin**, because a three-letter query must not turn into forty
 unrelated hits. Filtering preserves the catalog's own order rather than ranking,
 because the catalog is already sorted by city and an alphabet everybody can
 predict beats a relevance score nobody can.
@@ -2346,9 +2344,9 @@ predict beats a relevance score nobody can.
 Since M9 the folding itself lives in `domain/text/TextFolding`, and `ZoneSearch`
 delegates to it: `ALARM_SEARCH_MODE_LABEL` has to fold the same way, and a
 second copy of NFD-fold-and-lowercase is how "café" starts matching on one
-surface and missing on the other. The *matching* is still different on purpose —
-the picker is word-prefix, the label search is substring (§17) —
-`ZoneSearchTest` passes unmodified, which is the proof the extraction changed no
+surface and missing on the other. The *matching* is still different on purpose
+(the picker is word-prefix, the label search is substring, §17).
+`ZoneSearchTest` passes unmodified, which shows the extraction changed no
 behaviour.
 
 ### The offset and the day are read at the instant
@@ -2365,7 +2363,7 @@ dayDifference  = DAYS.between(home local date, other local date)
 That is the discipline `AlarmOccurrences` uses for alarms (§11): let `java.time`
 answer the transition. Berlin↔Sydney is **ten** hours apart in January and
 **eight** in July, and a subtraction of standard offsets would get both wrong.
-The day comes from the two local *dates*, not from the offset — Berlin and
+The day comes from the two local *dates*, not from the offset: Berlin and
 Honolulu are eleven hours apart and still on the same calendar day.
 
 The labels are **data, not strings**, following `NextFireFormat`'s precedent:
@@ -2384,7 +2382,7 @@ the fallback is tested rather than implied, and `ClockPrefs.homeZoneId` already
 normalises through `Zones` in both directions (§6), so a zone the tzdata later
 dropped reads back as absent before `resolve` ever sees it.
 
-Consequences, all deliberate. **Nothing is seeded** — a fresh install shows the
+Consequences, all deliberate. **Nothing is seeded**: a fresh install shows the
 device's zone on the face and an empty list, and the face is not a stored row.
 **Home is set from this tab**, through the top-bar action, because a preference
 the user cannot reach is not handling; M10 may surface it a second time. **The
@@ -2400,19 +2398,19 @@ would be a lie drawn to two decimal places.*
 
 So the morph here **carries information**. The dial is
 `Morph(MaterialShapes.Circle, MaterialShapes.Sunny)` and its progress is
-`DayNight.fractionAt(localTime)` — a plain circle in the middle of the night
+`DayNight.fractionAt(localTime)`: a plain circle in the middle of the night
 there, a sun at midday. "Is it the middle of the night where they are" is
 precisely the question a world clock exists to answer, and answering it with
 shape rather than a third line of text is what §8's "refinement comes from
 shape, colour, space and motion" means.
 
-`DayNight` is a stated **convention, not an ephemeris**: 0 below 05:00, a linear
+`DayNight` is a stated convention rather than an ephemeris: 0 below 05:00, a linear
 ramp to 1 at 07:00, 1 until 17:00, a linear ramp back to 0 at 19:00. It needs no
 latitude, it has obvious tests, and the app never claims it is sunrise.
 
-The rest is ordinary `Canvas` work over `AnalogFace`'s pure angles — twelve hour
-marks with the four quarters longer, three hands, a centre cap — in scheme
-tokens only. The morph is built once and the path re-derived into a reused
+The rest is ordinary `Canvas` work over `AnalogFace`'s pure angles: twelve hour
+marks with the four quarters longer, three hands, a centre cap, all in scheme
+tokens. The morph is built once and the path re-derived into a reused
 `Path` per frame through `toPath(Morph, Float, Path)`, which is not
 `@Composable` and is therefore callable from a `DrawScope`. M8 left the digital
 time out from under the face on the grounds that an analog face that also
@@ -2422,7 +2420,7 @@ home time now sits under the face as a `displaySmall` readout in the app's
 for and a dial is the slow way to read it. The face keeps the day/night shape
 digits cannot carry. With the time on screen as text, the face is hidden from
 TalkBack, and the readout, "Home", the city and the zone name are one merged
-node, so the time is read once. Neither is a live region — that would recite
+node, so the time is read once. Neither is a live region, since that would recite
 the clock for as long as the tab was open, which is the mistake M4 already
 refused for the live pill (§12).
 
@@ -2430,8 +2428,8 @@ refused for the live pill (§12).
 
 `WorldClockDefaults.Tick = 200 ms`. `RealTicker` is a plain `delay` loop with no
 alignment to the wall second, so a one-second cadence would leave the second
-hand up to a full second behind the device clock — visible, and not something a
-clock app ships. The cost is bounded by making the state **stable**:
+hand up to a full second behind the device clock, which is visible and not
+something a clock app ships. The cost is bounded by making the state **stable**:
 `HomeFaceState.time` is truncated to the second, `WorldClockRowState.time` to
 the minute, and the flow is `distinctUntilChanged`. The upstream emits five
 times a second, a new state is produced about once a second, and the rows' own
@@ -2444,19 +2442,19 @@ The kit's `ReorderableColumn` is not lazy and pins rows to a 64dp pitch, so the
 list needs a bound: **`WorldClocks.MAX = 24`**, one per hour of the day, a list
 a person can take in at a glance. Past it the FAB carries "Add up to 24 cities"
 as its description, the same sentence is printed below the list where a sighted
-user can read it — M3's `ExtendedFloatingActionButton` has no `enabled`
-parameter to dim it with, and a refusal only a screen reader can hear is a dead
-button to everybody else — and the ViewModel refuses the add: the same shape as
-`StopwatchLaps.MAX = 999` (§15): a constant with a reason, asserted as a
-constant so a change is deliberate.
+user can read it, and the ViewModel refuses the add. (M3's
+`ExtendedFloatingActionButton` has no `enabled` parameter to dim it with, and a
+refusal only a screen reader can hear is a dead button to everybody else.) This
+is the same shape as `StopwatchLaps.MAX = 999` (§15): a constant with a reason,
+asserted as a constant so a change is deliberate.
 
 A drag-only reorder is inaccessible. TalkBack cannot press-and-drag and neither
 can a keyboard, and M4 settled the principle when the hold challenge grew an
 accessibility `onClick`: *a challenge TalkBack cannot answer is exactly the
 stranding the requirement forbids.* So every row carries three custom
-accessibility actions — **Move up**, **Move down**, **Remove** — alongside the
+accessibility actions (**Move up**, **Move down**, **Remove**) alongside the
 handle and the long-press. The row also merges its descendants under one
-**content description** — the city, the time and the summary as one sentence —
+content description (the city, the time and the summary as one sentence)
 rather than letting TalkBack read three child texts in child order; that is
 also the only place the "no longer on your device" sentence is spoken. The arithmetic behind the first two is pure
 (`WorldClocks.moveUp`/`moveDown`), a no-op at the end it is already at and for
@@ -2464,13 +2462,13 @@ an id the list does not hold, and always a permutation of its input; a move that
 changes nothing writes nothing.
 
 Remove is a long-press plus a confirmation that names the city, with
-deliberately **no undo chip** — the same trade M5 and M6 made: the cheap moment
-to ask is before. The pending id is `rememberSaveable`, so a rotation
+deliberately **no undo chip**. That is the same trade M5 and M6 made: the cheap
+moment to ask is before. The pending id is `rememberSaveable`, so a rotation
 mid-confirmation does not lose the question.
 
 A row whose zone the device's tzdata no longer knows shows **no time, no offset
-and no day** — `WorldClockRowState` carries all three as `null`, non-null
-exactly when `known` is true — and says "This time zone is no longer on your
+and no day** (`WorldClockRowState` carries all three as `null`, non-null
+exactly when `known` is true) and says "This time zone is no longer on your
 device" instead. The row is kept, never rewritten: §4 already decided that, and
 inventing a time for a zone nobody can resolve would be worse still.
 
@@ -2480,9 +2478,9 @@ inventing a time for a zone nobody can resolve would be worse still.
 
 `android.provider.AlarmClock` is the contract every other app on the device
 drives a clock app through: an assistant, an automation app, a watch companion,
-a shell script. M9 answers **all seven** of its actions — `SET_ALARM`,
+a shell script. M9 answers **all seven** of its actions: `SET_ALARM`,
 `SET_TIMER`, `SHOW_ALARMS`, `SHOW_TIMERS`, `DISMISS_ALARM`, `SNOOZE_ALARM` and
-`DISMISS_TIMER` — and the section to read before touching anything
+`DISMISS_TIMER`. This is the section to read before touching anything
 intent-shaped.
 
 ### The shape: one pure parser, one Android adapter, one exported door
@@ -2510,23 +2508,23 @@ idempotent navigation and nothing else. That is why a process death recreating
 `MainActivity` with its original intent cannot re-run a `SKIP_UI` write, which
 it would if `MainActivity` parsed `SET_ALARM` itself. The handler runs on the
 injected `@ApplicationScope` with `async`, and the door `await`s it in
-`lifecycleScope` — so the write outlives a task swiped away mid-flight, while
+`lifecycleScope`, so the write outlives a task swiped away mid-flight, while
 the `startActivity` that follows only happens if the door is still alive. The
 `await` is wrapped in `runCatching`: a caller's broken intent must not take the
 app down mid-alarm.
 
 ### A `Bundle` modelled honestly
 
-Hostile input is not "an out-of-range int". It is an `Int` where a `String` was
+Hostile input is more than "an out-of-range int". It is an `Int` where a `String` was
 documented, a `CharSequence` that is not a `String`, a list with a `null` in it,
 a key that is present and null. The platform's typed getters hide all of that
-behind a default and cannot tell "absent" from "wrong type" — which is precisely
-the distinction this milestone is about. So the parser's input is
+behind a default and cannot tell "absent" from "wrong type", which is the
+distinction this milestone is about. So the parser's input is
 `IntentExtras`, a value class over `Map<String, Any?>` whose four accessors are
 **total**: absent *or* wrong type reads back as `null`. The adapter lifts
 exactly the contract's eleven keys out of the `Bundle` with one documented
-`@Suppress("DEPRECATION")` on `Bundle.get` — the only API that returns a
-heterogeneous value with its type intact — so there is **one** copy of the type
+`@Suppress("DEPRECATION")` on `Bundle.get` (the only API that returns a
+heterogeneous value with its type intact), so there is **one** copy of the type
 rules, and it is the copy the tests run. `string()` accepts any `CharSequence`
 (a `SpannableString` from another app is a legitimate message); `int()` accepts
 an `Int` and nothing else, because a caller sending `7L` for `EXTRA_HOUR` is
@@ -2547,12 +2545,12 @@ and M9 needs one rule:
 | `EXTRA_HOUR` | 0..23 | **dropped** ⇒ the spec is incomplete ⇒ the editor opens |
 | `EXTRA_MINUTES` | 0..59 | **dropped** ⇒ incomplete. Absent ⇒ **0**, the contract's own default |
 | `EXTRA_LENGTH` | 1..86 400 s | **dropped** ⇒ the setup panel opens |
-| `EXTRA_DAYS` entry | Calendar 1..7 | **dropped**, per entry — but see below |
+| `EXTRA_DAYS` entry | Calendar 1..7 | **dropped**, per entry, but see below |
 | `EXTRA_RINGTONE` | a scheme we accept | **dropped** ⇒ inherit the app default |
 | `EXTRA_ALARM_SNOOZE_DURATION` | 1..60 min | **clamped** |
 
 Clamping the hour would set an alarm for 23:00 that the caller asked to set for
-25:00 — enabled, and ringing at an hour nobody chose. Clamping the snooze is the
+25:00, enabled, and ringing at an hour nobody chose. Clamping the snooze is the
 opposite case: the alarm is sounding *now*, the user asked for quiet, and
 refusing a 1 000-minute snooze by leaving it ringing is strictly worse than
 granting a 60-minute one. 1..60 is `ClockPrefs`' own clamp, so a snooze an intent
@@ -2562,8 +2560,8 @@ can ask for is always one the user could have chosen by hand.
 side. Entries are dropped one by one, but a list the caller **sent non-empty**
 and from which **nothing** survived makes the spec incomplete, so the editor
 opens and the user sees it. What counts is what was *sent*, not what parsed:
-`[0, 99]` and `["mon", "tue"]` — the second is what
-`putStringArrayListExtra` produces — are the same mistake, and treating either
+`[0, 99]` and `["mon", "tue"]` (the second is what
+`putStringArrayListExtra` produces) are the same mistake, and treating either
 as "the caller asked for a one-shot" turns a repeating alarm into an enabled
 single alarm, which is a missed alarm next week. Only an **explicitly empty**
 list, an absent one, or a value that is not a list at all is a one-shot.
@@ -2575,13 +2573,13 @@ not reach for `putIntegerArrayListExtra`.
 
 Two more sanitisers. `EXTRA_MESSAGE` becomes a label: trimmed, stripped of every
 character below a space (a newline in a one-line `ListItem` is a layout bug and
-a `\u0000` in a `TEXT` column is worse) and **truncated** to 256 characters —
-truncated, not dropped, because half a label still names the alarm while half an
-hour does not. `EXTRA_RINGTONE` is accepted only if, after trimming, it is at
+a `\u0000` in a `TEXT` column is worse) and **truncated** to 256 characters.
+It is truncated rather than dropped because half a label still names the alarm,
+while half an hour does not. `EXTRA_RINGTONE` is accepted only if, after trimming, it is at
 most 2 048 characters, carries no control character and begins with `content://`
 or `android.resource://`; `"silent"` (exact, case-sensitive) maps to
 `Ringtones.SILENT_URI`, which forces vibration, so a silent alarm set by another
-app is still an alarm. Everything else — `file://`, `http://`, a bare path —
+app is still an alarm. Everything else (`file://`, `http://`, a bare path)
 reads back as `null`, which in Clockula means *inherit*, which is exactly the
 contract's own documented fallback. It is a drop, not a rejection: an unusable
 sound must never stop an alarm from being set.
@@ -2593,17 +2591,17 @@ sound must never stop an alarm from being set.
 | `SET_ALARM`, valid hour, `SKIP_UI` | create-or-reuse the alarm, enabled, transient; no window |
 | `SET_ALARM`, valid hour | the same, not transient, then the Alarms tab |
 | `SET_ALARM`, no valid hour | create at `nextWholeHour` carrying every extra that *was* valid, enabled, never transient, then **its editor** (§13) |
-| `SET_TIMER`, valid length | create-or-reuse a timer and **start** it — "this action always starts the timer" — with or without the Timers tab |
+| `SET_TIMER`, valid length | create-or-reuse a timer and **start** it ("this action always starts the timer"), with or without the Timers tab |
 | `SET_TIMER`, no valid length | write **nothing**; the setup panel |
 | `SHOW_ALARMS` / `SHOW_TIMERS` | the tab; no extra is read |
 | `DISMISS_ALARM` | see below |
 | `SNOOZE_ALARM` | the ringing alarm only, for the clamped minutes; nothing written if nothing is ringing |
-| `DISMISS_TIMER` | with no data URI, every expired timer; with one, the timer `clockula://timer/{id}` names — and a URI naming no timer of ours dismisses **nothing** and opens the Timers tab, because a mistyped id must not widen to "all of them", which for a transient timer means deleting them (§14) |
-| anything else, or null | `Unsupported`: no write, no window — opening the app because somebody aimed garbage at an exported activity would be a free way to take over the screen |
+| `DISMISS_TIMER` | with no data URI, every expired timer; with one, the timer `clockula://timer/{id}` names. A URI naming no timer of ours dismisses **nothing** and opens the Timers tab, because a mistyped id must not widen to "all of them", which for a transient timer means deleting them (§14) |
+| anything else, or null | `Unsupported`: no write, no window, since opening the app because somebody aimed garbage at an exported activity would be a free way to take over the screen |
 
 **Reuse** ("an identical alarm may be re-used") means time, repeat days, label,
-ringtone and vibrate all equal the sanitised request — the five fields the
-extras can set, so a snooze override the user set by hand does not prevent it.
+ringtone and vibrate all equal the sanitised request. Those are the five fields
+the extras can set, so a snooze override the user set by hand does not prevent it.
 Ties go to the **lower id**, the same rule the alarm engine's precedence
 already uses. A reused alarm is enabled *and* has any pending skip cleared,
 because leaving one armed would silently eat the occurrence just asked for, and
@@ -2626,23 +2624,23 @@ somebody's running countdown is destructive.
 
 Three deliberate narrowings, each because the alternative is worse. **A data
 URI that is present and unreadable is not the same as no URI**: it names none,
-rather than falling through to the search mode — or, with no mode given, to the
-unspecified search's *every enabled alarm*. Otherwise a caller that named one
+rather than falling through to the search mode (or, with no mode given, to the
+unspecified search's *every enabled alarm*). Otherwise a caller that named one
 alarm and mistyped its id would dismiss alarms it never named, and with exactly
 one enabled alarm that happens silently, below the two-match dialog. **Time
 matches exactly, never "nearest"**: the contract says "most closely matched", and
 dismissing an alarm the caller did not name is a missed alarm, at any distance.
 **`EXTRA_IS_PM` is consulted only when the hour is ambiguous**: 13..23 is a
 24-hour reading and wins over a contradictory flag, 12 + AM is midnight and 12 +
-PM is noon, and a 0..12 hour with the flag *absent* — the case the contract calls
-ambiguous and says to ask about — carries **both** readings as candidates, so the
+PM is noon, and a 0..12 hour with the flag *absent* (the case the contract calls
+ambiguous and says to ask about) carries **both** readings as candidates, so the
 ambiguity only reaches the user when the data cannot settle it. Label search is
 substring after folding rather than the zone picker's word-prefix, because "my
 gym alarm" must find "Morning gym"; a **blank** phrase matches nothing, since a
 needle that matched everything would dismiss every alarm in the app.
 
 When to ask: `ALL` means "all of them", so it dismisses every match and never
-asks — taken literally, the contract's "show the results" would make that mode
+asks; taken literally, the contract's "show the results" would make that mode
 useless. Every other search with **two or more** matches returns
 `ChooseAlarmToDismiss` and writes nothing; with one it dismisses; with none it
 opens the Alarms tab and writes nothing. "Dismiss" is
@@ -2653,8 +2651,8 @@ opens the Alarms tab and writes nothing. "Dismiss" is
 The contract, twice: a `SKIP_UI` alarm that is not repeating, and a `SKIP_UI`
 timer, "should be removed after it has been dismissed". Without it, "wake me at
 6:30" every morning leaves a disabled 06:30 row behind every single time. The
-flag is set **only** on the `SKIP_UI` create path — never on reuse, never on the
-incomplete/editor path — so only the voice/automation route can produce a
+flag is set **only** on the `SKIP_UI` create path (never on reuse, never on the
+incomplete/editor path), so only the voice/automation route can produce a
 transient row, and it is honoured in two places, both inside an engine and both
 under its lock (§11, §14). `upcoming()` stays read-only: collecting it over a
 transient alarm deletes nothing.
@@ -2662,7 +2660,7 @@ transient alarm deletes nothing.
 One consequence, accepted rather than papered over: a user who edits an
 assistant-set alarm's label still has a transient alarm, and it still vanishes
 after it rings. That is Google Clock's behaviour too, the alarm is still "the one
-the assistant set", and the alternative — clearing the flag on any edit — means
+the assistant set", and the alternative (clearing the flag on any edit) means
 the editor has to know about a contract it otherwise never touches.
 
 ### Deeplinks
@@ -2674,7 +2672,7 @@ digits, a positive `Long`, no query and no fragment, trimmed first because an
 and falls through to the search mode rather than being guessed at. It
 **publishes** none in v1: publishing one requires the
 `VoiceInteractor.CompleteVoiceRequest` flow that §10 puts out of scope. Reading
-an id from an untrusted caller is safe — dismissing an alarm is reversible, the
+an id from an untrusted caller is safe: dismissing an alarm is reversible, the
 caller already holds `SET_ALARM`, and every engine verb is guarded by the state
 it makes sense for.
 
@@ -2685,6 +2683,6 @@ M3; M9 fixed what tapping them opens (§11). That icon is also why there is **no
 toast** on a `SKIP_UI` write, where AOSP DeskClock has one: `SKIP_UI` means
 "bypass any intermediate UI", a voice assistant speaks its own confirmation, the
 app has shipped nine milestones with no toast anywhere, and formatting "Alarm set
-for 7:00" would need a second, non-composable 12/24-hour formatter — the thing
+for 7:00" would need a second, non-composable 12/24-hour formatter, the thing
 M8 spent a milestone eliminating. The platform's own receipt is better than a
 toast and costs nothing.
diff --git a/docs/BACKUP.md b/docs/BACKUP.md
index dafe8d2..fe3157d 100644
--- a/docs/BACKUP.md
+++ b/docs/BACKUP.md
@@ -1,6 +1,6 @@
 # Clockula backup format
 
-`clockula-backup-v1.json` — a documented, versioned JSON export of Clockula's
+`clockula-backup-v1.json` is a documented, versioned JSON export of Clockula's
 own data, written to (and read from) a user-chosen folder via SAF
 (`docs/PLAN.md` §7). This file is the schema's source of truth; the codec
 (`data/backup/BackupDto.kt`, `BackupCodec.kt`) implements exactly what is
@@ -20,18 +20,18 @@ written here.
 }
 ```
 
-- `format` — must be exactly `"clockula-backup"`.
-- `version` — must be exactly `1`. Any other value rejects the whole file:
+- `format`: must be exactly `"clockula-backup"`.
+- `version`: must be exactly `1`. Any other value rejects the whole file:
   Clockula does not guess at a schema it has not implemented.
-- `exportedAt` — epoch milliseconds, informational only (not re-imported).
+- `exportedAt`: epoch milliseconds, informational only (not re-imported).
 
 ## Parsing rules
 
 - **Tolerant of unknown fields, at any level.** An older or newer client's
   extra field is ignored, never an error.
 - **Strict about known fields.** A malformed value in a field this schema
-  defines — `format`, `version`, an alarm's `hour`/`minute`, a world clock's
-  `zone_id`, a timer's `duration_millis` — rejects the **whole file** with a
+  defines (`format`, `version`, an alarm's `hour`/`minute`, a world clock's
+  `zone_id`, a timer's `duration_millis`) rejects the **whole file** with a
   specific reason. Nothing is imported half-way.
 - Settings values (snooze minutes, volume ramp, …) are
   **not** range-checked at parse time; they pass through the same clamps
@@ -41,19 +41,19 @@ written here.
 - An enum field with a name this version does not recognise (a `dismiss_
   challenge` or `theme_mode` from a future version, say) degrades to that
   field's default, the same forgiving-read posture `AlarmMapper` already uses
-  for a corrupt Room row — it does not fail the import.
+  for a corrupt Room row. It does not fail the import.
 
 ## Import semantics
 
-Import **replaces all state** — alarms, timers and world clocks are deleted
+Import **replaces all state**: alarms, timers and world clocks are deleted
 and re-created from the file, and every setting the file carries is written
 over the current value. This is not a merge, and the backup screen says so
 before the user confirms. A ringing alarm is dismissed and any running timer
 is deleted *before* the replace, so the import never leaves an orphaned ring
 session; alarm/timer/stopwatch scheduling is re-resolved immediately after.
 
-Every imported alarm and timer gets a **fresh id and fresh timestamps** —
-the backup carries no id and no `created_at`/`updated_at`, since those are
+Every imported alarm and timer gets a **fresh id and fresh timestamps**.
+The backup carries no id and no `created_at`/`updated_at`, since those are
 local-database facts, not portable ones.
 
 ## Alarms
@@ -77,7 +77,7 @@ One object per row of `alarms`, config only:
 | `delete_after_use` | Boolean | A transient, contract-created alarm. |
 
 **Not exported:** the `alarm_states` ring-state table (snooze/ringing/handled-
-occurrence bookkeeping) — it is volatile, per-device state, not configuration,
+occurrence bookkeeping). It is volatile, per-device state, not configuration,
 and `docs/ARCHITECTURE.md` §4/§6 are explicit that it must never appear here.
 
 ## Timers
@@ -93,7 +93,7 @@ One object per row of `timers`, config only:
 | `delete_after_use` | Boolean | |
 
 **Not exported:** `state`, `remaining`, the elapsed-realtime anchors, or
-`ends_at_wall_clock` — a timer's running state is meaningless on another
+`ends_at_wall_clock`. A timer's running state is meaningless on another
 device or after a reboot (`docs/PLAN.md` §5). Every imported timer lands
 `IDLE`, with `remaining` equal to `duration`.
 
@@ -128,12 +128,12 @@ files may also carry `default_timer_duration_millis`, from a default timer
 length setting that has since been removed; it is ignored on import like any
 other unknown field. Every
 numeric/duration value is clamped on *apply*, through the existing pref
-setters — never on parse.
+setters, never on parse.
 
 ## Ringtone URIs
 
 Exported exactly as stored (a `content://` URI, typically). On import the
 URI is written back unchanged; if the *importing* device cannot resolve it
 at ring/preview time, the existing ringtone-resolution fallback already used
-elsewhere in the app applies (falls through to the device default) — this is
+elsewhere in the app applies (falls through to the device default). This is
 not special-cased in the backup path itself.
diff --git a/docs/PLAN.md b/docs/PLAN.md
index 9aed8bf..4899d1e 100644
--- a/docs/PLAN.md
+++ b/docs/PLAN.md
@@ -1,6 +1,6 @@
 # Clockula — implementation plan
 
-> The **design decisions and their rationale** — the "why". Locked unless
+> The design decisions and their rationale (the "why"). Locked unless
 > explicitly overturned here. For the moving status view see
 > [`ROADMAP.md`](ROADMAP.md); for the shape of the code as it actually stands,
 > [`ARCHITECTURE.md`](ARCHITECTURE.md) (written from M2 onward).
@@ -32,7 +32,7 @@ in three concrete places:
 1. **The platform alarm contract.** Clockula implements `android.provider.AlarmClock`
    in full (§6), so Assistant, automation apps and anything else that speaks the
    standard intent vocabulary can drive it. That contract *is* the open interface
-   for clocks on Android — the same role `CalendarContract` plays for Calendula.
+   for clocks on Android, the same role `CalendarContract` plays for Calendula.
    Being a good citizen of it is the thesis, applied.
 2. **IANA tzdata.** World clocks are IANA zone IDs, not a bespoke city table (§5).
 3. **Your data leaves whenever you want.** A documented, versioned JSON backup
@@ -44,7 +44,7 @@ Clockula owns storage, but **nothing above the data layer knows Room exists**.
 The app talks to `AlarmRepository` / `TimerRepository` / `WorldClockRepository` /
 `StopwatchRepository`; only the DAOs and one data source per aggregate touch Room
 entities. Domain models are plain Kotlin. **Never let a Room entity or a
-`@Query` string leak above the data layer** — the same discipline that let
+`@Query` string leak above the data layer**. That is the same discipline that let
 Agendula swap its whole storage posture without touching the UI.
 
 ---
@@ -89,7 +89,7 @@ recurrence) are a different animal from a due-date nudge.
 
 ## 3. floret-kit
 
-Consumed as a git submodule + Gradle composite build, as the siblings do —
+Consumed as a git submodule + Gradle composite build, as the siblings do:
 `includeBuild("floret-kit")`, `implementation("de.jeanlucmakiola.floret:<module>")`,
 with a gitignored `clockula/floret-kit/local.properties` locally and
 `ANDROID_HOME` in CI.
@@ -128,7 +128,7 @@ Everything else in this app is a readout. This is the engineering.
   `TIME_SET`, `TIMEZONE_CHANGED`, and `MY_PACKAGE_REPLACED`. DST transitions are
   handled by this re-resolution, not by arithmetic on stored millis. A 02:30
   alarm on a spring-forward night has a defined, tested behaviour.
-- Scheduled with `AlarmManager.setAlarmClock()` — not `setExactAndAllowWhileIdle`.
+- Scheduled with `AlarmManager.setAlarmClock()`, not `setExactAndAllowWhileIdle`.
   `setAlarmClock` is the only variant the system treats as a user-visible alarm:
   it is doze-exempt, and it populates `getNextAlarmClock()`, which is what draws
   the status-bar alarm icon and the lockscreen line. Permission is
@@ -147,7 +147,7 @@ notification whose content intent is the ring activity.
 - Full-screen intent on Android 14+ needs `USE_FULL_SCREEN_INTENT`; check
   `canUseFullScreenIntent()` and deep-link to the grant screen when denied. A
   denied FSI must degrade to a high-priority heads-up notification that still
-  rings — never to silence.
+  rings, never to silence.
 - Gradual volume ramp, per-alarm ringtone (system `RingtoneManager` URIs, so the
   user's existing sounds work), vibration pattern, `AudioAttributes` with
   `USAGE_ALARM` so DND's alarm exemption applies.
@@ -162,7 +162,7 @@ notification whose content intent is the ring activity.
 A "**Why might my alarm not ring?**" screen that reports actual device state, not
 generic advice: exact-alarm permission, notification permission, full-screen-intent
 permission, battery-optimisation exemption, **whether DND currently blocks alarms**
-(read via `NotificationManager.getCurrentInterruptionFilter()` — Clockula never
+(read via `NotificationManager.getCurrentInterruptionFilter()`; Clockula never
 requests `ACCESS_NOTIFICATION_POLICY` or changes DND itself, it only reports what the
 user already has), whether the OEM has Clockula under an aggressive app-killer, and
 the next scheduled fire time as the system sees it (`getNextAlarmClock()`), compared
@@ -175,19 +175,19 @@ the exact settings page. This screen is a v1 feature, not a support afterthought
 
 Room, schema exported and version-controlled, migrations tested from v1.
 
-- **`alarms`** — id, hour, minute, label, enabled, repeat-day mask, ringtone URI,
+- **`alarms`**: id, hour, minute, label, enabled, repeat-day mask, ringtone URI,
   vibrate, snooze minutes, snooze limit, volume-ramp seconds, dismiss challenge,
   `skipNextOccurrence`, timestamps.
-- **`timers`** — id, label, duration, state (idle/running/paused/expired), the
+- **`timers`**: id, label, duration, state (idle/running/paused/expired), the
   elapsed-realtime anchor it resolves against, ringtone, sort order. Multiple
   concurrent timers are first-class.
-- **`world_clocks`** — id, IANA zone ID, optional custom label, sort order.
-- **`stopwatch_laps`** — id, index, split, cumulative. The stopwatch's running
+- **`world_clocks`**: id, IANA zone ID, optional custom label, sort order.
+- **`stopwatch_laps`**: id, index, split, cumulative. The stopwatch's running
   state lives in DataStore (a single record), its laps in Room so they survive
   process death.
 
 Running timers and the stopwatch anchor on **`SystemClock.elapsedRealtime()`**,
-never wall-clock — a user changing the time must not warp a running timer. Alarms
+never wall-clock: a user changing the time must not warp a running timer. Alarms
 are the opposite: wall-clock by definition. This distinction is the single
 easiest thing to get wrong in a clock app; it is tested both ways.
 
@@ -226,12 +226,12 @@ than writing anything. `SKIP_UI` never means "skip validation".
 "timers": […], "worldClocks": […], "settings": {…} }`. The schema is **documented
 in the repo** (`docs/BACKUP.md`), versioned, and import is tolerant of unknown
 fields (ignored, at any level) and strict about known ones (a malformed known
-field rejects the whole file — nothing is imported half-way). Ringtone URIs are
+field rejects the whole file, so nothing is imported half-way). Ringtone URIs are
 exported as-is with a documented fallback when the target device can't resolve
 them.
 
 Import is **whole-state replacement**, not a merge: the user is shown exactly
-that before confirming. Alarm and timer records carry only configuration — ring
+that before confirming. Alarm and timer records carry only configuration. Ring
 state (`alarm_states`, a timer's running anchors) is never exported and never
 touched by an import; an imported timer always lands `IDLE`. Record field names
 mirror the Room column vocabulary (§5), so the schema, the exported Room schema
@@ -241,7 +241,7 @@ and the backup all read the same words.
 
 ## 8. Identity
 
-Seed **`#6B7A5C`** — a muted sage/olive.
+Seed **`#6B7A5C`**, a muted sage/olive.
 
 The family's seeds are one colour rotated: Calendula `#5C6B7A` (slate blue) →
 Agendula `#7A5C6B` (warm mauve) → Clockula `#6B7A5C` (sage). Same three bytes,
@@ -254,10 +254,10 @@ fallback, hand-tuned light/dark `ColorScheme`s in `ui/theme/Color.kt`.
 
 Design principles inherited from the family (non-negotiable):
 - **Expressive ≠ big or bold.** Refinement comes from shape, colour, space and
-  motion — never from enlarging text or upping weight.
+  motion, never from enlarging text or upping weight.
 - Content lives **on surfaces**, not as bare text on the background.
 - `MaterialShapes` / `androidx.graphics.shapes` morphs are for the genuinely
-  clock-specific surfaces — the analog face, the ring screen, timer progress —
+  clock-specific surfaces (the analog face, the ring screen, timer progress),
   not sprinkled everywhere.
 
 A clock app is mostly one enormous number. That readout is where the design
@@ -267,24 +267,24 @@ lives, and it is the thing to get right before anything else.
 
 ## 9. Navigation
 
-Four tabs — Alarm, Timer, Stopwatch, World clock — in an M3 navigation bar, with
+Four tabs (Alarm, Timer, Stopwatch, World clock) in an M3 navigation bar, with
 a **live pill** floating above it whenever a timer or the stopwatch is running:
 current value plus pause and stop, reachable from any tab.
 
 This is the one deliberate departure from the stock model, and it exists because
 the stock clock's worst flaw is that a running timer is invisible unless you are
-standing on its tab. The pill is not decoration; it is the fix.
+standing on its tab.
 
 Adaptive: navigation rail on wide layouts, per M3 adaptive guidance.
 
 ### Home-screen widgets (M10)
 
 Three Jetpack Glance app widgets, each a read-only mirror of state that already
-exists — no widget owns data: **next alarm** (day, time, label), **timer**
+exists (no widget owns data): **next alarm** (day, time, label), **timer**
 (the live pill's subject timer, same selection logic, with pause/resume/reset),
 and **clock** (local time, growing to world clocks at larger sizes). Tapping a
 widget opens the matching tab through the same `MainActivity` intents the
-`AlarmClock` contract (§6) already uses — a widget is just another caller of
+`AlarmClock` contract (§6) already uses. A widget is just another caller of
 that door, not a second entry point. Refresh is event-driven (`updatePeriodMillis
 = 0`): widgets update when the state they mirror changes, not on a timer.
 
@@ -292,24 +292,24 @@ that door, not a second entry point. Refresh is event-driven (`updatePeriodMilli
 
 ## 10. Repository & pipeline
 
-**Codeberg is canonical from the first commit** — git, issues, PRs and releases.
+**Codeberg is canonical from the first commit**: git, issues, PRs and releases.
 The self-hosted Gitea instance holds the secrets and runs the release job, and
 push-mirrors *from* Codeberg. There is no Gitea-canonical phase to migrate out
 of, which is the mistake Agendula had to unwind.
 
 The pipeline is copied wholesale from the siblings:
 
-- `.forgejo/workflows/ci.yaml` — contributor-facing, no secrets. Copy Agendula's,
+- `.forgejo/workflows/ci.yaml`: contributor-facing, no secrets. Copy Agendula's,
   adjusting `SKIP_RE`.
-- `.forgejo/workflows/translations.yaml` — identical in both siblings; copy as-is.
-- `.gitea/workflows/release.yaml` — **Agendula's spine** (Codeberg-canonical: pushes
+- `.forgejo/workflows/translations.yaml`: identical in both siblings; copy as-is.
+- `.gitea/workflows/release.yaml`: **Agendula's spine** (Codeberg-canonical: pushes
   the tag to Codeberg itself, pre-1.0 prerelease flag, and the Codeberg publish
   step is *not* `continue-on-error`, after five Calendula-era releases reported
   green while never publishing) **plus Calendula's `play` job** grafted on
-  unchanged — last, isolated, `continue-on-error`, skipping cleanly until
+  unchanged. It runs last, isolated and `continue-on-error`, and skips cleanly until
   `PLAY_SERVICE_ACCOUNT_JSON` exists. It therefore stays dormant through the
   pre-1.0 run, which is the correct behaviour anyway.
-- `.gitea/workflows/renovate.yml` — Agendula's, including the
+- `.gitea/workflows/renovate.yml`: Agendula's, including the
   `github.repository_owner == 'makiolaj'` guard.
 - Issue templates, PR template, F-Droid metadata, fastlane tree.
 
@@ -331,8 +331,8 @@ useful reference for the parts of an alarm app that are tedious to rediscover.
 - **Default posture: read it, don't copy it.** Understanding how it schedules and
   how its services are wired is free; retyping our own implementation from that
   understanding keeps Clockula cleanly MIT.
-- **Where we genuinely lift code** — realistically only intricate scheduling or
-  service-lifecycle edge cases — that file keeps its Apache-2.0 header and
+- **Where we genuinely lift code** (realistically only intricate scheduling or
+  service-lifecycle edge cases), that file keeps its Apache-2.0 header and
   attribution, is listed in `docs/PROVENANCE.md`, and the Apache text ships in
   `licenses/`. This is exactly the pattern Agendula already uses for the vendored
   dmfs provider, so it is a known, working arrangement rather than a new risk.
@@ -348,16 +348,16 @@ DAO/repository, and the Room entity shapes as a sanity check on §5.
 - Its **always-on foreground service** (`AlarmAlwaysForegroundService`). Keeping a
   permanent service alive to make alarms reliable is a battery-cost workaround;
   `setAlarmClock` is the supported mechanism and does not need it.
-- Its **Pomodoro** feature — out of scope.
+- Its **Pomodoro** feature, which is out of scope.
 - Its **settings/tile component vocabulary** (`ui/components/tiles/*`,
-  `SettingTile`) — floret-kit's `GroupedRow` / `OptionCard` / `OptionPicker` are
+  `SettingTile`). floret-kit's `GroupedRow` / `OptionCard` / `OptionPicker` are
   our equivalents and keep the family coherent.
-- **MaterialKolor + a colour-picker dependency** — the kit's `identity` module
+- **MaterialKolor + a colour-picker dependency**. The kit's `identity` module
   owns theming.
 - Its **no-Hilt, manual-ViewModel structure** and `minSdk 24`.
 
-For interaction detail — snooze behaviour, the ring screen, timer presentation,
-what the stopwatch does with laps — **Google Clock is the reference**, not
+For interaction detail (snooze behaviour, the ring screen, timer presentation,
+what the stopwatch does with laps), **Google Clock is the reference**, not
 ClockMaster.
 
 ---
diff --git a/docs/README.md b/docs/README.md
index 06fada2..665f9d4 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -1,12 +1,12 @@
 # Clockula — documentation
 
-Clockula is a Material 3 Expressive **clock** app for Android — alarms, timers,
+Clockula is a Material 3 Expressive **clock** app for Android: alarms, timers,
 stopwatch and world clock. Third floret of the bloom, after
 [Calendula](https://codeberg.org/jlmakiola/calendula) (calendar) and
 [Agendula](https://codeberg.org/jlmakiola/agendula) (tasks). See the top-level
 [`../README.md`](../README.md) for the pitch.
 
-Unlike its siblings, Clockula owns its storage — there is no open provider behind
+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`](PLAN.md).
 
@@ -15,8 +15,8 @@ is the first section of [`PLAN.md`](PLAN.md).
 | Doc | What it covers |
 |---|---|
 | [`PLAN.md`](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`](ROADMAP.md) | **Status and the work queue** — milestones M0–M11 and post-v1. What the build loop works through. |
-| [`ARCHITECTURE.md`](ARCHITECTURE.md) | How Clockula is built **today** — layers, the data seam, the alarm engine, DI, build/tooling, manifest. Written from M2 onward. |
+| [`ROADMAP.md`](ROADMAP.md) | **Status and the work queue**: milestones M0–M11 and post-v1. What the build loop works through. |
+| [`ARCHITECTURE.md`](ARCHITECTURE.md) | How Clockula is built **today**: layers, the data seam, the alarm engine, DI, build/tooling, manifest. Written from M2 onward. |
 | [`RELEASING.md`](RELEASING.md) | How to cut a release. Written at M0 alongside the pipeline. |
 | [`PROVENANCE.md`](PROVENANCE.md) | Any third-party code carried in-tree and under what licence. Created only if we actually lift something (`PLAN.md` §11). |
 
diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md
index 57cf529..bb7731b 100644
--- a/docs/ROADMAP.md
+++ b/docs/ROADMAP.md
@@ -1,6 +1,6 @@
 # Clockula — roadmap
 
-The **status** view, and the work queue. Design rationale for every decision here
+The status view and the work queue. Design rationale for every decision here
 lives in [`PLAN.md`](PLAN.md); the shape of the code as it stands will live in
 [`ARCHITECTURE.md`](ARCHITECTURE.md) from M2 onward.
 
@@ -13,16 +13,16 @@ Status legend: ✅ done · 🚧 in progress · ⬜ not started
 ✅ **M10 done.** Clockula now has a settings hub (theme, dynamic colour,
 language, the alarm/timer/clock defaults every new alarm or timer inherits,
 help), a documented, versioned JSON backup (`docs/BACKUP.md`) that exports and
-restores alarms/timers/world clocks and settings through SAF — configuration
-only, never ring state, never a timer's running anchors — as a whole-state
+restores alarms/timers/world clocks and settings through SAF (configuration
+only, never ring state, never a timer's running anchors) as a whole-state
 replace the screen is explicit about before the user confirms, a "why might my
 alarm not ring?" self-check that reads real device state (exact-alarm and
 notification permissions, full-screen intent, battery optimisation, DND, alarm
 volume, a known aggressive-OEM allowlist, and the system's own next alarm
 compared against what Clockula computed) and deep-links to the exact settings
-page for each, and three Glance home-screen widgets — next alarm, timer,
-clock — that mirror existing state and redraw event-driven, on every write,
-with no ticker of their own. **M11** (release readiness) is next.
+page for each, and three Glance home-screen widgets (next alarm, timer,
+clock) that mirror existing state and redraw event-driven, on every write,
+with no ticker of their own. M11 (release readiness) is next.
 
 ---
 
@@ -30,12 +30,12 @@ with no ticker of their own. **M11** (release readiness) is next.
 
 One milestone per iteration, auto-continuing. Each iteration:
 
-1. Pick the **first milestone not marked ✅**.
-2. Implement it **completely** — every checklist item under it.
+1. Pick the first milestone not marked ✅.
+2. Implement it completely: every checklist item under it.
 3. Build, and run the tests the milestone names. A milestone is not done until
    they pass.
 4. **Commit** (floret-kit submodule first where it changed, then Clockula's
-   pointer bump — separate commits, granular, lowercase area prefix).
+   pointer bump; separate commits, granular, lowercase area prefix).
 5. Mark the milestone ✅ here, update **Current state**, and commit that too.
 6. Continue to the next milestone.
 
@@ -45,7 +45,7 @@ Rules that hold across every iteration:
   (`PLAN.md` §0).
 - **Never** add a foojay toolchain resolver, anywhere, not even in a comment.
 - Commit each finished unit of work; never accumulate a WIP pile.
-- If a milestone turns out to be wrong, say so and amend `PLAN.md` — do not
+- If a milestone turns out to be wrong, say so and amend `PLAN.md`. Do not
   silently build something else.
 - `ARCHITECTURE.md` and `CHANGELOG.md` are updated as part of the milestone that
   changes them, not in a later cleanup pass.
@@ -75,7 +75,7 @@ The project exists, builds, is themed, and ships itself.
   `scripts/check_reproducible_release.sh` reports every invariant holding.
   Two notes for later: the store listing and `fastlane` changelogs are written
   but no screenshots exist yet (M11), and `docs/ARCHITECTURE.md` is still
-  unwritten by design — M2 writes it, once there is an architecture to
+  unwritten by design. M2 writes it, once there is an architecture to
   describe.
 
 ### ✅ M1 — floret-kit: `core-prefs` + `core-di`
@@ -83,16 +83,16 @@ Pay the extraction the kit's roadmap has been waiting for a third app to trigger
 - In the kit: `core-prefs` (`ThemeMode`, `dynamicColor`, typed DataStore wrapper,
   `toEnum()`) and `core-di` (`@IoDispatcher` + provider), each with tests, module
   docs, `CHANGELOG` and `ROADMAP`/`ARCHITECTURE` updates.
-- Clockula consumes both. Migrating Calendula and Agendula is explicitly **out of
-  scope** — note it in the kit's roadmap as a follow-up.
+- Clockula consumes both. Migrating Calendula and Agendula is explicitly out of
+  scope; note it in the kit's roadmap as a follow-up.
 - **Done when:** the kit's tests pass, Clockula builds against the new modules,
   and both repos are committed (submodule first, then the pointer bump).
 
   ✅ floret-kit 0.4.0. `core-prefs` (56 kit tests) gives the family a typed
   `Pref<T>`/`PrefStore` over DataStore; reads degrade to the default instead of
   throwing, and `flow()` is distinct-until-changed. The appearance key names are
-  frozen at what Calendula and Agendula already write, so the sibling migration —
-  a follow-up in the kit's roadmap, not here — needs no data migration.
+  frozen at what Calendula and Agendula already write, so the sibling migration
+  (a follow-up in the kit's roadmap, not here) needs no data migration.
   `core-di` carries `hilt-compiler` itself, since an `@InstallIn` module only
   reaches a consumer's component if its own library was processed; Clockula's
   `assembleDebug` is the integration test for that binding. Clockula's theme now
@@ -114,19 +114,19 @@ The whole storage stack, headless. No UI.
 
   ✅ Four tables (`alarms`, `timers`, `world_clocks`, `stopwatch_laps`), schema
   v1 exported to `app/schemas` so migrations can be tested from the beginning.
-  The seam that matters: the app talks to four repository interfaces speaking
-  domain types and Flows, and `ArchitectureRulesTest` fails the build if Room, an
-  entity or a query string ever appears above `data/`. Time is a parameter rather
-  than an ambient read — `WallClock` and `ElapsedRealtimeClock` are distinct
-  types, so a running timer anchors on the monotonic clock and keeps a wall-clock
-  value only as a post-reboot fallback, and the stopwatch keeps none at all. That
-  leaves one honest gap, written down rather than glossed: once a new boot's
-  uptime climbs past a stored anchor the reboot goes unnoticed, so closing it
-  needs a persisted boot id and M3's `BOOT_COMPLETED` receiver. Every
-  read-modify-write runs inside a DAO transaction, and the stopwatch run record
-  is written whole in one DataStore edit, so concurrent writers cannot swallow
-  each other's edits or persist a torn record. 151 JVM tests over fake DAOs and
-  injected fake clocks; the migration test is the only thing needing a device.
+  The app talks to four repository interfaces speaking domain types and Flows,
+  and `ArchitectureRulesTest` fails the build if Room, an entity or a query
+  string ever appears above `data/`. Time is a parameter rather than an ambient
+  read: `WallClock` and `ElapsedRealtimeClock` are distinct types, so a running
+  timer anchors on the monotonic clock and keeps a wall-clock value only as a
+  post-reboot fallback, and the stopwatch keeps none at all. That leaves one
+  gap: once a new boot's uptime climbs past a stored anchor the reboot goes
+  unnoticed, so closing it needs a persisted boot id and M3's `BOOT_COMPLETED`
+  receiver. Every read-modify-write runs inside a DAO transaction, and the
+  stopwatch run record is written whole in one DataStore edit, so concurrent
+  writers cannot swallow each other's edits or persist a torn record. 151 JVM
+  tests over fake DAOs and injected fake clocks; the migration test is the only
+  thing needing a device.
 
 ### ✅ M3 — Alarm engine
 The hard part (`PLAN.md` §4), still headless apart from the ring screen's
@@ -140,13 +140,13 @@ plumbing.
 - Ringing foreground service: audio focus, `USAGE_ALARM`, volume ramp, vibration,
   ringtone URIs; survives process death and reboot mid-ring.
 - Full-screen-intent notification + `canUseFullScreenIntent()` handling, degrading
-  to a high-priority heads-up notification that still rings — never to silence.
+  to a high-priority heads-up notification that still rings, never to silence.
 - **Tests:** DST spring-forward and fall-back, every repeat configuration, skip,
   snooze-vs-next-occurrence. These are the tests the app lives or dies on.
 
   ✅ 326 JVM tests, 172 of them new. The engine is a plain Kotlin class that
   reaches Android through four interfaces it does not implement, so the
-  behaviour the app lives or dies on is pinned without an emulator —
+  behaviour the app lives or dies on is pinned without an emulator.
   `ArchitectureRulesTest` fails the build if `android.*` ever appears in
   `domain/`, `AlarmEngine.kt` or `system/`. Occurrences are generated by walking
   local dates through `ZonedDateTime.of` rather than by adding 24 hours to an
@@ -155,43 +155,43 @@ plumbing.
   fall-back night. Asserted for Berlin and New York and across all 128 repeat
   masks. Two rules keep constant re-resolution honest: a two-minute grace window
   so a late fire still counts, and a `handled_occurrence` watermark that can
-  suppress a re-fire but — because suppression also requires the candidate to be
-  at-or-before now — can never silence the future. Skip needed a watermark of its
+  suppress a re-fire but can never silence the future, because suppression also
+  requires the candidate to be at-or-before now. Skip needed a watermark of its
   own, since a bare flag eats a second alarm once the skipped occurrence passes.
   At most one alarm rings and a newly-firing one takes over, so closing a cycle
   touches the shared ring and auto-silence slots only when that alarm is the one
   ringing; every write to `alarm_states` runs under one mutex, because a cold
   start triggered by the fire broadcast otherwise races its own reschedule pass.
-  The "never to silence" chain is a testable invariant, not a hope: full-screen
-  intent, else a heads-up notification that still rings, else the default
-  ringtone, else forced vibration. Schema v2 adds `alarm_states`, and the boot id
-  closes M2's blind spot for running timers **and** the stopwatch — a scope move
-  from M7, recorded in `ARCHITECTURE.md` §5. Knowingly open: the migration and
-  the other 12 instrumentation tests compile but have never run on hardware, as
-  no device was attached; an auto-silenced alarm is silently missed, with no
-  missed-alarm notification until someone asks for one.
+  The "never to silence" chain is a testable invariant: full-screen intent, else
+  a heads-up notification that still rings, else the default ringtone, else
+  forced vibration. Schema v2 adds `alarm_states`, and the boot id closes M2's
+  blind spot for running timers and the stopwatch, a scope move from M7
+  recorded in `ARCHITECTURE.md` §5. Knowingly open: the migration and the other
+  12 instrumentation tests compile but have never run on hardware, as no device
+  was attached; an auto-silenced alarm is silently missed, with no missed-alarm
+  notification until someone asks for one.
 
 ### ✅ M4 — App shell
 - Navigation host, four tabs, M3 navigation bar, adaptive rail on wide layouts.
-- The **live pill** (`PLAN.md` §9) — shared running-state surface, pause + stop
+- The **live pill** (`PLAN.md` §9): shared running-state surface, pause + stop
   from any tab.
 - The ring screen UI: over-lockscreen, turn-screen-on, snooze/dismiss, optional
   dismiss challenge that cannot strand the user.
 - Motion from the kit's `identity` module; predictive back.
 
-  ✅ 480 JVM tests, 154 of them new, and still **no Robolectric** — which had to
-  be earned rather than kept. Everything that decides something moved out of the
-  composables: `ShellNavigation` (what a tab tap does to the back stack, and
-  that back from a tab goes to Alarms while back from Alarms leaves the app),
+  ✅ 480 JVM tests, 154 of them new, and still no Robolectric. Keeping it that
+  way meant moving everything that decides something out of the composables:
+  `ShellNavigation` (what a tab tap does to the back stack, and that back from a
+  tab goes to Alarms while back from Alarms leaves the app),
   `LivePillSelector` (which of several running things the pill is about),
   `ClockFormat`, and `ChallengeGate`. The adaptive part is
-  `NavigationSuiteScaffold` taking its own default — the short bar on a phone,
-  the wide rail on a tablet — rather than a hand-rolled width branch that would
+  `NavigationSuiteScaffold` taking its own default (the short bar on a phone,
+  the wide rail on a tablet) rather than a hand-rolled width branch that would
   miss the tabletop posture. The pill shows for paused and expired timers too,
   not only running ones: pausing from the pill must not make the pill disappear
   under the thumb that pressed it. Its value comes from the snapshot, so a timer
   that reaches zero flips to "finished" before M6's expiry write lands. The
-  challenge's escape hatch opens on three wrong answers **or** sixty seconds of
+  challenge's escape hatch opens on three wrong answers or sixty seconds of
   ringing, for every challenge kind, asserted as one parameterised invariant;
   snooze is never gated; a completed hold *is* the dismissal, and an
   accessibility click completes the hold, because a challenge TalkBack cannot
@@ -200,7 +200,7 @@ plumbing.
   top-level tab draws no back arrow that would pop nothing.
 
   Knowingly open: M4 ships no in-app way to *start* a timer or the stopwatch, so
-  the live pill cannot be demonstrated by hand until M6/M7 — it is proven by its
+  the live pill cannot be demonstrated by hand until M6/M7. It is proven by its
   unit tests and by an instrumentation test that seeds the repository directly,
   and no debug button was added to paper over it. The nine new instrumentation
   tests compile in the gate but have never run on hardware, as no device was
@@ -213,18 +213,18 @@ List, create, edit, delete, enable/disable. Time picker, repeat-day selector,
 label, ringtone picker, vibrate, snooze settings, per-alarm overrides. Next-fire
 line ("in 9h 12m") on each row. Built on `GroupedSurface`/`GroupedRow`.
 
-  ✅ 624 JVM tests, 144 of them new, and **still no Robolectric** — kept for a
+  ✅ 624 JVM tests, 144 of them new, and still no Robolectric, kept for a
   whole *form*, which is where a screen usually reaches for one. Everything a
   tap decides is a pure object (`AlarmListRows`, `NextFireFormat`,
   `RepeatDaysSummary`, `AlarmDefaults`, `AlarmOverrides`, `RingtonePicker`,
   `AudioSourcePolicy`, `AlarmRoutes`) or a ViewModel method tested over the
-  **real** `AlarmEngine`; three new `ArchitectureRulesTest` rules make that a
+  real `AlarmEngine`; three new `ArchitectureRulesTest` rules make that a
   build fact rather than a habit.
 
   The decisions worth knowing: the next-fire line comes from
   `AlarmEngine.upcoming`, which grew a `refresh: Flow<Unit>` cadence parameter
   so the countdown advances without a database write and the screen re-derives
-  none of the engine's time arithmetic; the list is ordered by **time of day**,
+  none of the engine's time arithmetic; the list is ordered by time of day,
   not by next fire, so rows never swap under a thumb at 07:00; every per-alarm
   override is an `OptionPicker` whose first row is "App default (On)", because
   the stored value is ternary and a `Switch` cannot say "I have not chosen";
@@ -235,79 +235,79 @@ line ("in 9h 12m") on each row. Built on `GroupedSurface`/`GroupedRow`.
   read-modify-write, so a one-shot alarm that disabled itself underneath an open
   editor is not re-enabled by the next unrelated tap.
 
-  The correctness find: disabling or deleting a **ringing** alarm used to clear
-  `ringingSince` without stopping the ring service — whose auto-silence backstop
-  then disarms itself on its own null guard — so the alarm would have sounded
+  The correctness find: disabling or deleting a ringing alarm used to clear
+  `ringingSince` without stopping the ring service (whose auto-silence backstop
+  then disarms itself on its own null guard), so the alarm would have sounded
   until the 15-minute wake-lock timeout. Both new ViewModels now dismiss through
   the engine first, conditionally, so a merely snoozed alarm keeps its snooze.
 
-  floret-kit went to **0.6.0** for one change: `CollapsingScaffold` takes a
+  floret-kit went to 0.6.0 for one change: `CollapsingScaffold` takes a
   `floatingActionButton` slot, forwarded to the underlying `Scaffold`, rather
   than each app re-deriving the inset maths in a `Box`.
 
   Knowingly open: no hand reordering of alarms (the time order answers it, and
   `alarms` has no `sort_order` column), no multi-select or bulk delete, no undo
   chip after a delete (traded for a confirmation that names the alarm), no
-  repeat presets, and no per-alarm auto-silence — still M10 at the earliest.
+  repeat presets, and no per-alarm auto-silence (still M10 at the earliest).
   Editing the app-wide defaults every override row offers to follow is M10's
   settings screen. The seven new instrumentation tests compile in the gate but
-  have **never run on hardware**, as no device was attached.
+  have never run on hardware, as no device was attached.
 
 ### ✅ M6 — Timers
 Multiple concurrent timers, presets, labels, add/pause/reset/+1min. Foreground
 service with notification controls, expiry ringing reusing M3's audio path.
 Elapsed-realtime anchored.
 
-  ✅ 843 JVM tests, 219 of them new, and **still no Robolectric** — kept for a
+  ✅ 843 JVM tests, 219 of them new, and still no Robolectric, kept for a
   second screen *and* for a foreground service, which is the other place a
   project usually gives in. Every decision is a pure object (`TimerReadings`,
   `TimerExpiry`, `TimerRingPolicy`, `TimerNotificationPolicy`, `TimerPresets`,
   `TimerDurationEntry`, `TimerListRows`, `TimerRoutes`) or a method on the
-  engine or one of the two ViewModels, tested over the **real**
-  `TimerRepositoryImpl` and the **real** `TimerEngine`. `TimerService` holds no
-  policy and no state beyond one flag — even its two `delay` amounts come from
+  engine or one of the two ViewModels, tested over the real
+  `TimerRepositoryImpl` and the real `TimerEngine`. `TimerService` holds no
+  policy and no state beyond one flag; even its two `delay` amounts come from
   the engine, so the timings are asserted in a JVM test. Three new
   `ArchitectureRulesTest` rules pin it, one of which makes a *second*
   `MediaPlayer` a build failure. The four new instrumentation tests bring the
   compiled total to 32.
 
-  The decisions worth knowing: the expiry slot is **one** registration on the
-  `ELAPSED_REALTIME_WAKEUP` base — so a `TIME_SET` cannot warp a running timer,
+  The decisions worth knowing: the expiry slot is one registration on the
+  `ELAPSED_REALTIME_WAKEUP` base (so a `TIME_SET` cannot warp a running timer,
   and a timer never populates `getNextAlarmClock()`, which belongs to the user's
-  next *alarm* — and its fire is an **idempotent sweep carrying no id**, so a
+  next *alarm*), and its fire is an idempotent sweep carrying no id, so a
   late delivery expires everything due, an early one writes nothing, and the
   anchors *are* the watermark; the service adds a second, independent trigger
   for the same sweep, because neither has to be reliable alone; one
   `systemExempted` foreground service covers the countdown and the ring, alive
   on the live pill's own "active, not running" predicate, and the countdown
-  holds **no wake lock** (the alarm slot is what wakes the device); an alarm
-  ringing **wins the audio** and the timer's ring is *deferred, not lost*,
-  because the arbitration is a pure function of current state rather than an
-  event — so the reverse case is symmetric and free; two timers expiring
+  holds no wake lock (the alarm slot is what wakes the device); an alarm
+  ringing wins the audio and the timer's ring is deferred, because the
+  arbitration is a pure function of current state rather than an event, so the
+  reverse case is symmetric and free; two timers expiring
   together share one ring session and one ten-minute window, and each is stopped
   on its own, because silently resetting both destroys the information "which
   one finished"; auto-silence stops the noise and leaves the row EXPIRED, which
   is the load-bearing difference from an alarm; presets are app-wide in
-  DataStore with out-of-range values **dropped, never clamped**; and the
+  DataStore with out-of-range values dropped, never clamped; and the
   notification's countdown is the platform chronometer, so the service posts
   once per state change rather than once per second for forty-five minutes.
 
   Two things the checklist did not name were changed anyway, and are recorded in
-  `ARCHITECTURE.md`: **"+1 min" on an expired timer now resumes it** with
+  `ARCHITECTURE.md`: "+1 min" on an expired timer now resumes it with
   exactly the extra, in one transaction (M2 left it paused, written before any
-  UI existed and pinned by no test — and resuming is the only way to avoid
-  emitting an intermediate PAUSED frame to the pill and the row); and **the live
-  pill's timer actions now go through `TimerEngine`**, because after M6 there is
+  UI existed and pinned by no test; resuming is the only way to avoid
+  emitting an intermediate PAUSED frame to the pill and the row); and the live
+  pill's timer actions now go through `TimerEngine`, because after M6 there is
   an AlarmManager registration and a service that have to move with the state.
   The pill's contract is otherwise unchanged: M6 *extracted* its precedence into
   `TimerReadings` so the pill, the notification and the ring share one ordering,
-  and `LivePillSelectorTest` passing **unmodified** is the proof.
+  and `LivePillSelectorTest` passing unmodified is the proof.
 
   No schema change (the database stays at v2; the ring session's one volatile
   fact is a DataStore record, which is `PLAN.md` §5's own record-versus-rows
-  split and keeps it out of M10's backup), **no new permission** (a timer never
-  takes over the screen — no full-screen intent, no ring activity), and **no
-  floret-kit change**: the kit earned `CollapsingScaffold`'s
+  split and keeps it out of M10's backup), no new permission (a timer never
+  takes over the screen: no full-screen intent, no ring activity), and no
+  floret-kit change: the kit earned `CollapsingScaffold`'s
   `floatingActionButton` slot at 0.6.0 for exactly this shape of tab, and M6
   consumes it.
 
@@ -318,85 +318,85 @@ Elapsed-realtime anchored.
   "stop all" when several timers are expired, no undo after a delete (traded for
   a confirmation, as with alarms), no ramp on a timer's ring, no presets
   management screen and no editing of `default_timer_duration_millis` or
-  `default_timer_ringtone_uri` — M10's settings screen. `TimerSnapshot.anchorIsStale`
+  `default_timer_ringtone_uri` (M10's settings screen). `TimerSnapshot.anchorIsStale`
   is still not surfaced in the UI. Of `AlarmClock`'s intent contract only the
   in-process hook `ShellNavigation.tabForAction` exists, wired to one action;
   M9 owns the rest. The four new instrumentation tests compile in the gate but
-  have **never run on hardware**, as no device was attached — the same caveat
-  M5's seven carry.
+  have never run on hardware, as no device was attached; M5's seven carry the
+  same caveat.
 
-  Two cases in the new suite are left **red** and are a design conversation
-  rather than a behaviour gap; both are defects in the test, not in the code:
+  Two cases in the new suite are left red. Both are defects in the test, not in
+  the code, so they are a design conversation rather than a behaviour gap:
   `TimerIntentsTest` §5.17 #3 asserts `containsNoDuplicates` over a list that
   contains the *same* `requestCodeFor(REQUEST_PAUSE, 1L)` call twice by
   construction, which no deterministic function can satisfy; and `TimerPrefsTest`
   §5.10 #11 opens a second DataStore over a live file in the same scope, which
-  DataStore refuses by design — as `SettingsPrefsTest` itself documents.
+  DataStore refuses by design, as `SettingsPrefsTest` itself documents.
 
 ### ✅ M7 — Stopwatch
 Start/stop/reset, laps with splits and cumulative times, best/worst lap emphasis.
 Foreground service so it survives backgrounding; laps persist across process
 death. This is where the big-readout typography gets settled for the whole app.
-The post-reboot repair is **not** here — M3 took it (`ARCHITECTURE.md` §5);
+The post-reboot repair is not here: M3 took it (`ARCHITECTURE.md` §5), and
 M7 owns only how the paused result is presented.
 
-  ✅ 968 JVM tests, 125 of them new, and **still no Robolectric** — kept now for
+  ✅ 968 JVM tests, 125 of them new, and still no Robolectric, kept now for
   a third screen and a third service. Everything the tab decides is a pure
   object (`StopwatchFormat`, `StopwatchReadings`, `LapStats`, `StopwatchLaps`,
   `StopwatchNotificationPolicy`, `StopwatchRows`) or a method on the engine or
-  the ViewModel, tested over the **real** `StopwatchRepositoryImpl` across the
+  the ViewModel, tested over the real `StopwatchRepositoryImpl` across the
   real `appendLap` transaction and a real DataStore under a `@TempDir`.
-  `StopwatchService` holds no policy and **no state at all** — not even the
-  timers' one `alreadyAlerted` flag, because nothing here ever alerts — and it
+  `StopwatchService` holds no policy and no state at all (not even the
+  timers' one `alreadyAlerted` flag, because nothing here ever alerts), and it
   has no `delay`. Two new `ArchitectureRulesTest` rules and two extended; the
   four new instrumentation tests bring the compiled total to 36.
 
-  The decisions worth knowing: the foreground service is **`specialUse`**, not
-  `systemExempted`, because a stopwatch is not alarm functionality — it
+  The decisions worth knowing: the foreground service is `specialUse`, not
+  `systemExempted`, because a stopwatch is not alarm functionality. It
   schedules nothing, wakes nothing and rings nothing, and claiming the type
-  would have the app tell the platform something untrue; it holds **no wake
-  lock, ever**, since the elapsed value is derived from a persisted monotonic
-  anchor at read time; the notification is the **platform chronometer counting
-  up**, with its base `now - elapsed` **derived at post time and never stored**,
+  would have the app tell the platform something untrue. It holds no wake
+  lock, ever, since the elapsed value is derived from a persisted monotonic
+  anchor at read time; the notification is the platform chronometer counting
+  up, with its base `now - elapsed` derived at post time and never stored,
   which is how the run record keeps its "no wall-clock field whatsoever" rule;
   its channel is `IMPORTANCE_LOW` and silent, because nothing here ever
   finishes, so there is no alert-once rule and no session window anywhere in the
-  path; the readout is hundredths and it is **two strings**, so the
-  fastest-changing glyphs are not the loudest ones; best and worst need **three**
+  path; the readout is hundredths and it is two strings, so the
+  fastest-changing glyphs are not the loudest ones; best and worst need three
   laps, ties go to the earliest, and all-equal means neither; laps are capped at
-  **999**, guarded in the engine over one `COUNT(*)` so appending never
-  materialises the rows; and the tab ticks at ~60 Hz **only while running**, so
+  999, guarded in the engine over one `COUNT(*)` so appending never
+  materialises the rows; and the tab ticks at ~60 Hz only while running, so
   a paused or idle stopwatch costs nothing.
 
   Three things the checklist did not name were changed anyway, and are recorded
-  in `ARCHITECTURE.md`: **the live pill's stopwatch actions now go through
-  `StopwatchEngine`** (M6 recorded this as knowingly open), with the pill's own
-  contract unchanged and `LivePillSelectorTest` passing **unmodified** as the
-  proof; **`LivePillSelector` was re-pointed at a new pure `StopwatchReadings`**,
+  in `ARCHITECTURE.md`: the live pill's stopwatch actions now go through
+  `StopwatchEngine` (M6 recorded this as knowingly open), with the pill's own
+  contract unchanged and `LivePillSelectorTest` passing unmodified as the
+  proof; `LivePillSelector` was re-pointed at a new pure `StopwatchReadings`,
   the same extraction M6 made for timers, so the pill, the shade and the tab
   cannot answer "what does this read right now" three different ways; and
-  **`ui/theme/Type.kt` stopped being `Typography()`** — tabular figures on the
+  `ui/theme/Type.kt` stopped being `Typography()`: tabular figures on the
   display, headline and title roles, app-wide, with no call-site change
   anywhere, plus `ClockulaReadoutDefaults` naming the three roles a readout uses.
 
   The correctness find: a run that met a reboot mid-lap had `accumulated = 0`
   while its laps still recorded forty seconds, so the honest reading is
-  **floored at the last lap's total** as well as at zero — a readout sitting
+  floored at the last lap's total as well as at zero. A readout sitting
   below a lap the same run printed is not one anyone can believe, and the laps
   are real measurements that are never deleted to tidy the arithmetic. Recorded
   in `ARCHITECTURE.md` §5. The review found the other half of it: the floor has
-  to be **banked, not only displayed** — resuming writes
+  to be banked as well as displayed. Resuming writes
   `accumulated = max(accumulated, lastLapCumulative)`, and pausing and lapping
-  bank the same floored reading — or the record ticks from below its own last
-  lap, the shade's free-running chronometer counts while the tab sits frozen,
-  and the next lap records a cumulative below the previous one. The same review
-  pass moved the engine's verbs onto **the reading's** mode rather than the
-  stored row's, so a stale record's Resume button resumes instead of hitting a
-  silent no-op. `pauseAfterReboot` itself is still untouched.
+  bank the same floored reading; otherwise the record ticks from below its own
+  last lap, the shade's free-running chronometer counts while the tab sits
+  frozen, and the next lap records a cumulative below the previous one. The
+  same review pass moved the engine's verbs onto the reading's mode rather than
+  the stored row's, so a stale record's Resume button resumes instead of hitting
+  a silent no-op. `pauseAfterReboot` itself is still untouched.
 
   No schema change (the database stays at v2; `LapDao` gains one `COUNT(*)` and
-  nothing else), **one** new permission — `FOREGROUND_SERVICE_SPECIAL_USE`, the
-  one that names what the service actually does — and **no floret-kit change**:
+  nothing else), one new permission (`FOREGROUND_SERVICE_SPECIAL_USE`, the
+  one that names what the service actually does), and no floret-kit change:
   the kit stays at 0.6.0, untouched.
 
   Knowingly open: no lap export, sharing, deletion or editing, and no "previous
@@ -409,86 +409,86 @@ M7 owns only how the paused result is presented.
   is still not surfaced, the same answer M6 gave for timers. Of `AlarmClock`'s
   intent contract only the in-process hook `ShellNavigation.tabForAction` grew a
   second action; M9 owns the rest. The four new instrumentation tests compile in
-  the gate but have **never run on hardware**, as no device was attached — the
-  same caveat M5's seven and M6's four carry.
+  the gate but have never run on hardware, as no device was attached; M5's
+  seven and M6's four carry the same caveat.
 
 ### ✅ M8 — World clock
 IANA zone list with search, ICU-localised city and zone display names, offset and
 day-difference relative to home, reorder, home-zone handling. The analog face
-built from `MaterialShapes` / `androidx.graphics.shapes` — the app's one
+built from `MaterialShapes` / `androidx.graphics.shapes` is the app's one
 deliberate showpiece.
 
-  ✅ 1 139 JVM tests, 171 of them new, and **still no Robolectric** — kept now
-  for a fourth screen, and this was the milestone most tempted to break it,
+  ✅ 1 139 JVM tests, 171 of them new, and still no Robolectric, kept now
+  for a fourth screen. This was the milestone most tempted to break it,
   because ICU and `Canvas` both look like they need a device. They do not:
   everything ICU answers is behind `ZoneNames` (faked, with per-method call
   counters and a `failEverything` flag), everything the face draws is
-  `DrawScope` calls over `AnalogFace`'s angles and `DayNight`'s fraction — two
-  pure objects asserted at every minute of the day without a pixel — and
+  `DrawScope` calls over `AnalogFace`'s angles and `DayNight`'s fraction (two
+  pure objects asserted at every minute of the day without a pixel), and
   everything the list and the picker decide is `WorldClockRows`,
   `ZonePickerRows`, `ZoneSearch`, `ZoneComparisons`, `ZoneCatalog` and
-  `WorldClocks`. Every write is a `WorldClockViewModel` method over the **real**
+  `WorldClocks`. Every write is a `WorldClockViewModel` method over the real
   `WorldClockRepositoryImpl` across `FakeWorldClockDao` (so `addIfAbsent` and
   `reorder`'s real transactions run) and a real DataStore under a `@TempDir`.
   Three new `ArchitectureRulesTest` rules; the four new instrumentation tests
   bring the compiled total to 40.
 
-  The decisions worth knowing: **there is no engine and must not be one** — a
+  The decisions worth knowing: there is no engine and must not be one, because a
   world clock owns no AlarmManager slot, no service and no ring session, so a
   fourth engine would be three empty seams and a `Mutex` guarding nothing; the
-  tab reads the **wall clock**, and re-reads both the instant and the device
-  zone on **every tick**, which is what makes `TIME_SET` and `TIMEZONE_CHANGED`
-  free (no new receiver branch); the zone **ids** stay pure (through a new
-  `ZoneProvider.available()`) while only the **names** cross the ICU seam, which
+  tab reads the wall clock, and re-reads both the instant and the device
+  zone on every tick, which is what makes `TIME_SET` and `TIMEZONE_CHANGED`
+  free (no new receiver branch); the zone ids stay pure (through a new
+  `ZoneProvider.available()`) while only the names cross the ICU seam, which
   is one file, `runCatching`-guarded end to end and pinned there by a build
-  rule; the catalog keeps only region-based ids that are **their own canonical
-  id** — so the tzdata's own canonicalisation drops Asia/Calcutta in favour of
-  Asia/Kolkata and no table of ours can rot — unless the canonical id is not on
+  rule; the catalog keeps only region-based ids that are their own canonical
+  id (so the tzdata's own canonicalisation drops Asia/Calcutta in favour of
+  Asia/Kolkata and no table of ours can rot), unless the canonical id is not on
   the device at all, since ICU and tzdata are separately updatable APEX modules
   that can disagree, plus `UTC` by name; search is
-  **word-prefix over folded text**, so "erl" deliberately does not find Berlin;
-  the offset and day are computed **at the instant** from both zones' rules, the
+  word-prefix over folded text, so "erl" deliberately does not find Berlin;
+  the offset and day are computed at the instant from both zones' rules, the
   same discipline `AlarmOccurrences` uses, so Berlin↔Sydney is ten hours in
-  January and eight in July; labels are **data, not strings**, so Kathmandu is
+  January and eight in July; labels are data, not strings, so Kathmandu is
   `Ahead(4, 45)` rather than a signed 285 for a translator to interpret; the
-  cadence is **200 ms** with the state truncated to the second (face) and the
+  cadence is 200 ms with the state truncated to the second (face) and the
   minute (rows) and `distinctUntilChanged` over it; the list is capped at
-  **24**, with the cap spelled out on the screen once it is reached, because
+  24, with the cap spelled out on the screen once it is reached, because
   M3's `ExtendedFloatingActionButton` has no `enabled` to dim; and
-  reduce-motion snaps the morph but **never stops the second hand**,
+  reduce-motion snaps the morph but never stops the second hand,
   because a clock whose second hand stops is a broken clock.
 
   Three things outside the checklist were changed anyway, and are recorded in
-  `ARCHITECTURE.md`: **`ZoneProvider` gained `available()`**, because
+  `ARCHITECTURE.md`: `ZoneProvider` gained `available()`, because
   `ZoneId.getAvailableZoneIds()` at a call site is the same ambient read
-  `PLAN.md` §5 bans for `now()`; **`ui/common/AlarmTimeFormatter.kt` gained
-  `rememberLocalTimeFormatter`** with the existing function delegating to it, so
+  `PLAN.md` §5 bans for `now()`; `ui/common/AlarmTimeFormatter.kt` gained
+  `rememberLocalTimeFormatter` with the existing function delegating to it, so
   M5's "one 12/24-hour formatter" survives a fourth caller instead of growing a
-  second answer; and **`ShellDefaults.EmptyTabScreen` was deleted**, its own
-  KDoc having said it existed only until each of M5–M8 replaced its own tab —
+  second answer; and `ShellDefaults.EmptyTabScreen` was deleted, its own
+  KDoc having said it existed only until each of M5–M8 replaced its own tab;
   the world clock was its last caller.
 
   No schema change at all (the database stays at v2; `WorldClockEntity`, its
-  DAO, its mapper and its repository are not edited), **no new permission and no
-  manifest entry**, **one** new dependency coordinate —
-  `androidx.graphics:graphics-shapes:1.0.1`, pinned to the version that already
-  resolved transitively, because M8 imports that package directly — and **no
-  floret-kit change**: the kit stays at 0.6.0, untouched, with
+  DAO, its mapper and its repository are not edited), no new permission and no
+  manifest entry, one new dependency coordinate
+  (`androidx.graphics:graphics-shapes:1.0.1`, pinned to the version that already
+  resolved transitively, because M8 imports that package directly), and no
+  floret-kit change: the kit stays at 0.6.0, untouched, with
   `ReorderableColumn`, `GroupedSurface`, `FullScreenPicker`, `InlineTextField`
   and `CollapsingScaffold`'s FAB slot already covering the screen.
 
-  Knowingly open: no rename UI for `world_clocks.label` — the column is honoured
-  on read and M10's backup import will carry labels; no automatic "home" row
+  Knowingly open: no rename UI for `world_clocks.label` (the column is honoured
+  on read and M10's backup import will carry labels); no automatic "home" row
   while travelling (a separate feature with its own preference, and the hero
   face already follows the device); no per-city detail screen, map,
-  sunrise/sunset or day-length bar — `DayNight` is a stated convention for a
-  shape morph, not an ephemeris; no live times or long zone names in the picker;
+  sunrise/sunset or day-length bar (`DayNight` is a stated convention for a
+  shape morph, not an ephemeris); no live times or long zone names in the picker;
   no seeded data, so a fresh install really has an empty list; no reordering by
   anything but `sort_order`; and no `MaterialShapes` on the ring screen or timer
-  progress, which `PLAN.md` §8 also sanctions — the build rule makes widening
+  progress, which `PLAN.md` §8 also sanctions; the build rule makes widening
   that allowlist a deliberate edit. The four new instrumentation tests compile
-  in the gate but have **never run on hardware**, as no device was attached —
-  the same caveat M5's seven, M6's four and M7's four carry.
+  in the gate but have never run on hardware, as no device was attached;
+  M5's seven, M6's four and M7's four carry the same caveat.
 
 ### ✅ M9 — System interop
 The full `android.provider.AlarmClock` contract (`PLAN.md` §6): `SET_ALARM`,
@@ -496,103 +496,103 @@ The full `android.provider.AlarmClock` contract (`PLAN.md` §6): `SET_ALARM`,
 next-alarm publishing. Hostile-input validation at the intent boundary.
 - **Tests:** extra validation, including malformed and out-of-range input.
 
-  ✅ 1 420 JVM tests, 281 of them new, and **still no Robolectric** — kept now
+  ✅ 1 420 JVM tests, 281 of them new, and still no Robolectric, kept now
   for a *boundary*, which is the last place a project usually gives in, because
   "it is an `Intent`" sounds like it needs a device. It does not: the door is
   split so that everything which decides is pure (`AlarmClockRequests`,
   `AlarmMatching`, `IntentExtras`, `InteropText`, `InteropDeepLinks`) and the
-  Android half is two policy-free files — a `Bundle` reader and an `Intent`
-  builder. `AlarmClockHandler` orchestrates with **no `android.*` import**, as
-  all three engines do, and is tested over both **real** engines through a new
-  `InteropHarness` — deliberately *not* a composition of the existing harnesses,
-  since each builds a DataStore over the same file name and DataStore refuses a
-  second instance over a live one. Four new `ArchitectureRulesTest` rules and a
-  new `ManifestRulesTest`, because the manifest is where this milestone could be
-  silently wrong and none of it fails a compiler. The five new instrumentation
-  tests bring the compiled total to 45.
+  Android half is two policy-free files: a `Bundle` reader and an `Intent`
+  builder. `AlarmClockHandler` orchestrates with no `android.*` import, as
+  all three engines do, and is tested over both real engines through a new
+  `InteropHarness`. It is deliberately not a composition of the existing
+  harnesses, since each builds a DataStore over the same file name and DataStore
+  refuses a second instance over a live one. Four new `ArchitectureRulesTest`
+  rules and a new `ManifestRulesTest`, because the manifest is where this
+  milestone could be silently wrong and none of it fails a compiler. The five
+  new instrumentation tests bring the compiled total to 45.
 
-  `ACTION_DISMISS_TIMER` — the seventh action, named neither in this checklist
-  nor in `PLAN.md` §6's table — was built anyway: "the full contract" is the
+  `ACTION_DISMISS_TIMER`, the seventh action, named neither in this checklist
+  nor in `PLAN.md` §6's table, was built anyway: "the full contract" is the
   milestone's own first sentence, and shipping six of seven and calling it full
   would be the kind of quiet gap this loop exists to avoid.
 
-  The decisions worth knowing: **one range rule settles every extra** — a value
-  that decides when something will ring in the *future* is **dropped** out of
-  range, a value that modifies what the user is doing *now* is **clamped**, so
+  The decisions worth knowing: one range rule settles every extra. A value
+  that decides when something will ring in the *future* is dropped out of
+  range, and a value that modifies what the user is doing *now* is clamped, so
   hour 25 never becomes an enabled 23:00 alarm while a 1 000-minute snooze
-  becomes the 60 minutes `ClockPrefs` would have allowed; **a `Bundle` is
-  modelled honestly** as `Map<String, Any?>` with four *total* accessors,
+  becomes the 60 minutes `ClockPrefs` would have allowed; a `Bundle` is
+  modelled honestly as `Map<String, Any?>` with four *total* accessors,
   because hostile input is an `Int` where a `String` was documented far more
   often than it is an out-of-range number, and the platform's typed getters
-  cannot tell "absent" from "wrong type"; **`SKIP_UI` never means skip
-  validation** — an incomplete `SET_ALARM` creates the row from the extras that
+  cannot tell "absent" from "wrong type"; `SKIP_UI` never means skip
+  validation, so an incomplete `SET_ALARM` creates the row from the extras that
   *were* valid, at the next whole hour, and lands the user in its editor, since
   M5 locked that the editor edits a persisted row and nothing is ever written
-  and hidden; **`ALARM_SEARCH_MODE_TIME` matches exactly, never "nearest"**, and
+  and hidden; `ALARM_SEARCH_MODE_TIME` matches exactly, never "nearest", and
   an ambiguous 0..12 hour with no `IS_PM` carries *both* readings as candidates
   so the question only reaches the user when the data cannot settle it;
-  **`ALARM_SEARCH_MODE_ALL` never asks** — taken literally the contract's "show
-  the results" would make the mode useless — while every other search with two
+  `ALARM_SEARCH_MODE_ALL` never asks (taken literally, the contract's "show
+  the results" would make the mode useless), while every other search with two
   or more matches opens the milestone's one new surface, an M3 basic dialog with
   a `ListItem` list where tapping a row *is* the answer.
 
-  **A correctness find, fixed here:** the `AlarmClockInfo` **`showIntent`** — the
+  A correctness find, fixed here: the `AlarmClockInfo` `showIntent` (the
   thing the system opens when the user taps the status-bar alarm icon or the
-  lockscreen's next-alarm line — pointed at the *ring screen* with
+  lockscreen's next-alarm line) pointed at the *ring screen* with
   `CLEAR_TASK`, so tapping "my next alarm" opened a ring screen for an alarm
   that was not ringing, which resolved to `Finished` and closed itself. It now
   opens `MainActivity` on the Alarms tab, and a build rule fails the build if
   `AndroidAlarmScheduler` ever names `AlarmRingActivity` again. That intent is
-  literally what "next-alarm publishing" means to a user.
+  what "next-alarm publishing" means to a user.
 
-  **The schema went to v3**: `delete_after_use` on `alarms` and on `timers`, two
+  The schema went to v3: `delete_after_use` on `alarms` and on `timers`, two
   `ALTER TABLE`s in `MIGRATION_2_3`, `3.json` exported and committed, `1.json`
-  and `2.json` untouched. It is not optional polish — the contract says in two
-  places that a `SKIP_UI` alarm or timer should be removed once dismissed, and
-  without it a daily "wake me at 6:30" turns the Alarms tab into a graveyard.
+  and `2.json` untouched. The contract says in two places that a `SKIP_UI`
+  alarm or timer should be removed once dismissed, and without the column a
+  daily "wake me at 6:30" turns the Alarms tab into a graveyard.
   The flag is set only on the `SKIP_UI` create path and honoured inside the two
   engines, under their locks.
 
   Four things outside the checklist were changed anyway, and are recorded in
-  `ARCHITECTURE.md`: **`AlarmEngine` gained `dismissUpcoming(id)` and a
-  `minutesOverride` on `snooze`**, because both move the ring slot, the
+  `ARCHITECTURE.md`: `AlarmEngine` gained `dismissUpcoming(id)` and a
+  `minutesOverride` on `snooze`, because both move the ring slot, the
   auto-silence backstop and the next-alarm registration, and a handler calling
-  three repositories in a row would race a fire broadcast; **`TimerEngine` gained
-  `dismissAllExpired()` and `dismissExpired(id)`** — the first is the "stop all"
+  three repositories in a row would race a fire broadcast; `TimerEngine` gained
+  `dismissAllExpired()` and `dismissExpired(id)` (the first is the "stop all"
   the UI still deliberately does not offer, because that rule was about a thumb
-  on a ring and a programmatic request has stated exactly what it is discarding;
-  **`domain/text/TextFolding` was extracted** and `ZoneSearch` delegates to it,
-  with `ZoneSearchTest` passing unmodified as the proof; and **the shell's
-  `openTab` became `openRequest: ShellRequest?`**, since three of the contract's
+  on a ring and a programmatic request has stated exactly what it is discarding);
+  `domain/text/TextFolding` was extracted and `ZoneSearch` delegates to it,
+  with `ZoneSearchTest` passing unmodified as the proof; and the shell's
+  `openTab` became `openRequest: ShellRequest?`, since three of the contract's
   outcomes are not "select a tab".
 
-  **No new `<uses-permission>`**: the one new permission string is
-  `android:permission` *on the door*, a requirement on the caller. **No new
-  dependency coordinate** and **no floret-kit change** — the kit stays at 0.6.0,
+  No new `<uses-permission>`: the one new permission string is
+  `android:permission` *on the door*, a requirement on the caller. No new
+  dependency coordinate and no floret-kit change; the kit stays at 0.6.0,
   untouched, because the one new surface is material3's own `AlertDialog`.
 
   Knowingly open: no voice-interaction follow-on flows
   (`VoiceInteractor.CompleteVoiceRequest`/`PickOptionRequest`), so
   `android.intent.category.VOICE` is deliberately not declared and Clockula
   accepts a `clockula://` deeplink while publishing none; no "most closely
-  matched" time search; no toast on a `SKIP_UI` write — the status-bar icon is
-  the platform's own receipt; no `delete_after_use` surface in either editor, so
+  matched" time search; no toast on a `SKIP_UI` write (the status-bar icon is
+  the platform's own receipt); no `delete_after_use` surface in either editor, so
   an assistant-set alarm the user edits stays transient, as it does in Google
   Clock; no `EXTRA_MESSAGE` carried into the timer setup panel when no length
-  was given; and `AlarmScheduler.systemNextAlarm()` is still caller-less — it
+  was given; and `AlarmScheduler.systemNextAlarm()` is still caller-less, since it
   belongs to M10's self-check screen. The five new instrumentation tests and the
-  two new migration cases compile in the gate but have **never run on
-  hardware**, as no device was attached — the same caveat M5's seven, M6's four,
-  M7's four and M8's four carry.
+  two new migration cases compile in the gate but have never run on
+  hardware, as no device was attached; M5's seven, M6's four, M7's four and
+  M8's four carry the same caveat.
 
 ### ✅ M10 — Settings, backup, the self-check, and widgets
 - Settings composed from kit components: theme, dynamic colour, language,
   alarm/timer/clock defaults, about + crash reporting.
 - JSON backup export/import via SAF (`PLAN.md` §7), schema documented in
   `docs/BACKUP.md`.
-- The **"why might my alarm not ring?"** self-check screen (`PLAN.md` §4) —
+- The "why might my alarm not ring?" self-check screen (`PLAN.md` §4):
   real device state, deep links to the exact settings pages.
-- Three Glance home-screen widgets — next alarm, timer, clock (`PLAN.md` §9).
+- Three Glance home-screen widgets: next alarm, timer, clock (`PLAN.md` §9).
 - **Tests:** backup round-trip and unknown-field tolerance; self-check rule
   logic per permission/state combination; widget model selection/formatting.
 
@@ -608,13 +608,13 @@ reliability soak across a few real nights. Then 1.0.0.
 
 Deferred deliberately, in rough priority order:
 
-- **Dock / screensaver mode** — a `DreamService` full-screen clock. Cheapest big
+- **Dock / screensaver mode**: a `DreamService` full-screen clock. Cheapest big
   win, and the surface people look at most.
-- **Quick Settings tile** — timer control and next alarm from the shade.
-- **Bedtime / sleep schedule** — wind-down and wake, with DND handoff. A feature
+- **Quick Settings tile**: timer control and next alarm from the shade.
+- **Bedtime / sleep schedule**: wind-down and wake, with DND handoff. A feature
   in its own right, realistically v2.
-- **`core-notification` in floret-kit** — revisit once Clockula's real
+- **`core-notification` in floret-kit**: revisit once Clockula's real
   notification surface is known (`PLAN.md` §3).
-- **Migrate Calendula and Agendula onto `core-prefs` + `core-di`** — tracked in
+- **Migrate Calendula and Agendula onto `core-prefs` + `core-di`**: tracked in
   the kit's roadmap, not here.
-- **Wear OS companion** — unscoped.
+- **Wear OS companion**: unscoped.
diff --git a/fastlane/metadata/android/en-US/full_description.txt b/fastlane/metadata/android/en-US/full_description.txt
index dd8da04..2abce93 100644
--- a/fastlane/metadata/android/en-US/full_description.txt
+++ b/fastlane/metadata/android/en-US/full_description.txt
@@ -4,7 +4,7 @@ It is the third app in the Floret family, after Calendula (calendar) and Agendul
 
 <b>Alarms that actually ring</b>
 
-An alarm app is only worth having if you can trust it. Clockula schedules alarms the way Android intends — as real alarm clocks, exempt from battery saving, visible to the system lock screen and status bar. When something on your device would stop an alarm from ringing, Clockula tells you which setting it is and takes you there, instead of failing silently at 7am.
+Clockula schedules alarms the way Android intends: as real alarm clocks, exempt from battery saving and visible on the lock screen and status bar. When something on your device would stop an alarm from ringing, Clockula tells you which setting it is and takes you there, instead of failing silently at 7am.
 
 <b>Everything you expect</b>
 
@@ -17,6 +17,6 @@ A running timer or stopwatch stays reachable from every tab, so you never lose t
 
 <b>Open, and yours</b>
 
-Clockula speaks Android's standard alarm intents, so your assistant and your automation apps can set alarms and timers in it like any other clock app. Your alarms, timers and clocks export to a documented JSON file whenever you want them, because data you cannot take with you is not really yours.
+Clockula speaks Android's standard alarm intents, so your assistant and your automation apps can set alarms and timers in it like any other clock app. Your alarms, timers and clocks export to a documented JSON file whenever you want them.
 
-No account. No tracking. No ads. Free software under the MIT licence.
+No account, no tracking, no ads. Free software under the MIT licence.