Anthony Ettinger b873c2bf41 Keep what the Bitwarden export actually says (#206) ... Four things the first pass threw away, all of them recorded in the mapping notes from the 2026-09-02 hand conversion and all of them silent. Item ids were regenerated. Bitwarden ids are already UUIDs, so keeping them is what makes a re-import idempotent: run the same export twice and the second run reports its items as already present under "skip", rather than duplicating the entire vault. createItem deliberately refuses a caller-supplied id and always mints a fresh one, so the id is adopted after construction, and only when it really is a UUID. Timestamps were restamped to "now". creationDate and revisionDate are the only record of when a password was last rotated, and overwriting them destroys that permanently. The oldest item in a real export dates to 2018; every one of them would have been dated today. Password history was dropped entirely. It is carried now, newest first, mapping lastUsedDate to changedAt and capped at MAX_HISTORY_ENTRIES. 189 items in a real export have history, so this was not a rare case. URI match rules were hardcoded to "domain". Bitwarden stores them as a number -- 0 domain, 1 host, 2 startsWith, 3 exact, 4 regex, 5 never, with null meaning domain -- and flattening them quietly widens a login pinned to an exact URL, which is a security change rather than a cosmetic one. Verified on the same 4,395-item export: all 4,395 ids carried across, stable across two runs, 189 items with history recovered, and the oldest createdAt still 2018-02-22. That export happens to use domain matching throughout, so the match mapping is covered by tests rather than by it. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>		2026-09-24 04:06:47 -07:00
..
src	Keep what the Bitwarden export actually says (#206)	2026-09-24 04:06:47 -07:00
package.json
tsconfig.json