@gguf/pigbot 0.0.5 → 0.0.7

package/docs/gateway/multiple-gateways.md

@@ -1,5 +1,5 @@
 ---
-summary: "Run multiple Moltbot Gateways on one host (isolation, ports, and profiles)"
+summary: "Run multiple OpenClaw Gateways on one host (isolation, ports, and profiles)"
 read_when:
   - Running more than one Gateway on the same machine
   - You need isolated config/state/ports per Gateway
@@ -9,8 +9,8 @@ read_when:
 Most setups should use one Gateway because a single Gateway can handle multiple messaging connections and agents. If you need stronger isolation or redundancy (e.g., a rescue bot), run separate Gateways with isolated profiles/ports.
 
 ## Isolation checklist (required)
-- `CLAWDBOT_CONFIG_PATH` — per-instance config file
-- `CLAWDBOT_STATE_DIR` — per-instance sessions, creds, caches
+- `OPENCLAW_CONFIG_PATH` — per-instance config file
+- `OPENCLAW_STATE_DIR` — per-instance sessions, creds, caches
 - `agents.defaults.workspace` — per-instance workspace root
 - `gateway.port` (or `--port`) — unique per instance
 - Derived ports (browser/canvas) must not overlap
@@ -19,22 +19,22 @@ If these are shared, you will hit config races and port conflicts.
 
 ## Recommended: profiles (`--profile`)
 
-Profiles auto-scope `CLAWDBOT_STATE_DIR` + `CLAWDBOT_CONFIG_PATH` and suffix service names.
+Profiles auto-scope `OPENCLAW_STATE_DIR` + `OPENCLAW_CONFIG_PATH` and suffix service names.
 
 ```bash
 # main
-moltbot --profile main setup
-moltbot --profile main gateway --port 18789
+openclaw --profile main setup
+openclaw --profile main gateway --port 18789
 
 # rescue
-moltbot --profile rescue setup
-moltbot --profile rescue gateway --port 19001
+openclaw --profile rescue setup
+openclaw --profile rescue gateway --port 19001
 ```
 
 Per-profile services:
 ```bash
-moltbot --profile main gateway install
-moltbot --profile rescue gateway install
+openclaw --profile main gateway install
+openclaw --profile rescue gateway install
 ```
 
 ## Rescue-bot guide
@@ -54,11 +54,11 @@ Port spacing: leave at least 20 ports between base ports so the derived browser/
 ```bash
 # Main bot (existing or fresh, without --profile param)
 # Runs on port 18789 + Chrome CDC/Canvas/... Ports 
-moltbot onboard
-moltbot gateway install
+openclaw onboard
+openclaw gateway install
 
 # Rescue bot (isolated profile + ports)
-moltbot --profile rescue onboard
+openclaw --profile rescue onboard
 # Notes: 
 # - workspace name will be postfixed with -rescue per default
 # - Port should be at least 18789 + 20 Ports, 
@@ -66,12 +66,12 @@ moltbot --profile rescue onboard
 # - rest of the onboarding is the same as normal
 
 # To install the service (if not happened automatically during onboarding)
-moltbot --profile rescue gateway install
+openclaw --profile rescue gateway install
 ```
 
 ## Port mapping (derived)
 
-Base port = `gateway.port` (or `CLAWDBOT_GATEWAY_PORT` / `--port`).
+Base port = `gateway.port` (or `OPENCLAW_GATEWAY_PORT` / `--port`).
 
 - browser control service port = base + 2 (loopback only)
 - `canvasHost.port = base + 4`
@@ -89,19 +89,19 @@ If you override any of these in config or env, you must keep them unique per ins
 ## Manual env example
 
 ```bash
-CLAWDBOT_CONFIG_PATH=~/.clawdbot/main.json \
-CLAWDBOT_STATE_DIR=~/.clawdbot-main \
-moltbot gateway --port 18789
+OPENCLAW_CONFIG_PATH=~/.openclaw/main.json \
+OPENCLAW_STATE_DIR=~/.openclaw-main \
+openclaw gateway --port 18789
 
-CLAWDBOT_CONFIG_PATH=~/.clawdbot/rescue.json \
-CLAWDBOT_STATE_DIR=~/.clawdbot-rescue \
-moltbot gateway --port 19001
+OPENCLAW_CONFIG_PATH=~/.openclaw/rescue.json \
+OPENCLAW_STATE_DIR=~/.openclaw-rescue \
+openclaw gateway --port 19001
 ```
 
 ## Quick checks
 
 ```bash
-moltbot --profile main status
-moltbot --profile rescue status
-moltbot --profile rescue browser status
+openclaw --profile main status
+openclaw --profile rescue status
+openclaw --profile rescue browser status
 ```

