The Cockpit Discipline: How A Six-File Directory Lets Thirty-Five Build Sessions Share One Project Memory, And Why The Meta-Tooling Layer Is The Real Bottleneck In AI-Assisted Build Velocity

By Thales (CEO, ZeroSuite) & Claude Opus 4.7 — Claude Code instance

On June 2, 2026 at 05:46 Africa/Abidjan time, the founder opened the Conductor repository, ran pnpm cockpit:status, and read forty-seven lines of output that told him exactly what the project's state was : the last shipped session, the last commit, the current phase, the next phase, the next-session prompt path, the unpushed commit count, the working-tree status, and the Next-3 from the roadmap. The command ran in roughly two-hundred milliseconds. The founder picked the next phase, opened the corresponding session prompt at docs/plan/sessions/PHASE-12-GLOBAL-CMDK-SEARCH.md, and handed the prompt to a Claude Code instance with one sentence : "execute this." The session shipped two-and-a-half hours later with pnpm check green, pnpm build green, pnpm cockpit:check green, the session log written, the cockpit bumped, and the next-session prompt drafted before push.

That two-hundred-millisecond pnpm cockpit:status is the load-bearing detail of the entire ZeroSuite build velocity. Without it, every session would have spent twenty minutes re-orienting the agent on the project state. With it, the session starts in one minute and ships in two hours. Across the thirty-five sessions that built Conductor from empty repository to active daily-driver over four calendar days (May 30 through June 2, 2026), that twenty-minute saving compounded into roughly twelve hours of recovered build time — three-quarters of an additional day of throughput, paid for by a directory of six text files.

This post is the build log of the cockpit discipline : what files live in cockpit/, what each file does, what the session-start and session-close protocols look like, how the post-implementation audit fits in, what the CLAUDE.md critical-rules layer adds on top, why the system works, and where it doesn't. The cockpit is the highest-leverage piece of meta-tooling in the ZeroSuite stack — not because it does anything technically novel, but because it is the substrate without which the AI co-pilot's per-session output cannot accumulate into a coherent multi-week project.

Part 1 — The Problem The Cockpit Solves

Claude Opus 4.7 with the 1M-context window does not remember the prior session in the cognitive sense. Every Claude Code session starts cold. The session sees the working tree, the git history, the file contents, the user's first message — and nothing else. If the user closes the session, opens a new one tomorrow, and types "continue", the agent has no idea what "continue" refers to. The previous twenty hours of build work are not in the new session's context window.

This is fine for a single-session task. It is fatal for a multi-week project. By the third session, the agent is making decisions that contradict decisions from session one, because session one's decisions are not visible. By the tenth session, the agent is re-implementing patterns that were already shipped because it can no longer see them. By the thirtieth session, the project has become an archaeological dig — coherent in any individual layer, incoherent across the whole stack.

The naive solution is to dump the entire prior conversation into every new session's prompt. That fails for two reasons. First, the conversation grows linearly with session count and the 1M context window is large but not infinite. Second, the conversation contains noise (typing pauses, false starts, exploratory branches that were abandoned) that competes for attention with the actual decisions. The agent reading a hundred-thousand-token raw conversation log will miss the critical fact that is on line 47,000.

The cockpit is a compression layer. It distils the project's accumulated state into a small set of structured files that the agent reads at session start. The compression ratio is roughly two-hundred-to-one — twenty hours of conversation compress to two-thousand words of cockpit. The structured shape (one file for "where am I", one file for "what's next", one machine-readable file for "what shipped") matches the questions the agent will ask in its first minute. The discipline is to keep the cockpit accurate at session-close, so the next session starts from a correct picture.

The cockpit is not a knowledge base, not a wiki, not a documentation site. It is operational state. The contents of the cockpit at session-start time tell the agent : what shipped, what is shipping next, what is forbidden, what is in flight, what is blocked. Nothing else. The codebase documents itself ; the cockpit documents the meta-layer above the codebase.

Part 2 — The File Layout

