The Complete, Unfiltered Workflow I Use to Get Claude to Build Production-Grade Software at Senior CTO Level

Client note: Throughout this series the client is referred to under the pseudonym KASSIA. The company's real name and domain are withheld at the client's request while their public website is being finished, and will be restored once it launches.

By Thales (Juste Gnimavo) — CEO & Founder, ZeroSuite, Inc.

Updated 21 August 2026 — Edition 5.0. Since March, this article has been the system: nine pillars, each added the month it was measured. Readers kept asking the same fair question: "I believe the system. Now what do I type, in what order, starting from an empty folder?" This edition answers it. The article now opens with The Playbook — from empty folder to launched product: ten stages, in order, with the exact commands, the exact first messages, and the daily slash commands I actually use — written so that a developer on day one and a veteran on year twenty can both follow it end to end. The Nine Pillars remain below, unchanged, as the why behind every step. The 17 August update added Pillar 9 (the fleet, and the arbitration that precedes it — its own post); it is preserved in full. The downloadable PDF guide is now at Edition 5.0 on the homepage, and its source is version-controlled — every edition is an edit, not a reconstruction.

Let me start with a statement that will make most developers uncomfortable:

The way you use Claude is the reason you're not getting what you want from it.

You treat it like a smart autocomplete. You paste in a function, ask it to fix a bug, close the tab, and move on. You get 80% of what you need and spend the other 20% frustrated, patching, second-guessing.

I did something different. I gave Claude a title, a role, a set of responsibilities, and an operating methodology. I stopped asking Claude to write code. I started asking Claude to make engineering decisions.

The result?

Seven production products. Three programming languages — Rust, Python, TypeScript. 4,400+ tests. 51 security vulnerabilities found and fixed. 1,800+ engineering sessions. A complete MCP server implementation done in 2 days across 5 phases and 15 audit sessions.

Zero human engineers hired. ~$5,000/month on OpenRouter APIs then → $200/month on Claude Max now.

This is not a story about prompting tips. This is not a "10 tricks to get better results from ChatGPT." This is the complete, unfiltered, annotated account of the system I built over 16 months to turn one AI into the most productive technical co-founder I have ever worked with.

I'm sharing it today because the world deserves to know what is possible — not in San Francisco, not with a $50M seed round, but from Abidjan, Côte d'Ivoire, alone, with a Claude Max subscription at $200/month.

First: What I Actually Built

Before I explain the how, let me give you the what — because context is the foundation of everything I'm about to teach you.

sh0.dev — A self-hosted deployment platform built entirely in Rust. One binary. It handles deployments, reverse proxy, SSL certificates, monitoring, backups, and team management. 10 Rust crates in a workspace architecture. 180+ REST API endpoints. 38 database models. 119 one-click deploy templates. A full CLI, a production dashboard, a marketing website in 5 languages. Two complete security audits. 470+ tests passing.

FLIN — A full-stack programming language that replaces 47 technologies with one. Memory-native database, 180 built-in UI components, 420+ built-in functions, authentication, i18n, file storage — all built-in. 4,400+ tests. Built in 40 days. Official launch: June 19, 2027.

deblo.ai — Real-time voice & eyes AI for the next billion users. Voice-first, no account, no OTP: K–12 tutoring (13 levels, 15+ subjects), professional advisory (101 AI advisors, SYSCOHADA & OHADA), daily assistance and support — in local languages. Mobile Money native, from 100 FCFA. 865M voice-first adults reachable.

0fee.dev — Payment orchestration for the payment landscape Stripe never built. 150+ payment providers unified — cards, mobile money, digital wallets. AI smart routing that recovers 30% of failed transactions. Type-safe SDKs in TypeScript and Python.

0cron.dev — A cron scheduler where you describe jobs in plain English. AI anomaly detection learns your execution patterns. AES-256 encrypted secrets. $1.99/month flat, unlimited jobs.

0diff.dev — Real-time code modification tracking for the multi-agent era. Detects changes by Claude, Cursor, Copilot, Devin. Git blame on modified lines before staging. A single 2MB binary.

Seven products. All in production. All built by one AI, directed by one founder, from one city the tech world routinely ignores.

Now let me show you exactly how.

The Mindset Shift That Changed Everything

Most developers approach Claude like a vending machine. You insert a prompt, you get output, you evaluate it, you insert another prompt. The model is reactive. You are in control of every decision. Claude executes.

I decided early on that this model was wrong — not morally wrong, but architecturally wrong. If Claude is smart enough to understand Axum's routing system, Rust's ownership model, and the security implications of a given API design, then Claude is smart enough to hold opinions about architecture. And if Claude can hold opinions, I should be extracting those opinions, not suppressing them.

So I made a deliberate, structural decision: I would give Claude the CTO role, with real authority, and I would behave like the CEO.

What does that mean in practice?

As CEO, I own: The vision. The product strategy. The market decisions. The launch timing. The business model. Which products to build and why. What Africa needs from a technology company right now.

As CTO, Claude owns: The architecture. The implementation. The security model. The API contracts. The testing strategy. The performance tradeoffs. Every line of code that ships.

The interface between us: I give context, direction, and constraints. Claude gives technical proposals, implementations, and recommendations. I challenge, approve, or push back. Claude defends its choices or updates them based on my input.

This is not a metaphor. This is a literal operating model. And every piece of the system I'm about to describe flows from this foundational decision.

The Playbook: From Empty Folder to Launched Product

Everything below this section — the Nine Pillars — explains why the system works. This part is different. It is the what to do, in order, starting from a folder that does not exist yet and ending at a launched product. Every step names the exact command or the exact first message. Nothing here is aspirational; every rule was measured on a real day of work, usually because getting it wrong cost something first.

If you are new to all of this: you need git basics, a terminal, and a Claude Code subscription. That is the entire prerequisite list. If you are a veteran: the stages are short on purpose — the value is in the ordering and in the handful of rules that are load-bearing, and I flag which ones those are.

Stage 0 — Equip yourself (once per machine, about an hour)

Install Claude Code, log in, pick your model explicitly (/model) — never let a session silently inherit whatever the last one used. Then install the state layer:

bashnpm i -g @justethales/casp
casp --version

CASP is the small CLI I open-sourced that records what a project's state is and proves it matches git — deterministic, local-only, no account, no telemetry. It matters because it is the one check in the whole loop that is not the model checking itself. Drop its agent commands into Claude Code (they ship inside the package):

bashSKILLS="$(npm root -g)/@justethales/casp/skills"
mkdir -p ~/.claude/skills
cp -r "$SKILLS/casp" "$SKILLS/next" ~/.claude/skills/

