# Open Questions & Risks — Phase 2

Flagged for awareness before Phase 3 (System Architecture & Database Design) and Phase 4 (Design System & UI Framework) begin. None block Phase 2 — they're deliberate scope calls or decisions deferred to a later phase.

## 1. Ceiling on folding Inventory into Products

`01-information-architecture.md` deliberately folds Inventory into the Products section — stock level and reorder point show inline on the product, with no separate "Inventory" nav item, because a merchant thinks "this product is running low," not "check inventory." This holds well for a single-location merchant with simple stock.

**Needs a decision before Phase 4 designs the Products screens in detail:** at what point (multi-warehouse/multi-location stock, large-scale wholesale operations) does a merchant need a dedicated stock-management view that Products' inline treatment can't serve well? Recommend treating this as a progressive-disclosure case (advanced multi-location view reachable from a product's stock section, per `03-ux-patterns-and-conventions.md` rule 4) rather than adding an eighth top-level nav item, but this should be confirmed, not assumed.

## 2. Settings scope creep risk

Settings is the one IA section explicitly acknowledged as carrying necessary technical configuration (payments, shipping, tax, staff, notifications, content). It's the most likely section to become a dumping ground for "things that don't fit elsewhere" as the product grows.

**Recommendation for Phase 4:** Settings needs its own internal organization discipline (grouped by merchant concern — "Getting paid," "Getting orders to customers," "Who can access this store" — not an alphabetical settings list) decided explicitly when the design system takes this section on, not left to accumulate ad hoc.

## 3. Automation suggestion density / fatigue cap

`03-ux-patterns-and-conventions.md` rule 1 defines the shape of a single suggestion, but not how many can appear at once. Given the automation catalog is large (`../architecture/01-product-vision.md` lists 20+ distinct automated behaviors), Home and Products could plausibly surface many suggestions simultaneously for a merchant with a large, imperfect catalog.

**Needs a decision:** a cap and prioritization rule for how many suggestions surface at once (e.g., Home shows at most 5, ranked by estimated impact), so the "coaching" experience doesn't degrade into the "wall of charts" the product explicitly rejects. This is a Merchant Health / Automation Engine ranking concern as much as a UX one — worth resolving jointly with Phase 3.

## 4. Mobile navigation pattern

The seven-item sidebar in `01-information-architecture.md` is described in desktop terms. Deferred to Phase 4: whether mobile/tablet uses a bottom tab bar, a collapsible drawer, or a different pattern entirely, and whether all seven sections get equal mobile prominence or Home/Orders take priority as the most likely on-the-go tasks.

## 5. Staff permission granularity vs. module invisibility

User Management (folded into Settings) needs a permission model, but the "merchant never sees module boundaries" constraint (`../architecture/06-open-questions.md` item 1) means permissions can't just be "can access Orders module, Catalog module, etc." mapped 1:1 to backend modules — that would leak internal structure into a merchant-facing (if staff-facing) surface.

**Needs a decision in Phase 3:** design the permission model around merchant-legible roles (e.g., "Store Manager," "Order Fulfillment," "Marketing") that may span or partially cover multiple backend modules, rather than a permission checkbox per module.

## 6. Global search scope

`01-information-architecture.md` lists a global admin search spanning orders, products, and customers. Not yet decided: whether this expands to campaigns, reports, or settings pages themselves (a "search for a setting" pattern common in mature admin products), and whether search results are ranked/scoped differently for a large catalog vs. a small one.

**Recommendation:** start with orders/products/customers only (matches the highest-frequency lookup needs from `02-core-user-flows.md`); revisit expanding scope only if usage data justifies it post-launch — consistent with "opinionated defaults over endless customization."

---

**Status:** All six items are informational scope calls, not blockers. Items 1 and 5 should be resolved before Phase 3 finalizes the Products/Inventory and User Management module interfaces. Items 2 and 4 are Phase 4 design-system concerns. Item 3 needs joint resolution between Phase 3 (ranking logic) and Phase 4 (display cap). Item 6 has a default recommendation and can proceed as stated unless the user wants a different starting scope.