# Phase 3 – Boot-Time Recovery Verification

**Plugin:** Daily Notification Plugin  
**Scope:** Boot-Time Recovery (Recreate Alarms After Reboot)  
**Related Docs:**
- `android-implementation-directive-phase3.md`
- `PHASE3-EMULATOR-TESTING.md`
- `test-phase3.sh`
- `000-UNIFIED-ALARM-DIRECTIVE.md`

---

## 1. Objective

Phase 3 confirms that the Daily Notification Plugin:

1. Reconstructs all daily notification alarms after a **full device reboot**.
2. Correctly handles **past** vs **future** schedules:
   - Past: mark as missed, schedule next occurrence
   - Future: simply recreate alarms
3. Handles **empty DB / no schedules** without misfiring recovery.
4. Performs **silent boot recovery** (no app launch required) when schedules exist.
5. Logs a consistent, machine-readable summary:
   - `scenario`
   - `missed`
   - `rescheduled`
   - `verified`
   - `errors`

Verification is performed via the emulator harness:

```bash
cd test-apps/android-test-app
./test-phase3.sh
```

---

## 2. Test Matrix (From Script)

| ID  | Scenario                                | Script Test                                      | Expected Behavior                                                                                                        | Result | Notes |
| --- | --------------------------------------- | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ | ------ | ----- |
| 3.1 | Boot with Future Alarms                 | TEST 1 – Boot with Future Alarms                 | `scenario=BOOT`, `rescheduled>0`, `errors=0`; alarms present after boot                                                  | ☐      |       |
| 3.2 | Boot with Past Alarms                   | TEST 2 – Boot with Past Alarms                   | `missed>=1` and `rescheduled>=1`, `errors=0`; past schedules detected and next occurrences scheduled                     | ☐      |       |
| 3.3 | Boot with No Schedules (Empty DB)       | TEST 3 – Boot with No Schedules                  | Either no recovery logs **or** explicit "No schedules found/present" or `scenario=NONE` with `rescheduled=0`, `errors=0` | ☐      |       |
| 3.4 | Silent Boot Recovery (App Never Opened) | TEST 4 – Silent Boot Recovery (App Never Opened) | `rescheduled>0`, alarms present after boot, and no user launch required; `errors=0`                                      | ☐      |       |

Fill **Result** and **Notes** after running `test-phase3.sh` on your baseline emulator/device.

---

## 3. Expected Log Patterns

The script filters logs with:

```bash
adb logcat -d | grep "DNP-REACTIVATION"
```

### 3.1 Boot with Future Alarms (3.1 / TEST 1)

* Typical logs:

```text
DNP-REACTIVATION: Starting boot recovery
DNP-REACTIVATION: Loaded <N> schedules from DB
DNP-REACTIVATION: Rescheduled alarm: daily_<id> for <time>
DNP-REACTIVATION: Boot recovery complete: missed=0, rescheduled=<r>, verified=0, errors=0
```

* The script interprets this as:
  * `scenario = BOOT` (via "Starting boot recovery" or "boot recovery" text or `Detected scenario: BOOT`)
  * `rescheduled > 0`
  * `errors = 0`

### 3.2 Boot with Past Alarms (3.2 / TEST 2)

* Typical logs:

```text
DNP-REACTIVATION: Starting boot recovery
DNP-REACTIVATION: Loaded <N> schedules from DB
DNP-REACTIVATION: Marked missed notification: daily_<id>
DNP-REACTIVATION: Rescheduled alarm: daily_<id> for <next_time>
DNP-REACTIVATION: Boot recovery complete: missed=<m>, rescheduled=<r>, verified=0, errors=0
```

* The script parses `missed` and `rescheduled` and passes when:
  * `missed >= 1`
  * `rescheduled >= 1`
  * `errors = 0`

### 3.3 Boot with No Schedules (3.3 / TEST 3)

Two acceptable patterns:

1. **No `DNP-REACTIVATION` logs at all** → safe behavior
2. Explicit "no schedules" logs:

```text
DNP-REACTIVATION: ... No schedules found ...
```

or a neutral scenario:

```text
DNP-REACTIVATION: ... scenario=NONE ...
DNP-REACTIVATION: Boot recovery complete: missed=0, rescheduled=0, verified=0, errors=0
```

The script passes when:

* Either `logs` are empty, or
* Logs contain "No schedules found / present" with `rescheduled=0`, or
* `scenario=NONE` and `rescheduled=0`.

Any `rescheduled>0` in this state is flagged as a potential boot-recovery misfire.

### 3.4 Silent Boot Recovery (3.4 / TEST 4)

* Expected:

```text
DNP-REACTIVATION: Starting boot recovery
DNP-REACTIVATION: Loaded <N> schedules from DB
DNP-REACTIVATION: Rescheduled alarm: daily_<id> for <time>
DNP-REACTIVATION: Boot recovery complete: missed=0, rescheduled=<r>, verified=0, errors=0
```

* After reboot:
  * `count_alarms` > 0
  * User **did not** relaunch the app manually

Script passes if:

* `rescheduled>0`, and
* Alarm count after boot is > 0, and
* Boot recovery is detected from logs (via "Starting boot recovery"/"boot recovery" or scenario).

---

## 4. Latest Known Good Run (Template)

> Fill this in after your first clean emulator run.

**Environment**

* Device: Pixel 8 API 34 (Android 14)
* App ID: `com.timesafari.dailynotification`
* Build: Debug `app-debug.apk` from commit `<GIT_HASH>`
* Script: `./test-phase3.sh`
* Date: 2025-11-XX

**Observed Results**

* ☐ **3.1 – Boot with Future Alarms**
  * `scenario=BOOT`
  * `missed=0, rescheduled=<r>, errors=0`

* ☐ **3.2 – Boot with Past Alarms**
  * `missed=<m>=1`, `rescheduled=<r>≥1`, `errors=0`

* ☐ **3.3 – Boot with No Schedules**
  * Either no logs, or explicit "No schedules found" with `rescheduled=0`

* ☐ **3.4 – Silent Boot Recovery**
  * `rescheduled>0`, alarms present after boot, app not opened

**Conclusion:**

> Phase 3 **Boot-Time Recovery** is successfully verified on emulator using `test-phase3.sh`. This is the canonical baseline for future regression testing and refactors to `ReactivationManager` and `BootReceiver`.

---

## 5. Overall Status

> Update once the first emulator run is complete.

* **Implementation Status:** ☐ Pending / ✅ Implemented (Boot receiver + `runBootRecovery`)
* **Test Harness:** ✅ `test-phase3.sh` in `test-apps/android-test-app`
* **Emulator Verification:** ☐ Pending / ✅ Completed

Once all test cases pass:

> **Overall Status:** ✅ **VERIFIED** – Phase 3 boot-time recovery is implemented and emulator-tested, aligned with `android-implementation-directive-phase3.md` and the unified alarm directive.

---

## 6. Related Documentation

- [Phase 3 Directive](../android-implementation-directive-phase3.md) - Implementation details
- [Phase 3 Emulator Testing](./PHASE3-EMULATOR-TESTING.md) - Test procedures
- [Phase 1 Verification](./PHASE1-VERIFICATION.md) - Prerequisite verification
- [Phase 2 Verification](./PHASE2-VERIFICATION.md) - Prerequisite verification
- [Plugin Requirements](./03-plugin-requirements.md) - Requirements this phase implements
- [Platform Capability Reference](./01-platform-capability-reference.md) - OS-level facts

---

**Status**: ☐ **PENDING** – Phase 3 implementation and testing pending  
**Last Updated**: November 2025