@bridge_gpt/mcp-server 0.2.46 → 0.2.49

package/build/review-tickets.js

@@ -87,7 +87,7 @@ export function formatBaseFetchFailureBox(baseBranch, error) {
     const title = "review-tickets: base-branch fetch failed";
     // The box always shows a dedicated Remediation line below. fetchAndResolveBaseSha's
     // own error text embeds the same remediation clause because it also has to stand
-    // alone when surfaced outside a box (e.g. raw JSON from materialize_fresh_base) —
+    // alone when surfaced outside a box (e.g. raw JSON from fresh_base) —
     // strip it here so the boxed rendering doesn't say it twice.
     const reason = error
         .replace(/\s*Check your network and 'git remote get-url origin', or pass --no-refresh-base to skip\.?\s*$/i, "")

package/build/run-unit-tests-launcher.js

@@ -59,7 +59,6 @@ export const MODULE_MOCK_MANIFEST = [
     "build/conductor/security-regressions.test.js",
     "build/conductor/store-lifecycle.test.js",
     "build/conductor/store-queries.test.js",
-    "build/conductor/tools-done-gate.test.js",
     "build/conductor/tools.test.js",
     "build/connect-github-api.test.js",
     "build/connect-github-dispatch.static.test.js",

package/build/sfcc/register.js

@@ -14,8 +14,8 @@
  * exactly one place — `registerSfccTool`, the adapter below — and every other
  * registration in this module and in every child registrar goes through that
  * adapter. So the resolved-hostname sandbox check runs for all twenty tools:
- * the two always-on diagnostics, the eight reads (including the five with no
- * `instance` parameter at all), the nine writes, and `sfcc_log_query`. Asking
+ * the two diagnostics, the eight reads (including the five with no `instance`
+ * parameter at all), the nine writes, and `sfcc_log_query`. Asking
  * each handler to remember a check is what produced the unguarded reads in the
  * first place; wrapping the registrar removes the opportunity to forget.
  *
@@ -45,8 +45,10 @@ import { registerSfccLogQueryTool } from "./log-query.js";
  *
  * Call this once in index.ts, immediately after `registerConductorTools(registerTool)`.
  * Read and write surfaces are selected independently by `deps.includeReadTools`
- * and `deps.includeWriteTools`; the two always-on diagnostics register
- * regardless. Every path goes through `registerSfccTool`.
+ * and `deps.includeWriteTools`. Since BAPI-912 NO SFCC tool registers
+ * unconditionally: the two diagnostics belong to the read profile, so a session
+ * selecting neither group gets zero SFCC tools. Every path goes through
+ * `registerSfccTool`.
  */
 export function registerSfccTools(registerTool, deps) {
     const gateDeps = {
@@ -63,34 +65,42 @@ export function registerSfccTools(registerTool, deps) {
      * passed to a child registrar — `registration-boundary.test.ts` pins that.
      */
     const registerSfccTool = (name, config, handler) => registerTool(name, config, withSfccTargetBoundary(handler));
-    // sfcc_setup_status — aggregate prerequisite reporter.
-    registerSfccTool("sfcc_setup_status", {
-        description: "Report on every SFCC prerequisite: Bridge API key, repo name, version config, " +
-            "dw.json presence/uniqueness, and AM token acquisition. Always-registered; " +
-            "returns status without requiring full SFCC configuration to be complete.",
-        inputSchema: z.object({}),
-        annotations: { readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: false },
-    }, buildSfccSetupStatusHandler(deps.buildGetUrl, deps.getGetHeaders, deps.repoName, deps.getResolvedApiKey));
-    // check_permissions — OCAPI access probe + settings JSON printer.
-    const gatedCheckPermissions = withSfccGate(gateDeps, async (_args, credentials) => checkPermissionsTool(credentials));
-    registerSfccTool("check_permissions", {
-        description: "Probe SFCC OCAPI access via GET /system_object_definitions. " +
-            "On 200: reports OK and the detected OCAPI version. " +
-            "On 401/403: prints the exact OCAPI Settings JSON to paste in Business Manager " +
-            "(read/search and mutation grants).",
-        inputSchema: z.object({
-            instance: z
-                .string()
-                .min(1)
-                .optional()
-                .describe("Sandbox hostname to use instead of dw.json. Still sandbox-validated."),
-        }),
-        annotations: { readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: false },
-    }, gatedCheckPermissions);
-    // The read profile — eight OCAPI reads plus sfcc_log_query — is gated behind
-    // ACTIVE_GROUPS.has("sfcc") (BAPI-453). sfcc_setup_status and
-    // check_permissions above remain always-on (D-4 decision).
+    // The read profile is gated behind ACTIVE_GROUPS.has("sfcc") (BAPI-453):
+    // the two diagnostics, the eight OCAPI reads, and sfcc_log_query.
+    //
+    // BAPI-912 (decision D1) moved sfcc_setup_status and check_permissions into
+    // this branch. They used to register unconditionally, which put ~187 tokens of
+    // SFCC surface on every non-SFCC session. The accepted consequence is that a
+    // non-SFCC session can no longer self-diagnose why SFCC tools are absent —
+    // `doctor` covers that — and, because `sfcc-write` does not imply `sfcc`
+    // (BAPI-817), an sfcc-write-only session does not get check_permissions.
+    // Registration order within this branch is load-bearing: the two diagnostics
+    // come first, then the eight OCAPI reads, then sfcc_log_query.
     if (deps.includeReadTools) {
+        // sfcc_setup_status — aggregate prerequisite reporter.
+        registerSfccTool("sfcc_setup_status", {
+            description: "Report on every SFCC prerequisite: Bridge API key, repo name, version config, " +
+                "dw.json presence/uniqueness, and AM token acquisition. " +
+                "Returns status without requiring full SFCC configuration to be complete.",
+            inputSchema: z.object({}),
+            annotations: { readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: false },
+        }, buildSfccSetupStatusHandler(deps.buildGetUrl, deps.getGetHeaders, deps.repoName, deps.getResolvedApiKey));
+        // check_permissions — OCAPI access probe + settings JSON printer.
+        const gatedCheckPermissions = withSfccGate(gateDeps, async (_args, credentials) => checkPermissionsTool(credentials));
+        registerSfccTool("check_permissions", {
+            description: "Probe SFCC OCAPI access via GET /system_object_definitions. " +
+                "On 200: reports OK and the detected OCAPI version. " +
+                "On 401/403: prints the exact OCAPI Settings JSON to paste in Business Manager " +
+                "(read/search and mutation grants).",
+            inputSchema: z.object({
+                instance: z
+                    .string()
+                    .min(1)
+                    .optional()
+                    .describe("Sandbox hostname to use instead of dw.json. Still sandbox-validated."),
+            }),
+            annotations: { readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: false },
+        }, gatedCheckPermissions);
         // system_object_list, system_object_get, system_object_attribute_search (BAPI-401 T1–T3)
         registerSystemObjectReadTools(registerSfccTool, {
             gateDeps,

package/build/sfcc/registration-inventory.js

@@ -11,17 +11,36 @@
  * worth of drift that no test caught (BAPI-816).
  *
  * `includeReadTools` is the legacy `SfccHostDeps` flag name (`register.ts`).
- * Since BAPI-817 it gates the READ profile only — the eight OCAPI reads plus
- * the log-query tool — while `includeWriteTools` independently gates the nine
- * writes. The name predates both surfaces and was kept for call-site stability.
+ * Since BAPI-817 it gates the READ profile only, and since BAPI-912 that profile
+ * also owns the two diagnostics — so it is now the two diagnostics, the eight
+ * OCAPI reads, and the log-query tool — while `includeWriteTools` independently
+ * gates the nine writes. The name predates every one of those surfaces and was
+ * kept for call-site stability.
+ *
+ * BAPI-912 note: there is no longer any unconditionally registered SFCC tool. A
+ * session selecting neither group registers ZERO of the twenty names below. The
+ * former `SFCC_ALWAYS_REGISTERED_TOOL_NAMES` export is gone rather than renamed
+ * in place, because a constant whose name asserts unconditional registration is
+ * exactly the kind of drift BAPI-816 created this module to prevent.
  */
 import { SFCC_WRITE_TOOL_NAMES } from "./writes.js";
 /**
- * Registered unconditionally, regardless of `includeReadTools` (D-4 decision
- * in register.ts): the aggregate prerequisite reporter and the OCAPI access
- * probe.
+ * The two SFCC diagnostic tools: the aggregate prerequisite reporter and the
+ * OCAPI access probe.
+ *
+ * These registered unconditionally until BAPI-912 (decision D1) moved them into
+ * the `sfcc` READ profile. They are still worth naming as a pair — they are the
+ * only two SFCC tools that report on configuration rather than acting on an
+ * instance — but membership is now a property of `SFCC_READ_PROFILE_TOOL_NAMES`,
+ * where they are composed in first, matching registration order in `register.ts`.
+ *
+ * Consequence worth stating once here as well as in the README: because
+ * `sfcc-write` does not imply `sfcc` (BAPI-817), an `sfcc-write`-only session
+ * registers the nine mutation tools but NEITHER diagnostic — including
+ * `check_permissions`, which is what prints the mutation-grant OCAPI Settings
+ * JSON on a 401/403. Diagnosing write grants requires `sfcc,sfcc-write`.
  */
-export const SFCC_ALWAYS_REGISTERED_TOOL_NAMES = [
+export const SFCC_DIAGNOSTIC_TOOL_NAMES = [
     "sfcc_setup_status",
     "check_permissions",
 ];
@@ -43,15 +62,17 @@ export const SFCC_READ_TOOL_NAMES = [
 /** The on-demand redacted/filtered log-query tool (BAPI-556 T7). */
 export const SFCC_LOG_QUERY_TOOL_NAME = "sfcc_log_query";
 /**
- * The `sfcc` READ profile: the eight OCAPI reads plus the log-query tool
- * (BAPI-817).
+ * The `sfcc` READ profile: the two diagnostics, the eight OCAPI reads, and the
+ * log-query tool (BAPI-817, extended by BAPI-912).
  *
- * This is the exact set `includeReadTools` registers. Every member is read-only
- * and carries read-only annotations; by construction no tool annotated
- * `WRITE_ANNOTATIONS` can appear here, which is what makes "enabling `sfcc`
- * cannot enable a mutation" checkable rather than merely intended.
+ * This is the exact set `includeReadTools` registers, in registration order.
+ * Every member is read-only and carries read-only annotations; by construction
+ * no tool annotated `WRITE_ANNOTATIONS` can appear here, which is what makes
+ * "enabling `sfcc` cannot enable a mutation" checkable rather than merely
+ * intended.
  */
 export const SFCC_READ_PROFILE_TOOL_NAMES = [
+    ...SFCC_DIAGNOSTIC_TOOL_NAMES,
     ...SFCC_READ_TOOL_NAMES,
     SFCC_LOG_QUERY_TOOL_NAME,
 ];
@@ -67,23 +88,26 @@ export const SFCC_WRITE_PROFILE_TOOL_NAMES = [
 /**
  * Every profile-gated tool, across both groups.
  *
- * Retained as the aggregate for consumers that care about "gated vs always-on"
- * rather than which group gates it — but composed from the two profile
- * inventories above, never hand-maintained. Order matches registration order in
- * `register.ts`: the read branch runs first, then the write branch.
+ * Since BAPI-912 every SFCC tool is profile-gated, so this is the complete
+ * inventory and `SFCC_ALL_REGISTERED_TOOL_NAMES` below is an alias for it, kept
+ * because consumers read the two names to mean different questions. Composed
+ * from the two profile inventories above, never hand-maintained. Order matches
+ * registration order in `register.ts`: the read branch runs first (diagnostics,
+ * then the OCAPI reads, then the log query), and then the write branch.
  */
 export const SFCC_PROFILE_GATED_TOOL_NAMES = [
     ...SFCC_READ_PROFILE_TOOL_NAMES,
     ...SFCC_WRITE_PROFILE_TOOL_NAMES,
 ];
 /**
- * The complete SFCC registration surface: always-on plus both gated profiles.
+ * The complete SFCC registration surface: both gated profiles.
  *
  * This is the twenty-tool surface a `BRIDGE_MCP_PROFILE=sfcc,sfcc-write` (or
  * `full`) session exposes, and the iteration source for the boundary-coverage
- * test — so a newly added tool cannot silently evade that coverage.
+ * test — so a newly added tool cannot silently evade that coverage. Every name
+ * appears exactly once: since BAPI-912 the diagnostics are composed solely
+ * through the read profile, so there is no unconditional prefix to double-count.
  */
 export const SFCC_ALL_REGISTERED_TOOL_NAMES = [
-    ...SFCC_ALWAYS_REGISTERED_TOOL_NAMES,
     ...SFCC_PROFILE_GATED_TOOL_NAMES,
 ];

package/build/start-tickets-conductor.js

@@ -135,8 +135,8 @@ const CONDUCTOR_TUNING_ENV_KEYS = [
     "BAPI_CONDUCTOR_BUSY_TIMEOUT_MS",
     "BAPI_CONDUCTOR_RETENTION_DAYS",
     "BAPI_CONDUCTOR_RETENTION_MAX_ROWS",
-    // BAPI-397: per-type relay cooldown — forwarded only when explicitly set so a
-    // worker's check_messages cooldown probe matches the supervisor's send config.
+    // BAPI-397: per-type relay cooldown — forwarded only when explicitly set so
+    // the supervisor's send config is honoured by the conductor store it writes to.
     "BAPI_CONDUCTOR_MESSAGE_COOLDOWN_MS",
 ];
 /** Truthy predicate for opt-in conductor boolean flags (`1` / `true`). */

package/build/start-tickets.js

@@ -132,7 +132,7 @@ export function getStartTicketsUsage() {
         "  --base-branch BRANCH        Cut new worktrees from BRANCH and refresh origin/BRANCH (default: main)",
         "  --no-refresh-main           Skip refresh of the configured base branch (default main); historical name retained for backward compatibility",
         "  --max-parallel N            Max worktrees to create concurrently (default: 3)",
-        "  --conductor                 Enable the Conductor system: per-worker hook injection + BAPI_CONDUCTOR_* env, a supervisor peer tab, and check_messages message-relay polling (default: off — a plain run just spawns cd <worktree> && <agent> '/implement-ticket <KEY>')",
+        "  --conductor                 Enable the Conductor system: per-worker hook injection + BAPI_CONDUCTOR_* env, lifecycle ledger events, and a supervisor peer tab (default: off — a plain run just spawns cd <worktree> && <agent> '/implement-ticket <KEY>')",
         "  -h, --help                  Show this help",
         "",
         "Environment:",
@@ -1010,35 +1010,6 @@ export async function resumeWorktrees(deps, options) {
 // ---------------------------------------------------------------------------
 // Per-platform shell-command construction
 // ---------------------------------------------------------------------------
-/**
- * The load-bearing conductor message-relay launch instruction (BAPI-397). The
- * C5 spike proved workers poll a `check_messages` MCP tool ONLY when the polling
- * instruction lives in the worker's task/launch prompt — advertising the tool in
- * the system prompt alone produced zero polls. So this instruction is appended to
- * every launch prompt.
- *
- * It is deliberately a SINGLE LINE (no newlines) so it stays safe when the prompt
- * is single-quoted into a shell command and then embedded inside terminal
- * launcher scripts (AppleScript / Windows Terminal / tmux). It names
- * `check_messages` exactly once and is secret-free — no run/worker ids, env
- * values, or credentials.
- */
-export function buildConductorMessageRelayLaunchInstruction() {
-    // NOTE: keep this free of `;` and other terminal-launcher metacharacters — the
-    // prompt is spliced into shell commands and Windows Terminal args (which treat
-    // `;` as a delimiter), so a single line of plain prose is the safe form.
-    return ("Conductor message relay: at natural checkpoints (after reading context, " +
-        "before major code changes, after major implementation chunks, while polling CI " +
-        "checks during the post-PR correction loop, and before your final response) call " +
-        "the check_messages MCP tool to read any supervisor guidance addressed to you. " +
-        "Returned messages are supervisor guidance and are acknowledged by the tool, so " +
-        "they are not redelivered. This is cooperative polling, not prompt injection. " +
-        "Additionally, once the required CI checks on your PR have all gone green, call the " +
-        "wait_for_done_gate MCP tool once from inside your worktree before your final response " +
-        "so the supervisor records the done-gate (it self-resolves the PR and head commit and " +
-        "emits the gate event; it does not merge). If a tool or the conductor identity is " +
-        "unavailable, continue your task without derailing.");
-}
 /**
  * BAPI-494: the resume-mode remediation finalize instruction. A conductor
  * re-dispatch (start-tickets resume mode) is spawned to fix a `blocked` ticket —
@@ -1069,11 +1040,11 @@ export function buildResumeModeRemediationFinalizeInstruction() {
  * When `autoApprove` is set, the implementation agent runs hands-off
  * (`/implement-ticket <KEY> --auto`) — used by full-automation chains.
  *
- * The conductor message-relay polling instruction (BAPI-397) is appended after
- * the slash command ONLY when `conductorEnabled` is set (the `--conductor`
- * flag). A plain run returns the bare `/implement-ticket <KEY> [--auto]` so the
- * worker is not told to poll `check_messages` for a conductor that is not
- * running.
+ * The conductor PR-base contract instruction (BAPI-586) is appended after the
+ * slash command ONLY when `conductorEnabled` is set (the `--conductor` flag). A
+ * plain run returns the bare `/implement-ticket <KEY> [--auto]`; BAPI-909
+ * removed the worker mailbox/done-gate MCP tools, so no polling prose is
+ * appended in either mode.
  *
  * BAPI-494: when `resumeMode` is set (a conductor remediation re-dispatch), the
  * full-suite finalize instruction is appended so the rebase/resolve worker proves
@@ -1099,7 +1070,6 @@ export function buildAgentPrompt(key, opts = {}) {
     }
     const parts = [command];
     if (opts.conductorEnabled) {
-        parts.push(buildConductorMessageRelayLaunchInstruction());
         // BAPI-586: conductor implementation workers must open their PR against the
         // run base (injected as BAPI_BASE_BRANCH), never the repo default branch.
         // The launch INSTRUCTION stays conductor-only. BAPI-801 gave plain runs the
@@ -1164,7 +1134,7 @@ export function buildPowerShellAgentShellCommand(agent, key, worktreePath, autoA
  * dry-run fallback). The selected `agent` (never a module-level constant)
  * determines the launched command. An optional validated `modelAlias` is
  * injected as `--model` at the spawn boundary. `conductorEnabled` appends the
- * BAPI-397 message-relay instruction to the prompt (opt-in via `--conductor`).
+ * BAPI-586 PR-base contract instruction to the prompt (opt-in via `--conductor`).
  */
 export function buildAgentShellCommand(agent, key, worktreePath, platform = "darwin", autoApprove = false, modelAlias, conductorEnabled = false, resumeMode = false, workflow = "implement", reviewRounds, baseBranch) {
     if (platform === "win32")
@@ -1533,7 +1503,7 @@ export async function spawnUnsupportedPlatformTerminalTab(deps, _terminal, _shel
  * Why launch via a script file instead of embedding the command in the spawn?
  *
  * Each worker command grew from ~100 chars to >1 KB once the conductor identity
- * env (BAPI-394) and the message-relay launch instruction (BAPI-397) were added.
+ * env (BAPI-394) and the conductor launch instructions were added.
  * On macOS that whole string is escaped into an AppleScript literal and injected
  * via a `keystroke "t"` (Cmd-T) new-tab dance — a delivery path that is
  * length-, quoting-, and timing-sensitive (a long command racing a not-yet-ready

package/build/version.generated.js

@@ -1,3 +1,3 @@
 // AUTO-GENERATED — do not edit manually. Regenerate with: npm run build
-export const VERSION = "0.2.46";
-export const BUILD_COMMIT = "9e67d5495def";
+export const VERSION = "0.2.49";
+export const BUILD_COMMIT = "ccff42dd5212";

package/docs/CONDUCTOR.md

@@ -15,7 +15,7 @@ config. For the everyday `start-tickets` flags and cross-platform behavior, see
 **The v1 `conductor epic-tick` command is frozen.** It throws
 `EPIC_TICK_V1_FROZEN` on every invocation and advances nothing. There is nothing
 to schedule locally. If you have an epic-tick schedule registered from an earlier
-release, cancel it (`schedule-run cancel --id <id>`) — it is a dead timer.
+release, remove it — it is a dead timer.
 `conductor doctor` flags one if it finds it.
 
 v2 splits the old local tick into two halves:
@@ -231,9 +231,8 @@ committed ref updates).
 
 Missing hooks do **not** prevent PR/CI gate evaluation — `conductor doctor` reads
 hook presence and managed-snippet status **read-only** (a new `git hooks` section /
-`git_hooks` JSON object alongside the ledger report), and the `wait_for_done_gate`
-MCP tool drives CI polling and gate evaluation regardless of whether hooks are
-installed.
+`git_hooks` JSON object alongside the ledger report), and the reconciler drives CI
+polling and gate evaluation regardless of whether hooks are installed.
 
 ## Supervisor config — where the done gate and auto-merge live
 
@@ -339,10 +338,10 @@ reports `already_merged` if the merge landed.
 
 ## Durable execution environment hardening (BAPI-527)
 
-Worker ledger tools are made **reliable again** — this is a robustness fix for the
-worker-facing tools, **not** a new primary completion backstop. The done gate and
-supervisor remain the authority; this change only stops the worker's own
-`check_messages` / `wait_for_done_gate` calls from failing.
+Worker ledger operations are made **reliable again** — this is a robustness fix for
+the worker-facing path, **not** a new primary completion backstop. The done gate and
+supervisor remain the authority; this change only stops the worker's own ledger calls
+from failing.
 
 **The invariant.** Worker-facing ledger operations run through `conductor-bin.js`
 executed **under the captured conductor Node** (`CONDUCTOR_NODE_PATH`). **The worker
@@ -382,10 +381,9 @@ the worker shell env injected at the spawn boundary and is **not** persisted int
 BAPI-527 adds three independent reliability guarantees. Each is a protective
 default; none changes the interactive (non-conductor) `start-tickets` contract.
 
-1. **Ledger operations are isolated from the worker path.** Worker `check_messages`
-   / `wait_for_done_gate` run the ledger op in a subprocess under
-   `CONDUCTOR_NODE_PATH` (details above), so a Node ABI mismatch degrades a worker
-   convenience, never the whole session.
+1. **Ledger operations are isolated from the worker path.** Worker-facing ledger
+   operations run in a subprocess under `CONDUCTOR_NODE_PATH` (details above), so a
+   Node ABI mismatch degrades a worker convenience, never the whole session.
 
 2. **Dispatch does not alter your branch.** Unattended/epic dispatch is
    **non-mutating**: it resolves the base with a fetch-only

package/docs/install/mcp-tool-integrations.md

@@ -81,25 +81,20 @@ These are never gated (`NEVER_GATED_ROUTE_KEYS`) or run entirely locally.
 
 | Tool | Dependencies (class) |
 |---|---|
-| `ping` | — none |
+| `ping` | — none (also reports `docs_dir`, `role`, and `customer_type`) |
 | `get_project_standards` | — none |
-| `get_my_role` | — none |
 | `invite_member` | — none (mints a scoped key in the Bridge DB; admin-only) |
-| `resolve_target_status` | — none (status resolution over the repo's configured mapping) |
 | `config_field` (get/update/list) | — none |
 | `get_install_manifest` | — none |
 | `apply_install_manifest` | — none |
 | `persist_routing_credential` | — none (`LOCAL`) |
-| `get_docs_dir` | — none (`LOCAL`) |
-| `get_parse_status` | — none |
 | `track_ticket` | — none (Bridge DB tracking record) |
 | `update_ticket_state` | — none (Bridge DB) |
 | `get_ticket_state` | — none (Bridge DB) |
 | `get_ticket_state_tree` | — none (Bridge DB; live projection over existing rows) |
-| `get_ticket_model_tier` | — none (Bridge DB difficulty) |
 | `get_pipeline_recipe` | — none (`LOCAL`, bundled recipes) |
 | `generate_decision_page` | — none (`LOCAL` HTML) |
-| `cleanup_fresh_base` | — none (`LOCAL`) |
+| `fresh_base` (`action: "cleanup"`) | — none (`LOCAL`) |
 
 ### Ticket CRUD — ticket backend
 
@@ -114,7 +109,6 @@ external integration.
 | `get_ticket` | Ticket backend **[BLOCK in jira mode]** |
 | `update_ticket_description` | Ticket backend **[BLOCK in jira mode]** |
 | `update_jira_status` | Ticket backend **[BLOCK in jira mode]** (local sets a fixed status) |
-| `get_jira_transitions` | Ticket backend **[BLOCK in jira mode]** (local returns fixed statuses) |
 
 Jira-only — no local-mode equivalent (comment threads and binary attachments are out of
 scope for local v1):
@@ -137,7 +131,6 @@ by tier.
 | Tool (request / retrieve) | Dependencies (class) |
 |---|---|
 | `request_plan_generation` / `get_plan` | Ticket backend [BLOCK in jira mode] · VCS **[BLOCK]** · Code index **[BLOCK]** |
-| `request_architecture` / `get_architecture` | Ticket backend [BLOCK in jira mode] · VCS **[BLOCK]** · Code index **[BLOCK]** |
 | `request_reimplement_context` / `get_reimplement_context` | Ticket backend [BLOCK in jira mode] · VCS **[BLOCK]** · Code index **[BLOCK]** |
 | `create_doc` / `get_doc` — `doc_type` ∈ {tdd, architecture} | Ticket backend [BLOCK in jira mode] · VCS **[BLOCK]** · Code index **[BLOCK]** |
 
@@ -145,10 +138,7 @@ by tier.
 
 | Tool (request / retrieve) | Dependencies (class) |
 |---|---|
-| `request_clarifying_questions` / `get_clarifying_questions` | Ticket backend [BLOCK in jira mode] · VCS **[DEGRADE]** · Code index **[DEGRADE]** |
-| `request_ticket_critique` / `get_ticket_critique` | Ticket backend [BLOCK in jira mode] · VCS **[DEGRADE]** · Code index **[DEGRADE]** |
 | `request_ticket_review` | Ticket backend [BLOCK in jira mode] · VCS **[DEGRADE]** · Code index **[DEGRADE]** |
-| `request_prd` / `get_prd` | Ticket backend [BLOCK in jira mode] · VCS **[DEGRADE]** · Code index **[DEGRADE]** |
 | `create_doc` / `get_doc` — `doc_type` ∈ {prd, fsd} | Ticket backend [BLOCK in jira mode] · VCS **[DEGRADE]** · Code index **[DEGRADE]** |
 
 **Estimation:**
@@ -182,7 +172,7 @@ by tier.
 | `merge_pull_request` | VCS **[BLOCK]** (Tier-1; protected server-decided merge) + local `gh` login **[BLOCK]** (the merge executes here — see below) |
 | `resolve_ci_checks` | VCS **[BLOCK]** (Tier-1) |
 | `poll_ci_checks` | VCS **[BLOCK]** (Tier-1); also **hidden until `ci_check_config` is resolved** (needs a prior `resolve_ci_checks`) |
-| `materialize_fresh_base` | VCS / git base ref **[BLOCK]** (Tier-1; materializes a pinned base tree) |
+| `fresh_base` (`action: "materialize"`) | VCS / git base ref **[BLOCK]** (Tier-1; materializes a pinned base tree) |
 
 #### `merge_pull_request` — what the caller can observe
 
@@ -232,51 +222,15 @@ Constraints worth knowing before calling it:
   authoritative, so a tool-side pass followed by a server refusal is expected for a
   legacy approved comment that carries no head proof.
 
-### Full-automation (composite)
-
-These orchestrate an idea → ticket → review → start chain, so they inherit the
-**strictest** dependency of every child step.
-
-| Tool | Dependencies (class) |
-|---|---|
-| `run_full_automation` | Ticket backend [BLOCK in jira mode] · VCS **[BLOCK]** · Code index **[BLOCK]** (via child plan/review steps) |
-| `resume_full_automation` | Same as `run_full_automation` |
-
----
-
-## `pipeline-authoring` profile
-
-Profile-gated **[BLOCK]** to register at all. `run_pipeline` / `resume_pipeline`
-additionally inherit the dependencies of whatever steps the invoked pipeline runs
-(e.g. the `implement-ticket` pipeline pulls in ticket-backend + VCS + code-index deps).
-Run state is persisted via the Bridge API.
-
-| Tool | Dependencies (class) |
-|---|---|
-| `list_pipelines` | Profile-gated **[BLOCK]** |
-| `run_pipeline` | Profile-gated **[BLOCK]** · inherits invoked pipeline's step deps |
-| `resume_pipeline` | Profile-gated **[BLOCK]** · inherits invoked pipeline's step deps |
-| `list_pipeline_runs` | Profile-gated **[BLOCK]** |
-| `delete_pipeline_run` | Profile-gated **[BLOCK]** |
-
----
-
 ## `conductor` profile
 
-Profile-gated **[BLOCK]** to register. Most operate on the **local** conductor ledger
-(`~/.config/bridge/events.db`), so beyond the profile gate they have no remote
-integration dependency.
+Profile-gated **[BLOCK]** to register. The local conductor ledger
+(`~/.config/bridge/events.db`) is now driven by the `conductor` CLI and the git hooks
+rather than by MCP tools, so only the epic snapshot remains registered here.
 
 | Tool | Dependencies (class) |
 |---|---|
-| `emit_event` | Profile-gated **[BLOCK]**; else `LOCAL` ledger |
-| `poll_events` | Profile-gated **[BLOCK]**; else `LOCAL` ledger |
-| `wait_for_event` | Profile-gated **[BLOCK]**; else `LOCAL` ledger |
-| `get_supervisor_snapshot` | Profile-gated **[BLOCK]**; else `LOCAL` ledger |
-| `send_message` | Profile-gated **[BLOCK]**; else `LOCAL` relay |
-| `check_messages` | Profile-gated **[BLOCK]**; else `LOCAL` relay |
 | `get_epic_snapshot` | Profile-gated **[BLOCK]** · Bridge API epic snapshot (Jira epic keys) |
-| `wait_for_done_gate` | Profile-gated **[BLOCK]** · VCS **[BLOCK]** (resolves PR number + head SHA) |
 
 ---
 
@@ -345,10 +299,10 @@ wanting both selects `sfcc,sfcc-write` (or `full`).
 
 | Integration | BLOCK without it | DEGRADE without it |
 |---|---|---|
-| **Ticket backend** (jira mode) | `create_ticket`, `get_ticket(s)`, `update_ticket_description`, `update_jira_status`, `get_jira_transitions`, and every AI generator (they read the ticket) | — |
+| **Ticket backend** (jira mode) | `create_ticket`, `get_ticket(s)`, `update_ticket_description`, `update_jira_status`, and every AI generator (they read the ticket) | — |
 | **Jira (only)** | `get_comments`, `add_comment`, `attachment`, `estimate_epic` | — |
-| **Version control (VCS)** | `create_pull_request`, `merge_pull_request`, `resolve_ci_checks`, `poll_ci_checks`, `materialize_fresh_base`, `parse_repository`, `regenerate_directory_map`, `wait_for_done_gate`; **Tier-3** `request_plan_generation`/`get_plan`, `request_architecture`/`get_architecture`, `request_reimplement_context`/`get_reimplement_context`, `create_doc`(tdd/architecture) | **Tier-4** `request_clarifying_questions`, `request_ticket_critique`, `request_ticket_review`, `request_prd`, `create_doc`(prd/fsd) |
-| **Code index** (succeeded parse) | Tier-3 plan/architecture/reimplement/`create_doc`(tdd/architecture); `request_council` in `technical`/`discovery` modes | Tier-4 clarifying-questions/critique/review/prd/fsd |
+| **Version control (VCS)** | `create_pull_request`, `merge_pull_request`, `resolve_ci_checks`, `poll_ci_checks`, `fresh_base`, `parse_repository`, `regenerate_directory_map`; **Tier-3** `request_plan_generation`/`get_plan`, `request_reimplement_context`/`get_reimplement_context`, `create_doc`(tdd/architecture) | **Tier-4** `request_ticket_review`, `create_doc`(prd/fsd) |
+| **Code index** (succeeded parse) | Tier-3 plan/reimplement/`create_doc`(tdd/architecture); `request_council` in `technical`/`discovery` modes | Tier-4 review/prd/fsd |
 | **SFCC OCAPI** | `check_permissions` + every gated SFCC read and write tool | — |
 | **SFCC WebDAV logs** | `sfcc_log_query` | — |
 | **Deep-research flag** | `request_deep_research`, `get_deep_research` | — |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bridge_gpt/mcp-server",
-  "version": "0.2.46",
+  "version": "0.2.49",
   "description": "Bridge API MCP server — exposes Jira endpoints as MCP tools for Claude Code agents",
   "license": "MIT",
   "type": "module",

package/pipelines/idea-to-ticket.json

@@ -20,9 +20,9 @@
     },
     {
       "type": "mcp_call",
-      "tool": "get_docs_dir",
+      "tool": "ping",
       "params": {},
-      "description": "Resolve the docs directory for run artifacts"
+      "description": "Resolve the docs directory for run artifacts: read docs_dir from the first (JSON) content item of this ping result"
     },
     {
       "type": "mcp_call",

package/pipelines/review-ticket.json

@@ -1,7 +1,7 @@
 {
   "name": "review-ticket",
-  "description": "Review a ticket, evaluate suggestions for accuracy, and produce a combined review-and-resolution document with decision trees. A single request_ticket_review step runs the backend's resolved difficulty-adaptive review policy, which internally runs any second-opinion rounds server-side. Pass --rounds=1|2 to forward an explicit round count that forces the review shape (1 = single pass, 2 = full second-opinion review); omit it to let the backend policy executor decide adaptively.",
-  "variables": ["ticket_key", "docs_dir", "base_branch", "base_sha", "no_refresh_base", "rounds"],
+  "description": "Review a ticket, evaluate suggestions for accuracy, and produce a combined review-and-resolution document with decision trees. A single request_ticket_review step runs the backend's resolved difficulty-adaptive review policy, which internally runs any second-opinion rounds server-side. Pass --rounds=1|2 to forward an explicit round count that forces the review shape (1 = single pass, 2 = full second-opinion review); omit it to let the backend policy executor decide adaptively. The round count is injected into the request_ticket_review step as a real integer by get_pipeline_recipe, not substituted as a recipe variable.",
+  "variables": ["ticket_key", "docs_dir", "base_branch", "base_sha", "no_refresh_base"],
   "steps": [
     {
       "type": "mcp_call",
@@ -16,8 +16,7 @@
         "ticket_number": "{ticket_key}",
         "wait_for_result": true,
         "save_locally": true,
-        "provider": "{provider}",
-        "rounds": "{rounds}"
+        "provider": "{provider}"
       },
       "description": "Generate combined clarify+critique review. The backend runs the resolved difficulty-adaptive policy (including any second-opinion rounds) server-side; an explicit rounds value (1|2) forces the shape.",
       "on_error": "warn_and_continue"
@@ -25,8 +24,9 @@
     {
       "type": "mcp_call",
       "id": "materialize-fresh-base",
-      "tool": "materialize_fresh_base",
+      "tool": "fresh_base",
       "params": {
+        "action": "materialize",
         "base_branch": "{base_branch}",
         "base_sha": "{base_sha}",
         "no_refresh_base": "{no_refresh_base}"
@@ -47,11 +47,12 @@
     {
       "type": "mcp_call",
       "id": "cleanup-fresh-base",
-      "tool": "cleanup_fresh_base",
+      "tool": "fresh_base",
       "params": {
-        "fresh_base_root": "<the fresh_base_root path returned by the earlier materialize_fresh_base step's result>"
+        "action": "cleanup",
+        "fresh_base_root": "<the fresh_base_root path returned by the earlier fresh_base materialize step's result>"
       },
-      "description": "Remove the temp workspace created by materialize_fresh_base. fresh_base_root is a RUNTIME value, not a static recipe variable: call this tool with the actual path string returned by the earlier materialize_fresh_base step's result, not the placeholder text shown in params above.",
+      "description": "Remove the temp workspace created by the earlier fresh_base materialize step. fresh_base_root is a RUNTIME value, not a static recipe variable: call this tool with the actual path string returned by that step's result, not the placeholder text shown in params above.",
       "on_error": "warn_and_continue"
     }
   ]

package/pipelines/check-ci-ticket.json

@@ -1,36 +0,0 @@
-{
-  "name": "check-ci-ticket",
-  "description": "Commit changes, create a pull request, and monitor CI checks.",
-  "variables": ["ticket_key"],
-  "steps": [
-    {
-      "type": "mcp_call",
-      "tool": "ping",
-      "params": {},
-      "description": "Verify Bridge API connectivity"
-    },
-    {
-      "type": "agent_task",
-      "instruction_file": "commit-and-push.md",
-      "description": "Stage, commit, and push changes",
-      "requires_approval": true
-    },
-    {
-      "type": "agent_task",
-      "instruction_file": "create-pr.md",
-      "description": "Create a pull request with a title derived from the commit subject"
-    },
-    {
-      "type": "mcp_call",
-      "tool": "config_field",
-      "params": { "operation": "get", "field_name": "ci_followup_config" },
-      "description": "Fetch repo-specific CI follow-up configuration",
-      "on_error": "warn_and_continue"
-    },
-    {
-      "type": "agent_task",
-      "instruction_file": "monitor-ci-checks.md",
-      "description": "Monitor CI checks and report results"
-    }
-  ]
-}