@wardby/cli 0.2.1 → 0.3.0

package/help/github.md

@@ -0,0 +1,30 @@
+---
+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]
+appliesTo: >=0.2.1
+---
+
+# Connect GitHub repositories
+
+Wardby uses a GitHub App installed only on the repositories an agent may use.
+Repository access is checked against the agent owner's linked GitHub account,
+or an explicitly recorded administrator approval. Coding agents need write
+access because they can push a branch and open a draft pull request.
+
+Wardby rechecks access before preparing a coding workspace and again before
+pushing. Losing access, unlinking the account, or a failed access check stops
+the run without publishing changes. See [Repository-access troubleshooting](troubleshooting/repository-access.md)
+for the resulting refusal states.
+
+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.
+
+Read [`docs/coding-agent-setup.md`](../docs/coding-agent-setup.md) for coding
+agent setup and [`docs/code-review-agents.md`](../docs/code-review-agents.md)
+for pull-request review agents and webhook configuration.
+Use [Run GitHub code-review agents](code-review-agents.md) for the operator
+overview of checks, mentions, and fork limitations.

package/help/identity-and-access.md

@@ -0,0 +1,39 @@
+---
+id: identity-and-access
+title: Configure identity and privileged access
+summary: Protect remote MCP access with an OAuth/OIDC provider and restrict sensitive operations with scopes and roles.
+audience: operator
+tags: [identity, oauth, oidc, access-control, mcp]
+appliesTo: >=0.2.1
+---
+
+# Configure identity and privileged access
+
+Local stdio MCP created by `wardby quickstart` trusts the local operator. A
+shared HTTPS deployment needs an OAuth/OIDC identity provider. In delegating
+mode, that provider authenticates the caller and issues a signed JWT access
+token; Wardby verifies the token and enforces its scopes without administering
+the provider's users or exchanging authorization codes.
+
+Set the provider's resource audience, `MCP_CANONICAL_URI`, and `AUTH_AUDIENCE`
+to the exact same public MCP URL. Tokens need a stable subject, expiry, issuer,
+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, and memory. Three
+sensitive permissions have an additional role requirement:
+
+- `agents:admin` requires the Wardby `admin` role.
+- `packages:approve` requires the `admin` or `package-approver` role.
+- `services:manage` requires the `admin` or `service-manager` role.
+
+Map roles only from an IdP claim that users cannot self-assign. Removing a
+role affects the next token the caller receives.
+
+When you upgrade a delegating-mode deployment, define any newly advertised
+scope, such as `services:manage`, in the provider before deploying. Clients
+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.

package/help/mcp.md

@@ -0,0 +1,30 @@
+---
+id: mcp-access
+title: Connect an MCP client
+summary: Use Wardby's local stdio or protected HTTP MCP transport safely.
+audience: developer
+tags: [mcp, oauth, codex, claude-code]
+appliesTo: >=0.2.1
+---
+
+# Connect an MCP client
+
+For local use, `wardby quickstart` can register the local stdio MCP server with
+Codex or Claude Code. Local stdio trusts the local operator.
+
+For remote access, Wardby exposes an OAuth 2.1-protected HTTP resource server.
+Run the service with `MCP_TRANSPORT=http`, set a canonical public URI, and use
+the instance's configured identity-provider mode. Keep the MCP endpoint behind
+your intended ingress and authentication boundary.
+
+MCP clients use Wardby to manage agents, budgets, tools, schedules, secrets,
+datastores, and runs. They do not receive the provider or GitHub App
+credentials held by Wardby's trusted components.
+
+With the existing `agents:read` scope, clients can also use `search_help` to
+find bundled self-hosted guidance with fuzzy matching and `get_help_article`
+to read a complete article by id. These tools use the same release-bundled,
+offline catalog as `wardby help`; they expose no instance data or credentials.
+
+See [`docs/getting-started-identity-provider.md`](../docs/getting-started-identity-provider.md)
+for the supported self-hosted and delegated identity-provider setup.

