@wardby/cli 0.5.2 → 0.6.0

package/help/errors/native-sandbox-network-unenforced.md

@@ -0,0 +1,22 @@
+---
+id: errors/native-sandbox-network-unenforced
+title: Native worker network isolation not proven
+summary: On Kubernetes, Wardby could not prove a sandbox pod's network isolation in time, so it removed the pod and failed the run.
+audience: operator
+tags: [error, native-agents, sandbox, kubernetes, native_sandbox_network_unenforced]
+appliesTo: ">=0.5.4"
+---
+
+# Native worker network isolation not proven
+
+`native_sandbox_network_unenforced` means that with `NATIVE_SANDBOX_LAUNCHER=kubernetes`, Wardby ran a check inside the worker pod and it did not pass before the time limit. The check requires the gateway to be reachable on port 8790 while the gateway's deny port (8791 by default), an outside address, and the cloud metadata endpoints (`169.254.169.254:80`, the EKS Pod Identity agent `169.254.170.23:80` and `[fd00:ec2::23]:80`, and EC2's IPv6 metadata address `[fd00:ec2::254]:80`) are not. The message says which part failed. The pod is removed and the run never started.
+
+- **"the gateway was unreachable"**: confirm the gateway Deployment has ready pods, the `wardby-native-gateway` Service (or `NATIVE_GATEWAY_SERVICE`) exposes 8790 and 8791, and the gateway's own NetworkPolicy admits `wardby.io/component: native-run` pods on port 8790.
+- **"the gateway's deny port was reachable"** or **"an outside address was reachable"** (or a metadata endpoint): the cluster is not enforcing the per-run NetworkPolicy. Confirm your CNI enforces `NetworkPolicy` (some local clusters need a policy-capable CNI such as Calico), and that no other policy or mesh adds egress for these pods.
+- If the Service lacks port 8791, or the gateway's policy does not admit 8791, unprogrammed pods would look isolated. Keep both in place; the check depends on them.
+- On a slow node the policy can take longer to program. Retrigger the run once, or raise `NATIVE_SANDBOX_ENFORCEMENT_TIMEOUT_MS` (default 30000), before changing anything.
+
+A cluster that does not enforce NetworkPolicy fails every sandbox run this way, by design. Switch the agent back to `control-plane` if you cannot enable enforcement.
+
+See [Run native agents in a sandbox](../native-sandbox.md) and the
+[native sandbox guide](../../docs/native-sandbox.md).

package/help/errors/native-sandbox-requires-catalog.md

@@ -0,0 +1,31 @@
+---
+id: errors/native-sandbox-requires-catalog
+title: Sandbox run has no model catalog entry
+summary: A sandbox-mode run could not start because no model catalog entry was recorded for it.
+audience: operator
+tags: [error, native-agents, sandbox, model-catalog, native_sandbox_requires_catalog]
+appliesTo: ">=0.5.4"
+---
+
+# Sandbox run has no model catalog entry
+
+`native_sandbox_requires_catalog` means a sandbox-mode run reached its worker
+launch without a model catalog entry. The worker prices every model call and
+enforces the run's budget from that entry, so Wardby fails the run before
+starting a worker or spending anything.
+
+Every run records its model's catalog entry when it first starts. A model
+that is unknown, disabled, or has no configured provider fails earlier with
+its own model error, not this one. This error only appears when the process
+executing the run does not use Wardby's catalog-backed model router, for
+example a modified build or an embedding that supplies its own LLM provider.
+
+1. Run sandbox-mode agents on a standard `wardby serve` (or `wardby
+scheduler` / `wardby mcp`) process, which always uses the catalog.
+2. If you supply your own LLM provider, route it through the model catalog,
+   or keep the agent on `control-plane` with `update_agent` or
+   `wardby agent mode <name> control-plane`.
+3. Trigger the run again. A failed run is not retried on its own.
+
+See [Run native agents in a sandbox](../native-sandbox.md) and
+[Models and the model catalog](../models.md).

package/help/errors/native-sandbox-unavailable.md

