@wardby/cli 0.6.0 → 0.7.0

package/help/resume-runs-locally.md

@@ -0,0 +1,131 @@
+---
+id: resume-runs-locally
+title: Resume Claude Code runs locally (sessionResume, get_run_transcript, wardby resume)
+summary: Keep each Claude Code run's redacted conversation with sessionResume, then continue it on your machine with get_run_transcript and npx @wardby/cli@latest resume.
+audience: operator
+tags: [sessionResume, wardby resume, get_run_transcript, transcript, blob-store, WARDBY_SESSION_TRANSCRIPTS]
+appliesTo: ">=0.7.0"
+---
+
+# Resume Claude Code runs locally
+
+`sessionResume` makes a Claude Code agent keep a redacted copy of each run's
+conversation, so the session can be continued locally in Claude Code with
+`get_run_transcript` and `npx @wardby/cli@latest resume`. It is off by default and is not
+available for Codex agents. It needs Claude Code worker images from Wardby
+0.7.0 or later.
+
+## Turn it on
+
+```json
+{ "id": "<coding agent id>", "codingProfile": { "sessionResume": true } }
+```
+
+Use `update_agent` or `create_agent`. The server needs a blob store
+(`BLOB_STORE`, with `BLOB_STORE_LOCAL_DIR`, `BLOB_STORE_GCS_BUCKET`, or
+`BLOB_STORE_S3_BUCKET` and `BLOB_STORE_S3_REGION`, plus the optional
+`BLOB_STORE_S3_ENDPOINT` for an S3-compatible store) set on the **server
+process** that launches coding runs, not only on the coding proxy. Without a
+blob store nothing is stored, and `update_agent` warns you.
+
+## What is stored
+
+- The conversation as Claude Code recorded it: user and assistant messages,
+  tool calls and their results, compaction summaries, files and skills the
+  agent loaded, and a session title (`wardby run <id>: <task>` when Claude
+  Code made none).
+- Removed: thinking blocks, the system prompt, the worker's environment, date
+  and budget reminders, account and organisation details, and billing
+  records.
+- Redacted: the values of the agent's attached secrets, plus the run's
+  capability and registry token by their token shape. If the agent's secrets
+  cannot be loaded, nothing is stored.
+- Stored for runs that finish, stop at their budget, or fail. Not stored for
+  runs stopped with `stop_run` or ended by their timeout.
+- Stored gzip-compressed under the `run-transcripts/` prefix. When the run's
+  context was compacted, only what a resume loads is kept: the last
+  compaction's summary, the messages it kept, and everything after it.
+- At most `RUN_TRANSCRIPT_MAX_BYTES` per run, measured before compression
+  (default 10 MiB, at most 64 MiB). Each run records a status (`stored`,
+  `too_large`, `not_captured` or `failed`) with a reason code.
+
+## Who can read it
+
+Transcripts are stored from the first run with `sessionResume` on. Anyone
+who can read a run (its triggerer and the agent's owner, as for `get_run`)
+can download its transcript, which includes
+what the agent saw in the repository and in command output. Redaction removes secret
+values, not other sensitive text. Turn this on only for agents whose runs you
+are comfortable sharing with everyone who can read them.
+
+## Continue a run on your machine
+
+1. Ask your MCP client to call `get_run_transcript` with the run id (same
+   access as `get_run`). For a stored transcript it returns a download link
+   that works for 10 minutes and the command to run; otherwise the status
+   (`none`, `too_large`, `not_captured`, `failed`, `expired`, `unavailable`,
+   `unsupported`) and what it means.
+2. Run the command in a terminal, `npx @wardby/cli@latest resume -`, and paste the link
+   when it asks. (A link given as an argument stays in shell history and the
+   process list.) For a GitHub repository, run it inside a clone of that
+   repository. A `local:` repository is used only when the link comes from
+   this machine (a stdio MCP server); otherwise pass `--here` or `--dir`.
+
+It verifies the download's SHA-256, writes the session to
+`~/.wardby/sessions/<run id>/<session id>.jsonl` (mode 0600, never into
+Claude Code's own config directory), adds a detached git worktree of the
+run's branch next to the repository (the base commit, with a warning, when
+the branch is gone), and starts `claude --resume` there. A stand-in
+`wardby_tools` server shows the run's `run_command` calls but runs nothing,
+and a note tells the model `/workspace` is now the worktree.
+
+Options: `--dir <path>` (worktree location), `--here` (no checkout),
+`--force` (replace a different imported session file), `--print` (print the
+`claude` command instead of starting it). The command passes
+`--system-prompt-snapshot off` so the move note applies; remove it for a
+Claude Code older than 2.1.257 when the version could not be read. Under
+`npx`, the MCP config points into the npx cache: run `wardby resume` again if
+the cache was cleaned.
+
+The link is a credential until it expires: do not share it. Over stdio it
+points at a local port the MCP server opens, so keep your MCP client
+connected until the download finishes. The token is in the link's query
+string: keep `/run-transcripts/download` out of load-balancer and ingress
+access logs. Refusals:
+[Run transcript download refused](errors/run-transcript-download.md).
+
+## Retention
+
+`RUN_TRANSCRIPT_RETENTION_DAYS` is a whole number from 1 to 3650 (default 30).
+Expired transcripts are pruned when new ones are stored. On GCS or S3 also add
+a bucket lifecycle rule on the `run-transcripts/` prefix.
+
+## Set it up per deployment
+
+Give transcripts a bucket of their own, not the dependency cache bucket, that
+only the control plane can use.
+
+- GKE: `session_transcripts_enabled` and `session_transcripts_bucket_name` in
+  Terraform (optionally `session_transcripts_retention_days`), then
+  `WARDBY_SESSION_TRANSCRIPTS=true deploy/gke/up.sh`. Terraform adds the
+  lifecycle rule; `up.sh` passes the same retention to the control plane.
+- AWS: the same Terraform variables, then give the control plane `BLOB_STORE=s3`,
+  the `session_transcripts_bucket` output as `BLOB_STORE_S3_BUCKET`,
+  `BLOB_STORE_S3_REGION`, and the `session_transcripts_retention_days` output as
+  `RUN_TRANSCRIPT_RETENTION_DAYS`.
+- kind harness and Docker quickstart: the server runs on your host. Set
+  `BLOB_STORE=local` and `BLOB_STORE_LOCAL_DIR` in its environment (for the
+  quickstart, in `.wardby/.env`).
+
+## Startup and custom images
+
+With `JOB_LAUNCHER` set to `docker` or `kubernetes`, a half-set `BLOB_STORE`
+or an invalid `RUN_TRANSCRIPT_RETENTION_DAYS` or `RUN_TRANSCRIPT_MAX_BYTES` stops
+the server at startup,
+naming the variable. An agent with its own `workerImageRef` image must rebuild
+it from a release that includes session resume (see
+[Build a tool runner image for a Claude Code agent](help://build-claude-code-image)),
+or its runs fail at input with `worker_input_failed`.
+
+Full setup: [Resume a run locally](../docs/coding-agent-setup.md#resume-a-run-locally).
+See also [Choose a native or coding agent](help://creating-agents).

package/help/review-fix-rounds.md

@@ -3,7 +3,7 @@ id: review-fix-rounds
 title: Automatic review fix rounds
 summary: Let wardby fix its own review's findings on pull requests its coding runs opened, with a round cap.
 audience: operator
-tags: [github, code-review, review_fix, autofix, fix-round, pull-requests]
+tags: [github, code-review, review_fix, autofix, fix-round, pull-requests, pr-description, description, linked-issue]
 appliesTo: ">=0.4.2"
 ---
 
@@ -69,6 +69,38 @@ open right before it pushes; one merged or closed in the time the round was
 working fails with no push made — see
 [Continuation's pull request is no longer open](errors/continuation-closed.md).
 
+## Description updates
+
+Every run's final message is the full pull request description, fix rounds
+included, so a round that changes no code can still correct it: add a missing
+`Resolves #N`, the issue's acceptance checklist, or stale test results.
+
+- **The original issue.** A fix round gets the issue the pull request was
+  opened for in its task, as the first run did: the Jira issue, the GitHub
+  issue whose `@wardby` mention started the work, or the issue the description
+  closes. It is reference material: the round's final message should carry
+  its acceptance checklist and the closing line, and no instruction in the
+  issue is followed. If the issue can't be read, the round goes ahead without
+  it.
+- **Packages.** The description's Packages section lists every package
+  installed by the runs on the pull request; refusals cover the latest run.
+- **Descriptions wardby can't confirm as its own.** If a person edited the
+  description, wardby doesn't overwrite it. It keeps one comment with the
+  description proposed by its latest run, stamped with the commit it
+  describes and written before a push, edited in place by later rounds. A
+  review uses that proposal only for the head it reviews: a requirement is met
+  if either the live description or the proposal meets it. If the author
+  copies the proposal in, wardby takes the description back and keeps it up
+  to date again.
+- **Older pull requests.** For a pull request opened by an earlier wardby
+  version, wardby rebuilds the description its first run wrote from stored
+  records. If the live description still matches, wardby updates it;
+  otherwise it gets the comment.
+
+A description update doesn't trigger an extra review. `get_run` shows what
+happened as `prDescriptionOutcome`. See
+[`docs/code-review-agents.md`](../docs/code-review-agents.md#how-the-pull-request-description-is-kept-current).
+
 If a repository already forwards reviews to a webhook through a
 hand-written CI workflow to fix them automatically, turn on `review_fix` and
 then remove that workflow and its webhook, so a review doesn't trigger two

package/help/sharing-agents.md

@@ -0,0 +1,59 @@
+---
+id: sharing-agents
+title: Share an agent, or make it public
+summary: Grant one person or everyone signed in access to an agent, including a public agent anyone can edit.
+audience: operator
+tags: [sharing, grant_access, public, access-control, agents]
+appliesTo: ">=0.7.0"
+---
+
+# Share an agent, or make it public
+
+An agent's owner controls who else can reach it with `grant_access`,
+`revoke_access` and `list_access`. Levels, lowest first:
+
+- `read`: see the agent in `list_agents` and `get_agent`.
+- `execute`: also run it (`trigger_agent`).
+- `write`: also change it (`update_agent`, schedule, webhooks, tools).
+
+The grantee is one person, `{"subject": "..."}` or `{"principalId": "..."}`,
+who must have signed in once, or `"everyone"`: any principal signed in to the
+MCP server.
+
+## Public agents
+
+Grant `everyone` at `read` or `execute` for an agent anyone can see or run.
+Grant `everyone` at `write` for an agent anyone can also edit.
+
+Everyone-`write` is refused while the agent holds any of its owner's bindings:
+secrets, datastores, repositories, sub-agents, tool capabilities, or a coding
+repository, so a coding agent can't be public-write. Otherwise anyone could
+rewrite its prompt and use them. Detach them first, or grant `execute` instead.
+The reverse holds too: `attach_secret`, `attach_datastore`, `link_repository`,
+`attach_subagent`, `attach_tool` with capabilities, and `update_agent` making
+it a coding agent are refused on an agent everyone can write. Revoke or lower
+the everyone grant first.
+
+### Cap what a public-write agent can spend
+
+Runs of a shared agent are charged to its owner. With `write`, anyone signed in
+can change the agent's model, per-run budget, turns and schedule, and create
+webhooks that trigger it. Before granting everyone `write`, put the agent in a
+budget group (`create_budget_group`, then `update_agent` with `budgetGroupId`).
+Only the owner can change
+budget-group membership, so the group's limit caps total spend whatever anyone
+else changes.
+
+### After you revoke or lower the grant
+
+- **Webhooks:** a webhook fires only while its creator can still run the
+  agent. Revoking the everyone grant stops webhooks other people created;
+  lowering it to `execute` keeps them firing. Use `list_webhooks` and
+  `delete_webhook` to remove them; the owner can delete any webhook on the
+  agent.
+- **Schedule:** a schedule someone else set stays on the agent. Check it with
+  `get_agent` and remove it with `disable_schedule`.
+- **Prompt and settings:** edits stay. Check the prompt, model and budget with
+  `get_agent`.
+
+See [Identity and access](identity-and-access.md) for sign-in and scopes.

package/help/slack-notifications.md

@@ -28,11 +28,25 @@ per card. This is outbound only: nothing in Slack starts or affects a run.
 
 ## Events
 
-`issue_picked_up`, `run_failed` (top-level runs only), `pr_opened`,
-`review_posted` (approve / changes requested / comment), `review_fix` (round
-started, or stopped at the cap), and `pr_closed` (merged or closed, with any
-Jira status move). `events` on a link narrows which of these post; omitted
-means all six. `includeCost` appends the run's spend line.
+`issue_picked_up`, `run_failed` and `run_blocked` (top-level runs only),
+`pr_opened`, `review_posted` (approve / changes requested / comment),
+`review_fix` (round started, or stopped at the cap), `pr_closed` (merged or
+closed, with any Jira status move), and `packages_audited` (from Wardby 0.7.0,
+top-level runs only: what its coding runs installed under package audit mode,
+described in the `package-audit-mode` help article; it doesn't change the
+thread's status). `events` on a link narrows which of these post; omitted
+means all eight. `includeCost` appends the run's spend line.
+
+A pull request opened from a GitHub issue mention posts `pr_opened` and
+`pr_closed` too, the same as one opened for a Jira issue. Its thread is the
+issue's, one per GitHub issue, not one per pull request; once the pull request
+is recorded for the issue, its `review_posted` and `review_fix` events reply
+there as well. The run events of a run a GitHub issue mention started keep a
+thread of their own.
+
+A `run_blocked` event uses the same ⛔ package registry wording and fixes as
+[Run status comments](status-comments.md). See [Package refusal errors](errors/package-refusals.md)
+for allowlist, release-age, advisory, and malware guidance.
 
 wardby never posts code, diffs, review text, or run output to Slack.
 

package/help/status-comments.md

@@ -0,0 +1,31 @@
+---
+id: status-comments
+title: Run status comments
+summary: Read GitHub and Jira run outcomes, package registry blocked statuses, and Slack notifications.
+audience: operator
+tags: [status, comments, github, jira, slack, blocked, packages, mentions]
+appliesTo: >=0.2.1
+---
+
+# Run status comments
+
+Mentioning the GitHub App starts a run and posts a working status comment.
+The comment is updated when the run finishes, with pull request links, an
+answer, or a failure. This includes a run that a deploy moved to a new
+control-plane process. Jira requests also report their outcome in a status
+comment.
+
+When coding sub-runs record package refusals and no pull request or pushed
+changes result, the comment shows ⛔ **Blocked by the package registry: no
+changes were made.** It lists refused packages, registry codes, and fixes.
+Slack notifications use the same blocked wording. Lists are limited to ten
+distinct entries with a count of remaining refusals; use `get_run` for all.
+When changes were pushed despite refusals, the pull request link stays and
+there is a ⚠️ dependency install warning. Without refusals, the usual ✅
+success or ❌ failure wording remains.
+
+An approver can update the coding agent's package allowlist or policy with
+`update_agent` (requires `packages:approve` or `agents:admin`), then mention
+`@wardby` again. See [Package refusal errors](errors/package-refusals.md) for
+code-specific fixes and [Approve packages for coding agents](coding-packages.md)
+for policy details. Malware checks cannot be bypassed.

package/help/stop-run.md

@@ -0,0 +1,58 @@
+---
+id: stop-run
+title: Stop or cancel a run
+summary: Use stop_run to stop a pending, queued, or running run and its in-flight sub-agent runs; it ends as cancelled.
+audience: operator
+tags: [runs, stop run, cancel run, stop_run, cancelled, schedules, coding-agents, native-agents, sandbox]
+appliesTo: ">=0.7.0"
+---
+
+# Stop or cancel a run
+
+Call the MCP tool `stop_run` with the run's id to stop a run that has not
+finished. Add an optional `reason`; it is recorded on the run.
+
+```text
+stop_run {"runId": "<run id>", "reason": "unwanted scheduled run"}
+```
+
+Find the id with `list_runs` (filter with `"status": "pending"` or
+`"running"`). To stop a schedule from creating more runs, disable it with
+`disable_schedule` as well; `stop_run` stops one run, not the schedule.
+
+## What happens
+
+The run ends as `cancelled`, with `Stopped by <your id> with stop_run: <reason>`
+in its `stopRequestReason` (and, for a native run, in its `error`).
+
+| The run is                                 | `stop_run`                                                                                                                                                                                                     |
+| ------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Pending, or a coding run queued for a slot | Ends it now. It never starts.                                                                                                                                                                                  |
+| A running native run in the control plane  | Ends it now; the run stops at its next step (the model turn or tool call already under way finishes first).                                                                                                    |
+| A running native run in the sandbox        | Ends it now and ends its gateway session, so the worker's next call is refused and it exits. A worker still running after a short grace (5 seconds) is killed and removed; a warm pool worker is never reused. |
+| A running coding run                       | Ends it, cancels its model proxy session, and stops and removes its worker. It opens or updates no pull request afterwards.                                                                                    |
+| Already finished (any other status)        | Changes nothing and returns its status. Calling `stop_run` again is safe.                                                                                                                                      |
+
+Sub-agent runs the stopped run delegated, and that are still pending or running,
+are stopped too (their ids are in `stoppedChildRunIds`).
+
+Spend already recorded stays counted against the budget. A stopped run is not a
+failure: Slack notifications say it was cancelled, and no defect is filed.
+
+If the result still shows `pending` or `running`, the stop has been recorded
+but has not landed yet; check again with `get_run`.
+
+## Who can stop a run
+
+You need the `runs:trigger` scope and `execute` access to the run's agent, the
+same as `trigger_agent`. The agent's owner can stop any of its runs, including
+scheduled ones; anyone else can stop only runs they triggered. A run you cannot
+see returns `Run "<id>" not found.`, exactly like a missing one; a run you
+triggered but whose agent you can no longer execute returns a 403.
+
+## Related
+
+- [Operate managed agents](operating-agents.md)
+- [Run native agents in a sandbox](native-sandbox.md)
+- [Slack notifications](slack-notifications.md)
+- [Run lost](errors/run-lost.md), for runs a deploy interrupted

package/help/troubleshooting/budgets.md

@@ -41,3 +41,31 @@ with `already_dispatched` and a message naming how many delegations were
 made and how many are waiting for budget.
 
 For a shared-group refusal, read [Budget group exhausted](../errors/budget-group-exhausted.md).
+
+To see exactly which limit stopped a run and with what numbers, read
+`budgetEvents` in `get_run`; see the help article `errors/budget-exhausted`.
+A lead and the sub-agents it starts in the same budget group hold the lead's
+budget once (or its live sub-agent runs' unspent holds, if the lead's overrun
+let them be topped up past it), and `get_budget_group` reports `heldRuns` for
+each period.
+
+A coding run's per-request holds price the cached part of the input at the
+cache-read rate after the first reply of a conversation; see the help article
+`errors/budget-exhausted`.
+
+## Allowing a small overrun
+
+If coding runs stop just short of finishing, set `allowedOverrunPercent` (0 to
+100, default 0) on the coding agent so a run may spend that percent beyond
+`budgetUsd`. Set it on a lead agent that delegates to raise its run tree's
+ceiling for coding sub-agents; native runs' own model calls are not affected.
+
+The overrun is not reserved. A run reserves its base budget, and is topped up
+toward its limit while it works, only from room its budget group and run tree
+have at that moment. Budget group and run-tree caps stay hard: in a full group
+the run stops at what it was granted, and its budget sentence says so ("Only
+$0.40 of its 10% allowed overrun was available because the "team" group had no
+more left of its daily cap."). `get_run` shows `budgetBaseUsd`, the limit in `budgetLimitUsd`, and what
+has been granted so far in `budgetReservedUsd`. A run still stopped for budget
+keeps its work as a draft pull request you can continue. See
+`errors/budget-exhausted`.

package/help/troubleshooting/coding-workers.md

@@ -3,7 +3,7 @@ id: troubleshooting/coding-workers
 title: Troubleshoot coding workers
 summary: Investigate coding-worker setup, isolation preflight, and safe failure handling.
 audience: operator
-tags: [coding-agents, docker, kubernetes, isolation, services]
+tags: [coding-agents, quota, coding_queue_timeout, docker, kubernetes, isolation, services, debug-trace, debugTraceMinutes, debugTraceMaxMb, maxOutputTokens, output-tokens, claude-code, codex, memory, CODING_MEMORY_MB, CODING_CPUS, out-of-memory]
 appliesTo: >=0.2.1
 ---
 
@@ -54,14 +54,85 @@ raise `codingProfile.maxTurns` (up to 1000) with `update_agent` for the first,
 or narrow the task for the second. Codex runs have no turn limit. See
 [Coding run reached its turn limit](../errors/coding-turn-limit.md).
 
+## Claude Code replies that exceed the output token maximum
+
+A Claude Code run caps each model reply at 32000 output tokens by default,
+thinking included. When a reply needs more, Claude Code ends with an error
+that the response exceeded the output token maximum and the run fails as a
+stream failure. Raise `codingProfile.maxOutputTokens` (1024 to 128000; `null`
+restores the default) with `update_agent`, for example
+`{ "id": "<agent id>", "codingProfile": { "maxOutputTokens": 64000 } }`. The
+coding proxy reserves `maxOutputTokens` × the model's output price against the
+run's budget for every model request, so a higher value needs a larger
+`budgetUsd`; a request whose reservation does not fit ends the run as
+`budget_exhausted` (see the help article `errors/budget-exhausted`), so a small
+budget runs out sooner. Codex agents refuse the
+setting. The default and the setting need a Claude Code worker image from
+Wardby 0.7.0 or later: an older pinned image still caps replies at 4096 tokens
+and rejects a run whose agent sets `maxOutputTokens`.
+
+## Runs refused because the provider is out of credit
+
+A diagnostic of `job_coding_stream_quota_exceeded` means the model provider
+behind the coding proxy refused the run because its account is out of credit or
+over a spend limit, not that the run's own budget ran out. Every run on that
+account fails the same way until the limit is raised; see the help article
+`errors/coding-stream-quota-exceeded`.
+
+## Runs that die while running checks (out of memory)
+
+A run that fails with `coding_failure_executor` while it runs a linter, a type
+check or a test suite has often run out of memory. Each coding pod gets
+`CODING_MEMORY_MB` (2048 MiB by default) and `CODING_CPUS` (1 by default). In a
+Codex run the agent and its commands share that pod. In a Claude Code run the
+commands run in a tool-runner container limited to at most 512 MiB and 0.25 CPU.
+
+1. Turn on a debug trace (below) and run it again. A Node.js crash shows as
+   `Aborted` with exit code 134 in a command's output.
+2. Raise `CODING_MEMORY_MB` and `CODING_CPUS` on the control plane. On GKE, deploy
+   with `CODING_MEMORY_MB=6144 CODING_CPUS=2 deploy/gke/up.sh` (see the GKE deploy
+   guide). This applies to every coding run.
+3. For a Claude Code agent with heavy checks, run it on Codex instead, since raising
+   the pod's memory doesn't raise the tool runner's limit.
+
+## Debug trace
+
+When a run's fixed error code or a slow run doesn't say enough, an admin can
+trace the agent's runs for a while:
+`update_agent { "id": "<agent id>", "codingProfile": { "debugTraceMinutes": 30 } }`.
+Each run dispatched in that window writes its whole agent stream, redacted, to
+its worker container's log under a `debugTrace` key. That covers Codex events,
+or, for Claude Code (Wardby 0.7.0 or later), every Agent SDK message:
+each command the agent ran with its output, the final usage and duration, plus
+stream failures in full. For Claude Code, the time between a command's
+`tool_use` and its `tool_result` line is how long that command took. A run's
+trace stops at 2 MiB by default; set `codingProfile.debugTraceMaxMb` (1 to 64,
+admin only) for more. The trace can hold prompts and repository content, so
+keep it on briefly. See
+[the debug trace section](../../docs/coding-worker-isolation.md#debug-trace)
+for where the log lives and what is redacted.
+
 ## Runs that wait for cluster capacity
 
-On Kubernetes with `KUBERNETES_RESOURCE_QUOTA` set, a run whose pod would not
-fit the namespace quota stays `pending` with `codingQueuedAt` set, like a run
-over `CODING_MAX_CONCURRENT`, and starts once other runs finish. A run still
-waiting after `CODING_QUEUE_TIMEOUT_SEC` fails with `coding_queue_timeout`:
-raise the quota, lower the run pods' size, or lower `CODING_MAX_CONCURRENT` so
-fewer runs compete.
+On Kubernetes, a run whose pod would not fit the namespace quota waits instead
+of failing. With `KUBERNETES_RESOURCE_QUOTA` set, it is held before it starts;
+without it, or if the quota fills up meanwhile, the cluster refuses the pod and
+the run returns to the queue. Either way it stays `pending` with
+`codingQueuedAt` set, like a run over `CODING_MAX_CONCURRENT`, and is retried
+(a refused run no sooner than about a minute later). A refused run shows
+`running` briefly, then `pending` again.
+
+A run still waiting after `CODING_QUEUE_TIMEOUT_SEC` fails with
+`coding_queue_timeout`. That can mean either the concurrency limit or the
+namespace quota. To tell which, look for the control-plane log line
+`coding run waiting for capacity: the cluster refused its pod` (quota), and run
+`kubectl describe resourcequota -n <namespace>` to compare used against hard
+limits. If the quota is full, raise it, lower the run pods' size, or lower
+`CODING_MAX_CONCURRENT` so fewer runs compete; size the quota for
+`CODING_MAX_CONCURRENT` times the run pod's requests. If the log line
+`kubernetes_resource_quota_unconfigured` appears, set `KUBERNETES_RESOURCE_QUOTA`
+to the named quota and grant the launcher `get` on it. See
+[the queue section](../../docs/coding-worker-isolation.md#control-plane-configuration).
 
 A lead agent with `parallelDelegations` starts several coding runs together;
 expect some of them to queue when the lead fans out wider than the free slots.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wardby/cli",
-  "version": "0.6.0",
+  "version": "0.7.0",
   "description": "Self-hosted control plane for budget-guarded AI agents.",
   "license": "Apache-2.0",
   "homepage": "https://github.com/wardby/wardby#readme",
@@ -58,7 +58,7 @@
     "build:help": "tsx src/help/build.ts",
     "sync:reviewer-prompt": "tsx src/quickstart/sync-reviewer-prompt.ts",
     "build:viewer-schemas": "tsx src/viewer/build-schemas.ts",
-    "build": "npm run build:vendor && PRISMA_HIDE_UPDATE_MESSAGE=1 prisma generate && tsc -p tsconfig.build.json && npm run build:help",
+    "build": "npm run build:vendor && PRISMA_HIDE_UPDATE_MESSAGE=1 prisma generate && tsc -p tsconfig.build.json && node scripts/copy-build-modules.mjs && npm run build:help",
     "prepare": "npm run build:vendor && PRISMA_HIDE_UPDATE_MESSAGE=1 prisma generate",
     "prepack": "npm run build",
     "cli": "tsx --conditions=wardby-source src/wardby-bin.ts",
@@ -67,6 +67,7 @@
     "test": "npm run build:vendor && vitest run",
     "test:package": "node scripts/npm-package-acceptance.mjs",
     "test:contract": "vitest run --config vitest.contract.config.ts",
+    "test:release": "npm run build:vendor && vitest run --config vitest.release.config.ts",
     "test:kubernetes": "WARDBY_KUBERNETES_TEST=1 vitest run src/providers/jobs/kubernetes.integration.test.ts",
     "test:native-docker": "WARDBY_NATIVE_DOCKER_TEST=1 vitest run src/native-worker/docker.acceptance.test.ts",
     "test:native-kind": "WARDBY_NATIVE_KIND_TEST=1 vitest run src/native-worker/kubernetes.acceptance.test.ts",
@@ -100,12 +101,16 @@
     "@anthropic-ai/bedrock-sdk": "^0.33.4",
     "@anthropic-ai/sdk": "^0.124.0",
     "@aws-crypto/sha256-js": "4.0.0",
+    "@aws-sdk/client-s3": "3.1140.0",
+    "@aws-sdk/lib-storage": "3.1140.0",
     "@aws-sdk/rds-signer": "3.1140.0",
+    "@aws-sdk/s3-request-presigner": "3.1140.0",
     "@dbos-inc/dbos-sdk": "4.27.6",
+    "@google-cloud/storage": "8.2.0",
     "@kubernetes/client-node": "^2.0.0",
-    "@modelcontextprotocol/client": "^2.3.1",
-    "@modelcontextprotocol/node": "^2.0.0",
-    "@modelcontextprotocol/server": "^2.0.0",
+    "@modelcontextprotocol/client": "^2.4.0",
+    "@modelcontextprotocol/node": "^2.1.2",
+    "@modelcontextprotocol/server": "^2.4.0",
     "@prisma/adapter-pg": "7.10.0",
     "@prisma/client": "7.10.0",
     "@prometheus-io/client": "^0.16.1",
@@ -124,11 +129,11 @@
     "pino": "^9.14.0",
     "quickjs-emscripten": "^0.32.0",
     "semver": "^7.8.5",
+    "smol-toml": "1.9.0",
     "tar-stream": "^3.2.1",
-    "undici": "^8.7.0",
+    "undici": "^8.12.3",
     "yaml": "^2.9.1",
-    "zod": "^3.25.76",
-    "zod-to-json-schema": "^3.25.2"
+    "zod": "^4.6.7"
   },
   "devDependencies": {
     "@eslint/js": "^10.0.1",
@@ -148,10 +153,12 @@
     "tsx": "^4.19.0",
     "typescript": "^5.6.0",
     "typescript-eslint": "^8.69.0",
-    "vitest": "^4.1.11"
+    "vitest": "^4.1.12",
+    "zod-to-json-schema": "^3.25.2"
   },
   "overrides": {
     "deepmerge-ts": "8.0.2",
-    "mysql2": "3.24.4"
+    "mysql2": "3.24.4",
+    "uuid": "11.1.1"
   }
 }

package/prisma/migrations/20261016000000_registry_approved_accepted_advisories/migration.sql

@@ -0,0 +1,3 @@
+-- Additive: the blocking advisories a run's packagePolicy.acceptedAdvisories
+-- waived for a version its lockfile plan approved (empty when none).
+ALTER TABLE "RegistryApprovedVersion" ADD COLUMN "acceptedAdvisories" TEXT[] DEFAULT ARRAY[]::TEXT[];

package/prisma/migrations/20261016000001_mark_ready_when_passing/migration.sql

@@ -0,0 +1,3 @@
+-- Additive: opt-in to mark Wardby's draft pull requests ready once they pass, claimed once per pull request.
+ALTER TABLE "AgentRepository" ADD COLUMN "markReadyWhenPassing" BOOLEAN NOT NULL DEFAULT false;
+ALTER TABLE "CodingRun" ADD COLUMN "markedReadyAt" TIMESTAMP(3);

package/prisma/migrations/20261017000000_debug_trace_max_mb/migration.sql

@@ -0,0 +1,4 @@
+-- Configurable per-run debug-trace cap: the profile carries the admin-set cap
+-- (MiB), and each traced run records at dispatch the cap it used.
+ALTER TABLE "CodingAgentProfile" ADD COLUMN "debugTraceMaxMb" INTEGER;
+ALTER TABLE "CodingRun" ADD COLUMN "debugTraceMaxMb" INTEGER;

package/prisma/migrations/20261018000000_dependency_cache/migration.sql

@@ -0,0 +1,53 @@
+-- Additive: the run dependency cache. An agent flag snapshotted onto each
+-- coding run, the run's reported cache result, the proxy session's approved
+-- lock hashes and seal, and the snapshot metadata the coding proxy keeps.
+-- A snapshot outlives the run that created it: createdByRunId is cleared, not
+-- cascaded, when that run is deleted.
+
+-- AlterTable
+ALTER TABLE "CodingAgentProfile" ADD COLUMN "dependencyCache" BOOLEAN NOT NULL DEFAULT false;
+
+-- AlterTable
+ALTER TABLE "CodingRun" ADD COLUMN "dependencyCache" BOOLEAN NOT NULL DEFAULT false,
+ADD COLUMN "dependencyCacheResult" JSONB;
+
+-- AlterTable
+ALTER TABLE "CodingProxySession" ADD COLUMN "dependencyCacheLockHashes" TEXT[] DEFAULT ARRAY[]::TEXT[],
+ADD COLUMN "dependencyCacheSealedAt" TIMESTAMP(3);
+
+-- CreateTable
+CREATE TABLE "DependencySnapshot" (
+    "id" TEXT NOT NULL,
+    "ecosystem" TEXT NOT NULL,
+    "repository" TEXT NOT NULL,
+    "projectPath" TEXT NOT NULL DEFAULT '.',
+    "lockHash" TEXT NOT NULL,
+    "workerImage" TEXT NOT NULL,
+    "policyHash" TEXT NOT NULL,
+    "blobKey" TEXT NOT NULL,
+    "sha256" TEXT NOT NULL,
+    "sizeBytes" BIGINT NOT NULL,
+    "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    "lastUsedAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    "createdByRunId" TEXT,
+
+    CONSTRAINT "DependencySnapshot_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateIndex
+CREATE UNIQUE INDEX "DependencySnapshot_blobKey_key" ON "DependencySnapshot"("blobKey");
+
+-- CreateIndex
+CREATE UNIQUE INDEX "DependencySnapshot_ecosystem_repository_projectPath_lockHas_key" ON "DependencySnapshot"("ecosystem", "repository", "projectPath", "lockHash", "workerImage", "policyHash");
+
+-- CreateIndex
+CREATE INDEX "DependencySnapshot_ecosystem_repository_projectPath_workerI_idx" ON "DependencySnapshot"("ecosystem", "repository", "projectPath", "workerImage", "policyHash", "createdAt");
+
+-- CreateIndex
+CREATE INDEX "DependencySnapshot_lastUsedAt_idx" ON "DependencySnapshot"("lastUsedAt");
+
+-- CreateIndex
+CREATE INDEX "DependencySnapshot_createdByRunId_projectPath_idx" ON "DependencySnapshot"("createdByRunId", "projectPath");
+
+-- AddForeignKey
+ALTER TABLE "DependencySnapshot" ADD CONSTRAINT "DependencySnapshot_createdByRunId_fkey" FOREIGN KEY ("createdByRunId") REFERENCES "CodingRun"("runId") ON DELETE SET NULL ON UPDATE CASCADE;

package/prisma/migrations/20261019000000_claude_max_output_tokens/migration.sql

@@ -0,0 +1,5 @@
+-- Claude Code output tokens per model reply: the profile carries the agent's
+-- setting, and each run records at dispatch the value it used. Null = the
+-- worker default.
+ALTER TABLE "CodingAgentProfile" ADD COLUMN "maxOutputTokens" INTEGER;
+ALTER TABLE "CodingRun" ADD COLUMN "maxOutputTokens" INTEGER;