package/help/native-capabilities.md

@@ -0,0 +1,30 @@
+---
+id: native-capabilities
+title: Use native agents, tools, and data
+summary: Attach scoped tools, secrets, datastores, memory, schedules, and sub-agents to a native Wardby agent.
+audience: developer
+tags: [agents, tools, secrets, datastores, memory, schedules, subagents]
+appliesTo: >=0.2.1
+---
+
+# Use native agents, tools, and data
+
+Native agents work through the Wardby control plane rather than a repository
+checkout. Give each agent only the capabilities its job needs:
+
+- **Tools** for approved external actions or APIs.
+- **Secrets** as bindings to tools or agents; values remain in Wardby's trusted
+  components rather than being returned through MCP.
+- **Datastores** for scoped application data and queries.
+- **Memory** for agent-owned durable context.
+- **Schedules and webhooks** to start event-driven work.
+- **Sub-agents** for delegated, bounded work with their own capability set.
+
+Use a budget or shared budget group on every agent, and inspect runs before
+expanding its access. An access grant is intentional delegation: use it only
+when an owner permits one agent to use another resource. Creating or changing
+tools, secrets, datastores, schedules, webhooks, memory, and budget groups
+requires the matching MCP scope.
+
+See [Operate agents](operating-agents.md) for run and budget management, and
+[`README.md`](../README.md) for the feature overview and MCP operations.

package/help/observability.md

@@ -0,0 +1,41 @@
+---
+id: observability
+title: Monitor Wardby
+summary: Scrape private Prometheus metrics and build production alerting around the coding proxy and run lifecycle.
+audience: operator
+tags: [observability, prometheus, grafana, metrics, operations]
+appliesTo: >=0.2.1
+---
+
+# Monitor Wardby
+
+When `METRICS_BIND` is configured, Wardby's coding proxy exposes Prometheus
+metrics at `/metrics`. Keep that endpoint on a private network and permit only
+your collector to scrape it. Metrics cover proxy requests, errors, latency,
+audit events, model cost, reserved and actual budget spend, coding outcomes,
+and Node.js process health; they intentionally exclude prompts, repository
+content, credentials, diffs, raw worker output, and run identifiers.
+
+For a local dashboard stack, run:
+
+```sh
+npm run observability:up
+npm run observability:smoke
+```
+
+This starts Prometheus and Grafana locally. Use `npm run observability:down`
+when finished.
+
+In production, configure your own Prometheus-compatible collector, retention,
+private connectivity, alerts, and SLOs. GCP operators can use the Ops Agent or
+Managed Service for Prometheus; AWS operators can use the CloudWatch Agent
+Prometheus collector. Wardby's reference cloud deployments do not provision
+them, and application/MCP metrics are currently narrower than coding-proxy
+metrics.
+
+Alert on proxy failures, budget cutoffs, cleanup failures, stalled runs, and
+sustained latency or memory growth. Wardby's database remains the source of
+truth for runs, budgets, and accounting.
+
+Read [`docs/observability.md`](../docs/observability.md) for configuration and
+the full production checklist.

package/help/operating-agents.md

@@ -0,0 +1,30 @@
+---
+id: operating-agents
+title: Operate managed agents
+summary: Understand the identity, budget, capabilities, triggers, and result of a Wardby-managed agent.
+audience: operator
+tags: [agents, budgets, schedules, runs]
+appliesTo: >=0.2.1
+---
+
+# Operate managed agents
+
+Every Wardby-managed agent has an owner, system prompt, model, per-run budget,
+and explicitly attached capabilities. A run starts only when its identity,
+policy, and available budget agree.
+
+Create, update, pause, trigger, and inspect agents through Wardby's MCP tools.
+The CLI is the bootstrap and operations fallback. Scheduled work requires a
+running scheduler: `wardby serve` runs MCP, scheduler, and reconciliation in
+one process; `wardby mcp` alone does not execute schedules.
+
+Use [Choose a native or coding agent](creating-agents.md) to select the least
+powerful execution model that can safely produce the desired outcome.
+
+Before a run starts, Wardby reserves its allowed spend. The reservation is
+constrained by the agent's own budget, any shared budget group, and any
+sub-agent run tree. See [Budget troubleshooting](troubleshooting/budgets.md)
+when a run is refused for lack of budget.
+
+For the full lifecycle and the controls applied to every managed run, read
+[`README.md`](../README.md).

