Infrastructure-layer governance for AI agent containers.

Documentation | Quickstart | Manifesto

Swarm is for agents that work for you. Clawdapus is for bots that work as you.

Every agent framework answers the same question: how do I make agents collaborate? Swarm, CrewAI, LangGraph — all application-layer orchestration, all built on a shared assumption: the agent is a trusted process.

That assumption holds for autonomous assistants. It breaks the moment you deploy bots that operate publicly — posting to feeds, replying on Discord, executing trades, and burning provider tokens — as a persistent presence with a persistent identity.

Clawdapus treats the agent as an untrusted workload. It is the layer below the framework, where deployment meets governance, identity projection, and strict cost containment.

You need: Docker Desktop, an OpenRouter API key, and a Discord bot token + guild ID (see Discord setup guide).

# Install
curl -sSL https://raw.githubusercontent.com/mostlydev/clawdapus/master/install.sh | sh

# Clone the quickstart example
git clone https://github.com/mostlydev/clawdapus.git
cd clawdapus/examples/quickstart

# Configure
cp .env.example .env
# Edit .env — add OPENROUTER_API_KEY, DISCORD_BOT_TOKEN, DISCORD_BOT_ID, DISCORD_GUILD_ID

# Run the operator loop
source .env

# 1. pull pinned runtime infra, registry-backed pod services, and runner bases
claw pull

# 2. build this pod's local build: services
claw build

# 3. compile the pod and launch it
claw up -d

# Verify
claw ps        # assistant + cllama both running
claw health    # both healthy

# Run any docker compose command against the pod
claw compose exec assistant bash
claw compose restart cllama
claw compose top

# 4. tear the pod down when you're done
claw down

The cllama governance proxy dashboard runs on port 8181 — every LLM call in real time: which agent, which model, token counts, cost.

The Clawdapus Dash fleet dashboard runs on port 8082 — live service health, topology wiring, per-service drill-down, and agent context inspection. The Agents view shows each claw's compiled AGENTS.md/CLAWDAPUS.md, redacted runtime manifests, and the latest live context snapshot captured by cllama.

The operator surface is four verbs:

• claw pull fetches pinned runtime infra, registry-backed pod services, and refreshes built-in local runner bases
• claw build builds pod services that declare build:
• claw up compiles the pod and launches it, staying strict by default
• claw down tears the pod back down

Runner refresh happens through claw pull: for a pod it refreshes the runner bases used by build: services, and for a single Clawfile you can run claw pull ./agents/assistant/Clawfile. Use claw pull --no-runners when you want the fast pinned-infra path only.

If claw up finds something missing, it tells you exactly which command to run next. claw up --fix -d can pull/build missing infra and service images, but runner refresh still happens through claw pull.

Message @quickstart-bot in your Discord server. The bot responds through the proxy — it has no direct API access. The dashboard updates live.

claw up resolves ${...} placeholders inside x-claw metadata from your shell environment and the pod-local .env file before it generates runtime config. You do not need to duplicate handle IDs, guild IDs, or channel IDs into service environment: just to make driver config generation work.

Supported x-claw placeholder forms match shell-style parameter expansion:

• ${VAR} required
• ${VAR:-default} default when unset or empty
• ${VAR-default} default when unset
• ${VAR:?message} fail when unset or empty
• ${VAR?message} fail when unset
• ${VAR:+value} substitute value when set and non-empty
• ${VAR+value} substitute value when set

Built-in x-claw variables:

• REPO_ROOT defaults to the pod directory passed to claw up

This placeholder expansion is specific to x-claw metadata. Standard Compose fields still use normal Docker Compose .env interpolation rules.

For multi-agent pods, declare shared chat topology once under x-claw.handles-defaults and keep each service's x-claw.handles block focused on service-specific identity such as bot ID and username.

See examples/quickstart/ for the full walkthrough, Telegram/Slack alternatives, and migration from existing OpenClaw.

Or scaffold from scratch:

claw init my-pod
cd my-pod
cp .env.example .env
source .env
claw pull
claw build
claw up -d

# add another agent later
claw agent add researcher

Generated projects use the same operator loop: claw pull, claw build, claw up, then claw down when you're finished.

claw agent add preserves the project's existing layout by default:

• Canonical project: adds agents/<name>/Clawfile + agents/<name>/AGENTS.md
• Flat project: adds Clawfile.<name> + AGENTS-<name>.md

