# Build Brief — Ingredients & Labor Management System (ILMS)

*Self-reporting entity for SFIB / WFAG · v0 · 2026-05-05*

---

## What I'm building

An **ingredients and labor management system** that becomes the operational nervous system for SFIB / WFAG. The product I want is a **self-reporting entity** — a business that surfaces its own needs and proposes actions instead of being interrogated for them. The shift I'm making: from holding the business like a baby (comforting, prompting, polling it for what it needs) to directing a system that reads its own state and tells me what's true.

This is the next step in the **Engineering Systems Build** outlined in Project Brain. It implements layers 2–5 of that architecture (MRP Engine → Kanban Board → Engineering Docs → Engineering Dashboard) and operationalizes **Pillars 3 (Orders & Fulfillment) and 4 (Inventory)** of Operations Command. It also closes the **Memento Brain problem** — no session should require reconstructing what's true.

---

## What it inherits from

Built on the guardrails already established at `~/Desktop/scripts 2026/000 Rails/` (mirrored in the GitHub repo `sfibcode/2026-scripts`):

- **RAILS.md** — R0 do-what-asked, R1 no-fabrication, R3 ask-before-build, R5 source-and-date, R9 write-for-the-stranger, R12 park-and-link
- **APPROACH.md** — paradox-holding, framework shorthand, externalization, recognition-through-doing
- **Operations Command Standing Rules** — *No Fetching Rule* (information comes to me, I don't go get it), *Externalize Context* (the system captures so the team self-serves and the founder directs instead of doing)
- **MVP Iterative method** — v1 sample, v2 real data, v3 automation; every version usable, none final

---

## How it decomposes

Order fulfillment splits into two parallel tracks plus a control center:

### 1 · Ingredients Management

Per-mix seed inventory truth — on-hand (raw bulk), allocated (listed in Squarespace store), incoming (supplier shipments en route), ATP (available to promise = on-hand + incoming − allocated). Per-supplier minimums locked (AM 5 lb / PCS 5 lb / Stovers 2 lb). Auto-trigger reorder when ATP drops below threshold given lead time. Source-of-truth replaces the current Inventory 2.0 / Wholesale Order Cost Estimates GSheet sprawl.

### 2 · Labor Management

Per-person time tracking integrated with Clockify, format already standardized in Engineering Basecamp (Product + Mix + Qty per entry). Cost per batch derived from rate × hours. Schedule vs. actual variance. Per-person capacity utilization. Standard invoice generation (closes the gap that surfaced today with Kota's invoice format).

### 3 · Control Center

Aggregates Ingredients + Labor + Orders + Cashflow into one dashboard. Sections already designed in Captain's Log v3.1:

- **Now Position** — what's true right now
- **Pay-What-We-Can** — cashflow assignment to obligations
- **Cash Generation** — pipeline from orders + loans + capital
- **Inventory as Stored Cash** — paid materials, labor-only conversion to revenue
- **30/60/90-day cashflow forecast**
- **Architecture / Operationalization / Operations status** — the three-section system map

---

## Phases

### Phase 1 · CSV aggregation + internal matrix

Hand-loaded inputs: ShipStation order CSV, supplier invoice CSVs (PCS landed; AM/Stovers pending), inventory snapshots, Clockify exports, cashflow position. Output: static HTML control center reading from local JSON/CSV files.

*Partially here already — Captain's Log v3.1, SKU Matrix v3.10 invoice ingestion.*

### Phase 2 · Live API pulls

Replace manual entry with API reads. Sources: ShipStation, Squarespace, Stripe, Clockify, Mercury, Google Sheets API, Notion API. Same dashboard surface; no source-of-truth migration yet.

### Phase 3 · Own database

Migrate to **Supabase** (Postgres-as-service: remote, secure, silo'd per stated criteria). Schemas: `ingredients`, `inventory_snapshot`, `inbound_shipments`, `master_batches`, `batches`, `orders`, `labor_entries`, `obligations`, `decisions`. Nightly ETL from APIs into Supabase. Synology serves as the nightly `pg_dump` backup target — three-tier backup chain (Supabase native → Synology mirror → other Synologys via Hyper Backup).

### Phase 4 · Two-way write + self-reporting triggers

Dashboard becomes the editor. Row-level security per role (Kota / Heather / Ian see only their lanes). Notion + GSheets demoted to optional input layers, not source of truth. The system fires alerts: low-stock, SLA breach, cashflow shortfall predictions, capacity overrun.

**This is when the entity becomes self-reporting.**

---

## Data sources, current → target

| Source | Data | Phase 1 | Phase 2+ |
|---|---|---|---|
| ShipStation | Orders, batches, ship status | CSV export | API |
| Squarespace | Product catalog, listed inventory | CSV export | API |
| Stripe | Payouts, Capital, revenue | manual paste | API |
| Clockify | Labor hours per person/batch | CSV export | API |
| Mercury | Bank balance, IO card, transactions | manual paste | API |
| Google Sheets | Inventory 2.0, cost matrices | manual / link | Sheets API |
| Notion | Master Batches DB, basecamps, MB Tracker | manual fetch | Notion API |
| Local files | Supplier invoices | `inputs/` drop | unchanged |

---

## Standing constraints

- Source-and-date every number (R5)
- No fabrication; if data isn't there, say so (R1)
- Park, don't delete; link, don't duplicate (R8, R12)
- Each phase ships a working artifact before the next phase begins (MVP Iterative)
- Build for the stranger — every column, panel, alert must make sense to someone with no context (R9)

---

## Out of scope

- Customer-facing storefront (stays at Squarespace)
- Customer service ticketing (separate concern; gift program parked)
- Marketing analytics (future)
- Accounting / bookkeeping (we feed Xero/QuickBooks; we don't replace them)
- Non-seed physical inventory — mailers, shaker parts, etc. (could extend in Phase 3+; not v1)

---

## Success criteria

The system is working when:

- I no longer hold inventory truth, batch state, or cashflow position in my head
- Kota / Heather / Ian self-serve their lane status without asking me
- An order spike auto-surfaces with reorder + capacity alerts *before* I notice
- Every dashboard number is sourced and dated per R5
- Notion + GSheets become optional input layers, not the source of truth

---

## Decision Log

| Date | Decision | Rationale | Reference |
|---|---|---|---|
| 2026-05-05 | Phase 3 backend = **Supabase** (Postgres-as-a-service) | Founder criteria: remote, secure, silo'd. Supabase: hosted Postgres + auth + REST + realtime + storage; SOC 2; daily backups + PITR; one-project-per-concern silo'ing; free tier covers initial dev. | This brief, Phase 3 |
| 2026-05-05 | Created Supabase project `SFIB IMS` under WFAG org (free tier) | First concrete step into Phase 3. Project provisioned, awaiting completion. | `https://znzvnkfrfnshoisgghtk.supabase.co` |
| 2026-05-05 | Region: `us-east-1` (East US, N. Virginia) | Selected during creation. ~80ms latency from SF; acceptable for non-realtime ops. May revisit for realtime features. | Supabase project settings |
| 2026-05-05 | Project naming: `SFIB IMS` (brand-scoped) over `WFAG IMS` (entity-scoped) | Founder's choice. Cross-brand data later: either expand schemas in this project or spin sibling projects per silo'd-by-design principle. | Decision Log |
| 2026-05-05 | Compute: `t4g.nano` (free tier default) | Sufficient for Phase 3 dev. Upgrade when production workload requires. | Supabase project settings |
| 2026-05-05 | Branch: `main` (production) | Default. Branching to be considered when schema migrations need staging. | Supabase project settings |

---

## Infrastructure State

**Supabase project (created 2026-05-05, status: provisioning):**

- Name: `SFIB IMS`
- Organization: Wild Futures Advancement Group (free tier)
- URL: `https://znzvnkfrfnshoisgghtk.supabase.co`
- Region: `us-east-1` (East US, North Virginia)
- Compute: `t4g.nano`
- Branch: `main` (production)
- Connection options surfaced in Studio: Framework client library · Direct connection string · ORM · MCP

**Credentials (NOT in this doc — store in 1Password / Passwords ▸ SFIB Ops):**

- Database password (shown ONCE at project creation — copy now)
- Service role key (admin bypass — NEVER in client code or git)
- Anon (public) key — safe in client HTML/JS once available; RLS protects data

**Next steps after provisioning completes:**

1. Confirm database password + service role key saved to 1Password
2. Define Phase 3 schemas — `ingredients`, `inventory_snapshot`, `inbound_shipments`, `master_batches`, `batches`, `orders`, `labor_entries`, `obligations`, `decisions`
3. Set up RLS policies per table (security boundary per role)
4. Wire Captain's Log v4 → reads from Supabase via JS client
5. Configure nightly `pg_dump` backup chain to Synology

---

*Source: synthesized from Shalaco's working prompt 2026-05-05, grounded in 000 Rails (RAILS.md, APPROACH.md), Project Brain — Engineering Systems Build, Operations Command Six Pillars, Spring Engineering Basecamp, Kota's Basecamp Run List, Captain's Log v3.1, Master Batches Notion DB, and the data backend recommendation (Supabase + Synology backup chain). Decision log + infrastructure state appended 2026-05-05 upon Supabase project creation.*