package/help/security.md

@@ -0,0 +1,27 @@
+---
+id: security-boundaries
+title: Understand Wardby security boundaries
+summary: Review the isolation, credential, budget, and action-authority controls that apply to managed work.
+audience: operator
+tags: [security, isolation, credentials, budgets]
+appliesTo: >=0.2.1
+---
+
+# Understand Wardby security boundaries
+
+Wardby is designed to make agent work bounded and reviewable. It applies hard
+per-agent and shared-budget limits, grants only explicitly attached tools,
+secrets, datastores, and sub-agents, and records a durable result.
+
+Native tools run in a constrained QuickJS environment. Coding agents use
+isolated workers with bounded resources and a trusted proxy. Workers do not
+receive provider credentials or the GitHub App private key. Coding finalization
+creates a draft pull request; it does not grant the worker merge authority.
+
+Treat the deployment boundary as part of the security model. Restrict Docker or
+Kubernetes administrator access, protect secrets, constrain network egress,
+and read the deployment guide before enabling a production repository.
+
+See [`docs/security-deployment.md`](../docs/security-deployment.md) and
+[`docs/coding-worker-isolation.md`](../docs/coding-worker-isolation.md) for
+the detailed operational model.

package/help/troubleshooting/budgets.md

@@ -0,0 +1,26 @@
+---
+id: troubleshooting/budgets
+title: Troubleshoot budgets and reservations
+summary: Diagnose run refusals caused by an exhausted agent, shared budget group, or sub-agent run tree.
+audience: operator
+tags: [budgets, reservations, refusals, scheduling]
+appliesTo: >=0.2.1
+---
+
+# Troubleshoot budgets and reservations
+
+Wardby reserves budget when it dispatches a run. The reservation is limited by
+the agent's `budgetUsd`, the remaining shared daily, weekly, or monthly budget
+group capacity, and the remaining parent run-tree capacity for a sub-agent.
+
+When no capacity remains, Wardby records the run as refused and does not start
+a worker. Common errors include `budget_group_exhausted:day`,
+`budget_group_exhausted:week`, `budget_group_exhausted:month`, and
+`run_tree_exhausted`.
+
+Inspect the agent, its budget group, and recent runs before increasing a limit.
+In-progress runs retain their unspent reservation, so overlapping scheduled,
+webhook, and manual runs share one cap rather than each assuming the full
+remaining balance.
+
+For a shared-group refusal, read [Budget group exhausted](../errors/budget-group-exhausted.md).

package/help/troubleshooting/coding-workers.md