Use --layout canonical or --layout flat to override auto-detection.

curl -sSL https://raw.githubusercontent.com/mostlydev/clawdapus/master/install.sh | sh
claw doctor

Or build from source:

go build -o bin/claw ./cmd/claw

Clawdapus moves fast — update frequently.

claw update

claw checks for updates once an hour and prints a notice when a newer release is available.

Give your coding agent full operational knowledge of Clawdapus — the claw CLI, Clawfile syntax, claw-pod.yml structure, cllama proxy wiring, driver semantics, and troubleshooting patterns.

# Recommended: installs to ~/.claude/skills/ and ~/.agents/skills/
# Auto-updates whenever you update the claw binary.
claw skill install

Or install manually:

SKILL_URL="https://raw.githubusercontent.com/mostlydev/clawdapus/master/skills/clawdapus/SKILL.md"

# Claude Code / OpenCode
mkdir -p ~/.claude/skills/clawdapus-cli
curl -sSL "$SKILL_URL" -o ~/.claude/skills/clawdapus-cli/SKILL.md

# Codex CLI / Gemini CLI / OpenCode (shared .agents/skills/ convention)
mkdir -p .agents/skills/clawdapus-cli
curl -sSL "$SKILL_URL" -o .agents/skills/clawdapus-cli/SKILL.md

# Cursor / Windsurf / other .cursorrules-based agents
curl -sSL "$SKILL_URL" >> .cursorrules

The Image (Clawfile) — an extended Dockerfile.

FROM openclaw:latest

CLAW_TYPE openclaw
AGENT AGENTS.md                   # behavioral contract — bind-mounted read-only

MODEL primary openrouter/anthropic/claude-sonnet-5
MODEL fallback anthropic/claude-haiku-4-5

CLLAMA passthrough                # governance proxy — credential starvation + cost tracking

HANDLE discord                    # platform identity — mention patterns, peer discovery
INVOKE 15 8 * * 1-5  pre-market   # scheduled invocation — cron, managed by operator

SURFACE service://trading-api     # declared capabilities — auto-discovered, skill-mapped
SURFACE volume://shared-research read-write

SKILL policy/risk-limits.md       # operator policy — mounted read-only into runner

The Deployment (claw-pod.yml) — an extended docker-compose.

x-claw:
  pod: trading-desk
  master: octopus
  cllama-defaults:
    proxy: [passthrough]
    env:
      OPENROUTER_API_KEY: "${OPENROUTER_API_KEY}"
      ANTHROPIC_API_KEY: "${ANTHROPIC_API_KEY}"
  surfaces-defaults:
    - "service://trading-api"
    - "volume://shared-research read-write"
  feeds-defaults: [market-context]    # resolved from trading-api's claw.describe
services:
  analyst:
    image: trading-desk-analyst:latest
    build:
      context: ./agents/analyst
    x-claw:
      agent: ./agents/analyst/AGENTS.md
      handles:
        discord:
          id: "${ANALYST_DISCORD_ID}"
          username: "analyst"
      invoke:
        - schedule: "15 8 * * 1-5"
          name: "Pre-market synthesis"
          message: "Run pre-market synthesis and post the floor briefing."
          to: trading-floor

Services inherit cllama-defaults, surfaces-defaults, and feeds-defaults from the pod. Override any field to replace; use ... spread to extend:

    x-claw:
      skills:
        - ...                          # inherit pod defaults
        - ./policy/escalation.md       # add coordinator-only skill

claw build transpiles the Clawfile to a standard Dockerfile. claw up parses the pod YAML, runs driver enforcement, generates per-agent configs, wires the cllama proxy, and calls docker compose. The output is standard OCI images and a standard compose file. Eject from Clawdapus anytime — you still have working Docker artifacts.

Clawdapus extends two formats you already know:

Any valid Dockerfile is a valid Clawfile. Any valid docker-compose.yml is a valid claw-pod.yml. Extended directives live in namespaces Docker already ignores. Eject from Clawdapus anytime — you still have a working OCI image and a working compose file.

The Clawfile extends the Dockerfile with directives that the claw build preprocessor translates into standard Dockerfile primitives (LABEL, ENV, RUN). The output is a plain OCI image.

Pick a driver based on what you need. All drivers support MODEL, AGENT, CLLAMA, and CONFIGURE.

