Masters, instances, and the freeze
How your library and your trips relate — and why editing one never disturbs the other.
Checked against the app on 2026-10-12 (1.1).
| Master | Instance | |
|---|---|---|
| Lives in | your library | one trip or template |
| Created by | seeding, or you adding to the library | making a trip, or adding a row to one |
| Editing it affects | future trips only | that one trip only |
| Deleting it affects | trips: nothing. Templates: the row goes with it (1.1) | that one row |
The one rule
A trip is a frozen snapshot. When you create a trip, the app copies what it needs out of your library and stores it on the trip. From that moment the two are independent:
- Editing a library item does not reach into trips that already exist.
- Editing a trip item does not write back to the library.
- Deleting a library item leaves every existing trip untouched.
This is why you can experiment freely. Nothing you do in a trip can damage your library, and nothing you do in your library can damage a trip you're halfway through packing.
Why it works that way
The obvious alternative — trips reading through to their library item at display time — was tried and abandoned. It produced a crash class in Build 15, and it has a worse conceptual problem: a trip you packed last March would silently rewrite itself when you edited your library this June. A record of what you actually took stops being a record.
The cost is real and worth stating: there is no automatic way to push a trip edit back to your library. If you rename something mid-trip because the library name was wrong, the library stays wrong until you fix it there too.
Templates are not frozen the way trips are
Changed in 1.1 by R188. A trip row is a true instance with its own frozen copy, so deleting the library master it came from leaves the trip untouched. A template row is not: its item is the library item, with five per-template settings layered on top. Delete that item from your library and it leaves every template holding it — the warning counts them before you confirm.
So the freeze protects trips, and only trips. A template follows the library.
The partial exception
One door exists, and it is narrower than most people expect.
Long-press a Pack List row → "Save to Item Library." It mints a new master and re-points that row — and every linked sibling — at it.
Three limits:
- It appears only when the row has no library ancestry at all. A row the library has already seen gets no door.
- It is on the long-press menu only — not on any edit sheet. The moment you tap Save after editing is the moment nothing is offered.
- There is no update path, only add-as-new.
(An explicit, opt-in write-back is designed but not built.)
What carries identity
| Thing | Identified by | Consequence |
|---|---|---|
| Item on a trip | its own instance | two rows with the same name are two rows |
| Group membership | PackGroupRef | duplicate group names are allowed |
| Custom section | its own identity, not its name | renaming doesn't orphan it |
| Library item | name, in several paths | a name collision can merge things you meant to keep apart |
| Library section | its own identity, but its name must be unique (1.1) | two sections cannot share a name; the emoji does not distinguish them |
That last row is the sharp edge. The library treats an item's name as its identity in several places, so "Jacket" added twice may not stay two things.
Kits mint their own items
A kit is not a pointer to shared items. When a kit is used, it mints its own ItemMaster records; the library groups them by name for display. So the same item name can carry a different default quantity in two different kits, and changing one does not change the other.
A customized entry displays as "Customized for [kit name]".
Related: Templates — what they capture · Guide: How the app is organized
More in Reference