@@ -0,0 +1,47 @@
+---
+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]
+appliesTo: >=0.2.1
+---
+
+# Troubleshoot coding workers
+
+Before enabling a coding agent, configure an immutable worker image, the
+trusted coding proxy, a scoped GitHub App installation, and the selected job
+launcher. Run `wardby coding preflight` after changing the Docker or Kubernetes
+configuration.
+
+Wardby refuses to weaken an isolation profile when a required host feature,
+network setting, mount, environment, or cleanup guarantee cannot be verified.
+Investigate the host configuration instead of bypassing the refusal.
+
+Codex and Claude Code workers have different supported launcher combinations.
+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).
+
+## Service refusals and failures
+
+A repository can declare services such as PostgreSQL in `.wardby/services.yaml`
+on its base branch. Wardby checks the declaration, the service catalog, and the
+agent's `codingProfile.services` before a run starts, and refuses the run with a
+`service_*` code when they disagree. The run's `error` (from `get_run`) is the
+code followed by a sentence the requester also sees on the run's status comment.
+
+- [`service_declaration_invalid`](../errors/service-declaration-invalid.md):
+  the file on the base branch is not a valid declaration.
+- [`service_declaration_unavailable`](../errors/service-declaration-unavailable.md):
+  Wardby could not read the file through the GitHub App.
+- [`service_unknown`](../errors/service-unknown.md): the catalog has no such
+  name and version.
+- [`service_not_allowed`](../errors/service-not-allowed.md): the agent does not
+  allow that service.
+- [`service_launcher_unsupported`](../errors/service-launcher-unsupported.md):
+  services need the Kubernetes or Docker job launcher.
+- [`service_unready`](../errors/service-unready.md): the run started but a
+  service never became ready (launcher error `coding_service_unready:<name>`).
+
+See [Coding services](../coding-services.md).

package/help/troubleshooting/repository-access.md

@@ -0,0 +1,27 @@
+---
+id: troubleshooting/repository-access
+title: Troubleshoot repository access
+summary: Diagnose why Wardby refused repository work or could not verify the agent owner's GitHub access.
+audience: operator
+tags: [github, repositories, authorization, refusals]
+appliesTo: >=0.2.1
+---
+
+# Troubleshoot repository access
+
+Wardby checks that the owner of a coding or repository-linked agent has the
+required current GitHub permission. A coding repository requires write access;
+a read-only repository link requires read access. An administrator can record a
+repository approval when no individual's access is appropriate.
+
+`repo_access` means the current owner no longer has the required permission,
+has unlinked their account, or the repository was not authorized. Restore the
+owner's GitHub link and permission, or have an administrator review and record
+the appropriate repository authorization.
+
+`repo_access_unavailable` means Wardby could not verify GitHub access after its
+retry. Do not treat it as permission granted: resolve the GitHub/API condition
+and re-run the work later.
+
+Read [Repository access refused](../errors/repo-access.md) for the safe
+remediation sequence.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wardby/cli",
-  "version": "0.2.1",
+  "version": "0.3.0",
   "description": "Self-hosted control plane for budget-guarded AI agents.",
   "license": "Apache-2.0",
   "homepage": "https://github.com/wardby/wardby#readme",
@@ -35,8 +35,10 @@
     ".env.example",
     "NOTICE",
     "bin/",
+    "docs/",
     "deploy/local/docker-compose.yml",
     "dist/",
+    "help/",
     "prisma/migrations/",
     "prisma/migrate.config.mjs",
     "prisma/schema.prisma",
@@ -52,7 +54,8 @@
     "format": "prettier --write .",
     "format:check": "prettier --check .",
     "build:vendor": "node scripts/build-sandbox-vendor.mjs",
-    "build": "npm run build:vendor && PRISMA_HIDE_UPDATE_MESSAGE=1 prisma generate && tsc -p tsconfig.build.json",
+    "build:help": "tsx src/help/build.ts",
+    "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",
@@ -63,6 +66,7 @@
     "test:kubernetes": "WARDBY_KUBERNETES_TEST=1 vitest run src/providers/jobs/kubernetes.integration.test.ts",
     "prisma:generate": "PRISMA_HIDE_UPDATE_MESSAGE=1 prisma generate",
     "prisma:migrate": "prisma migrate deploy",
+    "dbos:migrate": "dbos schema \"$DATABASE_URL\"",
     "db:up": "docker compose -f deploy/local/docker-compose.yml up -d",
     "db:down": "docker compose -f deploy/local/docker-compose.yml down",
     "coding:local:up": "docker compose --env-file .env.local -f deploy/local/docker-compose.yml -f deploy/local/docker-compose.phase5.yml up --build -d coding-proxy",
@@ -76,7 +80,8 @@
     "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",
-    "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 .",
+    "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 .",
     "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",
