| 2026-06-04 | `f73f076` | Add archive finalization phase timings to diagnostics. | The post-`7e3b997` report proved the top-level `finalizeElapsed` bucket was too opaque for the next optimization. Diagnostics now split finalization into event-count/previous-summary lookup, type-summary work, daily-aggregate work, observation-type-run update, and residual other time. Follow-up report with `reportSchemaVersion: 3` and `buildFingerprint: 1.0(1)-1780606903-92064` completed in `22.6s`, with `127/127` complete, `CaptureModes: unchangedDelta=119, delta=8`, and `DeltaEvents: 27`. Finalization was `10.3s`: event-count/previous-summary lookup `1.8s`, type-summary `0.0s`, daily aggregates `7.3s`, run update `0.0s`, and other `1.2s`. Heart Rate had `9` delta events and spent `4.8s` finalizing, of which `3.8s` was daily aggregate work and `0.9s` was event-count/previous-summary lookup. Conclusion: the remaining finalize bottleneck is not type-summary fallback; it is changed-type daily aggregate maintenance, especially Heart Rate. |

 | 2026-06-04 | older build / schema v2 | Captured large first-import baseline on a bigger device database. | Initial full-profile snapshot on an older build completed with `127/127` metrics and `8,421,978` records, but it used `reportSchemaVersion: 2` and has no build fingerprint. Treat it as a volume/shape baseline, not a precise current-build comparison. Wall clock was `166m10s`; summed fetch `5m19s`, processing `20m29s`, insert `137m31s`, finalize `1m53s`. The high-volume types dominated: Heart Rate `2,225,738` records and `46m57s` total (`39m16s` insert), Active Energy `1,914,449` records and `41m35s` total (`35m21s` insert), another high-volume type around `2,007,920` records and `41m20s` total (`34m29s` insert), and Basal Energy `1,116,074` records and `21m37s` total (`17m48s` insert). Conclusion: for clean first imports on very large databases, SQLite insert/index/write-path cost remains the central risk; incremental daily-aggregate optimization should not add first-import indexes without measurement. |

 | 2026-06-05 | `6041bac` | Split daily aggregate finalization timings. | The first finalization phase report identified daily aggregate work as the remaining changed-type bottleneck, but `finalizeDailyAggregateElapsed` still mixed affected-bucket lookup, previous aggregate copy, destination delete, affected-bucket rebuild, replacement insert, and residual SQL/transaction overhead. Diagnostics now emit aggregate and per-type daily subphase fields: bucket lookup, copy, delete, rebuild, insert, and other. Follow-up report with `buildFingerprint: 1.0(1)-1780618540-92064` completed in `23.5s`, with `127/127` complete, `CaptureModes: unchangedDelta=118, delta=9`, and `DeltaEvents: 97`. Finalization was `10.5s`, daily aggregate work was `7.4s`, and daily rebuild alone was `6.9s`; daily copy was only `0.5s`. Heart Rate had `40` delta events and spent `4.8s` finalizing, of which `3.8s` was daily aggregate rebuild. Conclusion: copying previous materialized daily rows is not the bottleneck; affected-bucket rebuild scans are. |

 ## Current Diagnosis

   `3.8s` rebuilding affected daily buckets. The next experiment changes the

   affected-bucket rebuild query shape so it starts from time-ranged

   `sample_versions` instead of all samples of the type.

 - A large older-build first import on an `8.4M`-record database completed but

   took `166m10s`, with `137m31s` summed insert time. This confirms that full

   authorized backup volume can be much larger than the original 15-type test

    identity unless the build provenance is otherwise certain. `sourceCommit`

    and `sourceDirty` are useful when present, but may be `unknown` for normal

    Xcode test installs.

    a SQLite-derived capture-state/hash path. The current repeated full-profile

    reports still spend about `4s` processing Heart Rate for tiny deltas because

    the Swift compact archive is decoded and rewritten for the whole 900k-row

    type.

    Compare slow empty types across reports before changing behavior; any skip or

    lower-frequency strategy must preserve the promise that full authorized

    backup can notice newly appearing data.

    - keep archive semantics unchanged;

    - only relax work that can be safely reconstructed or validated;

    - re-enable normal idempotent paths for incremental observations.

 ## Verification Checklist For Each Optimization

     ) throws -> (appeared: Int, disappeared: Int, representationChanged: Int) {

         let sql = """

         SELECT e.event_kind, COUNT(*)

         GROUP BY e.event_kind

         """

         return try withStatement(sql, db: db) { statement in