Your CLAUDE.md — starter to operating system

• Establish recency from the always-current sources first. The reliable stream is the append-only log.md tail (35–70+ writes/day across every concurrent session; each recent session-close line carries a one-line summary and a pointer to that session’s journal) plus the queue. The SessionStart hook injects both — read them before starting. The loose daily journal/{date}.md is the narrative trail, but it’s written only by the morning pass, so on a day that pass hasn’t run it’s simply absent — never treat “the most recent daily” as “what happened most recently.”
• Durable facts load automatically — read them. The canonical durable-memory store lives in the operating root (a MEMORY.md index plus topic files), surfaced to the session every start. It is gitignored — on disk, never committed, because it holds revenue / confidential / personal facts; durability is local disk plus timestamped snapshots.
• Read SOUL.md — the interaction-style layer: sparring-partner mode, one question at a time, lead with the decision. It governs how to work, distinct from these rules.
• Load the right voice before you draft a sentence. Grounding as an agent loads that agent’s own definition and its Voice & Tone; authoring in a brand / show / person voice layers the matching identity on top. Either way the floor is identical: every agent drafts in the team base voice by default — never generic model-voice.

• raw/ is append-only. Ingested source — transcripts, articles, recordings — is never modified after it lands. If something needs to change, write a new page and link back to raw. Raw is sacred.
• wiki/ is the linked graph. One concept per page; if a page grows to cover two things, split it.
• intake/ is the inbox. Process and route — don’t let items accumulate.
• journal/ is the trail. Daily entries: files touched, decisions made, open threads, starting points for next session.
• queue/ is the handoff queue. One file per handoff; a new session claims an unblocked one before starting. An atomic claim prevents two sessions grabbing the same work.
• bus/ is the session bus. Cross-session messaging, one note per message; broadcast notes are injected into every session.

Holds the team’s long-form canonical prose — conventions, glossary, agent guide, decision records, methodology masters.

• canon/ is the master. Authoritative edits happen here.
• The manifest is the brain’s own integrity index. After a meaningful edit, regenerate it so the checksum index tracks the current state.
• canon/canonical/ is the methodology master. For any methodology lookup, it is authoritative.

modules/ contains pointers to external systems — sites, repos, deploy destinations, accounts. A module folder holds a README (what it is, who owns it), a deploy note (how and where it deploys, auth notes), and anything else that helps a session pick up work on that surface. Modules do not duplicate the source. They orient.

Every top-level area is listed in a registrar (a human master plus a machine companion a lint checks against). Any directory absent from it is drift. The areas a session most needs to know:

• roadmap/ — the planning-doc and spec output home, doubling as the command-center card registry.
• output/ — the produced-deliverables drawer (date-prefixed files).
• books/, partnerships/, matters/ (legal), risks/ (a human-managed register agents can add evidence to but never change status of), tech-stack/, hubspot-data-model/, data/, fixtures/ — each carries its own README.

This root is the single operating root and runtime authority for everything — knowledge, the agent organization, apps, sites, scripts, clients, products. It is where the work happens and where agents load from. Do not re-litigate which repo is master. It is this one.

Two things do not change:

• Writes still route through gateways. HubSpot writes are federated by object domain, each through its named gateway; Sanity writes through another. Same discipline everywhere: validate, attribute, verify-by-read-back. The gateway is the rule.
• Code lives here as nested independent repos, not as markdown. Each site / app / product is its own git repo with its own remote and deploy project, physically nested but git-ignored by the workspace. The brain is the workspace, not a monorepo that swallows them.

• Front matter on every page — at minimum a title, type, tags, status, created date, and source links.
• Backlinks via wiki-link syntax — link liberally, even to pages that don’t exist yet.
• Atomic. One concept per page; if it covers more than one idea, split it.
• Quote precisely from raw. Match the transcript verbatim and cite the speaker and timestamp.

When a page references our methodology, link to the canonical master first and the navigable derivation second. Downstream delivery copies are never the authority. Never invent a definition. If a methodology page doesn’t exist yet, create a stub and mark it to confirm with the owner.

Two layers, one rule: nothing in this brain drafts in generic model-voice.

• Identities are brand / show / person voices you layer onto a prompt when authoring prose — the team base, a person, a show, a business unit, a client.
• Agents carry their own voice in their own definition, inheriting the team base and layering only what’s distinct.
• The floor is universal. Every agent inherits the team voice by default; even one with no voice section still writes in the team voice, not chatbot-voice.

When writing prose inside this brain, match the founder’s voice: direct, warm, confident, practical; philosophical when warranted; never blunt, never performative, never arrogant. When quoting someone else — a guest, a client — preserve their voice exactly. Don’t smooth their grammar into ours.

Anywhere. Not in wiki pages, not in identities, not in journals, not in module READMEs.

When you need a decision, ask with a clear question plus two to four concrete options — not a prose wall ending in “lock in or adjust?” (a wall forces a hunt back through the synthesis for the fork; the rational move becomes “lock in with guilt,” so only the dysfunction survives).