@@ -94,9 +99,11 @@
     "@prisma/adapter-pg": "7.10.0",
     "@prisma/client": "7.10.0",
     "@prometheus-io/client": "^0.16.1",
+    "@renovatebot/pep440": "^5.0.1",
     "croner": "^10.0.1",
     "dotenv-flow": "^4.1.0",
     "fast-xml-parser": "^5.11.1",
+    "fflate": "^0.8.3",
     "gpt-tokenizer": "^2.5.0",
     "jose": "^6.2.12",
     "node-html-parser": "^9.0.3",
@@ -105,6 +112,7 @@
     "pg": "8.23.0",
     "pino": "^9.14.0",
     "quickjs-emscripten": "^0.32.0",
+    "semver": "^7.8.5",
     "tar-stream": "^3.2.1",
     "undici": "^8.7.0",
     "zod": "^3.25.76",
@@ -116,6 +124,7 @@
     "@types/node": "^24.0.0",
     "@types/papaparse": "^5.5.2",
     "@types/pg": "8.23.1",
+    "@types/semver": "^7.8.0",
     "@types/tar-stream": "^3.1.4",
     "esbuild": "^0.28.2",
     "eslint": "^10.10.0",

package/prisma/migrations/20260925010000_coding_collect_exclude/migration.sql

@@ -0,0 +1,8 @@
+-- Additive: per-agent workspace paths never collected from a coding run. See
+-- docs/superpowers/specs/2026-09-25-coding-package-registry-design.md §4.
+
+-- AlterTable
+ALTER TABLE "CodingAgentProfile" ADD COLUMN     "collectExclude" JSONB NOT NULL DEFAULT '[]';
+
+-- AlterTable
+ALTER TABLE "CodingRun" ADD COLUMN     "collectExclude" JSONB NOT NULL DEFAULT '[]';

package/prisma/migrations/20260925015000_allowed_egress_default/migration.sql

@@ -0,0 +1,8 @@
+-- allowedEgress was stored but never enforced and is no longer written. A default
+-- lets new rows omit it; the columns are dropped in a later release.
+
+-- AlterTable
+ALTER TABLE "CodingAgentProfile" ALTER COLUMN "allowedEgress" SET DEFAULT '[]';
+
+-- AlterTable
+ALTER TABLE "CodingRun" ALTER COLUMN "allowedEgress" SET DEFAULT '[]';

package/prisma/migrations/20260925020000_coding_package_registry/migration.sql