@@ -0,0 +1,19 @@
+---
+id: errors/native-sandbox-unavailable
+title: Native execution mode unavailable
+summary: A run failed with native_sandbox_unavailable because its agent is in sandbox mode but the server has no native sandbox configured.
+audience: operator
+tags: [error, native-agents, sandbox, native_sandbox_unavailable]
+appliesTo: ">=0.5.4"
+---
+
+# Native execution mode unavailable
+
+`native_sandbox_unavailable` means the agent's `nativeExecutionMode` is `sandbox` but this deployment has no native sandbox configured. Wardby fails the run before any spend rather than running it unisolated.
+
+1. To use the sandbox, set `NATIVE_SANDBOX_LAUNCHER=docker`, `NATIVE_SANDBOX_WORKER_IMAGE`, and `NATIVE_GATEWAY_CONTAINER` on the server that executes runs (`wardby serve` or `wardby scheduler`), start the native gateway, and restart the server.
+2. Otherwise set the agent back to `control-plane` with `update_agent`.
+3. Trigger the run again.
+
+See [Run native agents in a sandbox](../native-sandbox.md) and the
+[native sandbox guide](../../docs/native-sandbox.md).

package/help/errors/native-sandbox-warm-delivery-failed.md

@@ -0,0 +1,21 @@
+---
+id: errors/native-sandbox-warm-delivery-failed
+title: Native sandbox warm worker could not take the run
+summary: A run claimed an idle warm-pool worker, delivering its input failed, and the worker could not be confirmed stopped within 30 seconds, so the run failed instead of cold-launching.
+audience: operator
+tags: [error, native-agents, sandbox, warm-pool, kubernetes, docker, native_sandbox_warm_delivery_failed]
+appliesTo: ">=0.5.4"
+---
+
+# Native sandbox warm worker could not take the run
+
+`native_sandbox_warm_delivery_failed` means a sandbox run claimed an idle worker from the warm pool (`NATIVE_SANDBOX_WARM_POOL_SIZE`), but writing the run's input into that worker failed. The worker may already hold the run's one-time gateway capability, so Wardby removes it and waits up to 30 seconds for it to be confirmed gone before starting a cold worker. This error means it could not be confirmed gone in that time, so the run failed rather than risk two workers holding the same capability. If the worker is confirmed gone, the run cold-launches and you see no error (the log has a `fallback` event).
+
+1. Trigger the run again. Most failures are transient.
+2. Check that the worker is gone: `kubectl get pods -n <namespace> -l wardby.io/pool=warm` (Kubernetes) or `docker ps --all --filter label=io.wardby.pool=warm` (Docker). Pool upkeep removes leftovers, but a stuck pod usually means the node or Docker host is unhealthy.
+3. Look for `native-warm-pool` log entries with `event` `fallback`, and check that the server may exec into pods in the run namespace.
+4. To bypass the pool while you investigate, set `NATIVE_SANDBOX_WARM_POOL_SIZE=0`; every run then cold-starts.
+
+See [Run native agents in a sandbox](../native-sandbox.md) and the
+[native sandbox guide](../../docs/native-sandbox.md#warm-pool). A related error is
+[native_sandbox_capacity](native-sandbox-capacity.md).

package/help/errors/native-sandbox-worker-exited.md

@@ -0,0 +1,20 @@
+---
+id: errors/native-sandbox-worker-exited
+title: Native worker exited without a result
+summary: The sandbox worker container ended without producing a result.
+audience: operator
+tags: [error, native-agents, sandbox, native_sandbox_worker_exited]
+appliesTo: ">=0.5.4"
+---
+
+# Native worker exited without a result
+
+`native_sandbox_worker_exited` means the worker container stopped without reporting a result; the message includes its exit code. Common causes are a tool that exhausted the worker's memory or process limit, or a crash in tool code.
+
+1. Read the exit code in the run's error (`get_run`). Code 137 usually means the memory limit was hit.
+2. If limits are the cause, raise `NATIVE_SANDBOX_MEMORY_MB`, `NATIVE_SANDBOX_PIDS`, or `NATIVE_SANDBOX_CPUS` on the server and restart it.
+3. Otherwise test the agent's tools with `dry_run_tool` and fix the failing code.
+4. Trigger the run again.
+
+See [Run native agents in a sandbox](../native-sandbox.md) and the
+[native sandbox guide](../../docs/native-sandbox.md).

package/help/errors/native-sandbox-worker-lost.md

@@ -0,0 +1,20 @@
+---
+id: errors/native-sandbox-worker-lost
+title: Native worker lost
+summary: The sandbox worker container disappeared and was not relaunched.
+audience: operator
+tags: [error, native-agents, sandbox, native_sandbox_worker_lost]
+appliesTo: ">=0.5.4"
+---
+
+# Native worker lost
+
+`native_sandbox_worker_lost` means the run's worker container (or Kubernetes pod) is gone and left no result, for example because the Docker host restarted or an operator removed the container. Wardby never relaunches a worker, because a relaunch could repeat tool side effects.
+
+1. Check whether the Docker host or daemon restarted around the run's time.
+2. List workers with `docker ps --all --filter label=io.wardby.component=native-worker`; do not remove workers of running runs by hand.
+3. On Kubernetes, check whether the node was drained or preempted, and list pods with `kubectl get pods -n <namespace> -l wardby.io/component=native-run`.
+4. Trigger the run again.
+
+See [Run native agents in a sandbox](../native-sandbox.md) and the
+[native sandbox guide](../../docs/native-sandbox.md).

package/help/errors/native-sandbox-worker-unready.md

@@ -0,0 +1,22 @@
+---
+id: errors/native-sandbox-worker-unready
+title: Native worker pod did not start
+summary: On Kubernetes, the sandbox worker pod did not reach the Running state in time, so the run failed before starting.
+audience: operator
+tags: [error, native-agents, sandbox, kubernetes, native_sandbox_worker_unready]
+appliesTo: ">=0.5.4"
+---
+
+# Native worker pod did not start
+
+`native_sandbox_worker_unready` means that with `NATIVE_SANDBOX_LAUNCHER=kubernetes`, the worker pod stayed pending past the start-up limit (`NATIVE_SANDBOX_READY_TIMEOUT_MS`, default two minutes). Nothing ran.
+
+1. Describe the pod while it waits: `kubectl describe pod -n <namespace> -l wardby.io/component=native-run`. Look at the events for image pull errors, unschedulable reasons, or an unknown runtime class.
+2. Image pull: the cluster must be able to pull `NATIVE_SANDBOX_WORKER_IMAGE` (a registry digest) without interactive credentials; add a pull secret to the namespace's default service account if the registry is private.
+3. Scheduling: raise node capacity or lower `NATIVE_SANDBOX_CPUS` and `NATIVE_SANDBOX_MEMORY_MB`, and check namespace ResourceQuotas.
+4. Runtime class: confirm `NATIVE_SANDBOX_RUNTIME_CLASS` (or `KUBERNETES_RUNTIME_CLASS`) exists on the cluster. On Amazon EKS (`KUBERNETES_PLATFORM=eks`) the `gvisor` RuntimeClass must use handler `runsc` and its scheduling block must match your sandbox nodes (label `wardby.dev/sandbox=gvisor`, taint `sandbox=gvisor:NoSchedule`); a mismatch leaves the pod pending.
+5. On a cold node, such as a first gVisor pod on GKE Autopilot (about two minutes), raise `NATIVE_SANDBOX_READY_TIMEOUT_MS` (1000 to 1800000; about 600000 on Autopilot).
+6. Trigger the run again.
+
+See [Run native agents in a sandbox](../native-sandbox.md) and the
+[native sandbox guide](../../docs/native-sandbox.md).

package/help/errors/secret-broker-body-invalid.md

@@ -0,0 +1,26 @@
+---
+id: errors/secret-broker-body-invalid
+title: Secret broker body invalid
+summary: Body placement needs a JSON-object or form-encoded request body with a matching content-type.
+audience: operator
+tags: [error, secrets, secret_broker_body_invalid]
+appliesTo: ">=0.6.0"
+---
+
+# Secret broker body invalid
+
+`secret_broker_body_invalid` means a secret placed in the request body could not
+be added to the body the tool sent. Body placement needs one of:
+
+- a JSON object body with `content-type: application/json` (or a `+json` type);
+- a form body with `content-type: application/x-www-form-urlencoded`.
+
+The request must have a body, valid JSON that is an object (not an array or a
+scalar), and a matching `content-type` header.
+
+1. Send a body of a supported type and set the `content-type` header to match.
+2. If the API expects the credential elsewhere, change the placement with
+   `set_secret_broker` to `header` or `query`.
+
+See [Brokered secrets](../brokered-secrets.md) and the
+[secrets guide](../../docs/tool-secrets.md).

package/help/errors/secret-broker-changed.md

@@ -0,0 +1,20 @@
+---
+id: errors/secret-broker-changed
+title: Brokering changed since the link was created
+summary: A browser link to remove brokering was created before the secret's broker config changed, so it no longer applies.
+audience: operator
+tags: [error, secrets, secret_broker_changed]
+appliesTo: ">=0.6.0"
+---
+
+# Brokering changed since the link was created
+
+`secret_broker_changed` means the browser link for removing brokering was minted
+for a broker config that has since changed or been removed. A link only ever
+removes the exact config it was created for.
+
+1. Call `set_secret_broker` with `broker: null` again to get a new link.
+2. Check the config shown on the new page before confirming removal.
+
+See [Brokered secrets](../brokered-secrets.md) and the
+[secrets guide](../../docs/tool-secrets.md).

package/help/errors/secret-broker-config-invalid.md

@@ -0,0 +1,30 @@
+---
+id: errors/secret-broker-config-invalid
+title: Secret broker config invalid
+summary: A broker config failed validation: hosts, path prefixes, or placement are malformed.
+audience: operator
+tags: [error, secrets, secret_broker_config_invalid]
+appliesTo: ">=0.6.0"
+---
+
+# Secret broker config invalid
+
+`secret_broker_config_invalid` means the broker config passed to `create_secret`,
+`set_secret_broker`, or the browser form did not validate. The message lists
+each problem. Common causes:
+
+- `hosts` is empty, has more than 20 entries, or contains a scheme, port,
+  wildcard, or IP address (including short forms such as `127.1`), or a label
+  ending in `-`; use exact hostnames such as `api.example.com`;
+- a `pathPrefixes` entry does not start with `/`, or contains `?`, `#`, a
+  backslash, a control character, `%2F`, or `%5C`;
+- a header `format` does not contain `{value}` exactly once or contains a line
+  break, or the header name is not allowed (`Host`, `Content-Length` and similar);
+- an AWS `region` or `service` is malformed;
+- the config or its placement has fields it does not define.
+
+1. Fix the fields named in the message and retry.
+2. The config shape is `{ hosts, pathPrefixes?, placement }`.
+
+See [Brokered secrets](../brokered-secrets.md) and the
+[secrets guide](../../docs/tool-secrets.md).

package/help/errors/secret-broker-conflict.md

@@ -0,0 +1,27 @@
+---
+id: errors/secret-broker-conflict
+title: Secret broker placement conflict
+summary: The request already sets the header, parameter, or field a broker places, two brokers collide, or more than one SigV4 secret was named.
+audience: operator
+tags: [error, secrets, secret_broker_conflict]
+appliesTo: ">=0.6.0"
+---
+
+# Secret broker placement conflict
+
+`secret_broker_conflict` means the request would set the same spot twice. A
+brokered value is never merged with or overridden by one from the tool. It
+occurs when:
+
+- the tool sets the header, query parameter, or body field that a brokered
+  secret places (for SigV4: `authorization`, `x-amz-date`,
+  `x-amz-security-token`, or `x-amz-content-sha256`);
+- two named secrets place the same header, parameter, or field;
+- more than one AWS SigV4 secret is named in one request.
+
+1. Remove the conflicting header, parameter, or field from the tool's request.
+2. Send secrets that place the same spot in separate requests.
+3. Name at most one SigV4 secret per request.
+
+See [Brokered secrets](../brokered-secrets.md) and the
+[secrets guide](../../docs/tool-secrets.md).

package/help/errors/secret-broker-destination-denied.md

@@ -0,0 +1,28 @@
+---
+id: errors/secret-broker-destination-denied
+title: Secret broker destination denied
+summary: A fetch with a brokered secret targeted a URL that is not https, uses a non-default port, or is outside the allowed hosts or path prefixes.
+audience: operator
+tags: [error, secrets, secret_broker_destination_denied]
+appliesTo: ">=0.6.0"
+---
+
+# Secret broker destination denied
+
+`secret_broker_destination_denied` means a brokered secret may not be sent to
+the requested URL. The message says which check failed:
+
+- the URL is not `https`, or names a port other than the default;
+- the host is not in the secret's `hosts` (exact match, no wildcards);
+- the path does not start with any of the secret's `pathPrefixes`, or, for a
+  secret with `pathPrefixes`, contains an encoded slash or backslash (`%2F`,
+  `%5C`).
+
+1. Correct the URL in the tool.
+2. If the destination is intended, the secret's owner updates the config with
+   `set_secret_broker`, adding the host or path prefix.
+3. Make sure the tool attachment's `allowedHosts` also lists the host; a host
+   missing there is refused by the normal fetch policy.
+
+See [Brokered secrets](../brokered-secrets.md) and the
+[secrets guide](../../docs/tool-secrets.md).

package/help/errors/secret-broker-value-invalid.md

@@ -0,0 +1,28 @@
+---
+id: errors/secret-broker-value-invalid
+title: Secret broker value invalid
+summary: A brokered value is shorter than 6 characters, or an AWS SigV4 secret is not the expected JSON.
+audience: operator
+tags: [error, secrets, secret_broker_value_invalid]
+appliesTo: ">=0.6.0"
+---
+
+# Secret broker value invalid
+
+`secret_broker_value_invalid` means the stored value cannot be brokered under its
+config. It is returned when saving a config and when a tool uses the secret.
+
+- A brokered value must be at least 6 characters.
+- An AWS SigV4 secret's value must be JSON
+  `{"accessKeyId": "...", "secretAccessKey": "...", "sessionToken": "..."}` with
+  no other keys. `sessionToken` is optional; the secret access key and session
+  token must each be at least 6 characters.
+
+1. Re-enter the value with `create_secret` using the same name; it rotates the
+   value in place. Leave out `broker`: a rotation without one keeps the
+   existing broker config. In the browser form, correct the value and submit
+   the same link again.
+2. For SigV4, store the credentials as that JSON object.
+
+See [Brokered secrets](../brokered-secrets.md) and the
+[secrets guide](../../docs/tool-secrets.md).

package/help/errors/secret-brokered.md

@@ -0,0 +1,24 @@
+---
+id: errors/secret-brokered
+title: Secret is brokered and cannot be read
+summary: A tool called secrets.get on a brokered secret; brokered secrets are only sent with fetch(url, { secrets }).
+audience: operator
+tags: [error, secrets, secret_brokered]
+appliesTo: ">=0.6.0"
+---
+
+# Secret is brokered and cannot be read
+
+`secret_brokered` means a tool called `secrets.get(name)` on a secret that is
+brokered. A brokered secret never exposes its value to tool code.
+
+1. Update the tool to send the secret with
+   `fetch(url, { secrets: ["NAME"] })`; the host places the value in the request.
+2. Or, if the tool really must read the value, have the secret owner remove
+   brokering with `set_secret_broker` and `broker: null`, confirmed in the
+   browser. This makes the value readable by every tool granted it.
+3. `attach_tool` and `set_secret_broker` warn when a granted tool calls
+   `secrets.get`; that scan is best-effort.
+
+See [Brokered secrets](../brokered-secrets.md) and the
+[secrets guide](../../docs/tool-secrets.md).

package/help/errors/secret-not-brokered.md

@@ -0,0 +1,25 @@
+---
+id: errors/secret-not-brokered
+title: Secret is not brokered
+summary: A fetch named a secret that is readable, not attached to the agent, or not granted to the tool.
+audience: operator
+tags: [error, secrets, secret_not_brokered]
+appliesTo: ">=0.6.0"
+---
+
+# Secret is not brokered
+
+`secret_not_brokered` means `fetch(url, { secrets: [...] })` named a secret that
+is not a brokered secret available to this tool: it is readable, it is not
+attached to the agent, it is not listed in the attachment's `allowedSecrets`, or
+the request named more than 8 secrets.
+
+1. Check the name matches the alias the secret is attached under
+   (`attach_secret`) and appears in the tool attachment's `allowedSecrets`.
+2. To send the secret through `fetch`, make it brokered with
+   `set_secret_broker { name, broker }`.
+3. If the secret is meant to stay readable, read it with `secrets.get(name)`
+   instead of naming it in `fetch`.
+
+See [Brokered secrets](../brokered-secrets.md) and the
+[secrets guide](../../docs/tool-secrets.md).

package/help/errors/slack-auth-failed.md

@@ -0,0 +1,48 @@
+---
+id: errors/slack-auth-failed
+title: Bot authentication failed — invalid or revoked token
+summary: wardby's Slack bot token is invalid, revoked, disabled, or missing a required scope, so delivery to every linked channel is paused.
+audience: operator
+tags: [error, notifications, auth, authentication, invalid_auth, token_revoked, missing_scope]
+appliesTo: ">=0.6.0"
+---
+
+# Bot authentication failed — invalid or revoked token
+
+Slack returned `invalid_auth`, `token_revoked`, `account_inactive`,
+`missing_scope`, or `not_authed` for `WARDBY_SLACK_BOT_TOKEN`. This is
+different from a single channel being unreachable: it means the token
+itself no longer works, so wardby pauses delivery to **every** linked
+channel rather than attempting and failing each one. Deliveries already
+queued stay pending — nothing is lost — and wardby automatically re-checks
+the token every five minutes with Slack's `auth.test`, resuming delivery as
+soon as it succeeds.
+
+A **missing scope** (`missing_scope`) does not fix itself this way:
+`auth.test` needs no scope, so the re-check succeeds, the next delivery fails
+again, and delivery pauses again. Add the scope and reinstall the app (steps
+1–2 below).
+
+The same errors while linking a channel refuse the link, except
+`missing_scope` from a missing `channels:read`/`groups:read`, which only
+skips validating the channel id.
+
+wardby logs this once per pause, not on every retry.
+
+## What to do
+
+1. In Slack, check the app's **OAuth & Permissions** page: is the bot
+   installed, and does it still have `chat:write` at minimum?
+2. If the app's scopes changed (for example after editing
+   [`app-manifest.yaml`](../../deploy/slack/app-manifest.yaml)), reinstall
+   the app to the workspace to apply them.
+3. If the token was revoked or the app was uninstalled, reinstall it and
+   copy a fresh Bot User OAuth Token.
+4. If Slack issued a new token, set it as `WARDBY_SLACK_BOT_TOKEN` and
+   restart wardby; the startup log line `chat notifications acting as`
+   confirms it. If the token is unchanged (a scope added and the app
+   reinstalled), no restart is needed: pending deliveries go out after the
+   next check.
+
+See [Send workflow updates to Slack](../../docs/slack-notifications.md) for
+the full guide.

