future-plans: bins as items, inventory type-specific views
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -341,6 +341,24 @@ browsing pages in the lightbox.
|
|||||||
|
|
||||||
## Inventory
|
## Inventory
|
||||||
|
|
||||||
|
### Bins as a storage item type
|
||||||
|
Support bins (physical containers, boxes, bags, reels, etc.) as inventory items in
|
||||||
|
their own right — not just as locations. A bin can hold components but is itself a
|
||||||
|
trackable thing. Bins may contain non-electronic items.
|
||||||
|
|
||||||
|
### Inventory type-specific views
|
||||||
|
Currently the inventory and components views are tightly coupled to the assumption
|
||||||
|
that everything is an electronic component. Long term, the system should support
|
||||||
|
multiple item types (components, bins, tools, materials, etc.) with:
|
||||||
|
- A generic "everything" view showing all inventory regardless of type
|
||||||
|
- Type-specific views (e.g. the current components view) that filter and present
|
||||||
|
items with type-relevant fields and UI
|
||||||
|
- The current components section becomes one such type-specific view rather than
|
||||||
|
the only view
|
||||||
|
|
||||||
|
This is a significant architectural change — not needed now, but should inform data
|
||||||
|
model decisions so we don't paint ourselves into a corner.
|
||||||
|
|
||||||
### Inventory URL reflects selected entry
|
### Inventory URL reflects selected entry
|
||||||
Similar to how components now reflect `/components/:id` in the URL, inventory
|
Similar to how components now reflect `/components/:id` in the URL, inventory
|
||||||
entries have no URL state — refreshing loses context.
|
entries have no URL state — refreshing loses context.
|
||||||
|
|||||||
Reference in New Issue
Block a user