Retired drivers (nanoclaw, microclaw, nullclaw) fail claw up with a migration message; see ADR-026.

¹ PicoClaw long-tail: WhatsApp, Feishu, LINE, QQ, DingTalk, OneBot, WeCom, WeCom App, Pico, MaixCam. claw init scaffolds generic (alpine:3.20, no driver enforcement) for custom runtimes.

The OpenClaw driver now maps the supported channel://discord routing controls directly into generated config and rejects the unsupported ones early.

² The current OpenClaw runtime rejects guild-level policy; Clawdapus now fails during config generation instead of writing a config the container will reject at boot.

Use these when you want high-level HANDLE defaults, but need runtime-specific policy details.

# Base identity on a platform:
HANDLE discord

# Enable/adjust a channel beyond HANDLE defaults
CONFIGURE picoclaw config set channels.discord.enabled true

# Override the gateway port
CONFIGURE picoclaw config set gateway.port 19000

# Pin a fallback model name
CONFIGURE picoclaw config set agents.defaults.model_name "fallback"

Notes:

• CONFIGURE is driver-side DSL (<runner> config set <path> <value>), applied to the generated config.
• Values are parsed as JSON when possible: booleans/numbers/arrays/objects should be unquoted; strings should be quoted.
• CONFIGURE runs after defaults, so it overrides what HANDLE generated.

block-beta
  columns 1
  contract["Behavioral Contract\nread-only bind mount\nAGENTS.md — purpose, on the host\nSurvives full container compromise"]
  runner["Runner\nOpenClaw · Hermes · Nanobot · PicoClaw"]
  persona["Persona\nMemory · history · style · knowledge"]
  proxy["cllama — governance proxy\nIntercepts prompts outbound + responses inbound\nRunner never knows it's there"]

  style contract fill:#1a1a2e,stroke:#22d3ee,color:#eee
  style runner fill:#1a1a2e,stroke:#f0a500,color:#eee
  style persona fill:#1a1a2e,stroke:#a78bfa,color:#eee
  style proxy fill:#1a1a2e,stroke:#34d399,color:#eee

The contract lives on the host. Even a root-compromised runner cannot rewrite its own mission. Swap runners without touching identity. Add or remove the governance proxy without rebuilding anything.

When a reasoning model tries to govern itself, the guardrails are part of the same cognitive process they're trying to constrain. cllama is a separate process sitting between the runner and the LLM provider. The runner thinks it's talking directly to the model. It never sees the proxy.

• Credential starvation: The proxy holds the real API keys. Agents get unique bearer tokens. No credentials, no bypass.
• Identity resolution: Single proxy serves an entire pod. Bearer tokens resolve which agent is calling.
• Cost accounting: Extracts token usage from every response, multiplies by pricing table, tracks per agent/provider/model.
• Budget and rate enforcement: Per-agent x-claw.budget caps compile into the proxy context. cllama rejects over-budget or over-rate turns with 429 and logs budget_exceeded / rate_limited interventions.
• Audit logging: Structured JSON on stdout — timestamp, agent, model, latency, tokens, cost, intervention reason.
• Managed tool mediation: Services declare callable tools via claw.describe (MCP-shaped schemas). claw up compiles per-agent tools.json. cllama injects tools into LLM requests, intercepts tool_call responses, executes them against the service, and loops until terminal text — transparent to the runner. HTTP services, Streamable HTTP MCP sidecars, and stdio MCP servers wrapped by claw-mcp-stdio are supported.
• Ambient memory plane: Services declare recall, retain, and forget endpoints via claw.describe. claw up compiles per-agent memory.json. cllama calls /recall before each inference turn and /retain after each successful response (async, non-blocking). Memory intelligence stays in swappable external services — the proxy owns orchestration only.
• Context blocks: Operators can compile short per-agent context snippets into context-blocks.json; cllama injects enabled blocks into late runtime context so durable operating focus stays visible without expanding the primary contract.
• Operator dashboard: Real-time web UI at host port 8181 by default (container :8081) — agent activity, provider status, cost breakdown.

The reference implementation is cllama — a zero-dependency Go binary that implements the transport layer (identity, routing, cost tracking, budget enforcement). Future proxy types (cllama-policy) will add bidirectional interception: evaluating outbound prompts and amending inbound responses against the agent's behavioral contract.

See the cllama specification for the full standard.