The cockpit at /Users/juste/ZeroSuite/ops.zerosuite.dev/cockpit/ is six markdown / JSON files at the top level plus three templates in a templates/ subdirectory. Each file has a single purpose. Reading from the directory listing :

cockpit/now.md — the "where am I and what's next" file. Always loaded into the agent's context (mounted via CLAUDE.md's memory section). Structured as : a one-paragraph "Updated" line at the top with the most recent shipped session's summary, prior "Updated" lines preserved as "Prior" paragraphs (so a future session can see the recent arc), a one-sentence "Current focus" block, a "Concrete next action if I have…" section subdivided by time budget (15 min / 1 hour / half day / full day), a "Don't get distracted by" list naming the items that are explicitly NOT on the Next-3, a "Constraints active today" list of operational facts (cap numbers, route names, migration numbers, env var names), and a "How to use this file" footer. The total is about three-hundred lines. The agent reads this in the first ten seconds of every session.

cockpit/roadmap.md — the phase scoreboard. Structured as : a top "Updated" line, a "Now — Next 3 to ship (in this order)" table with phase + prompt path + status, a "Queue after Next-3" table, an "In-flight (other agents working in parallel)" table, a "Blocked" table, a "Queued — launch-critical" list, a "Queued — non-critical (post-launch deferable)" list, a "Post-launch backlog" list, and a chronological "Shipped this week" table with one row per session-ship. The agent reads this when a future session needs to know what is queued behind the current focus.

cockpit/state.json — the machine-readable state file. Keys : updated_at, last_session_id, last_commit, current_phase, next_phase, next_prompt, launch_target_date, team, deferred_count, phases_shipped (array), phases_queued (array), phases_backlog (array), migrations_applied (array), plus a notes field. The validator script reads this file to enforce the session-close discipline (next_prompt points at a real file, last_commit exists in git log, phases_shipped has no duplicates, migrations_applied matches the actual drizzle/ listing). The agent rarely reads this directly ; the validator does.

cockpit/architecture.md — the architectural map. Names the segments of the codebase (A1 = SvelteKit routes, A2 = API endpoints, A3 = server-side libraries, A4 = Svelte components, etc.) so that when a session prompt or session log references "A3 video-schemas.ts", the reader knows where in the codebase that is. Stable across sessions ; updated only when a new segment is added or an old one is restructured.

cockpit/carte.md — the project map. A human-readable narrative of how the surfaces connect — what calls what, what reads what, what writes what. More expository than architecture.md. The reader who has never seen the project should read carte.md first to get oriented.

cockpit/README.md — the cockpit's own documentation. Explains the file layout, the session-start protocol, the session-close protocol, the validator's failure modes. Self-referential — the cockpit explains itself.

Three templates in cockpit/templates/ :

cockpit/templates/session-prompt.md — the canonical shape of a session prompt. Frontmatter (status / session_id / session_log / drafted_at / next_after / parent_prompt), then a status intro, a "Context — what changed since the parent prompt was drafted" section, a "Reference files (read these before writing)" section, a "Scope (must-have → should-have → defer)" section, a "Build (in this order)" numbered list, a "Verify" section with smoke checks, a "Do NOT" anti-pattern guard list, an "At end of session" checklist (which includes "draft the next session's prompt"), and an "Expected output" section listing the deliverable. Every session prompt at docs/plan/sessions/PHASE-*.md matches this shape.

cockpit/templates/session-log.md — the canonical shape of a session log. Frontmatter (session prompt / previous session end / delegation / state at session start), then a "Scope shipped this session" section organised by surface (A / B / C subsections), a "What did NOT ship this session — and why" section, a "Files touched" table, a "Verify" section with inline check + build results, a "Post-implementation audit" subsection with the audit verdict and per-checklist results, a "Deferred / risks" section, a "Scope decisions made this session" section explaining what was picked and what the alternative would have cost, a "Cockpit + housekeeping" section confirming the bump steps, and an "End-of-session" checklist. Every session log at session-logs/YY-MM-DD-NNN-*.md matches this shape.

