@wardby/cli 0.5.3 → 0.6.0

package/help/related-pull-requests.md

@@ -1,7 +1,7 @@
 ---
 id: related-pull-requests
 title: Related pull requests across repositories
-summary: Wardby lists the other pull requests from the same request in each pull request's description, with a suggested merge order.
+summary: Wardby lists the other pull requests from the same request in each pull request's description, in the merge order the delegating agent set (mergeOrder) or else a suggested merge order.
 audience: operator
 tags: [github, pull-requests, multi-repo, merge-order, related, siblings, continuePriorRun, coding-agents, jira]
 appliesTo: ">=0.4.2"
@@ -14,7 +14,7 @@ agent that delegates to one coding agent per repository, or several runs for
 the same Jira issue — Wardby adds a **Related pull requests** section to each
 of those pull requests' descriptions. It lists the others with links and
 their state, names the originating issue when there is one, and gives a
-suggested merge order.
+merge order: the one the delegating agent set, or else a suggested one.
 
 Without a tracked Jira issue, the list covers the pull requests opened by
 runs in the same delegation tree (the same lead run and everything it
@@ -30,13 +30,33 @@ included, plus that run tree's own siblings.
   section on every open pull request of the request with the full list and
   current states. A later run that pushes to any pull request in the set
   refreshes the section on all of them the same way, and never removes it.
-- **Suggested merge order (the order Wardby's agent opened them in)** numbers
-  the open (and draft) pull requests in delegation order. It is not a
-  dependency analysis — it is only reliable when the lead delegates
-  repositories that own shared data first (see
+  With Wardby 0.6.0 or later, a reviewer linked to one of these pull requests does
+  not review it until that same lead run finishes, however it ends. When the
+  lead finishes normally the section has already been rewritten by then;
+  when it is ended another way, such as being cancelled, reviews start
+  without that rewrite, so reviewers should rely on `repo_pr_read`'s
+  `relatedPullRequests` either way — see [Reviewing a pull request a
+  delegated run
+  opened](code-review-agents.md#reviewing-a-pull-request-a-delegated-run-opened).
+- **Merge order.** Without a `mergeOrder` (see below) on any pull request in
+  the set, open (and draft) pull requests are numbered as a **Suggested merge
+  order (the order Wardby's agent opened them in)** — delegation order, not a
+  dependency analysis, and only reliable when the lead delegates repositories
+  that own shared data first (see
   [Fanning out to several builders](../docs/agent-recipes.md#fanning-out-to-several-builders)).
-  Check it before merging. Merged and closed pull requests follow in a
-  separate "Already merged or closed" list, as context only.
+  When any pull request in the set has a `mergeOrder` (open, merged or
+  closed), the open ones that have one are numbered under **Merge order (set
+  by the delegating agent; equal steps can merge in either order)** and
+  labelled "step k of n" (equal values share a step and merge in either
+  order relative to each other), and any open pull request without one is
+  listed after under "Not ordered:". If only merged or closed pull requests
+  have a `mergeOrder`, every open one is listed under "Not ordered:" and the
+  "Merge order" heading is left out. Steps are counted over the whole set,
+  merged and closed pull requests included, so "step 2 of 3" keeps its label
+  after step 1 merges. Either way, check it before merging — neither is a
+  guarantee. Merged and closed pull requests follow in a separate "Already
+  merged or closed" list, as context only, with their step label when they
+  have one.
 - Only open pull requests that Wardby's own GitHub App opened are edited;
   merged or closed ones are listed but never changed, and a pull request
   from a different Wardby deployment sharing the same App is never touched.
@@ -49,9 +69,50 @@ included, plus that run tree's own siblings.
 
 Reviewers see the section in the pull request description, so a reviewer
 agent can tell that a field, route, or schema a change relies on is added by
-a sibling pull request rather than missing. See the reviewer step in
+a sibling pull request rather than missing. Because the description is only
+rewritten at the points above, a sibling opened (or merged, or closed) since
+then can be missing from it or shown with an old state. With Wardby 0.6.0 or later,
+`repo_pr_read`'s `relatedPullRequests` field lists the request's pull
+requests fresh on every call instead, so a reviewer should prefer it over
+the description's section when they disagree. Its entry for the pull request
+just read always carries that pull request's live state; another entry
+carries a state only when Wardby has one stored (pull requests linked to an
+issue) and omits it otherwise, so call `repo_pr_read` on that pull request
+for its live state. `relatedPullRequests` is empty for a pull request on a
+local repository, which has no App-authored marker to resolve the request
+from. See the
+reviewer step in
 [Run GitHub code-review agents](code-review-agents.md#ci-and-sibling-pull-requests).
 
+## Setting a merge order
+
+A lead agent sets the order explicitly by passing `mergeOrder` on its
+`delegate_to_<name>` call to a coding sub-agent: an integer from 1 to 99,
+where 1 merges first. Give a repository that other repositories' changes
+depend on a lower number than the ones that use it — for example a shared
+service `1`, the API that calls it `2`, the client that calls the API `3`.
+Give two changes the same number when there is no order between them; they
+share a step and either can merge first. A bad value (not an integer, or
+outside 1-99) is refused as a tool error, not silently dropped or clamped.
+
+Set it whenever one request's change spans several repositories and the
+pull requests need to land in a specific sequence; leave it out and the set
+keeps the delegation-order suggestion above. `mergeOrder` applies only to
+coding sub-agents, since only a coding run's pull request can be ordered: a
+native sub-agent ignores it, and its tool result notes that it did.
+
+Each pull request shows the value most recently set for it, by the run that
+opened it or a later continuation of it. A `continuePriorRun` call that
+omits `mergeOrder` keeps that current value, so a follow-up does not need to
+repeat it to keep a pull request in its place; one that sets `mergeOrder`
+replaces it.
+
+With Wardby 0.6.0 or later, once a set has more than one `mergeOrder`, each
+open or draft pull request Wardby opened in it also gets a check run named
+`wardby merge order`, tracking whether the pull requests it depends on have
+merged yet. It's an informational check by default; search help for "merge
+order check" for its states and for requiring it in branch protection.
+
 ## Follow-up runs and sibling pull requests
 
 When someone asks for a follow-up on one of these pull requests (an

package/help/repo-instructions-and-skills.md

@@ -0,0 +1,91 @@
+---
+id: repo-instructions-and-skills
+title: Repository instructions and skills in coding runs
+summary: What AGENTS.md, CLAUDE.md, and repo skills a coding run loads, and how to turn repo skills off per agent with codingProfile.repoSkills.
+audience: all
+tags: [coding, skills, repoSkills, claudeBareMode, CLAUDE.md, AGENTS.md, SKILL.md, codex, claude-code]
+appliesTo: ">=0.5.4"
+---
+
+# Repository instructions and skills in coding runs
+
+Every coding run loads the repository's own instructions, and by default
+also loads whatever agent skills the repository ships. This is on for both
+builders and cannot be turned off for instructions; skills can be turned off
+per agent.
+
+## Repository instructions (always on)
+
+| Builder     | Gets                                                                              |
+| ----------- | --------------------------------------------------------------------------------- |
+| Codex       | `AGENTS.md`, read directly from the checkout                                      |
+| Claude Code | `CLAUDE.md`, `.claude/CLAUDE.md`, and their `@path` imports (up to 5 levels deep) |
+
+A repository that only has `AGENTS.md` still gets it in Claude Code, through
+a one-line `CLAUDE.md` wardby synthesizes for it. Subdirectory `CLAUDE.md`
+files (anything other than the repository root and `.claude/CLAUDE.md`) are
+not loaded unless an imported file pulls them in.
+
+Claude Code's instructions and skills are bounded: at most 64 KiB per file,
+200 files, and 256 KiB combined; symlinks and non-UTF-8 files are refused. A
+file that doesn't pass is left out of the run rather than failing it.
+Repository settings, hooks, `.mcp.json`, agents, and commands are never sent
+to Claude Code — only Markdown instruction files and
+`.claude/skills/<name>/SKILL.md` files are allowed through, whatever an
+instruction file imports.
+
+Repository instructions and skills are untrusted guidance: they can shape a
+run's work but never relax the worker's sandbox rules.
+
+## Repository skills
+
+`codingProfile.repoSkills` loads the repository's own agent skills into a
+run. It defaults to `true`, and the agent owner or an admin can set it with
+`create_agent`/`update_agent`:
+
+```json
+{ "id": "<agent-id>", "codingProfile": { "repoSkills": false } }
+```
+
+| Builder     | Reads skills from                   | `repoSkills: false`                |
+| ----------- | ----------------------------------- | ---------------------------------- |
+| Codex       | `.agents/skills/`, `.codex/skills/` | Every repository skill is disabled |
+| Claude Code | `.claude/skills/<name>/SKILL.md`    | No skill context is collected      |
+
+Codex's own four built-in skills (`imagegen`, `openai-docs`, `skill-creator`,
+`skill-installer`) are always disabled, whatever `repoSkills` is set to.
+
+A Claude Code skill ships to the worker as its `SKILL.md` only; its other
+files (scripts, references, data) stay in the repository checkout, read or
+run through the command runner at `/workspace/.claude/skills/<name>/`.
+
+## Claude Code loading mode
+
+`codingProfile.claudeBareMode` (Claude Code agents only, default `true`)
+decides how Claude Code uses its repository instructions and skills:
+
+- **`true` (default).** Claude Code's hardened bare mode stays on. Wardby
+  adds the repository's instruction files to the system prompt in full, and
+  lists each skill by name, description, and path; the model reads a
+  skill's full `SKILL.md` itself with `run_command`.
+- **`false`.** Bare mode is off and Claude Code loads `CLAUDE.md` and skills
+  itself, through its native Skill tool, instead of reading them from the
+  system prompt.
+
+Repository settings, hooks, MCP configuration, agents, and commands are
+never loaded in either mode.
+
+```json
+{ "id": "<agent-id>", "codingProfile": { "claudeBareMode": false } }
+```
+
+## See also
+
+- [Choose a native or coding agent](creating-agents.md) for `codingProfile`
+  basics and the other fields it accepts.
+- [Bring-Your-Own Coding-Worker Images](../docs/coding-worker-byo-images.md)
+  — a custom `workerImageRef` image must be rebuilt for the current release. A
+  Codex agent's image built on an older driver base rejects
+  `repoSkills: false` and keeps offering Codex's built-in skills.
+- [Build a tool runner image for a Claude Code agent](build-claude-code-image.md)
+  to give a Claude Code agent's commands the tools your project needs.

package/help/review-fix-rounds.md

@@ -37,6 +37,16 @@ still running. Clicking **Re-run** on the review check isn't counted as a
 round itself; if the re-run's review requests changes, that starts a round
 like any other review.
 
+With Wardby 0.6.0 or later, a round whose agent makes no change — it decided
+the review's finding was wrong, rather than pushing a fix — doesn't leave the
+failed review check standing with nothing to replace it: wardby starts one
+fresh review of the pull request's unchanged head instead, run by the same
+reviewer that requested the changes, with the round's own summary passed
+along as untrusted context. This happens once per review that requested
+changes and still counts as one of the round cap's rounds; if the cap has
+already been reached, wardby posts the usual cap comment instead of
+re-reviewing.
+
 Rounds are tracked with labels on the pull request:
 
 - `wardby-autofix-<N>` — one per round, added before that round's run

package/help/slack-notifications.md

@@ -0,0 +1,62 @@
+---
+id: slack-notifications
+title: Send workflow updates to Slack
+summary: Link a Slack channel to a Jira project or an agent to follow cards from pickup to merge, one thread per card.
+audience: operator
+tags: [slack, notifications, channels, jira, pull-requests, link_notification_channel]
+appliesTo: >=0.6.0
+---
+
+# Send workflow updates to Slack
+
+Link a Slack channel to a Jira project or to an agent (native or coding) and wardby posts
+that project's or agent's workflow updates there — a card picked up, a pull
+request opened, a review verdict, fix rounds, and the merge — with one thread
+per card. This is outbound only: nothing in Slack starts or affects a run.
+
+## Setup checklist
+
+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-…`).
+3. Set `WARDBY_SLACK_BOT_TOKEN` (store it like any other provider credential)
+   and restart wardby.
+4. Link a channel with `link_notification_channel` — to a Jira project
+   (`projectKey`) or to an agent (`agentId`).
+5. Call `test_notification_channel` and confirm "✅ wardby is connected to
+   this channel." posts there.
+
+## 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.
+
+wardby never posts code, diffs, review text, or run output to Slack.
+
+## If something isn't posting
+
+- The link's `lastError` (from `list_notification_channels`) names the
+  problem. A channel error means the bot can't write there — see
+  [`errors/slack-channel-unreachable`](errors/slack-channel-unreachable.md).
+- No deliveries at all, for every channel, usually means the bot token is
+  invalid, revoked, or missing a scope — see
+  [`errors/slack-auth-failed`](errors/slack-auth-failed.md).
+- A channel that recovers gets new events again right away; deliveries that
+  already failed are not resent.
+- Linking or testing refused outright means Slack isn't configured yet — see
+  [`errors/slack-not-configured`](errors/slack-not-configured.md).
+
+## Related
+
+- [Run Jira agents](jira.md) — link a channel to the same project a Jira
+  agent is linked to, to see its cards move end to end.
+- [Automatic review fix rounds](review-fix-rounds.md) — the `review_fix`
+  event covers these rounds.
+- [Connect GitHub repositories](github.md) — pull-request events come from
+  the same App your coding and review agents already use.
+
+For the full guide, including scopes, threads, and failure modes, see
+[`docs/slack-notifications.md`](../docs/slack-notifications.md).

package/help/troubleshooting/coding-workers.md

@@ -23,6 +23,27 @@ Review the deployment guide for your target before assigning a coding profile.
 
 For the specific isolation refusal, read [Coding-worker isolation unavailable](../errors/docker-isolation-unsupported.md).
 
+## Cluster preflight at start-up (Kubernetes)
+
+With `JOB_LAUNCHER=kubernetes`, a long-running server process (`wardby
+serve`, `wardby mcp` over either transport, or `wardby scheduler`) starts
+the cluster preflight as soon as it starts, instead of waiting for the
+first coding run. Check the process's start-up log for the result: an info
+line when the preflight passes, or a warning naming the failure code (the
+same `kubernetes_isolation_unsupported:<check>` codes `wardby coding
+preflight` reports) when it does not.
+
+A failed start-up preflight is logged and retried on the next coding run,
+not left failing until a restart: fix the underlying configuration and the
+next run checks the cluster again on its own. If a run was already
+starting at the moment the start-up preflight failed, that one run still
+fails with the logged error — it was waiting on that same check — but the
+run after it retries. This differs from a preflight failure a coding run
+triggers itself (no start-up check ran, or the cluster is still broken when
+the next run checks it): that failure does stick, failing every subsequent
+run in that process until it is restarted. Run `wardby coding preflight` at
+any time for a one-off check against the same cluster.
+
 ## Runs that stop at the turn limit
 
 A Claude Code run whose failure category is `turn_limit` reached its agent's

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wardby/cli",
-  "version": "0.5.3",
+  "version": "0.6.0",
   "description": "Self-hosted control plane for budget-guarded AI agents.",
   "license": "Apache-2.0",
   "homepage": "https://github.com/wardby/wardby#readme",
@@ -61,13 +61,16 @@
     "build": "npm run build:vendor && PRISMA_HIDE_UPDATE_MESSAGE=1 prisma generate && tsc -p tsconfig.build.json && 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/cli.ts",
+    "cli": "tsx --conditions=wardby-source src/wardby-bin.ts",
     "codex:rerecord": "tsx --conditions=wardby-source src/tools/codex-rerecord.ts",
     "capture:autopilot": "tsx --conditions=wardby-source src/tools/capture-autopilot-dry-run.ts",
     "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: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",
+    "test:native-cluster": "WARDBY_NATIVE_CLUSTER_TEST=1 vitest run src/native-worker/kubernetes-cluster.acceptance.test.ts",
     "prisma:generate": "PRISMA_HIDE_UPDATE_MESSAGE=1 prisma generate",
     "prisma:migrate": "prisma migrate deploy",
     "dbos:migrate": "dbos schema \"$DATABASE_URL\"",
@@ -79,13 +82,14 @@
     "observability:smoke": "node scripts/grafana-smoke.mjs",
     "observability:down": "docker compose --env-file .env.local -f deploy/local/docker-compose.yml -f deploy/local/docker-compose.phase5.yml -f deploy/observability/docker-compose.grafana.yml down",
     "worker:image:local": "node scripts/build-local-coding-worker.mjs",
+    "native-worker:image:local": "docker build -f src/native-worker/Dockerfile -t wardby-native-worker:local .",
     "test:phase5": "vitest run src/coding/observability.test.ts src/coding/profile.test.ts src/coding/protocol.test.ts src/providers/coding-proxy/proxy.test.ts src/providers/coding-proxy/secure-fetch.test.ts src/providers/coding-proxy/metering.test.ts src/providers/coding-proxy/runtime.test.ts src/providers/executor/container.test.ts src/providers/jobs/docker.test.ts src/providers/jobs/docker-isolation.test.ts src/providers/jobs/fake.test.ts src/providers/vcs/github.test.ts src/mcp/tools/trigger.test.ts src/core/webhooks.test.ts src/claude-coding-worker/driver.test.ts src/claude-coding-worker/sdk.test.ts src/claude-coding-worker/image-policy.test.ts src/claude-tool-runner/command.test.mjs src/claude-tool-runner/main.test.mjs src/claude-tool-runner/image-policy.test.ts",
     "test:phase5:database": "vitest run src/coding/schema.database.test.ts src/providers/coding-proxy/prisma-ledger.database.test.ts src/providers/executor/container.database.test.ts src/core/coding-concurrency.database.test.ts src/core/scheduler.test.ts src/mcp/integration.test.ts",
     "verify:phase5": "npm run typecheck && npm run test:phase5 && npm run build && npm run worker:image:policy",
     "test:docker-isolation": "node scripts/docker-isolation-acceptance.mjs",
     "test:docker-job": "node scripts/docker-job-acceptance.mjs",
     "test:docker-services": "node scripts/docker-services-acceptance.mjs",
-    "claude:images:local": "docker build -f src/claude-coding-worker/Dockerfile -t wardby-claude-coding-worker:phase5 . && docker build -f src/claude-tool-runner/Dockerfile -t wardby-claude-tool-runner:phase5 . && docker build -f src/claude-tool-runner/Dockerfile --target node-python -t wardby-claude-tool-runner:phase5-node-python .",
+    "claude:images:local": "docker build -f src/claude-coding-worker/Dockerfile -t wardby-claude-coding-worker:phase5 . && docker build -f src/claude-tool-runner/Dockerfile -t wardby-claude-tool-runner:phase5 . && docker build -f src/claude-tool-runner/Dockerfile --target node-python -t wardby-claude-tool-runner:phase5-node-python . && docker build -f src/claude-tool-runner/Dockerfile.custom-example -t wardby-claude-tool-runner-custom:phase5 .",
     "test:claude-compatibility": "docker build -f src/claude-coding-worker/Dockerfile.compatibility -t wardby-claude-compat:phase5 . && docker run --rm wardby-claude-compat:phase5",
     "test:claude-docker": "node scripts/claude-docker-acceptance.mjs",
     "test:production-boundary": "node scripts/production-boundary-policy.mjs",
@@ -95,6 +99,8 @@
   "dependencies": {
     "@anthropic-ai/bedrock-sdk": "^0.33.4",
     "@anthropic-ai/sdk": "^0.124.0",
+    "@aws-crypto/sha256-js": "4.0.0",
+    "@aws-sdk/rds-signer": "3.1140.0",
     "@dbos-inc/dbos-sdk": "4.27.6",
     "@kubernetes/client-node": "^2.0.0",
     "@modelcontextprotocol/client": "^2.3.1",
@@ -104,6 +110,7 @@
     "@prisma/client": "7.10.0",
     "@prometheus-io/client": "^0.16.1",
     "@renovatebot/pep440": "^5.0.1",
+    "@smithy/signature-v4": "5.7.4",
     "croner": "^10.0.1",
     "dotenv-flow": "^4.1.0",
     "fast-xml-parser": "^5.11.1",
@@ -125,7 +132,7 @@
   },
   "devDependencies": {
     "@eslint/js": "^10.0.1",
-    "@openai/codex-sdk": "0.159.2",
+    "@openai/codex-sdk": "0.160.1",
     "@types/node": "^24.0.0",
     "@types/papaparse": "^5.5.2",
     "@types/pg": "8.23.1",

package/prisma/migrations/20261009000003_native_execution_mode/migration.sql

@@ -0,0 +1,12 @@
+-- Additive: per-agent native execution mode (control-plane or sandbox) and the
+-- per-run snapshot the executor routes on. Existing agents default to
+-- control-plane; existing runs keep a null snapshot (legacy = control plane).
+
+-- CreateEnum
+CREATE TYPE "NativeExecutionMode" AS ENUM ('control-plane', 'sandbox');
+
+-- AlterTable
+ALTER TABLE "Agent" ADD COLUMN "nativeExecutionMode" "NativeExecutionMode" NOT NULL DEFAULT 'control-plane';
+
+-- AlterTable
+ALTER TABLE "Run" ADD COLUMN "nativeExecutionMode" "NativeExecutionMode";

package/prisma/migrations/20261009000004_native_gateway_ledger/migration.sql

@@ -0,0 +1,65 @@
+-- Additive: the native sandbox gateway's session and call ledger. A session
+-- authenticates a sandbox worker by capability hash and pins what its run
+-- loaded; calls reserve and settle model spend and keep replayable results.
+
+-- CreateEnum
+CREATE TYPE "NativeGatewaySessionStatus" AS ENUM ('active', 'finished', 'cancelled');
+
+-- CreateEnum
+CREATE TYPE "NativeGatewayCallStatus" AS ENUM ('reserved', 'completed', 'released', 'uncertain', 'pending', 'waiting_budget');
+
+-- CreateTable
+CREATE TABLE "NativeGatewaySession" (
+    "id" TEXT NOT NULL,
+    "runId" TEXT NOT NULL,
+    "capabilityHash" TEXT NOT NULL,
+    "status" "NativeGatewaySessionStatus" NOT NULL DEFAULT 'active',
+    "deadlineAt" TIMESTAMP(3) NOT NULL,
+    "budgetUsd" DECIMAL(18,10) NOT NULL,
+    "snapshot" JSONB NOT NULL,
+    "budgetExhaustedAt" TIMESTAMP(3),
+    "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    "updatedAt" TIMESTAMP(3) NOT NULL,
+
+    CONSTRAINT "NativeGatewaySession_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateTable
+CREATE TABLE "NativeGatewayCall" (
+    "id" TEXT NOT NULL,
+    "sessionId" TEXT NOT NULL,
+    "callId" TEXT NOT NULL,
+    "method" TEXT NOT NULL,
+    "status" "NativeGatewayCallStatus" NOT NULL,
+    "reservationUsd" DECIMAL(18,10),
+    "actualCostUsd" DECIMAL(18,10),
+    "inputTokens" INTEGER,
+    "outputTokens" INTEGER,
+    "cachedInputTokens" INTEGER,
+    "cacheWriteTokens" INTEGER,
+    "result" JSONB,
+    "childRunId" TEXT,
+    "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    "updatedAt" TIMESTAMP(3) NOT NULL,
+    "completedAt" TIMESTAMP(3),
+
+    CONSTRAINT "NativeGatewayCall_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateIndex
+CREATE UNIQUE INDEX "NativeGatewaySession_runId_key" ON "NativeGatewaySession"("runId");
+
+-- CreateIndex
+CREATE UNIQUE INDEX "NativeGatewaySession_capabilityHash_key" ON "NativeGatewaySession"("capabilityHash");
+
+-- CreateIndex
+CREATE INDEX "NativeGatewayCall_sessionId_status_idx" ON "NativeGatewayCall"("sessionId", "status");
+
+-- CreateIndex
+CREATE UNIQUE INDEX "NativeGatewayCall_sessionId_callId_key" ON "NativeGatewayCall"("sessionId", "callId");
+
+-- AddForeignKey
+ALTER TABLE "NativeGatewaySession" ADD CONSTRAINT "NativeGatewaySession_runId_fkey" FOREIGN KEY ("runId") REFERENCES "Run"("id") ON DELETE CASCADE ON UPDATE CASCADE;
+
+-- AddForeignKey
+ALTER TABLE "NativeGatewayCall" ADD CONSTRAINT "NativeGatewayCall_sessionId_fkey" FOREIGN KEY ("sessionId") REFERENCES "NativeGatewaySession"("id") ON DELETE CASCADE ON UPDATE CASCADE;

package/prisma/migrations/20261009000005_native_gateway_call_child_agent/migration.sql

@@ -0,0 +1,5 @@
+-- Additive: a delegation's sub-agent on its gateway call row, so a delegation
+-- waiting for budget holds its place in the per-run delegation limit.
+
+-- AlterTable
+ALTER TABLE "NativeGatewayCall" ADD COLUMN "childAgentId" TEXT;

package/prisma/migrations/20261009000006_run_deferred_start_stop/migration.sql

@@ -0,0 +1,14 @@
+-- Additive: runs dispatched (or asked to stop) by a process that holds no
+-- executor -- the native sandbox gateway -- are started (or stopped) by the
+-- scheduler leader through the server's executor.
+
+-- AlterTable
+ALTER TABLE "Run" ADD COLUMN "startDeferredAt" TIMESTAMP(3),
+ADD COLUMN "stopRequestedAt" TIMESTAMP(3),
+ADD COLUMN "stopRequestReason" TEXT;
+
+-- CreateIndex
+CREATE INDEX "Run_startDeferredAt_idx" ON "Run"("startDeferredAt");
+
+-- CreateIndex
+CREATE INDEX "Run_stopRequestedAt_idx" ON "Run"("stopRequestedAt");

package/prisma/migrations/20261009000007_native_gateway_network_ready/migration.sql

@@ -0,0 +1,5 @@
+-- Additive: when a native sandbox worker's network isolation was proven. The
+-- gateway serves a session only once this is set.
+
+-- AlterTable
+ALTER TABLE "NativeGatewaySession" ADD COLUMN "networkReadyAt" TIMESTAMP(3);

package/prisma/migrations/20261010000001_workflow_notifications/migration.sql

@@ -0,0 +1,99 @@
+-- Workflow notifications (Slack): channel links, the event outbox, per-channel
+-- deliveries, and thread parents. Additive only.
+
+CREATE TABLE "NotificationChannel" (
+    "id" TEXT NOT NULL,
+    "provider" TEXT NOT NULL,
+    "channelId" TEXT NOT NULL,
+    "channelName" TEXT,
+    "issueProvider" TEXT,
+    "projectKey" TEXT,
+    "agentId" TEXT,
+    "events" TEXT[] DEFAULT ARRAY[]::TEXT[],
+    "includeCost" BOOLEAN NOT NULL DEFAULT false,
+    "lastError" TEXT,
+    "lastErrorAt" TIMESTAMP(3),
+    "authorizedById" TEXT NOT NULL,
+    "authorizedAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    CONSTRAINT "NotificationChannel_pkey" PRIMARY KEY ("id"),
+    CONSTRAINT "NotificationChannel_one_subject" CHECK (
+        ("agentId" IS NOT NULL AND "issueProvider" IS NULL AND "projectKey" IS NULL)
+        OR ("agentId" IS NULL AND "issueProvider" IS NOT NULL AND "projectKey" IS NOT NULL)
+    )
+);
+
+-- Name truncated the way Prisma does for PostgreSQL's 63-byte identifier limit,
+-- so `migrate diff` sees it as the @@unique([provider, channelId, issueProvider, projectKey]).
+-- The one-subject CHECK above has no schema.prisma equivalent; migrate diff ignores it.
+CREATE UNIQUE INDEX "NotificationChannel_provider_channelId_issueProvider_projec_key"
+    ON "NotificationChannel"("provider", "channelId", "issueProvider", "projectKey");
+CREATE UNIQUE INDEX "NotificationChannel_provider_channelId_agentId_key"
+    ON "NotificationChannel"("provider", "channelId", "agentId");
+CREATE INDEX "NotificationChannel_issueProvider_projectKey_idx"
+    ON "NotificationChannel"("issueProvider", "projectKey");
+CREATE INDEX "NotificationChannel_agentId_idx" ON "NotificationChannel"("agentId");
+
+ALTER TABLE "NotificationChannel" ADD CONSTRAINT "NotificationChannel_agentId_fkey"
+    FOREIGN KEY ("agentId") REFERENCES "Agent"("id") ON DELETE CASCADE ON UPDATE CASCADE;
+
+CREATE TABLE "WorkflowEvent" (
+    "id" TEXT NOT NULL,
+    "kind" TEXT NOT NULL,
+    "dedupeKey" TEXT NOT NULL,
+    "runId" TEXT,
+    "agentId" TEXT,
+    "workItemProvider" TEXT,
+    "workItemKey" TEXT,
+    "codeProvider" TEXT,
+    "repository" TEXT,
+    "prNumber" INTEGER,
+    "payload" JSONB NOT NULL,
+    "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    CONSTRAINT "WorkflowEvent_pkey" PRIMARY KEY ("id")
+);
+
+CREATE UNIQUE INDEX "WorkflowEvent_dedupeKey_key" ON "WorkflowEvent"("dedupeKey");
+CREATE INDEX "WorkflowEvent_createdAt_idx" ON "WorkflowEvent"("createdAt");
+
+CREATE TABLE "NotificationDelivery" (
+    "id" TEXT NOT NULL,
+    "eventId" TEXT NOT NULL,
+    "provider" TEXT NOT NULL,
+    "channelId" TEXT NOT NULL,
+    "threadKey" TEXT NOT NULL,
+    "includeCost" BOOLEAN NOT NULL DEFAULT false,
+    "state" TEXT NOT NULL DEFAULT 'pending',
+    "attempts" INTEGER NOT NULL DEFAULT 0,
+    "nextAttemptAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    "lastError" TEXT,
+    "messageTs" TEXT,
+    "deliveredAt" TIMESTAMP(3),
+    "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    CONSTRAINT "NotificationDelivery_pkey" PRIMARY KEY ("id")
+);
+
+CREATE UNIQUE INDEX "NotificationDelivery_eventId_provider_channelId_key"
+    ON "NotificationDelivery"("eventId", "provider", "channelId");
+CREATE INDEX "NotificationDelivery_state_nextAttemptAt_idx"
+    ON "NotificationDelivery"("state", "nextAttemptAt");
+CREATE INDEX "NotificationDelivery_provider_channelId_threadKey_createdAt_idx"
+    ON "NotificationDelivery"("provider", "channelId", "threadKey", "createdAt");
+
+ALTER TABLE "NotificationDelivery" ADD CONSTRAINT "NotificationDelivery_eventId_fkey"
+    FOREIGN KEY ("eventId") REFERENCES "WorkflowEvent"("id") ON DELETE CASCADE ON UPDATE CASCADE;
+
+CREATE TABLE "NotificationThread" (
+    "id" TEXT NOT NULL,
+    "provider" TEXT NOT NULL,
+    "channelId" TEXT NOT NULL,
+    "threadKey" TEXT NOT NULL,
+    "parentTs" TEXT NOT NULL,
+    "status" TEXT NOT NULL,
+    "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    "updatedAt" TIMESTAMP(3) NOT NULL,
+    CONSTRAINT "NotificationThread_pkey" PRIMARY KEY ("id")
+);
+
+CREATE UNIQUE INDEX "NotificationThread_provider_channelId_threadKey_key"
+    ON "NotificationThread"("provider", "channelId", "threadKey");

package/prisma/migrations/20261011000001_native_gateway_session_status_index/migration.sql

@@ -0,0 +1,2 @@
+-- NATIVE_SANDBOX_MAX_CONCURRENT counts the active native gateway sessions on every sandbox start.
+CREATE INDEX "NativeGatewaySession_status_idx" ON "NativeGatewaySession"("status");

package/prisma/migrations/20261012000001_native_warm_worker/migration.sql

@@ -0,0 +1,32 @@
+-- Additive: the native sandbox warm pool. One row per pool worker, inserted
+-- before the worker exists; a run claims an idle row with a conditional update.
+
+-- CreateEnum
+CREATE TYPE "NativeWarmWorkerStatus" AS ENUM ('warming', 'idle', 'claimed', 'retiring');
+
+-- CreateTable
+CREATE TABLE "NativeWarmWorker" (
+    "id" TEXT NOT NULL,
+    "name" TEXT NOT NULL,
+    "status" "NativeWarmWorkerStatus" NOT NULL DEFAULT 'warming',
+    "specHash" TEXT NOT NULL,
+    "runId" TEXT,
+    "readyAt" TIMESTAMP(3),
+    "claimedAt" TIMESTAMP(3),
+    "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    "updatedAt" TIMESTAMP(3) NOT NULL,
+
+    CONSTRAINT "NativeWarmWorker_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateIndex
+CREATE UNIQUE INDEX "NativeWarmWorker_name_key" ON "NativeWarmWorker"("name");
+
+-- CreateIndex
+CREATE UNIQUE INDEX "NativeWarmWorker_runId_key" ON "NativeWarmWorker"("runId");
+
+-- CreateIndex
+CREATE INDEX "NativeWarmWorker_status_specHash_idx" ON "NativeWarmWorker"("status", "specHash");
+
+-- AddForeignKey
+ALTER TABLE "NativeWarmWorker" ADD CONSTRAINT "NativeWarmWorker_runId_fkey" FOREIGN KEY ("runId") REFERENCES "Run"("id") ON DELETE SET NULL ON UPDATE CASCADE;

package/prisma/migrations/20261013000001_coding_run_merge_order/migration.sql

@@ -0,0 +1,2 @@
+-- Additive: the merge step a delegating agent assigned to this coding run.
+ALTER TABLE "CodingRun" ADD COLUMN "mergeOrder" INTEGER;