package/help/errors/slack-channel-unreachable.md

@@ -0,0 +1,39 @@
+---
+id: errors/slack-channel-unreachable
+title: Channel unreachable — bot not invited or archived
+summary: wardby's bot can no longer post to a linked Slack channel — it was removed, archived, or never invited — and that channel's pending deliveries have failed.
+audience: operator
+tags: [error, notifications, channel, channel-error, not_in_channel, channel_not_found, is_archived]
+appliesTo: ">=0.6.0"
+---
+
+# Channel unreachable — bot not invited or archived
+
+Slack returned `channel_not_found`, `not_in_channel`, or `is_archived` when
+wardby tried to post or update a message. This means the bot genuinely
+cannot write to that channel right now — the channel was deleted or
+archived, or (most commonly) the bot was never invited to a private
+channel.
+
+wardby fails that channel's pending deliveries immediately rather than
+retrying forever, and stamps the error on every `NotificationChannel` link
+pointing at it. `list_notification_channels` shows it in `lastError` until
+you fix it.
+
+## What to do
+
+1. In Slack, confirm the channel still exists and isn't archived.
+2. If it's private, invite the bot: `/invite @wardby` (or whatever you named
+   the app) in that channel.
+3. Confirm it worked with `test_notification_channel` — it posts "✅ wardby
+   is connected to this channel."
+4. New events deliver as soon as the bot can post there again. Deliveries
+   that already failed are not resent. To clear `lastError`, re-link the
+   channel with `link_notification_channel` using the same arguments as
+   before (a successful `test_notification_channel` in step 3 also clears it).
+
+If the channel is gone for good, remove the link with
+`unlink_notification_channel` instead.
+
+See [Send workflow updates to Slack](../../docs/slack-notifications.md) for
+the full guide.

