# TANRAIL ONE — Phase 3.2.3 Core Sales Security Audit

## Audit Overview
An independent security and architecture audit was performed on the Phase 3.2.3 Core Sales Engine. 
The objective was to identify flaws in business unit isolation, inventory consistency, data immutability, and state machine integrity.

A new bespoke test suite (`tests/Feature/Core/Phase323SecurityAuditTest.php`) was authored to actively attempt to breach the boundaries of the architecture.

## Findings

### 1. Finding: Mass-Assignment Status & Total Manipulation
- **Severity**: HIGH
- **Attack Scenario**: A malicious user intercepts an HTTP request updating an Order and injects `status=completed` and `total=0` into the payload. Because standard Laravel controllers often use `$order->update($request->all())`, this bypasses the `OrderService` and instantly marks an order as paid without deducting inventory or recording a payment.
- **Root Cause**: `status`, `subtotal`, `tax_total`, and `total` were present in the `$fillable` array of the `Order` model, making them vulnerable to mass assignment.
- **Affected Files**: `app/Domains/Core/Models/Order.php`, `app/Domains/Core/Services/OrderService.php`
- **Remediation**: REMEDIATED. Removed the vulnerable fields from the `$fillable` array. `OrderService::createDraft()` was refactored to use `forceFill()` to securely seed the initial zero-state without exposing the model to mass assignment attacks.

### 2. Finding: Cross-BU Inventory Location Consistency
- **Severity**: PASS
- **Attack Scenario**: Branch A's `default_sales_location_id` is maliciously updated to point to an Inventory Location belonging to Branch B. When an order is confirmed, the Core Sales engine attempts to deduct stock from BU B on behalf of BU A.
- **Result**: The attack FAILED. The Phase 3.2.2 `InventoryService` correctly identified the Business Unit mismatch between the `Item` (BU A) and the `InventoryLocation` (BU B) and threw an immediate Exception, terminating the Sales transaction and reverting the Order to `DRAFT`. The Core Sales Engine perfectly inherits the strength of the Inventory Core.

### 3. Finding: Negative Payments and Quantities
- **Severity**: PASS
- **Attack Scenario**: An attacker passes `-100` as the payment amount to generate a fraudulent refund, or `-5` as the item quantity to magically add stock.
- **Result**: The attack FAILED. `OrderService` explicitly asserts `$quantity > 0` and `$amount > 0`.

### 4. Finding: State Immutability Destruction
- **Severity**: PASS
- **Attack Scenario**: An attacker attempts to execute `$orderLine->delete()` or `$payment->delete()` directly on the model to erase financial history.
- **Result**: The attack FAILED. The Eloquent Observers attached via the `booted()` method correctly identified the illegal mutation and threw a `RuntimeException`.

## Core Purity Audit
The `app/Domains/Core/` directory was audited for business-specific terminology.
**Result**: PASS. No references to Restaurant, Kitchen, Table, Catering, or Water exist in the Core.

## Performance Review
The architecture avoids N+1 query problems in its critical path. Order Confirmation utilizes a single `lockForUpdate()` query and executes the inventory deduction synchronously. No unnecessary loops or repetitive queries exist in the `OrderService`.

## Conclusion
One HIGH severity vulnerability was discovered and successfully remediated. The system proved incredibly resilient to cross-BU pollution due to the robust foundations built in Phases 2 and 3.2.