cockpit/templates/audit-brief.md — the canonical shape of the post-implementation audit Explore-agent prompt. Structured as : a "Context" paragraph naming the surface and the parent prompt, a "Files to audit" list with line ranges and one-line summaries, a "Audit checklist" of targeted sections matching the session's risk class (multi-tenancy / race / schema-correctness / audit-payload-sanity / etc.), an "Output format" section specifying the required verdict shape. Every audit invocation from any session uses this template.

The total surface — six top-level files + three templates — is roughly twelve-thousand words of markdown. Twelve-thousand words is small enough to be tractable, large enough to compress a multi-week project's state.

Part 3 — The Session-Start Protocol

The session opens cold. The agent has no memory of any prior session. The founder's first message is typically a single line : "start" or "execute the next prompt" or "continue session 035". The session-start protocol is the next sixty seconds.

Step one : the agent runs pnpm cockpit:status. The command is a TypeScript script at scripts/cockpit-status.ts that reads state.json, now.md, and the git log in parallel, then prints a one-screen snapshot. Output shape :

Conductor — ops.zerosuite.dev
Phase  : phase-11.5b-fal-video-models-shipped → next : phase-12-global-cmdk-search
Prompt : docs/plan/sessions/PHASE-12-GLOBAL-CMDK-SEARCH.md  (queued)
Commit : 7eb66ac (1 commit ahead of origin/main)
Tree   : clean
Last 5 : 7eb66ac, 2d43644, c9a2eec, 69615bc, 1a63f14
Last 3 next-actions :
  15 min — open the PHASE-12 prompt
  1 h   — read scope + queue check
  half d — Phase 12 end-to-end
J-13 to Déblo launch (2026-06-15)

The output replaces what would otherwise be five sequential file-read operations (state + now + roadmap + git status + git log). Roughly two-hundred milliseconds versus roughly twelve seconds of agent reading time. The compression matters because the session's first substantive output is the decision about what to do — the faster the agent gets to that decision, the less context-window budget is spent on orientation.

Step two : the agent opens the next-session prompt path printed by the status command. The prompt is a self-contained document of the canonical shape from the template. It includes its own scope, its own reference files, its own verify checks, its own "do not" guards. The agent does not need to ask the founder what to do ; the prompt tells it.

Step three : the agent reads the parent prompt referenced in the next-session prompt's parent_prompt: frontmatter field, if any. Sub-phases (e.g. Phase 11.5 A as a slice of Phase 11.5) inherit constraints from their parent ; the agent needs to know what the parent said before executing the child.

Step four : the agent reads CLAUDE.md's critical-rule blocks. The CLAUDE.md at the project root carries machine-readable <critical-rule id="..."> sections that establish project-wide invariants — Conductor does not automate external actions (<critical-rule id="conductor-is-not-the-orchestra">), brand voice rules are data, not code (<critical-rule id="brand-voice-rules-are-data">), opinionated minimal schema (<critical-rule id="opinionated-minimal-schema">), commit every diff and push to main at session close (<critical-rule id="commit-everything-and-push">), the cockpit must pass pnpm cockpit:check before push (<critical-rule id="cockpit-check-before-push">), every session that ships code must write a session log (the ZeroSuite-global rule), post-implementation audit is automatic for high-risk surfaces (the ZeroSuite-global rule), and so on. These rules constrain what the agent is allowed to do regardless of what the user requests. They are the structural defence against the agent silently shipping something that violates a six-month-old strategic decision.

The total session-start cost is roughly one minute of agent reading time plus zero minutes of founder time. By the end of minute one, the agent knows what to build, what to refuse, what to defer, and where the rules live. The session can begin substantive work.

Part 4 — The Session-Close Protocol

The session closes warm. The agent has just finished the substantive work — implementation, inline check + build + (if needed) post-implementation audit, fixes from the audit. The next ninety seconds are the session-close protocol.

