kward 0.78.0 → 0.80.0

data/doc/security.md

@@ -6,8 +6,8 @@ This guide explains the trust boundaries and gives you a safe way to start work
 
 ## The short version
 
-- Kward and anything it launches run with your operating-system permissions.
-- File tools stay inside the active workspace by default, but shell commands are not sandboxed.
+- Kward and its trusted host-process extensions run with your operating-system permissions.
+- File tools stay inside the active workspace by default. Worktree-backed tabs force workspace guardrails and an OS-enforced sandbox for model-requested shell commands when the platform supports it.
 - Existing files must be read before Kward's file tools can edit or overwrite them.
 - Plugins, MCP servers, command hooks, and HTTP hooks should be configured only from sources and endpoints you trust.
 - Project skills and workspace hooks are disabled until you opt in or trust them.
@@ -16,6 +16,12 @@ This guide explains the trust boundaries and gives you a safe way to start work
 
 If a task involves secrets, production credentials, customer data, or an untrusted repository, narrow the workspace and tools before asking Kward to act.
 
+## Local model endpoints and replacement prompts
+
+The Local provider defaults to loopback endpoints. If you set `local_base_url` to another host, Kward can send prompts, selected workspace content, attachments, and tool results to that host. Treat a non-loopback endpoint as a model provider: use TLS and authentication where appropriate, and do not assume a private-network address is harmless.
+
+A `system_prompt.file` replacement is model-visible and may be retained in session prompt snapshots. Do not put tokens, credentials, customer data, or other secrets in that file. Replacement mode intentionally removes Kward's normal prompt layers, including workspace guidance and skill descriptions; verify it with `kward sysprompt` before using a permissive local model.
+
 ## A safe first run in an unfamiliar repository
 
 Start with project-provided extensions disabled, which is the default:
@@ -42,7 +48,7 @@ Before enabling or running anything:
 6. Do not add repository-provided Ruby files to `~/.kward/plugins` unless you are willing to run them as your user.
 7. Ask Kward to explain proposed edits and commands before applying them when the impact is unclear.
 
-For especially sensitive work, use a disposable checkout, container, virtual machine, or restricted operating-system account. Kward's own guardrails do not replace operating-system isolation.
+For especially sensitive work, use a disposable checkout, container, virtual machine, or restricted operating-system account. Enable [command sandboxing](sandboxing.md) for model-requested shell commands, but remember that it does not sandbox the Kward host process, plugins, MCP servers, hooks, or interactive shell features.
 
 ## Workspace access is a guardrail, not a sandbox
 
@@ -50,12 +56,20 @@ Kward's built-in file tools normally resolve paths inside the active workspace.
 
 These protections reduce accidental edits. They do not contain the whole process:
 
-- `run_shell_command`, `!command`, `/shell`, and `/pty` run with your user permissions.
-- A shell command can access files, environment variables, processes, and networks available to your account.
+- With `sandbox.mode: off` (the default), `run_shell_command`, `!command`, `/shell`, and `/pty` run with your user permissions.
+- A non-off [command sandbox](sandboxing.md) restricts only model-requested `run_shell_command` workers and their descendants. It does not cover `!command`, `/shell`, or `/pty`.
 - Plugins, command hooks, and MCP servers are local processes with the same general operating-system access.
 - Read-before-edit applies to Kward's file tools, not to arbitrary shell commands or extension code.
 
