@wardby/cli 0.5.3 → 0.7.0

package/help/errors/secret-in-value.md

@@ -0,0 +1,69 @@
+---
+id: errors/secret-in-value
+title: A value was not stored because it contains a secret (secret_in_value)
+summary: A datastore or agent memory write was refused because the value contains the value of a secret attached to the agent; store the secret's name and read it when needed.
+audience: operator
+tags: [error, secrets, datastore, memory, secret_in_value, secret_check_unavailable, datastore set, memory set]
+appliesTo: ">=0.7.0"
+---
+
+# A value was not stored because it contains a secret (secret_in_value)
+
+`secret_in_value` means a write to a datastore or agent memory contained the
+value of a secret attached to the agent, in the value or in the key. The write
+came from a tool's `datastore.set` (or a shared datastore's `set`), from the
+`memory_set` tool, from the `datastore_set` or `set_agent_memory` MCP tools, or
+from a bundle import. The error names the secret. Nothing was stored.
+
+Secret values are never stored in datastores or agent memory, because anything
+stored there can be read back by other tools and later runs that were never
+given the secret, and can be printed.
+
+## What to do
+
+Store the secret's **name**, not its value, and read the secret when you need it:
+
+- `secrets.get("NAME")` in a tool that is allowed to read the secret, or
+- `fetch(url, { secrets: ["NAME"] })` for a brokered secret.
+
+See [Secrets and tools](../../docs/tool-secrets.md#secret-values-are-never-stored).
+
+## `secret_check_unavailable`
+
+The agent's secrets could not be read, so the value could not be checked and was
+not stored. Try the write again. If it keeps happening, check the database
+connection and the secret encryption configuration on the server.
+
+## Bundle imports
+
+A seeded datastore entry in an imported bundle, per-agent or shared, whose key
+or value contains an attached secret's value is skipped, and the import reports
+a warning that names the secret (the entry's key is withheld from the warning).
+The rest of the bundle is still imported.
+
+## Also masked
+
+Secret values are also kept out of other output:
+
+- A native run's final text and error have attached secret values replaced with
+  `[REDACTED]`.
+- The task text of a `delegate_to_*` call has the delegating agent's attached
+  secret values replaced with `[REDACTED]` before the sub-agent's run is created.
+- Comments, reviews, and Jira posts made through built-in tools have attached
+  secret values replaced with `[REDACTED]`.
+- If the secrets cannot be read when a run ends, both its stored final text and
+  its stored error are
+  `[withheld: this text could not be checked for secret values]`.
+- If the secrets cannot be read when a posting tool or a `delegate_to_*` call
+  runs, the tool returns `secret_check_unavailable` and posts nothing or creates
+  no sub-agent run.
+
+## Limits
+
+Matching is by exact value, including its JSON-escaped forms and, for brokered
+secrets, the encoded forms that the broker scrubs. Values shorter than 6
+characters are not matched. A value that is split, re-encoded, or otherwise
+transformed is not detected. Values stored before this check existed are not
+scanned.
+
+See also [Brokered secrets](../brokered-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/errors/target-merge.md

@@ -0,0 +1,40 @@
+---
+id: errors/target-merge
+title: Target branch could not be merged
+summary: A follow-up run could not fetch or merge its pull request's target branch, so it stopped before the agent started.
+audience: operator
+tags: [error, coding-agents, vcs, merge-conflict, target-branch, pull-requests]
+appliesTo: ">=0.7.0"
+---
+
+# Target branch could not be merged
+
+Before a follow-up run on a wardby pull request starts its agent, wardby
+merges the branch the pull request currently targets into the workspace (see
+[Fix merge conflicts on a wardby pull request](../fix-merge-conflicts.md)).
+A run stops with failure category `target_merge` (error
+`vcs_target_merge_failed`) when that could not be done:
+
+- the target branch could not be fetched from the repository (it was deleted,
+  or the fetch failed);
+- the pull request's branch and its target share no history wardby could
+  find: the branches are unrelated, or their common commit is more than about
+  5,000 commits back;
+- the merge itself failed for a reason other than a content conflict (content
+  conflicts are handed to the agent, not failed);
+- the git on the machine that runs wardby is older than 2.38, which does not
+  support the `merge-tree --write-tree` form the merge uses.
+
+Nothing is pushed and no agent work is lost, since the agent had not started.
+
+## What to do
+
+- Check the pull request's base branch on GitHub. Retarget it if the branch
+  it names no longer exists or is not the one it should merge into.
+- For unrelated histories, merge the branches by hand once; later follow-ups
+  then find the merge base.
+- A transient fetch failure succeeds on the next request.
+- Upgrade the machine's git to 2.38 or newer (`git --version` shows it).
+
+Related: [Conflict markers remain](merge-conflict.md),
+[Continuation's pull request is no longer open](continuation-closed.md).

package/help/fix-merge-conflicts.md

@@ -0,0 +1,73 @@
+---
+id: fix-merge-conflicts
+title: Fix merge conflicts on a wardby pull request
+summary: Follow-up runs merge the PR's current target branch first and resolve its conflicts; ask to update a PR that fell behind.
+audience: operator
+tags: [github, pull-requests, merge-conflict, update-pr, target-branch, continuation, review_fix]
+appliesTo: ">=0.7.0"
+---
+
+# Fix merge conflicts on a wardby pull request
+
+Every follow-up run on a pull request a wardby coding run opened (a mention on
+the PR, a delegated `continuePriorRun`, a review fix round) first brings the
+branch up to date with the branch the pull request **currently** targets:
+
+1. Before the agent starts, wardby asks GitHub for the pull request's base
+   branch. A pull request retargeted since it opened (a stacked PR whose
+   parent merged, a release branch) merges its new base, not the one the
+   first run used.
+2. wardby fetches that branch from the same repository (never a fork) and
+   merges it into the workspace, in trusted code, before the agent sees it.
+   A branch that already contains its target is left exactly as it was.
+3. **No conflicts:** the agent works on the updated branch as usual.
+   **Conflicts:** the agent's task lists the conflicted files and which side
+   is which (this pull request's branch, then the target). It is asked to
+   resolve every conflict keeping both sides' intent, fix the tests the
+   combination broke, and run the repository's checks.
+4. The push is one merge commit authored by Wardby, with the pull request's
+   head and the target as its parents. It is pushed even when the agent
+   changed nothing else, so asking a wardby agent on the pull request to
+   "update this PR" or "fix the merge conflicts" is enough.
+5. The run's status comment on the pull request says what was merged, for
+   example "Merged `main` @ `1a2b3c4` into this branch; resolved conflicts
+   in 2 files."
+
+## Ask to update this PR
+
+Mention the wardby agent on the pull request with "please update this PR" or
+"please fix the merge conflicts". The follow-up merges the target branch,
+resolves any conflicts, and pushes the merge commit.
+
+## What is checked
+
+- **Conflict markers.** A file the merge left conflicted that still holds
+  conflict markers when the run finishes stops the push: the run fails with
+  category `merge_conflict` and nothing is pushed — see
+  [Conflict markers remain](errors/merge-conflict.md).
+- **Protected paths and size limits** apply to the agent's own changes,
+  measured against the automatic merge: a change the target branch made to a
+  protected path is merged as it is, while resolving a conflict in a protected
+  path, or reverting the target's change to one, is an edit by the agent and
+  is refused as usual (see [Protected path](errors/protected-path.md)).
+- **Someone else pushed meanwhile.** The push is still a fast-forward of the
+  head the run started from, so a push by anyone else in the meantime fails
+  the run the same way it did before, with nothing pushed.
+- **No merge base.** A target branch that cannot be fetched, or shares no
+  history with the pull request, fails the run before the agent starts — see
+  [Target branch could not be merged](errors/target-merge.md).
+
+## Limits
+
+- Local repositories (`local:`) have no pull requests, so a continuation there
+  is not merged with anything.
+- A conflicted file with no markers (a binary file, or one deleted on one side
+  and changed on the other) holds one side's version, or the changed version.
+  The agent is told to check it, but nothing stops it from leaving that version
+  as it is.
+- A conflict in a protected path cannot be resolved by the agent: resolving it
+  is an edit to that path, which is refused. Resolve that file by hand and push.
+
+Related: [Run GitHub code-review agents](code-review-agents.md),
+[Automatic review fix rounds](review-fix-rounds.md),
+[Related pull requests across repositories](related-pull-requests.md).

package/help/getting-started.md

@@ -47,11 +47,10 @@ 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 with Codex, then build a
-  worker image with that toolchain on the base image `wardby doctor` prints,
-  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). Codex agents only.
+- **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

package/help/github-app-setup.md

@@ -0,0 +1,132 @@
+---
+id: github-app-setup
+title: Set up the GitHub App
+summary: Step by step, create Wardby's GitHub App, choose its events and permissions, install it on your repositories, and give the server its credentials.
+audience: operator
+tags: [github, github-app, setup, permissions, webhooks, GITHUB_APP_ID, GITHUB_APP_WEBHOOK_SECRET, link_host_account]
+appliesTo: ">=0.2.1"
+---
+
+# Set up the GitHub App
+
+Wardby reaches GitHub through a GitHub App that you create and own. Each Wardby
+server needs its own App, because an App has exactly one webhook URL. For an
+overview of how Wardby uses the App, see
+[Connect GitHub repositories](github.md).
+
+Decide first what the App is for:
+
+- **Coding agents only**, triggered with `trigger_agent` or on a schedule:
+  GitHub never calls your server, so you can skip the webhook (step 2) and the
+  events (step 4).
+- **Review agents, `@`-mentions, review fix rounds, merge watchers, or
+  marking pull requests ready**: these start from GitHub webhooks, so your
+  server must be reachable over public HTTPS at the host of
+  `MCP_CANONICAL_URI`.
+
+## 1. Create the App
+
+In the GitHub settings of the user or organization that will own it, open
+**Developer settings**, then **GitHub Apps**, then **New GitHub App**. Give
+it a name and a homepage URL. The owner matters: Wardby always serves the
+App's owner, and other accounts only when you list them (step 7).
+
+## 2. Webhook
+
+- **Webhook URL**: `https://<your-host>/hosts/github/events`, where
+  `<your-host>` is the host of `MCP_CANONICAL_URI`. Requests naming any other
+  host are rejected.
+- **Webhook secret**: a random value, for example from `openssl rand -hex 32`.
+  The same value goes into `GITHUB_APP_WEBHOOK_SECRET` (step 7). Until that
+  variable is set, the endpoint answers 404.
+
+For coding agents only, untick **Active** under Webhook instead.
+
+## 3. Repository permissions
+
+| Permission      | Access                                             |
+| --------------- | -------------------------------------------------- |
+| Contents        | Read and write (Read for an App that only reviews) |
+| Pull requests   | Read and write                                     |
+| Checks          | Read and write                                     |
+| Issues          | Read and write                                     |
+| Commit statuses | Read (optional)                                    |
+
+- **Contents: Read and write** lets coding agents push a branch for each pull
+  request. A review-only App can have Read, but its reviewers then can't
+  resolve their own fixed review threads.
+- **Checks** carries the `wardby review` and `wardby merge order` checks.
+- **Issues** covers mentions in issues and the labels used by
+  [automatic review fix rounds](review-fix-rounds.md).
+- **Commit statuses** lets reviewers see CI that reports commit statuses
+  rather than check runs.
+
+If you change permissions later, every installation must accept the new set
+before its webhooks resume.
+
+## 4. Events
+
+Tick each one; every event is its own checkbox.
+
+| Event                       | Needed for                                                                                                  |
+| --------------------------- | ----------------------------------------------------------------------------------------------------------- |
+| Pull request                | `pull_request` reviewers and `review_fix`                                                                   |
+| Check run                   | Re-running the review check                                                                                 |
+| Check suite                 | Reviews that wait for CI (`waitForCi`), and `markReadyWhenPassing` marking a draft ready once CI goes green |
+| Issue comment               | `@`-mentions in issue and pull request comments                                                             |
+| Issues                      | `@`-mentions in a newly opened or edited issue                                                              |
+| Pull request review comment | `@`-mentions in inline review threads                                                                       |
+| Push                        | The `push` trigger (merge-watcher agents)                                                                   |
+
+Missing an event fails quietly: the matching trigger never starts. A common
+case is leaving out Check suite, so drafts that should be marked ready stay
+drafts.
+
+## 5. Account linking
+
+`link_host_account` lets a Wardby user prove which GitHub account they are, so
+Wardby can check their repository access. In the App's **General** settings:
+
+- **Callback URL**: `https://<your-host>/hosts/github/user-callback`.
+- Leave **Request user authorization (OAuth) during installation** unticked.
+- Note the **Client ID** (not the numeric App ID) and generate a **client
+  secret**.
+
+## 6. Private key and installation
+
+1. Save the App, note its numeric **App ID**, and generate a **private key**
+   (a `.pem` file).
+2. Under **Install App**, install it on your account or organization and
+   choose **Only select repositories**: pick only the repositories your agents
+   may use.
+
+## 7. Configure Wardby
+
+| Variable                         | Value                                                                       |
+| -------------------------------- | --------------------------------------------------------------------------- |
+| `GITHUB_APP_ID`                  | The numeric App ID                                                          |
+| `GITHUB_APP_PRIVATE_KEY`         | The contents of the `.pem` file                                             |
+| `GITHUB_APP_WEBHOOK_SECRET`      | The webhook secret from step 2                                              |
+| `GITHUB_APP_CLIENT_ID`           | The Client ID from step 5 (set together with the client secret, or neither) |
+| `GITHUB_APP_CLIENT_SECRET`       | The client secret from step 5                                               |
+| `WARDBY_GITHUB_ALLOWED_ACCOUNTS` | Optional: accounts other than the App's owner to serve, comma-separated     |
+| `WARDBY_MENTION_EXPLANATIONS`    | Optional: `false` = no reply saying why a mention started nothing           |
+
+Restart the server after setting them. Without `GITHUB_APP_ID` and
+`GITHUB_APP_PRIVATE_KEY`, coding runs on GitHub repositories fail with
+[`vcs_github_not_configured`](errors/vcs-github-not-configured.md).
+Repositories of accounts that aren't served are refused with
+[`github_account_not_allowed`](errors/github-account-not-allowed.md).
+
+## 8. Check it
+
+- Run `link_host_account` and finish the GitHub sign-in it opens.
+- Link an agent with `link_repository`, or create a coding agent on the
+  repository (see [builder agents](builder-agent.md) and
+  [Run GitHub code-review agents](code-review-agents.md)).
+- In the App's **Advanced** settings, **Recent Deliveries** should show your
+  server answering webhooks with a 2xx status. A signature failure there means
+  the webhook secret and `GITHUB_APP_WEBHOOK_SECRET` differ.
+
+The full reference, including rollout order on Kubernetes deployments, is
+[Registering the GitHub App](../docs/code-review-agents.md#registering-the-github-app).

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
 ---
 
@@ -23,10 +23,23 @@ Workers do not receive the GitHub App private key. A trusted component validates
 the changes, pushes a controlled branch, and opens at most one draft pull
 request. Wardby does not auto-merge coding-agent output.
 
+To create and install the App, follow [Set up the GitHub App](github-app-setup.md).
+
 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).
 
@@ -58,8 +71,34 @@ The `review_fix` trigger lets Wardby fix its own review's findings
 automatically, up to a round cap, on pull requests its own coding runs
 opened. See [Automatic review fix rounds](review-fix-rounds.md).
 
+When a mention run finishes without opening a pull request or failing a
+sub-run and its reply is longer than about 2,000 characters (for example a
+plan), the status comment does not cut the reply short. It says "✅ Finished
+without opening a pull request. The full reply follows in the next
+comment(s)." (in a review thread: "...follows in this pull request's
+conversation."), and the reply is posted in up to four numbered comments
+("Reply, part i of n") of about 60,000 characters each, split at headings,
+paragraphs or lines. Anything beyond four parts is cut with a note; the full
+text stays on the run (`get_run`, `finalText`). `@`-mentions in the reply are
+defused. Each part is posted once; if one cannot be posted, the rest are
+skipped. Shorter replies, and runs that opened a pull request or had a failed
+sub-run, keep the status comment that quotes up to 2,000 characters.
+
 `waitForCi` holds a reviewer's review until that pull request's own CI
 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).
+
+With Wardby 0.7.0 or later, `markReadyWhenPassing` on the write link of the
+agent the event triggers (a builder, or a lead that delegates to a coding
+builder) has Wardby mark the draft pull requests it opens here ready for review
+on its own, once every Wardby reviewer check and CI on the head are green
+and, for a merge-ordered set, the steps it depends on have merged. See [Mark
+ready when passing](code-review-agents.md#mark-ready-when-passing).
+
 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.
@@ -42,3 +46,5 @@ that request every advertised scope otherwise fail with `invalid_scope`.
 Read [`docs/getting-started-identity-provider.md`](../docs/getting-started-identity-provider.md)
 for the required claims, scope list, role mapping, provider examples, and
 client registration.
+
+From Wardby 0.7.0, to share an agent with one person or with everyone signed in, see the help article `sharing-agents`.

package/help/jira.md

@@ -65,13 +65,24 @@ the `Jira acting as` startup line to confirm the account.
 Beyond reading, searching and commenting, linked agents get
 `jira_list_transitions`, `jira_transition`, `jira_update_fields`,
 `jira_link_issues`, and `jira_get_property` / `jira_set_property` for
-per-issue state, plus `jira_create_issue` and `jira_read_attachment`. Each authorizes against the issue's own project and the
-agent's live link. Properties are not allowlisted: any `write` link can set
-them and any link can read them. They are stored as `wardby.<agentId>.<name>`,
-and anyone with Jira API access to the issue can read or overwrite them, so
-never store secrets there. Run status comments include an `Agent spend: $...`
-line. To see what work on a card, epic, or project cost, read
+per-issue state, plus `jira_create_issue` and `jira_read_attachment`. Each
+authorizes against the issue's own project and the agent's live link.
+Properties are not allowlisted: any `write` link can set them and any link can
+read them. They are stored as `wardby.<agentId>.<name>`, and anyone with Jira
+API access to the issue can read or overwrite them, so never store secrets
+there. Run status comments include an `Agent spend: $...` line. To see what
+work on a card, epic, or project cost, read
 [Attribute agent spend to issues](cost-attribution.md).
+
+When a run succeeds, opens no pull request, has no failed sub-run, and its
+reply is longer than about 2,000 characters (for example a plan), the status
+comment says "✅ The full reply follows in the next comment(s)." and the reply
+follows in up to four numbered comments ("Reply, part i of n") of about 15,000
+characters each, split at headings, paragraphs or lines. Anything beyond is
+cut with a note, and the full text stays on the run (`get_run`, `finalText`).
+`@`-mentions are defused. Each part is posted once; if one cannot be posted,
+the rest are skipped. Shorter replies stay in the status comment.
+
 If the token belongs to a person, Wardby refuses to act: startup logs an error
 and the webhook answers 503 `jira_personal_account`. Deliveries with a
 timestamp older than two hours (or more than five minutes ahead) are ignored.
@@ -125,6 +136,12 @@ agent how to continue each open one; see
 [Related pull requests across repositories](related-pull-requests.md). See
 the full guide for the recipe.
 
+To have a code reviewer check such a pull request against the ticket's own
+acceptance criteria, link the reviewer to the Jira project too (read access
+is enough): it then reads the ticket with `jira_get_issue`. Without that link
+it can only judge the criteria from the pull request's description; see
+[Run GitHub code-review agents](code-review-agents.md#reading-the-issue-a-pull-request-resolves).
+
 ## Trust rules
 
 Only people (not customers, apps, or the service account itself) can trigger