future-plans: migrate to integer IDs via explicit safe migration tool

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

future-plans.md

@@ -76,10 +76,25 @@ review:
 #### Component IDs in dropdowns and lists
 The component selector dropdown (e.g. in the inventory entry dialog) only shows the
 display name, which is ambiguous when multiple components share a name. Should also
-show the component ID. Ties in with the question of whether components should have
-user-assignable short IDs (like a part number or internal ref) rather than the
-current auto-generated timestamp+random strings. A short sequential or user-defined
-ID would be far more readable in dropdowns, exports, and URLs.
+show the component ID.
+
+#### Migrate to integer IDs
+Current IDs are timestamp-base36 + random chars. Replace with plain integers
+(auto-incrementing). Benefits: human-readable, shorter in URLs, sortable by creation
+order, easier to reference verbally.
+
+Migration must be done as an explicit standalone tool (`tools/migrate-ids.mjs` or
+similar) that:
+1. Reads the current database
+2. Builds an old→new ID mapping for all entity types (components, fields, inventory
+   entries, grids, PDFs, etc.)
+3. Rewrites all references throughout the data (e.g. inventory entries reference
+   component IDs, components reference field IDs, file_ids arrays, etc.)
+4. Writes a new database file without touching the original until explicitly
+   confirmed
+5. Keeps a mapping log so the migration is auditable and reversible
+
+Should not be run automatically — operator invokes it deliberately after backing up.
 
 #### Component list sorted by display name
 The component left pane list is currently sorted by base name. It should sort by