-You can disable the file boundary with `tools.workspace_guardrails: false`, but doing so broadens file-tool access and is rarely needed. See [Workspace tools](workspace-tools.md) for exact limits and [Configuration](configuration.md#Tool_workspace_guardrails) for the setting.
+You can disable the file boundary with `tools.workspace_guardrails: false`, but worktree-backed tabs do not honor that weakening: they always keep file guardrails enabled. See [Workspace tools](workspace-tools.md) for exact limits and [Configuration](configuration.md#Tool_workspace_guardrails) for the setting.
+
+## Worktree tab boundaries
+
+A worktree-backed tab uses its linked worktree as the active workspace and requires an OS-enforced `workspace_write` command sandbox. If the platform cannot provide filesystem enforcement, Kward refuses to activate the worktree rather than running model-requested shell commands unrestricted.
+
+The strict worktree agent disables configured MCP clients and lifecycle hooks for that tab because those extensions run outside the command-worker sandbox. The interactive `/shell`, `!command`, and `/pty` features remain host-process features and are not covered by the worktree boundary. Use them only when you intentionally want to run a user-directed command outside the model command sandbox.
+
+Git worktrees share repository metadata. Kward keeps Git metadata protection enabled for generic model-requested commands. Active worktree tabs provide a narrow host-side `git_commit` tool for explicit agent commits; the interactive `/git` flow remains the manual review, staging, and commit path.
 
 ## Tool approvals and policy hooks
 
@@ -95,7 +109,11 @@ Project hooks in `.kward/hooks.json` run only after `/hooks trust`. Trust is tie
 
 ### Plugins
 
-Ruby plugins in `~/.kward/plugins/*.rb` run inside the Kward process with your permissions. They can read files and environment variables, write files, run commands, and make network requests. Kward intentionally does not load plugins from a workspace directory.
+Ruby plugins in `~/.kward/plugins/*.rb` or package entrypoints at
+`~/.kward/plugins/*/plugin.rb` run inside the Kward process with your permissions.
+They can read files and environment variables, write files, run commands, and
+make network requests. Kward intentionally does not load plugins from a
+workspace directory.
 
 ### MCP servers
 
@@ -116,7 +134,7 @@ To answer a turn, Kward sends the assembled conversation context to the active m
 - images you attach,
 - summaries produced during compaction.
 
-Provider retention and training policies are controlled by the provider and your account or organization. Do not give Kward content you are not permitted to send to that provider.
+Provider retention and training policies are controlled by the provider and your account or organization. Do not give Kward content you are not permitted to send to that provider. Review [Model providers](providers.md) before switching endpoints, especially when moving between direct, routed, cloud, and local runtimes.
 
 ### Web tools
 
@@ -144,7 +162,8 @@ Kward keeps user data under `~/.kward` by default, or mostly beside `KWARD_CONFI
 
 | Data | Typical location | Notes |
 | --- | --- | --- |
-| Main config and OpenRouter key | `~/.kward/config.json` | Do not commit or share it. |
+| Main config | `~/.kward/config.json` | Non-secret provider/model setup; do not commit environment-specific configuration blindly. |
+| Provider API keys | `~/.kward/api_keys.json` | Separate private store, written with mode `0600` when possible; environment variables take precedence. |
 | OAuth credentials | `~/.kward/auth.json`, `anthropic_auth.json`, `github_auth.json` | Written with mode `0600` when possible. |
 | Sessions and tool results | `~/.kward/sessions/` | Conversation, file/tool output, and compaction history; files use mode `0600`. |
 | Prompt history | `~/.kward/history/` | Workspace-scoped submitted prompts; files use mode `0600`. |
@@ -155,6 +174,8 @@ Kward keeps user data under `~/.kward` by default, or mostly beside `KWARD_CONFI
 
 Private file modes help on normal Unix-like systems but do not protect data from your own account, privileged users, backups, malware, or a compromised machine. Session exports are written to the path you choose and should be protected separately.
 
+RPC authentication status and errors are sanitized, and API-key values are never returned. RPC is still a trusted-local interface: a client allowed to call `auth/loginWithApiKey`, `config/update`, or model/tool methods can change credentials and send workspace context to external providers. Do not expose the RPC process directly to untrusted users or networks.
+
 Use these commands to inspect or remove stored credentials and context:
 
 ```bash
@@ -173,7 +194,7 @@ See [Authentication](authentication.md), [Sessions](session-management.md), [Mem
 ## Practical habits
 
 - Keep secrets out of prompts, screenshots, shell output, plugin context, and hook messages.
-- Prefer temporary environment variables to storing short-lived API keys in config.
+- Prefer temporary environment variables for short-lived API keys; saved keys belong in Kward's private key store, never in prompts or project config.
 - Disable web search for private work that should not trigger external requests.
 - Keep memory off unless cross-session recall is useful and appropriate.
 - Review diffs and `git status` before committing agent changes.

data/doc/session-management.md

@@ -1,10 +1,8 @@
 # Sessions
 
-Sessions are Kward's way of keeping real work alive across time. An interactive chat is not just a scrollback buffer: it is saved as a session with messages, tool calls, tool results, compaction checkpoints, branches, and enough metadata for Kward to resume the work later.
+Kward saves each interactive chat as a session, so you can close the terminal and continue the work later. Sessions keep the conversation, tool activity, branches, and compaction history needed to restore the right context.
 
-Think of sessions as **context management**. They let you decide which conversation context Kward should use next.
-
-Think of rewinding and forking as **context time travel**. You can go back to an earlier prompt, try a different path, and keep both versions instead of losing the original work.
+Rewinding and forking are a kind of **context time travel**: go back to an earlier prompt, try another path, and keep both versions instead of losing the original work.
 
 ## Where sessions live
 

data/doc/skills.md

@@ -42,6 +42,16 @@ The `name` and `description` fields are required. The description matters: Kward
 
 Skill names should be lowercase letters, numbers, and hyphens, such as `testing`, `code-review`, or `release-checklist`.
 
+## Capture a skill from a session
+
+Use `/skill capture` after a useful session. Choose any saved session; Kward uses its active branch and asks your active model to draft a reusable `SKILL.md`. Review and edit the draft in the terminal editor, then save it explicitly. Captured skills always go to your personal Kward skill directory and are not activated automatically.
+
+The draft request includes the complete persisted branch, including available raw tool output and saved session context. Treat it like any other model request: do not capture a session whose contents you are not willing to send to the active provider. Kward rejects a source that does not fit the active model context instead of silently truncating it.
+
+If the reviewed name already exists, Kward requires an explicit overwrite confirmation. Activate a saved draft later with `/skill <name>`.
+
+Pan provides the same saved-session picker and editable review flow. RPC clients use `skills/captureSessions`, `skills/captureDraft`, and `skills/saveCapturedDraft`; see the [RPC protocol](rpc.md).
+
 ## Skill locations
 
 User-level skills are available in every project:

data/doc/tabs.md

@@ -33,6 +33,36 @@ Close the current tab:
 
 The tab bar appears at the bottom of the composer. The active tab is framed, and each tab label starts with its number.
 
+## Worktree tabs
+
+A normal session tab can be activated in a linked Git worktree after you have researched a task and decide that implementation should be isolated:
+
+```text
+/tab worktree
+```
+
+When enabled, Kward keeps the same tab and transcript but rebuilds its agent against a new worktree. The tab label includes the worktree branch. The worktree is created from `HEAD`, so Kward warns when the original workspace is dirty and leaves those existing changes in the original checkout; it does not copy them automatically. `/tab worktree activate` is an explicit alias for the same action.
+
+Running `/tab worktree` again leaves an active worktree unchanged. To return the tab to its original workspace while keeping the linked worktree and branch, detach it explicitly:
+
+```text
+/tab worktree detach
+```
+
+Inspect, merge, or remove the binding explicitly:
+
+```text
+/tab worktree status
+/tab worktree merge
+/tab worktree remove
+```
+
+`/tab worktree merge` merges the active worktree's clean, committed branch directly into the branch currently checked out in its original workspace. Kward shows the source and target revisions and requires confirmation. Both worktrees must be clean. If Git reports conflicts, Kward leaves the original workspace in its normal merge state; resolve the conflicts there or cancel them with `/tab worktree merge abort`.
+
+Removal refuses a dirty worktree and keeps its branch. A worktree that is missing or no longer points at the recorded branch is restored as unavailable rather than silently falling back to the original workspace.
+
+Worktree tabs are available for normal session tabs, not plugin-owned tabs. Kward's file tools, `@`/`$` completion, `/files` browser, integrated editor, and model-requested shell workers use the active worktree root. Model operations retain strict workspace guardrails. The interactive `/shell`, `!command`, and `/pty` features remain user-controlled and are not contained by the model command sandbox; use them only when that is intentional. Generic shell Git writes remain protected. When explicitly asked to commit, the agent can use the active tab's narrow `git_commit` tool; use the interactive `/git` flow when you want to review and commit changes yourself.
+
 ## Common workflow
 
 A typical multi-tab flow looks like this:
@@ -61,6 +91,13 @@ Tabs keep the conversations separate, so context from one tab does not automatic
 | `/tab close` | Close the current tab |
 | `/tab name <label>` | Rename the current tab |
 | `/tab rename <label>` | Same as `/tab name` |
+| `/tab worktree` | Create or activate the current session tab's linked Git worktree |
+| `/tab worktree activate` | Explicitly create or activate the current session tab's linked Git worktree |
+| `/tab worktree detach` | Return to the original workspace while keeping the linked worktree and branch |
+| `/tab worktree status` | Show the current tab's worktree binding and Git status |
+| `/tab worktree merge` | Merge the current worktree branch into the branch checked out in its original workspace |
+| `/tab worktree merge abort` | Abort a conflicted worktree merge in the original workspace |
+| `/tab worktree remove` | Remove a clean linked worktree and keep its branch |
 | `/tab move left` | Move the current tab one slot left |
 | `/tab move right` | Move the current tab one slot right |
 | `/tab move <number>` | Move the current tab to a numbered position |

data/doc/telegram.md

@@ -0,0 +1,138 @@
+# Telegram transport
+
+Use the first-party Telegram transport to talk to a normal Kward session from a
+private Telegram chat. The example lives under `examples/plugins/` and uses the
+Telegram Bot API's long-polling interface.
+
+The transport runs as trusted local Ruby code. Install it only on a machine
+where the bot can safely access its configured workspace and Kward tools.
+
+## Install the plugin
+
+Copy the packaged plugin into the user plugin directory:
+
+```bash
+mkdir -p ~/.kward/plugins
+cp -R examples/plugins/telegram ~/.kward/plugins/
+```
+
+Kward loads the package through `~/.kward/plugins/telegram/plugin.rb`.
+
+Installing the plugin does not connect to Telegram. Start it explicitly with
+`kward transport run com.kward.telegram`.
+
+## Configuration
+
+Configure one fixed workspace and explicit numeric allowlists:
+
+```json
+{
+  "transports": {
+    "com.kward.telegram": {
+      "workspace": "/Users/me/src/project",
+      "allowed_user_ids": [123456789],
+      "allowed_chat_ids": [123456789],
+      "poll_timeout_seconds": 25
+    }
+  }
+}
+```
+
+Do not put the bot token in the config file. Set it in the environment of the
+foreground process instead:
+
+```bash
+export TELEGRAM_BOT_TOKEN='replace-with-the-token-from-botfather'
+```
+
+The plugin also accepts the transport-specific secret name exposed by the
+host, but `TELEGRAM_BOT_TOKEN` is the recommended explicit variable.
+
+## Run it
+
+First check that Kward discovers the plugin:
+
+```bash
+kward transport list
+```
+
+Then run the personal-assistant transport in the foreground:
+
+```bash
+kward transport run com.kward.telegram
+```
+
+To override the workspace configured for this process:
+
+```bash
+kward transport run com.kward.telegram /Users/me/src/project
+# or:
+kward --working-directory /Users/me/src/project transport run com.kward.telegram
+```
+
+The plugin also registers `com.kward.telegram.isolated`. It uses the generic
+`isolated_chat` execution profile: no tools, no plugin commands, no memory, no
+attachments, and no approval interactions. Configure that transport with a
+separate empty workspace:
+
+```json
+{
+  "transports": {
+    "com.kward.telegram.isolated": {
+      "workspace": "/var/lib/kward-chat/workspace",
+      "allowed_user_ids": [123456789],
+      "allowed_chat_ids": [123456789],
+      "poll_timeout_seconds": 25
+    }
+  }
+}
+```
+
+For stronger separation, run it with a dedicated home and config directory
+that contain only this plugin:
+
+```bash
+HOME=/var/lib/kward-chat \
+KWARD_CONFIG_PATH=/var/lib/kward-chat/.kward/config.json \
+TELEGRAM_BOT_TOKEN="$TELEGRAM_BOT_TOKEN" \
+kward transport run com.kward.telegram.isolated
+```
+
+The process removes any existing Telegram webhook, validates the bot token,
+and begins long polling. Run only one polling process for a bot token; multiple
+pollers conflict with each other. Supervise the process externally for
+restart-on-failure behavior.
+
+## Current scope
+
+The adapter supports:
+
+- private text messages,
+- one or more explicitly allowlisted numeric users and chats,
+- fixed workspace routing,
+- normal Kward session persistence,
+- idempotent Telegram update claims,
+- final responses split at Telegram's message length limit,
+- tool approval buttons and single-question choice buttons for the personal
+  transport.
+
+The isolated transport intentionally has no tool or interaction capabilities.
+
+It intentionally does not yet support groups, media uploads, webhooks,
+streaming message edits, inline mode, or multiple independent workspace
+policies.
+
+The transport allowlist is enforced before external messages reach a Kward
+session. Keep the first deployment restricted to one user, one private chat,
+one workspace, and conservative tool permissions. Never use incoming Telegram
+text to select a workspace or tool scope.
+
+## Account setup boundary
+
+The code is ready for account setup, but no Telegram account, bot token, or
+network test is required to run the automated tests. After creating a bot,
+set `TELEGRAM_BOT_TOKEN`, replace the placeholder numeric IDs, and test the
+foreground process with a private chat first.
+
+See the official [Telegram Bot API](https://core.telegram.org/bots/api) for
+BotFather setup, polling behavior, message limits, and callback queries.

data/doc/transports.md

@@ -0,0 +1,209 @@
+# Transports
+
+A transport lets people use Kward through another service, such as Telegram,
+Slack, Discord, email, or HTTP. It receives messages from the service and sends
+Kward's responses back.
+
+A transport can target either a normal Kward session or an explicitly
+transport-capable plugin-owned chat. The transport handles service-specific
+details such as identities and message formatting. The target continues to
+own sessions, transcripts, tools, memory, and policy.
+
+Start with the first-party [Telegram transport](telegram.md) to see a complete
+example. It uses long polling and starts explicitly rather than with the normal
+interactive CLI.
+
+## How transports fit into Kward
+
+A transport should use the public transport host API rather than creating an
+`Agent`, opening a `SessionStore`, or calling the RPC server directly. This
+keeps session and tool behavior consistent across the CLI, RPC clients, and
+external services.
+
+Transport plugins are different from plugin-owned tabs:
+
+- A plugin tab runs its own chat and stores its own data.
+- A normal-session transport connects an external conversation to a Kward session.
+- A plugin-chat transport connects an external conversation to an explicitly
+  opted-in plugin chat and preserves that plugin's storage and model behavior.
+
+Transports run as trusted local Ruby code. Install only transports you trust.
+
+## Registration
+
+Transport registration is intentionally separate from transport startup. A
+plugin declares a transport and returns an adapter when Kward starts it:
+
+```ruby
+Kward.plugin do |plugin|
+  plugin.transport(
+    "example",
+    id: "com.example.transport",
+    capabilities: {
+      inbound: %i[text],
+      outbound: %i[text],
+      streaming: :aggregate
+    }
+  ) do |host, config|
+    ExampleTransport.new(host: host, config: config)
+  end
+end
+```
+
+Loading a plugin must not make network connections. Transports are started
+explicitly by the transport runtime.
+
+The `id` is a stable identifier used for configuration and persisted transport
+state. It must not change after release.
+
+## Message flow
+
+Inbound platform messages are normalized before they reach Kward. A normalized
+message contains an external transport ID, conversation ID, actor identity,
+message ID, text, attachments, reply context, and an idempotency key.
+
+The transport resolves the external conversation to a Kward session or an
+opted-in plugin chat, submits a turn, and subscribes to normalized turn events.
+The transport decides whether to stream, edit, aggregate, or otherwise render
+those events for its platform.
+
+A delivery failure must not fail the underlying model turn. The transport is
+responsible for retrying or reporting delivery failures, while the transcript
+and final turn status remain authoritative.
+
+### Targeting a plugin-owned chat
+
+A plugin must explicitly opt into external targeting:
+
+```ruby
+plugin.tab_type(
+  "example-bot",
+  id: "com.example.bot",
+  rpc: true,
+  transport: true
+) do |host, descriptor|
+  ExampleBot::Chat.new(client: host.client, descriptor: descriptor)
+end
+```
+
+A transport resolves it through the host instead of opening a workspace session:
+
+```ruby
+chat = host.plugin_chats.resolve(
+  type_id: "com.example.bot",
+  conversation: conversation,
+  actor: actor,
+  scope_key: "conversation:#{conversation.external_id}"
+)
+
+turn = chat.start_turn(message.text)
+turn.subscribe { |event| render_event(event) }
+```
+
+Plugin-chat drivers may accept a `context:` keyword on `submit`. Transport turns
+provide the authenticated actor there. Existing drivers that do not accept the
+keyword continue to work, but cannot use actor-specific context.
+
+Plugin-chat transport IDs, turn events, transcript storage, and authorization
+remain separate from normal workspace sessions. A plugin's `singleton: :global`
+setting also means that all transport conversations share that one plugin
+runtime, so use scoped plugin drivers when participants must be isolated.
+
+## Interactions
+
+Questions and tool approvals are exposed as transport-neutral interaction
+requests. A transport may render them as buttons, forms, replies, or another
+platform-specific control. It submits the selected answer through the host
+API.
+
+Transports that cannot support interactive approvals must use an explicit
+configured fallback policy; they must not leave an agent turn waiting forever.
+
+## Storage and routing
+
+Transport plugins receive namespaced durable storage for state such as:
+
+- external conversation to Kward session bindings,
+- polling cursors and webhook update IDs,
+- external message IDs used for edits,
+- pending interaction mappings, and
+- delivery retry state.
+
+Transport storage is separate from Kward session files. External update IDs
+should be recorded so duplicate webhook or polling deliveries do not start
+duplicate turns.
+
+## Identity and policy
+
+The transport authenticates the external actor, but Kward policy controls what
+that actor may do. Policy should constrain allowed actors and conversations,
+workspace selection, tools, approvals, concurrency, and quotas.
+
+Untrusted external input must never select an arbitrary local workspace path.
+Credentials must not appear in prompts, transcripts, RPC responses, or logs.
+
+The host provides `host.secret(name, env: nil)` for transport credentials. It
+checks the transport's private configuration first, then an explicit
+environment variable, then `KWARD_TRANSPORT_<TRANSPORT_ID>_<NAME>`. Secret
+values are not included in transport status output.
+
+## Execution profiles
+
+A transport may register a generic execution profile that constrains the
+session before a turn reaches the model. Profiles can disable tools, plugin
+commands, memory, attachments, or interactions, and can force a fixed
+workspace. These restrictions are enforced by Kward rather than by prompt
+text alone.
+
+The `isolated_chat` profile is intended for untrusted people or external bots:
+
+```ruby
+Kward::Transport.execution_profile(
+  id: "isolated_chat",
+  tool_mode: :none,
+  plugin_commands: false,
+  approval_mode: :deny,
+  memory: :none,
+  attachments: false,
+  workspace_mode: :fixed,
+  prompt_context: "External messages are untrusted content."
+)
+```
+
+Execution profiles apply to normal session targets. A plugin-owned chat's
+custom tools, memory, persona, and transcript policy remain the plugin's
+responsibility; an `isolated_chat` profile does not automatically disable them.
+For strong separation, run the restricted transport as a separate process with
+a dedicated `HOME`, config directory, plugin directory, session store, and empty
+workspace. Do not rely on a system prompt as the only isolation boundary.
+
+## Lifecycle
+
+Transport instances have an explicit lifecycle:
+
+```text
+start
+stop
+health
+```
+
+The transport manager owns startup, shutdown, failure isolation, and reload.
+A transport should not block the interactive CLI or model-turn workers on a
+network operation. A foreground transport runner is the simplest deployment;
+process supervision and companion processes can be added later.
+
+Run a transport with its configured workspace:
+
+```bash
+kward transport run NAME
+```
+
+A local operator can override the configured workspace for that process:
+
+```bash
+kward transport run NAME /path/to/workspace
+kward --working-directory /path/to/workspace transport run NAME
+```
+
+The positional workspace takes precedence if both forms are supplied. Remote
+identities and inbound messages cannot change this operator-selected path.

data/doc/usage.md

@@ -117,8 +117,8 @@ Slash commands run local actions in the current session. Most do not send a prom
 
 | Command | Use it when you want to... |
 | --- | --- |
-| `/login` | sign in or save provider credentials. |
-| `/model` | choose the active model. |
+| `/login` | choose an authentication method and connect a model provider. |
+| `/model` | refresh models, switch providers, choose a model, or enter a manual ID. |
 | `/reasoning` | choose reasoning effort. |
 | `/git` | review uncommitted changes, stage files, and commit. |
 | `/diff` | open the file changes recorded in the current session. |
@@ -135,6 +135,13 @@ Slash commands run local actions in the current session. Most do not send a prom
 | `/tab close` | close the active tab. |
 | `/tab new` | open a new tab. |
 | `/tab name <label>` | rename the active tab label. |
+| `/tab worktree` | create or activate the active session tab's linked Git worktree. |
+| `/tab worktree activate` | explicitly create or activate the active session tab's linked Git worktree. |
+| `/tab worktree detach` | return to the original workspace while keeping the linked worktree and branch. |
+| `/tab worktree status` | inspect the active tab's worktree binding and changes. |
+| `/tab worktree merge` | merge a clean worktree branch into the branch checked out in its original workspace. |
+| `/tab worktree merge abort` | abort a conflicted worktree merge in the original workspace. |
+| `/tab worktree remove` | remove a clean linked worktree while keeping its branch. |
 | `/session` | open the saved sessions picker or continue a previous session by path. |
 | `/resume` | alias for `/session`. |
 | `/session name <name>` | name or clear the current session. |
@@ -237,8 +244,9 @@ During a turn, Kward can inspect and change the workspace with tools for:
 
 Important guardrails:
 
-- Existing files must be read before Kward can edit or overwrite them.
+- Workspace guardrails limit file tools to the active workspace; existing files must be read before Kward can edit or overwrite them. They do not constrain shell commands. See [Workspace tools](workspace-tools.md).
 - File reads and edits are bounded to avoid loading very large files by accident.
+- The permission policy can decide whether a model-requested tool starts. The command sandbox is a separate, opt-in operating-system boundary for model-requested shell commands. See [Permissions](permissions.md) and [Command sandboxing](sandboxing.md).
 - Shell commands run from the workspace and should be treated like commands you run yourself.
 
 ## Images

data/doc/web-search.md

@@ -26,17 +26,17 @@ Kward has three web tools:
 2. `fetch_content` reads human-readable pages.
 3. `fetch_raw` reads machine-readable files such as JSON, YAML, XML, RSS, OpenAPI specs, or plain text.
 
-A good research flow is:
+For reliable results, ask Kward to find the source, read the important page, and include its URL:
 
 ```text
 Search for the official docs, fetch the relevant page, then answer with the source URL.
 ```
 
-Kward should search first, then fetch important pages before relying on them.
+Kward searches for likely sources first, then reads the important pages before relying on them.
 
 ## Network behavior
 
-Web tools are advertised to the model by default. Queries and fetched URLs are sent over the network to the selected provider or target host. See [Configuration](configuration.md) for the full `web_search` config reference including API key storage and the `provider` config setting.
+Web tools are available by default. Search queries and fetched URLs leave your machine and go to the selected search provider or target host. See [Configuration](configuration.md) for API key storage, provider selection, and the full `web_search` reference.
 
 In automatic mode, provider fallback is:
 

data/doc/workspace-tools.md

@@ -12,14 +12,14 @@ Kward normally chooses these tools itself. You do not need to know their exact n
 
 ## Guardrails
 
-Workspace tools use the active workspace as their boundary. File paths are workspace-relative by default, and file tools are guarded so Kward does not edit arbitrary unread files. Guardrails can be disabled with the `tools.workspace_guardrails` setting — see [Configuration](configuration.md). When disabled, file tools can access paths outside the workspace, but shell commands are unaffected since they already run as your OS user.
+Workspace guardrails limit Kward file tools to the active workspace. File paths are workspace-relative by default, and existing files must be read before Kward can change them. Guardrails can be disabled with the `tools.workspace_guardrails` setting — see [Configuration](configuration.md). When disabled, file tools can access paths outside the workspace. Guardrails are not an operating-system sandbox and do not constrain shell commands; model-requested commands can instead use the separate, opt-in [command sandbox](sandboxing.md).
 
 Important behavior:
 
 - Existing files must be read in the current conversation before `write_file` or `edit_file` can change them.
 - Reads are bounded to avoid pulling very large files into context by accident. Files larger than 256 KB cannot be read or edited. Read output is capped at 50 KB or 2,000 lines, whichever comes first.
 - Edits use exact text replacement, so accidental partial or fuzzy changes fail instead of guessing.
-- Shell commands run as your operating-system user from the workspace. They are powerful and should be treated like commands you run yourself. Command output is capped at 128 KB.
+- With sandboxing off (the default), shell commands run as your operating-system user from the workspace. Enable [command sandboxing](sandboxing.md) to apply an OS boundary to model-requested `run_shell_command` workers. Command output is capped at 128 KB.
 
 ## Reading the workspace
 
@@ -94,7 +94,7 @@ Arguments:
 - `path`: workspace-relative file path.
 - `content`: complete file content.
 
-Use full writes when replacing generated content or creating a new file. For small edits to existing files, Kward should usually prefer `edit_file`.
+Full writes are useful for generated content and new files. For a small change to an existing file, `edit_file` is usually the better fit.
 
 The result includes a unified diff of the changes, capped at 8 KB with a summary of additions and deletions when truncated.
 
@@ -124,7 +124,7 @@ Arguments:
 - `command`: command to run.
 - `timeout_seconds`: optional timeout, default 30 seconds.
 
-Kward uses shell commands for tests, linters, build checks, and simple repository inspection. Command output is bounded at 128 KB and may be compacted before it is sent back into model context, while the original output remains available in the session record.
+Kward uses shell commands for tests, linters, build checks, and simple repository inspection. When configured, the [command sandbox](sandboxing.md) applies to this tool and its descendants. Command output is bounded at 128 KB and may be compacted before it is sent back into model context, while the original output remains available in the session record.
 
 The output format is `Exit status: N` followed by `STDOUT:` and `STDERR:` sections. On timeout, Kward sends SIGTERM then SIGKILL after 0.2 seconds and returns a timeout error. Commands support cooperative cancellation when the session is cancelled.
 

data/examples/plugins/stardate_footer.rb

@@ -0,0 +1,10 @@
+# Displays the current Federation stardate in Kward's interactive footer.
+Kward.plugin do |plugin|
+  plugin.footer do |_ctx|
+    now = Time.now.utc
+    reference = Time.utc(1987, 7, 15)
+    stardate = 41_000 + ((now - reference) / (365.25 * 24 * 60 * 60) * 1_000)
+
+    "Stardate: #{format('%.1f', stardate)}"
+  end
+end