command-center — harvested value (picked up, NOT graveyarded)

Reviewed: 2026-07-01 · fresh read of the actual code (per Sam: never decide from memory; review before deciding) · Sam: "I don't like graveyarding — if there's stuff to pick up, pick it up."
Source: HookStreet-Business-OS/command-center/ — an abandoned Next.js 14 + Supabase "Personal Business Operating System" (Sam's early obligations/tasks dashboard, ~Mar 2025, 4 commits, never deployed). Left in place (not moved to graveyard). The value below is harvested so it feeds the current stack; the runtime shell is superseded by the live Cloudflare-Worker + Sheets + static-portal stack.

Why not revive the app itself

It's ~45-50% of an MVP: schema + server-side write actions are real, but there's no write UI (QuickActions link to /tasks/new, /obligations/new, /reports/generate — none exist; console buttons have no onClick). Reviving it would fork the stack onto Next.js + Supabase (not in our stack) + Netlify (deprecated per the hosting rule) and duplicate the live portal. So: harvest the data model + logic, leave the shell dormant.

THE VALUABLE PARTS (reuse these)

1. The obligations schema — better-normalized than the live flat Sheet ⭐

command-center/supabase/schema.sql lines ~107-153. Fields worth lifting into the Cloud Memory Layer (D1) and/or an ops-api obligations upgrade:
- obligation_type enum: credit_card | mortgage | heloc | personal_loan | auto_loan | installment | subscription | utility | insurance | tax
- is_autopay, due_day, next_due_date
- minimum_payment vs monthly_payment (distinct — the live sheet conflates)
- apr / interest_rate, payments_remaining, current_balance, total_paid
- account_id FK (pay-from routing as a relation, not free text)
This is essentially the data model the obligations-audit skill tracks by hand — worth making first-class.

2. The work_items master-queue + history_events audit pattern

schema.sql lines ~159-206. One row per actionable item (type/category/status/priority/owner_id/assigned_to/source/parent_id) + an append-only history_events table with a log_history_event() trigger. This is the same doctrine as the live Action_Queue + the "one row per loop" CURRENT_STATE rule — but a fuller reference schema. The append-only audit log (not snapshots) mirrors Action_Events. Reference when the command-inbox engine or Cloud Memory Layer needs a normalized queue/audit model.

3. recordPayment() business logic

command-center/src/actions/obligations.ts lines ~91-156. Real reusable logic: advance next_due_date +1 month, decrement payments_remaining, reduce current_balance, bump total_paid. Directly portable to ops-api obligation handling.

4. src/lib/types.ts (402 lines)

Clean TypeScript domain interfaces: Obligation, WorkItem, FinancialSummary, PaymentDue, DashboardStats. ops-api is a TS Worker → drop-in-quality type seeds for portal financial widgets.

5. Owner/assistant RLS split

schema.sql lines ~545-553 + console/page.tsx (assistant sees only assigned_to = me). Good reference for the Mildred boundary (own/flag/off-limits) if the portal gets a Mildred-scoped data view.

NOT useful / superseded

The runtime shell (Next.js + Supabase + Netlify), the fake seed data, and all Phase-2 integrations (Gmail/Calendar/Plaid/QuickBooks/CSV/PDF = 0 code, roadmap prose only).

Where this plugs in

• Flagship Cloud Memory Layer (D1): items 1 + 2 are the migration-reference schema for obligations + a normalized queue/audit model.
• ops-api obligations upgrade: items 1 + 3 + 4 (schema, recordPayment logic, types).
• Brain's live BOS/obligations research thread: this is the "better schema" input for making obligations work for real.