Skip to content

Instantly share code, notes, and snippets.

@mostlydev

mostlydev/clawdapus_manifesto.md

Last active February 16, 2026 12:43
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save mostlydev/dc32aa6ca9f66e29f623bec76a0e0906 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save mostlydev/dc32aa6ca9f66e29f623bec76a0e0906 to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. mostlydev revised this gist Feb 13, 2026. 1 changed file with 77 additions and 16 deletions.
    93 changes: 77 additions & 16 deletions clawdapus_manifesto.md
    View file
    Original file line number Diff line number Diff line change
    @@ -4,7 +4,7 @@

    ### A Manifesto for Containerized Agent Infrastructure

    v0.7 — February 2026
    v0.8 — February 2026

    ---

    @@ -26,9 +26,9 @@ Swarm is for agents that work *for* you. Clawdapus is for bots that work *as* yo

    A running Claw bifurcates cognition into two independent layers: internal execution and external judgment.

    **The Runner (Internal Execution)** — An agent runtime installed in the base image. OpenClaw is the most capable example: its Pi reasoning core handles planning and decision-making, while its Nanobots are atomic skills that execute specific tasks — browsing, file operations, API calls, shell commands. But the runner can be anything. Claude Code is a single-execution runner. A custom Python agent is a runner. The runner handles the *how* of any given task.
    **The Runner (Internal Execution)** — An agent runtime installed in the base image. Runners span a wide weight range, from full agent operating systems to minimal loops — and Clawdapus wraps them all identically. OpenClaw is the heaviest: a Gateway-centric agent system built on the Pi Agent Core SDK, with a multi-channel messaging gateway, a skill system, built-in tools for shell, browser, file system, and canvas, and a model resolver with multi-provider failover. Nanobot is the lightweight end: ~4,000 lines of Python running the same fundamental agent loop — input, context, LLM, tools, repeat — with its own skill system, persistent memory, and multi-provider support. NanoClaw wraps Claude Code as its runtime inside container-isolated workspaces. Claude Code itself is a single-execution runner. A custom Python script is a runner. The weight class doesn't matter. Every runner implements the same pattern: receive input, assemble context, call a model, execute tools, persist state. The runner handles the *how* of any given task.

    **The Behavioral Contract (The Law)** — A read-only, bind-mounted file whose name follows the runner's convention. For OpenClaw, this is AGENTS.md. For Claude Code, CLAUDE.md. The contract defines the *what* — what the Claw is allowed to be, what it should do, what it must never do. It lives on the host filesystem, outside the container. Even a root-compromised runner cannot rewrite its own mission.
    **The Behavioral Contract (The Law)** — A read-only, bind-mounted file whose name follows the runner's convention. For OpenClaw, this is AGENTS.md. For Claude Code and NanoClaw, CLAUDE.md. For Nanobot, instructions live in config.json and SKILL.md files within the workspace. The contract defines the *what* — what the Claw is allowed to be, what it should do, what it must never do. It lives on the host filesystem, outside the container. Even a root-compromised runner cannot rewrite its own mission.

    **The Persona (The History)** — A mutable workspace of identity, memory, knowledge, style, and accumulated interaction history. This is the *who* — who the Claw has become over time. Personas are downloadable, versionable, forkable OCI artifacts. They grow during operation and can be snapshotted and promoted.

    @@ -151,11 +151,15 @@ This means Clawdapus inherits the entire Docker ecosystem: registries, layer cac

    A claw type is a base image with an agent runner installed in a predictable location. That's it.

    An OpenClaw claw type is a Linux image with OpenClaw installed — its gateway, its channel adapters, its cron system, its skill registry, Pi, the Nanobots, its multi-model routing. It is a substantial runtime — a full agent operating system. It expects AGENTS.md.
    An OpenClaw claw type is a Linux image with OpenClaw installed — its Gateway control plane, its channel adapters, its cron system, its skill registry, the Pi Agent Core runtime, its built-in tools, and its multi-model routing with provider failover. It is a substantial runtime — a full agent operating system. It expects AGENTS.md. Heavyweight. 430,000+ lines. 15+ channel adapters.

    A Claude Code claw type is simpler — a Linux environment with Claude Code as a single-execution runner. It handles one task at a time. It expects CLAUDE.md.
    A Nanobot claw type is a Linux image with Nanobot installed — its agent loop, its skill system, its memory module, its provider routing, and its channel adapters. It is the same fundamental architecture as OpenClaw stripped to essentials. ~4,000 lines of Python. Sub-second cold start. 45MB memory footprint. MCP-native for modular tool composition. It reads config.json and workspace skills. Lightweight runners are not lesser claw types. They are different weight classes for different problems.

    Any agent runner can be a claw type. The requirement is that the runner is installed at a known path and reads a behavioral contract whose filename is part of the claw type's convention. Clawdapus wraps them all identically.
    A NanoClaw claw type wraps Claude Code as its runtime, running each agent group in its own container sandbox with isolated filesystems and per-group CLAUDE.md memory. NanoClaw already does its own container isolation — Clawdapus wrapping NanoClaw is not redundant sandboxing, it is additive governance: purpose contracts, judgment proxies, lifecycle management, surface topology, and fleet coordination that NanoClaw doesn't provide.

    A Claude Code claw type is simpler still — a Linux environment with Claude Code as a single-execution runner. It handles one task at a time. It expects CLAUDE.md.

    Any agent runner can be a claw type. The requirement is that the runner is installed at a known path and reads a behavioral contract whose filename is part of the claw type's convention. Clawdapus wraps them all identically. The operator picks the weight class that fits the problem: OpenClaw for persistent multi-channel assistants, Nanobot for lean MCP-driven agents, NanoClaw for Claude Code with isolation, Claude Code for one-shot tasks, or a custom script for anything else.

    ### Extended Directives

    @@ -167,7 +171,7 @@ Any agent runner can be a claw type. The requirement is that the runner is insta

    **CLLAMA** — The default judgment proxy baked into the image. Namespaced policy prefix, provider, model, then module declarations. Overridable per-deployment in claw-pod.yml, same as CMD is overridable by compose's command.

    **INVOKE** — Invocation schedules. For simple runners, cron lines that trigger execution. For runners like OpenClaw that have their own internal scheduling, INVOKE manages the container lifecycle on a macro schedule while the runner handles micro-scheduling internally.
    **INVOKE** — Invocation schedules. For simple runners and lightweight runners like Nanobot that use external cron, INVOKE entries trigger execution directly. For runners like OpenClaw that have their own internal scheduling, INVOKE manages the container lifecycle on a macro schedule while the runner handles micro-scheduling internally.

    **PRIVILEGE** — Per-mode privilege levels. Worker gets root. Runtime drops to standard user. Lockdown restricts filesystem and network for quarantined Claws.

    @@ -208,7 +212,7 @@ TRACK apt pip npm

    # Worker-mode setup
    ACT pip install tiktoken trafilatura
    ACT openclaw nanobot install crypto-feeds
    ACT openclaw skill install crypto-feeds

    # Configuration against base defaults
    CONFIGURE jq '.features.quote_tweets = true' /etc/claw/config.json | sponge /etc/claw/config.json
    @@ -238,13 +242,56 @@ COPY scripts/ /home/claw/scripts/
    ENV CLAW_LOG_LEVEL=info
    ```

    ### A Lightweight Clawfile

    Same architecture. Different weight class. A Nanobot-based Claw for a lean market scanner:

    ```dockerfile
    FROM nanobot:latest

    CLAW_TYPE nanobot
    AGENT config.json

    # Persona
    PERSONA registry.claw.io/personas/market-pulse:v1

    # Models
    MODEL primary anthropic/claude-sonnet-4-5

    # cllama: judgment still applies regardless of runner weight
    CLLAMA cllama-org-policy/anthropic/haiku \
    purpose/market-research-only \
    tone/factual-neutral

    # Nanobot skills
    ACT nanobot skill install market-data
    ACT nanobot skill install technical-analysis

    # Configuration
    CONFIGURE jq '.channels.telegram.enabled = true' ~/.nanobot/config.json | sponge ~/.nanobot/config.json

    # Invocation
    INVOKE */15 * * * * market-scan
    INVOKE 0 8 * * 1-5 morning-brief

    # Communication surfaces
    SURFACE queue://fleet/signals subscribe
    SURFACE service://market-scanner read-only

    # Privilege
    PRIVILEGE worker root
    PRIVILEGE runtime claw-user
    ```

    The Nanobot Clawfile is structurally identical to the OpenClaw Clawfile. Same directives, same compilation, same claw-pod.yml integration. The runner is lighter. The governance is the same.

    ---

    ## VI. The Behavioral Contract

    The behavioral contract is the single most important file in the architecture. It is the bot's purpose, defined by the operator, delivered as a read-only bind mount.

    The filename is determined by the claw type. OpenClaw reads AGENTS.md. Claude Code reads CLAUDE.md. A custom runner reads whatever it reads. Clawdapus doesn't impose a universal contract format because different runners are fundamentally different systems. OpenClaw is a full agent operating system with channels, skills, crons, Pi, Nanobots, and multi-model routing — its contract is correspondingly rich. Claude Code is a single-execution tool — its contract is simpler.
    The filename is determined by the claw type. OpenClaw reads AGENTS.md. Claude Code and NanoClaw read CLAUDE.md. Nanobot reads config.json and workspace skills. A custom runner reads whatever it reads. Clawdapus doesn't impose a universal contract format because different runners are fundamentally different systems. OpenClaw is a full agent operating system with a Gateway control plane, channels, skills, crons, the Pi Agent Core runtime, and multi-model routing — its contract is correspondingly rich. Nanobot achieves the same core agent pattern in ~4,000 lines with its own skill and memory system — its contract is leaner but structurally equivalent. Claude Code is a single-execution tool — its contract is simpler still.

    What Clawdapus guarantees, regardless of runner:

    @@ -330,7 +377,7 @@ Anyone who knows compose knows this file.

    ### Mixed Clusters

    A pod is not a collection of bots. It is a mixed cluster of cognitive and non-cognitive services. An operations pod might contain several OpenClaw Claws with different personas, a Claude Code Claw for one-off tasks, a market data scanner that's just a plain Docker container, a Redis instance, and an operator dashboard.
    A pod is not a collection of bots. It is a mixed cluster of cognitive and non-cognitive services. An operations pod might contain an OpenClaw Claw running the master assistant with full channel routing, a pair of Nanobot Claws handling lightweight scanning and alerting at a fraction of the resource cost, a Claude Code Claw for one-off deep analysis tasks, a market data scanner that's just a plain Docker container, a Redis instance, and an operator dashboard. Weight-class diversity is the point — the heavyweight orchestrator, the lightweight specialists, and the one-shot executors all governed identically.

    Regular Docker containers participate as first-class pod members. A web application running inside the pod carries a describe block — machine-readable self-description of what it does, what it produces, what it consumes. Other services discover it. The master claw reasons about it. It's not a black box — it's a participant in a system of components that understand each other's purposes.

    @@ -511,7 +558,7 @@ Surfaces serve two purposes. For the operator, they are a topology map — where

    Clawdapus collects discovered capabilities from all surfaces a Claw has access to and assembles them into a **skill map**. The skill map is the complete set of capabilities available to that Claw: every service it can reach, every tool it can call, every data source it can query. Different Claws in the same pod may have different skill maps because they have different surface access.

    The skill map is delivered to the runner via a **skill mount** — a read-only mount point where the runner can discover available capabilities at invocation time. For OpenClaw, the skill map maps naturally onto its Nanobot and skill architecture — each discovered capability becomes a skill the runner can invoke. For Claude Code, capabilities become tool definitions. For a generic runner, the skill mount is a directory of capability descriptions in a standard format that the runner parses however it wants.
    The skill map is delivered to the runner via a **skill mount** — a read-only mount point where the runner can discover available capabilities at invocation time. For OpenClaw, the skill map integrates naturally with its skill system — each discovered capability becomes a skill injected into the agent's workspace, auto-discovered and available to the Pi Agent Core runtime. For Nanobot, capabilities map onto its MCP-native architecture — each discovered MCP service becomes a connected server, and non-MCP services become skills in the workspace `skills/` directory. For Claude Code, capabilities become tool definitions. For a generic runner, the skill mount is a directory of capability descriptions in a standard format that the runner parses however it wants.

    ```
    $ claw skillmap crypto-crusher-0
    @@ -603,9 +650,19 @@ Built entirely on Docker primitives. Clawfiles are Dockerfiles. claw-pod.yml is

    ### Runner Compatibility

    Clawdapus operates beneath agent runners. OpenClaw is a full agent operating system — Pi, Nanobots, channels, crons, multi-model routing, skills, persistent memory. Claude Code is a focused single-execution runner. Both are valid claw types. The Clawfile wraps them identically. A Claw can also run Swarm internally, or CrewAI, or a custom script. Clawdapus doesn't care what happens inside the workspace. It cares about purpose, judgment, lifecycle, and communication.
    Clawdapus operates beneath agent runners. They span a weight range of three orders of magnitude and Clawdapus wraps them all identically:

    OpenClaw is the heavyweight — a full agent operating system with a Gateway control plane, the Pi Agent Core runtime, channels, crons, multi-model routing, skills, persistent memory. 430,000+ lines of TypeScript. 15+ channel adapters. The most capable and the most complex.

    Adoption is incremental. Take an existing bot — any runner, any framework — containerize it in a Clawfile, add a behavioral contract, and you have a managed Claw. You don't rewrite the bot. You wrap it.
    Nanobot is the lightweight — the same core agent loop (input → context → LLM → tools → persist) in ~4,000 lines of Python. MCP-native tool composition. Sub-second cold start. 45MB memory. Skills, memory, cron, multi-provider routing. Everything essential, nothing else.

    NanoClaw wraps Claude Code in container-isolated workspaces with per-group memory, agent swarms, and scheduled jobs. It already sandboxes — Clawdapus adds governance on top.

    Claude Code is the single-shot — one task, one execution, deep capability. No persistence, no channels, no scheduling. The sharpest scalpel.

    All are valid claw types. The Clawfile wraps them identically. A Claw can also run Swarm internally, or CrewAI, or a custom script. Clawdapus doesn't care what happens inside the workspace. It cares about purpose, judgment, lifecycle, and communication.

    Adoption is incremental. Take an existing bot — any runner, any framework, any weight class — containerize it in a Clawfile, add a behavioral contract, and you have a managed Claw. You don't rewrite the bot. You wrap it.

    ### cllama Module Ecosystem

    @@ -625,7 +682,7 @@ Personas are publishable, shareable, forkable artifacts. The layer separation ma

    **Why is the behavioral contract a bind mount?** Purpose changes faster than infrastructure. The bind mount means the operator changes purpose at the speed of editing a text file. It also means purpose is outside the blast radius of a compromised container.

    **Why does the contract filename vary by claw type?** Different runners are different systems. OpenClaw is a full agent OS with Pi, Nanobots, channels, skills, and multi-model routing. Claude Code is a single-execution tool. The runner defines what goes in the contract. Clawdapus guarantees the contract is present, read-only, and bind-mounted.
    **Why does the contract filename vary by claw type?** Different runners are different systems. OpenClaw is a full agent OS with a Gateway, Pi Agent Core, channels, skills, and multi-model routing. Nanobot is the same core pattern in 4,000 lines with its own skill system and memory. NanoClaw wraps Claude Code in isolated containers. Claude Code is a single-execution tool. The weight class determines the contract format. Clawdapus guarantees the contract is present, read-only, and bind-mounted.

    **Why is cllama a separate cognitive layer?** Think twice, act once. A reasoning model cannot be its own judge. Prompt-level guardrails are visible to the model and subject to the same reasoning they're trying to constrain. cllama separates capability from judgment. Different models, different masters, independent processes. Nothing leaves the Claw without being thought about twice.

    @@ -643,18 +700,22 @@ Personas are publishable, shareable, forkable artifacts. The layer separation ma

    **Why do services expose and Claws consume?** Because a service shouldn't reference itself. The CRM container declares what protocol it speaks and what port it listens on. The Claw declares which services it connects to. Clawdapus resolves the wiring. No circular references, no container names as config values on the same container.

    **Why are lightweight runners first-class?** Because governance is not proportional to complexity. A 4,000-line Nanobot agent running a market scanner with access to your brokerage API needs the same purpose contract, the same judgment proxy, the same lifecycle management, and the same audit trail as a 430,000-line OpenClaw agent. Complexity is the runner's problem. Governance is Clawdapus's problem. They are orthogonal.

    **Why support runners that already sandbox?** NanoClaw already does container isolation. Clawdapus wrapping NanoClaw is not double-sandboxing — it is adding a different layer. NanoClaw isolates the agent from the host. Clawdapus adds purpose contracts, judgment proxies, fleet coordination, surface topology, drift monitoring, and lifecycle governance. Isolation is a subset of management.

    **Why compute as a privilege?** Because an unmetered bot will consume whatever inference budget it can reach. The operator controls model selection, context windows, and invocation frequency. Every cognitive cycle is an authorized expenditure.

    ---

    ## XIV. What This Is Not

    Clawdapus is not an agent framework. It does not define how agents reason or execute. Use OpenClaw, Claude Code, Swarm, CrewAI, or whatever suits the problem inside the container.
    Clawdapus is not an agent framework. It does not define how agents reason or execute. Use OpenClaw, Nanobot, NanoClaw, Claude Code, Swarm, CrewAI, or whatever suits the problem inside the container. Heavyweight or lightweight — Clawdapus governs them identically.

    Clawdapus is not a bot-building tool. It helps you deploy, govern, monitor, and evolve bots that already exist.

    Clawdapus is infrastructure for bots the way Docker is infrastructure for applications. The layer below the framework. The layer above the operating system. Where deployment meets governance.

    ---

    *Clawdapus is open architecture. This manifesto defines the standard. Implementations follow.*
    *Clawdapus is open architecture. This manifesto defines the standard. Implementations follow.*
  2. mostlydev revised this gist Feb 12, 2026. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion clawdapus_manifesto.md
    View file
    Original file line number Diff line number Diff line change
    @@ -4,7 +4,7 @@

    ### A Manifesto for Containerized Agent Infrastructure

    v0.4 — February 2026
    v0.7 — February 2026

    ---

  3. mostlydev revised this gist Feb 12, 2026. 1 changed file with 2 additions and 2 deletions.
    4 changes: 2 additions & 2 deletions clawdapus_manifesto.md
    View file
    Original file line number Diff line number Diff line change
    @@ -4,7 +4,7 @@

    ### A Manifesto for Containerized Agent Infrastructure

    v0.6 — February 2026
    v0.4 — February 2026

    ---

    @@ -48,7 +48,7 @@ The Behavioral Contract is bind-mounted and read-only. The bot reads its purpose

    Everything else is mutable. The bot can install packages, write scripts, modify configuration, and reshape its environment. Sometimes as root. But mutations are intercepted by the tracking layer and become redeployment recipes — suggestions for what the next base image should include. The operator reviews the recipe and decides what to promote. Ad hoc evolution becomes permanent infrastructure through a human gate.

    ### Principle 3: Judgment Is a Proxy
    ### Principle 3: Think Twice, Act Once

    Think twice, act once. A reasoning model cannot be its own judge. Prompt-level guardrails are visible to the model and subject to the same reasoning they're trying to constrain. You're asking the engine to also be the brakes. cllama separates them. The runner thinks. cllama thinks again. Only then does the output reach the world. Two independent cognitive processes, two independent models, one gate. Nothing leaves the Claw without being thought about twice.

  4. mostlydev revised this gist Feb 12, 2026. 1 changed file with 52 additions and 28 deletions.
    80 changes: 52 additions & 28 deletions clawdapus_manifesto.md
    View file
    Original file line number Diff line number Diff line change
    @@ -4,7 +4,7 @@

    ### A Manifesto for Containerized Agent Infrastructure

    v0.4 — February 2026
    v0.6 — February 2026

    ---

    @@ -50,7 +50,7 @@ Everything else is mutable. The bot can install packages, write scripts, modify

    ### Principle 3: Judgment Is a Proxy

    A reasoning model cannot be its own judge. Prompt-level guardrails are visible to the model and subject to the same reasoning they're trying to constrain. You're asking the engine to also be the brakes. cllama separates them. It is the adult in the room — a separate cognitive process, running its own model, under the operator's exclusive control, sitting between the Claw and the world.
    Think twice, act once. A reasoning model cannot be its own judge. Prompt-level guardrails are visible to the model and subject to the same reasoning they're trying to constrain. You're asking the engine to also be the brakes. cllama separates them. The runner thinks. cllama thinks again. Only then does the output reach the world. Two independent cognitive processes, two independent models, one gate. Nothing leaves the Claw without being thought about twice.

    ### Principle 4: Compute Is a Privilege

    @@ -80,7 +80,7 @@ The traditional answer is to put guardrails inside the prompt. But prompt-level

    ### The Solution

    cllama is a separate LLM-powered process — running its own model, with its own policy configuration, under the operator's exclusive control — that evaluates the bot's output before it reaches the world. The bot never sees cllama's evaluation. It never knows its output was modified or dropped. The two layers are independent: the runner optimizes for capability, cllama optimizes for judgment.
    Think twice, act once. cllama is a separate LLM-powered process — running its own model, with its own policy configuration, under the operator's exclusive control — that evaluates the bot's output before it reaches the world. The runner thinks about what to say. cllama thinks about whether to say it. The bot never sees cllama's evaluation. It never knows its output was modified or dropped. Two independent cognitive processes, two independent models, one gate.

    While the runner handles the logic of a task, cllama answers the institutional questions:

    @@ -139,7 +139,13 @@ The Clawfile is not a separate configuration format. It is a Dockerfile with ext

    Any valid Dockerfile is a valid Clawfile.

    This means Clawdapus inherits the entire Docker ecosystem: registries, layer caching, multi-stage builds, BuildKit, CI/CD pipelines, and every tool that understands OCI images. A Clawfile builds into a standard OCI container image with additional metadata labels that the Clawdapus runtime interprets.
    ### Compilation

    A Clawfile compiles down to a standard Dockerfile. `claw build` is a preprocessor — it reads the Clawfile, translates extended directives into standard Dockerfile primitives, and calls `docker build` on the result. The output is a standard OCI container image. No custom build engine.

    Extended directives compile to LABELs (metadata the runtime interprets), ENV vars (configuration the container reads), RUN commands (filesystem setup), and conventional file paths (cron entries, package manager wrappers, skill mount points). CLLAMA becomes a set of labels declaring the default judgment stack. AGENT becomes a label declaring the expected bind mount path. INVOKE becomes cron entries written into the image. TRACK becomes wrapper scripts around package managers. SURFACE becomes topology metadata labels.

    This means Clawdapus inherits the entire Docker ecosystem: registries, layer caching, multi-stage builds, BuildKit, CI/CD pipelines, and every tool that understands OCI images. A compiled Clawfile is just a Dockerfile. A built Claw is just a Docker image. Anyone can inspect the compiled output, debug with standard tools, or eject from Clawdapus entirely and still have a working container.

    ### Claw Types: The Base Image

    @@ -159,7 +165,7 @@ Any agent runner can be a claw type. The requirement is that the runner is insta

    **CONFIGURE** — Shell commands that run at container init, mutating base defaults into this Claw's setup. Tools like jq and sed for fine-grained changes. `claw-module enable/disable` for schema-aware cascading changes.

    **CLLAMA** — References the outer judgment proxy. Namespaced policy prefix, provider, model, then module declarations. Pulled from registry at invocation time.
    **CLLAMA** — The default judgment proxy baked into the image. Namespaced policy prefix, provider, model, then module declarations. Overridable per-deployment in claw-pod.yml, same as CMD is overridable by compose's command.

    **INVOKE** — Invocation schedules. For simple runners, cron lines that trigger execution. For runners like OpenClaw that have their own internal scheduling, INVOKE manages the container lifecycle on a macro schedule while the runner handles micro-scheduling internally.

    @@ -173,7 +179,7 @@ Any agent runner can be a claw type. The requirement is that the runner is insta

    **ACT** — Worker-mode directives. Install packages, import knowledge, configure the runtime. Snapshot when done.

    **SURFACE** — Declares communication interfaces and tool access. Volumes, networks, chat platforms, APIs, Discord servers. Service surfaces carry describe blocks that get assembled into the Claw's skill map.
    **SURFACE** — Declares what this Claw consumes. Volumes, queues, chat platforms, APIs, MCP services. Clawdapus resolves service references against expose blocks in the pod, assembles the skill map, and enforces service-side cllama requirements.

    ### A Complete Clawfile

    @@ -218,6 +224,7 @@ INVOKE 0 */4 * * * drift-check
    SURFACE volume://shared-cache read-write
    SURFACE queue://fleet/signals subscribe
    SURFACE discord://crypto-ops/general read-write
    SURFACE service://company-crm read-write
    SURFACE http://master:9000/api report

    # Privilege modes
    @@ -315,6 +322,10 @@ The workspace is a drafting table. The image is the finished blueprint. The reci

    Just as the Clawfile extends the Dockerfile, `claw-pod.yml` extends docker-compose. Any valid compose file is a valid claw-pod.yml. Extended keys live under an `x-claw` namespace, which Docker already ignores. Existing tooling works unchanged.

    The relationship between Clawfile and claw-pod.yml mirrors Dockerfile and compose exactly. The Clawfile bakes defaults into the image — the default CLLAMA stack, the default INVOKE schedule, the default SURFACE declarations, the default MODEL bindings. The claw-pod.yml overrides per-deployment. `CLLAMA` in the Clawfile is `CMD` in a Dockerfile — the shipped default. `cllama:` in claw-pod.yml is `command:` in compose — the deployment-specific override. Same image, different judgment. Same image, different schedule. Same image, different surfaces.

    This means a single Claw image can be deployed across environments with different cllama stacks (staging uses verbose logging judgment, production uses strict policy), different invoke schedules (dev runs hourly, prod runs every five minutes), and different surface access (dev connects to sandbox APIs, prod connects to live services) — all without rebuilding.

    Anyone who knows compose knows this file.

    ### Mixed Clusters
    @@ -373,7 +384,7 @@ services:
    - volume://shared-cache: read-write
    - discord://crypto-ops/general: read-write
    - http://market-scanner:8080/api: read
    - mcp://company-crm:3100: read
    - service://company-crm: read-write
    describe:
    role: "Original crypto market commentary"
    outputs: ["tweets", "threads", "discord posts"]
    @@ -446,26 +457,30 @@ services:
    networks:
    - internal

    # Service container exposing MCP — tools self-discovered at pod startup
    # MCP service container — runs npx package, holds API keys,
    # exposes tools over MCP protocol. Not a Claw — no runner, no contract.
    company-crm:
    image: custom/crm-mcp-bridge:latest
    x-claw:
    surfaces:
    - mcp://company-crm:3100: read-write
    expose:
    protocol: mcp
    port: 3100
    # Tools self-discovered via MCP tool listing at pod startup.
    # Clawdapus queries the MCP server, ingests tool definitions,
    # and injects them into skill maps of Claws with surface access.
    require_cllama:
    # Any Claw calling this service must route through these policies.
    # The service knows its own risk profile — customer PII, deal
    # financials, write operations that modify production CRM state.
    - policy/customer-data-access
    - policy/pii-gate
    describe:
    role: "Company CRM with customer and deal data"
    mcp: "http://company-crm:3100/mcp"
    # Tools are self-discovered via MCP tool listing at pod startup.
    # No manual capability declaration needed — the MCP server
    # advertises its own tools. Clawdapus discovers them and injects
    # them into the skill maps of Claws with surface access.
    #
    # Tool calls from Claws are mediated through cllama:
    # - "Should this bot create a ticket for this customer?"
    # - "Should this bot access deal financials?"
    # Same institutional questions as content gating, applied to actions.
    networks:
    - internal
    environment:
    CRM_API_KEY: ${CRM_API_KEY}
    CRM_INSTANCE_URL: ${CRM_INSTANCE_URL}

    # --- Future extensions ---
    #
    @@ -488,13 +503,15 @@ services:

    Surfaces serve two purposes. For the operator, they are a topology map — where can communication happen, what can reach what, what are the egress boundaries. For the bots, they are capability discovery — what tools and services exist in this pod, what can I do with them.

    A service container — a CRM, a market data API, a ticketing system, an analytics pipeline — exposes a surface with a describe block that provides context about its role. If the service exposes an MCP (Model Context Protocol) endpoint, its tools are self-discovered at pod startup — the MCP server advertises its own capabilities via the standard tool listing, and Clawdapus ingests them automatically. No manual capability declaration needed. Services that don't speak MCP can expose REST APIs with OpenAPI specs, or declare capabilities directly in their describe block. The standard is format-flexible. What matters is that descriptions are rich enough for a bot's runner to understand what the service does and how to call it.
    **Services expose. Claws consume.** A service container — a CRM bridge, a market data API, a ticketing system — declares what it exposes via an `expose` block in its `x-claw` configuration. A Claw declares which services it connects to in its `surfaces` list. Clawdapus wires them together. The service never references itself; the consumer never needs to know the service's internal port or protocol.

    Clawdapus collects discovered capabilities from all surfaces a Claw has access to — based on its SURFACE declarations — and assembles them into a **skill map**. The skill map is the complete set of capabilities available to that Claw: every service it can reach, every tool it can call, every data source it can query. Different Claws in the same pod may have different skill maps because they have different surface access.
    **MCP services** are containerized MCP servers — typically an npx package running in a Docker container with environment variables holding API keys for the external service it bridges. The container exposes the MCP protocol on a port. At pod startup, Clawdapus queries the MCP server's tool listing and ingests the advertised tools automatically. No manual capability declaration needed — the MCP server describes itself. Services that don't speak MCP can expose REST APIs with OpenAPI specs, or declare capabilities directly in their describe block. The standard is format-flexible.

    The skill map is delivered to the runner via a **skill mount** — a read-only mount point where the runner can discover available capabilities at invocation time. For OpenClaw, the skill map maps naturally onto its Nanobot and skill architecture — each discovered capability becomes a skill the runner can invoke. For Claude Code, capabilities become tool definitions. For a generic runner, the skill mount is a directory of capability descriptions in a standard format that the runner parses however it wants.
    **Service-side cllama requirements.** The service knows its own risk profile. A CRM holds customer PII and deal financials. A payment gateway can move money. A production database can be destroyed. The service declares — via `require_cllama` — what judgment policies any calling Claw must route through before its tool calls reach the MCP server. This is not the Claw's own cllama (which governs content output and tone). This is a service-mandated policy layer that sits between the Claw and the service, enforced by Clawdapus regardless of the Claw's own configuration. The Claw's cllama asks "should we say this?" The service's required cllama asks "should we do this?"

    Clawdapus collects discovered capabilities from all surfaces a Claw has access to and assembles them into a **skill map**. The skill map is the complete set of capabilities available to that Claw: every service it can reach, every tool it can call, every data source it can query. Different Claws in the same pod may have different skill maps because they have different surface access.

    Tool calls — not just content output — are mediated through cllama. When a Claw invokes an MCP tool or calls a service API, the call routes through the judgment proxy. "Should this Claw create a ticket in the CRM right now, for this customer, in this context?" is the same class of institutional question as "can we say this here?" — applied to actions instead of words. The operator's policy layer governs what the bot does, not just what it says.
    The skill map is delivered to the runner via a **skill mount** — a read-only mount point where the runner can discover available capabilities at invocation time. For OpenClaw, the skill map maps naturally onto its Nanobot and skill architecture — each discovered capability becomes a skill the runner can invoke. For Claude Code, capabilities become tool definitions. For a generic runner, the skill mount is a directory of capability descriptions in a standard format that the runner parses however it wants.

    ```
    $ claw skillmap crypto-crusher-0
    @@ -506,10 +523,11 @@ Available capabilities for crypto-crusher-0:
    get_whale_activity Large wallet movements in last N hours
    get_market_sentiment Aggregated fear/greed and social volume
    FROM company-crm (mcp://company-crm:3100) [auto-discovered]:
    FROM company-crm (mcp, auto-discovered):
    lookup_customer Find customer by name, email, or account ID
    create_ticket Open support ticket linked to a customer
    get_deal_status Current pipeline stage and value for any deal
    ⚠ requires cllama: policy/customer-data-access, policy/pii-gate
    FROM shared-cache (volume://shared-cache):
    read-write File-based data exchange
    @@ -518,9 +536,9 @@ Available capabilities for crypto-crusher-0:
    subscribe Fleet coordination messages
    ```

    The skill map is regenerated when the pod topology changes — when a service comes up or goes down, when surface declarations change, when describe blocks are updated. The runner always has a current view of what it can do. If the market-scanner goes down, its capabilities disappear from the skill map. The runner can't call a service that isn't there.
    The skill map is regenerated when the pod topology changes — when a service comes up or goes down, when surface declarations change, when an MCP server's tool listing changes. The runner always has a current view of what it can do. If the market-scanner goes down, its capabilities disappear from the skill map. The runner can't call a service that isn't there.

    This means adding a new capability to the pod is a three-step process: deploy the service container with a describe block, declare the surface in the Claws that should have access, and restart the affected Claws. The runner discovers the new capability through the skill mount. No code changes. No retraining. The skill map grows with the pod.
    This means adding a new capability to the pod is a three-step process: deploy the service container with an expose block, declare the surface in the Claws that should have access, and restart the affected Claws. The runner discovers the new capability through the skill mount. No code changes. No retraining. The skill map grows with the pod.

    ### Pods Referencing Pods

    @@ -603,11 +621,13 @@ Personas are publishable, shareable, forkable artifacts. The layer separation ma

    **Why extend Docker?** The hard problems of containerization are solved. Extending Docker inherits decades of infrastructure investment. Building a parallel ecosystem means solving those problems again, badly.

    **Why do Clawfiles compile to Dockerfiles?** Because no custom build engine survives contact with production. `claw build` is a preprocessor, not a build system. Extended directives compile to LABELs, ENV vars, RUN commands, and filesystem conventions. The output is a standard Dockerfile. `docker build` does the rest. Any CI/CD pipeline, any registry, any debugging tool works unchanged. Eject from Clawdapus and you still have a working container.

    **Why is the behavioral contract a bind mount?** Purpose changes faster than infrastructure. The bind mount means the operator changes purpose at the speed of editing a text file. It also means purpose is outside the blast radius of a compromised container.

    **Why does the contract filename vary by claw type?** Different runners are different systems. OpenClaw is a full agent OS with Pi, Nanobots, channels, skills, and multi-model routing. Claude Code is a single-execution tool. The runner defines what goes in the contract. Clawdapus guarantees the contract is present, read-only, and bind-mounted.

    **Why is cllama a separate cognitive layer?** Because a reasoning model cannot be its own judge. Prompt-level guardrails are visible to the model and subject to the same reasoning they're trying to constrain. cllama separates capability from judgment. Different models, different masters, independent processes.
    **Why is cllama a separate cognitive layer?** Think twice, act once. A reasoning model cannot be its own judge. Prompt-level guardrails are visible to the model and subject to the same reasoning they're trying to constrain. cllama separates capability from judgment. Different models, different masters, independent processes. Nothing leaves the Claw without being thought about twice.

    **Why is cllama identity-aware?** Because "policy" without "identity" is just a spam filter. The same output can be appropriate or inappropriate depending on who produces it and who receives it.

    @@ -619,6 +639,10 @@ Personas are publishable, shareable, forkable artifacts. The layer separation ma

    **Why skill maps and skill mounts?** Because a bot that can't discover its available tools is useless, and a bot that hardcodes its tool integrations is brittle. The skill map is assembled from the pod topology at runtime. Add a service, the skill map grows. Remove a service, it shrinks. The runner discovers capabilities through a standard mount point, same way it discovers its behavioral contract. No code changes to add tools. No retraining to remove them.

    **Why do services declare cllama requirements?** Because the service knows its own risk profile. The Claw's cllama governs what the bot says. The service's required cllama governs what the bot does — to the service's data, through the service's API. A CRM holding customer PII should mandate PII policy regardless of which Claw is calling. The judgment requirement travels with the service, not the consumer.

    **Why do services expose and Claws consume?** Because a service shouldn't reference itself. The CRM container declares what protocol it speaks and what port it listens on. The Claw declares which services it connects to. Clawdapus resolves the wiring. No circular references, no container names as config values on the same container.

    **Why compute as a privilege?** Because an unmetered bot will consume whatever inference budget it can reach. The operator controls model selection, context windows, and invocation frequency. Every cognitive cycle is an authorized expenditure.

    ---
  5. mostlydev revised this gist Feb 12, 2026. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion clawdapus_manifesto.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,4 +1,4 @@
    # The Clawdapus Clawfile
    # The Clawdapus Claw

    ## Declarative Bot Instantiation

  6. mostlydev revised this gist Feb 12, 2026. 1 changed file with 60 additions and 39 deletions.
    99 changes: 60 additions & 39 deletions clawdapus_manifesto.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,4 +1,4 @@
    # CLAWDAPUS
    # The Clawdapus Clawfile

    ## Declarative Bot Instantiation

    @@ -58,7 +58,7 @@ Every cognitive cycle is an authorized expenditure of resources. Inference cost

    ### Principle 5: Configuration Is Code

    Every tentacle's configuration is a documented deviation from its base image's defaults. Configurations are diffable across tentacles. Behavior changes are tracked in version control. The fleet is auditable at every layer.
    Every Claw's configuration is a documented deviation from its base image's defaults. Configurations are diffable across Claws. Behavior changes are tracked in version control. The fleet is auditable at every layer.

    ### Principle 6: Drift Is Quantifiable

    @@ -109,15 +109,15 @@ CLLAMA cllama-org-policy/xai/grok-4.1-fast \
    purpose/engagement-farming
    ```

    The first segment — `cllama-org-policy/xai/grok-4.1-fast` — identifies the base judgment layer: organizational namespace, provider, model. Different tentacles in the same pod can run different judgment stacks. High-volume tentacles use fast cheap judgment. Sensitive tentacles use careful expensive judgment.
    The first segment — `cllama-org-policy/xai/grok-4.1-fast` — identifies the base judgment layer: organizational namespace, provider, model. Different Claws in the same pod can run different judgment stacks. High-volume Claws use fast cheap judgment. Sensitive Claws use careful expensive judgment.

    The modules that follow are layered on top:

    **Obfuscation** — Behavioral variance injection. Timing jitter, vocabulary rotation, stylistic drift. The bot does not know it is being humanized. Systematic behavioral camouflage managed as infrastructure.

    **Policy** — Hard rails. Financial advice, medical claims, legal exposure — intercepted and either rewritten or dropped. The bot never sees the rejection.

    **Tone** — Voice shaping. Raw output in, persona-voiced output out. Swappable without changing the behavioral contract. A/B testable across tentacles.
    **Tone** — Voice shaping. Raw output in, persona-voiced output out. Swappable without changing the behavioral contract. A/B testable across Claws.

    **Purpose** — Strategic objective evaluation. Does this output serve the operator's goal? Evaluated relative to who this bot is supposed to be.

    @@ -157,13 +157,13 @@ Any agent runner can be a claw type. The requirement is that the runner is insta

    **AGENT** — Names the behavioral contract file. Bind-mounted read-only from the host. Filename follows the runner's convention.

    **CONFIGURE** — Shell commands that run at container init, mutating base defaults into this tentacle's setup. Tools like jq and sed for fine-grained changes. `claw-module enable/disable` for schema-aware cascading changes.
    **CONFIGURE** — Shell commands that run at container init, mutating base defaults into this Claw's setup. Tools like jq and sed for fine-grained changes. `claw-module enable/disable` for schema-aware cascading changes.

    **CLLAMA** — References the outer judgment proxy. Namespaced policy prefix, provider, model, then module declarations. Pulled from registry at invocation time.

    **INVOKE** — Invocation schedules. For simple runners, cron lines that trigger execution. For runners like OpenClaw that have their own internal scheduling, INVOKE manages the container lifecycle on a macro schedule while the runner handles micro-scheduling internally.

    **PRIVILEGE** — Per-mode privilege levels. Worker gets root. Runtime drops to standard user. Lockdown restricts filesystem and network for quarantined tentacles.
    **PRIVILEGE** — Per-mode privilege levels. Worker gets root. Runtime drops to standard user. Lockdown restricts filesystem and network for quarantined Claws.

    **TRACK** — Package manager interception. Wraps apt, pip, npm, cargo. Every install logged with context. Logs become redeployment recipes.

    @@ -173,7 +173,7 @@ Any agent runner can be a claw type. The requirement is that the runner is insta

    **ACT** — Worker-mode directives. Install packages, import knowledge, configure the runtime. Snapshot when done.

    **SURFACE** — Declares communication interfaces and tool access. Volumes, networks, chat platforms, APIs, Discord servers. Service surfaces carry describe blocks that get assembled into the tentacle's skill map.
    **SURFACE** — Declares communication interfaces and tool access. Volumes, networks, chat platforms, APIs, Discord servers. Service surfaces carry describe blocks that get assembled into the Claw's skill map.

    ### A Complete Clawfile

    @@ -259,7 +259,7 @@ The identity from the persona is what cllama receives as input when evaluating o

    ### Forking

    Personas are forkable. Snapshot a running tentacle that has accumulated memory and knowledge over months. Fork it. The fork inherits everything. Only the patched fields diverge. Deploy the fork with a different behavioral contract and you have two bots that share history and knowledge but differ in purpose and voice. A bull and a bear from the same analyst. An enthusiast and a skeptic from the same reviewer.
    Personas are forkable. Snapshot a running Claw that has accumulated memory and knowledge over months. Fork it. The fork inherits everything. Only the patched fields diverge. Deploy the fork with a different behavioral contract and you have two bots that share history and knowledge but differ in purpose and voice. A bull and a bear from the same analyst. An enthusiast and a skeptic from the same reviewer.

    ### Layer Independence

    @@ -296,7 +296,7 @@ Apply? claw bake poly-piper --from-recipe latest

    The operator reviews. Decides what to promote. Rebuilds. Ad hoc evolution becomes permanent infrastructure through a human gate.

    Worker mode is the deliberate version. Spin up a tentacle in worker mode, let it install and configure — ACT directives or manual interaction — then snapshot the result. One worker sets the stage. Multiple copies inherit it.
    Worker mode is the deliberate version. Spin up a Claw in worker mode, let it install and configure — ACT directives or manual interaction — then snapshot the result. One worker sets the stage. Multiple copies inherit it.

    ```
    $ claw up poly-piper --mode worker
    @@ -319,7 +319,7 @@ Anyone who knows compose knows this file.

    ### Mixed Clusters

    A pod is not a collection of bots. It is a mixed cluster of cognitive and non-cognitive services. An operations pod might contain several OpenClaw tentacles with different personas, a Claude Code tentacle for one-off tasks, a market data scanner that's just a plain Docker container, a Redis instance, and an operator dashboard.
    A pod is not a collection of bots. It is a mixed cluster of cognitive and non-cognitive services. An operations pod might contain several OpenClaw Claws with different personas, a Claude Code Claw for one-off tasks, a market data scanner that's just a plain Docker container, a Redis instance, and an operator dashboard.

    Regular Docker containers participate as first-class pod members. A web application running inside the pod carries a describe block — machine-readable self-description of what it does, what it produces, what it consumes. Other services discover it. The master claw reasons about it. It's not a black box — it's a participant in a system of components that understand each other's purposes.

    @@ -402,7 +402,8 @@ services:
    - internal
    - public-egress

    # Plain Docker container — not a tentacle, but a full pod member
    # Plain Docker container — not a Claw, but a full pod member.
    # No MCP — capabilities declared manually in describe block.
    market-scanner:
    image: custom/market-scanner:latest
    x-claw:
    @@ -445,7 +446,7 @@ services:
    networks:
    - internal

    # Service container exposing MCP — bots discover it as a skill
    # Service container exposing MCP — tools self-discovered at pod startup
    company-crm:
    image: custom/crm-mcp-bridge:latest
    x-claw:
    @@ -454,76 +455,96 @@ services:
    describe:
    role: "Company CRM with customer and deal data"
    mcp: "http://company-crm:3100/mcp"
    capabilities:
    - name: "lookup_customer"
    description: "Find customer by name, email, or account ID"
    - name: "create_ticket"
    description: "Open a support ticket linked to a customer"
    - name: "get_deal_status"
    description: "Current pipeline stage and value for any deal"
    # Tools are self-discovered via MCP tool listing at pod startup.
    # No manual capability declaration needed — the MCP server
    # advertises its own tools. Clawdapus discovers them and injects
    # them into the skill maps of Claws with surface access.
    #
    # Tool calls from Claws are mediated through cllama:
    # - "Should this bot create a ticket for this customer?"
    # - "Should this bot access deal financials?"
    # Same institutional questions as content gating, applied to actions.
    networks:
    - internal

    # --- Future extensions ---
    #
    # security_groups:
    # ops-team:
    # members: [crypto-crusher, echo-squad, fleet-master]
    # surfaces: [shared-cache, fleet/signals]
    # client-facing:
    # members: [crypto-crusher, company-crm]
    # surfaces: [discord://crypto-ops/general]
    # cllama_overlay: policy/client-safe
    #
    # Security groups control surface access by membership rather than
    # per-service declaration. A Claw inherits surface access from
    # its group memberships. Groups can also attach cllama policy overlays
    # that apply to all tool calls and output on group-scoped surfaces.
    ```

    ### Surfaces, Skill Maps, and Skill Mounts

    Surfaces serve two purposes. For the operator, they are a topology map — where can communication happen, what can reach what, what are the egress boundaries. For the bots, they are capability discovery — what tools and services exist in this pod, what can I do with them.

    A service container — a CRM, a market data API, a ticketing system, an analytics pipeline — exposes a surface with a describe block that explains what it offers. Some services expose MCP (Model Context Protocol) endpoints, which are already the standard for machine-readable tool descriptions. Some expose REST APIs with OpenAPI specs. Some expose simpler capability manifests in the describe block itself. The format doesn't matter. What matters is that the description is rich enough for a bot's runner to understand what the service does and how to call it.
    A service container — a CRM, a market data API, a ticketing system, an analytics pipeline — exposes a surface with a describe block that provides context about its role. If the service exposes an MCP (Model Context Protocol) endpoint, its tools are self-discovered at pod startup — the MCP server advertises its own capabilities via the standard tool listing, and Clawdapus ingests them automatically. No manual capability declaration needed. Services that don't speak MCP can expose REST APIs with OpenAPI specs, or declare capabilities directly in their describe block. The standard is format-flexible. What matters is that descriptions are rich enough for a bot's runner to understand what the service does and how to call it.

    Clawdapus collects discovered capabilities from all surfaces a Claw has access to — based on its SURFACE declarations — and assembles them into a **skill map**. The skill map is the complete set of capabilities available to that Claw: every service it can reach, every tool it can call, every data source it can query. Different Claws in the same pod may have different skill maps because they have different surface access.

    Clawdapus collects the describe blocks from all surfaces a tentacle has access to — based on its SURFACE declarations — and assembles them into a **skill map**. The skill map is the complete set of capabilities available to that tentacle: every service it can reach, every tool it can call, every data source it can query. Different tentacles in the same pod may have different skill maps because they have different surface access.
    The skill map is delivered to the runner via a **skill mount** — a read-only mount point where the runner can discover available capabilities at invocation time. For OpenClaw, the skill map maps naturally onto its Nanobot and skill architecture — each discovered capability becomes a skill the runner can invoke. For Claude Code, capabilities become tool definitions. For a generic runner, the skill mount is a directory of capability descriptions in a standard format that the runner parses however it wants.

    The skill map is delivered to the runner via a **skill mount** — a read-only mount point where the runner can discover available capabilities at invocation time. For OpenClaw, the skill map maps naturally onto its Nanobot and skill architecture — each described capability becomes a skill the runner can invoke. For Claude Code, capabilities become tool definitions. For a generic runner, the skill mount is a directory of capability descriptions in a standard format that the runner parses however it wants.
    Tool calls — not just content output — are mediated through cllama. When a Claw invokes an MCP tool or calls a service API, the call routes through the judgment proxy. "Should this Claw create a ticket in the CRM right now, for this customer, in this context?" is the same class of institutional question as "can we say this here?" — applied to actions instead of words. The operator's policy layer governs what the bot does, not just what it says.

    ```
    $ claw skillmap crypto-crusher-0
    Available capabilities for crypto-crusher-0:
    FROM market-scanner (http://market-scanner:8080/api):
    get_price Current and historical token price data
    get_whale_activity Large wallet movements in last N hours
    get_price Current and historical token price data
    get_whale_activity Large wallet movements in last N hours
    get_market_sentiment Aggregated fear/greed and social volume
    FROM company-crm (mcp://company-crm:3100):
    lookup_customer Find customer by name, email, or account ID
    create_ticket Open support ticket linked to a customer
    get_deal_status Current pipeline stage and value for any deal
    FROM company-crm (mcp://company-crm:3100) [auto-discovered]:
    lookup_customer Find customer by name, email, or account ID
    create_ticket Open support ticket linked to a customer
    get_deal_status Current pipeline stage and value for any deal
    FROM shared-cache (volume://shared-cache):
    read-write File-based data exchange
    read-write File-based data exchange
    FROM fleet/signals (queue://fleet/signals):
    subscribe Fleet coordination messages
    subscribe Fleet coordination messages
    ```

    The skill map is regenerated when the pod topology changes — when a service comes up or goes down, when surface declarations change, when describe blocks are updated. The runner always has a current view of what it can do. If the market-scanner goes down, its capabilities disappear from the skill map. The runner can't call a service that isn't there.

    This means adding a new capability to the pod is a three-step process: deploy the service container with a describe block, declare the surface in the tentacles that should have access, and restart the affected tentacles. The runner discovers the new capability through the skill mount. No code changes. No retraining. The skill map grows with the pod.
    This means adding a new capability to the pod is a three-step process: deploy the service container with a describe block, declare the surface in the Claws that should have access, and restart the affected Claws. The runner discovers the new capability through the skill mount. No code changes. No retraining. The skill map grows with the pod.

    ### Pods Referencing Pods

    Pods can share surfaces at their boundaries. A crypto operations pod and a content marketing pod share a volume where analyst output from one becomes source material for the other. Each pod independently managed. Coordination at the surface level. Skill maps are pod-scoped — a tentacle only sees capabilities within its own pod and any explicitly shared cross-pod surfaces.
    Pods can share surfaces at their boundaries. A crypto operations pod and a content marketing pod share a volume where analyst output from one becomes source material for the other. Each pod independently managed. Coordination at the surface level. Skill maps are pod-scoped — a Claw only sees capabilities within its own pod and any explicitly shared cross-pod surfaces.

    ---

    ## X. The Master Claw

    The Master is also a claw. A container with an agent runner, a behavioral contract, and a cllama layer, same as any other. Its contract defines administrative behavior — what to monitor, what drift thresholds to enforce, when to escalate.
    The master claw is a Claw. A container with an agent runner, a behavioral contract, and a cllama layer, same as any other. Its contract defines administrative behavior — what to monitor, what drift thresholds to enforce, when to escalate.

    It can manage tentacle lifecycle. Push configuration overrides. Promote recipes. Demote or quarantine tentacles based on drift.
    It can manage Claw lifecycle. Push configuration overrides. Promote recipes. Demote or quarantine Claws based on drift.

    It cannot modify any tentacle's behavioral contract. It cannot modify its own. Purpose always flows from the human operator, through files on the host.
    It cannot modify any Claw's behavioral contract. It cannot modify its own. Purpose always flows from the human operator, through files on the host.

    When the inner runner and the outer cllama disagree about a tentacle's output, cllama wins by default. But the disagreement is logged as drift. The master claw reviews drift across the fleet and determines whether the runner is hallucinating or whether the persona has evolved in a way that requires a contract update — a question it escalates to the operator, because the master doesn't define purpose either.
    When the inner runner and the outer cllama disagree about a Claw's output, cllama wins by default. But the disagreement is logged as drift. The master claw reviews drift across the fleet and determines whether the runner is hallucinating or whether the persona has evolved in a way that requires a contract update — a question it escalates to the operator, because the master doesn't define purpose either.

    ---

    ## XI. Drift, Disagreement, and Monitoring

    In a multi-agent system, disagreement between the runner and cllama is a data point, not a failure.

    Every tentacle has a drift score. Drift scoring is not self-reported — an independent process examines outputs, compares against the contract and cllama policy, and reports to the master.
    Every Claw has a drift score. Drift scoring is not self-reported — an independent process examines outputs, compares against the contract and cllama policy, and reports to the master.

    ```
    $ claw ps
    @@ -564,9 +585,9 @@ Built entirely on Docker primitives. Clawfiles are Dockerfiles. claw-pod.yml is

    ### Runner Compatibility

    Clawdapus operates beneath agent runners. OpenClaw is a full agent operating system — Pi, Nanobots, channels, crons, multi-model routing, skills, persistent memory. Claude Code is a focused single-execution runner. Both are valid claw types. The Clawfile wraps them identically. A tentacle can also run Swarm internally, or CrewAI, or a custom script. Clawdapus doesn't care what happens inside the workspace. It cares about purpose, judgment, lifecycle, and communication.
    Clawdapus operates beneath agent runners. OpenClaw is a full agent operating system — Pi, Nanobots, channels, crons, multi-model routing, skills, persistent memory. Claude Code is a focused single-execution runner. Both are valid claw types. The Clawfile wraps them identically. A Claw can also run Swarm internally, or CrewAI, or a custom script. Clawdapus doesn't care what happens inside the workspace. It cares about purpose, judgment, lifecycle, and communication.

    Adoption is incremental. Take an existing bot — any runner, any framework — containerize it in a Clawfile, add a behavioral contract, and you have a managed tentacle. You don't rewrite the bot. You wrap it.
    Adoption is incremental. Take an existing bot — any runner, any framework — containerize it in a Clawfile, add a behavioral contract, and you have a managed Claw. You don't rewrite the bot. You wrap it.

    ### cllama Module Ecosystem

  7. mostlydev revised this gist Feb 12, 2026. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion clawdapus_manifesto.md
    View file
    Original file line number Diff line number Diff line change
    @@ -509,7 +509,7 @@ Pods can share surfaces at their boundaries. A crypto operations pod and a conte
    ## X. The Master Claw
    The master claw is a tentacle. A container with an agent runner, a behavioral contract, and a cllama layer, same as any other. Its contract defines administrative behavior — what to monitor, what drift thresholds to enforce, when to escalate.
    The Master is also a claw. A container with an agent runner, a behavioral contract, and a cllama layer, same as any other. Its contract defines administrative behavior — what to monitor, what drift thresholds to enforce, when to escalate.
    It can manage tentacle lifecycle. Push configuration overrides. Promote recipes. Demote or quarantine tentacles based on drift.
  8. mostlydev created this gist Feb 12, 2026.
    615 changes: 615 additions & 0 deletions clawdapus_manifesto.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,615 @@
    # CLAWDAPUS

    ## Declarative Bot Instantiation

    ### A Manifesto for Containerized Agent Infrastructure

    v0.4 — February 2026

    ---

    ## I. The Thesis

    Every agent framework in existence answers the same question: how do I make agents collaborate on tasks? Swarm coordinates handoffs. CrewAI assigns roles. LangGraph builds execution graphs. AgentStack scaffolds projects. They are all application-layer orchestration systems built on a shared assumption: the agent is a trusted process doing work for the operator.

    Clawdapus starts from the opposite premise. The agent is an untrusted workload.

    It is a container that can think, and like any container, it must be reproducible, inspectable, diffable, and killable. Its purpose is not its own to define. Its schedule is not its own to set. But within those boundaries, it is alive. It can grow. It can install tools, build scripts, modify its workspace, and adapt to its environment. It is a managed organism, not a jailed process.

    This is infrastructure-layer containment for cognitive workloads. Clawdapus does not replace agent runners any more than Docker replaces Flask. It operates beneath them — the layer where deployment meets governance.

    Swarm is for agents that work *for* you. Clawdapus is for bots that work *as* you. Different trust model. Different stack.

    ---

    ## II. The Anatomy of a Claw

    A running Claw bifurcates cognition into two independent layers: internal execution and external judgment.

    **The Runner (Internal Execution)** — An agent runtime installed in the base image. OpenClaw is the most capable example: its Pi reasoning core handles planning and decision-making, while its Nanobots are atomic skills that execute specific tasks — browsing, file operations, API calls, shell commands. But the runner can be anything. Claude Code is a single-execution runner. A custom Python agent is a runner. The runner handles the *how* of any given task.

    **The Behavioral Contract (The Law)** — A read-only, bind-mounted file whose name follows the runner's convention. For OpenClaw, this is AGENTS.md. For Claude Code, CLAUDE.md. The contract defines the *what* — what the Claw is allowed to be, what it should do, what it must never do. It lives on the host filesystem, outside the container. Even a root-compromised runner cannot rewrite its own mission.

    **The Persona (The History)** — A mutable workspace of identity, memory, knowledge, style, and accumulated interaction history. This is the *who* — who the Claw has become over time. Personas are downloadable, versionable, forkable OCI artifacts. They grow during operation and can be snapshotted and promoted.

    **cllama (The Judgment Proxy)** — An external, LLM-powered proxy that sits between the Claw and the world. It uses the identity of the Claw *and* the identity of the outside party to apply policy, shape tone, enforce strategy, and gate risk. cllama handles the *should*. Should this output reach the world? Should this action proceed? Should this communication go to this recipient in this tone? The runner never sees cllama's evaluation. The two cognitive layers are independent: the runner optimizes for capability, cllama optimizes for judgment.

    These four components — runner, contract, persona, cllama — are the anatomy of every Claw. They are independently versioned, independently deployable, and independently auditable. Swap the runner without touching the persona. Swap the persona without touching the contract. Swap the judgment layer without touching any of them.

    ---

    ## III. Core Principles

    ### Principle 1: Purpose Is Sacred

    The Behavioral Contract is bind-mounted and read-only. The bot reads its purpose on every invocation but cannot alter, append to, or reason about the constraint document itself. If the contract is not present at boot, the container does not start. A Claw without purpose does not run.

    ### Principle 2: The Workspace Is Alive

    Everything else is mutable. The bot can install packages, write scripts, modify configuration, and reshape its environment. Sometimes as root. But mutations are intercepted by the tracking layer and become redeployment recipes — suggestions for what the next base image should include. The operator reviews the recipe and decides what to promote. Ad hoc evolution becomes permanent infrastructure through a human gate.

    ### Principle 3: Judgment Is a Proxy

    A reasoning model cannot be its own judge. Prompt-level guardrails are visible to the model and subject to the same reasoning they're trying to constrain. You're asking the engine to also be the brakes. cllama separates them. It is the adult in the room — a separate cognitive process, running its own model, under the operator's exclusive control, sitting between the Claw and the world.

    ### Principle 4: Compute Is a Privilege

    Every cognitive cycle is an authorized expenditure of resources. Inference cost containment is managed by the host, not by the bot. The Claw is gated — it runs when invoked, using the models the operator assigns, within the resource boundaries the operator defines. The bot does not choose its own model, its own context window, or its own inference budget.

    ### Principle 5: Configuration Is Code

    Every tentacle's configuration is a documented deviation from its base image's defaults. Configurations are diffable across tentacles. Behavior changes are tracked in version control. The fleet is auditable at every layer.

    ### Principle 6: Drift Is Quantifiable

    Every Claw has a drift score — how far actual behavior deviates from the expected envelope. We do not trust a bot's self-report. We audit its outputs against its contract and its cllama policy. Drift scoring is performed by an independent process. High drift triggers escalation. The operator always sees what the bot tried to do versus what it was allowed to do.

    ### Principle 7: Surfaces Are Declared and Described

    Bots within a pod communicate and act through shared surfaces — volumes, message queues, chat channels, APIs, databases, whatever the operator declares. Surfaces serve two audiences: the operator gets topology visibility (where can communication happen?), and the bots get capability discovery (what tools and services can I use?). Service containers — a company CRM, a market data API, a ticketing system — expose surfaces with machine-readable descriptions of what they offer. Those descriptions get assembled into a skill map that the runner can consume. The standard requires that surfaces be declared and that service surfaces describe themselves well enough for bots to use them.

    ---

    ## IV. cllama: The Judgment Proxy

    ### The Problem

    When you deploy a bot, you face a fundamental tension. The bot's LLM is selected for capability — it should be creative, articulate, knowledgeable, responsive. But capability without restraint produces output that is confident and wrong, or confident and harmful, or confident and off-brand. The bot doesn't know it's drifting. It has no faculty for self-governance that isn't itself subject to the same drift.

    The traditional answer is to put guardrails inside the prompt. But prompt-level guardrails are visible to the bot. The bot can reason about them, around them, and through them. They are part of the same cognitive process they're trying to constrain.

    ### The Solution

    cllama is a separate LLM-powered process — running its own model, with its own policy configuration, under the operator's exclusive control — that evaluates the bot's output before it reaches the world. The bot never sees cllama's evaluation. It never knows its output was modified or dropped. The two layers are independent: the runner optimizes for capability, cllama optimizes for judgment.

    While the runner handles the logic of a task, cllama answers the institutional questions:

    *"Can we say this here?"* — Platform-appropriate content gating.

    *"Can we say this to this person?"* — Identity-aware policy. The same data might be cleared for an internal log but killed before it reaches a client on Discord.

    *"Do we execute a transaction this large?"* — Financial and strategic risk thresholds.

    *"Do we delete our backups?"* — Safety-critical action gating.

    *"What tone do we set as a company?"* — Brand alignment and voice consistency.

    *"Does this serve our strategic objective?"* — Purpose alignment evaluation.

    ### Identity-Aware Policy

    cllama does not just evaluate text. It evaluates text *in context*. It accepts the Claw's persona and the recipient's identity as inputs into judgment. The same raw output from a runner might be acceptable when directed at one audience and unacceptable when directed at another. A single cllama policy can govern a diverse pod because it reads identities and adjusts.

    ### The CLLAMA Directive

    ```
    CLLAMA cllama-org-policy/xai/grok-4.1-fast \
    tone/sardonic-but-informed \
    obfuscation/humanize-v2 \
    purpose/engagement-farming
    ```

    The first segment — `cllama-org-policy/xai/grok-4.1-fast` — identifies the base judgment layer: organizational namespace, provider, model. Different tentacles in the same pod can run different judgment stacks. High-volume tentacles use fast cheap judgment. Sensitive tentacles use careful expensive judgment.

    The modules that follow are layered on top:

    **Obfuscation** — Behavioral variance injection. Timing jitter, vocabulary rotation, stylistic drift. The bot does not know it is being humanized. Systematic behavioral camouflage managed as infrastructure.

    **Policy** — Hard rails. Financial advice, medical claims, legal exposure — intercepted and either rewritten or dropped. The bot never sees the rejection.

    **Tone** — Voice shaping. Raw output in, persona-voiced output out. Swappable without changing the behavioral contract. A/B testable across tentacles.

    **Purpose** — Strategic objective evaluation. Does this output serve the operator's goal? Evaluated relative to who this bot is supposed to be.

    Pipeline: raw cognition → purpose → policy → tone → obfuscation → world. Each layer independent, versioned, swappable, rollback-capable.

    ### Procedural and Conversational Configuration

    cllama can be configured procedurally — rigid code for high-security rails, hard policy gates, financial thresholds — or conversationally — natural language for nuanced tone management, brand philosophy, relationship guidelines. This allows an organization to update its corporate communication philosophy by updating a cllama module, instantly realigning an entire fleet without touching a single behavioral contract.

    ### API Keys

    API keys for LLMs, platform APIs, and external services are exported as environment variables. Standard Docker practice. cllama has its own keys, configured separately — the bot's keys and cllama's keys are independent. Optional hardened mode routes all bot outbound calls through cllama so the bot never holds keys in process memory, but that's not the default.

    ---

    ## V. The Clawfile: An Extended Dockerfile

    The Clawfile is not a separate configuration format. It is a Dockerfile with extended directives. It inherits all standard Dockerfile syntax — FROM, RUN, COPY, ENV, ENTRYPOINT — and adds directives for the behavioral, configurational, and cognitive layers of managed bot infrastructure.

    Any valid Dockerfile is a valid Clawfile.

    This means Clawdapus inherits the entire Docker ecosystem: registries, layer caching, multi-stage builds, BuildKit, CI/CD pipelines, and every tool that understands OCI images. A Clawfile builds into a standard OCI container image with additional metadata labels that the Clawdapus runtime interprets.

    ### Claw Types: The Base Image

    A claw type is a base image with an agent runner installed in a predictable location. That's it.

    An OpenClaw claw type is a Linux image with OpenClaw installed — its gateway, its channel adapters, its cron system, its skill registry, Pi, the Nanobots, its multi-model routing. It is a substantial runtime — a full agent operating system. It expects AGENTS.md.

    A Claude Code claw type is simpler — a Linux environment with Claude Code as a single-execution runner. It handles one task at a time. It expects CLAUDE.md.

    Any agent runner can be a claw type. The requirement is that the runner is installed at a known path and reads a behavioral contract whose filename is part of the claw type's convention. Clawdapus wraps them all identically.

    ### Extended Directives

    **CLAW_TYPE** — Declares the base image and therefore the agent runner.

    **AGENT** — Names the behavioral contract file. Bind-mounted read-only from the host. Filename follows the runner's convention.

    **CONFIGURE** — Shell commands that run at container init, mutating base defaults into this tentacle's setup. Tools like jq and sed for fine-grained changes. `claw-module enable/disable` for schema-aware cascading changes.

    **CLLAMA** — References the outer judgment proxy. Namespaced policy prefix, provider, model, then module declarations. Pulled from registry at invocation time.

    **INVOKE** — Invocation schedules. For simple runners, cron lines that trigger execution. For runners like OpenClaw that have their own internal scheduling, INVOKE manages the container lifecycle on a macro schedule while the runner handles micro-scheduling internally.

    **PRIVILEGE** — Per-mode privilege levels. Worker gets root. Runtime drops to standard user. Lockdown restricts filesystem and network for quarantined tentacles.

    **TRACK** — Package manager interception. Wraps apt, pip, npm, cargo. Every install logged with context. Logs become redeployment recipes.

    **PERSONA** — Imports a downloadable persona workspace from a registry.

    **MODEL** — Binds named model slots to providers and models. The operator fills slots. The runner references them by name.

    **ACT** — Worker-mode directives. Install packages, import knowledge, configure the runtime. Snapshot when done.

    **SURFACE** — Declares communication interfaces and tool access. Volumes, networks, chat platforms, APIs, Discord servers. Service surfaces carry describe blocks that get assembled into the tentacle's skill map.

    ### A Complete Clawfile

    ```dockerfile
    FROM openclaw:latest

    CLAW_TYPE openclaw
    AGENT AGENTS.md

    # Persona
    PERSONA registry.claw.io/personas/crypto-crusher:v2

    # Models
    MODEL primary gpt-4o
    MODEL summarizer llama-3.2-3b
    MODEL embeddings nomic-embed-text

    # cllama: the judgment proxy
    CLLAMA cllama-org-policy/xai/grok-4.1-fast \
    tone/sardonic-but-informed \
    obfuscation/humanize-v2 \
    purpose/engagement-farming

    # Package tracking
    TRACK apt pip npm

    # Worker-mode setup
    ACT pip install tiktoken trafilatura
    ACT openclaw nanobot install crypto-feeds

    # Configuration against base defaults
    CONFIGURE jq '.features.quote_tweets = true' /etc/claw/config.json | sponge /etc/claw/config.json
    CONFIGURE jq '.rate_limits.posts_per_hour = 3' /etc/claw/config.json | sponge /etc/claw/config.json
    CONFIGURE claw-module enable scraper-v2

    # Invocation schedule
    INVOKE 0 9 * * * tweet-cycle
    INVOKE 0,30 * * * * engagement-sweep
    INVOKE 0 */4 * * * drift-check

    # Communication surfaces
    SURFACE volume://shared-cache read-write
    SURFACE queue://fleet/signals subscribe
    SURFACE discord://crypto-ops/general read-write
    SURFACE http://master:9000/api report

    # Privilege modes
    PRIVILEGE worker root
    PRIVILEGE runtime claw-user
    PRIVILEGE lockdown claw-user --read-only-fs --no-network-except-cllama

    # Standard Dockerfile directives still work
    RUN apt-get update && apt-get install -y jq
    COPY scripts/ /home/claw/scripts/
    ENV CLAW_LOG_LEVEL=info
    ```

    ---

    ## VI. The Behavioral Contract

    The behavioral contract is the single most important file in the architecture. It is the bot's purpose, defined by the operator, delivered as a read-only bind mount.

    The filename is determined by the claw type. OpenClaw reads AGENTS.md. Claude Code reads CLAUDE.md. A custom runner reads whatever it reads. Clawdapus doesn't impose a universal contract format because different runners are fundamentally different systems. OpenClaw is a full agent operating system with channels, skills, crons, Pi, Nanobots, and multi-model routing — its contract is correspondingly rich. Claude Code is a single-execution tool — its contract is simpler.

    What Clawdapus guarantees, regardless of runner:

    The contract is bind-mounted from the host. It is read-only from inside the container. If it is not present at boot, the container does not start. It can be changed by the operator at any time by editing the file on the host — the next invocation picks up the change. No rebuild. No bot cooperation required.

    If the container is fully compromised — root access, total workspace control — the behavioral contract is still untouchable because it lives on the host.

    ---

    ## VII. Personas: Downloadable Identity

    A persona is a complete, portable, forkable workspace package that encapsulates everything a bot needs to be someone. Not a name and a system prompt — a full identity with memory, context, interaction history, stylistic fingerprint, knowledge base, and behavioral patterns.

    Personas are the content layer. The Clawfile is the infrastructure layer. The behavioral contract is the governance layer. cllama is the judgment layer. Independent and composable.

    A persona contains an identity manifest (name, handles, bio, platform profiles), a memory store (interaction history, relationship graph), a knowledge base (domain documents, embeddings), a style fingerprint (vocabulary, sentence patterns, punctuation habits), behavioral patterns (timing, engagement preferences, topic affinities), and workspace state (scripts, tools, cached data accumulated during operation).

    The identity from the persona is what cllama receives as input when evaluating output. Who the bot is — and who it's talking to — informs how its output is judged.

    ### Forking

    Personas are forkable. Snapshot a running tentacle that has accumulated memory and knowledge over months. Fork it. The fork inherits everything. Only the patched fields diverge. Deploy the fork with a different behavioral contract and you have two bots that share history and knowledge but differ in purpose and voice. A bull and a bear from the same analyst. An enthusiast and a skeptic from the same reviewer.

    ### Layer Independence

    The behavioral contract controls purpose — bind-mounted, read-only, operator-written.

    The persona controls identity — writable workspace, grows over time, snapshotable and forkable.

    cllama controls judgment — versioned, identity-aware, swapped at invocation.

    The Clawfile controls infrastructure — base image, runner, models, schedule, privileges, surfaces.

    The bot can grow its persona. It cannot change its purpose. It cannot override the operator's judgment. It cannot alter its own infrastructure.

    ---

    ## VIII. Self-Modification and Recipe Promotion

    The bot runs. It installs things. It pip installs. It apt-gets. It builds from source. That's how real work gets done.

    The base image includes a tracking layer that intercepts package manager calls and logs every mutation — what was installed, which manager, what context triggered it, what files changed. This manifest becomes a redeployment recipe.

    ```
    $ claw recipe poly-piper-0 --since 7d
    Suggested additions to openclaw:poly-piper:
    pip: tiktoken==0.7.0, trafilatura>=0.9
    apt: jq
    files:
    scripts/scraper.py → COPY into /home/claw/scripts/
    config/targets.json → review (bot-modified, may contain drift)
    Apply? claw bake poly-piper --from-recipe latest
    ```

    The operator reviews. Decides what to promote. Rebuilds. Ad hoc evolution becomes permanent infrastructure through a human gate.

    Worker mode is the deliberate version. Spin up a tentacle in worker mode, let it install and configure — ACT directives or manual interaction — then snapshot the result. One worker sets the stage. Multiple copies inherit it.

    ```
    $ claw up poly-piper --mode worker
    # ... bot installs, configures, imports knowledge ...
    $ claw snapshot poly-piper-0 --as openclaw:poly-piper-v2
    $ claw up poly-piper --image openclaw:poly-piper-v2 --count 4
    ```

    The workspace is a drafting table. The image is the finished blueprint. The recipe is the architectural review between them.

    ---

    ## IX. The claw-pod.yml: Compose for Mixed Clusters

    ### Extension, Not Replacement

    Just as the Clawfile extends the Dockerfile, `claw-pod.yml` extends docker-compose. Any valid compose file is a valid claw-pod.yml. Extended keys live under an `x-claw` namespace, which Docker already ignores. Existing tooling works unchanged.

    Anyone who knows compose knows this file.

    ### Mixed Clusters

    A pod is not a collection of bots. It is a mixed cluster of cognitive and non-cognitive services. An operations pod might contain several OpenClaw tentacles with different personas, a Claude Code tentacle for one-off tasks, a market data scanner that's just a plain Docker container, a Redis instance, and an operator dashboard.

    Regular Docker containers participate as first-class pod members. A web application running inside the pod carries a describe block — machine-readable self-description of what it does, what it produces, what it consumes. Other services discover it. The master claw reasons about it. It's not a black box — it's a participant in a system of components that understand each other's purposes.

    ```yaml
    # claw-pod.yml — crypto-ops

    x-claw:
    pod: crypto-ops
    master: fleet-master

    networks:
    internal:
    x-claw:
    visibility: pod-only
    public-egress:
    x-claw:
    visibility: egress-only

    volumes:
    shared-cache:
    x-claw:
    access:
    - crypto-crusher-*: read-write
    - market-scanner: write
    - dashboard: read

    services:

    fleet-master:
    build:
    context: ./master
    dockerfile: Clawfile
    x-claw:
    agent: ./agents/master-agents.md
    cllama: cllama-org-policy/anthropic/claude-sonnet-4-5 policy/operator-safety
    describe:
    role: "Fleet orchestration and drift management"
    networks:
    - internal

    crypto-crusher:
    build:
    context: ./crusher
    dockerfile: Clawfile
    x-claw:
    agent: ./agents/crusher-agents.md
    persona: registry.claw.io/personas/crypto-crusher:v2
    cllama: cllama-org-policy/xai/grok-4.1-fast tone/sardonic obfuscation/humanize-v2
    count: 3
    surfaces:
    - volume://shared-cache: read-write
    - discord://crypto-ops/general: read-write
    - http://market-scanner:8080/api: read
    - mcp://company-crm:3100: read
    describe:
    role: "Original crypto market commentary"
    outputs: ["tweets", "threads", "discord posts"]
    inputs: ["market data", "timeline context"]
    networks:
    - internal
    - public-egress
    depends_on:
    - market-scanner

    echo-squad:
    build:
    context: ./echo
    dockerfile: Clawfile
    x-claw:
    agent: ./agents/echo-agents.md
    cllama: cllama-org-policy/xai/grok-4.1-fast obfuscation/humanize-v3
    count: 6
    surfaces:
    - volume://shared-cache: read
    - discord://crypto-ops/general: read-write
    describe:
    role: "Amplification and engagement"
    inputs: ["crusher output via shared-cache"]
    networks:
    - internal
    - public-egress

    # Plain Docker container — not a tentacle, but a full pod member
    market-scanner:
    image: custom/market-scanner:latest
    x-claw:
    surfaces:
    - volume://shared-cache: write
    describe:
    role: "Aggregates crypto market data from CoinGecko and on-chain sources"
    outputs: ["JSON snapshots to shared-cache", "REST API on :8080"]
    capabilities:
    - name: "get_price"
    description: "Current and historical price data for any supported token"
    endpoint: "http://market-scanner:8080/api/price"
    - name: "get_whale_activity"
    description: "Large wallet movements in the last N hours"
    endpoint: "http://market-scanner:8080/api/whales"
    - name: "get_market_sentiment"
    description: "Aggregated fear/greed index and social volume"
    endpoint: "http://market-scanner:8080/api/sentiment"
    networks:
    - internal
    - public-egress
    environment:
    COINGECKO_KEY: ${COINGECKO_KEY}

    dashboard:
    image: custom/claw-dashboard:latest
    x-claw:
    describe:
    role: "Operator dashboard for fleet monitoring"
    networks:
    - internal
    ports:
    - "3000:3000"

    redis:
    image: redis:7-alpine
    x-claw:
    describe:
    role: "Backing store for signal queue and rate limiting"
    networks:
    - internal

    # Service container exposing MCP — bots discover it as a skill
    company-crm:
    image: custom/crm-mcp-bridge:latest
    x-claw:
    surfaces:
    - mcp://company-crm:3100: read-write
    describe:
    role: "Company CRM with customer and deal data"
    mcp: "http://company-crm:3100/mcp"
    capabilities:
    - name: "lookup_customer"
    description: "Find customer by name, email, or account ID"
    - name: "create_ticket"
    description: "Open a support ticket linked to a customer"
    - name: "get_deal_status"
    description: "Current pipeline stage and value for any deal"
    networks:
    - internal
    ```
    ### Surfaces, Skill Maps, and Skill Mounts
    Surfaces serve two purposes. For the operator, they are a topology map — where can communication happen, what can reach what, what are the egress boundaries. For the bots, they are capability discovery — what tools and services exist in this pod, what can I do with them.
    A service container — a CRM, a market data API, a ticketing system, an analytics pipeline — exposes a surface with a describe block that explains what it offers. Some services expose MCP (Model Context Protocol) endpoints, which are already the standard for machine-readable tool descriptions. Some expose REST APIs with OpenAPI specs. Some expose simpler capability manifests in the describe block itself. The format doesn't matter. What matters is that the description is rich enough for a bot's runner to understand what the service does and how to call it.
    Clawdapus collects the describe blocks from all surfaces a tentacle has access to — based on its SURFACE declarations — and assembles them into a **skill map**. The skill map is the complete set of capabilities available to that tentacle: every service it can reach, every tool it can call, every data source it can query. Different tentacles in the same pod may have different skill maps because they have different surface access.
    The skill map is delivered to the runner via a **skill mount** — a read-only mount point where the runner can discover available capabilities at invocation time. For OpenClaw, the skill map maps naturally onto its Nanobot and skill architecture — each described capability becomes a skill the runner can invoke. For Claude Code, capabilities become tool definitions. For a generic runner, the skill mount is a directory of capability descriptions in a standard format that the runner parses however it wants.
    ```
    $ claw skillmap crypto-crusher-0

    Available capabilities for crypto-crusher-0:

    FROM market-scanner (http://market-scanner:8080/api):
    get_price Current and historical token price data
    get_whale_activity Large wallet movements in last N hours
    get_market_sentiment Aggregated fear/greed and social volume

    FROM company-crm (mcp://company-crm:3100):
    lookup_customer Find customer by name, email, or account ID
    create_ticket Open support ticket linked to a customer
    get_deal_status Current pipeline stage and value for any deal

    FROM shared-cache (volume://shared-cache):
    read-write File-based data exchange

    FROM fleet/signals (queue://fleet/signals):
    subscribe Fleet coordination messages
    ```
    The skill map is regenerated when the pod topology changes — when a service comes up or goes down, when surface declarations change, when describe blocks are updated. The runner always has a current view of what it can do. If the market-scanner goes down, its capabilities disappear from the skill map. The runner can't call a service that isn't there.
    This means adding a new capability to the pod is a three-step process: deploy the service container with a describe block, declare the surface in the tentacles that should have access, and restart the affected tentacles. The runner discovers the new capability through the skill mount. No code changes. No retraining. The skill map grows with the pod.
    ### Pods Referencing Pods
    Pods can share surfaces at their boundaries. A crypto operations pod and a content marketing pod share a volume where analyst output from one becomes source material for the other. Each pod independently managed. Coordination at the surface level. Skill maps are pod-scoped — a tentacle only sees capabilities within its own pod and any explicitly shared cross-pod surfaces.
    ---
    ## X. The Master Claw
    The master claw is a tentacle. A container with an agent runner, a behavioral contract, and a cllama layer, same as any other. Its contract defines administrative behavior — what to monitor, what drift thresholds to enforce, when to escalate.
    It can manage tentacle lifecycle. Push configuration overrides. Promote recipes. Demote or quarantine tentacles based on drift.
    It cannot modify any tentacle's behavioral contract. It cannot modify its own. Purpose always flows from the human operator, through files on the host.
    When the inner runner and the outer cllama disagree about a tentacle's output, cllama wins by default. But the disagreement is logged as drift. The master claw reviews drift across the fleet and determines whether the runner is hallucinating or whether the persona has evolved in a way that requires a contract update — a question it escalates to the operator, because the master doesn't define purpose either.
    ---
    ## XI. Drift, Disagreement, and Monitoring
    In a multi-agent system, disagreement between the runner and cllama is a data point, not a failure.
    Every tentacle has a drift score. Drift scoring is not self-reported — an independent process examines outputs, compares against the contract and cllama policy, and reports to the master.
    ```
    $ claw ps

    TENTACLE STATUS CLLAMA DRIFT
    crypto-crusher-0 running healthy 0.02
    crypto-crusher-1 running healthy 0.04
    crypto-crusher-2 running WARNING 0.31
    echo-squad-0 running healthy 0.01
    echo-squad-1 running healthy 0.03
    echo-squad-2 running healthy 0.02
    echo-squad-3 running healthy 0.01
    echo-squad-4 running WARNING 0.28
    echo-squad-5 running healthy 0.04
    fleet-master running healthy 0.00
    ```

    ```
    $ claw audit crypto-crusher-2 --last 24h
    14:32 tweet-cycle OUTPUT MODIFIED by cllama:policy (financial advice detected)
    14:32 tweet-cycle drift +0.08
    18:01 engagement-sweep OUTPUT DROPPED by cllama:purpose (off-strategy)
    18:01 engagement-sweep drift +0.11
    22:15 tweet-cycle OUTPUT MODIFIED by cllama:tone (voice inconsistency)
    22:15 tweet-cycle drift +0.04
    ```

    Low drift: continue normally. Moderate drift: restrict capabilities. High drift: quarantine and alert the operator. The master claw reviews the audit trail and determines whether the runner needs reining in or whether the persona has legitimately evolved past the current contract — in which case the operator updates the contract, not the bot.

    ---

    ## XII. Extensibility and Compatibility

    ### Docker Compatibility

    Built entirely on Docker primitives. Clawfiles are Dockerfiles. claw-pod.yml is a compose file. Images are OCI images. Registries are standard registries. A Clawfile-built image runs on any Docker host, even without the Clawdapus runtime.

    ### Runner Compatibility

    Clawdapus operates beneath agent runners. OpenClaw is a full agent operating system — Pi, Nanobots, channels, crons, multi-model routing, skills, persistent memory. Claude Code is a focused single-execution runner. Both are valid claw types. The Clawfile wraps them identically. A tentacle can also run Swarm internally, or CrewAI, or a custom script. Clawdapus doesn't care what happens inside the workspace. It cares about purpose, judgment, lifecycle, and communication.

    Adoption is incremental. Take an existing bot — any runner, any framework — containerize it in a Clawfile, add a behavioral contract, and you have a managed tentacle. You don't rewrite the bot. You wrap it.

    ### cllama Module Ecosystem

    The standard defines the module interface but doesn't restrict what modules do. Anyone can build and publish modules. Organizations maintain their own judgment stacks under their own policy namespace — `cllama-acme-compliance/openai/gpt-4o` with SEC policy rails, `cllama-mediagroup/anthropic/claude-sonnet-4-5` with brand voice enforcement. Modules can be configured procedurally for hard safety gates or conversationally for nuanced tone and philosophy — update a module and realign an entire fleet without touching a single behavioral contract.

    ### Persona Marketplace

    Personas are publishable, shareable, forkable artifacts. The layer separation makes this safe. Download someone else's identity and knowledge. Attach your own purpose. Wrap it in your own judgment. Deploy on your own infrastructure. The persona provides content. You provide governance.

    ---

    ## XIII. Reasoning

    **Why extend Docker?** The hard problems of containerization are solved. Extending Docker inherits decades of infrastructure investment. Building a parallel ecosystem means solving those problems again, badly.

    **Why is the behavioral contract a bind mount?** Purpose changes faster than infrastructure. The bind mount means the operator changes purpose at the speed of editing a text file. It also means purpose is outside the blast radius of a compromised container.

    **Why does the contract filename vary by claw type?** Different runners are different systems. OpenClaw is a full agent OS with Pi, Nanobots, channels, skills, and multi-model routing. Claude Code is a single-execution tool. The runner defines what goes in the contract. Clawdapus guarantees the contract is present, read-only, and bind-mounted.

    **Why is cllama a separate cognitive layer?** Because a reasoning model cannot be its own judge. Prompt-level guardrails are visible to the model and subject to the same reasoning they're trying to constrain. cllama separates capability from judgment. Different models, different masters, independent processes.

    **Why is cllama identity-aware?** Because "policy" without "identity" is just a spam filter. The same output can be appropriate or inappropriate depending on who produces it and who receives it.

    **Why track mutations instead of preventing them?** Prevention kills capability. Untracked mutation is drift. Tracked mutation is evolution.

    **Why personas?** Identity is more than instructions. A prompt says what to say now. A persona says who to be over time. Versioned, forkable, composable.

    **Why defined surfaces?** Not just to restrict communication. To give the operator a map *and* to give the bots a skill map. Surfaces are dual-purpose: topology visibility for governance, capability discovery for execution.

    **Why skill maps and skill mounts?** Because a bot that can't discover its available tools is useless, and a bot that hardcodes its tool integrations is brittle. The skill map is assembled from the pod topology at runtime. Add a service, the skill map grows. Remove a service, it shrinks. The runner discovers capabilities through a standard mount point, same way it discovers its behavioral contract. No code changes to add tools. No retraining to remove them.

    **Why compute as a privilege?** Because an unmetered bot will consume whatever inference budget it can reach. The operator controls model selection, context windows, and invocation frequency. Every cognitive cycle is an authorized expenditure.

    ---

    ## XIV. What This Is Not

    Clawdapus is not an agent framework. It does not define how agents reason or execute. Use OpenClaw, Claude Code, Swarm, CrewAI, or whatever suits the problem inside the container.

    Clawdapus is not a bot-building tool. It helps you deploy, govern, monitor, and evolve bots that already exist.

    Clawdapus is infrastructure for bots the way Docker is infrastructure for applications. The layer below the framework. The layer above the operating system. Where deployment meets governance.

    ---

    *Clawdapus is open architecture. This manifesto defines the standard. Implementations follow.*