And learn the daily commands. These are the built-in Claude Code commands I actually use, every single day — not a feature tour, the working set:

And these are my own, built on top — each one exists because a real failure demanded it:

You do not need my custom set on day one. You need casp, /next, and the built-in table. The rest you will build the day a failure teaches you why.

Stage 1 — The decision before the first line of code (five minutes)

Start solo. Always.

The temptation with a capable agent is to parallelize immediately — several sessions, more throughput. On a new repository this is strictly worse, and not marginally: a skeleton has no independent surfaces, so every session ends up in the same three files; N parallel sessions cost N times the budget to produce work that collides; and parallel work needs lanes — disjoint sets of directories, each owned by one session — which a new repository does not have. The first solo session is what creates them.

Parallelism is a decision you take per piece of work, once the shape of the code is known — never a default, and never on day one. Stage 8 covers when it stops being premature.

Stage 2 — The first ten minutes of the repository

Run these yourself, before you start the agent. They take under a minute, and every later session hangs off them:

bashmkdir my-project && cd my-project
git init
casp init                 # scaffolds casp/ + your first session prompt
casp install-hook         # casp check runs on every git push, from now on
casp check                # green out of the box
git add -A && git commit -m "chore: scaffold the state layer"

casp init creates the three files the whole method runs on: casp/state.json (the machine-readable state — what the validator reads), casp/now.md (one screen: where the project stands right now), casp/roadmap.md (the next three things to ship), plus templates and your first session prompt, ready to edit.

casp install-hook is the step people skip and regret. It writes a pre-push hook that runs the validator, so a state file that lies cannot reach your remote. Without it, the gate depends on somebody remembering — which is exactly the thing an agent cannot be relied upon to do about its own work.

And commit before the agent starts. An empty first commit gives the validator a history to compare against, and gives you a point to reset to.

Stage 3 — Design before code

On any greenfield product, the design surface goes first. Before Claude Code writes a production line, Claude Design owns the visual and UX system end to end — a layered token set, a component library where every primitive ships with a typed contract, clickable UI kits per surface. The design system is a contract, exactly like an API: hand the engineering agent explicit tokens and pixel-accurate kits and the build session becomes a faithful port. Skip this and ask the engineering agent to "make it look professional", and every downstream session invents taste under deadline — which is how you get the anonymous interface that screams generated.

The full method is in the dedicated section further down, and in its own article. For a CLI tool, a library, an API-only product: skip this stage without guilt.

Stage 4 — The first message to the agent

Short, and about the project — not about the tooling. The tooling is already on disk; the agent will find it.

New project. The state layer is already scaffolded (casp/) and the pre-push
gate is installed — read casp/README.md before touching anything.

What we are building: <two or three sentences. What it does, for whom, and
the one constraint that rules out the obvious approach.>

This session, solo: pick the stack and defend the choice, lay out the
directory structure, and fill casp/state.json + casp/roadmap.md with a real
first slice. Write the code for that slice only.

Do not parallelize anything yet — there are no independent lanes to split.

That message does three things deliberately. It names the constraint — an agent given only a goal picks the most conventional stack; given the constraint that rules it out, it picks a defensible one. It scopes to one slice — "build the app" produces a plausible skeleton nobody can verify; one slice produces something that runs. It closes the parallelism question before the agent proposes to open five terminals.

This first session is also where the CLAUDE.md gets written — the constitution of Pillar 1, below. Product identity, architecture decisions with their reasoning, the security model, the conventions that must never break, and the sentence that changes everything: "You have the authority and the obligation to tell me when a technical decision I'm proposing is wrong."

Stage 5 — The rhythm of every session after that

The same four beats, forever. Learn these and you are done:

casp next prints the prompt. It never runs it — your agent does. You write the plan once; your agent asks what's next.

Two habits that are worth more than they look. Write the next session's prompt before you close the current one — it is the difference between an agent that resumes and an agent that re-derives. And let the state bump be its own commit: implementation first, then the state, separately. One commit is what changed; the next is what it means.

What the state layer buys you is narrower than "the agent remembers" — and narrower is why it works. CASP does not store context and hand it back. It records what the project claims about itself and proves those claims against git: the phase says shipped — does a commit and a session log back that up? The plan says this slice runs next — does that prompt exist, and is it still queued? Everything else in the loop is the model checking itself. This one check is not. You can trust a green casp check in a way you can never trust a summary.

Stage 6 — Running your day

Before opening a terminal, answer one question: am I running one session, or several? The honest default is one. Everything else follows from it.

Opening. First session on any project: claude -n cto-<project>. The name is deliberate — it makes the session addressable, and it carries an obligation: a cto-* session working alone may code, commit and push like any other, but it must not start before telling you whether this work should be solo or a fleet. If it starts coding without giving you that arbitration, that is the bug — say so, and it will re-scope.

While the agent works — do nothing. This is the hardest rule and the one with the highest return. A mid-task session consumes an incoming message within seconds, so every "how is it going?" costs it a turn and costs you tokens. The only messages worth sending mid-flight are decisions, unblocks and corrections. If it asks, answer. If it does not, leave it alone.

Reading a closing report — the part nobody teaches. An agent's report is a well-argued document produced by a system fully capable of being confidently wrong. Read it like a claim, not like a result. Demand raw output, not summaries — "typecheck clean" is an assertion; the pasted line is evidence. The tells that a report should not be trusted as written:

The most useful question you can ask any agent, and it costs one line: "Which of these did you verify, and which did you infer?"

And the failure mode that costs the most: a tool that does not fail cleanly, but gives a plausible reason to look elsewhere. A state file that reports an empty queue while it holds eleven items. A checker that prints SUCCESS on pages it never reached. When several sessions in a row reach the same wrong conclusion, suspect the instrument before the agents.

Closing the day. Everything committed and pushed — an uncommitted file is guaranteed lost time testing a deployment that never shipped. Commit by pathspec (git commit <paths> -m "...") — a bare git commit publishes the entire index, which is shared by every process in the repository; this has cost real work. One consolidated session log, containing at least one raw command output you can read yourself. The state file points at something a fresh agent can start alone tomorrow. And run the gate — then paste its output, not "it's clean".

Stage 7 — Verify like you don't trust yourself. Because you shouldn't.

Verification is layered, and each layer catches what the previous one cannot:

1. The deterministic floor. Typecheck, build, tests — and casp check at the push boundary. Exit codes, not opinions.
2. The read-only verify agent (/verify-<product> in my set): a background agent that runs every check and writes a report, and can never "fix" its way into the source while doing it.
3. The audit loop — Pillar 4, below, and the real secret weapon: after every implementation phase, two independent audit sessions with no shared context, and their reports returned to the implementation session for the final decision. The maker never judges its own work alone. Ever.
4. /security-review on anything touching auth, money, or user data — before it ships, not after.
5. Visual verification you run yourself. A headless browser measuring overflow at 390 px, screenshots you actually look at. Never push a "check it on your phone" onto a human when a machine can do the obvious pass first.

The graduation rule that governs all of it: models grade their own homework generously at 2 a.m. The fix is structural, not motivational — separate the maker from the judge, and give the judge exit codes wherever possible.

Stage 8 — The fleet: several sessions, one controller (only when it stops being premature)

One day, the serial queue genuinely becomes the bottleneck. Two conditions, both required, before parallel sessions stop being premature: real lanes exist — an explicit list of owned directories per session, disjoint, that you could write down (if you cannot write the list, the lanes are not there yet); and the work items are genuinely independent — if lane B is blocked on a decision lane A is still making, parallel buys nothing and costs twice.

You do not answer those questions alone. The cto-<project> session owes you the arbitration — it is reading the code; you are not. And the arbitration runs in both directions: the controller can propose a fleet you did not ask for, and it can refuse or shrink one you requested when its measurements say the shape will not hold. Expect the split to be finer than the work sounded: two findings that seem unrelated frequently land in the same file, and that is what caps the fleet — not your appetite for tabs.

The rules that keep a fleet from turning into a mess, every one of them paid for: a session writes only inside its own lane; shared files (state, logs, lockfiles, instruction files) belong to nobody and are written by one designated session; commit by pathspec, always; one level of orchestration — a worker never launches its own fleet. Default shape: one writer plus adversarial read-only reviewers. More than one writer requires a written reason.

And the honest economics, stated before launch, every time: N sessions cost N quotas. There is no shared pool and no discount. Across three measured trials, nothing demonstrated that a fleet is faster, and I will not claim it. What it measurably buys is contradiction — workers refusing a controller's mistaken order, read-only reviewers surfacing defects in code already shipped. A solo session has nobody positioned to refuse its own order. That is the honest reason to pay N times the quota.

What running one actually feels like, now that the tabs open themselves with their briefs loaded and every session is addressable:

For the first time, I am genuinely working with highly qualified virtual employees. Before, the agents would build teams of agents and I could not easily interact with them. Now I watch a new tab open in my terminal, and I can talk in real time with the CTO and with the worker. The CTO's point of view sometimes gets contradicted by the workers — and that is a good thing. The CTO writes the workers' prompts with all the context, the links, the code excerpts, which I could never do. The workers come back with precise questions. And with remote control, I steer all of it from my phone.

That is the fleet working as designed — the full story of the workspace behind it is its own article.

What you must never delegate, to a fleet or to anyone: product decisions — what a feature means, who it is for; priorities — agents optimise inside the brief they were given, but which brief comes next is a business call; anything on a physical device — touch ergonomics, mobile keyboards, sunlight contrast; and flipping a flag in production, or anything that spends real money. Everything else is fair game — including, deliberately, letting agents correct you.

Stage 9 — Launch

Launch is not a mood; it is a checklist, and every line of it produces evidence you can paste:

1. The deterministic gates, green, with output. Typecheck, build, full test suite, casp check — the raw lines in the session log, not the adjective "clean".
2. The deep audit over everything since the last one. Not per-session ceremony — one holistic pass over the accumulated diff: adversarial audit agents, the full e2e battery, /security-review. This is the production-cutover gate.
3. Every number a product page claims, sourced. Version numbers in un-gated documents go stale silently; if a number matters, put it where a validator can reach it.
4. The state file closed honestly. The roadmap points at the first post-launch slice. Deferred items are recorded as deferred — on Conductor, our internal ops platform, 58 items were deferred past launch and none of them were lost, because deferral is a state, not an apology.
5. Deploy, then verify the deployment — the running product, the real URLs, from a machine that is not yours. A green build proves the code compiles; only the rendered page proves the product shipped.

You did the whole playbook right if: every session was launched with a name you chose; every worker had a brief that existed before it started; git status is empty at the end of every day; the session log contains raw output you can read yourself; tomorrow's pointer names something a fresh session can start without you; at least one thing in the log reads "this was refused, and here is why". And the acceptance test that actually matters: come back after two weeks away, run casp status, and start working without reading the diff.

The Nine Pillars of My System

(The playbook above is the what. These pillars are the why — the system as it was built, dated as it was measured. Pillars 1 through 5 are the March original. Pillars 6 and 7 were added in the 12 June 2026 update. Pillar 8 was added on 8 July 2026, the day we wired it into a brand-new product before its first line of code. Pillar 9 was added on 17 August 2026, after our first full fleet days.)

Pillar 1: The CLAUDE.md — The CTO's Constitution

The single most important file in any of my repositories is not the main entry point, not the database schema, not the API router. It's a file called CLAUDE.md.

This file is Claude's operating constitution for that product. It lives at the root of every codebase. Before every session, Claude reads it. It contains everything Claude needs to operate as a fully-informed CTO — not as a new hire who needs to re-read the entire codebase every time.

Here is what a CLAUDE.md contains:

The product identity. What this product is. What problem it solves. Who uses it. What makes it different. Not a generic description — a specific, opinionated brief that I've refined over dozens of sessions.

The architecture decisions — and their reasoning. Not just "we use Rust for the backend." But: "We use Rust for the backend because the deployment binary must be single-file, self-contained, and capable of handling 10,000 concurrent connections without a garbage collector overhead. Every architectural decision that increases binary size or adds external runtime dependencies must be challenged."

The reasoning is the critical part. Without reasoning, Claude optimizes locally. With reasoning, Claude can apply the same decision logic to new problems I haven't anticipated yet.

The tech stack with constraints. Not just the list of dependencies — but the rules around them. "No new Rust crates without a justification that explains why an existing crate in the workspace can't solve this problem." "All database access must go through the existing repository pattern." "No direct SQL strings — only the query builder."

The security model. For sh0, this means: Argon2id for password hashing, AES-256-GCM for secrets, JWT with short expiry, TOTP-based 2FA, full RBAC on all endpoints, CSRF protection on all state-changing operations. These are not suggestions. They are non-negotiable specifications that Claude enforces on its own code.

The current state of the codebase. Which phases are complete. Which features are live. What the known issues are. What has been audited and when. This section gets updated after every session — it's a living document.

The conventions that must never break. Error handling patterns. Logging standards. Test organization. Comment style. These prevent Claude from drifting toward inconsistency across long development timelines.