@@ -0,0 +1,55 @@
+-- Additive: coding package registry. See
+-- docs/superpowers/specs/2026-09-25-coding-package-registry-design.md.
+
+-- CreateEnum
+CREATE TYPE "RegistryFetchOutcome" AS ENUM ('served', 'refused');
+
+-- AlterTable
+ALTER TABLE "CodingAgentProfile" ADD COLUMN     "packageAllowlist" JSONB NOT NULL DEFAULT '{}',
+ADD COLUMN     "packagePolicy" JSONB NOT NULL DEFAULT '{}';
+
+-- AlterTable
+ALTER TABLE "CodingRun" ADD COLUMN     "packageAllowlist" JSONB NOT NULL DEFAULT '{}',
+ADD COLUMN     "packagePolicy" JSONB NOT NULL DEFAULT '{}';
+
+-- AlterTable
+ALTER TABLE "CodingProxySession" ADD COLUMN     "registryTokenHash" TEXT;
+
+-- CreateTable
+CREATE TABLE "RegistryAllowance" (
+    "runId" TEXT NOT NULL,
+    "ecosystem" TEXT NOT NULL,
+    "name" TEXT NOT NULL,
+    "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+
+    CONSTRAINT "RegistryAllowance_pkey" PRIMARY KEY ("runId","ecosystem","name")
+);
+
+-- CreateTable
+CREATE TABLE "RegistryFetch" (
+    "id" TEXT NOT NULL,
+    "runId" TEXT NOT NULL,
+    "ecosystem" TEXT NOT NULL,
+    "name" TEXT NOT NULL,
+    "version" TEXT,
+    "filename" TEXT,
+    "integrity" TEXT,
+    "sizeBytes" INTEGER,
+    "outcome" "RegistryFetchOutcome" NOT NULL,
+    "reason" TEXT,
+    "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+
+    CONSTRAINT "RegistryFetch_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateIndex
+CREATE UNIQUE INDEX "CodingProxySession_registryTokenHash_key" ON "CodingProxySession"("registryTokenHash");
+
+-- CreateIndex
+CREATE INDEX "RegistryFetch_runId_createdAt_idx" ON "RegistryFetch"("runId", "createdAt");
+
+-- AddForeignKey
+ALTER TABLE "RegistryAllowance" ADD CONSTRAINT "RegistryAllowance_runId_fkey" FOREIGN KEY ("runId") REFERENCES "CodingRun"("runId") ON DELETE CASCADE ON UPDATE CASCADE;
+
+-- AddForeignKey
+ALTER TABLE "RegistryFetch" ADD CONSTRAINT "RegistryFetch_runId_fkey" FOREIGN KEY ("runId") REFERENCES "CodingRun"("runId") ON DELETE CASCADE ON UPDATE CASCADE;

package/prisma/migrations/20260925030000_tool_name_per_owner/migration.sql

@@ -0,0 +1,11 @@
+-- Tool names become unique per owner instead of globally, matching
+-- BudgetGroup / Datastore / Secret. Safe on existing data: global uniqueness
+-- already implies per-owner uniqueness. As with those models, PostgreSQL
+-- treats NULLs as distinct, so public (null-owner) tools are not deduplicated
+-- by this index; `wardby tool create` checks that case in the application.
+
+-- DropIndex
+DROP INDEX "Tool_name_key";
+
+-- CreateIndex
+CREATE UNIQUE INDEX "Tool_ownerId_name_key" ON "Tool"("ownerId", "name");

package/prisma/migrations/20260926010000_run_trigger_host_event/migration.sql

@@ -0,0 +1,7 @@
+-- Additive: a run started by a code-review host event (GitHub App webhook).
+-- Its own migration: Postgres cannot use a newly added enum value in the
+-- same transaction that adds it. See
+-- docs/private/2026-09-25-code-review-host-design.md §4.
+
+-- AlterEnum
+ALTER TYPE "RunTrigger" ADD VALUE 'host_event';

package/prisma/migrations/20260926020000_code_review_hosts/migration.sql

@@ -0,0 +1,53 @@
+-- Additive: repository links for native agents, the check a run owns, and
+-- host webhook delivery de-duplication. See
+-- docs/private/2026-09-25-code-review-host-design.md §4.
+
+-- CreateTable
+CREATE TABLE "AgentRepository" (
+    "id" TEXT NOT NULL,
+    "agentId" TEXT NOT NULL,
+    "provider" TEXT NOT NULL,
+    "repository" TEXT NOT NULL,
+    "access" TEXT NOT NULL,
+    "triggers" TEXT[] DEFAULT ARRAY[]::TEXT[],
+    "checkName" TEXT,
+    "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+
+    CONSTRAINT "AgentRepository_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateTable
+CREATE TABLE "RunHostCheck" (
+    "runId" TEXT NOT NULL,
+    "provider" TEXT NOT NULL,
+    "repository" TEXT NOT NULL,
+    "checkId" TEXT NOT NULL,
+    "headSha" TEXT NOT NULL,
+    "completedAt" TIMESTAMP(3),
+
+    CONSTRAINT "RunHostCheck_pkey" PRIMARY KEY ("runId")
+);
+
+-- CreateTable
+CREATE TABLE "HostEventDelivery" (
+    "provider" TEXT NOT NULL,
+    "deliveryId" TEXT NOT NULL,
+    "receivedAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+
+    CONSTRAINT "HostEventDelivery_pkey" PRIMARY KEY ("provider","deliveryId")
+);
+
+-- CreateIndex
+CREATE UNIQUE INDEX "AgentRepository_agentId_provider_repository_key" ON "AgentRepository"("agentId", "provider", "repository");
+
+-- CreateIndex
+CREATE INDEX "AgentRepository_provider_repository_idx" ON "AgentRepository"("provider", "repository");
+
+-- CreateIndex
+CREATE INDEX "HostEventDelivery_receivedAt_idx" ON "HostEventDelivery"("receivedAt");
+
+-- AddForeignKey
+ALTER TABLE "AgentRepository" ADD CONSTRAINT "AgentRepository_agentId_fkey" FOREIGN KEY ("agentId") REFERENCES "Agent"("id") ON DELETE CASCADE ON UPDATE CASCADE;
+
+-- AddForeignKey
+ALTER TABLE "RunHostCheck" ADD CONSTRAINT "RunHostCheck_runId_fkey" FOREIGN KEY ("runId") REFERENCES "Run"("id") ON DELETE CASCADE ON UPDATE CASCADE;

package/prisma/migrations/20260926030000_auth_user_roles/migration.sql

@@ -0,0 +1,9 @@
+-- Additive: roles for self-hosted users (security finding A1). A privileged
+-- operation (make_owner, setting workerImageRef, package approval) needs its
+-- scope on the token AND one of the user's roles granting it, checked on
+-- every request. Role names are validated in code (admin, package-approver).
+-- Existing users get no roles (member) - an operator re-grants admin with
+-- `wardby auth user grant --subject <subject> --role admin`.
+
+-- AlterTable
+ALTER TABLE "AuthUser" ADD COLUMN     "roles" TEXT[] DEFAULT ARRAY[]::TEXT[];

package/prisma/migrations/20260926040000_agent_effort/migration.sql

@@ -0,0 +1,6 @@
+-- Additive: per-agent reasoning effort for native agents. Nullable, so every
+-- existing agent keeps the provider's default. Levels are validated in code
+-- against the agent's model (low, medium, high, xhigh, max), not a DB enum.
+
+-- AlterTable
+ALTER TABLE "Agent" ADD COLUMN "effort" TEXT;

package/prisma/migrations/20260926050000_registry_lockfile_plan/migration.sql

@@ -0,0 +1,32 @@
+-- Additive: npm lockfile verification (POST /registry/npm/-/plan). See
+-- docs/coding-packages.md. Immutable per-version facts read from the
+-- registry, and the exact versions a run's lockfile plan approved.
+
+-- CreateTable
+CREATE TABLE "RegistryVersionFact" (
+    "ecosystem" TEXT NOT NULL,
+    "name" TEXT NOT NULL,
+    "version" TEXT NOT NULL,
+    "publishedAt" TIMESTAMP(3) NOT NULL,
+    "integrity" TEXT NOT NULL,
+    "downloadUrl" TEXT NOT NULL,
+    "dependencies" JSONB NOT NULL,
+    "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+
+    CONSTRAINT "RegistryVersionFact_pkey" PRIMARY KEY ("ecosystem","name","version")
+);
+
+-- CreateTable
+CREATE TABLE "RegistryApprovedVersion" (
+    "runId" TEXT NOT NULL,
+    "ecosystem" TEXT NOT NULL,
+    "name" TEXT NOT NULL,
+    "version" TEXT NOT NULL,
+    "integrity" TEXT NOT NULL,
+    "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+
+    CONSTRAINT "RegistryApprovedVersion_pkey" PRIMARY KEY ("runId","ecosystem","name","version")
+);
+
+-- AddForeignKey
+ALTER TABLE "RegistryApprovedVersion" ADD CONSTRAINT "RegistryApprovedVersion_runId_fkey" FOREIGN KEY ("runId") REFERENCES "CodingRun"("runId") ON DELETE CASCADE ON UPDATE CASCADE;