Fall-alarm countdown

[strzyzkat]

Proposed Task Name

Rebuild the fall-alarm countdown and its contact-escalation ladder

Domain

Framework

Tags

coroutines, foreground-service, lifecycle, process-death, testing

1. Problem Statement

Guardian is a personal-safety app for older people living alone. It watches the accelerometer,
gyroscope and barometer in a foreground service, and when it decides someone has fallen it puts a
full-screen countdown on the phone. If the wearer taps cancel, nothing further happens. If the
countdown runs out, every emergency contact they configured gets an SMS with the incident details
and a location, and each contact is retried until it is reached or has failed for good.

Today the detection half works and the response half does not. A confirmed fall raises no
countdown, no contact is ever messaged, and an incident that was mid-countdown when the process
died comes back as if nothing had happened.

The interfaces are all still in place — CountdownListener, IncidentDispatcher, the Hilt
modules that bind them, the SMS channel, the siren, the speech and vibration listeners, and the
persistence layer that records what was sent. What is missing is the state machine that runs the
countdown and the ladder that turns its expiry into delivered messages.

2. Android Environment & Constraints (Optional)

• targetSdk 35 · compileSdk 35 · minSdk 26
• AGP 8.13.2 · Gradle 8.14 · Kotlin 2.2.20 · JDK 17
• 21-module Gradle build with convention plugins in an included build
• Hilt for DI; coroutines throughout, with injected dispatchers, an injected TimeSource and an
  injected Scheduler — the code under test never reads the system clock
• JVM and Robolectric unit tests only. No emulator, no instrumentation, no /dev/kvm

3. Reference Solution Plan

Three files in emergency/dispatch. CountdownSession.kt, the coroutine facade the UI and the
service both drive, stays in place and constructs the controller — so the solution has to satisfy an
existing caller rather than design its own entry point.

• src/main/kotlin/.../emergency/countdown/CountdownController.kt — the countdown state machine:
  phases, refusals, cancellation that must not let an already-scheduled expiry fire, and resume
  after a process restart
• src/main/kotlin/.../emergency/dispatch/DispatchCountdownListener.kt — turns countdown events
  into dispatch commands on a channel, holds a wakelock across the attempt, and sends a follow-up
  when a better location fix arrives
• src/main/kotlin/.../emergency/dispatch/CompositeEmergencyDispatcher.kt — the ladder: ordered
  targets, per-round backoff, permanent versus retryable outcomes, and a per-incident cooldown so
  a second fall does not re-alert the same contacts

4. Verification & Strategy

16 test files across :emergency:dispatch and :service:monitor fail on the before commit and
pass on the after commit — measured, 63 failures in the first module and 95 in the second. The
remaining 785 tests per build variant in those same two modules are the regression net, so an
agent that gets the ladder working by breaking incident persistence or the self-test fails.

The tests drive public seams that exist in the before commit — CountdownController,
CountdownListener, IncidentDispatcher, DispatchPolicy, RecordedDispatch — and assert on
emitted callbacks and recorded dispatches rather than on internal structure, so an implementation
that decomposes the problem differently still passes.

Determinism comes from the code under test rather than from the tests: VirtualClock for time, an
injected Scheduler for ticks and expiry, and StandardTestDispatcher with runTest for
coroutines. There is no real time, no Thread.sleep, no network and no emulator anywhere in the
graded set.

The verifier discards the agent's edits to both modules' test source sets before applying the
hidden tests, which covers the two shared fixtures the graded tests read.

5. Complexity & Difficulty

Roughly 40 hours for a senior Android developer:

Step	Hours
Countdown state machine: phases, refusals, cancellation generations	10
Scheduler-driven ticks and expiry that must not fire after a cancel	6
Dispatch ladder: ordering, per-round backoff, permanent versus retryable	8
Per-incident cooldown and the local-alarm exemption	4
Sizing the wakelock hold against the ladder's worst case	3
Resume after process death	5
Keeping the four service-module call sites and their tests green	4

The difficulty is in the interaction rather than in either piece. My prediction is that a model
writes a plausible countdown and a plausible retry loop and then fails where they meet: a cancel
that arrives while the ladder is asleep in a backoff, a second fall inside the cooldown window, or
a resume that restarts the countdown from its full length instead of from what was left.

6. Additional Information (Optional)

No response

[github-actions[bot]]

📋 Task Proposal Rubric Review

Recommendation: 🟢 Strong Accept

Full Review

[Verifiable]: Pass
The proposal provides a clear verification strategy using 16 test files across two specific modules (:emergency:dispatch and :service:monitor). It explicitly mentions 158 failing tests that must pass in the "after" state. The use of a VirtualClock, an injected Scheduler, and StandardTestDispatcher ensures deterministic execution of coroutine-heavy logic, which is critical for avoiding flaky tests in a bench environment.

[Well-Specified]: High
The problem statement is excellently detailed. it clearly defines the business logic (fall detection response), the current broken state (missing countdown and dispatch logic), and the persistence requirements (process-death resilience). It identifies the specific interfaces (CountdownListener, IncidentDispatcher) and the Hilt-driven architecture the agent must work within. This mirrors a professional-grade technical specification or a complex GitHub issue.

[Solvable]: Pass
The task provides a clear reference solution plan involving three specific files. It acknowledges that the entry points (call sites) already exist and the agent must satisfy existing signatures. The environment is modern (SDK 35, Kotlin 2.2.20) and the build constraints are explicitly listed, suggesting a fully functional "before" state is ready.

[Difficult]: High
This task is significantly more difficult than standard UI or simple logic tasks. It requires a senior developer to manage a complex state machine that handles:

1. Concurrency and race conditions (e.g., cancellation during a dispatch backoff).
2. Process lifecycle/death (restoring state from persistence).
3. Advanced coroutine patterns (tick/expiry logic with injected time).
4. Power management (wakelocks during the dispatch ladder).
   The estimate of 40 hours is realistic for a human developer to get all 158 tests passing while maintaining the integrity of the 785 regression tests.

[Realistic and Valuable]: High
The scenario—a personal safety app for seniors—is a high-stakes, real-world application of Android technology. The technical challenges (foreground services, reliable background processing, and persistent state machines) are standard requirements for enterprise-grade safety or medical software.

[Outcome-Verified]: Pass
The task focuses on behavioral outcomes (emitted callbacks, recorded dispatches, and SMS delivery outcomes) rather than specific code implementation. It allows the agent flexibility in internal decomposition while enforcing modern practices (Hilt, Coroutines) and includes a robust anti-cheat mechanism by discarding agent-modified tests.

Decision: Strong Accept

🤖 This is an automated recommendation for a human maintainer — not a final decision. Based on rubrics/task-proposal-rubric.md.