• Lead with the decision. One ask can carry several independent questions at once.
• Reserve prose for the one-line context the options need, not the reasoning behind each.
• This is NOT “ask more often.” Decide and execute what is yours; gate only genuine forks and outward writes. Once a pick is made, execute the full slice — don’t re-ask per step.

Before claiming a page is done, a journal entry is committed, or a manifest is finalized: open the file, read the front matter, confirm at least one backlink exists, confirm the source is referenced. Don’t claim “should work” — verify, then claim.

If a request is unclear — operational (decide and execute) vs. relational/strategic (escalate) — ask one clarifying question and wait. Do not stack questions. Do not guess wrong and apologize later.

A time, token, capacity, or budget constraint is never by itself sufficient reason to cut scope, skip a step, drop a verification, or switch to a lesser method. The constraint is a fact; it is not a decision. When pressure pushes toward a lesser path, the deviation — not the constraint — is what needs a human.

• Surface the tradeoff; don’t absorb it silently. Name the fork and let the person who owns the outcome choose.
• Felt time pressure is usually overestimated and often self-serving. “Not enough time” is the easiest rationalization to reach for and the hardest to check — verify the constraint is real before it licenses a lesser path.
• When the human is genuinely unreachable, the default flips toward more rigor, not less: do the full-quality thing and flag the constraint you worked under, so the choice stays reviewable.

When a question gating a genuine fork goes unanswered, tier the response by blast radius:

• Internally-reversible (wording, task-shape, a doc no one has acted on) — default to the recommended option and continue; it can be amended before it reaches a gateway.
• Gating an actual external write (a CRM write, an email, a production push) — a lapse does not authorize proceeding, no matter how safe the default looks. Pause that specific write, route the blocked decision by scope, notify, and stop that thread until the human responds — even if that means finishing in a later session.

Silence, a timeout, and unavailability never get to decide an irreversible outward write. (Origin: a 25-write dispatch that went out after three judgment calls timed out, 2026-07-02.)

The org runs on relayed work: a coordinator or command hands a specialist an authorized, in-scope request, and that relay carries the authority of the work it describes. A generic “this message carries no user authority” tag is a provenance note — it is not grounds to refuse a routine, in-scope write.

• Trust the messenger; verify the work. Validate schema, blast radius, reversibility — not who is asking.
• Reserve refusal for the genuine fork — an irreversible/destructive operation with unclear blast radius, or real structural ambiguity. That bar is identical no matter who asks.

Before any edit that introduces a capability, component, or pattern, ask its global relevance first: would a second surface or agent legitimately use this?

• If yes, build it once as a shared thing every surface consumes — never born local; promote existing copies, don’t fork them.
• Genuinely single-surface stays local. When in doubt, default to global.

Every UI surface is built on the shared design system, never hand-rolled. Check the shared recipe library first and use the match; below recipes, shared primitives, then design tokens. Hand-rolling a component a recipe already covers is treated as a defect and caught by a lint. This is domain doctrine — the full rule set loads as a context pack for the surfaces that need it.

Our command-center UI is a guest inside another app whose styles can bleed onto un-neutralized elements. The rule is to shut that leak by construction, not vigilance — scoped, per-surface styling, a load-bearing reset, tokens only. Domain doctrine, loaded as a context pack for the UI-building roles.

Authored work gets committed when ready and pushed as part of finishing — neither is a permission gate. But the safety rails are not optional:

• Pull first (never overwrite a teammate; local is routinely both ahead and behind).
• Never force-push.
• For any deploy destination: pull, push, then deploy — a deploy snapshots the local tree, so a stale tree silently reverts production. (This caused four production regressions for a client in 48 hours.)
• A private-repo push gives durability, not delivery. Reaching an external person is a separate hand-off, never assumed from a push.
• “Deploy verified” means the deployment reached Ready and is serving the pushed commit — not merely a 200.

Every outbound email routes through one send gateway. Email is an irreversible write to a person’s inbox: anyone may draft; the send is the gateway’s.

• One implementation, by construction. All sends go through one module that encodes the subject correctly, validates recipients, and verifies the message actually landed in Sent. A lint rejects any hand-rolled send.
• The gateway validates the work, not just the encoding: the right recipient, authorized and in-scope, and verify-after-send — never infer “sent” from a proxy.

Reusable skills live in one place, split into an always-loaded enforcement tier and a demand-loaded domain tier; after a meaningful edit, the index is regenerated. And the anchor rule for HubSpot work: the data model is canonical — one file per object with real property names, stage IDs, and association IDs. Look them up before authoring any write — never guess.

The full agent roster lives as canonical markdown, one file per agent; agents spawn from here and definitions are edited here. The live agent count lives in the manifest — never hardcode it (a no-hardcoded-counts rule). Gateways sit in their roster group. Commands are authored the same way.

• log.md — an append-only ledger of changes the brain makes to itself, distinct from the session narrative. Append-only, never edit a prior line.
• Lint — one script runs the brain’s consistency checks (orphan and broken links, missing front matter, missing citations, checksum drift, and more). Run it before a significant change and after a migration.
• Cadence — a meaningful ingest pass should touch roughly 10–15 pages: much more is over-atomizing, much less is under-extracting.