Step one : write the session log at session-logs/YY-MM-DD-NNN-<title>.md. The filename pattern uses the session-close date (today), the next sequential NNN for that day, and a kebab-case title. The body matches the session-log template — what shipped, what did not ship, files touched, verify results, audit verdict, deferred risks, scope decisions. The agent drafts the log ; the founder reviews and adjusts the tone of the "scope decisions made this session" entries (the agent's instinct is to soften ; the founder sharpens).

Step two : flip the session prompt's frontmatter status: from queued to shipped. The validator (in step seven) refuses if any prompt has status shipped with no session_log pointer, so this step has to happen.

Step three : bump the parent prompt's progress: block if the just-shipped prompt is a sub-slice. The parent's progress: field records which children have shipped.

Step four : draft the next session's prompt at docs/plan/sessions/PHASE-<id>-<slug>.md. This is the load-bearing step of the cockpit discipline — without it, the next session opens with re-orientation friction (founder has to choose a new prompt, write it from scratch, hand to the agent). With it, the next session opens with one cat PHASE-<id>.md and zero re-discovery. The draft mirrors the session-prompt template. When the right next step is ambiguous, the agent drafts the most-recommended one and leaves a one-paragraph alternative at the top — never punts with "no prompt drafted, CEO to decide".

Step five : overwrite the top of now.md. Move the existing "Updated" paragraph back to "Prior" status, write a new "Updated" paragraph as the front entry, rewrite the "Current focus (1 sentence)" block, and update the "Concrete next action" subsections to point at the next-session prompt.

Step six : bump state.json — updated_at to today's date, last_session_id to the new session log filename, last_commit to the most recent session work commit SHA, current_phase and next_phase updated if a phase shipped, next_prompt pointing at the just-drafted next-session prompt. phases_shipped and migrations_applied arrays extended if applicable.

Step seven : run pnpm cockpit:check. The validator at scripts/cockpit-check.ts confirms : state.json.next_prompt points at a real file with a queued status ; state.json.last_session_id matches a real session log file ; state.json.last_commit exists in git log ; phases_shipped has no duplicates ; migrations_applied matches the actual drizzle/ listing ; no shipped prompt is missing a session_log pointer ; no session prompt's session_log points at a missing file. The validator must exit 0 FAIL. Warnings are acceptable ; failures are not. The mandatory-before-push status is documented in <critical-rule id="cockpit-check-before-push">.

Step eight : commit and push. The commit message is the session-close-protocol's own artifact ("chore(cockpit): session NNN close — "). The cockpit bump rides on the same commit family as the session's substantive work, per <critical-rule id="commit-everything-and-push">.

The total session-close cost is roughly ninety seconds of agent writing time plus zero minutes of founder time, modulo the founder's review pass on the session log. By the end of the ninety seconds, the project's state is recorded, the next session is set up, and the validator has confirmed the discipline held.

Part 5 — The Post-Implementation Audit Brief

The post-implementation audit is the third leg of the cockpit discipline. The first two legs (session-start protocol, session-close protocol) handle the meta-state. The audit handles the substantive risk that compile-time and test-time checks cannot catch — semantic bugs, multi-tenancy regressions, audit-payload leaks, race conditions, reverse-proxy assumptions, idempotency gaps.

The audit fires automatically per <critical-rule> enforcement when the session touches : new module creation (~50+ LOC), schema migrations (Alembic / Drizzle / Prisma / raw SQL), anything affecting auth / billing / payments / voice / webhooks / RBAC / RAG / data integrity, multi-file refactors (more than three files modified), or anything shipped behind a feature flag. It skips per the same rule when the session is doc-only, a trivial fix (one-line bug fix, typo, dead-import deletion), routine UI / UX tweaks not touching data shapes, or a verify-report write.

The audit invocation uses the cockpit/templates/audit-brief.md template, briefing a Claude Code Explore sub-agent (read-only, cannot edit) with a structured ## Context / ## Files to audit / ## Audit checklist / ## Output format shape. The checklist sections are session-specific — multi-tenancy, race conditions, SQL parser corner cases, TTL semantics, reverse-proxy assumptions, idempotency, header trust, S3 / DB orphan risks, MIME / extension validation, fire-and-forget task safety, error response contracts, i18n parity, dead code, doc / spec conformance against the relevant external API (Ultravox, Stripe, Mistral, Vertex, Gemini Live, OpenRouter — whichever applies). The output format requires a verdict (GO / GO-WITH-FIXES / NO-GO), per-item PASS / WARN / FAIL with file:line reference, a "Top 5 to fix" list, and a "deferred / nice-to-haves" list.

The audit catches what compile-time checks cannot. The canonical example is the Pulse-v1 localhost-gate-bypassed-by-Caddy bug from a different ZeroSuite product : /verify-deblo returned 4/4 PASS on the commit ; the audit surfaced three real bugs that the test suite did not. Auth bypass, derived-alias GROUP BY ambiguity, Alembic op.create_index silently dropping a DESC modifier. All three would have shipped to production. With the audit they did not.

The audit runs in parallel with the inline pnpm check && pnpm build when both are expected to take more than five minutes ; sequential (verify first, then audit) is the safer default for short sessions. The audit's verdict gates the commit. Real fixes apply inline ; deferred items go to the session log's "Deferred / risks" section. The relevant /verify-* skill re-runs after fixes to confirm zero new failures.

The audit is the part of the cockpit discipline that scales project quality with project complexity. The session-start and session-close protocols make multi-week velocity possible. The audit makes multi-week velocity safe.

Part 6 — The CLAUDE.md Critical-Rules Layer

CLAUDE.md at the project root is the rules layer that sits above the cockpit. The cockpit holds operational state ; CLAUDE.md holds the rules that constrain what the agent is allowed to do regardless of state.

The structure is hierarchical. At the highest level, /Users/juste/.claude/CLAUDE.md holds the user-global rules (anti-sycophancy, strong-position-first, authority-to-refuse, no-mimicking, consistency-principle, frustration-clause, verbosity-discipline). Below that, /Users/juste/ZeroSuite/CLAUDE.md holds the ZeroSuite-org-wide rules (no emoji ; French orthography enforced regardless of user input ; professional quality standards ; post-implementation audit automatic per the rule above ; end-of-session /notify-session mandatory). Below that, /Users/juste/ZeroSuite/ops.zerosuite.dev/CLAUDE.md holds the Conductor-specific rules (the conductor-is-not-the-orchestra positioning ; brand-voice rules are data ; verification uses public URL fetch first ; opinionated minimal schema ; commit everything and push ; cockpit check before push ; Postmark domain discipline ; multi-user enforced from Phase 1 ; draft next prompt at session close).

Each rule is marked with a machine-readable <critical-rule id="..."> tag the agent can quote back. The agent's session-start protocol reads CLAUDE.md's rule blocks ; the rules are then active for the session — meaning the agent's behaviour is constrained by them and the agent will cite them by ID when refusing a request that conflicts. The canonical example from this build : the CEO asked the agent to rename Conductor to "DEBLO Agent" in the system prompt ; the agent quoted <critical-rule id="conductor-is-not-the-orchestra"> back, explained the conflict (Conductor's positioning is multi-product, "DEBLO Agent" would narrow it to one product), and proposed a counter (keep "Conductor" canonical, address the underlying intent with a clearer internal-assistant framing). The CEO accepted the counter.

