# TANRAIL ONE — Core Sales Security & Isolation

## 1. Contextual Access Control
The Sales engine relies strictly on the Phase 2 Context Architecture.
- `Order` models are protected by an `OrderScope` that dynamically filters by `business_unit_id` (via the joined Branch).
- A user operating in Business Unit A can only view, create, or mutate Orders belonging to Branch A.

## 2. Hard Service Boundaries
The `SalesService` (or equivalent `OrderService`) will execute strict assertions matching the remediation applied in Phase 3.2.2.
Before adding an `Item` to an `Order`, the service will assert:
`$item->business_unit_id === $order->branch->business_unit_id`

If this fails, an Exception is thrown. Cross-BU data pollution is prevented at the application boundary, not just the UI or Controller layer.

## 3. Transaction Integrity
Every state change (`DRAFT` to `CONFIRMED`, or Payment Recording) operates inside a database transaction (`DB::transaction`).
If stock is insufficient, the `InventoryService` throws an exception, and the entire Sales transaction rolls back cleanly. No partial orders. No partial payments.

## 4. Immutability & Deletion
- `Order` models cannot be deleted. They can only be `CANCELLED`.
- `OrderLine` models cannot be updated or deleted once the Order transitions out of `DRAFT`. Model-level `booted` events (Observer pattern) will enforce this by throwing an Exception on `updating` or `deleting` events, mirroring the `StockMovement` hardening.
