@ironbee-ai/cli 0.8.3 → 0.9.0

package/dist/clients/claude/{fragments → platforms}/rule.node.md

@@ -1,10 +1,10 @@
 <!-- Node backend verification is ENABLED for this project. The Stop hook
      enforces a node cycle in addition to the browser cycle whenever an
-     edited file matches `backend.node.verifyPatterns`. -->
+     edited file matches `node.verifyPatterns`. -->
 
 ## Node cycle
 
-Backend file changes IF the file matches `backend.node.verifyPatterns` ALSO require verification through the **node-devtools** MCP server (prefix `ndt_`). Node-cycle verification means attaching to the running Node process via the V8 inspector, setting a probe (tracepoint / logpoint / exceptionpoint) at the changed code, exercising the path so the probe fires, and reading snapshots — OR inspecting runtime error logs.
+Backend file changes IF the file matches `node.verifyPatterns` ALSO require verification through the **node-devtools** MCP server (prefix `ndt_`). Node-cycle verification means attaching to the running Node process via the V8 inspector, setting a probe (tracepoint / logpoint / exceptionpoint) at the changed code, exercising the path so the probe fires, and reading snapshots — OR inspecting runtime error logs.
 
 Both cycles can be active simultaneously (e.g. you edit both a React component and an API handler in the same task). One `verification-start` covers all active cycles; one verdict file carries fields for all active cycles; one retry counter applies globally.
 
