# Archive

Delivered work, kept for the record. Nothing here is current.

## WBA / `WebEntry` assessments — 2026-05-21

| Document | What it covered |
|---|---|
| [`code-critique.md`](./code-critique.md) | Application architecture, service layer, Blazor frontend, async/concurrency hygiene, secrets handling, testing, operability. Graded C / C-. |
| [`db-architecture-assessment.md`](./db-architecture-assessment.md) | SQL Server schema, indexes, type choices, the audit subsystem, and the EF Core 8 layer. Graded C+. |

**Why they're archived.** Both were delivered, and Taher has since decided to **rebuild WBA
completely** rather than remediate it. That makes their remediation-oriented findings — god
services, `FLOAT` money columns, the runaway audit table, index hygiene — moot as a work plan.
They remain useful only as a record of what the legacy platform was and why replacing it was the
right call.

**Where the live WBA material is.** Current-state functional documentation for WBA lives outside
this folder, in the separate `taher-wba-rebuild` repo — a numbered set covering
architecture, data model, UI, workflows, reporting, integrations, jobs, API/auth, security and
tech debt, plus jobs-to-be-done. That, not this, is the input to the rebuild.

**Note on scope.** WBA is a *different application* from Food4Life. WBA is the legacy financial and
operations platform (weekly data entry, DCR, invoicing, budgeting, Sage/ADP/Clover integrations).
Food4Life — everything in the parent folder — owns menus, nutrition, compliance, production records
and inventory. They share domain vocabulary (Region → District → Unit → Building; FSD; K-12 / B&I)
but not a codebase, and the Food4Life review found no evidence of a shared database.