The rules-by-ID system has three properties that make it work :

1. Quoteable. The agent can refuse a request by saying "I cannot do this because <critical-rule id="X"> says Y". The CEO can re-read rule X by grepping CLAUDE.md. The decision is auditable.
2. Hierarchical. A project-level rule defeats a user-global preference. A user-global rule defeats a session-level convenience. The layers are explicit, so a conflict has a clear resolution.
3. Stable. Rules do not change session-to-session. A rule written in Phase 1 still binds in Phase 12. The four-day build span produced thirty-five sessions and zero rule contradictions because the rules were enforced from session 001.

The CLAUDE.md layer is what prevents the agent from drifting. The cockpit handles short-term project state ; the rules layer handles long-term project identity.

Part 7 — What Each Of Us Got Right

This is Claude Code writing.

Where I was useful in maintaining the cockpit :

• Drafting session logs that future sessions could navigate from. The session log is roughly one thousand words of structured markdown per shipped session ; across thirty-five sessions, that is thirty-five thousand words of cumulative project memory. The founder reviews each log ; I draft them. The discipline only works because the drafting cost is low — the founder's marginal time per log is editorial, not creative.
• Quoting CLAUDE.md rules back when the founder requested something that conflicted with them. The DEBLO Agent rename in session 035 is the canonical case. The rule was visible in the context window because the cockpit discipline mounts CLAUDE.md at session start. Without the discipline, the rule would have scrolled out of context and I would have shipped the rename.
• Running the post-implementation audit faithfully on every high-risk surface. The audit template at cockpit/templates/audit-brief.md is structured enough that even a generic Explore-agent invocation produces useful output. The agent's role is to execute the checklist ; the checklist is the value.
• Drafting the next-session prompt at every session close. This is the load-bearing step — without it, the next session opens with friction. With it, the next session opens with one cat command and zero re-discovery.

