Kindred Table

Kindred Table is a marketplace of the kind that usually takes a team months to scope: several roles, money moving between strangers, and the trust mechanics that make them show up. It was written as a synthetic specification to test whether the method holds on something with real coordination in it.

The specification describes a marketplace with several roles — hosts who post dinners, guests who buy seats, and the operator between them — and the money and trust mechanics that have to hold between strangers: listings, bookings, payments, refunds, reviews. Every requirement traces to its source, and every one has a criterion that can pass or fail.

It is version 0.2 because it changed. The build package was regenerated from it eight times, at about ninety minutes each. Between runs the specification gained its rulings, seven of them, each closing a question the first drafts had left open: what a cancellation at exactly seventy-two hours refunds, what a takedown is, what happens to a late payment on an expired hold. When building takes hours, the specification is where the iteration happens, and this one shows what that looks like.

The build ran in six phases, each gated before the next began. Phases one and two laid the server foundation and sign-in. Phase three built the marketplace itself: listings, bookings with holds that cannot oversell, pricing in integer cents, refunds against the original charge, the payment adapter and its webhooks, discovery, the founder’s console and the waitlist. Phase four added the host dashboard, the reliability mark and the refund-fee rules; phase five, refund outcomes, reviews and ratings; phase six, the performance runs and the acceptance suites.

The specification carries fifty-one requirements and two hundred and fifteen criteria, and every criterion was graded by at least one gate. Behind them, at the close, are 1,604 unit tests and 158 end-to-end tests. The stack is the one the specification named: TypeScript on Node, Postgres, a React web client, a notification adapter.

The gates said no before they said yes, and the record keeps both. The package was rejected four times before it was accepted: 61 of 89 criteria on the first graded run, then 83, 79 and 107 of 115, with blockers named each time. The accepted package scored 112 of 115, with no blockers; the three misses are rulings, not gaps. The build phases went the same way. Phase three passed 109 of 109 criteria at its first gate and was still rejected, because a test teardown raced; the re-gate accepted it. Phase four was sent back once, for reminders that were not rescheduled when a dinner moved, and the defect was closed in phase five. Phases one, two and five were accepted at their first gate; phases one and two went from approval to verdict in about an hour and twenty minutes. Phase six rejected on the health instrument alone, forty of forty-one satisfied with one that only a tax form’s delivery could verify, and was accepted once two rulings were ratified. The build was complete.

Then the specification was read against the finished code by a reviewer who had not seen the build. Of 115 criteria checked, seven findings were real and unrecorded: a host could mark attendance before the dinner, and so dodge the refund rule; a host whose payouts were restricted could still publish; the launch gate covered the front page and nothing else; one failing payment event could block every newer one; the revenue figures dropped money the platform had kept. The owner ruled on each before a line changed, reversing one earlier ruling in the process. One remediation slice fixed all of them, with a regression test for each that fails on the old code, and its gate accepted at the first pass: thirty-one of thirty-one requirements, 147 of 147 criteria, the spec checked on every one with no divergence. The deviation register closed at zero open, and the rulings log at 106.

What the gates could not reach is written down too. Payments were proven against the payment provider’s adapter, not its live test mode; 1099-K delivery, real phones, a real notification provider and the founder’s own acceptance testing are owed to a real environment. Sales tax, disputes and a handful of other concerns were waived for a demonstration build, by ruling, in the open.