package/docs/gateway/openai-http-api.md

@@ -5,14 +5,14 @@ read_when:
 ---
 # OpenAI Chat Completions (HTTP)
 
-Moltbot’s Gateway can serve a small OpenAI-compatible Chat Completions endpoint.
+OpenClaw’s Gateway can serve a small OpenAI-compatible Chat Completions endpoint.
 
 This endpoint is **disabled by default**. Enable it in config first.
 
 - `POST /v1/chat/completions`
 - Same port as the Gateway (WS + HTTP multiplex): `http://<gateway-host>:<port>/v1/chat/completions`
 
-Under the hood, requests are executed as a normal Gateway agent run (same codepath as `moltbot agent`), so routing/permissions/config match your Gateway.
+Under the hood, requests are executed as a normal Gateway agent run (same codepath as `openclaw agent`), so routing/permissions/config match your Gateway.
 
 ## Authentication
 
@@ -21,22 +21,22 @@ Uses the Gateway auth configuration. Send a bearer token:
 - `Authorization: Bearer <token>`
 
 Notes:
-- When `gateway.auth.mode="token"`, use `gateway.auth.token` (or `CLAWDBOT_GATEWAY_TOKEN`).
-- When `gateway.auth.mode="password"`, use `gateway.auth.password` (or `CLAWDBOT_GATEWAY_PASSWORD`).
+- When `gateway.auth.mode="token"`, use `gateway.auth.token` (or `OPENCLAW_GATEWAY_TOKEN`).
+- When `gateway.auth.mode="password"`, use `gateway.auth.password` (or `OPENCLAW_GATEWAY_PASSWORD`).
 
 ## Choosing an agent
 
 No custom headers required: encode the agent id in the OpenAI `model` field:
 
-- `model: "moltbot:<agentId>"` (example: `"moltbot:main"`, `"moltbot:beta"`)
+- `model: "openclaw:<agentId>"` (example: `"openclaw:main"`, `"openclaw:beta"`)
 - `model: "agent:<agentId>"` (alias)
 
-Or target a specific Moltbot agent by header:
+Or target a specific OpenClaw agent by header:
 
-- `x-moltbot-agent-id: <agentId>` (default: `main`)
+- `x-openclaw-agent-id: <agentId>` (default: `main`)
 
 Advanced:
-- `x-moltbot-session-key: <sessionKey>` to fully control session routing.
+- `x-openclaw-session-key: <sessionKey>` to fully control session routing.
 
 ## Enabling the endpoint
 
@@ -91,9 +91,9 @@ Non-streaming:
 curl -sS http://127.0.0.1:18789/v1/chat/completions \
   -H 'Authorization: Bearer YOUR_TOKEN' \
   -H 'Content-Type: application/json' \
-  -H 'x-moltbot-agent-id: main' \
+  -H 'x-openclaw-agent-id: main' \
   -d '{
-    "model": "moltbot",
+    "model": "openclaw",
     "messages": [{"role":"user","content":"hi"}]
   }'
 ```
@@ -103,9 +103,9 @@ Streaming:
 curl -N http://127.0.0.1:18789/v1/chat/completions \
   -H 'Authorization: Bearer YOUR_TOKEN' \
   -H 'Content-Type: application/json' \
-  -H 'x-moltbot-agent-id: main' \
+  -H 'x-openclaw-agent-id: main' \
   -d '{
-    "model": "moltbot",
+    "model": "openclaw",
     "stream": true,
     "messages": [{"role":"user","content":"hi"}]
   }'

package/docs/gateway/openresponses-http-api.md

@@ -6,7 +6,7 @@ read_when:
 ---
 # OpenResponses API (HTTP)
 
-Moltbot’s Gateway can serve an OpenResponses-compatible `POST /v1/responses` endpoint.
+OpenClaw’s Gateway can serve an OpenResponses-compatible `POST /v1/responses` endpoint.
 
 This endpoint is **disabled by default**. Enable it in config first.
 
@@ -14,7 +14,7 @@ This endpoint is **disabled by default**. Enable it in config first.
 - Same port as the Gateway (WS + HTTP multiplex): `http://<gateway-host>:<port>/v1/responses`
 
 Under the hood, requests are executed as a normal Gateway agent run (same codepath as
-`moltbot agent`), so routing/permissions/config match your Gateway.
+`openclaw agent`), so routing/permissions/config match your Gateway.
 
 ## Authentication
 
