mikael-lovqvists-claude-agent/electronics-inventory
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

future-plans: clarify logical cell grouping is for batch overflow, not large components

Browse Source 
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
mikael-lovqvists-claude-agent
2026-03-23 00:24:59 +00:00
parent 1bebf7a12b
commit 27bf6043d3
1 changed files with 6 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
future-plans.md
View File

@@ -229,10 +229,12 @@ different column count and cell size. Example: 5 rows of 5 small columns, then 1
row of 4 medium columns, then 1 row with a single large drawer. Cells are not row of 4 medium columns, then 1 row with a single large drawer. Cells are not
multiples of a common base — the sections are structurally independent. multiples of a common base — the sections are structurally independent.
**Logical merging (multi-select):** Independent of the above, a user should be able **Logical merging (cell groups):** Independent of physical layout, a user should be
to designate several cells as one logical storage location (e.g. a large component able to group several cells into a single named logical location. The motivating
that physically spans 3 cells). This is a storage/inventory concern rather than a case is a batch of 50 components that won't fit in one cell — they spill across 3
grid layout concern. cells, but you want one inventory entry saying "these cells together hold this
batch", not three separate entries to keep in sync. This is purely a
storage/inventory concern, not a grid layout concern.
**Open question — architecture:** Should this be: **Open question — architecture:** Should this be:
1. A single generic nested/hierarchical grid model flexible enough to encode both 1. A single generic nested/hierarchical grid model flexible enough to encode both