# Baseline failures — recorded 2026-08-01, BEFORE any WP

Command:
```
/opt/cpanel/ea-php82/root/usr/bin/php -d memory_limit=1G vendor/bin/pest \
  --filter='ProductApiTest|ProductUnitApiTest|SettingApiTest|SettingPermissionEnforcementTest|BrandApiTest|UnitConversionServiceTest|UnitBaseValidationTest|POSTerminalApiTest'
```
(`ProductApiTest` also substring-matches `StorefrontProductApiTest`.)

**Result: `Tests: 14 failed, 174 passed (844 assertions)` — 230s**

A WP is green when it introduces **zero new** failures against this list. Do **not** attempt to fix these.

## The 14

### 1 — in the settings area (⚠️ read this before reviewing WP1/WP3)

| Test | Failure |
|---|---|
| `Modules\Core\tests\Feature\SettingPermissionEnforcementTest` → *the shipped GL account-mapping settings declare their permission* | `Failed asserting that null is identical to 'accounting.settings.manage'` at `SettingPermissionEnforcementTest.php:99` — `setting_definitions.permission` is `null` for `accounting.ar_parent_account`. |

**Diagnosis:** a seeding/backfill gap in the sqlite test database, not a code defect. The test's own comment says the value is *"Seeded by `SettingDefinitionSeeder` + backfilled by the WP5 migration"* — under `RefreshDatabase` on sqlite that backfill evidently does not land.

**Why it matters here:** it sits in exactly the area WP1 and WP3 touch. It is **pre-existing** — it fails on untouched code. Do not credit a WP for fixing it and do not blame a WP for it. If a WP happens to make it pass, say so explicitly rather than quietly.

### 13 — WebStore storefront (unrelated)

All in `Modules\WebStore\tests\Feature\StorefrontProductApiTest`, all HTTP **404** — the storefront routes are gated off in the test environment:

- can list …
- can search …
- can filter …
- can sort …
- can get …
- can include …
- `on_sale` returns only products whose offer is running today [ISS-2026-9331]
- without `on_sale` the catalogue is unfiltered [ISS-2026-9331]
- (+ the remaining cases in the same file)

## Separate pre-existing blocker — FIXED before baselining

The suite was returning **exit 255 with zero output under every filter**: `makeOrder()` was declared at top level in **both** `Modules/WebStore/tests/Feature/LoyaltyPointsTest.php:54` and `Modules/Production/tests/Feature/ProductionConfirmationsTest.php:157`. Pest loads every test file into one process ⇒ fatal redeclare.

Fixed by renaming the WebStore helper to `makeLoyaltyOrder` (9 call sites, one file) plus a comment recording the trap. **Fourth occurrence** in this project (Clinic, Inventory, POS, WebStore↔Production).

Until this was fixed, **nobody could run any test at all** and the failure looked like silence.