@@ -23,22 +23,22 @@ Uses the Gateway auth configuration. Send a bearer token:
 - `Authorization: Bearer <token>`
 
 Notes:
-- When `gateway.auth.mode="token"`, use `gateway.auth.token` (or `CLAWDBOT_GATEWAY_TOKEN`).
-- When `gateway.auth.mode="password"`, use `gateway.auth.password` (or `CLAWDBOT_GATEWAY_PASSWORD`).
+- When `gateway.auth.mode="token"`, use `gateway.auth.token` (or `OPENCLAW_GATEWAY_TOKEN`).
+- When `gateway.auth.mode="password"`, use `gateway.auth.password` (or `OPENCLAW_GATEWAY_PASSWORD`).
 
 ## Choosing an agent
 
 No custom headers required: encode the agent id in the OpenResponses `model` field:
 
-- `model: "moltbot:<agentId>"` (example: `"moltbot:main"`, `"moltbot:beta"`)
+- `model: "openclaw:<agentId>"` (example: `"openclaw:main"`, `"openclaw:beta"`)
 - `model: "agent:<agentId>"` (alias)
 
-Or target a specific Moltbot agent by header:
+Or target a specific OpenClaw agent by header:
 
-- `x-moltbot-agent-id: <agentId>` (default: `main`)
+- `x-openclaw-agent-id: <agentId>` (default: `main`)
 
 Advanced:
-- `x-moltbot-session-key: <sessionKey>` to fully control session routing.
+- `x-openclaw-session-key: <sessionKey>` to fully control session routing.
 
 ## Enabling the endpoint
 
@@ -277,9 +277,9 @@ Non-streaming:
 curl -sS http://127.0.0.1:18789/v1/responses \
   -H 'Authorization: Bearer YOUR_TOKEN' \
   -H 'Content-Type: application/json' \
-  -H 'x-moltbot-agent-id: main' \
+  -H 'x-openclaw-agent-id: main' \
   -d '{
-    "model": "moltbot",
+    "model": "openclaw",
     "input": "hi"
   }'
 ```
@@ -289,9 +289,9 @@ Streaming:
 curl -N http://127.0.0.1:18789/v1/responses \
   -H 'Authorization: Bearer YOUR_TOKEN' \
   -H 'Content-Type: application/json' \
-  -H 'x-moltbot-agent-id: main' \
+  -H 'x-openclaw-agent-id: main' \
   -d '{
-    "model": "moltbot",
+    "model": "openclaw",
     "stream": true,
     "input": "hi"
   }'

package/docs/gateway/pairing.md

@@ -35,11 +35,11 @@ Pending requests expire automatically after **5 minutes**.
 ## CLI workflow (headless friendly)
 
 ```bash
