Sidecat Master Design

Sidecat has one plain law: agents should choose it because it makes serious work easier to finish, prove, resume, and hand off. The system is not a dashboard or a pile of commands. It is a local daemon, a small language, and a set of admitted vocabularies that turn agent work into durable evidence.

The ten patterns

1. Truth is a log. State is a fold over append-only events. Corrections are new events, not edits pretending the old thing never happened.
2. Identity is content. Important objects have canonical digests. Names are refs; the content is the thing.
3. The world enters through cats. Pure work stays cheap. Effects happen through governed capabilities and leave receipts.
4. Cores own meaning; ports own boundaries; surfaces render. Internal *cat cores hold semantics, the operation catalog is the port registry, and side* programs are adapters.
5. Checks are born from contracts. Work should not certify itself at the moment it wants to close. Decision contracts create obligations; agents resolve them with evidence.
6. Vocabulary is admitted. New packages, commands, milestones, verdicts, and estate categories enter through owned vocabularies, with low-ceremony private-use space for exploration.
7. Derived things know their pins. Plans, judgments, caches, documents, and definitions record what they were derived against and rot visibly when that moves.
8. Creating categories is privileged; applying them is cheap. New rubrics, belief types, protocols, and capability classes are rare governed acts. Classifying work into existing categories is frequent and easy.
9. Topology is evidence, not interface. An agent talks to its local sidecatd; whether work crossed machines belongs in the evidence, not in a different command shape.
10. The governed path is the lazy path. Governance must reduce repeated discovery, surprise halts, and rework. If raw bash is easier for ordinary work, Sidecat loses.

flowchart LR
  subgraph A["Adapters render and steer"]
    CLI["sidecat CLI"]
    MCP["MCP projection"]
    BAR["sidebar · sidebird · sidespy"]
    CHAT["sidechat"]
  end
  subgraph R["Operation catalog: port registry"]
    P["work · messages · effects · watch · invocation · packages"]
  end
  subgraph C["Cores own meaning"]
    WORK["workcat"]
    EVID["evidencecat"]
    MSG["messagecat"]
    PKG["packagecat"]
    INFRA["infracat"]
    LISP["lispcat"]
  end
  CLI --> P
  MCP --> P
  BAR --> P
  CHAT --> P
  P --> WORK
  P --> EVID
  P --> MSG
  P --> PKG
  P --> INFRA
  P --> LISP

The two operator decisions

• Git is native Go, not an extension. Git work is too central to Sidecat's custody path to live as a demo package or optional plugin.
• Demos do not earn infrastructure. The package shelf starts empty. The first real customer authors the first real package; examples do not justify a permanent estate.

How work moves

Sidecat work starts at the local sidecatd. The daemon provides scope, authority, messages, work records, evidence, and the ports that packages and clients act through. Lispcat gives agents the workbench language. Infracat helps agents avoid believing stale or merely-present things. Evidencecat and receiptcat make the work replayable.

flowchart TB
  STREAM["typed event streams"] --> FOLD["folds and memos with pins"]
  FOLD --> RENDER["boards · briefs · replays"]
  CAT["cat firing"] --> RCPT["signed receipt"]
  RCPT --> EVREC["evidence record"]
  EVREC --> BUNDLE["portable evidence crate"]
  RCPT --> REPLAY["replay without re-running effects"]

The practical loop is short:

1. Load the current work image from sidecatd.
2. Ask Sidecat what is allowed, stale, proven, accepted, and owned.
3. Act through an operation or a cat.
4. Record receipts and evidence.
5. Fold the event stream into the next board, replay, or plan.

flowchart LR
  PLAN["typed plan"] -->|"daemon builds scope"| EXEC["agent or harness acts"]
  EXEC -->|"events + receipts"| THREAD["work thread"]
  THREAD -->|"pure folds"| SYN["strategy and replay"]
  SYN -->|"next plan pins evidence"| PLAN

What the data says

The long design run adjudicated 47 packages and 9 binaries. Its editable verdict source is now typed data in the Sidecat repository:

• design/adjudication.json
• design/decisions.json
• design/open-ledger.json

Those files say what conforms, what gets retrofitted, what gets rebuilt, and what gets deleted. This page narrates the law; the data enumerates the verdicts.

Growth path

flowchart LR
  L["Laptop: agents share one daemon"] --> H["Homeserver: durability and watches"]
  H --> F["Federation: gated on peer-boundary verification"]
  F --> CL["Cloud or institution: relay tier and purchased verification"]

The shape is the same at every rung: local agents work through a local daemon; authority boundaries live between daemons; evidence records where the work actually ran.

Run record

This page is the human artifact. The run volume is evidence of how the law was formed, not the front door for readers. It now lives in sidecat/design/archive/master-design-run-2026-07-03.md with a supersession banner.