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. Humans make the meaningful decisions. AI does the chore work.
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.
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.
Watch them work together on one order. Each message flies from one cook to the next, and only the two cooks who talk light up. Humans make the meaningful decisions: what to cook, the answers to business questions, what ships. The AI crew does the chore work.
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.
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.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.
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.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.
Every merged change lands on staging, a shared copy of the app with made-up data only. First Chef's Check proves the change by itself. Then the Chaos Critic tries to break it on purpose: it puts on a hat, acts like that person, and lets a seeded monkey click around. People decide what happens with each finding.
Chef's Check waits for the deploy, then opens only the screens the change touched. Every acceptance check needs proof: a screenshot with a numbered red box on what is new. A success reply alone never counts. A pass means staging-pass. A fail sends the dish back to the kitchen.
A monkey clicks, types and jumps between screens at random. A seed number controls the random choices, so the same seed gives the same steps. A bug found by chance can be shown again on purpose.
Each run picks a hat, a person to act like: 😈 troublemaker, 🧑💼 loan officer, 🙋 applicant in a hurry, 🧾 underwriter, 📱 phone on a slow network, 🛠️ admin. Each hat looks for the problems that person would hit.
Each finding gets its own EXP id, with screenshots of every step, what we expected and what happened. Mason posts it in the kitchen thread. No ticket is made automatically: people in triage decide.
Allowed test targets only, made-up data only, never production.
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.
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.
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.