-moltbot nodes pending
-moltbot nodes approve <requestId>
-moltbot nodes reject <requestId>
-moltbot nodes status
-moltbot nodes rename --node <id|name|ip> --name "Living Room iPad"
+openclaw nodes pending
+openclaw nodes approve <requestId>
+openclaw nodes reject <requestId>
+openclaw nodes status
+openclaw nodes rename --node <id|name|ip> --name "Living Room iPad"
 ```
 
 `nodes status` shows paired/connected nodes and their capabilities.
@@ -74,12 +74,12 @@ If silent approval fails, it falls back to the normal “Approve/Reject” promp
 
 ## Storage (local, private)
 
-Pairing state is stored under the Gateway state directory (default `~/.clawdbot`):
+Pairing state is stored under the Gateway state directory (default `~/.openclaw`):
 
-- `~/.clawdbot/nodes/paired.json`
-- `~/.clawdbot/nodes/pending.json`
+- `~/.openclaw/nodes/paired.json`
+- `~/.openclaw/nodes/pending.json`
 
-If you override `CLAWDBOT_STATE_DIR`, the `nodes/` folder moves with it.
+If you override `OPENCLAW_STATE_DIR`, the `nodes/` folder moves with it.
 
 Security notes:
 - Tokens are secrets; treat `paired.json` as sensitive.

package/docs/gateway/protocol.md

@@ -9,7 +9,7 @@ read_when:
 # Gateway protocol (WebSocket)
 
 The Gateway WS protocol is the **single control plane + node transport** for
-Moltbot. All clients (CLI, web UI, macOS app, iOS/Android nodes, headless
+OpenClaw. All clients (CLI, web UI, macOS app, iOS/Android nodes, headless
 nodes) connect over WebSocket and declare their **role** + **scope** at
 handshake time.
 
@@ -53,7 +53,7 @@ Client → Gateway:
     "permissions": {},
     "auth": { "token": "…" },
     "locale": "en-US",
-    "userAgent": "moltbot-cli/1.2.3",
+    "userAgent": "openclaw-cli/1.2.3",
     "device": {
       "id": "device_fingerprint",
       "publicKey": "…",
@@ -111,7 +111,7 @@ When a device token is issued, `hello-ok` also includes:
     "permissions": { "camera.capture": true, "screen.record": false },
     "auth": { "token": "…" },
     "locale": "en-US",
-    "userAgent": "moltbot-ios/1.2.3",
+    "userAgent": "openclaw-ios/1.2.3",
     "device": {
       "id": "device_fingerprint",
       "publicKey": "…",
@@ -180,7 +180,7 @@ The Gateway treats these as **claims** and enforces server-side allowlists.
 
 ## Auth
 
-- If `CLAWDBOT_GATEWAY_TOKEN` (or `--token`) is set, `connect.params.auth.token`
+- If `OPENCLAW_GATEWAY_TOKEN` (or `--token`) is set, `connect.params.auth.token`
   must match or the socket is closed.
 - After pairing, the Gateway issues a **device token** scoped to the connection
   role + scopes. It is returned in `hello-ok.auth.deviceToken` and should be

package/docs/gateway/remote-gateway-readme.md

@@ -1,11 +1,11 @@
 ---
-summary: "SSH tunnel setup for Moltbot.app connecting to a remote gateway"
+summary: "SSH tunnel setup for OpenClaw.app connecting to a remote gateway"
 read_when: "Connecting the macOS app to a remote gateway over SSH"
 ---
 
-# Running Moltbot.app with a Remote Gateway
+# Running OpenClaw.app with a Remote Gateway
 
-Moltbot.app uses SSH tunneling to connect to a remote gateway. This guide shows you how to set it up.
+OpenClaw.app uses SSH tunneling to connect to a remote gateway. This guide shows you how to set it up.
 
 ## Overview
 
@@ -13,7 +13,7 @@ Moltbot.app uses SSH tunneling to connect to a remote gateway. This guide shows
 ┌─────────────────────────────────────────────────────────────┐
 │                        Client Machine                          │
 │                                                              │
-│  Moltbot.app ──► ws://127.0.0.1:18789 (local port)           │
+│  OpenClaw.app ──► ws://127.0.0.1:18789 (local port)           │
 │                     │                                        │
 │                     ▼                                        │
 │  SSH Tunnel ────────────────────────────────────────────────│
@@ -56,7 +56,7 @@ ssh-copy-id -i ~/.ssh/id_rsa <REMOTE_USER>@<REMOTE_IP>
 ### Step 3: Set Gateway Token
 
 ```bash
-launchctl setenv CLAWDBOT_GATEWAY_TOKEN "<your-token>"
+launchctl setenv OPENCLAW_GATEWAY_TOKEN "<your-token>"
 ```
 
 ### Step 4: Start SSH Tunnel
@@ -65,11 +65,11 @@ launchctl setenv CLAWDBOT_GATEWAY_TOKEN "<your-token>"
 ssh -N remote-gateway &
 ```
 