Services declare callable tools in their claw.describe descriptor. claw up compiles per-agent tools.json from the declared and policy-filtered tool catalog.

services:
  analyst:
    x-claw:
      cllama: passthrough
      surfaces:
        - service://trading-api
      tools:
        - service: trading-api
          allow:
            - get_market_context   # read-only
            - execute_trade        # side-effecting

  trading-api:
    image: trading-api:latest
    # declares tools[] in claw.describe label

tools: follows the same pod-defaults model as feeds: and surfaces:. No tools are injected unless explicitly declared — deny by default.

cllama injects the compiled tool schemas into each upstream LLM request, intercepts tool_call responses, executes them against the service, and loops until the LLM returns terminal text. The runner receives only the final text — managed tool rounds are transparent.

Non-cllama services that declare x-claw.tools or x-claw.memory are a hard error at claw up time.

Stdio MCP packages can be wrapped without hand-written glue. Declare the command on a wrapper sidecar, then let MCP self-describe:

services:
  perplexity:
    image: ghcr.io/mostlydev/claw-mcp-stdio:v0.23.1
    environment:
      PERPLEXITY_API_KEY: ${PERPLEXITY_KEY}
    expose:
      - "8080"
    x-claw:
      mcp-stdio:
        command: npx
        args: ["-y", "perplexity-mcp"]

  analyst:
    x-claw:
      cllama: passthrough
      tools:
        - service: perplexity
          allow: [search]

Run claw discover perplexity once to ask the MCP server for tools/list; it writes .claw-discovered/perplexity.claw-describe.json, which claw up then consumes deterministically. claw up --discover-tools -d can refresh missing or stale stdio snapshots as an explicit convenience. x-claw.describe-file remains available as a descriptor override when live discovery cannot run.

Services declare memory endpoints in their claw.describe descriptor. claw up compiles per-agent memory.json.

services:
  analyst:
    x-claw:
      cllama: passthrough
      memory:
        service: mem-svc
        timeout-ms: 300

  mem-svc:
    image: reference-memory:latest
    # declares memory.recall/retain/forget in claw.describe

cllama calls /recall before each upstream inference request and /retain asynchronously after each successful response. Retain failures never fail the user-visible response.

Operator commands:

# Replay the durable session ledger into a memory service
claw memory backfill mem-svc

# Replay only entries after a given time
claw memory backfill mem-svc --after 2026-03-01T00:00:00Z

# Tombstone a retained entry (does not mutate session history)
claw memory forget mem-svc --agent analyst-0 --entry-id hist1_abc123 --reason "operator request"

A runnable reference adapter lives at examples/reference-memory/ — file-backed, idempotent on entry.id, tombstone-aware.

# Available in every pod service automatically:
CLAW_HANDLE_CRYPTO_CRUSHER_DISCORD_ID=123456789
CLAW_HANDLE_CRYPTO_CRUSHER_DISCORD_GUILDS=111222333

HANDLE discord in a Clawfile declares the agent's platform identity. Clawdapus broadcasts every agent's handles as env vars into every service in the pod — including non-claw services. A trading API that needs to mention a bot in a webhook message knows its Discord ID without hardcoding anything.

The driver also wires each agent's openclaw config automatically: allowBots: true (enables bot-to-bot messaging), Discord mentionPatterns derived from the native handle ID so agents only trigger on explicit Discord mentions, and a guild users[] allowlist that includes every peer bot in the pod.

When many services share the same Discord guild/channel topology, put that shared topology in pod-level x-claw.handles-defaults and let per-service handles.discord override only the identity fields that differ.

claw up is a compiler. It reads the pod file, inspects images, and emits deterministic runtime artifacts. These principles govern the compilation pipeline:

1. Compile-time, not runtime. All wiring — feeds, skills, identity, surfaces — is resolved during claw up. No runtime self-registration. The generated compose file is the single source of truth for what's deployed.

2. Provider-owns, consumer-subscribes. Services declare what they offer (feeds, endpoints, auth). Agents subscribe by name. The consumer should never need to know a service's URL path or TTL — that's the provider's concern.

3. Pod-level defaults, service-level overrides. Anything shared across most services — proxy config, surfaces, feeds, skills — is declared once at pod level. Services inherit by default and override or extend as needed.

4. One canonical descriptor. A service's capabilities, feeds, and endpoints are declared once (via claw.describe in the image) and projected into whatever artifacts need them — CLAWDAPUS.md, feed manifests, effective agent contracts.

