`. If the hub fails, the agent generates a minimal harness itself.
-5. **Run the task** using only harness commands, for example:
-
- ```
- cli-anything-gimp image resize input.jpg output.jpg 1920 1080
- cli-anything-libreoffice convert doc.docx output.pdf
- cli-anything-blender render scene.blend --output frames/ --format PNG
- ```
-
-6. **Report** in a sentence or two: what was produced and where.
-
-Every step runs as a shell action, so you can watch the whole flow (version checks, installs, the task command) in the [task panel](../interfaces/browser.md#tasks), and it all lands in [logs](../concepts/logs.md).
-
-The skill hard-bans the failure modes of driving desktop apps directly: no `.exe` suffixes, no hardcoded `C:\Program Files\...` paths, no `&&` command chaining, no raw `soffice`/`gimp`/`blender` invocations. The harness resolves app locations and flags per platform, which is what makes the same task work on all three OSes.
-
-## Python fallback
-
-CLI-anything is the first choice, not the only one. If a harness command fails after one retry, the agent falls back to a pure-Python route (PIL for images, python-docx for documents, pydub for audio, moviepy for video), completes the task anyway, and tells you what it actually used (with a note that installing the app gives better results next time). Installs are never retried, timeouts are never looped on, and after repeated failures on one step the agent stops and reports rather than spinning.
-
-## Requirements
-
-- **Enable the skill** (see the note above). It does nothing while disabled.
-- **Action sets:** the skill declares `shell` and `file_operations`. It works through ordinary shell actions, no extra plumbing.
-- **A package manager** for auto-install: `winget` (Windows), Homebrew (macOS), or `apt` (Linux, where installs run under `sudo`). `pip` is needed for the harness hub.
-- **Internet access** the first time any given app or harness is installed.
-- **File paths:** give the agent full paths to input files (`C:\Users\you\Desktop\photo.jpg`, `/home/user/photo.jpg`) for the smoothest run.
-
-!!! warning "It installs software"
- By design, this skill can install real applications on your machine (silently, with license agreements auto-accepted) and run them with your privileges. Each install is a visible shell action in the task panel, and installs are attempted at most once. If you don't want the agent installing anything, keep the skill disabled or preinstall the apps you care about.
-
-## Related
-
-- [Skills](../concepts/skills.md): how skills are enabled, discovered, and invoked
-- [Built-in commands](builtin.md#skill): `/skill enable cli-anything` and friends
-- [Actions and action sets](../concepts/actions-and-action-sets.md): the shell actions underneath
-- [Living UI](../../living-ui/index.md): a different kind of "agent builds it for you"
diff --git a/mkdocs/docs/core/commands/index.md b/mkdocs/docs/core/commands/index.md
deleted file mode 100644
index 2bb4a143..00000000
--- a/mkdocs/docs/core/commands/index.md
+++ /dev/null
@@ -1,62 +0,0 @@
-# Commands
-
-Commands are slash-prefixed inputs (`/help`, `/provider anthropic sk-...`, `/skill enable pdf`) that the [UI layer](../interfaces/ui-layer.md) intercepts before anything reaches the agent. They're how you configure providers, integrations, skills, and MCP servers (instantly, without spending tokens or starting a task) and they work identically in the [browser](../interfaces/browser.md) and the [CLI](../interfaces/cli.md).
-
-
-
-- :material-book-alphabet:{ .lg .middle } __[Built-in commands](builtin.md)__
-
- ---
-
- The complete reference: every command, alias, and subcommand.
-
-- :material-console-line:{ .lg .middle } __[CLI-anything](cli-anything.md)__
-
- ---
-
- The bundled skill that automates desktop apps (GIMP, Blender, LibreOffice, ...) through cross-platform command-line harnesses.
-
-
-
-## How dispatch works
-
-When you submit input, the UI controller offers it to the command executor first. Input starting with `/` is split into a name and arguments, resolved against the command registry (aliases included, case-insensitive), and executed; the result comes back as a system message. Anything not starting with `/` goes to the agent as a normal chat message.
-
-An unknown command like `/frobnicate` returns `Unknown command`. It is **not** forwarded to the agent. Commands and conversation are handled separately.
-
-In the browser, typing `/` opens an autocomplete listing everything registered, so you rarely need to memorize names. In the CLI, `/help` prints the same list.
-
-## Four kinds of commands
-
-The registry is populated from four sources at startup:
-
-| Kind | Examples | Where they come from |
-|---|---|---|
-| **Built-in** | `/help`, `/provider`, `/mcp`, `/skill`, `/cred`, `/update` | Shipped in `app/ui_layer/commands/builtin/`; always present |
-| **Integration** | `/gmail`, `/slack`, `/telegram_bot`, `/notion` | One per available [integration](../../integrations/index.md), each with `connect` / `disconnect` / `status` plus integration-specific subcommands |
-| **Skill** | `/pdf`, `/docx`, `/pptx` | One per **enabled** [skill](../concepts/skills.md); registered and unregistered live as you toggle skills |
-| **Agent-provided** | varies | Commands the agent runtime registers programmatically, wrapped into the same registry |
-
-Built-in and integration commands run immediately in the UI layer. Skill commands are different: `/pdf merge these three files` doesn't run UI code. It routes your text to the agent with that skill pre-selected, and the argument text is substituted into the skill's instructions via `$ARGUMENTS`. It's a shortcut for "do this task, using this skill."
-
-## The commands you'll actually use
-
-```
-/help # list every command; /help mcp for details on one
-/provider [name] [key] # view or switch the LLM provider
-/mcp list # manage MCP servers
-/skill list # manage skills
-/cred status # see which integrations are connected
-/update --check # check for a new CraftBot version
-/clear # clear the chat /reset # reset agent state
-/exit # shut down
-```
-
-The full catalogue with every subcommand is in [Built-in commands](builtin.md).
-
-## Related
-
-- [Interfaces](../interfaces/index.md): where you type commands
-- [UI layer](../interfaces/ui-layer.md): the registry and executor behind dispatch
-- [Skills](../concepts/skills.md): the packages behind skill slash commands
-- [MCP](../../integrations/mcp.md): what `/mcp` manages
diff --git a/mkdocs/docs/core/concepts/actions-and-action-sets.md b/mkdocs/docs/core/concepts/actions-and-action-sets.md
deleted file mode 100644
index 948e84a6..00000000
--- a/mkdocs/docs/core/concepts/actions-and-action-sets.md
+++ /dev/null
@@ -1,103 +0,0 @@
-# Actions and action sets
-
-An **action** is one concrete thing the agent can do: write a file, search the web, send a Slack message, run a shell command. The action registry is the agent's entire vocabulary: if no action exists for something, the agent cannot do it. Action **sets** group related actions so each task carries only the vocabulary it needs.
-
-## Overview
-Three layers, each answering a different question:
-
-| Layer | Question it answers | When it's decided |
-|---|---|---|
-| **Registry** | What can this agent do at all? | At startup (import time), plus whenever MCP servers connect |
-| **Action sets** | What can *this task* do? | Once, at task creation (adjustable mid-task) |
-| **Router** | What happens *this turn*? | Every iteration of the [agent loop](agent-loop.md) |
-
-CraftBot ships 1,176 actions: 56 core actions (task management, files, web, documents, media, shell, scheduling, memory, messaging) and 1,120 integration actions under `app/data/action/integrations//`. The full catalogue is in the [actions reference](default-actions.md).
-
-## Anatomy of an action
-
-An action is a Python function with an `@action` decorator that registers it at import time. The metadata (not the implementation) is what the selection LLM sees, so the `description` field does most of the work:
-
-| Field | What it does |
-|---|---|
-| `name` | Unique identifier, e.g. `web_search` |
-| `description` | What the LLM reads to decide when to pick this action |
-| `input_schema` / `output_schema` | Parameter and result contracts, shown to the LLM |
-| `action_sets` | Which sets contain this action (an action can be in several) |
-| `mode` | Interface visibility (which interface contexts offer the action); `"ALL"` means everywhere |
-| `execution_mode` | `"internal"` (in-process) or `"sandboxed"` (isolated venv) |
-| `platforms` | `windows` / `linux` / `darwin` / `all`; see platform dispatch below |
-| `requirement` | pip packages the action needs; installed automatically before it runs |
-| `parallelizable` | Whether it may run alongside other actions in one turn (`False` for writes, state changes, `send_message`) |
-| `irreversible` | Marks side effects that can't be undone once they reach the outside world (send email, post publicly) |
-| `default`, `test_payload` | Always-available flag (legacy; prefer `action_sets`), and data for simulated test runs |
-
-**Irreversible actions get a crash guard.** Before an `irreversible=True` action executes, its intent is durably recorded in an activity ledger. After execution the outcome is recorded too. If CraftBot crashes between the send and the record, the guard refuses a blind re-execution and surfaces a warning instead. The agent verifies or asks you rather than sending your email twice.
-
-**Platform dispatch.** The registry stores implementations per platform. One logical name like `run_shell` can have Windows, macOS, and Linux variants. Lookup picks the current platform's implementation and falls back to the generic `all` one.
-
-## Action sets
-
-Sets are labels declared in each action's metadata. The registry discovers them dynamically by scanning, so a custom action declaring `action_sets=["my_tools"]` creates the `my_tools` set with no other registration step. The built-in sets:
-
-| Set | Contains |
-|---|---|
-| `core` | 35 always-included actions: messaging, task control, file operations, search, web research, shell and HTTP, clipboard, scheduling, integration management, skill and set management, memory search, and sub-agent spawning |
-| `document_processing` | PDF reading, editing, and conversion, markdown conversion, OCR, image description, video understanding |
-| `image` | `describe_image`, `generate_image`, `perform_ocr`, `understand_video` |
-| `video` | `generate_video`, `perform_ocr`, `understand_video` |
-| `content_creation` | `generate_image`, `generate_video` |
-| `scheduler` | Schedule management actions (also present in `core`) |
-| `proactive` | Recurring-task management for `PROACTIVE.md` plus schedule management |
-| `living_ui` | The 7 Living UI lifecycle actions (scaffold, launch, restart, import, data access) |
-
-Connected integrations contribute their own sets, and each connected [MCP server](../../integrations/mcp.md) becomes a set named `mcp_` (see below).
-
-## How a task gets its actions
-
-When a task starts, one LLM call selects both the [skills](skills.md) and the action sets for it, based on the task description: a report-writing task gets `document_processing`, a Living UI build gets `living_ui`. Sets recommended by the selected skill are merged in automatically, `core` is always included, and the union is compiled into a static action list that the task carries for its lifetime.
-
-This compile-once design is deliberate: during execution there is no retrieval step and no searching for tools. The task's vocabulary is a fixed list the router reads directly.
-
-The list can still change, though. Mid-task, the agent can call `list_action_sets`, `add_action_sets`, and `remove_action_sets` (all in `core`, so always available) to expand or trim its own vocabulary when it discovers it needs something. These calls appear in the action panel when a task discovers mid-way that it needs another capability.
-
-## Per-turn selection
-
-Every iteration of the [agent loop](agent-loop.md), the router makes **one LLM call** that returns reasoning plus a list of one *or more* actions:
-
-```json
-{"reasoning": "...", "actions": [{"action_name": "web_search", "parameters": {...}},
- {"action_name": "task_update_todos", "parameters": {...}}]}
-```
-
-Rules applied to that list before execution:
-
-- **Parallel execution.** Multiple actions in one decision run concurrently, up to 10 per batch.
-- **Non-parallelizable wins alone.** If any selected action has `parallelizable=False`, it runs by itself and the rest are dropped with an error the agent sees next turn.
-- **Format errors retry, then abort.** Malformed LLM output gets up to 3 retries with the parse error fed back. After that the task aborts rather than wasting tokens.
-- **Conversation mode is narrow.** Outside a task, the candidates are only `send_message`, `task_start`, `ignore`, plus messaging actions for connected platforms. Real work requires a task.
-
-Each execution logs `action_start` / `action_end` events to the task's [event stream](event-stream.md), which is what the action panel in the browser renders live.
-
-## Internal vs sandboxed execution
-
-`execution_mode` decides where the function body runs:
-
-- **`internal`** runs in the CraftBot process. Used by actions that touch agent state (task management, messaging, memory) and by MCP tools. Declared `requirement` packages are pip-installed into the main environment before the first run.
-- **`sandboxed`** runs in a separate process using a persistent virtual environment (`~/.craftbot/sandbox_venv`, created lazily on first use and reused). Requirements install into the sandbox venv once and persist across calls. A timeout kills runaway executions.
-
-Either way, the action returns a dict that flows back into the event stream as the observation for the next turn.
-
-## MCP tools join the same registry
-
-Servers configured in `app/config/mcp_config.json` (or managed via the `/mcp` command and **Settings**) expose tools that are converted into ordinary actions at connect time: each tool becomes an action named `mcp__`, its JSON Schema becomes the `input_schema`, and all of a server's tools land in an action set named `mcp_` (configurable per server). From that point nothing downstream knows the difference: MCP sets appear in task-creation selection, MCP actions appear in the router's candidates, and disabling a server unregisters its actions. Details and server setup: [MCP](../../integrations/mcp.md).
-
-!!! note "Implementation files"
- Registry and decorator: `agent_core/core/action_framework/registry.py`. Set compilation: `app/action/action_set.py`. Set/skill selection at task creation: `app/internal_action_interface.py`. Per-turn routing: `agent_core/core/impl/action/router.py`. Execution: `agent_core/core/impl/action/manager.py` and `executor.py`. MCP conversion: `agent_core/core/impl/mcp/adapter.py`.
-
-## Next
-
-- [Actions reference](default-actions.md): the full catalogue, action by action
-- [Write a custom action](../../develop/custom-action.md): one file, one decorator
-- [Skills](skills.md): strategy injected on top of the action vocabulary
-- [Agent loop](agent-loop.md): where selection and execution sit in the cycle
-- [MCP](../../integrations/mcp.md): connecting external tool servers
diff --git a/mkdocs/docs/core/concepts/agent-bundles.md b/mkdocs/docs/core/concepts/agent-bundles.md
deleted file mode 100644
index c8a61e84..00000000
--- a/mkdocs/docs/core/concepts/agent-bundles.md
+++ /dev/null
@@ -1,95 +0,0 @@
-# Agent bundles and profiles
-
-An agent profile is the portable part of a CraftBot agent: its personality files, enabled skills, enabled MCP servers, and Living UI apps, packaged into a single `.craftbot` file. Exporting a profile lets you move your configured agent to another machine or share it. Importing a profile turns a stock CraftBot into a configured specialist in one step.
-
-An **agent bundle** is a pre-built profile authored for a specific role (CEO agent, senior Python engineer, finance agent, and others). CraftOS publishes 42 of them in the [CraftBot Agent Bundles repository](https://github.com/CraftOS-dev/craftbot-agent-bundles), free to download and import.
-
-## Example bundles
-
-The 42 bundles are grouped by domain. Each one wires the agent with the skills, MCP servers, and operating rules a senior practitioner of that role uses, so the agent executes the work rather than only describing it. A sample:
-
-| Bundle | Domain | What it does |
-|---|---|---|
-| `ceo-agent` | Executive | Drafts strategy documents, board packs, and investor updates, and tracks OKRs. |
-| `finance-agent` | Finance | Builds FP&A models, runs capital-allocation analysis, and drafts term sheets. |
-| `project-manager` | Operations | Writes charters, work-breakdown structures, Gantt schedules, and status reports. |
-| `senior-python-engineer` | Engineering | Reviews Python code, debugs failures, and proposes optimizations. |
-| `devops-engineer` | Engineering | Works with containers, Kubernetes, infrastructure-as-code, and GitOps pipelines. |
-| `marketing-agent` | Marketing | Plans campaigns and produces content across channels. |
-| `seo-specialist` | Marketing | Audits sites, researches keywords, and drafts on-page and technical SEO fixes. |
-| `sales-agent` | Sales | Researches prospects, drafts outreach, and maintains pipeline records. |
-| `data-analyst` | Research | Queries data, runs analysis, and turns results into reports and charts. |
-| `legal-counsel` | Legal | Reviews contracts, flags risk, and drafts standard clauses. |
-| `recruiter` | People | Writes job descriptions, sources candidates, and screens applicants. |
-| `personal-assistant` | Personal | Manages your inbox, calendar, and day-to-day tasks. |
-
-The repository lists all 42 with a description of each, spanning executive and strategy, engineering, marketing and growth, sales and customer, content and documentation, research and analytics, legal and compliance, and people and product roles.
-
-## What a profile contains
-
-A `.craftbot` file is a ZIP archive. It carries the parts of an agent that are portable between installs:
-
-| Included | Notes |
-|---|---|
-| Personality files | `SOUL.md`, `USER.md`, and the other `agent_file_system` markdown that defines behavior. See [Agent file system](agent-file-system.md). |
-| Enabled skills | The skill folders you have enabled. Skills already present on the target install are not re-shipped. See [Skills](skills.md). |
-| Enabled MCP servers | Server definitions from `mcp_config.json`, with secret environment values stripped out. See [MCP servers](../../integrations/mcp.md). |
-| Living UI apps | Any apps you built. See [Living UI](../../living-ui/index.md). |
-| `manifest.json` and `README.md` | Bundle metadata and a human-readable summary of the contents. |
-
-Four things are deliberately **never** included, so a bundle is safe to share:
-
-- API keys and provider credentials.
-- OAuth tokens and integration secrets.
-- Personal memory (`MEMORY.md` and the memory index).
-- Conversation history.
-
-## Importing a profile
-
-You import a profile from the browser interface.
-
-1. Open **Settings → General** and choose **Import Agent Profile**.
-2. Select or drag in a `.craftbot` file. To use a pre-built bundle, download one from the [agent bundles repository](https://github.com/CraftOS-dev/craftbot-agent-bundles) first (see [Using a pre-built bundle](#using-a-pre-built-bundle) below).
-3. CraftBot inspects the bundle and shows a preview: which skills and MCP servers it contains, which of those you already have installed, and which MCP servers need environment values (API keys) that were stripped on export.
-4. Choose an import mode:
-
-| Mode | Effect on existing personality files |
-|---|---|
-| **Merge and Replace** | Applies the bundle's skills, MCP servers, and apps, and replaces the personality files the bundle provides. Files the bundle does not include are left alone. |
-| **Overwrite** | Replaces the personality files with the bundle's versions. |
-
-5. Confirm. CraftBot installs the bundle's skills into your `skills/` directory and enables them, adds its MCP servers (disabled until you supply the missing keys), applies the personality files, and registers any Living UI apps.
-
-### What import does not change
-
-- **Your model and provider stay the same.** A bundle's `agent.yaml` names a recommended model, but importing never switches your configured provider or API key. Set the model yourself from **Settings → Model** if you want the recommended one. See [LLM providers](../providers/llm.md).
-- **Your existing credentials stay.** The importer only adds skills, servers, personality files, and apps. It does not touch your keys or connected integrations.
-- **Skills are added, not deleted.** If a skill folder already exists, the importer keeps it and reports it as skipped rather than overwriting your version.
-
-After import, the agent typically asks a few questions about your routines and proposes recurring tasks for `PROACTIVE.md`. See [Proactive mode](../modes/proactive.md).
-
-### Using a pre-built bundle
-
-1. Open the [CraftBot Agent Bundles repository](https://github.com/CraftOS-dev/craftbot-agent-bundles).
-2. Open the `bundles/` folder and download the file for the role you want. Files are named `-.craftbot`, for example `ceo-agent-20260611.craftbot`. The most recent date is the current version.
-3. Import it with the steps above.
-4. Fill in API keys for the MCP servers you actually plan to use. The preview lists exactly which servers need keys. You do not need to configure servers for tools you will not use.
-
-The repository lists all 42 bundles grouped by domain (executive, engineering, marketing, sales, research, legal, and others), each with a description of what it does.
-
-## Exporting your own profile
-
-Once you have configured an agent you like, you can export it.
-
-1. Open **Settings → General** and choose **Export Agent Profile**.
-2. Optionally add a description. CraftBot writes a `.craftbot` file named `craftbot--.craftbot`.
-
-The export includes only enabled skills and enabled MCP servers, so the file stays small and does not carry the roughly 157 disabled default servers or machine-specific command paths. Secrets are stripped, so the recipient supplies their own keys.
-
-Use export to move your agent to another machine, back up a configuration before experimenting, or share a persona you built. To publish a polished persona to the public repository, follow the authoring and submission process in [Create an agent bundle](../../develop/custom-agent.md).
-
-## Next
-
-- [Create an agent bundle](../../develop/custom-agent.md): author your own persona and publish it to the repository
-- [Agent bundle config](../configuration/agent-config-yaml.md): the `agent.yaml` manifest fields
-- [Skills](skills.md) and [MCP servers](../../integrations/mcp.md): the two capability layers a bundle carries
diff --git a/mkdocs/docs/core/concepts/agent-file-system.md b/mkdocs/docs/core/concepts/agent-file-system.md
deleted file mode 100644
index ba12fb12..00000000
--- a/mkdocs/docs/core/concepts/agent-file-system.md
+++ /dev/null
@@ -1,83 +0,0 @@
-# Agent file system
-
-`agent_file_system/` at the project root is the agent's home directory: a dozen markdown files that hold its identity, its knowledge of you, and its memory of everything that's happened, plus a `workspace/` where task outputs land. Understanding who writes each file, and which ones you're meant to edit, is the single highest-leverage way to tune your agent.
-
-## Overview
-The files fall into three categories. Some are **yours to write**: the personality brief, your profile, the style guide. Some are **the agent's working notes**: the ops manual it consults and the task list it maintains. The rest are **records**: event logs, task history, and distilled memory, maintained by harness subsystems rather than by you or the agent.
-
-The agent reads and writes these files with ordinary file actions, and a few (SOUL.md, AGENT.md pointers, USER.md) feed directly into every LLM call. Edit one and behavior changes on the next turn, with no restart.
-
-The directory is seeded from templates in `app/data/agent_file_system_template/` on first run, and the `/reset` command restores the markdown files from those templates.
-
-## The files
-
-| File | Who writes it | May I edit it? | What it does |
-|---|---|---|---|
-| `SOUL.md` | You (agent only on your explicit request) | **Yes, the main personality knob** | Personality, tone, behavior. Injected into the system prompt every turn |
-| `USER.md` | Onboarding wizard; agent, after confirming with you | **Yes** | Your profile: identity, timezone, communication preferences, life goals |
-| `FORMAT.md` | You | **Yes** | Formatting standards the agent reads before generating any document |
-| `GLOBAL_LIVING_UI.md` | You | **Yes** | Global design preferences for every [Living UI](../../living-ui/index.md) project: colors, theme, enforced rules |
-| `AGENT.md` | Ships with CraftBot; agent appends learned operational fixes | Yes, carefully | The agent's versioned operations manual: runtime, errors, integrations, conventions. The agent greps it by `## ` |
-| `PROACTIVE.md` | `recurring_*` actions and the planners | Prefer the actions; preserve the `` markers | Recurring proactive tasks plus the planner's Goals / Plan / Status; see [Proactive mode](../modes/proactive.md) |
-| `MEMORY.md` | Memory processor only (nightly job) | **No** | Distilled long-term memory, one timestamped fact per line; see [Memory](memory.md) |
-| `EVENT.md` | Event stream manager | **No** | Append-only chronological log of every event (actions, messages, errors) |
-| `EVENT_UNPROCESSED.md` | Event stream manager | **No** | Staging buffer of events awaiting the nightly memory run; cleared after each run |
-| `TASK_HISTORY.md` | Appended on every `task_end` | **No** | One summary section per finished task: status, timestamps, outcome, skills used |
-| `CONVERSATION_HISTORY.md` | Event stream manager | **No** | Rolling transcript of every user ↔ agent exchange, never auto-cleared |
-| `MISSION_INDEX_TEMPLATE.md` | Static template | **No** | Copied into `workspace/missions//INDEX.md` when a mission starts |
-
-The "No" files are harness-managed. Hand-editing them creates inconsistencies the agent can't recover from: the memory pipeline expects `MEMORY.md` in its exact line format, and the event logs are the ground truth other subsystems replay. Read them freely, but never write to them.
-
-## Files you should edit
-
-Three files do most of the customization work:
-
-**SOUL.md** shapes *how* the agent behaves. It's injected into the system prompt on every single turn, so edits take effect immediately and affect every interaction. Want it more terse, more playful, stricter about asking before acting? Say so here, or just tell the agent to update its soul, and it will ask for confirmation before saving.
-
-**USER.md** shapes *who it's working for*. Onboarding fills the skeleton (identity, timezone, communication preferences, goals). Keep it current as things change. The agent reads it at the start of user-facing tasks and only writes durable, confirmed facts back. One-off requests don't land here.
-
-**FORMAT.md** shapes *what it produces*. The agent consults it before generating any file. A `## global` section sets universal rules (colors, typography, writing style), and per-filetype sections (`## pptx`, `## docx`, `## xlsx`, `## pdf`) override it for that format. If every deck the agent makes has the wrong brand color, fix it once here and every future document follows.
-
-`GLOBAL_LIVING_UI.md` plays the same role for generated apps: design preferences and enforced rules applied to every Living UI project, with per-project answers overriding when they conflict.
-
-A useful side-effect to know: `AGENT.md`, `PROACTIVE.md`, `MEMORY.md`, `USER.md`, and `EVENT_UNPROCESSED.md` are indexed for the agent's semantic memory search, and a file watcher re-indexes them the moment they change, so edits to these files become retrievable knowledge, not just prompt text.
-
-## workspace/
-
-Everything a task produces lands under `agent_file_system/workspace/`. Four zones with different lifecycles:
-
-```text
-workspace/
-├── Persistent task outputs: reports, exports,
-│ anything you asked for. Never auto-cleaned.
-├── tmp// Per-task scratch: drafts, downloads,
-│ intermediate state. Auto-created when the task
-│ starts; auto-deleted on task end AND at startup.
-├── missions// Multi-session initiatives. INDEX.md (from the
-│ template) records goal, findings, next steps;
-│ it's what a future task reads to restore context.
-│ Never auto-cleaned.
-└── living_ui/_/ Living UI projects: self-contained apps managed
- by their own lifecycle actions. Don't rename or
- delete these by hand.
-```
-
-The practical rules:
-
-- **Deliverables go in the workspace root.** That's where "save it as frameworks.md" ends up, and where you go looking for outputs.
-- **Anything in `tmp/` is disposable by design.** If a task saved something there that you want, move it out before the task ends.
-- **Missions are for work bigger than one task** (a job hunt, a research program). The mission's `INDEX.md` is the durable state. Individual tasks come and go.
-
-## Configuration and limits
-
-- **Location:** `agent_file_system/` in the project root. The template lives at `app/data/agent_file_system_template/`.
-- **Edits apply on the next trigger**, with no restart. `SOUL.md` in particular takes effect on the very next turn.
-- **Reset:** `/reset` deletes the markdown files and re-copies the templates. Workspace contents are handled separately, and Living UI projects are preserved by the generic reset (they have their own teardown).
-- **Growth:** `EVENT.md` auto-rotates on size. `CONVERSATION_HISTORY.md` and `TASK_HISTORY.md` grow indefinitely, and `EVENT_UNPROCESSED.md` is cleared by each successful memory run.
-- **Not for secrets:** API keys and credentials live in `app/config/settings.json` and `.credentials/`, not in these markdown files.
-
-## Next
-
-- [Memory](memory.md): how events become `MEMORY.md` facts, and how the agent retrieves them
-- [Proactive mode](../modes/proactive.md): the system that reads and maintains `PROACTIVE.md`
-- [Living UI](../../living-ui/index.md): the projects living under `workspace/living_ui/`
diff --git a/mkdocs/docs/core/concepts/agent-loop.md b/mkdocs/docs/core/concepts/agent-loop.md
deleted file mode 100644
index a4ff63db..00000000
--- a/mkdocs/docs/core/concepts/agent-loop.md
+++ /dev/null
@@ -1,98 +0,0 @@
-# Agent loop
-
-The agent loop is the cycle CraftBot runs every time something wakes it up: claim a [trigger](triggers.md), route it to a workflow, let the LLM pick actions, execute them, and queue the follow-up. This cycle explains why tasks tick forward one step at a time, why the agent can wait hours for your reply without burning tokens, and why a restart doesn't lose work in flight.
-
-## Overview
-CraftBot does not run continuously. The agent sleeps until a trigger fires (your message, a schedule, a task's own "continue" note) then runs **exactly one turn** and goes back to sleep. The design has three properties:
-
-1. **One trigger, one turn.** A turn is a single pass through the loop: the LLM picks one or more [actions](actions-and-action-sets.md), CraftBot executes them, and the results land on the [event stream](event-stream.md).
-2. **Continuation is a new trigger, not a loop.** A ten-step task is not a `while` loop held in memory. Each turn ends by enqueuing a fresh continuation trigger for the same session. The next turn picks it up. Waiting is just a trigger with a `fire_at` timestamp in the future.
-3. **State lives outside the process.** Progress is recorded in the task's todos, its event stream, and the durable trigger queue, so a crash or restart between turns re-delivers the pending trigger and the task resumes where it left off.
-
-This is also why several tasks can run "at once": their triggers interleave through the same loop, each turn scoped to its own [session](task-sessions.md).
-
-## The outer loop
-
-A single consumer drives everything:
-
-| Step | What happens |
-|---|---|
-| 1. Claim | `trigger_service.next()` waits for the next due trigger and marks its durable record as claimed |
-| 2. React | `agent.react(trigger)` runs one full turn (everything below) |
-| 3. Settle | On success the trigger is `ack()`ed (done); on an exception it is `nack()`ed, which retries it with backoff |
-
-A crash between claim and settle leaves the trigger claimed. The next boot re-delivers it. The guarantee is *at-least-once*, never silently lost. The details are on the [Triggers](triggers.md) page.
-
-!!! note "Implementation files"
- The consumer is `_consume_triggers()` in `app/ui_layer/controller/ui_controller.py`. The turn itself is `AgentBase.react()` in `app/agent_base.py`. Claim/ack/nack live in `app/triggers/service.py`.
-
-## Inside a turn: routing
-
-`react()` checks the trigger, then the session's state, in a fixed order. First match wins:
-
-| Order | Condition | What runs |
-|---|---|---|
-| 1 | Trigger is a restart notice | Posts the prebuilt "I was restarted" message to chat and returns; no LLM call |
-| 2 | Trigger source is `memory` | Memory workflow: spawns a task that distills recent events into long-term [memory](memory.md) |
-| 3 | Trigger source is `proactive_heartbeat` / `proactive_planner` | [Proactive](../modes/proactive.md) workflow: collects due recurring tasks or runs a planner |
-| 4 | Task waiting for your reply, and this trigger carries no message | Re-schedules the wait for another 3 hours and returns; the task keeps sleeping |
-| 5 | Session has a running **complex** task | Complex-task workflow: todo-driven, approval-gated |
-| 6 | Session has a running **simple** task | Simple-task workflow: linear, auto-completing |
-| 7 | Anything else | Conversation workflow: no task exists yet |
-
-Before steps 4–7, the turn initializes the session and, if the trigger carries a user message routed in mid-task, records it onto the event stream so the LLM sees it.
-
-The three main workflows (5–7) differ in prompt shape, todo handling, and caching (compared side by side in [Task modes](../modes/index.md)) but they all execute the same four-phase pipeline.
-
-## The turn pipeline
-
-Every conversation, simple-task, and complex-task turn runs the same four phases:
-
-1. **Select.** One LLM call chooses one or more actions and their inputs, based on the task instruction, todos, and the event stream. In conversation mode the menu is deliberately tiny: reply, start a task (several in parallel is allowed), or deliberately ignore a message that needs no reaction.
-2. **Prepare.** Each selected action is resolved by name from the task's action sets and its inputs are bound.
-3. **Execute.** The actions run, in parallel when more than one was selected. Every action logs `action_start` / `action_end` events, which is what the action panel in the browser renders live.
-4. **Finalize.** The action output is inspected: did it create a task? ask for a delay (`wait`)? flag `waiting_for_user_reply`? Then a **new continuation trigger** is enqueued for the session (or for each task that a parallel `task_start` created) and the turn ends.
-
-The finalize phase drives multi-step work. A complex task making twenty tool calls is roughly twenty turns, each handed to the next by a `task_continuation` trigger. Between turns the agent is idle, free to run a different task's turn or to sleep.
-
-## What happens when you send a message
-
-Putting it together, end to end:
-
-1. Your message is durably recorded, then [session routing](task-sessions.md) decides whether it continues an existing task or opens a fresh session.
-2. A `user_message` trigger fires. The consumer claims it and calls `react()`.
-3. No task is running for the fresh session, so the conversation workflow runs: the LLM either answers directly (`send_message`) or calls `task_start`.
-4. If a task started, finalize queues a continuation trigger. Each subsequent turn works a todo, until the agent sends you a result and (for complex tasks) waits for your approval before `task_end`.
-5. If the agent asked you something mid-task, the task flips to waiting-for-reply and its trigger sleeps. Your answer routes back and wakes it immediately.
-
-## Watch it run
-
-- **In the browser.** The task card, todo list, and action panel are a live rendering of the loop: each visible action is one entry in a turn's execute phase.
-- **In the logs.** Every run writes to `logs/` ([Logs](logs.md)). Grep for the loop's own tags:
-
-```bash
-grep -E "\[REACT\]|\[WORKFLOW|\[ACTION\]|\[TRIGGER" logs/.log
-```
-
-```text
-[REACT] starting...
-[WORKFLOW: CONVERSATION] Query: what's the weather in Tokyo
-[ACTION] Ready to run 1 action(s): ['task_start']
-[TRIGGER] Creating new trigger for session: 4f2c1a
-```
-
-- **On disk.** Every event a turn produces is also appended to `agent_file_system/EVENT.md` ([Event stream](event-stream.md)).
-
-## Limits and error handling
-
-- **Per-task budgets.** Each task counts its actions and tokens. At 80% of either limit the agent gets a warning event telling it to wrap up. At 100% the task pauses and you get a Continue/Abort choice in chat. Nothing runs unbounded.
-- **Waiting costs nothing.** A task waiting for your reply re-schedules itself in 3-hour hops without invoking the LLM (step 4 in the routing table).
-- **Errors don't kill the loop.** Exceptions inside a turn are caught by `react()` itself, logged, and surfaced to the affected session. The consumer keeps running. Failures that escape a turn entirely cause a `nack()`: retry with exponential backoff, then a dead-letter message in chat rather than silent loss (see [Triggers](triggers.md)).
-- **Feature switches.** Disabling memory or proactive mode in settings makes their triggers no-ops. Routing steps 2 and 3 return without doing anything.
-
-## Next
-
-- [Triggers](triggers.md): everything that wakes the loop, and what survives a restart
-- [Task sessions](task-sessions.md): how messages find the right task, and how tasks live and end
-- [Event stream](event-stream.md): the record each turn reads from and writes to
-- [Task modes](../modes/index.md): conversation vs simple vs complex, compared
diff --git a/mkdocs/docs/core/concepts/context-engine.md b/mkdocs/docs/core/concepts/context-engine.md
deleted file mode 100644
index 7a9d145f..00000000
--- a/mkdocs/docs/core/concepts/context-engine.md
+++ /dev/null
@@ -1,96 +0,0 @@
-# Context engine
-
-Every time CraftBot calls the LLM, the context engine decides what the model actually sees: who the agent is, who you are, what's happening right now, and what it's being asked to decide. Understanding its layout explains most of CraftBot's token costs, most of its speed, and most of "why did the agent know that?"
-
-## Overview
-Every LLM call is two halves:
-
-| Half | Contents | Changes between calls? | Cached? |
-|---|---|---|---|
-| **Static prefix** (system prompt) | Agent identity, your profile, personality, policy, environment, file-system map | No; byte-identical within a session | Yes (provider KV cache) |
-| **Dynamic tail** (user prompt) | The decision template, current task, conversation history, live event stream, your query | Yes, every call | Only incrementally |
-
-The split is the whole design. LLM providers cache a prompt *prefix*: as long as the opening bytes of a call are identical to a previous call, those tokens are nearly free and fast. So the engine pushes everything stable to the front and everything volatile to the back. A follow-up call in a long task pays full price only for the events that happened since the last call, not for the agent's entire identity again.
-
-One consequence worth internalizing: **anything that varies call-to-call is banned from the prefix.** The clearest example is the current date and time. It would be natural to put "it is 14:32 on Thursday" in the system prompt, but that would change the prefix every call and bust the cache (Gemini's implicit caching is prefix-based, so even one changed byte invalidates everything after it). The engine deliberately keeps date/time out of the cached prefix. A dedicated `current_datetime_block` renders it for the dynamic tail, and every event in the stream carries its own timestamp, so the model still knows when things happened.
-
-## System prompt contents
-
-The engine assembles the system prompt from fixed sections in a fixed order:
-
-| # | Section | What it contains | You control it via |
-|---|---|---|---|
-| 1 | Agent info | Capabilities, task system, working ethic, format standards | Nothing (built-in) |
-| 2 | User profile | Your `USER.md`, verbatim | Edit [`USER.md`](agent-file-system.md) |
-| 3 | Soul | Your `SOUL.md`, verbatim: personality and tone | Edit [`SOUL.md`](agent-file-system.md) |
-| 4 | Language instruction | "Use the user's preferred language" rule | Language preference in `USER.md` |
-| 5 | Policy | Safety, privacy, prompt-injection defense | Nothing (built-in) |
-| 6 | Role info | Agent name + role persona | [Onboarding](../../start/onboarding.md) sets the name |
-| 7 | Environment | Timezone, working directory, OS (stable facts only) | Nothing (detected) |
-| 8 | File system | Map of `agent_file_system/`: what each file is for | Nothing (built-in) |
-| 9 | Base instruction | One-line closing instruction | Nothing (built-in) |
-
-Sections 2 and 3 are read from disk at prompt-build time, which is why editing `USER.md` or `SOUL.md` changes behavior on the very next call, with no restart. It also means an edit invalidates the cached prefix once. The first call after the edit pays full price, then caching resumes. The prompt templates behind each section are covered in [Prompts](prompts.md).
-
-## Per-turn message contents
-
-The tail is built per call and per session. Its ingredients, roughly back-to-front:
-
-**The decision template.** Which one depends on what's being decided: conversation-mode action selection, in-task selection, session routing, and so on (see [Prompts](prompts.md)). Within the tail, static template text still comes first and volatile content last, for the same caching reason.
-
-**`