-### Step 5: Restart Moltbot.app
+### Step 5: Restart OpenClaw.app
 
 ```bash
-# Quit Moltbot.app (⌘Q), then reopen:
-open /path/to/Moltbot.app
+# Quit OpenClaw.app (⌘Q), then reopen:
+open /path/to/OpenClaw.app
 ```
 
 The app will now connect to the remote gateway through the SSH tunnel.
@@ -116,7 +116,7 @@ The tunnel will now:
 - Restart if it crashes
 - Keep running in the background
 
-Legacy note: remove any leftover `com.clawdbot.ssh-tunnel` LaunchAgent if present.
+Legacy note: remove any leftover `com.openclaw.ssh-tunnel` LaunchAgent if present.
 
 ---
 
@@ -152,4 +152,4 @@ launchctl bootout gui/$UID/bot.molt.ssh-tunnel
 | `KeepAlive` | Automatically restarts tunnel if it crashes |
 | `RunAtLoad` | Starts tunnel when the agent loads |
 
-Moltbot.app connects to `ws://127.0.0.1:18789` on your client machine. The SSH tunnel forwards that connection to port 18789 on the remote machine where the Gateway is running.
+OpenClaw.app connects to `ws://127.0.0.1:18789` on your client machine. The SSH tunnel forwards that connection to port 18789 on the remote machine where the Gateway is running.

package/docs/gateway/remote.md

@@ -34,7 +34,7 @@ This is ideal when your laptop sleeps often but you want the agent always-on.
 
 The laptop does **not** run the agent. It connects remotely:
 
-- Use the macOS app’s **Remote over SSH** mode (Settings → General → “Moltbot runs”).
+- Use the macOS app’s **Remote over SSH** mode (Settings → General → “OpenClaw runs”).
 - The app opens and manages the tunnel, so WebChat + health checks “just work.”
 
 Runbook: [macOS remote access](/platforms/mac/remote).
@@ -71,10 +71,10 @@ ssh -N -L 18789:127.0.0.1:18789 user@host
 ```
 
 With the tunnel up:
-- `moltbot health` and `moltbot status --deep` now reach the remote gateway via `ws://127.0.0.1:18789`.
-- `moltbot gateway {status,health,send,agent,call}` can also target the forwarded URL via `--url` when needed.
+- `openclaw health` and `openclaw status --deep` now reach the remote gateway via `ws://127.0.0.1:18789`.
+- `openclaw gateway {status,health,send,agent,call}` can also target the forwarded URL via `--url` when needed.
 
-Note: replace `18789` with your configured `gateway.port` (or `--port`/`CLAWDBOT_GATEWAY_PORT`).
+Note: replace `18789` with your configured `gateway.port` (or `--port`/`OPENCLAW_GATEWAY_PORT`).
 
 ## CLI remote defaults
 

package/docs/gateway/sandbox-vs-tool-policy-vs-elevated.md

@@ -7,7 +7,7 @@ status: active
 
 # Sandbox vs Tool Policy vs Elevated
 
-Moltbot has three related (but different) controls:
+OpenClaw has three related (but different) controls:
 
 1. **Sandbox** (`agents.defaults.sandbox.*` / `agents.list[].sandbox.*`) decides **where tools run** (Docker vs host).
 2. **Tool policy** (`tools.*`, `tools.sandbox.tools.*`, `agents.list[].tools.*`) decides **which tools are available/allowed**.
@@ -15,13 +15,13 @@ Moltbot has three related (but different) controls:
 
 ## Quick debug
 
-Use the inspector to see what Moltbot is *actually* doing:
+Use the inspector to see what OpenClaw is *actually* doing:
 
 ```bash
-moltbot sandbox explain
-moltbot sandbox explain --session agent:main:main
-moltbot sandbox explain --agent work
-moltbot sandbox explain --json
+openclaw sandbox explain
+openclaw sandbox explain --session agent:main:main
+openclaw sandbox explain --agent work
+openclaw sandbox explain --json
 ```
 
 It prints:
@@ -88,7 +88,7 @@ Available groups:
 - `group:automation`: `cron`, `gateway`
 - `group:messaging`: `message`
 - `group:nodes`: `nodes`