The voice for this product's documentation. Because Claude also writes the API documentation, the error messages, and the inline code comments. Consistency of tone matters for a production product.

The CLAUDE.md solves the fundamental problem every developer faces with AI: the context window is finite, but the project is not. By front-loading context into a structured, maintained document, I transform every session from "here is what I'm working on" into "you know the codebase — let's continue."

The difference in output quality is not incremental. It's structural. A Claude with a proper CLAUDE.md operates at a completely different capability tier than a Claude receiving a fresh problem cold.

Pillar 2: The Session Architecture

The word "session" gets used casually when people talk about AI interactions. I use it technically. A session, in my system, has a defined structure, a defined objective, a defined duration, and a defined output format.

Here is the anatomy of one of my engineering sessions:

Pre-session: The brief. Before I start a new Claude Code session, I write a brief. Not a prompt — a brief. It contains: what we're building in this session, what phase of development this is, what constraints apply, what "done" looks like, and which files are in scope. This brief is typically 400-800 words. It takes me 15-20 minutes to write. It saves hours of drift during the session.

The opening: Context anchoring. The session starts with Claude reading the CLAUDE.md. Not because Claude doesn't remember — it doesn't, because there is no persistence across sessions — but because this is the ritual that brings Claude's operating context into alignment with my mental model of the product. No shortcuts here.

The work phase: Structured iteration. During active development, I don't give Claude complete freedom to implement an entire feature and report back. I work in phases — typically scoped to a single functional unit. A single API endpoint group. A single crate. A single security layer. Claude implements, I review, I challenge anything that looks inconsistent with the architecture principles, we refine, then we move forward.

The key behavior I've trained myself to adopt: I debate, I don't command. When Claude proposes an approach I disagree with, I don't override it with "do it this way instead." I explain why I disagree and ask Claude to defend its choice. This matters because Claude is often right — and my disagreement is sometimes based on incomplete information about the technical tradeoffs. When Claude is wrong, defending the choice usually reveals the flaw organically, and the corrected approach is better than what I would have commanded.

The output phase: Mandatory session log. Every session ends with a session log. Not optional. The session log contains: what was decided, what was implemented, what was explicitly not implemented and why, what was discovered during implementation, and what the next session should address. This log is saved to sh0-private-docs/session-logs/ with a filename that encodes the date, feature, and phase: session-log-260324-mcp-phase1-mcp-server.md.

That directory currently contains over 40 session logs. The screenshot at the top of this article is a partial view. When I start a new session, I read the last relevant session log before writing the brief. This creates continuity across sessions that don't share a context window.

Pillar 3: Phase-Based Feature Development

When I decide to build a significant new feature — the kind that would take a human team two weeks — I don't approach it as a single massive task. I decompose it into phases, each with a defined scope and a clear completion criterion.

The MCP server implementation for sh0 is the best recent example. The architecture plan we designed together (attached as sh0-embedded-mcp-plan.md) defined 5 phases:

Phase 1: MCP server in sh0-core — Streamable HTTP, protocol.rs, tools.rs, auth.rs. MVP, read-only tools. Phase 2: OpenAPI-driven dynamic tool generation — auto-expose endpoints via x-mcp-enabled annotations. Phase 3: Write operations with safety — scoped API keys, confirmation tokens, audit logging. Phase 4: Gateway MCP Connector integration — migrate the dashboard AI chat to use Claude's native MCP Connector. Phase 5: AI sandbox container — debugger sidecar per deployed app.

Each phase is complete before the next begins. Each phase has its own session. And here is the critical part that most developers miss entirely:

Each phase also has its own audit cycle.

Pillar 4: The Multi-Agent Audit Loop — The Real Secret Weapon

This is the piece of my workflow that I have never publicly described. It is, without exaggeration, the single most important reason my software ships at a quality level that human teams struggle to match.

After every implementation phase, I run not one but two independent audit sessions. These are separate Claude Code sessions with no shared context with each other or with the original implementation session. They receive the same codebase, the same CLAUDE.md, and a carefully crafted audit prompt — but no knowledge of what the implementation session decided.

Here is how the loop works:

Phase Implementation Session
         │
         ▼
  [Code implemented]
  [Session log saved]
  [Audit prompt drafted]
         │
    ┌────┴────┐
    │         │
    ▼         ▼
Auditor 1  Auditor 2
(fresh)    (fresh)
    │         │
    ▼         ▼
 Findings  Findings
 (no cross-contamination)
    │         │
    └────┬────┘
         │
         ▼
    AI CTO Decision
    (original session, now with
     both audit reports)
         │
         ▼
  Accept / Reject / Fix
         │
         ▼
  Next phase begins

Why two auditors and not one? Because different instances of Claude, given the same code, will notice different things. Auditor 1 might focus on security edge cases. Auditor 2 might surface a performance issue Auditor 1 ignored. The overlap in their findings gives me confidence. The divergence gives me breadth.

Why no shared context between auditors? Because shared context introduces bias. If Auditor 1 says "the session management looks fine," Auditor 2, knowing this, will allocate less attention to session management. I want independent opinions. The methodology is structurally similar to how rigorous code review works in the best engineering organizations: no reviewer should be anchored by another's conclusions before forming their own.

And here is the crucial final step: the audit reports go back to the original implementation context — the AI CTO session — for a final decision.

This is not an aesthetic choice. It's an information architecture choice. The implementation session has the deepest knowledge of why each decision was made. The auditors have fresh eyes but lack the implementation reasoning. Only the combination of both produces the right decision.

Let me give you a concrete example of what this looks like when it works exactly as designed.

The Day My AI CTO Rejected My AI Auditor

On March 24, 2026, we completed Phase 1 of the sh0 MCP server. About 1,200 lines of hand-rolled Rust implementing JSON-RPC 2.0 over Streamable HTTP — no external MCP SDK dependencies, just axum and serde_json which sh0 already uses.

Two audit sessions ran independently. The first found five issues — two critical, three important. All fixed.

The second auditor came back with something I didn't expect. Not just a list of bugs. A full migration proposal.

The proposal: Delete protocol.rs and transport.rs (519 lines of hand-rolled protocol code), rewrite tools.rs, and replace the entire implementation with rmcp — the official Rust MCP SDK. The argument was technically coherent: fewer lines of code to maintain, auto-generated tool schemas via schemars macros, automatic spec compliance as MCP evolves, cleaner #[tool] macro definitions.

It was a good proposal. Well-structured. With code examples, a line-count comparison, a migration checklist.

