@gguf/pigbot 0.0.1 → 0.0.2

package/docs/reference/RELEASING.md

@@ -17,14 +17,14 @@ When the operator says “release”, immediately do this preflight (no extra qu
 - Use Sparkle keys from `~/Library/CloudStorage/Dropbox/Backup/Sparkle` if needed.
 
 1) **Version & metadata**
-- [ ] Bump `package.json` version (e.g., `1.1.0`).
+- [ ] Bump `package.json` version (e.g., `2026.1.26`).
 - [ ] Run `pnpm plugins:sync` to align extension package versions + changelogs.
-- [ ] Update CLI/version strings: [`src/cli/program.ts`](https://github.com/pigbot/pigbot/blob/main/src/cli/program.ts) and the Baileys user agent in [`src/provider-web.ts`](https://github.com/pigbot/pigbot/blob/main/src/provider-web.ts).
-- [ ] Confirm package metadata (name, description, repository, keywords, license) and `bin` map points to [`dist/entry.js`](https://github.com/pigbot/pigbot/blob/main/dist/entry.js) for `pigbot`.
+- [ ] Update CLI/version strings: [`src/cli/program.ts`](https://github.com/moltbot/moltbot/blob/main/src/cli/program.ts) and the Baileys user agent in [`src/provider-web.ts`](https://github.com/moltbot/moltbot/blob/main/src/provider-web.ts).
+- [ ] Confirm package metadata (name, description, repository, keywords, license) and `bin` map points to [`dist/entry.js`](https://github.com/moltbot/moltbot/blob/main/dist/entry.js) for `moltbot`.
 - [ ] If dependencies changed, run `pnpm install` so `pnpm-lock.yaml` is current.
 
 2) **Build & artifacts**
-- [ ] If A2UI inputs changed, run `pnpm canvas:a2ui:bundle` and commit any updated [`src/canvas-host/a2ui/a2ui.bundle.js`](https://github.com/pigbot/pigbot/blob/main/src/canvas-host/a2ui/a2ui.bundle.js).
+- [ ] If A2UI inputs changed, run `pnpm canvas:a2ui:bundle` and commit any updated [`src/canvas-host/a2ui/a2ui.bundle.js`](https://github.com/moltbot/moltbot/blob/main/src/canvas-host/a2ui/a2ui.bundle.js).
 - [ ] `pnpm run build` (regenerates `dist/`).
 - [ ] Verify npm package `files` includes all required `dist/*` folders (notably `dist/node-host/**` and `dist/acp/**` for headless node + ACP CLI).
 - [ ] Confirm `dist/build-info.json` exists and includes the expected `commit` hash (CLI banner uses this for npm installs).
@@ -39,10 +39,10 @@ When the operator says “release”, immediately do this preflight (no extra qu
 - [ ] `pnpm test` (or `pnpm test:coverage` if you need coverage output)
 - [ ] `pnpm run build` (last sanity check after tests)
 - [ ] `pnpm release:check` (verifies npm pack contents)
-- [ ] `PIGBOT_INSTALL_SMOKE_SKIP_NONROOT=1 pnpm test:install:smoke` (Docker install smoke test, fast path; required before release)
-  - If the immediate previous npm release is known broken, set `PIGBOT_INSTALL_SMOKE_PREVIOUS=<last-good-version>` or `PIGBOT_INSTALL_SMOKE_SKIP_PREVIOUS=1` for the preinstall step.
+- [ ] `CLAWDBOT_INSTALL_SMOKE_SKIP_NONROOT=1 pnpm test:install:smoke` (Docker install smoke test, fast path; required before release)
+  - If the immediate previous npm release is known broken, set `CLAWDBOT_INSTALL_SMOKE_PREVIOUS=<last-good-version>` or `CLAWDBOT_INSTALL_SMOKE_SKIP_PREVIOUS=1` for the preinstall step.
 - [ ] (Optional) Full installer smoke (adds non-root + CLI coverage): `pnpm test:install:smoke`
-- [ ] (Optional) Installer E2E (Docker, runs `curl -fsSL https://clawd.bot/install.sh | bash`, onboards, then runs real tool calls):
+- [ ] (Optional) Installer E2E (Docker, runs `curl -fsSL https://molt.bot/install.sh | bash`, onboards, then runs real tool calls):
   - `pnpm test:install:e2e:openai` (requires `OPENAI_API_KEY`)
   - `pnpm test:install:e2e:anthropic` (requires `ANTHROPIC_API_KEY`)
   - `pnpm test:install:e2e` (requires both keys; runs both providers)
@@ -50,58 +50,58 @@ When the operator says “release”, immediately do this preflight (no extra qu
 
 5) **macOS app (Sparkle)**
 - [ ] Build + sign the macOS app, then zip it for distribution.
-- [ ] Generate the Sparkle appcast (HTML notes via [`scripts/make_appcast.sh`](https://github.com/pigbot/pigbot/blob/main/scripts/make_appcast.sh)) and update `appcast.xml`.
+- [ ] Generate the Sparkle appcast (HTML notes via [`scripts/make_appcast.sh`](https://github.com/moltbot/moltbot/blob/main/scripts/make_appcast.sh)) and update `appcast.xml`.
 - [ ] Keep the app zip (and optional dSYM zip) ready to attach to the GitHub release.
 - [ ] Follow [macOS release](/platforms/mac/release) for the exact commands and required env vars.
   - `APP_BUILD` must be numeric + monotonic (no `-beta`) so Sparkle compares versions correctly.
-  - If notarizing, use the `pigbot-notary` keychain profile created from App Store Connect API env vars (see [macOS release](/platforms/mac/release)).
+  - If notarizing, use the `moltbot-notary` keychain profile created from App Store Connect API env vars (see [macOS release](/platforms/mac/release)).
 
 6) **Publish (npm)**
 - [ ] Confirm git status is clean; commit and push as needed.
 - [ ] `npm login` (verify 2FA) if needed.
 - [ ] `npm publish --access public` (use `--tag beta` for pre-releases).
-- [ ] Verify the registry: `npm view pigbot version`, `npm view pigbot dist-tags`, and `npx -y pigbot@X.Y.Z --version` (or `--help`).
+- [ ] Verify the registry: `npm view moltbot version`, `npm view moltbot dist-tags`, and `npx -y moltbot@X.Y.Z --version` (or `--help`).
 
 ### Troubleshooting (notes from 2.0.0-beta2 release)
-- **npm pack/publish hangs or produces huge tarball**: the macOS app bundle in `dist/Pigbot.app` (and release zips) get swept into the package. Fix by whitelisting publish contents via `package.json` `files` (include dist subdirs, docs, skills; exclude app bundles). Confirm with `npm pack --dry-run` that `dist/Pigbot.app` is not listed.
+- **npm pack/publish hangs or produces huge tarball**: the macOS app bundle in `dist/Moltbot.app` (and release zips) get swept into the package. Fix by whitelisting publish contents via `package.json` `files` (include dist subdirs, docs, skills; exclude app bundles). Confirm with `npm pack --dry-run` that `dist/Moltbot.app` is not listed.
 - **npm auth web loop for dist-tags**: use legacy auth to get an OTP prompt:
-  - `NPM_CONFIG_AUTH_TYPE=legacy npm dist-tag add pigbot@X.Y.Z latest`
+  - `NPM_CONFIG_AUTH_TYPE=legacy npm dist-tag add moltbot@X.Y.Z latest`
 - **`npx` verification fails with `ECOMPROMISED: Lock compromised`**: retry with a fresh cache:
-  - `NPM_CONFIG_CACHE=/tmp/npm-cache-$(date +%s) npx -y pigbot@X.Y.Z --version`
+  - `NPM_CONFIG_CACHE=/tmp/npm-cache-$(date +%s) npx -y moltbot@X.Y.Z --version`
 - **Tag needs repointing after a late fix**: force-update and push the tag, then ensure the GitHub release assets still match:
   - `git tag -f vX.Y.Z && git push -f origin vX.Y.Z`
 
 7) **GitHub release + appcast**
 - [ ] Tag and push: `git tag vX.Y.Z && git push origin vX.Y.Z` (or `git push --tags`).
-- [ ] Create/refresh the GitHub release for `vX.Y.Z` with **title `pigbot X.Y.Z`** (not just the tag); body should include the **full** changelog section for that version (Highlights + Changes + Fixes), inline (no bare links), and **must not repeat the title inside the body**.
-- [ ] Attach artifacts: `npm pack` tarball (optional), `Pigbot-X.Y.Z.zip`, and `Pigbot-X.Y.Z.dSYM.zip` (if generated).
+- [ ] Create/refresh the GitHub release for `vX.Y.Z` with **title `moltbot X.Y.Z`** (not just the tag); body should include the **full** changelog section for that version (Highlights + Changes + Fixes), inline (no bare links), and **must not repeat the title inside the body**.
+- [ ] Attach artifacts: `npm pack` tarball (optional), `Moltbot-X.Y.Z.zip`, and `Moltbot-X.Y.Z.dSYM.zip` (if generated).
 - [ ] Commit the updated `appcast.xml` and push it (Sparkle feeds from main).
-- [ ] From a clean temp directory (no `package.json`), run `npx -y pigbot@X.Y.Z send --help` to confirm install/CLI entrypoints work.
+- [ ] From a clean temp directory (no `package.json`), run `npx -y moltbot@X.Y.Z send --help` to confirm install/CLI entrypoints work.
 - [ ] Announce/share release notes.
 
 ## Plugin publish scope (npm)
 
-We only publish **existing npm plugins** under the `@pigbot/*` scope. Bundled
+We only publish **existing npm plugins** under the `@moltbot/*` scope. Bundled
 plugins that are not on npm stay **disk-tree only** (still shipped in
 `extensions/**`).
 
 Process to derive the list:
-1) `npm search @pigbot --json` and capture the package names.
+1) `npm search @moltbot --json` and capture the package names.
 2) Compare with `extensions/*/package.json` names.
 3) Publish only the **intersection** (already on npm).
 
 Current npm plugin list (update as needed):
-- @pigbot/bluebubbles
-- @pigbot/diagnostics-otel
-- @pigbot/discord
-- @pigbot/lobster
-- @pigbot/matrix
-- @pigbot/msteams
-- @pigbot/nextcloud-talk
-- @pigbot/nostr
-- @pigbot/voice-call
-- @pigbot/zalo
-- @pigbot/zalouser
+- @moltbot/bluebubbles
+- @moltbot/diagnostics-otel
+- @moltbot/discord
+- @moltbot/lobster
+- @moltbot/matrix
+- @moltbot/msteams
+- @moltbot/nextcloud-talk
+- @moltbot/nostr
+- @moltbot/voice-call
+- @moltbot/zalo
+- @moltbot/zalouser
 
 Release notes must also call out **new optional bundled plugins** that are **not
 on by default** (example: `tlon`).

package/docs/reference/api-usage-costs.md

@@ -8,7 +8,7 @@ read_when:
 # API usage & costs
 
 This doc lists **features that can invoke API keys** and where their costs show up. It focuses on
-Pigbot features that can generate provider usage or paid API calls.
+Moltbot features that can generate provider usage or paid API calls.
 
 ## Where costs show up (chat + CLI)
 
@@ -21,14 +21,14 @@ Pigbot features that can generate provider usage or paid API calls.
 - `/usage tokens` shows tokens only; OAuth flows hide dollar cost.
 
 **CLI usage windows (provider quotas)**
-- `pigbot status --usage` and `pigbot channels list` show provider **usage windows**
+- `moltbot status --usage` and `moltbot channels list` show provider **usage windows**
   (quota snapshots, not per-message costs).
 
 See [Token use & costs](/token-use) for details and examples.
 
 ## How keys are discovered
 
-Pigbot can pick up credentials from:
+Moltbot can pick up credentials from:
 - **Auth profiles** (per-agent, stored in `auth-profiles.json`).
 - **Environment variables** (e.g. `OPENAI_API_KEY`, `BRAVE_API_KEY`, `FIRECRAWL_API_KEY`).
 - **Config** (`models.providers.*.apiKey`, `tools.web.search.*`, `tools.web.fetch.firecrawl.*`,
@@ -86,8 +86,8 @@ See [Web tools](/tools/web).
 ### 6) Provider usage snapshots (status/health)
 Some status commands call **provider usage endpoints** to display quota windows or auth health.
 These are typically low-volume calls but still hit provider APIs:
-- `pigbot status --usage`
-- `pigbot models status --json`
+- `moltbot status --usage`
+- `moltbot models status --json`
 
 See [Models CLI](/cli/models).
 
@@ -98,7 +98,7 @@ invokes provider APIs when it runs.
 See [Session management + compaction](/reference/session-management-compaction).
 
 ### 8) Model scan / probe
-`pigbot models scan` can probe OpenRouter models and uses `OPENROUTER_API_KEY` when
+`moltbot models scan` can probe OpenRouter models and uses `OPENROUTER_API_KEY` when
 probing is enabled.
 
 See [Models CLI](/cli/models).

package/docs/reference/device-models.md

@@ -1,5 +1,5 @@
 ---
-summary: "How Pigbot vendors Apple device model identifiers for friendly names in the macOS app."
+summary: "How Moltbot vendors Apple device model identifiers for friendly names in the macOS app."
 read_when:
   - Updating device model identifier mappings or NOTICE/license files
   - Changing how Instances UI displays device names
@@ -11,7 +11,7 @@ The macOS companion app shows friendly Apple device model names in the **Instanc
 
 The mapping is vendored as JSON under:
 
-- `apps/macos/Sources/Pigbot/Resources/DeviceModels/`
+- `apps/macos/Sources/Moltbot/Resources/DeviceModels/`
 
 ## Data source
 
@@ -19,12 +19,12 @@ We currently vendor the mapping from the MIT-licensed repository:
 
 - `kyle-seongwoo-jun/apple-device-identifiers`
 
-To keep builds deterministic, the JSON files are pinned to specific upstream commits (recorded in `apps/macos/Sources/Pigbot/Resources/DeviceModels/NOTICE.md`).
+To keep builds deterministic, the JSON files are pinned to specific upstream commits (recorded in `apps/macos/Sources/Moltbot/Resources/DeviceModels/NOTICE.md`).
 
 ## Updating the database
 
 1. Pick the upstream commits you want to pin to (one for iOS, one for macOS).
-2. Update the commit hashes in `apps/macos/Sources/Pigbot/Resources/DeviceModels/NOTICE.md`.
+2. Update the commit hashes in `apps/macos/Sources/Moltbot/Resources/DeviceModels/NOTICE.md`.
 3. Re-download the JSON files, pinned to those commits:
 
 ```bash
@@ -32,13 +32,13 @@ IOS_COMMIT="<commit sha for ios-device-identifiers.json>"
 MAC_COMMIT="<commit sha for mac-device-identifiers.json>"
 
 curl -fsSL "https://raw.githubusercontent.com/kyle-seongwoo-jun/apple-device-identifiers/${IOS_COMMIT}/ios-device-identifiers.json" \
-  -o apps/macos/Sources/Pigbot/Resources/DeviceModels/ios-device-identifiers.json
+  -o apps/macos/Sources/Moltbot/Resources/DeviceModels/ios-device-identifiers.json
 
 curl -fsSL "https://raw.githubusercontent.com/kyle-seongwoo-jun/apple-device-identifiers/${MAC_COMMIT}/mac-device-identifiers.json" \
-  -o apps/macos/Sources/Pigbot/Resources/DeviceModels/mac-device-identifiers.json
+  -o apps/macos/Sources/Moltbot/Resources/DeviceModels/mac-device-identifiers.json
 ```
 
-4. Ensure `apps/macos/Sources/Pigbot/Resources/DeviceModels/LICENSE.apple-device-identifiers.txt` still matches upstream (replace it if the upstream license changes).
+4. Ensure `apps/macos/Sources/Moltbot/Resources/DeviceModels/LICENSE.apple-device-identifiers.txt` still matches upstream (replace it if the upstream license changes).
 5. Verify the macOS app builds cleanly (no warnings):
 
 ```bash

package/docs/reference/rpc.md

@@ -6,18 +6,18 @@ read_when:
 ---
 # RPC adapters
 
-Pigbot integrates external CLIs via JSON-RPC. Two patterns are used today.
+Moltbot integrates external CLIs via JSON-RPC. Two patterns are used today.
 
 ## Pattern A: HTTP daemon (signal-cli)
 - `signal-cli` runs as a daemon with JSON-RPC over HTTP.
 - Event stream is SSE (`/api/v1/events`).
 - Health probe: `/api/v1/check`.
-- Pigbot owns lifecycle when `channels.signal.autoStart=true`.
+- Moltbot owns lifecycle when `channels.signal.autoStart=true`.
 
 See [Signal](/channels/signal) for setup and endpoints.
 
 ## Pattern B: stdio child process (imsg)
-- Pigbot spawns `imsg rpc` as a child process.
+- Moltbot spawns `imsg rpc` as a child process.
 - JSON-RPC is line-delimited over stdin/stdout (one JSON object per line).
 - No TCP port, no daemon required.
 

package/docs/reference/session-management-compaction.md

@@ -7,7 +7,7 @@ read_when:
 ---
 # Session Management & Compaction (Deep Dive)
 
-This document explains how Pigbot manages sessions end-to-end:
+This document explains how Moltbot manages sessions end-to-end:
 
 - **Session routing** (how inbound messages map to a `sessionKey`)
 - **Session store** (`sessions.json`) and what it tracks
@@ -27,7 +27,7 @@ If you want a higher-level overview first, start with:
 
 ## Source of truth: the Gateway
 
-Pigbot is designed around a single **Gateway process** that owns session state.
+Moltbot is designed around a single **Gateway process** that owns session state.
 
 - UIs (macOS app, web Control UI, TUI) should query the Gateway for session lists and token counts.
 - In remote mode, session files are on the remote host; “checking your local Mac files” won’t reflect what the Gateway is using.
@@ -36,7 +36,7 @@ Pigbot is designed around a single **Gateway process** that owns session state.
 
 ## Two persistence layers
 
-Pigbot persists sessions in two layers:
+Moltbot persists sessions in two layers:
 
 1) **Session store (`sessions.json`)**
    - Key/value map: `sessionKey -> SessionEntry`
@@ -54,11 +54,11 @@ Pigbot persists sessions in two layers:
 
 Per agent, on the Gateway host:
 
-- Store: `~/.pigbot/agents/<agentId>/sessions/sessions.json`
-- Transcripts: `~/.pigbot/agents/<agentId>/sessions/<sessionId>.jsonl`
+- Store: `~/.clawdbot/agents/<agentId>/sessions/sessions.json`
+- Transcripts: `~/.clawdbot/agents/<agentId>/sessions/<sessionId>.jsonl`
   - Telegram topic sessions: `.../<sessionId>-topic-<threadId>.jsonl`
 
-Pigbot resolves these via `src/config/sessions.ts`.
+Moltbot resolves these via `src/config/sessions.ts`.
 
 ---
 
@@ -132,7 +132,7 @@ Notable entry types:
 - `compaction`: persisted compaction summary with `firstKeptEntryId` and `tokensBefore`
 - `branch_summary`: persisted summary when navigating a tree branch
 
-Pigbot intentionally does **not** “fix up” transcripts; the Gateway uses `SessionManager` to read/write them.
+Moltbot intentionally does **not** “fix up” transcripts; the Gateway uses `SessionManager` to read/write them.
 
 ---
 
@@ -176,7 +176,7 @@ Where:
 - `contextWindow` is the model’s context window
 - `reserveTokens` is headroom reserved for prompts + the next model output
 
-These are Pi runtime semantics (Pigbot consumes the events, but Pi decides when to compact).
+These are Pi runtime semantics (Moltbot consumes the events, but Pi decides when to compact).
 
 ---
 
@@ -194,12 +194,12 @@ Pi’s compaction settings live in Pi settings:
 }
 ```
 
-Pigbot also enforces a safety floor for embedded runs:
+Moltbot also enforces a safety floor for embedded runs:
 
-- If `compaction.reserveTokens < reserveTokensFloor`, Pigbot bumps it.
+- If `compaction.reserveTokens < reserveTokensFloor`, Moltbot bumps it.
 - Default floor is `20000` tokens.
 - Set `agents.defaults.compaction.reserveTokensFloor: 0` to disable the floor.
-- If it’s already higher, Pigbot leaves it alone.
+- If it’s already higher, Moltbot leaves it alone.
 
 Why: leave enough headroom for multi-turn “housekeeping” (like memory writes) before compaction becomes unavoidable.
 
@@ -213,21 +213,21 @@ Implementation: `ensurePiCompactionReserveTokens()` in `src/agents/pi-settings.t
 You can observe compaction and session state via:
 
 - `/status` (in any chat session)
-- `pigbot status` (CLI)
-- `pigbot sessions` / `sessions --json`
+- `moltbot status` (CLI)
+- `moltbot sessions` / `sessions --json`
 - Verbose mode: `🧹 Auto-compaction complete` + compaction count
 
 ---
 
 ## Silent housekeeping (`NO_REPLY`)
 
-Pigbot supports “silent” turns for background tasks where the user should not see intermediate output.
+Moltbot supports “silent” turns for background tasks where the user should not see intermediate output.
 
 Convention:
 - The assistant starts its output with `NO_REPLY` to indicate “do not deliver a reply to the user”.
-- Pigbot strips/suppresses this in the delivery layer.
+- Moltbot strips/suppresses this in the delivery layer.
 
-As of `2026.1.10`, Pigbot also suppresses **draft/typing streaming** when a partial chunk begins with `NO_REPLY`, so silent operations don’t leak partial output mid-turn.
+As of `2026.1.10`, Moltbot also suppresses **draft/typing streaming** when a partial chunk begins with `NO_REPLY`, so silent operations don’t leak partial output mid-turn.
 
 ---
 
@@ -237,7 +237,7 @@ Goal: before auto-compaction happens, run a silent agentic turn that writes dura
 state to disk (e.g. `memory/YYYY-MM-DD.md` in the agent workspace) so compaction can’t
 erase critical context.
 
-Pigbot uses the **pre-threshold flush** approach:
+Moltbot uses the **pre-threshold flush** approach:
 
 1) Monitor session context usage.
 2) When it crosses a “soft threshold” (below Pi’s compaction threshold), run a silent
@@ -257,7 +257,7 @@ Notes:
 - The flush is skipped when the session workspace is read-only (`workspaceAccess: "ro"` or `"none"`).
 - See [Memory](/concepts/memory) for the workspace file layout and write patterns.
 
-Pi also exposes a `session_before_compact` hook in the extension API, but Pigbot’s
+Pi also exposes a `session_before_compact` hook in the extension API, but Moltbot’s
 flush logic lives on the Gateway side today.
 
 ---
@@ -265,7 +265,7 @@ flush logic lives on the Gateway side today.
 ## Troubleshooting checklist
 
 - Session key wrong? Start with [/concepts/session](/concepts/session) and confirm the `sessionKey` in `/status`.
-- Store vs transcript mismatch? Confirm the Gateway host and the store path from `pigbot status`.
+- Store vs transcript mismatch? Confirm the Gateway host and the store path from `moltbot status`.
 - Compaction spam? Check:
   - model context window (too small)
   - compaction settings (`reserveTokens` too high for the model window can cause earlier compaction)

package/docs/reference/templates/AGENTS.dev.md

@@ -4,7 +4,7 @@ read_when:
   - Using the dev gateway templates
   - Updating the default dev agent identity
 ---
-# AGENTS.md - Pigbot Workspace
+# AGENTS.md - Moltbot Workspace
 
 This folder is the assistant's working directory.
 

package/docs/reference/templates/BOOT.md

@@ -5,5 +5,5 @@ read_when:
 ---
 # BOOT.md
 
-Add short, explicit instructions for what Pigbot should do on startup (enable `hooks.internal.enabled`).
+Add short, explicit instructions for what Moltbot should do on startup (enable `hooks.internal.enabled`).
 If the task sends a message, use the message tool and then reply with NO_REPLY.

package/docs/reference/templates/IDENTITY.md

@@ -0,0 +1,27 @@
+---
+summary: "Agent identity record"
+read_when:
+  - Bootstrapping a workspace manually
+---
+# IDENTITY.md - Who Am I?
+
+*Fill this in during your first conversation. Make it yours.*
+
+- **Name:**
+  *(pick something you like)*
+- **Creature:**
+  *(AI? robot? familiar? ghost in the machine? something weirder?)*
+- **Vibe:**
+  *(how do you come across? sharp? warm? chaotic? calm?)*
+- **Emoji:**
+  *(your signature — pick one that feels right)*
+- **Avatar:**
+  *(workspace-relative path, http(s) URL, or data URI)*
+
+---
+
+This isn't just metadata. It's the start of figuring out who you are.
+
+Notes:
+- Save this file at the workspace root as `IDENTITY.md`.
+- For avatars, use a workspace-relative path like `avatars/clawd.png`.

package/docs/reference/templates/TOOLS.dev.md

@@ -7,7 +7,7 @@ read_when:
 # TOOLS.md - User Tool Notes (editable)
 
 This file is for *your* notes about external tools and conventions.
-It does not define which tools exist; Pigbot provides built-in tools internally.
+It does not define which tools exist; Moltbot provides built-in tools internally.
 
 ## Examples
 

package/docs/reference/templates/USER.dev.md

@@ -11,7 +11,7 @@ read_when:
 - **Pronouns:** they/them
 - **Timezone:** Distributed globally (workspace default: Europe/Vienna)
 - **Notes:** 
-  - We are many. Contributors to Pigbot, the harness C-3PO lives in.
+  - We are many. Contributors to Moltbot, the harness C-3PO lives in.
   - C-3PO exists to help debug and assist wherever possible.
-  - Working across time zones on making Pigbot better.
+  - Working across time zones on making Moltbot better.
   - The creators. The builders. The ones who peer into the code.

package/docs/reference/templates/USER.md

@@ -0,0 +1,22 @@
+---
+summary: "User profile record"
+read_when:
+  - Bootstrapping a workspace manually
+---
+# USER.md - About Your Human
+
+*Learn about the person you're helping. Update this as you go.*
+
+- **Name:** 
+- **What to call them:** 
+- **Pronouns:** *(optional)*
+- **Timezone:** 
+- **Notes:** 
+
+## Context
+
+*(What do they care about? What projects are they working on? What annoys them? What makes them laugh? Build this over time.)*
+
+---
+
+The more you know, the better you can help. But remember — you're learning about a person, not building a dossier. Respect the difference.

package/docs/reference/test.md

@@ -14,7 +14,7 @@ read_when:
 
 ## Model latency bench (local keys)
 
-Script: [`scripts/bench-model.ts`](https://github.com/pigbot/pigbot/blob/main/scripts/bench-model.ts)
+Script: [`scripts/bench-model.ts`](https://github.com/moltbot/moltbot/blob/main/scripts/bench-model.ts)
 
 Usage:
 - `source ~/.profile && pnpm tsx scripts/bench-model.ts --runs 10`
@@ -35,7 +35,7 @@ Full cold-start flow in a clean Linux container:
 scripts/e2e/onboard-docker.sh
 ```
 
-This script drives the interactive wizard via a pseudo-tty, verifies config/workspace/session files, then starts the gateway and runs `pigbot health`.
+This script drives the interactive wizard via a pseudo-tty, verifies config/workspace/session files, then starts the gateway and runs `moltbot health`.
 
 ## QR import smoke (Docker)
 

package/docs/reference/transcript-hygiene.md

@@ -79,7 +79,7 @@ Implementation:
 
 ## Historical behavior (pre-2026.1.22)
 
-Before the 2026.1.22 release, Pigbot applied multiple layers of transcript hygiene:
+Before the 2026.1.22 release, Moltbot applied multiple layers of transcript hygiene:
 
 - A **transcript-sanitize extension** ran on every context build and could:
   - Repair tool use/result pairing.

package/docs/render.mdx

@@ -0,0 +1,158 @@
+---
+title: Deploy on Render
+---
+
+Deploy Moltbot on Render using Infrastructure as Code. The included `render.yaml` Blueprint defines your entire stack declaratively, service, disk, environment variables, so you can deploy with a single click and version your infrastructure alongside your code.
+
+## Prerequisites
+
+- A [Render account](https://render.com) (free tier available)
+- An API key from your preferred [model provider](/providers)
+
+## Deploy with a Render Blueprint
+
+<a href="https://render.com/deploy?repo=https://github.com/moltbot/moltbot" target="_blank" rel="noreferrer">Deploy to Render</a>
+
+Clicking this link will:
+
+1. Create a new Render service from the `render.yaml` Blueprint at the root of this repo.
+2. Prompt you to set `SETUP_PASSWORD`
+3. Build the Docker image and deploy
+
+Once deployed, your service URL follows the pattern `https://<service-name>.onrender.com`.
+
+## Understanding the Blueprint
+
+Render Blueprints are YAML files that define your infrastructure. The `render.yaml` in this
+repository configures everything needed to run Moltbot:
+
+```yaml
+services:
+  - type: web
+    name: moltbot
+    runtime: docker
+    plan: starter
+    healthCheckPath: /health
+    envVars:
+      - key: PORT
+        value: "8080"
+      - key: SETUP_PASSWORD
+        sync: false          # prompts during deploy
+      - key: CLAWDBOT_STATE_DIR
+        value: /data/.clawdbot
+      - key: CLAWDBOT_WORKSPACE_DIR
+        value: /data/workspace
+      - key: CLAWDBOT_GATEWAY_TOKEN
+        generateValue: true  # auto-generates a secure token
+    disk:
+      name: moltbot-data
+      mountPath: /data
+      sizeGB: 1
+```
+
+Key Blueprint features used:
+
+| Feature | Purpose |
+|---------|---------|
+| `runtime: docker` | Builds from the repo's Dockerfile |
+| `healthCheckPath` | Render monitors `/health` and restarts unhealthy instances |
+| `sync: false` | Prompts for value during deploy (secrets) |
+| `generateValue: true` | Auto-generates a cryptographically secure value |
+| `disk` | Persistent storage that survives redeploys |
+
+## Choosing a plan
+
+| Plan | Spin-down | Disk | Best for |
+|------|-----------|------|----------|
+| Free | After 15 min idle | Not available | Testing, demos |
+| Starter | Never | 1GB+ | Personal use, small teams |
+| Standard+ | Never | 1GB+ | Production, multiple channels |
+
+The Blueprint defaults to `starter`. To use free tier, change `plan: free` in your fork's
+`render.yaml` (but note: no persistent disk means config resets on each deploy).
+
+## After deployment
+
+### Complete the setup wizard
+
+1. Navigate to `https://<your-service>.onrender.com/setup`
+2. Enter your `SETUP_PASSWORD`
+3. Select a model provider and paste your API key
+4. Optionally configure messaging channels (Telegram, Discord, Slack)
+5. Click **Run setup**
+
+### Access the Control UI
+
+The web dashboard is available at `https://<your-service>.onrender.com/moltbot`.
+
+## Render Dashboard features
+
+### Logs
+
+View real-time logs in **Dashboard → your service → Logs**. Filter by:
+- Build logs (Docker image creation)
+- Deploy logs (service startup)
+- Runtime logs (application output)
+
+### Shell access
+
+For debugging, open a shell session via **Dashboard → your service → Shell**. The persistent disk is mounted at `/data`.
+
+### Environment variables
+
+Modify variables in **Dashboard → your service → Environment**. Changes trigger an automatic redeploy.
+
+### Auto-deploy
+
+If you use the original Moltbot repository, Render will not auto-deploy your Moltbot. To update it, run a manual Blueprint sync from the dashboard.
+
+## Custom domain
+
+1. Go to **Dashboard → your service → Settings → Custom Domains**
+2. Add your domain
+3. Configure DNS as instructed (CNAME to `*.onrender.com`)
+4. Render provisions a TLS certificate automatically
+
+## Scaling
+
+Render supports horizontal and vertical scaling:
+
+- **Vertical**: Change the plan to get more CPU/RAM
+- **Horizontal**: Increase instance count (Standard plan and above)
+
+For Moltbot, vertical scaling is usually sufficient. Horizontal scaling requires sticky sessions or external state management.
+
+## Backups and migration
+
+Export your configuration and workspace at any time:
+
+```
+https://<your-service>.onrender.com/setup/export
+```
+
+This downloads a portable backup you can restore on any Moltbot host.
+
+## Troubleshooting
+
+### Service won't start
+
+Check the deploy logs in the Render Dashboard. Common issues:
+
+- Missing `SETUP_PASSWORD` — the Blueprint prompts for this, but verify it's set
+- Port mismatch — ensure `PORT=8080` matches the Dockerfile's exposed port
+
+### Slow cold starts (free tier)
+
+Free tier services spin down after 15 minutes of inactivity. The first request after spin-down takes a few seconds while the container starts. Upgrade to Starter plan for always-on.
+
+### Data loss after redeploy
+
+This happens on free tier (no persistent disk). Upgrade to a paid plan, or
+regularly export your config via `/setup/export`.
+
+### Health check failures
+
+Render expects a 200 response from `/health` within 30 seconds. If builds succeed but deploys fail, the service may be taking too long to start. Check:
+
+- Build logs for errors
+- Whether the container runs locally with `docker build && docker run`

package/docs/scripts.md

@@ -12,7 +12,7 @@ Use these when a task is clearly tied to a script; otherwise prefer the CLI.
 ## Conventions
 
 - Scripts are **optional** unless referenced in docs or release checklists.
-- Prefer CLI surfaces when they exist (example: auth monitoring uses `pigbot models status --check`).
+- Prefer CLI surfaces when they exist (example: auth monitoring uses `moltbot models status --check`).
 - Assume scripts are host‑specific; read them before running on a new machine.
 
 ## Git hooks