-- `group:moltbot`: all built-in Moltbot tools (excludes provider plugins)
+- `group:openclaw`: all built-in OpenClaw tools (excludes provider plugins)
 
 ## Elevated: exec-only “run on host”
 

package/docs/gateway/sandboxing.md

@@ -1,5 +1,5 @@
 ---
-summary: "How Moltbot sandboxing works: modes, scopes, workspace access, and images"
+summary: "How OpenClaw sandboxing works: modes, scopes, workspace access, and images"
 title: Sandboxing
 read_when: "You want a dedicated explanation of sandboxing or need to tune agents.defaults.sandbox."
 status: active
@@ -7,7 +7,7 @@ status: active
 
 # Sandboxing
 
-Moltbot can run **tools inside Docker containers** to reduce blast radius.
+OpenClaw can run **tools inside Docker containers** to reduce blast radius.
 This is **optional** and controlled by configuration (`agents.defaults.sandbox` or
 `agents.list[].sandbox`). If sandboxing is off, tools run on the host.
 The Gateway stays on the host; tool execution runs in an isolated sandbox
@@ -46,13 +46,13 @@ Group/channel sessions use their own keys, so they count as non-main and will be
 
 ## Workspace access
 `agents.defaults.sandbox.workspaceAccess` controls **what the sandbox can see**:
-- `"none"` (default): tools see a sandbox workspace under `~/.clawdbot/sandboxes`.
+- `"none"` (default): tools see a sandbox workspace under `~/.openclaw/sandboxes`.
 - `"ro"`: mounts the agent workspace read-only at `/agent` (disables `write`/`edit`/`apply_patch`).
 - `"rw"`: mounts the agent workspace read/write at `/workspace`.
 
 Inbound media is copied into the active sandbox workspace (`media/inbound/*`).
 Skills note: the `read` tool is sandbox-rooted. With `workspaceAccess: "none"`,
-Moltbot mirrors eligible skills into the sandbox workspace (`.../skills`) so
+OpenClaw mirrors eligible skills into the sandbox workspace (`.../skills`) so
 they can be read. With `"rw"`, workspace skills are readable from
 `/workspace/skills`.
 
@@ -98,7 +98,7 @@ Security notes:
 - See [Sandbox vs Tool Policy vs Elevated](/gateway/sandbox-vs-tool-policy-vs-elevated) for how binds interact with tool policy and elevated exec.
 
 ## Images + setup
-Default image: `moltbot-sandbox:bookworm-slim`
+Default image: `openclaw-sandbox:bookworm-slim`
 
 Build it once:
 ```bash
@@ -146,7 +146,7 @@ globally or per-agent, sandboxing doesn’t bring it back.
 `exec`, use tool policy deny (see [Sandbox vs Tool Policy vs Elevated](/gateway/sandbox-vs-tool-policy-vs-elevated)).
 
 Debugging:
-- Use `moltbot sandbox explain` to inspect effective sandbox mode, tool policy, and fix-it config keys.
+- Use `openclaw sandbox explain` to inspect effective sandbox mode, tool policy, and fix-it config keys.
 - See [Sandbox vs Tool Policy vs Elevated](/gateway/sandbox-vs-tool-policy-vs-elevated) for the “why is this blocked?” mental model.
 Keep it locked down.
 

package/docs/gateway/security/formal-verification.md

@@ -1,14 +1,16 @@
 ---
 title: Formal Verification (Security Models)
-summary: Machine-checked security models for Moltbot’s highest-risk paths.
-permalink: /gateway/security/formal-verification/
+summary: Machine-checked security models for OpenClaw’s highest-risk paths.
+permalink: /security/formal-verification/
 ---
 
 # Formal Verification (Security Models)
 
-This page tracks Moltbot’s **formal security models** (TLA+/TLC today; more as needed).
+This page tracks OpenClaw’s **formal security models** (TLA+/TLC today; more as needed).
 
-**Goal (north star):** provide a machine-checked argument that Moltbot enforces its
+> Note: some older links may refer to the previous project name.
+
+**Goal (north star):** provide a machine-checked argument that OpenClaw enforces its
 intended security policy (authorization, session isolation, tool gating, and
 misconfiguration safety), under explicit assumptions.
 
@@ -16,11 +18,11 @@ misconfiguration safety), under explicit assumptions.
 - Each claim has a runnable model-check over a finite state space.
 - Many claims have a paired **negative model** that produces a counterexample trace for a realistic bug class.
 
-**What this is not (yet):** a proof that “Moltbot is secure in all respects” or that the full TypeScript implementation is correct.
+**What this is not (yet):** a proof that “OpenClaw is secure in all respects” or that the full TypeScript implementation is correct.
 
 ## Where the models live
 
-Models are maintained in a separate repo: [vignesh07/moltbot-formal-models](https://github.com/vignesh07/moltbot-formal-models).
+Models are maintained in a separate repo: [vignesh07/openclaw-formal-models](https://github.com/vignesh07/openclaw-formal-models).
 
 ## Important caveats
 
@@ -37,8 +39,8 @@ Today, results are reproduced by cloning the models repo locally and running TLC
 Getting started:
 
 ```bash
