Skip to content

OpenClaw Platform Contract

Lawbooks: BluCity-Docs/library/governance/upstream-lawbooks.md — do not paraphrase OpenClaw upstream here.

OpenClaw is the Bluefly execution-plane adapter. It exposes agents, routes requests, manages channels, manages plugins, schedules work, and dispatches jobs. It must remain infrastructure, not a replacement home for Bluefly governance, engineering standards, deployment logic, product policy, Gas Town, Gas City, or Blu CLI.

Separation of Concerns

OpenClaw Platform

Owns:

  • gateway
  • plugins
  • channels
  • auth
  • runtime
  • scheduling
  • session execution
  • request dispatch

The platform configuration must stay upstream-aligned and must not encode Bluefly business policy.

Bluefly Configuration

Owns:

  • Bluefly agents
  • prompts
  • routing
  • company policies
  • workflows
  • approved tool bindings

Bluefly configuration is the correct place for Git history about how Bluefly uses OpenClaw.

Runtime Secrets

Owns:

  • tokens
  • OAuth credentials
  • passwords
  • API keys
  • signing secrets
  • session credentials

Runtime secrets must never be committed. Committed files may contain only secret names, secret references, or documented required variables.

Canonical Placement

Within the Bluefly architecture:

  • OpenClaw Gateway belongs to the Oracle Runtime layer. It executes work and hosts channels, plugins, MCP integrations, schedulers, and automations.
  • OpenClaw Control UI belongs to the Operator Surfaces layer. It configures and observes the gateway, but it is not a source of truth.
  • OpenClaw configuration belongs to the Bluefly Configuration layer beside City, Packs, Formulas, Orders, deployment configuration, governance, and runtime contracts. This is Bluefly-owned IP and belongs in Git.

Configuration Model

Start with the official OpenClaw configuration layout:

openclaw/
  README.md
  openclaw.json
  secrets.example.json

Do not pre-split configuration into many files. Modularize only when editing the official layout becomes painful, and only through OpenClaw's documented include mechanism. The goal is convergence with OpenClaw, not a Bluefly-owned configuration architecture.

The OpenClaw Control UI may edit configuration, but Git remains the durable authority:

UI change
git diff
commit
tag
deploy

No daily configuration snapshots are required. Git is the history.

Convergence Rule

Every new OpenClaw integration must be classified before implementation:

  1. OpenClaw Core
  2. Official Plugin
  3. Community Plugin
  4. Configuration
  5. Bluefly Extension
  6. Bluefly Runtime
  7. Bluefly Custom Code

Bluefly custom code may exist only after all previous layers are proven insufficient. Before writing any plugin, ask whether OpenClaw core, an official plugin, a community plugin, or plain configuration already solves the problem. If yes, delete the custom plan and use the upstream path.

Plugin Classification

All plugins must be classified as one of:

  • Required
  • Optional
  • Experimental
  • Bluefly
  • Deprecated

Plugin inventory without classification is not enough. Classification prevents plugin sprawl and makes upgrade decisions explicit.

Runtime and Session Execution

OpenClaw acts as a runtime adapter to execute prompts and maintain interactive or execution sessions. OpenClaw is a transient execution environment and must not act as the durable source of project memory.

Scratch and Artifact Boundaries

All runtime scratch files, temporary logs, and audit outputs must go to:

~/.openclaw/workspace/blu/_audit

unless another path is explicitly approved in the active execution packet. OpenClaw must not create top-level files or directories in the BluTown root.

Orchestration Flow

OpenClaw must route durable work and task execution state through Gas Town Beads and Convoys. Durable files and outputs must be written to approved BluTown ledger paths instead of local workspace paths.