package/help/errors/slack-not-configured.md

@@ -0,0 +1,33 @@
+---
+id: errors/slack-not-configured
+title: Notification bot token not configured
+summary: link_notification_channel and test_notification_channel are refused because wardby has no Slack bot token configured.
+audience: operator
+tags: [error, notifications, configuration, config, setup, WARDBY_SLACK_BOT_TOKEN]
+appliesTo: ">=0.6.0"
+---
+
+# Notification bot token not configured
+
+`link_notification_channel` and `test_notification_channel` are refused when
+the wardby server has no `WARDBY_SLACK_BOT_TOKEN` set. Without it, Slack workflow notifications are
+entirely disabled: the notification dispatcher does not start, and any event
+that would otherwise post to Slack is skipped — none are queued or
+backfilled once you do configure it.
+
+`list_notification_channels` and `unlink_notification_channel` still work,
+so you can see and remove links created earlier, but nothing is delivered to
+them while Slack is unconfigured.
+
+## What to do
+
+1. Create the Slack app from
+   [`deploy/slack/app-manifest.yaml`](../../deploy/slack/app-manifest.yaml)
+   and install it to your workspace.
+2. Copy the Bot User OAuth Token (`xoxb-…`) and set
+   `WARDBY_SLACK_BOT_TOKEN`, stored like any other provider credential.
+3. Restart wardby. The startup log line `chat notifications acting as`
+   confirms which Slack workspace and bot it authenticated as.
+
+See [Send workflow updates to Slack](../../docs/slack-notifications.md) for
+the full setup.