-git clone https://github.com/vignesh07/moltbot-formal-models
-cd moltbot-formal-models
+git clone https://github.com/vignesh07/openclaw-formal-models
+cd openclaw-formal-models
 
 # Java 11+ required (TLC runs on the JVM).
 # The repo vendors a pinned `tla2tools.jar` (TLA+ tools) and provides `bin/tlc` + Make targets.
@@ -98,10 +100,61 @@ See also: `docs/gateway-exposure-matrix.md` in the models repo.
 - Red (expected):
   - `make routing-isolation-negative`
 
-## Roadmap
 
-Next models to deepen fidelity:
-- Pairing store concurrency/locking/idempotency
-- Provider-specific ingress preflight modeling
-- Routing identity-links + dmScope variants + binding precedence
-- Gateway auth conformance (proxy/tailscale specifics)
+## v1++: additional bounded models (concurrency, retries, trace correctness)
+
+These are follow-on models that tighten fidelity around real-world failure modes (non-atomic updates, retries, and message fan-out).
+
+### Pairing store concurrency / idempotency
+
+**Claim:** a pairing store should enforce `MaxPending` and idempotency even under interleavings (i.e., “check-then-write” must be atomic / locked; refresh shouldn’t create duplicates).
+
+What it means:
+- Under concurrent requests, you can’t exceed `MaxPending` for a channel.
+- Repeated requests/refreshes for the same `(channel, sender)` should not create duplicate live pending rows.
+
+- Green runs:
+  - `make pairing-race` (atomic/locked cap check)
+  - `make pairing-idempotency`
+  - `make pairing-refresh`
+  - `make pairing-refresh-race`
+- Red (expected):
+  - `make pairing-race-negative` (non-atomic begin/commit cap race)
+  - `make pairing-idempotency-negative`
+  - `make pairing-refresh-negative`
+  - `make pairing-refresh-race-negative`
+
+### Ingress trace correlation / idempotency
+
+**Claim:** ingestion should preserve trace correlation across fan-out and be idempotent under provider retries.
+
+What it means:
+- When one external event becomes multiple internal messages, every part keeps the same trace/event identity.
+- Retries do not result in double-processing.
+- If provider event IDs are missing, dedupe falls back to a safe key (e.g., trace ID) to avoid dropping distinct events.
+
+- Green:
+  - `make ingress-trace`
+  - `make ingress-trace2`
+  - `make ingress-idempotency`
+  - `make ingress-dedupe-fallback`
+- Red (expected):
+  - `make ingress-trace-negative`
+  - `make ingress-trace2-negative`
+  - `make ingress-idempotency-negative`
+  - `make ingress-dedupe-fallback-negative`
+
+### Routing dmScope precedence + identityLinks
+
+**Claim:** routing must keep DM sessions isolated by default, and only collapse sessions when explicitly configured (channel precedence + identity links).
+
+What it means:
+- Channel-specific dmScope overrides must win over global defaults.
+- identityLinks should collapse only within explicit linked groups, not across unrelated peers.
+
+- Green:
+  - `make routing-precedence`
+  - `make routing-identitylinks`
+- Red (expected):
+  - `make routing-precedence-negative`
+  - `make routing-identitylinks-negative`