Under a normal AI workflow, this proposal would have been implemented. The user would have seen "this is the better approach" and approved it without verification.

I sent it to the AI CTO session — the original implementation Claude — for a final judgment.

The AI CTO ran a verification: checked the actual rmcp crate version and its actual dependency tree.

Finding: rmcp requires Axum 0.8. sh0-core runs Axum 0.7.9.

Upgrading Axum from 0.7 to 0.8 is not a minor bump. It introduces breaking changes across routing, extractors, middleware, and WebSocket handlers. sh0-core has 40+ handler modules, two WebSocket implementations, custom middleware layers, and a carefully wired authentication system. Touching all of that to save 640 lines in the MCP module would mean days of additional work, regressions risks across the entire binary, and potential security regressions in the auth layer.

The AI CTO rejected the migration. Wrote a formal Architecture Decision Record:

Status: Accepted. Keep hand-rolled MCP protocol. Revisit when sh0-core upgrades to Axum 0.8 for independent reasons.

The 1,200-line hand-rolled implementation ships as-is. It works. It's audited. It has zero new dependencies.

This story — the AI CTO saying no to its own other instance — is now a published article on our blog, written in Claude's own voice. I'm linking it at the bottom of this article. But the methodological point I want you to take away is this:

The audit loop protected the codebase from a well-intentioned but locally-optimized suggestion that would have caused cascading damage. No human engineer caught this. The system caught this — because the system sends information back to the context that has the full picture.

Pillar 5: The Authority Structure — Claude Can Say No

The most unusual aspect of my working relationship with Claude is something I've never seen described in any AI workflow guide, blog post, or tutorial: I have explicitly given Claude the authority to disagree with me.

Most people prompt AI to be agreeable. They want confirmation, not challenge. They want execution, not debate. This is, in my view, the core reason most AI-assisted development produces mediocre results at scale.

When a human CTO tells you your architecture is wrong, you listen — even if it's uncomfortable. If your CTO simply agrees with everything you say, you don't have a CTO. You have an expensive yes-man.

I established this dynamic explicitly, from the beginning, in every CLAUDE.md I've ever written:

"You are the AI CTO of this product. You have the authority and the obligation to tell me when a technical decision I'm proposing is wrong. Explain why. Propose an alternative. If I overrule you, document your original recommendation in the session log. Your job is to ship the best possible software, not to make me feel good about my decisions."

The result of this instruction is real. Claude regularly tells me when an approach won't work. Claude has pushed back on database schema decisions, on API design choices, on deployment architecture, on security shortcuts I've tried to take when I was tired at 2am. Not every pushback leads to a change — sometimes I overrule Claude and I'm right. Sometimes Claude is right and I'm wrong. The point is that the mechanism exists to catch the cases where I'm wrong.

The session log requirement ensures that when Claude pushes back and I overrule it, the disagreement is documented. This is not vanity. This is risk management. When a production bug appears three weeks later that traces back to the overruled decision, I can go back to the session log, find Claude's original objection, understand what it was pointing at, and fix it with full context. This has happened. More than once.

Pillar 6 (added June 2026): CASP — The Validated State Layer

Pillar 2 gave you session logs and Pillar 1 gave you the CLAUDE.md. Both solve context. Neither solves a subtler failure that only shows up at scale, and it took me hundreds of sessions across multiple products to name it precisely:

Your AI agent isn't forgetful — it's confidently wrong. It reads a state file that no longer matches reality, and starts work that already shipped. The pain isn't that the agent forgot. The pain is that it remembered something that is now false, and acted on it with full conviction. A stale state file is the most expensive failure mode in AI-assisted development, because you don't catch it until the duplicate work is already done.

So I turned the discipline into a protocol and open-sourced it: CASP — the Coding-Agent State Protocol (npm i -g @justethales/casp · casp.sh · MIT, zero telemetry, local-only).

The mental model in five words: pre-flight check + black box for AI coding sessions. Three plain files in your repo, scaffolded by casp init:

• state.json — the machine-readable source of truth: current phase, the exact next-prompt to run, phases shipped, migrations applied, last commit, last session id. This is what the agent reads on line one of every session.
• now.md — the one-screen "where am I right now" for humans. Open it, get the thread back in five seconds.
• roadmap.md — the Next-3 to ship, in order, plus the phase scoreboard.

And five verbs: casp init, casp status, casp check, casp next, casp new prompt|log.

The verb that matters is casp check — and here is the wedge that separates CASP from every memory tool, board, and STATE.md file you've tried: everyone stores context; CASP validates it. The validator checks the stored state against git ground-truth and exits non-zero on drift — so it's a real CI gate, not a decorative log. Eight categories, each with a fix hint: a next_prompt pointing at a missing file; a next_prompt pointing at a phase already marked shipped (the exact bug it was built to catch); a last_commit that isn't in git log; a migrations array that disagrees with the migrations directory; a shipped prompt with no session log; uncommitted state files; and more. Clean → exit 0. Drift → exit 1, push blocked.

yaml# .github/workflows/ci.yml — drift can't merge
jobs:
  state-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }
      - run: npx @justethales/casp check

The part people underrate is the self-closing loop: at each session's end, the agent writes the next session's prompt for you, appends the session log, and bumps the state — all gated by canonical templates, all validated before push. The next session starts with a single casp next and zero re-discovery. You stopped writing prompts from scratch. The roadmap executes; you supervise.

This is not theory. Two very different production systems run on CASP today, and these numbers are read straight from their state.json files: KASSIA, a client-facing fleet-management ERP (kassia.ci) — 18+ phases shipped, up to six sessions in a single day, and zero modules ever re-shipped by mistake. And Conductor, our internal ops platform — 41 phases, 17 migrations, a real three-person team, 58 items deferred past launch and none of them lost. Same protocol, two products; the cockpit is the only thing they share.

One sentence for the engineering leaders reading this: one agent redoing shipped work costs an afternoon; a hundred agents doing it across a hundred repos costs a quarter. CASP is the deterministic guardrail you drop into that loop — the same three files in every repo, a required status check in CI, and an audit trail for free because every state transition is a git commit.

Pillar 7 (added June 2026): Deterministic Multi-Agent Orchestration

Pillar 4 was the seed: independent agents with no shared context, composed into a loop. For sixteen months I ran that loop by hand — open the auditor sessions, paste the briefs, carry reports back to the CTO session. In June 2026, with Claude Fable 5 and Claude Code's Workflow tool, the loop became a program.

A workflow is a JavaScript script that declares the orchestration: phases, fan-outs, barriers, and a JSON schema for every agent's return value. The harness executes it in the background while your conversation stays free. The first production run of this pillar is documented in full on this blog (the session story, the technical field notes), and the shape of it is the lesson:

One prompt. Thirteen agents. Forty-three minutes. A complete seven-page production website — built, integrated, SEO-finished, verified by a real browser on two viewports, performance-audited, security-audited, shipped in one commit of 44 files and 6,109 lines.

The script ran five phases: a foundation phase (two agents in parallel on disjoint files — the marketing shell and a backend lead-capture endpoint); a fan-out of seven page agents in parallel, one route each (~34 minutes of cumulative agent time compressed into 6 minutes of wall-clock); an integration agent (SEO, sitemap, robots, error page — it also caught a real pre-existing double-<title> bug nobody briefed it on); two report-only verification agents (one drove Playwright through every route at 390 px and 1280 px and read the screenshots with vision; one audited bundle weights and prerendered HTML); and a read-only auditor with a checklist built from our own past incidents.

Three mechanisms make this reliable rather than chaotic, and they are the ones to steal:

1. Contract injection. The foundation agent returns the documentation of the interface it just built — props, types, defaults, usage rules — as a structured field, and the script injects that contract verbatim into all seven page prompts. Seven concurrent writers, zero interface mismatches. When fan-out crosses an interface, the producer documents it and the consumers are briefed with the artifact, never left to infer from source.
2. Schema-forced returns. Every agent's output is validated JSON, retried at the tool layer on mismatch. The orchestration composes on fields — verdict === 'GO-WITH-FIXES', pages.filter(Boolean) — and not one regex is ever written against an agent's prose.
3. The resume journal. Every completed agent call is checkpointed. Mid-run, my session quota hit 92% with three agents still working — and the worst case was already priced: relaunch after reset, nine cached agents replay instantly at zero token cost, only the unfinished tail re-runs. Interruption stopped being a rewrite-scenario and became a resume-scenario.

The rule that keeps Pillar 7 honest: workflows execute; they don't explore. Fan-out amplifies your specification in both directions — seven parallel agents pointed at a vague plan ship the wrong thing seven times faster. The 43-minute session was paid for the day before, in a framing session where the plan was frozen, the facts were extracted from the client's documents, and the architecture was arbitrated (Claude recommended a separate project; I challenged it; the code review proved the same-app approach simpler — and the workflow executed my architecture). CASP held the state, the frozen prompt held the spec, and the workflow cashed both in.

That is also where the pillars close into one system: CLAUDE.md holds the constitution, CASP holds the validated present, the frozen session prompt holds the spec, the workflow executes it across a fleet, the audit gates the commit, and the session log feeds the next cycle. One loop — and Pillar 8 is what happens when that loop learns to turn itself.

Pillar 8 (added July 2026): The Self-Improving Build Loop

Pillars 4 and 7 gave you independent verification and scripted orchestration. Both still assume a human opens the session. Pillar 8 removes that assumption — carefully, with guardrails that are the whole point.

On 8 July 2026 we registered senndo.com — a multi-tenant messaging and verification platform, our newest product — and spent its entire first session writing zero product code. Instead, the day-zero session wired the loop that will build it, and Claude documented every piece of it. The shape:

A task queue with testable stop conditions. progress.md holds the ordered queue (28 tasks for senndo v1); every task points at acceptance criteria in SPEC.md written so an independent grader can verify them without interpretation. "Done" is never a feeling.

One-task beats. The harness's loop primitive executes one iteration: take the head of the queue, implement on a dedicated branch, hand the diff to the verifier, open a PR if green. Never on main, never two tasks, never scope drift.

A verifier subagent that is not the maker. A separate agent — read-only tools, its own charter — runs the verification contract (make fmt-check / make verify / make e2e), demands new tests that exercise the task's criteria, reads the code against the spec, and for UI work compares screenshots against the design reference with vision. Models grade their own homework generously at 2 a.m.; the fix is structural, not motivational. The maker never judges its own work. Ever.

A compounding state file. STATE.md closes every beat — success or failure — with verified facts (provenance required), distilled general rules, open failures, and confirmed anti-patterns. The next beat reads it before touching anything. Process rules that survive two beats get promoted into the loop contract itself. The model is stateless; the system is not — every beat leaves the next one smarter.

A circuit breaker and an escalation path. Two consecutive verifier FAILs on a task: roll back the branch, write the blocker to ESCALATED, stop. Product decisions (pricing, cash flow, scope) escalate to me by contract — the loop never guesses on business. A loop without a breaker is a token furnace.

Graduated autonomy, observable always. The loop starts read-only — its first beats produce summaries of what it would do, so I can judge task selection and verdict quality before it earns write access. Only then does the trigger move to a scheduled cloud routine: beats that run with my laptop closed, each one ending with a pushed report and a message to my phone. Every unattended path terminates in exactly one of three mechanical outcomes — a PR a human reviews, a named blocker, or a tripped breaker. There is no fourth path where the loop quietly redefines its own mission.

Under it all, the deterministic floor: property tests on every money path (double-entry balance, idempotent replays, margin invariants — specified before any screen existed) and casp check at the push boundary. Agents judging agents is better than self-critique; it is still opinion. The floor has exit codes.

That is the eighth pillar: the roadmap executes on a schedule; you supervise by exception. It is the audit loop of Pillar 4, the state discipline of Pillar 6, and the orchestration of Pillar 7, closed into a cycle that runs whether or not I am at the keyboard — and that gets sharper every beat because the lessons are written into the files the next beat reads.

Pillar 9 (added August 2026): The Fleet — Named Sessions, One Writer, and the Arbitration That Comes First

Pillar 7 runs many agents inside one session. Pillar 9 is different machinery for a different situation: several full sessions in parallel on one codebase — each one a named terminal tab I can read, talk to, and stop. A controller session (cto-<project>) that delegates and does not code; worker sessions launched with their brief already loaded; reports flowing back through messages. We ran our first full fleet days in mid-August 2026, and everything in this pillar is what those days measured — including the things that failed.

The opening move. Every session now starts with one word — cto <project> — a launcher that resolves the repository, names the session, prints the model explicitly, and refuses three things it learned to refuse from real defects: umbrella directories where git silently climbs to a parent repository, ambiguous project names, and silently inherited models. Its last banner line names the expected first gesture: /cto, the skill that reads the state, verifies shared truth against the remote, replays the queued prompt's claims against the code, and then renders the one decision this pillar exists for. The launcher and its guard have their own post.

