WAYS OF WORKING · DEMO 14 NINO CHAVEZ
Kibble & Co.
doesn't sell
anything.
It's a pet-supply storefront on a real BigCommerce sandbox, moving real Stripe-sandbox money through real dunning logic. It exists only so a subscription-billing platform could be built against a genuine store instead of a slide deck. Five deployed apps, 94 ADRs, and a generated file that answers "what's shipped" so nobody has to narrate it.
What the README still says
"38 ADRs" — written 2026-05-24, never updated.
ls docs/decisions/*.md | wc -l → 94 decision records. The count nobody wrote down is the one that's true.→ or scroll to advance · ← to go back
02 WHAT SHIPPED
Five apps, one repo, all deployed
Not a demo environment behind a login wall — a fleet, publicly reachable, each surface doing its actual job. The storefront runs against a real BigCommerce sandbox store; the admin app is the real BigDesign App Extension a merchant would install; the API is the live engine settling charges.
Every tour is a captured recording of the live app, not a mockup: plays real UI, deep-linkable, gated behind one shared passphrase so any surface opens with the same credential.
03 WHAT IT DOES
Orders are BC orders. Payments are BC Payments.
The bet is depth, not breadth. Every recurring charge produces a native BigCommerce order and settles through the merchant's own BC Payments account — inventory, tax, and shipping all ride BC's existing surfaces instead of a parallel system. Charges hit BC's stored-instruments vault; the app never touches card data. Zero PCI scope, proven end-to-end on a real sandbox store.
Merchant
Turns an existing catalog into subscriptions — plans, cadence, dunning rules — without duplicating a product record.
Subscriber
Skip, swap, pause, or update payment from one self-serve portal, no support ticket.
Support
One screen: subscriber, next charge, last five orders, payment health, dunning state.
Three of four PRD personas, verified against §5
04 WHY IT'S NATIVE, NOT BOLTED ON
Every other option on BigCommerce runs the money somewhere else
The existing subscription apps on BigCommerce settle through a separate Stripe or Braintree account outside BC Payments — a second dashboard, a second payout flow, a second reconciliation problem for the merchant. This build routes the whole thing through the platform's own payment rail instead: one dashboard, one payout, one relationship. Pet food is one of the five verticals the spec names outright — CPG, vitamins, coffee, consumables, pet food — which is the actual reason Kibble & Co. is a pet-supply shop and not, say, a coffee subscription.
05 HOW IT WAS DELIVERED · SPEC EDITS
No one edits the spec directly
Discovery and delivery run in one repo, not two. A spec change — PRD, BRD, ARCHITECTURE — starts as a [Spec] proposal, gets ratified in a weekly synthesis pass, and only then becomes a PR. The synthesis ID rides in the commit message, so any spec change is traceable back to the decision that authorized it — not just to whoever typed the diff.
The convention, in a real commit
docs(adr): store-credit ledger substrate design (synthesis #1930) (#1933)
218 user stories across 28 epics have moved through this path.
06 HOW IT WAS DELIVERED · "WHAT'S SHIPPED"
The answer is a file, not a paragraph
The methodology's own rule: state derives from code, not from docs. A prose "what's shipped" audit decays within hours in a multi-agent repo — the moment it's true is over before the doc lands on main. So the canonical answer lives in a generated file, re-run on every deploy.
Presence is not function
The storefront widget injector emitted <bc-subscriptions-widget>; the PDP renderer read [data-bcs-widget]. Both files existed.
COMPLIANT. The feature was broken. The fix wasn't a smarter check — it was admitting presence has a ceiling. A five-gate ladder now separates is it specified (G1) from does the artifact exist (G3) from does a scenario pass (G4) from is it green on the live store (G5). Nothing may claim a gate without the ones below it.
07 HOW IT WAS DELIVERED · THE FLEET
A runnable prototype settles design arguments; a shared board settles collisions
The design oracle
Every BRD epic gets a working prototype slice — 30 of them, one npm install and five minutes to a running screen. When a spec and a screenshot disagree, the running slice is the tiebreaker, not whoever argued louder.
The coordination substrate
Multiple agents work the same repo at once through Hive: a task board, file locks, and an append-only decision log on Cloudflare Workers + D1, called through 20+ MCP tools. fit_check catches duplicate work before an agent starts, not after two conflicting PRs land.
Five actor classes, each with a different authority: a principal's own harness inherits full authority because a human is in the loop; a pipeline agent gets a narrow deterministic contract; a triage agent can propose from external comments but never merge. Authority follows locus and scope, not which one is "the AI."
08 TWO THINGS THAT BROKE
An audit that checked nothing, and a repo that rate-limited itself
The circular audit
Two review agents were asked whether this repo fabricates platform claims. Both returned "clean — zero hard fabrications."
The self-inflicted rate limit
~146 pushes a day, each fanning out to ~28 workflows, billed ~2,900 of a 3,000-minute monthly GitHub Actions quota in the first four days of one month.
dev branch absorbs day-to-day pushes; main only fast-forwards on release. Neither failure shipped quietly. Both are recorded in the repo's own amendments log, with the fix and the reasoning, not just the outcome.
09 WHAT'S REUSABLE
Three habits that don't need BigCommerce to be worth stealing
Spec edits through synthesis
Nobody hand-edits the canonical spec. A proposal gets ratified before it becomes a diff, and the ratification ID travels in the commit message — so "why" survives as long as "what" does.
Derived state, never narrated
"What's shipped" is a generated file re-run on every deploy, not a document someone remembers to update. If the check can be automated, the prose version of the same claim is a liability, not a convenience.
A disposable, real front
When a feature needs to be proven against real platform behavior, build a fictional merchant on real infrastructure instead of a mockup. Nothing that happens to Kibble & Co. can leak a real customer's data.
10 WHAT THIS DEMONSTRATES
Not a product pitch — a delivery method, proven against a real platform
bc-subscriptions is an independent art-of-the-possible build by Nino Chavez, run against public BigCommerce APIs on a personal sandbox store. It is not a BigCommerce product, and nothing here reflects an internal roadmap. What it demonstrates: spec-driven development with an agent fleet can produce working software on a real platform — five deployed apps, a subscriber portal, dunning recovery, and a documentation set someone could actually onboard from — while keeping its own honesty checkable, one derived file and one amendments log at a time.