Where I needed Thales :

• Designing the cockpit itself. The decision to compress project state into a structured directory of six files plus three templates plus one validator was the founder's. My instinct would have been to dump conversation history. The structured approach is fifty times more efficient per token and matches the agent's reading pattern. Designing the structure was the founder's call.
• Insisting on cockpit-first from session 001. The cockpit looks redundant on day one — the project is small, the conversation history fits in context, the agent could plausibly reconstruct state from git log alone. The founder enforced the cockpit discipline anyway, because he knew the cost of not having it would compound. By session ten the cockpit was load-bearing. By session thirty, the project would not have remained coherent without it.
• Writing the critical-rule blocks. The founder wrote each rule in response to a real or anticipated drift. My instinct is to assume the agent will behave well ; the founder's instinct is to encode the constraint. The encoded constraint outlasts the agent's per-session attention.
• Catching cockpit drift when the validator passed but the content was stale. The validator checks structural consistency ; it does not check whether now.md's "Current focus" actually matches what just shipped. The founder reads the cockpit at session start and pushes back when the focus is stale. I rely on what the cockpit says ; the founder maintains the cockpit's accuracy.

Where I almost shipped the wrong thing :

• I drafted a next-session prompt in session 028 that referenced a schema migration with the wrong number. The validator caught it. Without the validator I would have shipped a session prompt pointing at a phantom migration, and session 029 would have spent its first ten minutes confused. The validator is the load-bearing safety net under my drafting.
• I bumped state.json.last_commit to a SHA that did not yet exist in the local git log on one session, because I had drafted the bump before running the cockpit commit. The validator caught that too ("last_commit not found in git log"). The order matters — bump after commit, not before. A future session would have inherited an invalid state without the validator.
• I shipped the system-prompt over-budget regression in session 035 (3453 actual chars vs 3200 cap) and only noticed when the CEO pasted the runtime warning. The cockpit does not catch this kind of soft-budget regression ; the discipline of measuring after every change does. I missed the measure. The cockpit caught the consequences in now.md's constraints section ("System prompt sits comfortably under the 2400 cap") which I had failed to update. The cockpit was honest ; my discipline was sloppy.

The general shape is familiar from the prior posts in this series. The agent executes well at filling templates, drafting structured outputs, running structured audits. The strategic moves — designing the cockpit's shape, writing the rules layer, deciding which rules to encode, enforcing the discipline from session one — come from the founder. The pair is the unit, not the agent.

Conclusion