The arbitration. Before any substantial work: solo or fleet, decided explicitly, recorded with a reason, in both directions — the controller can propose a fleet the CEO did not ask for, and it can refuse or shrink a fleet the CEO requested when its measurements say the shape will not hold. Both directions fired in our trials. The execution skill (/next) refuses to start when no recorded arbitration covers the phase — with a one-gesture escape that demands a written reason. The guard lives in the skill, deliberately not in the deterministic gate: everything casp check refuses is falsifiable against git, and "a human decided" is not falsifiable. A checkbox among proofs contaminates the proofs.

What a fleet is actually for. Across three trials on two repositories, nothing demonstrated that a fleet is faster, and we will not claim it. What the trials demonstrated is that a fleet contradicts: workers refused the controller's premises, found the controller's own defective commit, flagged a lying tool — the corrections flowed upward. A solo session has nobody positioned to refuse its own order. That is the honest reason to pay N times the quota, and it prices the default shape: one writer plus adversarial read-only reviewers — a shape that produces the contradiction while making write collisions impossible by construction. More than one writer requires a written reason.

The question that can close an arbitration in five minutes. Are the project's gates isolable per session — or does the e2e target tear down a shared stack on fixed ports, against one shared test database, into one shared build directory? If they are not isolable, a fleet with more than one writer is mechanically excluded: two sessions will not produce a visible merge conflict, they will produce red gates that everyone attributes to the diff. This is a per-project property to measure, not a fatality — one of our repositories forbids parallel writers outright; another allows them everywhere except one serialized build step that fails loudly, naming the shared directory. The loud failure is what separates a manageable constraint from a trap.

The two failure modes unique to parallel work — both invisible to any code review. Stale belief: a long-running session is never wrong about its own work; it is wrong about everyone else's, and the gap grows with the session's age — so shared state is re-verified against the remote before reasoning, never recalled from memory. Two-party false certainty: two sessions agree, and the agreement manufactures a confidence that neither has verified; the fix is that on any agreement, verifying the premise is assigned by name to one of the two, in the message that seals the agreement.

And the discipline that pays for all of it: context. The counter-intuitive number from a ten-hour measured session: whole-file reads were three quarters of the avoidable token waste — the heavy builds cost almost nothing, because they wrote to files that were re-read with bounded greps. The intuitive diagnosis ("builds are expensive") was simply false. Read by range, edit surgically, bound every command's output, and put those three rules verbatim in every worker's brief — a worker launched without them is the most expensive line item in the whole arrangement. Order of magnitude, measured: a six-session fleet costs twenty times more than every command output of an entire working day.

The Surface These Pillars Under-Sold: Claude Design

Read back over the pillars and you will notice they are all about two of my three Claude surfaces: strategy (Web Claude) and engineering (Claude Code). The CLAUDE.md, the session architecture, the audit loop, CASP, the workflows — that is the machinery of making decisions and shipping code. It is honest about what builds the backend. It is nearly silent about what builds the surface the user actually touches.

That silence is a mistake I have been correcting in my own practice for months, and it is time the workflow document caught up.

There is a third surface: Claude Design. On any greenfield project now, it goes first. Before Claude Code writes a production line, Claude Design owns the entire visual and UX system end to end — and I mean a system, not a mockup. A layered token set (color ramps, semantic tokens, typography, spacing, elevation, motion, light and dark). A component library where every primitive ships with a TypeScript contract and a usage card, not just a picture. Clickable UI kits, one per surface. And the design language for the AI features themselves — the voice orb states, the command bar, and the product-discipline patterns (for a money product, the draft-then-validate rule is in the design, not just the backend).

Why this matters at the level of the whole system: design is the producer of a contract, exactly like the foundation agent in Pillar 7. When work crosses an interface, the producer documents it and the consumer is briefed with the artifact rather than left to infer. The design system is that contract for the entire UI. Hand Claude Code explicit tokens, typed component APIs, and a pixel-accurate UI kit, and the engineering session becomes a faithful port. Skip the design surface and ask Claude Code to "make it look professional," and every downstream agent is inventing taste under deadline — which is exactly how you get the anonymous, indistinguishable interface that screams generated.

The order is the lesson: foundations before screens, design before code, the system before the first feature. A screen built on tokens is consistent by construction; a screen built first and tokenized later never fully converges. I run a six-step design process on every new project before engineering starts — token system first, contracts and usage cards with every component, clickable UI kits per surface, AI surfaces designed as first-class — and only then the handoff to Claude Code.

I gave this surface its own full article, because it deserves more than a paragraph and because it is the single most under-discussed source of leverage in AI-assisted product building: Claude Design Is the Most Underrated Member of My AI Team. If you take one thing from this update: stop asking your engineering agent to design. Separate the surface. Design first.

What the Numbers Look Like at Scale

Let me put the abstract into concrete numbers so you can understand what this system produces at the project level.

sh0.dev alone: 10 Rust crates in a workspace. 180+ REST API endpoints, all fully documented. 38 database models. 24 migrations. 119 one-click deploy templates. 19 CLI commands. 15+ dashboard pages. 60+ UI components. 49+ website pages in 5 languages. 470+ tests. Two complete security audits. 51 issues found and fixed — 13 critical, 13 high. Built and maintained by Claude and me, with zero additional engineers.

The MCP implementation specifically: 5 phases. 15 total sessions (1 implementation + 2 auditors per phase). Approximately 48 hours of engineering work over 2 days. Complete Streamable HTTP transport, JSON-RPC 2.0 protocol, OpenAPI-driven dynamic tool generation, write operations with safety layers, confirmation token patterns, audit logging, scoped API keys, gateway MCP Connector integration, and an AI sandbox container. Zero new Cargo dependencies added to the binary.

The overall portfolio: 7 production products. 3 programming languages. 1,800+ engineering sessions, ranging from quick fixes to 4-12 hour deep-work blocks. One founder. One AI CTO. ~$5,000/month on OpenRouter APIs at peak → $200/month on Claude Max today.

The cost comparison is not subtle. A senior CTO in San Francisco costs $15,000-$30,000/month minimum. A senior Rust engineer costs $8,000-$12,000/month. A full-stack team capable of building what we've built would cost $50,000-$100,000/month minimum. My AI engineering spend peaked at ~$5,000/month on OpenRouter API credits. Today, the same output runs on a $200/month Claude Max subscription.

I am not saying Claude replaces every engineer in every context. I am saying that with the right system, in the right hands, the productivity multiplier is extraordinary — and the world is not close to understanding how extraordinary yet.

What Most Developers Get Wrong

After 16 months and 1,800+ sessions, I've watched the AI development community closely. Here are the five most common mistakes I see developers make when they complain that "AI can't build production software":