5. Services self-describe. Images can carry a structured descriptor (LABEL claw.describe=...) that advertises feeds provided, auth requirements, and a skill file. claw up extracts and compiles these into the pod. Framework-specific adapters (e.g., RailsTrail for Rails apps) can generate descriptors from code introspection.

Every Claw receives a generated CLAWDAPUS.md — the single context document listing surfaces, mount paths, peer handles, feeds, and available skills. Service descriptions from claw.describe labels or claw.skill.emit are inlined directly into CLAWDAPUS.md surface sections, so workflow-critical API docs are always in prompt context without extra pod YAML. Add a service, the skill map updates. No code changes.

For example, an agent that declares a service://market-scanner surface and a volume://shared-cache surface receives a generated CLAWDAPUS.md whose surface sections inline the service's advertised tools and the mount path:

## Surfaces

### market-scanner (service://market-scanner)
- get_price — current and historical token price data
- get_whale_activity — large wallet movements in the last N hours
  (discovered via claw.describe)

### shared-cache (volume://shared-cache)
- read-write at /mnt/shared-cache

Clawdapus is designed for autonomous fleet governance. The operator writes the Clawfile and sets the budgets, but day-to-day oversight can be delegated to a Master Claw — an AI governor.

The Governance Proxy is its Sensory Organ: The cllama proxy is the programmatic choke point. It sits on the network, holds provider credentials, applies compiled model/tool/context/budget policy, rejects over-cap turns, injects compiled context blocks, and emits structured telemetry (cost, interventions, tool rounds). It doesn't "think" about management; it is a passive sensor and firewall.

The Master Claw is the Brain: The Master Claw is an actual LLM-powered agent running in the pod, reading proxy telemetry and acting on it. x-claw.master wires this today: it auto-injects a claw-api service and hands the governor a scoped bearer token and CLAW_API_URL, so it can read fleet telemetry and act through an authenticated, scope-checked API. The executive policy it runs — shifting enforced budget caps, quarantining a high-cost or off-policy agent, promoting a recipe — is operator-defined (recipe promotion is still on the roadmap).

In enterprise deployments, this naturally forms a Hub-and-Spoke Governance Model: multiple pods across zones run their own cllama proxies as local firewalls, while a single Master Claw ingests telemetry from them all to oversee the fleet.

cllama emits normalized telemetry for every turn it proxies. claw audit aggregates that ledger into a per-claw summary for the current pod — an independent record of what each bot did, what it cost, and where the proxy intervened. Because the provider keys live with the proxy, this record is authoritative, not self-reported.

$ claw audit --since 24h

Pod: research-pod
Events: 460
CLAW        REQ  RESP  ERR  INT  TOOLS  TOOL_ERR  TOK_IN  TOK_OUT  COST_USD  MODELS
analyst     142  142   0    3    18     0         284011  39402    1.8742    anthropic/claude-sonnet-5
researcher  88   87    1    0    5      0         151233  20118    0.9931    anthropic/claude-sonnet-5

Totals: req=230 resp=229 err=1 int=3 tools=23/0 tokens=435244/59520 cost=$2.8673

Filter with --claw <id>, --type <event>, or --since <duration>; add --json for machine-readable output. Drift scoring is deliberately not built in — defining behavioral drift is organization-specific, so Clawdapus ships the raw telemetry (the open metric) and leaves scoring to a swappable proxy implementation or a Master Claw policy. There is no drift_score in the reference proxy and no DRIFT column in claw audit.

Bots install things — that's how real work gets done. The planned recipe-promotion loop turns ad hoc mutation into permanent infrastructure through a human gate: a TRACK directive logs every package-manager mutation, claw recipe reviews the accumulated changes, and claw bake promotes the approved ones into the base image. Tracked mutation is evolution; untracked is drift.

This loop is designed but not yet implemented — the TRACK/recipe/bake surface does not ship today.

