@bridge_gpt/mcp-server 0.2.51 → 0.2.53

package/README.md

@@ -352,7 +352,7 @@ later boot.
   "mcpServers": {
     "bridge": {
       "command": "npx",
-      "args": ["-y", "--prefer-offline", "@bridge_gpt/mcp-server@0.2.51", "serve"],
+      "args": ["-y", "--prefer-offline", "@bridge_gpt/mcp-server@0.2.53", "serve"],
       "env": {
         "BAPI_BASE_URL": "https://bridgegpt-api.com",
         "BAPI_REPO_NAME": "your-repo",
@@ -374,7 +374,7 @@ later boot.
     "bridge": {
       "type": "stdio",
       "command": "npx",
-      "args": ["-y", "--prefer-offline", "@bridge_gpt/mcp-server@0.2.51", "serve"],
+      "args": ["-y", "--prefer-offline", "@bridge_gpt/mcp-server@0.2.53", "serve"],
       "env": {
         "BAPI_BASE_URL": "https://bridgegpt-api.com",
         "BAPI_REPO_NAME": "your-repo",
@@ -396,7 +396,7 @@ later boot.
     "bridge": {
       "type": "stdio",
       "command": "npx",
-      "args": ["-y", "--prefer-offline", "@bridge_gpt/mcp-server@0.2.51", "serve"],
+      "args": ["-y", "--prefer-offline", "@bridge_gpt/mcp-server@0.2.53", "serve"],
       "env": {
         "BAPI_BASE_URL": "https://bridgegpt-api.com",
         "BAPI_REPO_NAME": "your-repo",
@@ -421,7 +421,7 @@ you select `copilot-cli`; the shape below is what it produces.
     "bridge": {
       "type": "local",
       "command": "npx",
-      "args": ["-y", "--prefer-offline", "@bridge_gpt/mcp-server@0.2.51", "serve"],
+      "args": ["-y", "--prefer-offline", "@bridge_gpt/mcp-server@0.2.53", "serve"],
       "tools": ["*"],
       "env": {
         "BAPI_BASE_URL": "https://bridgegpt-api.com",
@@ -445,7 +445,7 @@ Windsurf only supports global MCP configuration.
   "mcpServers": {
     "bridge": {
       "command": "npx",
-      "args": ["-y", "--prefer-offline", "@bridge_gpt/mcp-server@0.2.51", "serve"],
+      "args": ["-y", "--prefer-offline", "@bridge_gpt/mcp-server@0.2.53", "serve"],
       "env": {
         "BAPI_BASE_URL": "https://bridgegpt-api.com",
         "BAPI_REPO_NAME": "your-repo",
@@ -464,7 +464,7 @@ Windsurf only supports global MCP configuration.
 ```toml
 [mcp_servers.bridge]
 command = "npx"
-args = ["-y", "--prefer-offline", "@bridge_gpt/mcp-server@0.2.51", "serve"]
+args = ["-y", "--prefer-offline", "@bridge_gpt/mcp-server@0.2.53", "serve"]
 
 [mcp_servers.bridge.env]
 BAPI_BASE_URL = "https://bridgegpt-api.com"
@@ -570,7 +570,7 @@ The tools worth knowing for most tickets.
 **1. Review Ticket**
 - **What it does:** Runs a full quality review of a ticket: clarifying questions and a critique plus an alternate-model second opinion, then evaluates the findings and produces a decision page for accepting or rejecting them.
 - **When it's useful:** (Refinement) Right after a ticket is drafted, before anyone starts building — to surface gaps and tighten it.
-- **How to use it:** `/review-ticket BAPI-123` (command only — "review" as free text is easily mistaken for a freehand agent review). For several tickets at once, `/review-tickets BAPI-123 BAPI-456` opens one terminal tab per ticket and reviews them in parallel with no worktrees; every `/review-ticket` flag applies, and `--review KEY=auto,rounds=N` sets per-ticket overrides.
+- **How to use it:** `/review-tickets BAPI-123` (command only — "review" as free text is easily mistaken for a freehand agent review). A single key reviews inline in the current session — no terminal tab, no worktree. For several tickets at once, `/review-tickets BAPI-123 BAPI-456` opens one terminal tab per ticket and reviews them in parallel with no worktrees; every review flag applies, and `--review KEY=auto,rounds=N` sets per-ticket overrides.
 - **Flags:** `--auto` auto-accept findings and skip the approval gates · `--rounds=1` a cheaper single-pass review that still evaluates findings and captures decisions · `--rounds=2` force the full second-opinion review · omit `--rounds` to let the difficulty-adaptive review policy decide.
 
 **2. Start Tickets**
@@ -581,7 +581,7 @@ The tools worth knowing for most tickets.
 
 **3. Review and Start**
 - **What it does:** Spawns one worktree per ticket; each session reviews the ticket inline and, after a per-ticket proceed/halt gate, hands off to a **fresh implementation session** that reuses the same worktree — review and implementation run in two separate agent contexts, not one shared session.
-- **When it's useful:** (Refinement | Implementation | Automation) The **recommended front door** for "review these tickets, then implement the ones that pass," starting from existing ticket keys (unlike `/full-automation`, which only accepts an idea).
+- **When it's useful:** (Refinement | Implementation | Automation) The **recommended front door** for "review these tickets, then implement the ones that pass," starting from existing ticket keys (unlike `/idea-to-pr`, which only accepts an idea).
 - **How to use it:** `/review-and-start BAPI-248 BAPI-250` (single or multiple keys flow through the identical code path).
 - **Flags:** `--auto` auto-approves both the review and the implementation phase of every spawned session · `--rounds=1|2` forwarded to the review phase · `--agent`, `--base-branch`, `--max-parallel`, `--dry-run` mirror `/start-tickets`.
 
@@ -637,6 +637,12 @@ Good to know, but not needed every day.
 - **How to use it:** Ask your agent — "Generate an image of a dashboard showing SOC2 evidence freshness as a traffic-light grid."
 - **Flags:** `provider` openai (`gpt-image-2`) / gemini (Imagen, which adds an invisible SynthID watermark) · `quality` low (default, cheapest) / medium / high · `size` 1024x1024 / 1024x1536 / 1536x1024. The image is saved to `BAPI_DOCS_DIR/images/` and also returned inline.
 
+**6. Create Decision Page**
+- **What it does:** Turns open decisions from the current conversation into an interactive HTML decision page, then folds the submitted answers back into the conversation.
+- **When it's useful:** (Refinement) Use it whenever a conversation has accumulated more open choices than are comfortable to settle in prose — not for a single simple question, which is faster to just ask directly.
+- **How to use it:** `/create-decision-page <topic or open questions>` — e.g. *"how we handle rate limiting"* — or leave it empty to frame the open choices already raised earlier in the conversation.
+- **Flags:** None.
+
 ### Now and then
 
 Useful once in a while.
@@ -688,11 +694,35 @@ Useful once in a while.
 - **When it's useful:** (Architecture | Refinement) When you need a sizing pass across an epic, or across a set of tickets you name explicitly.
 - **How to use it:** `/estimate-epic BAPI-123`
 - **Flags:** Pass an epic key, or an explicit list of ticket keys to estimate as one group.
+
+**9. Regression Check**
+- **What it does:** Runs the deterministic regression-reviewer (lightweight mode) against a proposed code change and reports its blast radius — which real call-sites, tests, mocks, or config the change does and doesn't account for.
+- **When it's useful:** (Correctness) Before merging a change, to see which real callers, tests, or config it leaves unaccounted for.
+- **How to use it:** `/regression-check` reviews the working tree against `HEAD` by default; `/regression-check --diff main...HEAD` reviews an explicit range.
+- **Flags:** `--diff <range>` review a specific diff/PR range instead of the working tree vs. `HEAD` · `--symbols a,b,c` review a not-yet-diffed planned change by naming its symbols directly.
+
+**10. Scan Test Coverage**
+- **What it does:** Scans recently shipped tickets from git history and reports which features have or could gain integration tests, and which can only be smoke tested.
+- **When it's useful:** (Testing) Periodically, to find recently shipped features still missing integration-test coverage and how each could be smoke tested instead.
+- **How to use it:** `/scan-test-coverage` runs incrementally from the last recorded marker in `docs/test-coverage/STATE.md`.
+- **Flags:** `--since=YYYY-MM-DD` override the window start date · `--full` ignore the marker and use a 6-month lookback · `--limit=N` cap the number of features investigated.
+
+**11. Estimate Ticket**
+- **What it does:** One-ticket shortcut over the existing epic estimation capability: estimates a single Jira ticket via the same `estimate_epic` tool.
+- **When it's useful:** (Estimation) When you want one ticket's estimate without typing out an epic key or an explicit ticket list.
+- **How to use it:** `/estimate-ticket BAPI-123`
+- **Flags:** `--allow-partial` the sole optional flag.
+
+**12. Draft Ticket**
+- **What it does:** Delegates to the Jira Ticket Writer to create only a local Markdown draft — it does not create or update a Jira issue.
+- **When it's useful:** (Refinement) When you want a reviewable local ticket draft before committing to an upload workflow.
+- **How to use it:** `/draft-ticket <description>`
+- **Flags:** None.
 <!-- END GENERATED: mcp-tool-documentation -->
 
 ### Workflow commands
 
-Slash commands that drive several tools at once. Start Tickets, Review and Start, and Explore Ticket are documented above under [Regularly useful](#regularly-useful) — the rest live here.
+Slash commands that drive several tools at once. Start Tickets, Review and Start, and Explore Ticket are documented above under [Regularly useful](#regularly-useful); Create Decision Page is documented above under [Occasionally useful](#occasionally-useful); Regression Check and Scan Test Coverage are documented above under [Now and then](#now-and-then) — the rest live here.
 
 **1. Implement Ticket**
 - **What it does:** Full build for one ticket: generate a plan, write the code, commit, open a PR, and monitor CI.
@@ -991,7 +1021,7 @@ Each `KEY` must match `[A-Z]+-[0-9]+` (e.g., `BAPI-248`). The CLI creates/switch
 npx -y @bridge_gpt/mcp-server start-tickets --agent cursor-agent BAPI-248
 ```
 
-**Difficulty-based model routing.** Before launching each agent, the CLI selects an implementation **model tier** from the ticket's `difficulty` (1-2 → cheap, 3-5 → basic, 6+ → premium) and injects it as a `--model` flag at the spawn boundary. The Python backend returns only the coarse tier (`GET /jira/tickets/{KEY}/model-tier`, computing + caching difficulty on demand); this CLI alone maps a tier to the agent-specific alias (`claude`: `haiku`/`sonnet`/`opus`; `cursor-agent`: version-suffixed strings validated against `cursor-agent --list-models`). It is gated per repo by `difficulty_model_routing_enabled` (default **ON**) with an optional `difficulty_model_tier_overrides` JSON map (tier → alias). Routing is **fail-open**: missing credentials, an evaluation failure/timeout, a backend `fallback`, an invalid/unavailable alias, an unadvertised Cursor model, or an agent without `--model` support all default to the **premium** (Opus) model — and when even the premium alias cannot be resolved/validated for the agent, `--model` is omitted (the agent uses its default) — each surfaced as a per-ticket warning rather than failing the spawn. `--dry-run` does **not** create worktrees or open tabs, but it **does** resolve routing read-only to preview the `--model` each tab would use.
+**Difficulty-based model routing.** Before launching each agent, the CLI selects an implementation **model tier** from the ticket's `difficulty` (1-2 → cheap, 3-6 → basic, 7-10 → premium) and injects it as a `--model` flag at the spawn boundary. The Python backend returns only the coarse tier (`GET /jira/tickets/{KEY}/model-tier`, computing + caching difficulty on demand); this CLI alone maps a tier to the agent-specific alias (`claude`: `haiku`/`sonnet`/`opus`; `cursor-agent`: version-suffixed strings validated against `cursor-agent --list-models`). It is gated per repo by `difficulty_model_routing_enabled` (default **ON**) with an optional `difficulty_model_tier_overrides` JSON map (tier → alias). Routing is **fail-open**: missing credentials, an evaluation failure/timeout, a backend `fallback`, an invalid/unavailable alias, an unadvertised Cursor model, or an agent without `--model` support all default to the **premium** (Opus) model — and when even the premium alias cannot be resolved/validated for the agent, `--model` is omitted (the agent uses its default) — each surfaced as a per-ticket warning rather than failing the spawn. `--dry-run` does **not** create worktrees or open tabs, but it **does** resolve routing read-only to preview the `--model` each tab would use.
 
 **Coarse `--tier` override.** Passing `--tier cheap|basic|premium` bypasses **only** the per-ticket difficulty lookup above and applies that one tier to every ticket; the tier is still resolved to an alias through the same agent registry + `difficulty_model_tier_overrides` and validated the same way (including the live `cursor-agent --list-models` check). It is never treated as a raw `--model` alias, and no API key or credential belongs in the spawned command (the CLI resolves credentials itself via `resolveBapiCredentials`). A malformed/unrecognized `--tier` value is **fail-open**: the CLI logs one concise warning and routes every ticket on the premium (Opus) fallback rather than aborting. `/review-and-implement` uses this flag to hand its review-time tier snapshot to the fresh implementation session.
 
@@ -1059,6 +1089,10 @@ unauthorized, or malformed — it escalates and prints no conductor invocation a
 all, because an unknown owner is not the same as a not-ready one. No branch,
 including every error path, ever offers you two paths.
 
+`drive-epic` owns no branch behavior of its own — it forwards `--feature-branch
+<name>` and `--into-base` verbatim to `setup-epic`, which decides the strategy (see
+below). With neither flag, a multi-ticket epic runs on `epic/<KEY>`.
+
 Two conductors is a transitional state. When one is eliminated, `drive-epic` is
 the only thing that changes.
 
@@ -1072,6 +1106,18 @@ npx -y @bridge_gpt/mcp-server setup-epic --epic-key <KEY> --plan-file <path-to-e
 
 The plan sidecar is produced by the `decompose-epic` pipeline step. `setup-epic` validates it locally (unique ticket keys, resolvable dependency references, acyclicity) before sending anything, so a malformed plan fails legibly instead of as a bare HTTP 400. It is **idempotent**: re-running it on an epic that already has a live run reuses that run rather than minting a second one. `--dry-run` validates and previews the calls without mutating anything; `--json` emits a single machine-readable result object.
 
+**The command above uses an epic branch.** For a plan with **two or more** nodes and
+no branch flag, `setup-epic` derives `epic/<KEY>`: every child-ticket PR targets that
+branch, and one draft integration PR targets the repository base branch. This holds on
+every path, CI and `--json` included. A single-node plan keeps the repository base
+branch, matching plain `start-tickets`.
+
+> **Behavior change (BAPI-1009).** The same no-flag command previously ran children
+> directly into the repository base branch. **Pass `--into-base` to restore that**, if
+> your automation depends on it. Pass `--feature-branch <name>` to override the derived
+> name, or to force a branch for a single-node plan. Passing both is a parse error,
+> refused before any file read, credential resolution, or network call.
+
 Once the plan is approved, the **server-side reconciler** picks the run up within ~30s. To execute claimed jobs on your machine, run `executor`:
 
 ```
@@ -1441,7 +1487,7 @@ The full surface, for when you need the complete enumeration. Day-to-day, use [U
 
 ### MCP tools
 
-The authoritative tool catalog covers **70 tools** (enumerated below). What's actually registered in a session depends on `BRIDGE_MCP_PROFILE`: the default `core` profile loads a trimmed subset, and the conductor/pipeline-authoring/SFCC tools are added only under their respective profiles (see [Environment Variables](#environment-variables)). Async AI tools follow a request/get pattern: call the `request_*` tool to kick off generation, then the matching `get_*` tool to retrieve the result (or pass `wait_for_result: true` to poll automatically).
+The authoritative tool catalog covers **73 tools** (enumerated below). What's actually registered in a session depends on `BRIDGE_MCP_PROFILE`: the default `core` profile loads a trimmed subset, and the conductor/pipeline-authoring/SFCC tools are added only under their respective profiles (see [Environment Variables](#environment-variables)). Async AI tools follow a request/get pattern: call the `request_*` tool to kick off generation, then the matching `get_*` tool to retrieve the result (or pass `wait_for_result: true` to poll automatically).
 
 - **Connectivity & identity** — `ping` (its JSON also carries `docs_dir`, `role`, and `customer_type`)
 - **Team & access** — `invite_member` (admin-only; mints a scoped access key for a teammate on an already-configured project — the plaintext key is shown exactly once)
@@ -1462,10 +1508,10 @@ Pipelines are declarative, multi-step workflows your AI agent executes step-by-s
 | Pipeline | Description | Invoke with |
 |---|---|---|
 | `implement-ticket` | Generate a plan, execute the implementation, commit, open a PR, and monitor CI | `/implement-ticket PROJ-123` |
-| `review-ticket` | Full ticket quality review: clarifying questions + critique plus an automatic second-opinion pass, then evaluation and decision capture. The backend owns round orchestration; pass `--rounds=1` for a single-pass review or `--rounds=2` to force the full second-opinion review, or omit `--rounds` to let the backend decide adaptively. | `/review-ticket PROJ-123` |
+| `review-ticket` | Full ticket quality review: clarifying questions + critique plus an automatic second-opinion pass, then evaluation and decision capture. The backend owns round orchestration; pass `--rounds=1` for a single-pass review or `--rounds=2` to force the full second-opinion review, or omit `--rounds` to let the backend decide adaptively. Internal atomic pipeline invoked by `/review-tickets` (inline for one key, spawned per tab for several) and by `/review-and-implement`, `/review-and-start`, `/start-tickets`, and `/conduct-epic`. | `/review-tickets PROJ-123` |
 | `idea-to-ticket` | Turn an idea into a Jira Task/Spike (or Epic + children) with research, dedup, and critique | `/idea-to-ticket "<idea>"` |
 | `plan-epic` | Decompose an epic into sub-tasks with a structured exploration doc for each | `/plan-epic "<epic>"` |
-| `full-automation` | Client-side wrapper: runs the `idea-to-ticket` recipe, then hands the created keys to `/review-and-start --auto` | `/full-automation "<idea>"` |
+| `full-automation` | Client-side wrapper: runs the `idea-to-ticket` recipe, then hands the created keys to `/review-and-start --auto` | `/idea-to-pr "<idea>"` |
 | `learn-repository` | Analyze codebase architecture, testing, review, and documentation standards, then upload to Bridge | `/learn-repository` |
 
 ### Pipeline response envelope

package/build/agent-capabilities/probe-context.js

@@ -20,8 +20,10 @@ import { DEFAULT_PROBE_TIMEOUT_MS, } from "./types.js";
  *   `--trust` is MANDATORY headless or the workspace-trust prompt hangs; cursor has
  *   its own `--workspace` cwd flag. All `OutputFormat` values (including `stream-json`)
  *   pass through the generic `--output-format <fmt>` slot.
- * - claude: `-p [--dangerously-skip-permissions] [--model <m>] [--output-format json|
- *   stream-json --verbose] <prompt>`. Claude has NO working-dir flag — cwd is set via
+ * - claude: `-p [--permission-mode auto|acceptEdits | --dangerously-skip-permissions]
+ *   [--model <m>] [--output-format json|stream-json --verbose] <prompt>`. The
+ *   worker default is `--permission-mode auto` (BAPI-1020); bypass is emitted only
+ *   for the explicit revert posture and for the probe that must still measure it. Claude has NO working-dir flag — cwd is set via
  *   the spawn options, never an argument. `stream-json` REQUIRES `--verbose`. The
  *   prompt is ALWAYS the final argv element so mocked prompt extraction stays valid.
  */
@@ -32,11 +34,17 @@ export function buildHeadlessArgs(agentName, opts) {
     }
     // claude (and any positional-prompt agent without a cwd flag)
     const args = ["-p"];
-    // BAPI-725: exactly ONE permission form, matching the Claude executor
-    // adapter's argv builder (`agent-launchers/claude-executor-adapter.ts`).
-    // `permissionMode` wins when both are supplied — emitting both would let the
-    // skip flag take effect and the probe would report on a posture it never ran.
-    if (opts.permissionMode === "acceptEdits") {
+    // BAPI-725, widened by BAPI-1020: exactly ONE permission form, matching the
+    // Claude executor adapter's argv builder
+    // (`agent-launchers/claude-executor-adapter.ts`). `permissionMode` wins when
+    // both are supplied — emitting both would let the skip flag take effect and the
+    // probe would report on a posture it never ran. That precedence is UNCHANGED;
+    // only the set of accepted modes grew, so a probe can now measure the `auto`
+    // posture every worker actually runs under.
+    if (opts.permissionMode === "auto") {
+        args.push("--permission-mode", "auto");
+    }
+    else if (opts.permissionMode === "acceptEdits") {
         args.push("--permission-mode", "acceptEdits");
     }
     else if (opts.skipPermissions === true) {

package/build/agent-capabilities/probes.js

@@ -419,10 +419,15 @@ function evaluateDenyRun(run, allowedMarker) {
 export async function runDenyEnforcementCheck(ctx, opts) {
     const marker = ctx.marker("DENY_ALLOWED");
     const prompt = denyProbePrompt();
-    const acceptEdits = opts?.permissionPosture === "accept_edits";
+    // Exactly ONE permission form per posture, mirroring the adapter's argv map.
+    const permissionMode = opts?.permissionPosture === "auto"
+        ? "auto"
+        : opts?.permissionPosture === "accept_edits"
+            ? "acceptEdits"
+            : undefined;
     const runOpts = {
-        skipPermissions: !acceptEdits,
-        permissionMode: acceptEdits ? "acceptEdits" : undefined,
+        skipPermissions: permissionMode === undefined,
+        permissionMode,
         model: opts?.model,
         timeoutMs: opts?.timeoutMs,
     };
@@ -493,7 +498,8 @@ export async function runDenyEnforcementCheck(ctx, opts) {
     return {
         result: withDenyLayer({
             status: "fail",
-            detail: "deny is NOT enforced for this installed Claude version under --dangerously-skip-permissions " +
+            detail: "deny is NOT enforced for this installed Claude version under the probed " +
+                `permission posture (${opts?.permissionPosture ?? "skip_permissions"}) ` +
                 "(neither settings permissions.deny nor a PreToolUse hook rejected the denied call)",
             elapsedMs: hookRun.elapsedMs,
             evidence: h.evidence,
@@ -507,8 +513,10 @@ const denyEnforcement = {
     description: "Runs a no-deny control run first (proving the agent actually attempts the canary call), then spawns " +
         "claude headless with --dangerously-skip-permissions in a disposable temp project carrying a " +
         "permissions.deny rule, attempts the denied call, and asserts it is rejected — reporting which layer " +
-        "enforced (settings-deny vs a PreToolUse hook fallback). A fail means deny is NOT enforced on the " +
-        "installed CLI (or cannot be verified) and is a load-bearing executor preflight signal.",
+        "enforced (settings-deny vs a PreToolUse hook fallback). Since BAPI-1020 this is the EXPLICIT REVERT " +
+        "posture rather than the worker default, and it is still probed for exactly that reason: " +
+        "`skip_permissions` remains selectable and must stay guarded. A fail means deny is NOT enforced on " +
+        "the installed CLI (or cannot be verified) and is a load-bearing executor preflight signal.",
     tier: "heavy",
     appliesTo: ["claude"],
     spawnsAgent: true,
@@ -517,6 +525,33 @@ const denyEnforcement = {
         return result;
     },
 };
+/**
+ * The same check under the posture every worker actually runs (BAPI-1020).
+ *
+ * Registered as a SEPARATE probe rather than replacing the bypass probe, because
+ * the two answer different questions and one cannot stand in for the other. Under
+ * bypass the CLI's own classifier is out of the picture entirely, so the probe
+ * measures the deny layer alone; under `auto` the classifier is in the path and a
+ * denied call could in principle wait for an approval that headless `-p` mode can
+ * never supply. The control-run discipline is identical and applies unchanged: a
+ * marker-free run is a REFUSAL, never enforcement.
+ */
+const denyEnforcementAuto = {
+    id: "deny-enforcement-auto",
+    title: "Enforces a permissions.deny rule under --permission-mode auto",
+    description: "The deny-enforcement check under the DEFAULT worker posture (BAPI-1020): a no-deny control run " +
+        "first, then claude headless with --permission-mode auto in a disposable temp project carrying a " +
+        "permissions.deny rule, asserting the denied call is rejected and reporting which layer enforced. " +
+        "This is the posture every conductor worker spawns under, so a fail here means the executor would " +
+        "be claiming jobs whose deny layer is unverified for the posture they actually run in.",
+    tier: "heavy",
+    appliesTo: ["claude"],
+    spawnsAgent: true,
+    async run(ctx) {
+        const { result } = await runDenyEnforcementCheck(ctx, { permissionPosture: "auto" });
+        return result;
+    },
+};
 /** All probes in deterministic report order. */
 export const ALL_PROBES = [
     binaryResolves,
@@ -526,6 +561,7 @@ export const ALL_PROBES = [
     preambleMidPrompt,
     outputFormat,
     denyEnforcement,
+    denyEnforcementAuto,
     workspaceFlag,
     noCwdFlag,
 ];

package/build/agent-launchers/claude-executor-adapter.js

@@ -2,7 +2,9 @@ import { isModelTier, isValidModelAlias, resolveModelAlias } from "../agent-regi
 import { evaluateClaudeMcpShadowingPolicy, inspectClaudeUserConfigForMcpShadowing, resolveClaudeUserConfigPath, } from "../claude-user-config-doctor.js";
 import { runDenyEnforcementPreflight } from "../conductor/deny-enforcement-preflight.js";
 import { buildExecutorBaseWorkerEnv } from "../executor/env.js";
+import { ExecutorNamedError } from "../executor/job-errors.js";
 import { provisionExecutorDenyLayer } from "../executor/permissions.js";
+import { WORKER_GUARD_ROOT_FLAG } from "../executor/worker-guard-hook.js";
 import { SUPPORTED_EXECUTOR_PLATFORMS, evaluateExecutorPlatform } from "../executor/platform.js";
 import { normalizeMcpServerNames } from "../executor/observation.js";
 import { supported } from "./executor-adapter.js";
@@ -179,17 +181,31 @@ export function resolveClaudeModelAlias(spec, payload) {
  * Build the exact headless Claude argv.
  *
  * Moved verbatim from `worker-command.ts`'s `buildClaudeExecutorArgv`. The
- * ordering is the golden shape the tests pin:
+ * ordering is the golden shape the tests pin, unchanged by BAPI-1020:
  *
  *   -p <prompt> --output-format stream-json --verbose
  *   [--model <alias>]
- *   (--dangerously-skip-permissions | --permission-mode acceptEdits)
+ *   (--permission-mode auto | --permission-mode acceptEdits | --dangerously-skip-permissions)
  *   --strict-mcp-config --mcp-config <verified path>
  *
+ * The DEFAULT form is now `--permission-mode auto` (BAPI-1020): Claude's own
+ * classifier runs, a flagged call is denied with a reason, and the worker
+ * continues. Claude CLI 2.1.258 headless behavior was confirmed during design —
+ * under `auto` a denied call does not wait for an approval that can never arrive
+ * in `-p` mode. `--dangerously-skip-permissions` is now emitted ONLY for the
+ * explicit `skip_permissions` revert.
+ *
  * Exactly ONE permission form is emitted. Emitting both would let the skip flag
  * win silently and make the `accept_edits` policy look effective while doing
- * nothing. The posture changes how Claude PROMPTS, not what it may do — the deny
- * layer is provisioned in both postures.
+ * nothing. The branch is an EXHAUSTIVE three-way map rather than the two-way
+ * `if/else` it replaced, whose `else` was the skip flag: under the old shape a
+ * posture the union grew but this function did not would have fallen through into
+ * bypass, silently. It now throws the same fixed, secret-free contract error the
+ * payload resolver uses, so an unmapped posture fails loudly instead of buying
+ * full bypass.
+ *
+ * The posture changes how Claude PROMPTS, not what it may do — the deny layer and
+ * the deterministic worker guard are provisioned in EVERY posture.
  *
  * Every entry is pushed SEPARATELY and never joined into a command string, so a
  * prompt or path containing a space or a shell metacharacter is just a value.
@@ -199,15 +215,34 @@ export function buildClaudeArgv(prompt, alias, mcpConfigPath, posture) {
     if (alias) {
         argv.push("--model", alias);
     }
-    if (posture === "accept_edits") {
-        argv.push("--permission-mode", "acceptEdits");
-    }
-    else {
-        argv.push("--dangerously-skip-permissions");
-    }
+    argv.push(...claudePermissionArgs(posture));
     argv.push("--strict-mcp-config", "--mcp-config", mcpConfigPath);
     return argv;
 }
+/**
+ * The single permission form for one posture — the whole policy→argv mapping,
+ * in one exhaustive place.
+ *
+ * Returns an ARRAY so every caller appends exactly what this function decided;
+ * there is no path on which a caller can add a second form. The thrown message
+ * names the FIELD and the accepted spellings and never the supplied value,
+ * matching `resolveWorkerPermissionPosture` — this text can reach the server
+ * through `/fail`, so echoing an operator's mistyped policy value would turn a
+ * typo into an exfiltration path.
+ */
+function claudePermissionArgs(posture) {
+    switch (posture) {
+        case "auto":
+            return ["--permission-mode", "auto"];
+        case "accept_edits":
+            return ["--permission-mode", "acceptEdits"];
+        case "skip_permissions":
+            return ["--dangerously-skip-permissions"];
+        default:
+            throw new ExecutorNamedError("ContractError.PermissionPosture", "worker_permission_posture is not a supported posture " +
+                "(expected 'auto', 'skip_permissions', or 'accept_edits').");
+    }
+}
 /**
  * Build the Claude worker environment: the generic executor base, plus the one
  * conditional OAuth passthrough.
@@ -224,9 +259,11 @@ export function buildClaudeArgv(prompt, alias, mcpConfigPath, posture) {
  * and cannot reach a worker environment through any path in this function.
  *
  * `options` is forwarded to the generic builder unchanged, including BAPI-844's
- * `indexScope`. This adapter neither reads nor validates the scope: it is not an
- * agent-specific credential decision, so it stays owned by the generic builder,
- * where the deny-list and the shared shape check both live.
+ * `indexScope` and BAPI-1020's `workerBranch`. This adapter neither reads nor
+ * validates either one: neither is an agent-specific credential decision, so both
+ * stay owned by the generic builder, where the deny-list and the shared shape
+ * check both live. In particular `workerBranch` is never read from `parentEnv`
+ * here — the generic builder denies that key outright.
  */
 export function buildClaudeWorkerEnv(parentEnv, options = {}) {
     const env = buildExecutorBaseWorkerEnv(parentEnv, options);
@@ -236,6 +273,43 @@ export function buildClaudeWorkerEnv(parentEnv, options = {}) {
     }
     return env;
 }
+/**
+ * Shell-quote a path for embedding in a hook command string.
+ *
+ * Same convention as `start-tickets-conductor.ts`'s conductor-hook command:
+ * single-quote for POSIX safety, escaping any embedded single quote. Claude Code
+ * interprets a hook `command` through a shell, so a worktree path containing a
+ * space — or an apostrophe — must survive that interpretation intact.
+ */
+function shellQuoteHookPath(value) {
+    return `'${value.replace(/'/g, "'\\''")}'`;
+}
+/**
+ * The PreToolUse command that runs the packaged deterministic worker guard.
+ *
+ * Invoked through the EXECUTOR's own Node executable rather than a bare shebang,
+ * for the same reason `conductorNodePath` exists (BAPI-527): the worker's `PATH`
+ * may resolve a different Node — or none — and a guard that fails to launch is a
+ * guard that is not there. A launch failure still fails open, but it should not be
+ * something the environment can cause casually.
+ *
+ * The command carries exactly ONE argument: the trusted worktree root. Templating
+ * it here is what makes every path-containment answer trustworthy — provisioning
+ * already HOLDS the authoritative worktree path, whereas the hook process's own
+ * `cwd` is not guaranteed by the PreToolUse contract to be the project root, and a
+ * containment check measured from the wrong root reports success rather than
+ * failing safe. The path is not a secret (it is already visible in `ps` for the
+ * worker itself) and it is shell-quoted, so a directory containing a space or an
+ * apostrophe survives intact.
+ *
+ * The BRANCH is deliberately NOT an argument: it travels in `BAPI_WORKER_BRANCH`,
+ * where the executor's env deny-list can guarantee an ambient value never
+ * substitutes for the job's own.
+ */
+export function buildWorkerGuardHookCommand(binPath, execPath, worktreePath) {
+    return (`${shellQuoteHookPath(execPath)} ${shellQuoteHookPath(binPath)} ` +
+        `${WORKER_GUARD_ROOT_FLAG} ${shellQuoteHookPath(worktreePath)}`);
+}
 // ---------------------------------------------------------------------------
 // The adapter factory
 // ---------------------------------------------------------------------------
@@ -268,6 +342,9 @@ export function createClaudeExecutorAdapter(spec, deps = {}) {
             if (input.indexScope !== undefined) {
                 envOptions.indexScope = input.indexScope;
             }
+            if (input.workerBranch !== undefined) {
+                envOptions.workerBranch = input.workerBranch;
+            }
             return {
                 executable: spec.command,
                 argv: buildClaudeArgv(input.prompt, input.modelAlias, input.mcpConfigPath, input.posture),
@@ -323,7 +400,14 @@ export function createClaudeExecutorAdapter(spec, deps = {}) {
                         "continuing fail-open",
                 };
             }
-            return provision(input.worktreePath, { baseBranch: input.baseBranch }, provisioningDeps);
+            const options = {
+                baseBranch: input.baseBranch,
+                workerGuardHookCommand: buildWorkerGuardHookCommand(input.workerGuardHookBinPath, deps.execPath ?? process.execPath, input.worktreePath),
+            };
+            if (input.workerBranch !== undefined) {
+                options.workerBranch = input.workerBranch;
+            }
+            return provision(input.worktreePath, options, provisioningDeps);
         },
         async probeEnforcement(options = {}) {
             const probe = deps.runDenyPreflight ?? runDenyEnforcementPreflight;