Inventory tracking — UX direction & IA for Phases 2–5

[MrJarnould]

Following up on the phased inventory plan (#251) with some UX direction that came in from the community. @ETolboom opened a PR on my fork (MrJarnould/nocturne#1) with screenshots and a proof-of-concept demo of how he'd see inventory living in the app. The code itself is throwaway (vibe-coded, his words) but the suggestions are concrete and I think worth talking through before we get to Phase 2.

Opening this here so anyone working on inventory — or thinking about IA more broadly — can weigh in. None of these are decisions, just direction questions.

Information architecture

Today inventory lives under /settings/inventory. ETolboom argues that's the wrong shape — inventory is a working area like Food/Meals, not a config page. His proposal: a top-level Inventory sidebar entry with three subroutes:

• Overview — current on-hand state
• History — closed/expired/wasted items, plus a "See Future Events" toggle for upcoming expirations
• Packing Calculator — the existing /tools/packing page, moved under inventory

The merge of packing with inventory feels right to me — they're the same domain split awkwardly across two locations today. Does that map cleanly onto how Phase 5 (UI polish) is scoped, or does the sidebar restructuring belong somewhere else in the plan?

Per-item Details view

Currently Details is a modal dialog with internal tabs including "Settings". ETolboom suggests:

• Full sub-route (/inventory/[id]) instead of a modal — more canvas, shareable URL
• Replace the Edit button with a settings cog icon in the top-right
• Drop the "Settings" tab in favor of that cog

A separate global History view would coexist with per-item Details — global ledger vs. scoped drill-in. Both useful, complementary.

Seeding & deletion flows

Two smaller UX asks:

• Seeding: instead of bulk-creating everything on setup, present a checklist of suggested items and let users tick what they actually use.
• Deletion: today's flow is Details → Settings → Archive. He proposes Details → Settings → Delete → confirm with a "Keep history?" checkbox (default on). Same data outcome, but the language matches user mental models better.

DeviceEvent → consumable mapping

Phase 1 (currently up as #286) hard-codes the mapping: SensorStart → CGM sensor, SiteChange → Pod/InfusionSet (based on PumpCapability.IsTubeless). Strict allowlist, no heuristics.

ETolboom flagged a concern: different uploaders emit different event types for the same physical action — some send PodChange instead of SiteChange, etc. His suggestion: allow user-configurable mapping (or at least a multi-select per consumable kind). I'd lean toward keeping Phase 1 strict and revisiting in Phase 5 once we have real-world data on what uploaders actually emit, but I'd love a sanity check on that. Continuing this thread on #286.

Where each suggestion lands

Tracking these so nothing gets lost when we get to the relevant phase:

Suggestion	Phase	Notes
Inventory as top-level + subroutes	2 / 5	IA decision at the Phase 2 design step, polish in Phase 5
Packing merged into Inventory	2 / 5	Same
Global History view + future events	3	Future-expiration projection feeds stockout alerts
Per-item Details as a route, not modal	5	UI polish
Settings cog (not Edit button)	5	UI polish
Checklist seeding	2	Setup flow
"Keep history?" delete	2	Destructive-action UX
DeviceEvent mapping policy	1 / 5	Discussion on #286

Happy to hear pushback on any of this. Tagging @ryceg for visibility — no urgency, just want to align direction before Phase 2 work starts.