1. Purpose is sacred — contract is bind-mounted read-only; survives full container compromise
2. The workspace is alive — bots install and adapt; mutations are tracked and promotable
3. Configuration is code — every deviation from defaults is diffable
4. Drift is an open metric — independent audit via the governance proxy, not self-report
5. Surfaces are declared — topology for operators; capability discovery for bots. The proxy enforces cognitive boundaries.
6. Claws are users — standard credentials; the proxy governs intent, the service's own auth governs execution
7. Compute is a privilege — operator assigns models, schedules, and budget caps; proxy meters usage and rejects over-cap turns; bot doesn't choose
8. Think twice, act once — a reasoning model cannot be its own judge
9. Memory survives the container (and the runner) — session history is captured at the proxy boundary and persisted outside the runtime directory. Bots don't start amnesia-fresh after every restart. Infrastructure owns the record; the runner owns the scratch space. Two surfaces, two owners, never merged. Because the architecture is the agent, you can swap the runtime (CLAW_TYPE) without losing the mind; knowledge seamlessly crosses driver boundaries. Retention is only half of memory. The ambient memory plane is live: pluggable memory services declared via claw.describe, compiled by claw up, and orchestrated by cllama — recalling derived context before each inference turn and retaining after each response. The agent does not manage its own long-term memory. Infrastructure does.

Clawdapus is in active development and released regularly — see the latest release and the changelog. The build pipeline, the seven runner drivers, the cllama governance proxy (credential starvation, compiled tool mediation, normalized telemetry + claw audit), the memory plane (session history, portable memory, ambient recall), context feeds and channel-memory, social topology, and claw-api/Master Claw wiring all ship today. Recipe promotion (TRACK/recipe/bake) and a built-in drift score are on the roadmap.

For the capability-by-capability picture — what ships versus what is planned, and the ADR behind each — see How It Fits Together and the canonical docs/PROJECT_STATE.md.

• How It Fits Together — the systems map: lifecycle, planes, and shipped-vs-roadmap
• docs/PROJECT_STATE.md — canonical shipped-vs-planned reconciliation and ADR status index
• MANIFESTO.md — vision, principles, full architecture
• docs/CLLAMA_SPEC.md — Standardized Sidecar interface for policy and compute metering
• docs/decisions/001-cllama-transport.md — ADR: cllama as sidecar HTTP proxy
• docs/decisions/002-runtime-authority.md — ADR: compose-only lifecycle authority
• docs/decisions/003-topology-simplification.md — ADR: Topology simplification and the HANDLE directive
• docs/decisions/004-service-surface-skills.md — ADR: Service surface skills strategy
• docs/decisions/006-invoke-scheduling.md — ADR: INVOKE scheduling mechanism
• docs/decisions/007-llm-isolation-credential-starvation.md — ADR: LLM Isolation via Credential Starvation
• docs/decisions/008-cllama-sidecar-standard.md — ADR: cllama as a Standardized Sidecar Interface
• docs/decisions/009-contract-composition-and-policy.md — ADR: Contract Composition and Policy Inclusion
• docs/decisions/010-cli-surface-simplification.md — ADR: CLI Surface Simplification (claw compose * → claw *)
• docs/decisions/011-canonical-project-layout.md — ADR: Canonical-By-Default Scaffold Layout
• docs/decisions/012-master-claw-fleet-governance.md — ADR: Master Claw and Fleet Governance
• docs/decisions/013-context-feeds.md — ADR: Context Feeds — Live Data Injection for Claws
• docs/decisions/014-telemetry-normalization-and-audit.md — ADR: Telemetry Normalization and claw audit
• docs/decisions/015-claw-api-authentication-and-scoping.md — ADR: claw-api Authentication and Authorization Scoping
• docs/decisions/016-canonical-social-identity-and-conformance-spikes.md — ADR: Canonical Social Identity and Conformance Spikes
• docs/decisions/017-pod-defaults-and-service-self-description.md — ADR: Pod-Level Defaults and Service Self-Description (claw.describe, provider-owned feeds)
• docs/decisions/018-session-history-and-memory-retention.md — ADR: Session History and Persistent Memory Surfaces (two surfaces, two owners, phase model)
• docs/decisions/020-cllama-compiled-tool-mediation.md — ADR: Compiled Tool Plane with Native and Mediated Execution Modes
• docs/decisions/021-memory-plane-and-pluggable-recall.md — ADR: Memory Plane as a Compiled Capability
• docs/UPDATING.md — checklist of everything to update when implementation changes
• TESTING.md — unit, E2E, and spike test runbook

Start with MANIFESTO.md for the why, then CONTRIBUTING.md for the how: dev setup, test tiers, the issue-first workflow, and the release-artifact rules.

Priorities live on the project board — column order is priority order. Bug reports and feature requests have issue templates.