The Implementation Manager asks for a change in Slack, or a ticket lands in Linear. Mason brings it to the kitchen. That is an order 🧾. A crew of AI cooks preps it, cooks it, tastes it, times it, and serves it. Nothing leaves the kitchen until automatic inspectors say it is good. People decide what to cook. The kitchen does the cooking.
Every cook has one job, its own tools, and a clear list of things it never does. The small grey name on each card is the real agent behind the costume.
A simulation of a real shift. Mason brings orders from the Implementation Manager and from Linear. The head witch sends each one to a free station. Inspectors send bad dishes back. Press Break a stove to see the kitchen fix itself.
Click each step. Every step has an owner, a proof it must show, and a rule for what happens when it fails. A dish only moves forward with proof, and only a tool can move it.
Dealers send loan applications through dealer networks: DealerTrack, RouteOne and CUDL. Mason has his own browser. He logs in to the test site of each dealer network himself, with logins from the password vault, and does the whole check alone, with made-up customers only. He types the application in the dealer site, finds the same values in the LOS, lets the LOS decide, then goes back to the dealer site and sees the decision arrive. Every value must match on both sides. Screenshots prove it. No person has to click anything.
His private rig: a browser that stays logged in, a private copy of the LOS, a password vault and a Tailscale exit node, so every call leaves from the approved Fuse address.
| Field | In the portal | In the LOS | |
|---|---|---|---|
| 📥 Portal → LOS: what Mason typed | |||
| 📤 LOS → portal: what the dealer sees | |||
/dealer-track-testClones a finished test application, follows its reference number, then checks the contract status and app status that the portal shows.
/routeone-testClones in the test portal, notes the app and deal jacket numbers, then opens the finance source decision page. Comments and conditions must fit the portal limits.
/cudl-testSubmits in the test portal, replays the raw application unchanged, then checks the deal queue for the decision and the notes.
--iterations 5 or --duration 30m.Every step in the kitchen is built so an AI cook can check its own work. A cook never just says "done". It runs a real check, saves the proof and prints one result line. If the check fails, the dish goes back with the exact reason, gets fixed and is checked again.
Each station ends with its own automatic check: a test run, a verdict script, a database query, a timing run. The cook does not decide that it is done. The check decides.
Every pass leaves proof: test logs, a caught mutant, a verdict file, screenshots, database rows, a speed report. No proof means not done, even if the reply says "success".
A fail names the exact cause, for example mutant_survived or db_row_missing. The dish goes back to the cook who can fix it, and the same check runs again.
Every check script has its own test and a mutant: a broken copy of the check that the test must catch. So a check can never quietly stop checking.
impl-done, verify-pass, perf-fail, staging-pass. The head chef moves orders on these lines, not on long chat replies.Not every order needs the most expensive chef. The OpenAI Decisions API reads the order and picks a recipe size. A routing board then picks the AI model and how hard it should think for each step. Quota meters swap chefs when one runs low.
Mason brings orders from the Implementation Manager and from Linear: requests, tickets, bugs. Internal tasks too. All go through the same router.
Sorts every order into no code small fix full chain. If it cannot answer, the head chef decides and writes the reason down.
A dashboard row says which model and effort to use per step, for example a strong model to build and a fast one for small fixes.
Every launch and every move prints one line, so anyone can see who cooks, how hard, and what comes next.
Questions, config, research. No kitchen station used.
One small change, lighter model, same inspectors.
New features. Every inspector, every proof.
The kitchen holds several Claude accounts and Codex. An hourly quota watch reads each one. Below 25% left = starving, new work prefers the other provider. Below 10% = disabled for routing. Back above 15% = recovered. Running cooks finish their dish; only new launches move. Labels stay generic (Claude 1, Claude 2), never account names.
If Claude cooked it, a GPT model reviews it. If GPT cooked it, Claude reviews it. Two different "palates" catch different mistakes. Unknown cook model = review refused, never a same-provider default.
The head chef never launches a generic chatbot. Each cook starts in its own lab harness, set up for that one job.
Claude Code or Codex, whichever cooks that step best. The routing board picks the model and how hard it thinks.
The second chef only reads and reviews. A cook cannot publish; only the publisher can. Each role gets a short tool list.
Short role rules, compressed skills and a context budget. When the context gets big, the cook saves notes and starts fresh.
Small scripts run at session start and before and after every tool call. They block unsafe moves, log every step and nudge the cook back on track.
Two kinds of inspector work together. Machines run the same checks the same way every time. AI judges on the OpenAI Decisions API handle things that need reading and judgment. The rule: AI may suggest, but only a script can record a verdict, and the script refuses anything malformed.
Does the code do what the order asks? The cook writes the tests first, then the code, plus one full browser test that clicks through the app like a person.
Are the loan workflow files safe? It finds broken JSON, missing or duplicate IDs, unsafe handler files and steps that point to nothing.
Is the code clear without notes? An added code comment blocks the dish. Good names and tests explain the intent.
Do the tests really test? A script breaks the fix on purpose. If the tests still pass, they are too weak and the dish goes back.
Is it correct, easy to change and secure? A second chef reads the change with a checklist. The AI suggests; only the verdict script records.
Is the money rule right for every possible input, not only for the test examples? Rules for fees, limits and eligibility are written as math theorems in Lean. A test checks a few cases; a proof covers all of them.
theorem fee_le_cap : ∀ amount, fee amount ≤ cap"For any loan amount, the fee is never above the cap." Lake must build the proof at the exact code version. If the code has the cap off by one, the proof does not build and the dish goes back. Then the OpenAI Decisions API scores the result.
Does it really work for a person? The taste tester proves every acceptance rule in a real browser on its own copy of the app, checks the database and saves screenshots, video and traces.
Loans talk to credit bureaus, dealer networks and pricing partners. Integration code is tested against the real providers, and every real answer is recorded so future tests can replay it as a fake. Some lanes get mock providers, others get real providers. Mason runs the real scenarios himself.
Every provider has its fake answers registered. A test picks the exact case it needs, and the fake says which case it served.
Fake answers prove the plumbing. They never count as real provider proof.
Integration code is proven against the real provider sandbox, but only on a lane whose ticket has a written allowance. Logins come from the vault. Everyone else is refused. Every real answer is recorded.
Test hosts only, never production. No real customer data.
Mason has his own copy of the app with real providers allowed, and his own browser that stays logged in. He sees every request that comes in and every call that goes out, so he knows exactly what is going on. Provider traffic rides the Tailscale exit node, so it leaves from the approved Fuse address.
He records the video and screenshots himself and posts the proof.
A real provider answer is saved as a new case in the mock registry. From then on, every mock lane can replay that exact answer in seconds, with no real call and no cost. Real lanes keep the fakes honest; mock lanes keep the kitchen fast.
The desktop keeps 20 build lanes and 5 staging lanes working at all times. A lane only counts if a live cook is on it. Each lane is its own private copy of the app, database and browser, so nobody bumps into anyone. Lanes live on internal IPs behind NAT, never open to the internet, yet each one gets real HTTPS names (app, API, database console) on the shared wildcard certificate, provisioned automatically.
Good cooks need good stoves. These are the pieces that let 25 stations cook at once without bumping into each other.
Each station gets its own copy of the code, its own running app, database, test data, provider mocks and browser. A queue builds one station at a time per machine, so builds never fight. Real provider logins come from the vault, checked for parity.
Lanes sit on internal IPs behind NAT. Private DNS points each lane name to the internal address, and the proxy serves it with the wildcard certificate. Only the LAN and Tailscale can reach it, so tests see real HTTPS without exposing anything.
Credit bureaus and dealer networks only accept traffic from approved addresses. Every provider test rides in one container that exits through the Fuse IP, never a laptop. "IP not allowed" = first check the truck.
Station browsers reset after each test. Mason has a separate browser that stays logged in to the admin tools and the app, so he can check, record videos and take screenshots any time.
Every station streams logs and CPU to Grafana. The detective reads logs to find the exact line of a bug. The photographer proves the log stream for each verified dish.
Every station gets its own secure web address under one wildcard certificate, served by one shared web gateway.
Every decision, answer and root-cause fix is saved. Before anyone asks a question, the kitchen searches memory first. Found = apply it, no new question.
A laptop and a big desktop both cook. Same scripts, same router, same gates. Any path that only exists on one machine is treated as a bug.
Every order, station and question shows live on a board. It accepts changes only from tools, so the board can never drift from reality.
Credentials come from the password vault and are used in place. They never appear in chat, logs, reports, commits or this page.
Kitchens break. Stoves go cold, a cook freezes, a delivery fails. Timers ring all night, and every ring means: find what is stuck and fix it now.
🔧 Infra crew repairs stations: rebuilds stacks, checks credentials, swaps a broken station, frees disk. One task, then it leaves.
🛠️ Harness engineer improves the kitchen itself: scripts, gates, cook instructions. Every change comes with a real test and a mutant that must fail.
📚 Learnings board: the top 15 lessons each get an automatic check in the shift doctor. A failed check is a finding to fix the same turn.
🩺 Bootstrap doctor: at every shift start it checks routing, station floor, publisher count, tool versions and memory before any cooking.
Mason posts a kitchen board every morning and an update every 3 hours, with screenshots of every screen that changed. Times are in EST. ETAs come from the last 6 hours of real cooking times, not guesses.
Reading the order, asking questions.
Being built and reviewed.
Being verified on its own copy of the app.
Verified, bundled every hour into one deploy.
Live on staging.
Proven again on staging.
Blocked. Always with the question and lettered options a) b) c).
Failed a check with a named blocker. Back to its station.