Design Rationale — Multi Loc
Non-obvious design choices for the multi_loc module — the WHY behind each decision.
Multi-location (locked 2026-06-09)
Site only in v1.0; inter-site stock transfers deferred to v1.5
Decision: multi_loc contains only site in v1.0. Stock transfer tables, transfer-order workflows, and multi-site fulfillment routing are deferred to v1.5.
Why: Multi-location selling and per-site inventory scoping work with site_id alone. Transfers are a heavier workflow (receiving-side confirmation, in-transit stock, transfer order lifecycle) not needed to launch. Building it now would be speculative.
Rejected: Transfer tables now — premature; adds schema complexity before any tenant has proven the need.
Site access is application-layer, not RLS
Decision: Which sites a user can access is controlled by identity.user_site_assignment checked at the application layer, not by Postgres RLS policies that filter on site_id.
Why: RLS on site_id would require every tenant-scoped query to also filter by site, complicating multi-site reporting and manager-level views. The app layer can enforce site scope where needed while allowing broader reads for aggregate queries.