@@ -12,7 +12,7 @@ Both cycles can be active simultaneously (e.g. you edit both a React component a
 
 `node-devtools` is a V8 inspector wrapper. It does NOT work for Java, Python, Go, Rust, Ruby, .NET, PHP, or any other runtime. If you see `pom.xml`, `build.gradle`, `requirements.txt`, `pyproject.toml`, `go.mod`, `Cargo.toml`, etc., the backend is NOT Node.js and you must NOT call `ndt_*` tools — they will fail to connect to non-Node processes.
 
-**Misconfiguration recovery.** If you reach this state, the operator enabled the node cycle for a non-Node project by mistake. The Stop hook will keep blocking with `incomplete_tools` for the node cycle until you call `ndt_debug_connect` (which will fail) or until `maxRetries` is exhausted. Don't attempt the connection. Instead, stop and clearly report to the user: the project's backend is not Node.js, and they must run `ironbee disable-backend node` to unblock the gate. Continue with browser-cycle verification only in the meantime.
+**Misconfiguration recovery.** If you reach this state, the operator enabled the node cycle for a non-Node project by mistake. The Stop hook will keep blocking with `incomplete_tools` for the node cycle until you call `ndt_debug_connect` (which will fail) or until `maxRetries` is exhausted. Don't attempt the connection. Instead, stop and clearly report to the user: the project's backend is not Node.js, and they must run `ironbee node disable` to unblock the gate. Continue with browser-cycle verification only in the meantime.
 
 ### Node-cycle additions to the main flow
 

package/dist/clients/claude/platforms/skill.backend.md

@@ -0,0 +1,65 @@
+<!-- Backend protocol verification is ENABLED for this project. The Stop hook
+     enforces a backend cycle in addition to the browser cycle whenever an
+     edited file matches `backend.verifyPatterns`. The cycle is runtime- and
+     language-agnostic — it binds to wire protocols, not frameworks. -->
+
+## Backend cycle — runtime- and language-agnostic
+
+The **backend protocol cycle** verifies backend changes by driving real protocol calls (HTTP / gRPC / GraphQL / WebSocket) against the running service and reading the responses. It works for ANY backend runtime: Node, Java, Python, Go, Rust, Ruby, .NET, PHP, Elixir, Kotlin, Scala — the agent never attaches to a process; it just calls endpoints.
+
+**This is different from the node cycle.** Node-cycle (`ndt_*`) attaches to a V8 inspector and sets non-blocking probes inside a running Node.js process — it's Node-only. Backend-cycle (`bedt_*`) makes outside-in protocol calls against any service. They can be active at the same time when both are enabled.
+
+## Backend flow
+
+1. **Confirm a backend service is running** (the user's dev server, Docker compose, k8s port-forward, …). The agent itself does not start the service — ask the user if uncertain.
+2. **Identify the affected endpoint(s)** for your code change. Look at routes / handlers / controllers in the changed files. Map them to wire-level addresses (URL, gRPC service+method, GraphQL operation name, WebSocket path).
+3. **Make a real protocol call** with one of:
+   - **HTTP/1.1 + HTTP/2**: `mcp__backend-devtools__bedt_request_http` — full method/headers/body/query/follow-redirects support; ALPN auto-negotiates H2 on TLS, falls back to H1.1.
+   - **gRPC**: `mcp__backend-devtools__bedt_request_grpc` — unary + 3 streaming modes; pass `.proto` text or descriptor.
+   - **GraphQL**: `mcp__backend-devtools__bedt_request_graphql` — query/mutation, variables, persisted query support.
+   - **WebSocket** (stateful — open/send/receive/close cycle):
+     - `mcp__backend-devtools__bedt_request_websocket-open` — establish session.
+     - `mcp__backend-devtools__bedt_request_websocket-send` / `bedt_request_websocket-receive` — exchange frames.
+     - `mcp__backend-devtools__bedt_request_websocket-close` — clean teardown (and `bedt_request_websocket-list` for running sessions).
+   - **Replay**: `mcp__backend-devtools__bedt_request_replay` — re-issue a captured curl command or HAR entry.
+4. **Inspect the response** — `status` (HTTP / gRPC code), body, headers, returned `traceId` (always W3C `traceparent`).
+   **`4xx/5xx and gRPC non-OK are normal results, not errors.** A test for "404 Not Found" SHOULD return 404. Only transport-level failures (DNS, TLS, timeout, abort) populate the response's `error` field. Decide PASS/FAIL based on what your task actually requires.
+5. **Chain follow-up calls** if you need to verify side effects (e.g. POST then GET to confirm the new resource is readable). Use `bedt_request_set-default-headers` to pin auth tokens once per host, `bedt_request_set-cookies` for session cookies — both stay scoped to that target across calls.
+6. **Submit verdict** including `backend_*` fields. If browser and/or node cycles are also active, include their fields in the SAME verdict — do not submit two verdicts.
+
+### Backend verdict fields
+```json
+{
+  "session_id": "<sid>",
+  "status": "pass",
+  "checks": ["POST /api/orders returned 201 with order id", "GET /api/orders/:id reflects new order"],
+  "backend_endpoints_called": [
+    "POST http://localhost:3000/api/orders",
+    "GET http://localhost:3000/api/orders/42"
+  ],
+  "backend_response_statuses": [201, 200],
+  "backend_traces_collected": ["00-1234abcd-...01"]
+}
+```
+
+`backend_endpoints_called` is the only required field for the cycle (any non-empty array proves the agent engaged the protocol layer). `backend_response_statuses` and `backend_traces_collected` are optional but strongly recommended — same order as `backend_endpoints_called`. Status interpretation is YOUR call: there is no automatic pass-criteria override on this cycle. If the agent claims `status: pass` and the evidence is structurally valid, the gate honors it.
+
+## Multi-cycle (browser + backend, or browser + node + backend)
+
+Common case: a feature edit touches a `.tsx` page (browser-cycle) and a `routes/orders.ts` (node-cycle if Node.js, plus backend-cycle for protocol verification when `backend` is enabled). All active cycles must be satisfied for `status: pass`. **Single** `verification-start`, **single** verdict, **single** retry counter cover all of them.
+
+```json
+{
+  "session_id": "<sid>",
+  "status": "pass",
+  "pages_tested": ["http://localhost:3000/checkout"],
+  "checks": ["checkout submits", "POST /api/orders returned 201", "no console errors"],
+  "console_errors": 0,
+  "network_failures": 0,
+  "backend_endpoints_called": ["POST http://localhost:3000/api/orders"],
+  "backend_response_statuses": [201],
+  "backend_traces_collected": ["00-1234abcd-...01"]
+}
+```
+
+For a multi-cycle pass, EVERY active cycle's pass criteria must hold. Claiming `pass` without a cycle's evidence will be overridden to `fail`.

package/dist/clients/claude/platforms/skill.browser.md

@@ -0,0 +1,31 @@
+<!-- Browser cycle verification is ENABLED for this project. The Stop hook
+     enforces a browser cycle whenever an edited file matches
+     `browser.verifyPatterns` (default: most code extensions). -->
+
+## Browser flow
+
+> **Recording (only when `recording.enable` is on in config):** the gate blocks every other browser tool until you first call `mcp__browser-devtools__bdt_content_start-recording`, and `submit-verdict` rejects with `"recording is still active"` unless you call `mcp__browser-devtools__bdt_content_stop-recording` after the steps below. **Treat start/stop as bookends around steps 1-5.** The same is enforced as step 6 of the Universal flow.
+
+1. **Navigate**: `mcp__browser-devtools__bdt_navigation_go-to` — go to the affected page(s)
+2. **Interact**: actually exercise what changed — click buttons, fill forms, submit data, trigger workflows. Don't just look at the page.
+3. **Screenshot**: `mcp__browser-devtools__bdt_content_take-screenshot` — capture the final visual state
+4. **Accessibility**: `mcp__browser-devtools__bdt_a11y_take-aria-snapshot` — verify page structure
+5. **Console**: `mcp__browser-devtools__bdt_o11y_get-console-messages` — check for errors
+
+All four tools are MANDATORY (the Stop hook checks each). Functional interaction is expected for every verification.
+
+### Browser verdict fields
+```json
+{
+  "session_id": "<sid>",
+  "status": "pass",
+  "pages_tested": ["http://localhost:3000/page"],
+  "checks": ["form submits successfully", "new item appears in list", "no console errors"],
+  "console_errors": 0,
+  "network_failures": 0
+}
+```
+
+For `status: "pass"` (browser cycle): `console_errors === 0` AND `network_failures === 0`.
+
+On fail, include `issues`. On pass after a previous fail, include `fixes`.

package/dist/clients/claude/{fragments → platforms}/skill.node.md

@@ -1,6 +1,6 @@
 <!-- Node backend verification is ENABLED for this project. The Stop hook
      enforces a node cycle in addition to the browser cycle whenever an
-     edited file matches `backend.node.verifyPatterns`. -->
+     edited file matches `node.verifyPatterns`. -->
 
 ## ⚠️ CRITICAL: when NOT to use node-devtools
 
@@ -15,7 +15,7 @@
 
 If you see `pom.xml`, `build.gradle`, `requirements.txt`, `pyproject.toml`, `go.mod`, `Cargo.toml`, `Gemfile`, `composer.json`, `*.csproj` — the backend is NOT Node.js. Do NOT call any `ndt_*` tools.
 
-**Misconfiguration recovery.** If you read this section it means the operator enabled the node cycle for this project. If the backend isn't actually Node.js, this was a mistake — the Stop hook will keep blocking the gate (with `incomplete_tools` for the node cycle) until you call `ndt_debug_connect` (which will fail) or `maxRetries` is exhausted. Don't attempt the connection. Stop and tell the user clearly: the project's backend is not Node.js; ask them to run `ironbee disable-backend node` to unblock the gate. Continue with browser-cycle verification only in the meantime.
+**Misconfiguration recovery.** If you read this section it means the operator enabled the node cycle for this project. If the backend isn't actually Node.js, this was a mistake — the Stop hook will keep blocking the gate (with `incomplete_tools` for the node cycle) until you call `ndt_debug_connect` (which will fail) or `maxRetries` is exhausted. Don't attempt the connection. Stop and tell the user clearly: the project's backend is not Node.js; ask them to run `ironbee node disable` to unblock the gate. Continue with browser-cycle verification only in the meantime.
 
 ## Node flow
 

package/dist/clients/claude/rules/ironbee-verification.md

@@ -1,10 +1,8 @@
 You MUST verify all code changes through real tools before completing any task. After every verification attempt, you MUST submit a verdict (pass or fail) via `ironbee hook submit-verdict` before doing anything else. If verification fails, submit the fail verdict first, then fix.
 
-Verification runs in **cycles** decided by file pattern match — you don't choose, the gate detects:
+Verification runs in **cycles** decided by file-pattern match — you don't choose, the gate detects. Multiple cycles can run in parallel within a single Stop hook; each one has its own activation patterns, tools, and verdict fields.
 
-- **Browser cycle** — frontend file changes (default: most code extensions). Tools come from the **browser-devtools** MCP server (prefix `bdt_`). Verification means navigating to the affected page and FUNCTIONALLY exercising the change in the browser — clicking, typing, submitting — not just looking at it.
-
-A backend-runtime cycle (e.g. `node` after `ironbee enable-backend node`) may also be active for this project — **see the runtime section near the bottom of this file** for whether it applies and which tools to call.
+**See the platform sections near the bottom of this file** for which cycles are active for this project, the tools they expose, and the per-cycle verdict fields you must include.
 
 ## Application lifecycle
 
@@ -19,16 +17,14 @@ Skip start if already running. Fix build errors before proceeding. **Don't guess
 
 1. Build and start the application if not already running.
 2. **Start verification**: `echo '{"session_id":"<your-session-id>"}' | ironbee hook verification-start` — required before any devtools tool call.
-3. Run the **Browser cycle** flow: navigate (`bdt_navigation_go-to`) → functionally test → screenshot (`bdt_content_take-screenshot`) → accessibility (`bdt_a11y_take-aria-snapshot`) → console (`bdt_o11y_get-console-messages`). All four are MANDATORY.
-   - If `recording.enable` is on, the gate forces `bdt_content_start-recording` BEFORE the steps above and rejects the verdict if you don't call `bdt_content_stop-recording` AFTER them. Always pair start/stop around steps above.
-   - **See the runtime section near the bottom of this file** — if a backend-runtime cycle is active for this project, run its flow within the same verification cycle as well.
+3. **Run the per-cycle flow for every active cycle** — see the platform sections near the bottom of this file. Multiple cycles can be active in the same Stop run; every one of them must be exercised within this single verification cycle.
 4. Stop the dev server when done.
-5. **If recording was started, stop it NOW** — `bdt_content_stop-recording` BEFORE submit-verdict. submit-verdict rejects with "recording is still active" if you skip this.
+5. **Honor any cycle-specific teardown** noted in the platform sections BEFORE submit-verdict.
 6. **IMMEDIATELY submit your verdict** — do NOT edit any code before submitting: `echo '<verdict-json>' | ironbee hook submit-verdict`.
    - Pass verdict carries fields for every active cycle. Fail verdict adds `issues`. Pass after fail adds `fixes`.
    - Status `pass` is overridden to fail by the gate when evidence doesn't back it.
 
-The stop hook checks tool usage AND verdict validity for every active cycle. After EVERY verification attempt, you MUST submit a verdict before doing anything else — even if it failed. Do not skip to fixing code.
+The Stop hook checks tool usage AND verdict validity for every active cycle. After EVERY verification attempt, you MUST submit a verdict before doing anything else — even if it failed. Do not skip to fixing code.
 
 If verification fails: submit fail verdict → fix the code → re-verify → submit again.
 
@@ -41,8 +37,13 @@ Every code edit (Write/Edit) automatically clears your verdict, requiring re-ver
 - Submitting a verdict without actually performing verification through real tools.
 - Submitting a verdict based on assumptions, code reading, or prior knowledge.
 - Copying example verdicts from hook messages without doing real verification first.
-- Calling `bdt_*` tools without first opening a verification cycle (`ironbee hook verification-start`).
-- **Submitting a verdict while a browser recording is still active** — always call `bdt_content_stop-recording` BEFORE `ironbee hook submit-verdict`. The recording start/stop pair brackets the verification flow.
+- Calling devtools tools for any cycle without first opening a verification cycle (`ironbee hook verification-start`).
+
+<!--IRONBEE:PLATFORM:browser-->
+<!--/IRONBEE:PLATFORM:browser-->
+
+<!--IRONBEE:PLATFORM:node-->
+<!--/IRONBEE:PLATFORM:node-->
 
-<!--IRONBEE:RUNTIME:node-->
-<!--/IRONBEE:RUNTIME:node-->
+<!--IRONBEE:PLATFORM:backend-->
+<!--/IRONBEE:PLATFORM:backend-->

package/dist/clients/claude/skills/ironbee-verification.md

@@ -3,31 +3,30 @@ name: ironbee-verification
 description: >
   MANDATORY verification after code changes. Activates when implementing features, fixing
   bugs, modifying UI components, API endpoints, styles, refactoring, or any task that
-  changes application behavior. Frontend changes require browser verification via the
-  browser-devtools MCP server. Backend changes ALSO require runtime-specific verification
-  via the matching MCP server when the operator has enabled that runtime (see
-  `ironbee enable-backend <runtime>`). After every code edit you MUST verify the affected
-  cycle(s) through real tools and submit a single verdict (pass or fail) before reporting
-  task completion. If verification fails, submit the fail verdict first, then fix.
+  changes application behavior. Verification runs in cycles activated by file-pattern
+  match — which cycles are wired up for this project is shown in the platform sections
+  near the bottom of this file. After every code edit you MUST verify the affected
+  cycle(s) through real tools and submit a single verdict (pass or fail) before
+  reporting task completion. If verification fails, submit the fail verdict first,
+  then fix.
 ---
 
 # IronBee Verification
 
 ## Rule
-No task is complete until changes are verified — through **real tools** (browser interaction or, when enabled, a backend-runtime debugger), not by reading code or inferring behavior. After verification, you MUST submit a verdict (pass or fail) before doing anything else. If verification fails, submit the fail verdict first, then fix.
+No task is complete until changes are verified — through **real tools**, not by reading code or inferring behavior. After verification, you MUST submit a verdict (pass or fail) before doing anything else. If verification fails, submit the fail verdict first, then fix.
 
 ## Cycles
 
 IronBee runs verification in **cycles**. A single Stop hook can drive multiple cycles in parallel — every active cycle must pass for your task to complete.
 
-- **Browser cycle** — always available. Triggered when a changed file matches `browser.verifyPatterns` (default: most code extensions — `.ts`, `.tsx`, `.css`, `.html`, `.py`, `.go`, `.java`, etc.). Tools come from the **browser-devtools** MCP server (prefix `bdt_`). Verification means navigating to the affected page and FUNCTIONALLY exercising the change in the browser.
-- **Backend-runtime cycle(s)** — opt-in per project via `ironbee enable-backend <runtime>` (e.g. `node`). Triggered when a changed file matches `backend.<runtime>.verifyPatterns`. Tools come from a runtime-specific MCP server. **See the runtime section near the bottom of this file** for whether a backend cycle is active for this project and which tools to call.
+You don't choose which cycle runs — the file pattern decides. A single edited file can match multiple cycles' patterns and activate them all. Cycles always run in parallel within a single Stop run. Each cycle has its own tools, flow steps, and verdict fields.
 
-You don't choose which cycle runs — the file pattern decides. A single file can match multiple cycles' patterns and activate them all. Cycles always run in parallel within a single Stop run.
+**See the platform sections near the bottom of this file** for which cycles are active for this project, the tools they expose, and the per-cycle verdict fields you must include.
 
 ## Application lifecycle (your responsibility)
 
-For both cycles you manage the running application:
+For every active cycle you manage the running application:
 - **Build** if needed (`npm run build`, `docker compose build`, …)
 - **Start** before navigating/connecting (`npm run dev`, `docker compose up -d`, …)
 - **Stop** when verification is complete
@@ -39,15 +38,15 @@ If already running, skip start. If the build fails, fix it before proceeding.
 ## Universal flow
 
 1. Implement your changes (write/edit code).
-2. **Start verification** (one cycle covers every active mode — browser plus any enabled backend-runtime cycles):
+2. **Start verification** (one cycle covers every active mode — every active cycle's flow runs within the same verification cycle):
    ```
    echo '{"session_id":"<your-session-id>"}' | ironbee hook verification-start
    ```
    Devtools tools are blocked without this.
 3. Build and start the application if not already running.
-4. Run the **Browser flow** below. **See the runtime section near the bottom of this file** — if a backend-runtime cycle is active for this project, run its flow within the same verification cycle as well.
+4. **Run the per-cycle flows for every active cycle.** See the platform sections near the bottom of this file — each enabled cycle's section has its own flow steps, mandatory tools, and verdict fields. All active cycles must be exercised within this one verification cycle.
 5. Stop the dev server when verification is complete.
-6. **If recording was started, stop it now** — `mcp__browser-devtools__bdt_content_stop-recording`. submit-verdict rejects when recording is still active.
+6. **Honor any cycle-specific teardown** noted in the platform sections (e.g. recording stop) BEFORE submitting your verdict.
 7. **Submit your verdict immediately** — do NOT edit any code first:
    ```
    echo '<verdict-json>' | ironbee hook submit-verdict
@@ -57,43 +56,14 @@ If already running, skip start. If the build fails, fix it before proceeding.
    - **The Stop hook overrides `status: pass` to fail when evidence doesn't back it.**
 8. If failed → fix → rebuild → go back to step 2 → repeat until pass.
 
-## Browser flow (when browser cycle is active)
+<!--IRONBEE:PLATFORM:browser-->
+<!--/IRONBEE:PLATFORM:browser-->
 
-> **Recording (only when `recording.enable` is on in config):** the gate blocks every other browser tool until you first call `mcp__browser-devtools__bdt_content_start-recording`, and `submit-verdict` rejects with `"recording is still active"` unless you call `mcp__browser-devtools__bdt_content_stop-recording` after the steps below. **Treat start/stop as bookends around steps 1-5.** This is also enforced as step 6 of the Universal flow above.
+<!--IRONBEE:PLATFORM:node-->
+<!--/IRONBEE:PLATFORM:node-->
 
-1. **Navigate**: `mcp__browser-devtools__bdt_navigation_go-to` — go to the affected page(s)
-2. **Interact**: actually exercise what changed — click buttons, fill forms, submit data, trigger workflows. Don't just look at the page.
-3. **Screenshot**: `mcp__browser-devtools__bdt_content_take-screenshot` — capture the final visual state
-4. **Accessibility**: `mcp__browser-devtools__bdt_a11y_take-aria-snapshot` — verify page structure
-5. **Console**: `mcp__browser-devtools__bdt_o11y_get-console-messages` — check for errors
-
-All four tools are MANDATORY (the Stop hook checks each). Functional interaction is expected for every verification.
-
-### Browser verdict fields
-```json
-{
-  "session_id": "<sid>",
-  "status": "pass",
-  "pages_tested": ["http://localhost:3000/page"],
-  "checks": ["form submits successfully", "new item appears in list", "no console errors"],
-  "console_errors": 0,
-  "network_failures": 0
-}
-```
-
-For `status: "pass"` (browser cycle): `console_errors === 0` AND `network_failures === 0`.
-
-On fail, include `issues`. On pass after a previous fail, include `fixes`.
-
-<!--IRONBEE:RUNTIME:node-->
-<!--/IRONBEE:RUNTIME:node-->
-
-## What good verification looks like
-
-- Changed a form handler? → Start the app, fill the form, submit it, verify the response (browser flow).
-- Added an API endpoint in a backend file (when a runtime cycle is enabled)? → Run that runtime's flow per the runtime section: attach to the running process, set a probe at the handler, exercise the path from the browser, confirm the probe triggered (or inspect runtime logs).
-- Fixed a bug that surfaced as both a UI glitch AND a server error? → Multi-cycle: visual confirmation in the browser AND probe/log proof on the server.
-- Changed styling only? → Browser flow with extra attention on screenshot review.
+<!--IRONBEE:PLATFORM:backend-->
+<!--/IRONBEE:PLATFORM:backend-->
 
 ## Important
 - **Always submit a verdict after every verification attempt** — both pass AND fail. Fail verdicts are tracked for analytics.

package/dist/clients/cursor/commands/ironbee-verify/SKILL.md

@@ -1,126 +1,44 @@
 ---
 name: ironbee-verify
-description: "Trigger verification of code changes (browser cycle for frontend, runtime-specific cycle for backend when enabled). Args: (default), full, visual, functional"
+description: "Trigger verification of code changes — runs every active cycle wired up for this project (see the platform sections at the bottom of the file)."
 disable-model-invocation: true
 ---
 
 # IronBee Verify
 
-Verify the current code changes through real tools — browser interaction for frontend, runtime-specific debugger for any enabled backend cycle.
+Verify the current code changes through real tools. The gate runs every cycle that has been wired up for this project, and all active cycles must be satisfied within a single verification cycle for `status: pass`. Each cycle has its own tools, flow, and verdict fields — **see the platform sections near the bottom of this file** for which cycles apply and what to call.
 
-## Usage
-- `/ironbee-verify` — **default** — focus on what changed, visual + functional checks on affected areas (browser-cycle modes; any enabled backend-runtime cycle runs alongside automatically — see runtime section below)
-- `/ironbee-verify full` — **full scope** — entire application, all checklists, edge cases, responsive, accessibility deep dive
-- `/ironbee-verify visual` — **visual only** — contrast, layout, spacing, fonts, images, theming
-- `/ironbee-verify functional` — **functional only** — clicks, forms, navigation, data flow, error handling
+## Universal steps
 
-A backend-runtime cycle (e.g. `node` after `ironbee enable-backend node`) may also be active for this project — **see the runtime section near the bottom of this file** for whether it applies and which tools to call.
-
-If no argument is given, use **default** mode.
-
----
-
-## Steps (all modes)
-
-1. **Start verification**: Run `echo '{"session_id":"<your-session-id>"}' | ironbee hook verification-start` via terminal
-2. **Build and start** the application if not already running
-3. **For EVERY page you visit**, repeat this cycle:
-   a. **Navigate** using `MCP:bdt_navigation_go-to`
-   b. **Take a FULL PAGE screenshot** using `MCP:bdt_content_take-screenshot` with `fullPage: true`
-   c. **Take an ARIA snapshot** using `MCP:bdt_a11y_take-aria-snapshot`
-   d. **STOP and visually analyze the screenshot** — switch your focus entirely to finding visual problems. Look at this screenshot as if your ONLY job is to find visual defects:
-      **WARNING: ARIA reports DOM content, not what the user actually sees.** Do NOT assume the page looks correct just because ARIA shows the right content. Only the screenshot tells you what the user actually sees.
-      - Text readability — is it readable against its background? Look for text that blends in or poor contrast
-      - Layout — overlapping elements, unexpected gaps, overflow, content cut off
-      - Spacing — consistent padding/margin? Too cramped or too far apart?
-      - Colors — intentional and consistent? Any jarring mismatches?
-      - Typography — right sizes? Clipped or truncated text?
-      - Images/icons — loaded? Right size and aspect ratio?
-      - States — empty, loading, disabled, error states rendered properly?
-      Report your visual findings before continuing.
-   e. **Read the ARIA snapshot** — verify headings, labels, landmarks, and structure
-   f. If anything looks wrong → note it as an issue
-4. **Functionally test** — run the checklist for your mode (see below). After each significant interaction, take another screenshot and repeat the visual analysis.
-5. **Check console** for errors using `MCP:bdt_o11y_get-console-messages`
-6. **Stop** the dev server when verification is complete
-7. **If recording was started, stop it now** — `MCP:bdt_content_stop-recording`. submit-verdict rejects with `"recording is still active"` when this step is skipped. (Recording is a server-side opt-in via `recording.enable` — when on, the gate forces `MCP:bdt_content_start-recording` BEFORE the steps above and demands the matching stop here.)
-8. **Submit your verdict** via terminal:
-    - Pass: `echo '{"session_id":"...","status":"pass","pages_tested":[...],"checks":[...],"console_errors":0,"network_failures":0}' | ironbee hook submit-verdict`
-    - Fail: `echo '{"session_id":"...","status":"fail","pages_tested":[...],"checks":[...],"console_errors":N,"network_failures":N,"issues":["describe what failed"]}' | ironbee hook submit-verdict`
-9. **If failed** → collect ALL issues first (finish testing all affected pages), submit one fail verdict with all issues, then fix everything, rebuild, and re-verify. Do not fix one issue at a time — batch fixes to avoid repeated build/restart cycles.
-10. If pass after a previous fail, include `"fixes"` in the verdict describing what was fixed
+1. **Start verification**: Run `echo '{"session_id":"<your-session-id>"}' | ironbee hook verification-start` via terminal.
+2. **Build and start** the application if not already running.
+3. **For every active cycle, run its flow** as described in the platform sections near the bottom of this file. All active cycles must be exercised within this same verification cycle.
+4. **Stop** the dev server when verification is complete.
+5. **Honor any cycle-specific teardown** noted in the platform sections BEFORE submitting your verdict.
+6. **Submit your verdict** via terminal. Include fields for every active cycle:
+    - Pass: `echo '{"session_id":"...","status":"pass", ...cycle-specific fields...}' | ironbee hook submit-verdict`
+    - Fail: `echo '{"session_id":"...","status":"fail", ...cycle-specific fields..., "issues":["describe what failed"]}' | ironbee hook submit-verdict`
+7. **If failed** → collect ALL issues first (finish testing every active cycle), submit one fail verdict with all issues, then fix everything, rebuild, and re-verify. Do not fix one issue at a time — batch fixes to avoid repeated build/restart cycles.
+8. If pass after a previous fail, include `"fixes"` in the verdict describing what was fixed.
 
 ---
 
-## Default Mode
+<!--IRONBEE:PLATFORM:browser-->
+<!--/IRONBEE:PLATFORM:browser-->
 
-Focus on the code you changed — not the entire application.
+<!--IRONBEE:PLATFORM:node-->
+<!--/IRONBEE:PLATFORM:node-->
 
-### 1. Study the changes
-1. Run `git diff --name-only` and `git diff --name-only HEAD~1`
-2. **Ignore `.ironbee/`, `.claude/`, `.cursor/`** — tool config, not application code
-3. **Read the full diff** (`git diff` and/or `git diff HEAD~1`) — understand every change: what was added, removed, modified. Note specific values (colors, sizes, conditions, logic, API endpoints, component props).
-4. Before opening the browser, you should be able to answer: what exactly changed, what should look or behave differently, and what could go wrong?
-
-### 2. Verify in the browser
-- **Cross-reference the diff against what you see.** For each change in the diff, verify it is correctly reflected in the browser. If the diff changes a color → check that color. If it changes a calculation → verify the result. If it adds a component → confirm it renders.
-- **Test the flow end-to-end** — navigate, click, fill forms, submit, verify the outcome
-- **Check one edge case** — empty input, invalid data, or double-click
-- **Console** — any new errors or warnings?
-
----
-
-## Full Mode (`/ironbee-verify full`)
-
-Comprehensive verification of the **entire application**. Do NOT run `git diff` or scope to recent changes. Test every page, every flow, every visual detail. Any issue is a failure, regardless of when it was introduced.
-
-### Visual Checklist
-In addition to the per-page visual analysis in step 3d:
-- **Responsiveness** — does the layout adapt if viewport changes? No horizontal scrolling on standard widths
-- **Borders & separators** — visible and consistent? Not too faint or missing
-- **Scroll behavior** — does the page scroll smoothly? No content hidden behind sticky headers/footers?
-
-### Functional Checklist
-- **Navigation** — do links and buttons navigate to the correct pages?
-- **Forms** — fill inputs with real data, select options, submit. Do validation messages appear correctly?
-- **Buttons & interactions** — do click handlers fire? Do toggles, dropdowns, and modals work?
-- **Data flow** — does submitted data appear where expected?
-- **Error handling** — what happens with invalid input? Does the UI handle errors gracefully?
-- **Authentication** — if applicable, do protected routes redirect correctly?
-- **API calls** — do network requests succeed? Check for failed requests in console/network
-- **State persistence** — does state survive page refresh where expected?
-- **Edge cases** — empty inputs, very long text, special characters, rapid clicks
-
-### Accessibility (deep dive)
-- Are headings hierarchical? Do form inputs have labels? Are landmarks present?
-- Check for missing alt text on images
-
----
-
-## Visual Mode (`/ironbee-verify visual`)
-
-Focus exclusively on visual quality. Run the per-page visual analysis from step 3d on every page, plus:
-- **Responsiveness** — viewport changes, no horizontal scrolling
-- **Borders & separators** — visible and consistent?
-- **Scroll behavior** — smooth scrolling, no hidden content
-
-Take screenshots of **multiple states** if applicable (hover, active, disabled, empty, populated).
-
----
-
-## Functional Mode (`/ironbee-verify functional`)
-
-Focus exclusively on behavior. Use the same functional checklist as Full Mode above.
-
-Test the **complete user flow**, not just the single step you changed.
+<!--IRONBEE:PLATFORM:backend-->
+<!--/IRONBEE:PLATFORM:backend-->
 
 ---
 
 ## When to FAIL
 
-If you observe ANY problem — wrong data, unexpected errors, visual defects, broken interactions, console errors, data inconsistency between pages — you MUST submit a **fail** verdict.
+If you observe ANY problem on any active cycle — wrong data, unexpected errors, broken interactions, missing evidence, anything that doesn't match the spec — you MUST submit a **fail** verdict.
 
-**Do NOT rationalize away problems.** If something looks wrong or behaves unexpectedly, it IS wrong. In **full** mode, there is no such thing as "pre-existing" — if it's broken, fail it.
+**Do NOT rationalize away problems.** If something looks wrong or behaves unexpectedly, it IS wrong.
 
 **After a fail verdict, you MUST fix the issues and re-verify.** Do not just report and stop.
 
@@ -134,8 +52,3 @@ Your `checks` array must list **specific observations**, not generic statements:
 - ALWAYS submit a verdict after every verification attempt — both pass AND fail
 - Do NOT edit code before submitting a fail verdict
 - **Noticing a bug and submitting pass is the #1 violation** — if you see it, fail it
-
----
-
-<!--IRONBEE:RUNTIME:node-->
-<!--/IRONBEE:RUNTIME:node-->

package/dist/clients/cursor/hooks/require-verdict.d.ts

@@ -2,7 +2,7 @@
  * Cursor — require-verdict hook adapter
  *
  * preToolUse hook for Write|StrReplace|Delete — blocks file edits
- * if the agent used any devtools tools (browser-devtools or node-devtools) but hasn't submitted a verdict
+ * if the agent used any devtools tools (browser-devtools / node-devtools / backend-devtools) but hasn't submitted a verdict
  * yet. Forces the agent to submit a fail verdict before fixing code.
  *
  * Side effect: when `tool_name === "Write"`, stashes whether the target

package/dist/clients/cursor/hooks/require-verdict.js

@@ -3,7 +3,7 @@
  * Cursor — require-verdict hook adapter
  *
  * preToolUse hook for Write|StrReplace|Delete — blocks file edits
- * if the agent used any devtools tools (browser-devtools or node-devtools) but hasn't submitted a verdict
+ * if the agent used any devtools tools (browser-devtools / node-devtools / backend-devtools) but hasn't submitted a verdict
  * yet. Forces the agent to submit a fail verdict before fixing code.
  *
  * Side effect: when `tool_name === "Write"`, stashes whether the target
@@ -42,9 +42,9 @@ async function run(projectDir) {
     if ((0, actions_1.hasToolCallsSinceLastVerdict)(actionsFile)) {
         const output = {
             permission: "deny",
-            agent_message: `BLOCKED: You used verification tools (browser-devtools or node-devtools) but did not submit a verdict. You MUST submit a verdict (pass or fail) before editing code.
+            agent_message: `BLOCKED: You used verification tools (browser-devtools / node-devtools / backend-devtools) but did not submit a verdict. You MUST submit a verdict (pass or fail) before editing code.
 
-Submit your verdict first (include cycle-appropriate fields — browser fields for bdt_*, backend_node_* fields for ndt_*):
+Submit your verdict first (include cycle-appropriate fields — browser fields for bdt_*, backend_node_* for ndt_*, backend_endpoints_called/backend_response_statuses for bedt_*):
   echo '{"session_id":"${sessionId}","status":"fail","checks":[...],"issues":["describe what failed"], ...}' | ironbee hook submit-verdict
 
 Then you can edit code to fix the issues.`,

package/dist/clients/cursor/hooks/require-verification.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"require-verification.d.ts","sourceRoot":"","sources":["../../../../src/clients/cursor/hooks/require-verification.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;GAYG;AAkCH,wBAAsB,GAAG,CAAC,UAAU,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC,CA8H3D"}
+{"version":3,"file":"require-verification.d.ts","sourceRoot":"","sources":["../../../../src/clients/cursor/hooks/require-verification.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;GAYG;AAsCH,wBAAsB,GAAG,CAAC,UAAU,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC,CA8H3D"}

package/dist/clients/cursor/hooks/require-verification.js

@@ -22,10 +22,14 @@ const config_1 = require("../../../lib/config");
 const logger_1 = require("../../../lib/logger");
 const stdin_1 = require("../../../lib/stdin");
 /** Prefix → MCP server lookup. Cursor's `MCP:<bare-tool>` wire has no server
- *  segment, so we identify by tool prefix (matcher widened to `MCP:(bdt|ndt)_.*`). */
+ *  segment, so we identify by tool prefix (matcher routes
+ *  `MCP:(bdt|ndt|bedt)_.*`). All three prefixes are mutually distinct
+ *  (`bdt` / `ndt` / `bedt` differ in the second character), so iteration
+ *  order doesn't matter for correctness. */
 const SERVER_BY_PREFIX = {
     "MCP:bdt_": "browser-devtools",
     "MCP:ndt_": "node-devtools",
+    "MCP:bedt_": "backend-devtools",
 };
 const FALLBACK_MCP_SERVER_NAME = "browser-devtools";
 async function run(projectDir) {
@@ -48,12 +52,12 @@ async function run(projectDir) {
     if (!verificationId) {
         const output = {
             permission: "deny",
-            agent_message: `BLOCKED: You must start a verification cycle before using devtools tools (browser-devtools or node-devtools).
+            agent_message: `BLOCKED: You must start a verification cycle before using devtools tools (browser-devtools / node-devtools / backend-devtools).
 
 Start verification first:
   echo '{"session_id":"${sessionId}"}' | ironbee hook verification-start
 
-Then use the verification tools for the active cycle(s) — MCP:bdt_* for browser, MCP:ndt_* for node.`,
+Then use the verification tools for the active cycle(s) — MCP:bdt_* for browser, MCP:ndt_* for node, MCP:bedt_* for backend.`,
         };
         process.stdout.write(JSON.stringify(output));
         process.exit(2);
@@ -118,8 +122,8 @@ Then use the verification tools for the active cycle(s) — MCP:bdt_* for browse
     }
     // Cursor's preToolUse stdin doesn't expose the MCP server and its
     // tool_name format (`MCP:<bare-tool>`) has no server segment. The
-    // matcher restricts this hook to `MCP:(bdt|ndt)_.*` — we identify the
-    // server by prefix lookup. Future runtimes extend SERVER_BY_PREFIX.
+    // matcher restricts this hook to `MCP:(bdt|ndt|bedt)_.*` — we identify
+    // the server by prefix lookup. Future runtimes extend SERVER_BY_PREFIX.
     metadata.mcpServer = (() => {
         for (const prefix of Object.keys(SERVER_BY_PREFIX)) {
             if (toolName.startsWith(prefix)) {

package/dist/clients/cursor/hooks/require-verification.js.map

@@ -1 +1 @@
-{"version":3,"file":"require-verification.js","sourceRoot":"","sources":["../../../../src/clients/cursor/hooks/require-verification.ts"],"names":[],"mappings":";AAAA;;;;;;;;;;;;GAYG;;AAkCH,kBA8HC;AA9JD,mCAAoC;AACpC,qEAAyK;AACzK,yDAAiE;AACjE,2DAA6D;AAC7D,gDAAiD;AACjD,gDAAyD;AACzD,8CAA+C;AAE/C;sFACsF;AACtF,MAAM,gBAAgB,GAA2B;IAC7C,UAAU,EAAE,kBAAkB;IAC9B,UAAU,EAAE,eAAe;CAC9B,CAAC;AAEF,MAAM,wBAAwB,GAAW,kBAAkB,CAAC;AAiBrD,KAAK,UAAU,GAAG,CAAC,UAAkB;IACxC,IAAI,KAA4B,CAAC;IACjC,IAAI,CAAC;QACD,KAAK,GAAG,IAAI,CAAC,KAAK,CAAC,IAAA,iBAAS,GAAE,CAA0B,CAAC;IAC7D,CAAC;IAAC,OAAO,CAAU,EAAE,CAAC;QAClB,eAAM,CAAC,KAAK,CAAC,0BAA0B,CAAC,EAAE,CAAC,CAAC;QAC5C,MAAM,MAAM,GAA2B,EAAE,UAAU,EAAE,OAAO,EAAE,CAAC;QAC/D,OAAO,CAAC,MAAM,CAAC,KAAK,CAAC,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,CAAC,CAAC;QAC7C,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;QAChB,OAAO;IACX,CAAC;IAED,MAAM,SAAS,GAAW,KAAK,CAAC,eAAe,IAAI,SAAS,CAAC;IAC7D,MAAM,UAAU,GAAW,GAAG,UAAU,sBAAsB,SAAS,EAAE,CAAC;IAC1E,IAAA,mBAAU,EAAC,GAAG,UAAU,cAAc,CAAC,CAAC;IAExC,MAAM,WAAW,GAAW,GAAG,UAAU,gBAAgB,CAAC;IAE1D,MAAM,cAAc,GAAuB,IAAA,uCAAuB,EAAC,UAAU,CAAC,CAAC;IAC/E,IAAI,CAAC,cAAc,EAAE,CAAC;QAClB,MAAM,MAAM,GAA2B;YACnC,UAAU,EAAE,MAAM;YAClB,aAAa,EAAE;;;yBAGF,SAAS;;qGAEmE;SAC5F,CAAC;QACF,OAAO,CAAC,MAAM,CAAC,KAAK,CAAC,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,CAAC,CAAC;QAC7C,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;QAChB,OAAO;IACX,CAAC;IAED,mEAAmE;IACnE,0CAA0C;IAC1C,MAAM,QAAQ,GAAW,KAAK,CAAC,SAAS,IAAI,EAAE,CAAC;IAC/C,MAAM,qBAAqB,GAAY,QAAQ,CAAC,UAAU,CAAC,UAAU,CAAC,CAAC;IACvE,MAAM,oBAAoB,GAAY,QAAQ,CAAC,QAAQ,CAAC,6BAA6B,CAAC,CAAC;IACvF,IACI,qBAAqB;QACrB,IAAA,mCAAmB,EAAC,UAAU,CAAC;QAC/B,CAAC,IAAA,iCAAiB,EAAC,UAAU,CAAC;QAC9B,CAAC,oBAAoB,EACvB,CAAC;QACC,MAAM,MAAM,GAA2B;YACnC,UAAU,EAAE,MAAM;YAClB,aAAa,EAAE;;;;;;;;;iFASsD;SACxE,CAAC;QACF,OAAO,CAAC,MAAM,CAAC,KAAK,CAAC,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,CAAC,CAAC;QAC7C,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;QAChB,OAAO;IACX,CAAC;IAED,yEAAyE;IACzE,MAAM,IAAA,wBAAa,EAAC,EAAE,UAAU,EAAE,WAAW,EAAE,MAAM,EAAE,cAAc,EAAE,CAAC,CAAC;IAEzE,MAAM,OAAO,GAAuB,IAAA,gCAAgB,EAAC,UAAU,CAAC,CAAC;IACjE,MAAM,UAAU,GAAuB,IAAA,mCAAmB,EAAC,UAAU,CAAC,CAAC;IAEvE,6EAA6E;IAC7E,MAAM,WAAW,GAAW,IAAA,4BAAkB,EAAC,UAAU,CAAC,CAAC;IAC3D,MAAM,eAAe,GAAa,CAAC,OAAO,WAAW,EAAE,EAAE,OAAO,SAAS,EAAE,CAAC,CAAC;IAC7E,IAAI,UAAU,EAAE,CAAC;QACb,eAAe,CAAC,IAAI,CAAC,OAAO,UAAU,EAAE,CAAC,CAAC;IAC9C,CAAC;IACD,eAAe,CAAC,IAAI,CAAC,OAAO,cAAc,EAAE,CAAC,CAAC;IAC9C,MAAM,UAAU,GAAW,WAAW,eAAe,CAAC,IAAI,CAAC,GAAG,CAAC,EAAE,CAAC;IAClE,MAAM,MAAM,GAAkC,IAAA,mBAAU,EAAC,UAAU,CAAC,CAAC;IACrE,MAAM,YAAY,GAA4B,EAAE,GAAG,CAAC,KAAK,CAAC,UAAU,IAAI,EAAE,CAAC,EAAE,CAAC;IAC9E,MAAM,QAAQ,GAA4B;QACtC,WAAW;QACX,SAAS;QACT,UAAU;QACV,cAAc;QACd,OAAO;QACP,UAAU;QACV,oEAAoE;QACpE,kEAAkE;QAClE,gEAAgE;QAChE,gEAAgE;QAChE,kDAAkD;QAClD,UAAU,EAAE,IAAA,mBAAU,GAAE;KAC3B,CAAC;IACF,IAAI,KAAK,CAAC,WAAW,EAAE,CAAC;QACpB,QAAQ,CAAC,SAAS,GAAG,KAAK,CAAC,WAAW,CAAC;IAC3C,CAAC;IACD,kEAAkE;IAClE,kEAAkE;IAClE,sEAAsE;IACtE,oEAAoE;IACpE,QAAQ,CAAC,SAAS,GAAG,CAAC,GAAW,EAAE;QAC/B,KAAK,MAAM,MAAM,IAAI,MAAM,CAAC,IAAI,CAAC,gBAAgB,CAAC,EAAE,CAAC;YACjD,IAAI,QAAQ,CAAC,UAAU,CAAC,MAAM,CAAC,EAAE,CAAC;gBAC9B,OAAO,gBAAgB,CAAC,MAAM,CAAC,CAAC;YACpC,CAAC;QACL,CAAC;QACD,OAAO,wBAAwB,CAAC;IACpC,CAAC,CAAC,EAAE,CAAC;IACL,MAAM,SAAS,GAAuB,IAAA,4BAAY,EAAC,UAAU,CAAC,CAAC;IAC/D,IAAI,SAAS,EAAE,CAAC;QACZ,QAAQ,CAAC,SAAS,GAAG,SAAS,CAAC;IACnC,CAAC;IACD,IAAI,MAAM,CAAC,SAAS,EAAE,GAAG,EAAE,CAAC;QACxB,QAAQ,CAAC,YAAY,GAAG,MAAM,CAAC,SAAS,CAAC,GAAG,CAAC;IACjD,CAAC;IACD,IAAI,MAAM,CAAC,SAAS,EAAE,MAAM,EAAE,CAAC;QAC3B,QAAQ,CAAC,eAAe,GAAG,MAAM,CAAC,SAAS,CAAC,MAAM,CAAC;IACvD,CAAC;IACD,YAAY,CAAC,SAAS,GAAG,QAAQ,CAAC;IAElC,MAAM,MAAM,GAA2B;QACnC,UAAU,EAAE,OAAO;QACnB,aAAa,EAAE,YAAY;KAC9B,CAAC;IACF,OAAO,CAAC,MAAM,CAAC,KAAK,CAAC,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,CAAC,CAAC;IAC7C,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;AACpB,CAAC"}
+{"version":3,"file":"require-verification.js","sourceRoot":"","sources":["../../../../src/clients/cursor/hooks/require-verification.ts"],"names":[],"mappings":";AAAA;;;;;;;;;;;;GAYG;;AAsCH,kBA8HC;AAlKD,mCAAoC;AACpC,qEAAyK;AACzK,yDAAiE;AACjE,2DAA6D;AAC7D,gDAAiD;AACjD,gDAAyD;AACzD,8CAA+C;AAE/C;;;;4CAI4C;AAC5C,MAAM,gBAAgB,GAA2B;IAC7C,UAAU,EAAE,kBAAkB;IAC9B,UAAU,EAAE,eAAe;IAC3B,WAAW,EAAE,kBAAkB;CAClC,CAAC;AAEF,MAAM,wBAAwB,GAAW,kBAAkB,CAAC;AAiBrD,KAAK,UAAU,GAAG,CAAC,UAAkB;IACxC,IAAI,KAA4B,CAAC;IACjC,IAAI,CAAC;QACD,KAAK,GAAG,IAAI,CAAC,KAAK,CAAC,IAAA,iBAAS,GAAE,CAA0B,CAAC;IAC7D,CAAC;IAAC,OAAO,CAAU,EAAE,CAAC;QAClB,eAAM,CAAC,KAAK,CAAC,0BAA0B,CAAC,EAAE,CAAC,CAAC;QAC5C,MAAM,MAAM,GAA2B,EAAE,UAAU,EAAE,OAAO,EAAE,CAAC;QAC/D,OAAO,CAAC,MAAM,CAAC,KAAK,CAAC,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,CAAC,CAAC;QAC7C,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;QAChB,OAAO;IACX,CAAC;IAED,MAAM,SAAS,GAAW,KAAK,CAAC,eAAe,IAAI,SAAS,CAAC;IAC7D,MAAM,UAAU,GAAW,GAAG,UAAU,sBAAsB,SAAS,EAAE,CAAC;IAC1E,IAAA,mBAAU,EAAC,GAAG,UAAU,cAAc,CAAC,CAAC;IAExC,MAAM,WAAW,GAAW,GAAG,UAAU,gBAAgB,CAAC;IAE1D,MAAM,cAAc,GAAuB,IAAA,uCAAuB,EAAC,UAAU,CAAC,CAAC;IAC/E,IAAI,CAAC,cAAc,EAAE,CAAC;QAClB,MAAM,MAAM,GAA2B;YACnC,UAAU,EAAE,MAAM;YAClB,aAAa,EAAE;;;yBAGF,SAAS;;6HAE2F;SACpH,CAAC;QACF,OAAO,CAAC,MAAM,CAAC,KAAK,CAAC,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,CAAC,CAAC;QAC7C,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;QAChB,OAAO;IACX,CAAC;IAED,mEAAmE;IACnE,0CAA0C;IAC1C,MAAM,QAAQ,GAAW,KAAK,CAAC,SAAS,IAAI,EAAE,CAAC;IAC/C,MAAM,qBAAqB,GAAY,QAAQ,CAAC,UAAU,CAAC,UAAU,CAAC,CAAC;IACvE,MAAM,oBAAoB,GAAY,QAAQ,CAAC,QAAQ,CAAC,6BAA6B,CAAC,CAAC;IACvF,IACI,qBAAqB;QACrB,IAAA,mCAAmB,EAAC,UAAU,CAAC;QAC/B,CAAC,IAAA,iCAAiB,EAAC,UAAU,CAAC;QAC9B,CAAC,oBAAoB,EACvB,CAAC;QACC,MAAM,MAAM,GAA2B;YACnC,UAAU,EAAE,MAAM;YAClB,aAAa,EAAE;;;;;;;;;iFASsD;SACxE,CAAC;QACF,OAAO,CAAC,MAAM,CAAC,KAAK,CAAC,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,CAAC,CAAC;QAC7C,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;QAChB,OAAO;IACX,CAAC;IAED,yEAAyE;IACzE,MAAM,IAAA,wBAAa,EAAC,EAAE,UAAU,EAAE,WAAW,EAAE,MAAM,EAAE,cAAc,EAAE,CAAC,CAAC;IAEzE,MAAM,OAAO,GAAuB,IAAA,gCAAgB,EAAC,UAAU,CAAC,CAAC;IACjE,MAAM,UAAU,GAAuB,IAAA,mCAAmB,EAAC,UAAU,CAAC,CAAC;IAEvE,6EAA6E;IAC7E,MAAM,WAAW,GAAW,IAAA,4BAAkB,EAAC,UAAU,CAAC,CAAC;IAC3D,MAAM,eAAe,GAAa,CAAC,OAAO,WAAW,EAAE,EAAE,OAAO,SAAS,EAAE,CAAC,CAAC;IAC7E,IAAI,UAAU,EAAE,CAAC;QACb,eAAe,CAAC,IAAI,CAAC,OAAO,UAAU,EAAE,CAAC,CAAC;IAC9C,CAAC;IACD,eAAe,CAAC,IAAI,CAAC,OAAO,cAAc,EAAE,CAAC,CAAC;IAC9C,MAAM,UAAU,GAAW,WAAW,eAAe,CAAC,IAAI,CAAC,GAAG,CAAC,EAAE,CAAC;IAClE,MAAM,MAAM,GAAkC,IAAA,mBAAU,EAAC,UAAU,CAAC,CAAC;IACrE,MAAM,YAAY,GAA4B,EAAE,GAAG,CAAC,KAAK,CAAC,UAAU,IAAI,EAAE,CAAC,EAAE,CAAC;IAC9E,MAAM,QAAQ,GAA4B;QACtC,WAAW;QACX,SAAS;QACT,UAAU;QACV,cAAc;QACd,OAAO;QACP,UAAU;QACV,oEAAoE;QACpE,kEAAkE;QAClE,gEAAgE;QAChE,gEAAgE;QAChE,kDAAkD;QAClD,UAAU,EAAE,IAAA,mBAAU,GAAE;KAC3B,CAAC;IACF,IAAI,KAAK,CAAC,WAAW,EAAE,CAAC;QACpB,QAAQ,CAAC,SAAS,GAAG,KAAK,CAAC,WAAW,CAAC;IAC3C,CAAC;IACD,kEAAkE;IAClE,kEAAkE;IAClE,uEAAuE;IACvE,wEAAwE;IACxE,QAAQ,CAAC,SAAS,GAAG,CAAC,GAAW,EAAE;QAC/B,KAAK,MAAM,MAAM,IAAI,MAAM,CAAC,IAAI,CAAC,gBAAgB,CAAC,EAAE,CAAC;YACjD,IAAI,QAAQ,CAAC,UAAU,CAAC,MAAM,CAAC,EAAE,CAAC;gBAC9B,OAAO,gBAAgB,CAAC,MAAM,CAAC,CAAC;YACpC,CAAC;QACL,CAAC;QACD,OAAO,wBAAwB,CAAC;IACpC,CAAC,CAAC,EAAE,CAAC;IACL,MAAM,SAAS,GAAuB,IAAA,4BAAY,EAAC,UAAU,CAAC,CAAC;IAC/D,IAAI,SAAS,EAAE,CAAC;QACZ,QAAQ,CAAC,SAAS,GAAG,SAAS,CAAC;IACnC,CAAC;IACD,IAAI,MAAM,CAAC,SAAS,EAAE,GAAG,EAAE,CAAC;QACxB,QAAQ,CAAC,YAAY,GAAG,MAAM,CAAC,SAAS,CAAC,GAAG,CAAC;IACjD,CAAC;IACD,IAAI,MAAM,CAAC,SAAS,EAAE,MAAM,EAAE,CAAC;QAC3B,QAAQ,CAAC,eAAe,GAAG,MAAM,CAAC,SAAS,CAAC,MAAM,CAAC;IACvD,CAAC;IACD,YAAY,CAAC,SAAS,GAAG,QAAQ,CAAC;IAElC,MAAM,MAAM,GAA2B;QACnC,UAAU,EAAE,OAAO;QACnB,aAAa,EAAE,YAAY;KAC9B,CAAC;IACF,OAAO,CAAC,MAAM,CAAC,KAAK,CAAC,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,CAAC,CAAC;IAC7C,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;AACpB,CAAC"}

package/dist/clients/cursor/hooks/track-action-monitor.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"track-action-monitor.d.ts","sourceRoot":"","sources":["../../../../src/clients/cursor/hooks/track-action-monitor.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AA2BH,wBAAsB,GAAG,CAAC,UAAU,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC,CAwE3D"}
+{"version":3,"file":"track-action-monitor.d.ts","sourceRoot":"","sources":["../../../../src/clients/cursor/hooks/track-action-monitor.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AA4BH,wBAAsB,GAAG,CAAC,UAAU,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC,CA0E3D"}

package/dist/clients/cursor/hooks/track-action-monitor.js

@@ -37,6 +37,7 @@ const queue_1 = require("../../../queue");
 const util_1 = require("../util");
 const TOOL_NAME_PREFIX = "bdt_";
 const NODE_TOOL_NAME_PREFIX = "ndt_";
+const BACKEND_TOOL_NAME_PREFIX = "bedt_";
 async function run(projectDir) {
     let input;
     try {
@@ -62,7 +63,9 @@ async function run(projectDir) {
     const activityId = (0, session_state_1.getActiveActivityId)(sessionDir);
     const classified = (0, util_1.classifyTool)(rawToolName, input.tool_input);
     const isOurDevToolsTool = classified.tool_type === "mcp"
-        && (classified.tool_name.startsWith(TOOL_NAME_PREFIX) || classified.tool_name.startsWith(NODE_TOOL_NAME_PREFIX));
+        && (classified.tool_name.startsWith(TOOL_NAME_PREFIX)
+            || classified.tool_name.startsWith(NODE_TOOL_NAME_PREFIX)
+            || classified.tool_name.startsWith(BACKEND_TOOL_NAME_PREFIX));
     if (isOurDevToolsTool) {
         logger_1.logger.debug(`track-action-monitor: skipped devtools tool ${rawToolName}`);
         (0, output_1.writeAndExit)(JSON.stringify({}), 0);