package/help/getting-started.md

@@ -30,6 +30,11 @@ Claude Code. Run `wardby doctor` afterwards to verify the local installation.
   Review that branch with
   `trigger_agent {"agentId": "<reviewer id>", "review": {"branch": "wardby/run-<run id>"}}`.
   You need Docker and an OpenAI key (Codex) or an Anthropic key (Claude Code).
+  For a Python project (a root `pyproject.toml`, `setup.py`, `setup.cfg`,
+  `Pipfile` or `requirements*.txt`), the builder gets a Node + Python 3.12
+  workspace and can run `pytest`. Quickstart also offers the packages the
+  repository declares as the builder's package allowlist, so it can install
+  them (`--allow-repo-packages` in a non-interactive run).
   See [Use local git repositories](local-repositories.md).
 - **B. A coding agent that opens GitHub pull requests.** Do A first. Then
   install a GitHub App on the repository (Contents and Pull requests: read and
@@ -42,6 +47,19 @@ Claude Code. Run `wardby doctor` afterwards to verify the local installation.
   with webhooks, link a native agent to the repository with the `pull_request`
   trigger, and open a pull request. See [Code review agents](code-review-agents.md).
 
+- **D. Another language (Go, Java, Rust…).** Do A, then build an image with
+  that toolchain and set the builder's `codingProfile.workerImageRef`. Ask your
+  assistant "Help me build a Wardby worker image for Go"; it follows
+  [Build a custom worker image](build-worker-image.md).
+
+The quickstart ends with a menu of next steps to ask your assistant: run the
+builder and reviewer, allow more packages, build a worker image, schedule an
+agent, set up an architecture reviewer and keeper (see
+[Set up an architecture agent](architecture-agent.md), which has a
+local-repository variant), or plan a GKE deployment
+([Deploy on GKE](deploy-gke.md)). Each names the help article the assistant
+follows.
+
 The full step-by-step guide is "Choose what to set up next" in
 [`docs/getting-started.md`](../docs/getting-started.md).
 

package/help/github.md

@@ -3,7 +3,7 @@ id: github-integration
 title: Connect GitHub repositories
 summary: Authorize repository access and configure Wardby coding or review agents through a scoped GitHub App.
 audience: operator
-tags: [github, repositories, coding-agents, code-review]
+tags: [github, repositories, coding-agents, code-review, WARDBY_GITHUB_ALLOWED_ACCOUNTS]
 appliesTo: >=0.2.1
 ---
 
@@ -27,6 +27,17 @@ Set the App's credentials as `GITHUB_APP_ID` and `GITHUB_APP_PRIVATE_KEY` on
 the wardby server. Without them, a coding run on a GitHub repository fails with
 [`vcs_github_not_configured`](errors/vcs-github-not-configured.md).
 
+From Wardby 0.6.0, wardby serves only trusted GitHub accounts through the App:
+the App's owner, plus any accounts listed in `WARDBY_GITHUB_ALLOWED_ACCOUNTS`
+(comma-separated logins). Other accounts' events are ignored and their
+repositories are refused with `github_account_not_allowed` (help article
+`errors/github-account-not-allowed`), including existing links and scheduled
+runs after an upgrade. wardby removes the App when another account installs it
+or changes its repository selection; remove installations that already exist
+on other accounts by hand (App settings, **Install App**). After transferring
+the App or renaming its owner, list the new owner in the variable or restart
+wardby.
+
 No GitHub App is needed for a git repository on the wardby host. See
 [Use local git repositories](local-repositories.md).
 
@@ -62,4 +73,10 @@ opened. See [Automatic review fix rounds](review-fix-rounds.md).
 finishes, and gates its ability to approve on CI passing. See
 [Review after CI (`waitForCi`)](code-review-agents.md#review-after-ci-waitforci).
 
+With Wardby 0.6.0 or later, a `pull_request` reviewer also holds its review, with or without
+`waitForCi`, until the pull request's own delegating run finishes, when its
+opening coding run was delegated by a lead agent. See [Reviewing a pull
+request a delegated run
+opened](code-review-agents.md#reviewing-a-pull-request-a-delegated-run-opened).
+
 For Jira Cloud instead of GitHub, see [Run Jira agents](jira.md).

package/help/identity-and-access.md

@@ -21,7 +21,7 @@ audience, and the granted Wardby scopes in `scope` or `scp`.
 
 Scopes authorize normal operations such as managing agents, runs, tools,
 datastores, secrets, webhooks, budgets, packages, services, memory, and
-models. Five sensitive permissions have an additional role requirement:
+models. Six sensitive permissions have an additional role requirement:
 
 - `agents:admin` requires the Wardby `admin` role.
 - `packages:approve` requires the `admin` or `package-approver` role.
@@ -31,6 +31,10 @@ models. Five sensitive permissions have an additional role requirement:
 - `models:admin` requires the `admin` or `model-manager` role. It adds,
   overrides, disables, and resets model catalog entries; see
   [Models and pricing](models.md).
+- `power:manage` requires the `admin` role. It reads low-power state and
+  sleeps the coding proxy and native gateway now (`power_status`,
+  `power_sleep`); see
+  [Low-power mode](../docs/getting-started-gke.md#low-power-mode).
 
 Map roles only from an IdP claim that users cannot self-assign. Removing a
 role affects the next token the caller receives.