or scroll
Overnight build · morning briefing

All 10 features
built & committed.

The full Slabfy-parity plan is implemented on a branch, build green throughout, nothing deployed. Designed by Fable agents, built by Opus agents, each feature verified and committed on its own. Here's exactly what happened and the handful of things that need you.

10/10
Features shipped
11
Commits on branch
4
Migrations live
0
Deploys (held for you)

Branch feature/slabfy-parity · 11 commits ahead of main · full report in docs/SLABFY_PARITY_BUILD_REPORT.md

The 10 features

Every Slabfy feature, one commit each

Feature #11 (eBay listing/repricing) was deferred per your call. The three Slabfy headliners — Price Check, grade-ladder ROI, real-time values — were already live in Cardboard, so the app now covers their whole surface.

CommitFeatureWhat it adds
4e68f4dF1 · Fees + Dexie v5Channel presets + net-of-fees profit; the one schema bump all later features reuse
33e3f36F2 · Binders / tagsTag chips, editor, filter, tag search
9d95fbbF3 · CSV import/exportRFC-4180 + CollX/Ludex column mapping — the migration wedge
4c9b363F4 · Dealer tab + POS5th tab; live-P&L shows, cart + bundle allocation, quick-scan to cart
6df7142F5 · Sync generalizationCards-only → N-table engine; 5 new synced tables; crash-safe cursor migration
12886b7F6 · Want List UIWanted cards w/ live FMV-vs-target; entry points from movers & sold cards
8ad419dF7 · ConsignmentsConsignors, splits, payout ledger, statements; "your cut" P&L
b0f8737F8 · QR StorefrontPublic for-sale page from a leak-safe view; client QR
613bbe3F9 · Ask Cardboard AIStreaming chat, client-side tool loop over your data, in-chat slab scan
d0c48f8F10 · eBay monitor + Flip Finder24/7 want-list watch + arbitrage feed — dormant until you provision eBay
Deployment status

What's live, what's waiting on you

Applied to live DB

4 Supabase migrations

All additive and invisible to the currently-deployed app — new nullable columns and RLS-scoped tables the old client never reads. Applied so the schema is ready; no data touched.

  • F1 — 11 card columns
  • F5 — 5 dealer sync tables + RLS
  • F8 — storefront table + leak-tested public views
  • F10 — eBay alerts + flip feed + want columns
Held for review

Worker + client — not deployed

The Cloudflare Worker was validated with wrangler deploy --dry-run (bundles clean, all bindings resolve) but not deployed — pushing new worker code would risk live scanning/pricing traffic for zero benefit until the new client ships.

Everything deploys together, under your eye, once you've reviewed the branch.
The storefront leak test passed at the DB level: the public views expose only safe columns (title, player, grade, asking price, thumb) — zero cost / FMV / sale / consignor fields. Re-run tools/storefront-leak-test.mjs against a live storefront after deploy to confirm end-to-end.
Your move

What needs you

Nothing here blocks the rest — I did everything that didn't require you and parked these.

① Review & merge

All local commits on feature/slabfy-parity — nothing pushed. Merge to main when happy.

② Deploy when ready

Migrations already applied → wrangler deploy the Worker → deploy the Pages client. Together.

③ eBay activation — the one blocker

Create an eBay dev account → set the verification token (compliance endpoint goes live) → production keyset → set EBAY_CLIENT_ID + EBAY_CLIENT_SECRET. It activates at the next cron tick, no code change. Start early — approval latency is the wildcard. Full steps in the F10 spec.

④ The /s/* route

Storefront claims thecardboard.app/s/* for the Worker so QRs carry the brand domain. Confirm the marketing site doesn't use that path before deploying the route.

⑤ Tunables

AI daily cap (300) & model (Haiku → Sonnet via MODEL_AGENT); eBay call cap (4000). Change if you like.

⑥ Runtime tests

I verified builds + math + the leak test, not browser click-throughs. Highest-value: the v4→v7 Dexie upgrade on a real install, two-device sync, and the POS bundle math.

The method

Fable designed · Opus built · verified each step

  • 10 Fable design agents in parallel — ~1.95M tokens of file-precise specs, each grounded in the real code (they live in docs/build-plans/).
  • 10 Opus build agents, sequential — because nearly every feature integrates through App.jsx, parallel builds would collide. Sequential kept the branch coherent.
  • A verification gate per feature — my own build, a diff review of the risk surface, then commit. The build never went red.
  • A living coordination doc caught cross-feature drift (e.g. several specs each assumed they owned the schema bump — F1 won, the rest reused it).

A few calls I made

  • Applied additive migrations live (safe; keeps schema reproducible)
  • Held every deploy (conservative for a production API)
  • POS stores the channel label so sold-card detail reads consistently — a polish fix beyond spec
  • eBay ships gated on secret-presence, so it's inert tonight and activates cleanly when you add the keyset
Bottom line

You matched Slabfy — and kept your lead.

Parity, cheaply

Everything rode the existing single Worker + Supabase + Claude key. One new npm dep (qrcode). Read-only eBay is free at your volume.

Still ahead

Movers, sell-signals, offline PWA, and now an AI agent that knows your portfolio — none of which Slabfy has.

A wedge to grow

CSV import pulls users off CollX/Ludex. The storefront beats Slabfy's "coming soon." Their article is your comparison-page template.

Next move when you're up: skim the branch, kick off the eBay developer application (approval clock), then deploy Worker + client together. Everything else is done and waiting.

Cardboard · overnight Slabfy-parity build · reviewable at feature/slabfy-parity