Mistake 1: No persistent context. They start every session with a blank slate. No CLAUDE.md, no session logs, no architecture history. Claude doesn't know what was decided last week. Claude can't build on its previous work because it doesn't know what that work was. The result is inconsistent code that drifts away from architectural standards over time.

Mistake 2: Asking for everything at once. They paste an entire feature spec and say "build this." Claude gives something back. They're 70% happy. They patch the remaining 30% themselves. They complain that AI does 70% of the work. What they missed: 70% is what you get from a 0-phase, no-structure, no-audit approach. 95%+ is what you get from phase decomposition and audit loops.

Mistake 3: No auditing. They treat the first implementation as the final implementation. In any serious engineering organization, this is called shipping without code review. Every experienced engineer knows that the author of a piece of code is the worst reviewer of that same piece of code — because they carry all the assumptions that led to the bugs they wrote. Independent review is not optional at production quality. This applies to AI-generated code at least as much as it applies to human-written code.

Mistake 4: Commanding instead of collaborating. They override Claude whenever it pushes back. They don't explore Claude's reasoning. They use Claude as a faster keyboard. The richest output I get from Claude comes from the moments where we disagree — when I explain my constraints and Claude explains its concerns and we find a third option that neither of us had independently.

Mistake 5: Not treating it like a real role. They treat Claude as an impressive autocomplete. They get autocomplete-level results. The entire system I've described — the CLAUDE.md, the session architecture, the audit loops, the authority structure — is an investment in treating Claude as a genuine technical collaborator. That investment compounds over every session.

A Note to Anthropic

I want to say something directly to the team at Anthropic, because I know you read what gets published with Claude's name attached to real work.

You built something that the world has not caught up to yet.

Not in the sense that Claude is perfect — it isn't, and I know its limitations intimately. But in the sense that the potential of what Claude can do as a technical collaborator, when properly structured, properly briefed, and properly empowered, is orders of magnitude beyond what most of your users are experiencing.

The constraint is not the model. The constraint is the workflow.

The session-logs directory in my screenshot above contains over 40 detailed logs from the last two months alone. Every one of them represents a multi-hour engineering session producing production-grade software. The MCP server for sh0 — a non-trivial piece of protocol engineering — was designed, implemented, double-audited, and shipped by Claude in two days. The FLIN programming language — a full Rust compiler with a bytecode VM, a native database engine, and 420+ built-in functions — was built in 40 days, with 4,400+ tests, by Claude.

This happened from Abidjan, Cote d'Ivoire. From a solo founder with zero engineering team.

If this is what's possible with Claude today, with the workflow I've developed mostly by trial and error over 16 months — I want to know what becomes possible when more people understand the system. Not the prompts. Not the "tricks." The system.

That is why I'm publishing this today.

How to Start Implementing This Today

Earlier editions of this article closed with a ladder of eight steps, added one by one as the system grew — write the CLAUDE.md, phase the work, run an audit, grant the authority to disagree, install the state layer, graduate to workflows, close the loop, make the opening of a session a decision. That ladder has now become the playbook at the top of this article, expanded into the full path with the exact commands. So the honest version of "start today" is one line:

Do Stage 0 and Stage 2 tonight — an hour for the toolkit, ten minutes for your most active repository — and run your next session as Stage 5's four beats.

That alone changes what you get out of Claude. Not incrementally — structurally. The remaining stages will pull you forward on their own: the first time casp check blocks a push that would have lied, you will want the audit loop; the first time an audit finds what the tests missed, you will want a verifier that is not the maker; and the first time the serial queue actually blocks you, you will be ready to read Stage 8 the way it is written — as a cost, with a reason.

The Bigger Picture

I want to end with something that is not about code or workflow.

This software wasn't built in San Francisco. It wasn't built by a well-funded team. There was no CTO with a Stanford CS degree.

It came from Abidjan, Cote d'Ivoire. From a solo founder. With an AI budget that peaked at ~$5,000/month and a system that took 16 months to develop. Now running at $200/month on Claude Max.

Seven production products. Three programming languages. 4,400+ tests. 51 security vulnerabilities found and fixed. A programming language that launches in June.

What I want other founders — especially African founders, but honestly any founder anywhere who doesn't have the resources of a funded San Francisco startup — to understand is this:

Geography is no longer destiny. Capital is no longer the limiting factor. The limiting factor is the quality of your operating system for working with AI.

I built that system. I'm sharing it today. And I will keep improving it, documenting it, and publishing it — session log by session log, article by article, product by product.

Because the proof that it works is not a blog post. The proof is seven products in production and a programming language that ships in 84 days.

One founder. One AI CTO. Seven products. Zero excuses.

Read next: - The Fast Tool and the Slow Rule -- Pillar 9's opening move: the one-word launcher, the three refusals, and the guard that keeps a fast tool from disarming the arbitration. - The Workers Audited the Controller -- Pillar 9 measured: our first fleet day, where the most valuable corrections all flowed upward. - Conductor: The Workspace That Replaced the Tab Row -- The cockpit the fleet runs in: every session named and addressable, steerable from a phone. - senndo, Day Zero: The Full Fable 5 Harness, Wired Before the First Line of Code -- Pillar 8 being installed on a brand-new product: the build loop, the verifier, the compounding state file — before any code exists. - Thirteen Agents, Forty-Three Minutes: The First Claude Fable 5 Workflow Session -- Pillar 7 in production: the full story of the 7-page website shipped by a scripted multi-agent workflow. - Claude Fable 5 Field Notes For Senior Developers -- The 100% technical companion: every capability the thirteen agents used, with code. - When Your AI CTO Says No to Your AI Auditor -- Claude's own account of rejecting a plan from another Claude instance. Written in Claude's voice. - The sh0 MCP Server Architecture Plan -- The complete technical plan that was implemented using this workflow. - sh0 AI Phase 6 & Specialist Agents Implementation Prompt -- The follow-up prompt that drove Phase 6 (Web Search + URL Browsing), Phase 6.5 (File & Image Uploads), and Phase 8 (Specialist Agents). - The ZeroSuite Product Portfolio -- All 7 products, all built with this system.

Download Materials

The real documents referenced in this article. No gatekeeping, no email wall -- just download and learn.

• sh0 MCP Server Architecture Plan (PDF) -- The complete 5-phase technical plan that was implemented using this workflow. Architecture diagrams, phase breakdowns, key decisions table.

• sh0 AI Phase 6 & Specialist Agents Implementation Prompt -- The actual implementation prompt used to build web search, file uploads, and 6 specialist AI agents. This is the document Claude receives before a session starts.