| 2026-06-04 | `7e3b997` | Avoid summary full scans when delta safely replaces extremes. | Follow-up after `d4de48c` still showed `SummedFinalizeElapsed: 9.3s`, with Heart Rate finalize at `5.0s` despite only `4` Heart Rate delta events. `markVerification` already tries to update type summaries incrementally, but it fell back to a full visible-row aggregate scan whenever a removed row matched the previous earliest/latest/max, even if the same delta added a row that safely preserved or extended that extreme. The fallback is now narrower: full scan is still used when an extreme becomes unknown, but not when added rows replace the removed earliest/latest/max with an equivalent or stronger value. Follow-up report with `reportSchemaVersion: 3` and `buildFingerprint: 1.0(1)-1780603665-92064` completed in `21.0s`, with `127/127` complete, `CaptureModes: unchangedDelta=121, delta=6`, and `DeltaEvents: 20`. This was effectively flat versus the `d4de48c` report: wall `21.1s -> 21.0s`, processing `7.8s -> 7.4s`, finalize `9.3s -> 9.4s`, and Heart Rate finalize `5.0s -> 4.8s` while Heart Rate had `7` delta events. Conclusion: this optimization did not materially move the bottleneck; either the safe-extreme case did not trigger or type-summary fallback is no longer the dominant finalize cost. |

 | 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. |

 ## Current Diagnosis

   then rebuilds affected buckets; distinguish copy cost from affected-bucket

   rebuild cost before adding new SQLite indexes, because first-import reports

   show insert/index overhead is already the dominant large-database risk.

 - 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.

 9. Investigate replacing legacy compact `recordArchiveData` delta rebuild with

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

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

         )

         """, db: db)

         try execute("CREATE INDEX IF NOT EXISTS idx_sample_versions_sample ON sample_versions(sample_id)", db: db)

         try execute("DROP INDEX IF EXISTS idx_sample_versions_time", db: db)

         try execute("""

         CREATE TABLE IF NOT EXISTS sample_observation_events (

                 CAST(((v.start_date + ?) / 86400) AS INTEGER) * 86400 - ? + 86400 AS bucket_end,

                 v.numeric_value,

                 v.source_revision_id

             JOIN sample_visibility_ranges r INDEXED BY idx_visibility_sample_open_version

              AND r.last_observation_id IS NULL

               AND v.start_date < ?

         )

         SELECT

             bucket_start,

             sqlite3_bind_double(statement, 2, Double(secondsFromGMT))

             sqlite3_bind_double(statement, 3, Double(secondsFromGMT))

             sqlite3_bind_double(statement, 4, Double(secondsFromGMT))

             for (index, bucketStart) in bucketStarts.enumerated() {

                 sqlite3_bind_double(statement, Int32(index + 8), bucketStart)

             }