Flutter Hive Persistence Engineering

Mission

Treat Hive/Hive CE persistence as a long-lived data contract, not a transient implementation detail. Use this loop:

Classify data/access pattern
→ inspect deployed storage contract
→ choose storage/box/model strategy
→ design compatibility + recovery
→ implement smallest safe change
→ test old persisted data + failures
→ measure startup/memory/storage/write cost

Highest-priority invariant:

Persisted data is part of the application's long-lived external contract. A Dart model change is not safe merely because the new code compiles.

Operating Rules

1. Inspect pinned package versions and existing storage before editing persistence.
2. Treat box names, key formats, type IDs, field IDs, encryption configuration, and generated schema metadata as migration-sensitive.
3. Never reuse a retired type ID for a different persisted type.
4. Never renumber existing field IDs for aesthetics or source-order cleanup.