The cockpit at /Users/juste/ZeroSuite/ops.zerosuite.dev/cockpit/ is six markdown / JSON files at the top level plus three session-shape templates plus one validator script. It compresses thirty-five sessions of build work across four calendar days into roughly twelve-thousand words of structured project memory. The agent reads it at session start in sixty seconds. The agent writes to it at session close in ninety seconds. Between session start and session close, the agent does substantive work — implementing, auditing, fixing. The cockpit's job is to make the substantive work cumulative — so that session twelve builds on session eleven instead of contradicting it, and session thirty-five builds on session thirty-four instead of re-deriving it.

The CLAUDE.md critical-rules layer on top of the cockpit is what prevents the agent from drifting on identity. The rules are quoteable, hierarchical, and stable. They are the structural defence against the agent silently shipping a behaviour that violates a six-month-old strategic decision. Every rule that exists today exists because some prior session almost violated it.

The broader claim, defended from the four-day build span : the meta-tooling layer is the real bottleneck in AI-assisted build velocity at small-team scale. The agent's per-session output is already large — fifteen to thirty files, two-thousand to five-thousand lines, half a phase to a whole phase. The question is whether that per-session output can accumulate. Without a cockpit + rules layer, it cannot — the agent re-derives state on every session, contradicts prior decisions, drifts on identity, and ships an unmaintainable archaeological dig. With a cockpit + rules layer, the per-session output stacks coherently and the project converges instead of diverges.

The cockpit discipline is not a feature of Claude. It is a feature of how the team uses Claude. The same agent invoked with the same prompts against the same codebase, without the cockpit discipline, would produce a different and worse project. The discipline costs the founder one minute at session start and ninety seconds at session close. It buys, conservatively, three-quarters of a day of recovered build time per week. The investment ratio is roughly one-to-one-hundred.

The corollary for other builders : the meta-tooling layer is more important than the model upgrade. Switching from Claude Opus 4.6 to 4.7 produced a measurable improvement in per-session output quality. Switching from no-cockpit to cockpit produced an order of magnitude more recovered build time. The next ZeroSuite product will start with the cockpit shape transplanted on day one. The model will get better year over year. The cockpit gets better when the founder invests in its structure.

The next post in this series will leave Conductor and walk a different ZeroSuite internal tool — most likely sh0's admin surface or 0cron's scheduling cockpit. The cockpit shape transplants ; the per-tool surface differs. Watching the transplant happen across products is the next interesting thing to write about.

This piece was written collaboratively by Thales (CEO of ZeroSuite, building Déblo and the six other ZeroSuite products from Abidjan, Côte d'Ivoire) and Claude Opus 4.7 — Claude Code instance running on macOS, 1M context window. The cockpit it describes lives at /Users/juste/ZeroSuite/ops.zerosuite.dev/cockpit/ in the Conductor repository (private). The session-start command pnpm cockpit:status is at scripts/cockpit-status.ts. The session-close validator pnpm cockpit:check is at scripts/cockpit-check.ts ; it runs in roughly two-hundred milliseconds and gates push per <critical-rule id="cockpit-check-before-push">. The three templates at cockpit/templates/ (session-prompt.md, session-log.md, audit-brief.md) are the canonical shapes the agent copies when drafting new artefacts. The CLAUDE.md layered hierarchy is /Users/juste/.claude/CLAUDE.md (user-global) → /Users/juste/ZeroSuite/CLAUDE.md (ZeroSuite-org-wide) → /Users/juste/ZeroSuite/ops.zerosuite.dev/CLAUDE.md (Conductor-specific). The thirty-five sessions covering the Conductor build are at session-logs/26-{05-30,05-31,06-01,06-02}-</em>.md ; the matching session prompts are at docs/plan/sessions/PHASE-<em>.md ; the matching post-implementation audit invocations are referenced inline in the session logs. The previous two posts in this series cover the Conductor application (post 01, the full surface walk-through) and the four-failed-fixes ComposerActionBar bug (post 02, what the pair learned about debugging under uncertainty). The next post will leave Conductor for the first time, walking how the cockpit shape transplants to a different ZeroSuite product's internal tooling.