@ironbee-ai/cli 0.9.6 → 0.10.1

package/dist/clients/claude/platforms/command-verify.node.md

@@ -4,7 +4,7 @@
 
 > **Precondition: the backend must actually be Node.js.** If you see `pom.xml`, `build.gradle`, `requirements.txt`, `pyproject.toml`, `go.mod`, `Cargo.toml`, etc., this section does NOT apply — `ndt_*` tools won't connect to non-Node processes. Just do browser verification.
 
-If the project has node backend verification enabled (`ironbee node enable` once at setup, by an operator who confirmed the backend is Node.js) and your edits touch matching paths (e.g. `server/**`, `pages/api/**`), the Stop hook also enforces a Node cycle. The same `verification-start` covers both cycles; the same verdict file carries fields for both.
+If the project has node backend verification enabled (`ironbee node enable` once at setup, by an operator who confirmed the backend is Node.js) and your edits touch matching paths (e.g. `server/**`, `pages/api/**`), the Stop hook also enforces a Node cycle. The same `verification-start` covers both cycles; one platform-agnostic verdict covers both.
 
 ### Mode behavior (node cycle)
 - **default** (no arg or `default`): probe / log only the code paths your diff touched. Map each changed file → the handler(s) it affects → place probes there.
@@ -16,26 +16,20 @@ If the project has node backend verification enabled (`ironbee node enable` once
 2. **Connect**: `mcp__node-devtools__ndt_debug_connect` with one of `pid` / `processName` / `containerId` / `containerName` / `inspectorPort` / `wsUrl`. Inspector is auto-activated via SIGUSR1 if needed.
 3. **Pick an evidence path** for each changed code path:
    - **Probe path** (proves the code path executed): `mcp__node-devtools__ndt_debug_put-tracepoint` (or `put-logpoint` / `put-exceptionpoint`) at the changed code, exercise the path (e.g. trigger the API call from the browser), then `mcp__node-devtools__ndt_debug_get-probe-snapshots`. At least one probe must come back with `triggered: true`.
-   - **Log path** (proves no errors): exercise the path, then `mcp__node-devtools__ndt_debug_get-logs` with the error level filter. `node_log_errors` must be empty for `status: pass`.
+   - **Log path** (proves no errors): exercise the path, then `mcp__node-devtools__ndt_debug_get-logs` with the error level filter.
 4. **Disconnect** (optional): `mcp__node-devtools__ndt_debug_disconnect`.
-5. **Submit verdict** including `node_*` fields. If browser cycle is also active, include browser fields in the SAME verdict — do not submit two verdicts.
+5. **Submit verdict** — platform-agnostic, just status + checks (+ issues/fixes).
 
-### Verdict (node-cycle fields)
+### Verdict (platform-agnostic)
 ```json
 {
   "session_id": "...",
   "status": "pass",
-  "checks": ["POST /api/orders returned 201", "tracepoint at handler.ts:42 fired once"],
-  "node_processes_connected": ["pid:12345 (next-server)"],
-  "node_probes_set": [
-    { "type": "tracepoint", "location": "src/api/orders.ts:42", "triggered": true }
-  ],
-  "node_probe_snapshots_collected": 1,
-  "node_log_errors": []
+  "checks": ["POST /api/orders returned 201", "tracepoint at handler.ts:42 fired once"]
 }
 ```
 
-For a multi-cycle pass, both browser and node criteria must hold — claiming `pass` without one cycle's evidence will be overridden to fail by the gate.
+For a multi-cycle pass, both browser and node pass criteria must hold.
 
 ---
 
@@ -54,7 +48,7 @@ Focus on the code you changed — not the entire Node service.
 - **Exercise the path end-to-end** (trigger from browser, curl, or the backend cycle if active)
 - **Each touched probe must report `triggered: true`** in `mcp__node-devtools__ndt_debug_get-probe-snapshots`
 - **Check one edge case per new branch** — invalid input, missing field, auth failure, …
-- **Logs** — `mcp__node-devtools__ndt_debug_get-logs` at error level; `node_log_errors` must be empty for `pass`
+- **Logs** — `mcp__node-devtools__ndt_debug_get-logs` at error level; no ERROR-level entries are expected for `pass`
 
 ---
 
@@ -64,4 +58,4 @@ Probe every Node code path reachable from files matching `node.verifyPatterns`,
 
 - Place probes at every handler / route / service entry point in scope, plus key internal branch points (early returns, error catches, conditional middleware)
 - Exercise each path with at least one happy-path call AND one failure-path call
-- `node_log_errors` must be empty after the full run — any unexpected log error is a fail, regardless of when it was introduced
+- No ERROR-level log entries are expected after the full run — any unexpected log error is a fail, regardless of when it was introduced

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

@@ -16,7 +16,7 @@ These attach to the **Required steps** above — they don't replace any step. Nu
   - **Protocol-call** — identify the affected endpoint(s) → call the matching protocol tool (`bedt_request_http` / `bedt_request_grpc` / `bedt_request_graphql` / `bedt_request_websocket-open` / `bedt_request_replay`) → inspect status / body / `traceId` → chain follow-up calls when verifying side effects. **A 4xx / 5xx response is a normal result, not an error** — only transport failures populate the `error` field.
   - **Log evidence** — `bedt_log_register-source` (file / docker / kubernetes) → `bedt_log_read` (point-in-time, supports `tail` / `since-until` / `pattern` / `level` / `parseJson` + `jsonFilter` / `contextBefore-After` / `select` / `coalesce`) OR `bedt_log_follow` + `bedt_log_get-followed` (streaming). Fit for jobs / queue workers / async handlers, or any case where an external driver is hitting the endpoint and you only need to verify what the server logged. `bedt_log_register-source` is mandatory on this path (the gate counts it as the setup step).
   - **DB evidence** — `bedt_db_connect` (named, `connectionStringEnv` preferred, default readonly) → ONE of `bedt_db_query` / `bedt_db_describe-table` / `bedt_db_list-tables` / `bedt_db_snapshot` (+ optional `bedt_db_diff`) / `bedt_db_get-changes`. Fit for migrations, seed-data changes, query-result regressions, and any code change whose side effect lives in a relational DB. `bedt_db_connect` is mandatory on this path (same anti-fluke rule as `log-evidence` — the connection name is on the wire).
-- **Within step 6 (submit verdict):** include `backend_endpoints_called` for protocol-call evidence (optionally with `backend_response_statuses` and `backend_traces_collected`), `backend_log_sources_read` for log-evidence, and/or `backend_db_connections_read` for db-evidence. **At least one** of those three arrays must be non-empty. One verdict carries fields for every active cycle.
+- **Within step 6 (submit verdict):** submit one platform-agnostic verdict (`status` + `checks` + optionally `issues` / `fixes`). The gate requires that at least one evidence path (protocol-call, log-evidence, or DB-evidence) was exercised in your `bedt_*` tool calls.
 
 ### Trace correlation (`o11y_*` is auxiliary, not evidence)
 
@@ -26,7 +26,7 @@ IronBee already injects the active verification `traceId` into every backend too
 
 - Calling `bedt_*` tools without first opening a verification cycle (`ironbee hook verification-start`).
 - Treating a 4xx / 5xx response as a transport failure when the test was specifically asking for that error condition (e.g. "POST should reject malformed body with 400"). Decide PASS/FAIL based on the test's intent, not the status code's HTTP-class default.
-- Submitting a backend verdict that omits ALL of `backend_endpoints_called`, `backend_log_sources_read`, and `backend_db_connections_read` — at least one of those evidence arrays must be non-empty.
+- Claiming `status: pass` for a backend cycle without exercising at least one evidence path (no `bedt_request_*` call, no `bedt_log_register-source` + read, no `bedt_db_connect` + read). The gate will reject.
 - Inferring backend behavior by reading code without exercising any evidence path. The cycle is satisfied only by making a real protocol call, reading real logs, or inspecting real DB state on the running service.
 - Reading a pre-existing log source / DB unrelated to your task to fake the log-evidence or db-evidence path. `bedt_log_register-source` and `bedt_db_connect` are required setup steps on those paths so the registration / connection is on the wire.
 - Opening a DB connection with `allowWrites: true` to "set up" verification data without an explicit need (seed / migration). Read-only is the default for a reason — flipping it widens the blast radius if a query goes wrong.

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

@@ -9,7 +9,7 @@
 Run the **Browser cycle** flow when an edited file activates it: 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 the steps above.
-- Pass verdict carries `pages_tested`, `checks`, `console_errors`, `network_failures`. `status: pass` requires `console_errors === 0` AND `network_failures === 0`.
+- The verdict you submit carries only semantic judgment (`status`, `checks`, optionally `issues` / `fixes`). The gate enforces that the required `bdt_*` tools were called and that `checks` is non-empty.
 
 ## Browser-cycle BANNED
 

package/dist/clients/claude/platforms/rule.node.md

@@ -6,7 +6,7 @@
 
 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.
+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 platform-agnostic verdict covers them all; one retry counter applies globally.
 
 ### ⚠️ `node-devtools` is ONLY for Node.js backends
 
@@ -19,11 +19,10 @@ Both cycles can be active simultaneously (e.g. you edit both a React component a
 These attach to the **Required steps** above — they don't replace any step. Numbering follows the main flow:
 
 - **Within step 3 (run flow):** also run the node flow: connect (`ndt_debug_connect`) → set probe (`ndt_debug_put-tracepoint` / `put-logpoint` / `put-exceptionpoint`) AND exercise + read snapshots (`ndt_debug_get-probe-snapshots`), OR exercise + read logs (`ndt_debug_get-logs`). When both browser and node cycles are active, run BOTH within the same verification cycle.
-- **Within step 6 (submit verdict):** include `node_*` fields (`node_processes_connected` non-empty, plus `node_probes_set` and/or `node_log_errors`). One verdict carries fields for every active cycle.
+- **Within step 6 (submit verdict):** submit one platform-agnostic verdict with `status` + `checks` (+ `issues`/`fixes` as needed). Node-cycle pass criteria: process connected, probe triggered (or log path used with no ERROR entries).
 
 ### Additional BANNED for node cycle
 
 - Calling `ndt_*` tools without first opening a verification cycle (`ironbee hook verification-start`).
 - **Calling `ndt_*` tools when the project's backend is NOT Node.js** (Java / Python / Go / Rust / .NET / Ruby / PHP / Elixir / etc.). Use the browser cycle only for non-Node backends.
-- Claiming `status: pass` for a node cycle when no probe triggered AND `node_log_errors` was never collected.
-- Submitting a node-only verdict that omits `node_processes_connected` — every node-cycle verdict requires this field non-empty.
+- Claiming `status: pass` for a node cycle when no probe triggered AND no log path was used — those criteria must hold.

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

@@ -65,62 +65,31 @@ The IronBee verification cycle already pins a W3C trace id on every backend tool
 
 ### Submit verdict
 
-Include the fields matching the path(s) you exercised. If browser and/or node cycles are also active, include their fields in the SAME verdict — do not submit two verdicts.
+The verdict is platform-agnostic — `status`, `checks`, and (when applicable) `issues` / `fixes`. The gate enforces that AT LEAST one backend evidence path was exercised in your `bedt_*` tool calls (protocol-call OR log-evidence OR DB-evidence) and that `checks` is non-empty.
 
 ```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"]
+  "checks": ["POST /api/orders returned 201 with order id", "GET /api/orders/:id reflects new order"]
 }
 ```
 
-Or, for a log-evidence path:
-
-```json
-{
-  "session_id": "<sid>",
-  "status": "pass",
-  "checks": ["api-server logged 'order 42 created' on POST /api/orders", "no ERROR-level lines after the change"],
-  "backend_log_sources_read": ["api-server"]
-}
-```
-
-Or, for a DB-evidence path:
-
-```json
-{
-  "session_id": "<sid>",
-  "status": "pass",
-  "checks": ["users table has new email_verified column with default false", "row count unchanged after migration"],
-  "backend_db_connections_read": ["app"]
-}
-```
-
-At least one of `backend_endpoints_called`, `backend_log_sources_read`, or `backend_db_connections_read` must be non-empty. The optional protocol-call fields (`backend_response_statuses`, `backend_traces_collected`) are strongly recommended when you used the protocol-call path — 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.
+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. The verdict shape doesn't change with the number of active cycles — same minimal verdict regardless:
 
 ```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"]
+  "checks": [
+    "checkout page renders",
+    "POST /api/orders returned 201",
+    "tracepoint at handler.ts:42 fired once",
+    "orders table reflects the new row"
+  ]
 }
 ```
 
-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`.
+For a multi-cycle pass, EVERY active cycle's pass criteria must hold.

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

@@ -14,18 +14,15 @@
 
 All four tools are MANDATORY (the Stop hook checks each). Functional interaction is expected for every verification.
 
-### Browser verdict fields
+### Verdict fields
+The verdict is platform-agnostic — you submit only semantic judgment:
+
 ```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
+  "checks": ["form submits successfully", "new item appears in list", "no console errors"]
 }
 ```
 
-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/platforms/skill.node.md

@@ -28,50 +28,35 @@ If you see `pom.xml`, `build.gradle`, `requirements.txt`, `pyproject.toml`, `go.
      - Read collected snapshots: `ndt_debug_get-probe-snapshots`. At least one probe must come back with `triggered: true`.
    - **Log path** (proves no errors during execution):
      - Exercise the path.
-     - Read errors: `ndt_debug_get-logs` with the error-level filter. `node_log_errors` must be empty for `status: pass`.
+     - Read errors: `ndt_debug_get-logs` with the error-level filter.
 4. **Disconnect** (optional): `ndt_debug_disconnect`.
 
-### Node verdict fields
+### Verdict fields
+The verdict is platform-agnostic — you submit only semantic judgment:
+
 ```json
 {
   "session_id": "<sid>",
   "status": "pass",
-  "checks": ["POST /api/orders returned 201", "tracepoint at handler.ts:42 fired once"],
-  "node_processes_connected": ["pid:12345 (next-server)"],
-  "node_probes_set": [
-    { "type": "tracepoint", "location": "src/api/orders.ts:42", "triggered": true }
-  ],
-  "node_probe_snapshots_collected": 1,
-  "node_log_errors": []
+  "checks": ["POST /api/orders returned 201", "tracepoint at handler.ts:42 fired once"]
 }
 ```
 
-For `status: "pass"` (node cycle):
-- If probes were set, at least one must have `triggered: true` (proves the code path executed).
-- If only logs were used, `node_log_errors.length === 0` (no errors observed).
+Node-cycle pass criteria:
+- If probes were set, at least one must have triggered (proves the code path executed).
+- If only logs were used, no ERROR-level entries.
 - If both forms were used, both conditions must hold.
 
 ## Multi-cycle (browser + node simultaneously)
 
-Common case: in the same task you edit a `.tsx` component (browser-cycle) and a `server/api/*.ts` handler (node-cycle). Both cycles activate. **Single** `verification-start`, **single** `verdict.json`, **single** retry counter cover both.
-
-Submit ONE verdict carrying fields for every active cycle:
+Common case: in the same task you edit a `.tsx` component (browser-cycle) and a `server/api/*.ts` handler (node-cycle). Both cycles activate. **Single** `verification-start`, **single** `verdict.json`, **single** retry counter cover both. The verdict shape doesn't change — one verdict regardless of how many cycles ran:
 
 ```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,
-  "node_processes_connected": ["pid:12345 (next-server)"],
-  "node_probes_set": [
-    { "type": "tracepoint", "location": "src/api/orders.ts:42", "triggered": true }
-  ],
-  "node_probe_snapshots_collected": 1,
-  "node_log_errors": []
+  "checks": ["checkout submits", "POST /api/orders returned 201", "no console errors"]
 }
 ```
 
-For a multi-cycle `pass`, BOTH cycles' pass criteria must hold. Claiming `pass` without one cycle's evidence will be overridden to `fail` by the gate.
+For a multi-cycle `pass`, BOTH cycles' pass criteria must hold.

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

@@ -18,13 +18,12 @@ 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 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.
+4. Stop the dev server when done — every cycle, including the final one.
 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.
+   - Platform-agnostic shape: `status`, `checks` (always required); add `issues` on fail; add `fixes` on pass-after-fail. One verdict regardless of how many cycles ran.
 
-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 for every active cycle and that the verdict carries non-empty `checks`. 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.
 

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

@@ -44,16 +44,18 @@ If already running, skip start. If the build fails, fix it before proceeding.
    ```
    Devtools tools are blocked without this.
 3. Build and start the application if not already running.
-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.
+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 and mandatory tools. All active cycles must be exercised within this one verification cycle.
+5. Stop the dev server when verification is complete (every cycle — including the final one).
 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
    ```
-   - Pass → submit pass verdict (with fields for every active cycle)
-   - Fail → submit fail verdict with `issues`
-   - **The Stop hook overrides `status: pass` to fail when evidence doesn't back it.**
+   - Verdict shape is platform-agnostic: `status`, `checks`, optionally `issues` / `fixes`. One verdict regardless of how many cycles ran.
+   - Pass → `{ "session_id": "...", "status": "pass", "checks": [...] }`
+   - Fail → add `"issues": [...]` describing what failed.
+   - Pass after a previous fail → add `"fixes": [...]` describing what was repaired.
+   - **The Stop hook enforces that you called the required tools for every active cycle and that the verdict carries non-empty `checks`.**
 8. If failed → fix → rebuild → go back to step 2 → repeat until pass.
 
 <!--IRONBEE:PLATFORM:browser-->
@@ -67,7 +69,7 @@ If already running, skip start. If the build fails, fix it before proceeding.
 
 ## Important
 - **Always submit a verdict after every verification attempt** — both pass AND fail. Fail verdicts are tracked for analytics.
-- The Stop hook checks tool usage AND verdict validity for every active cycle. Pass criteria are enforced separately per cycle, then AND-combined.
+- The Stop hook checks that the required tools were used for every active cycle and that the verdict carries non-empty `checks`.
 - Submit verdicts via `ironbee hook submit-verdict`, never write `verdict.json` directly.
 - Every code edit (Write/Edit) automatically clears your session's verdict.
 - After 3 failed verification attempts, you may complete but must report unresolved issues.

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

@@ -6,18 +6,18 @@ disable-model-invocation: true
 
 # IronBee Verify
 
-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.
+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 and flow — **see the platform sections near the bottom of this file** for which cycles apply and what to call. The verdict shape itself is platform-agnostic (`status`, `checks`, `issues?`, `fixes?`); the gate enforces that you called each cycle's required tools and that `checks` is non-empty.
 
 ## Universal steps
 
 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.
+4. **Stop** the dev server when verification is complete (every cycle — including the final one).
 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`
+6. **Submit your verdict** via terminal. One verdict covers every active cycle:
+    - Pass: `echo '{"session_id":"...","status":"pass","checks":["..."]}' | ironbee hook submit-verdict`
+    - Fail: `echo '{"session_id":"...","status":"fail","checks":["..."],"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.
 

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

@@ -44,8 +44,8 @@ async function run(projectDir) {
             permission: "deny",
             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_*, 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
+Submit your verdict first:
+  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/session-start.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"session-start.d.ts","sourceRoot":"","sources":["../../../../src/clients/cursor/hooks/session-start.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAuBH,wBAAsB,GAAG,CAAC,UAAU,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC,CAyE3D"}
+{"version":3,"file":"session-start.d.ts","sourceRoot":"","sources":["../../../../src/clients/cursor/hooks/session-start.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAuBH,wBAAsB,GAAG,CAAC,UAAU,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC,CAmE3D"}

package/dist/clients/cursor/hooks/session-start.js

@@ -47,18 +47,12 @@ async function run(projectDir) {
     const verdictPass = JSON.stringify({
         session_id: sessionId,
         status: "pass",
-        pages_tested: ["http://localhost:3000/affected-page"],
         checks: ["form submits successfully", "new item appears in list"],
-        console_errors: 0,
-        network_failures: 0,
     });
     const verdictFail = JSON.stringify({
         session_id: sessionId,
         status: "fail",
-        pages_tested: ["http://localhost:3000/affected-page"],
         checks: ["form renders", "submit button unresponsive"],
-        console_errors: 2,
-        network_failures: 0,
         issues: ["button click handler not firing", "TypeError in console"],
     });
     const context = `IRONBEE VERIFICATION — SESSION ACTIVE
@@ -75,7 +69,7 @@ Submit via terminal:
 On fail (issues is required):
   echo '${verdictFail}' | ironbee hook submit-verdict
 
-Required fields: session_id, status, pages_tested, checks, console_errors, network_failures
+Required fields: session_id, status, checks
 On fail, include: issues (array of strings describing what failed)
 On pass after a previous fail, include: fixes (array of strings describing what was fixed)`;
     const output = {

package/dist/clients/cursor/hooks/session-start.js.map

@@ -1 +1 @@
-{"version":3,"file":"session-start.js","sourceRoot":"","sources":["../../../../src/clients/cursor/hooks/session-start.ts"],"names":[],"mappings":";AAAA;;;;;;GAMG;;AAuBH,kBAyEC;AA9FD,yDAA2F;AAC3F,qEAAwF;AACxF,gDAAyE;AACzE,gDAAyD;AACzD,gDAAmD;AACnD,8CAA+C;AAC/C,sDAA2D;AAepD,KAAK,UAAU,GAAG,CAAC,UAAkB;IACxC,IAAI,KAA8B,CAAC;IACnC,IAAI,CAAC;QACD,KAAK,GAAG,IAAI,CAAC,KAAK,CAAC,IAAA,iBAAS,GAAE,CAA4B,CAAC;IAC/D,CAAC;IAAC,OAAO,CAAU,EAAE,CAAC;QAClB,eAAM,CAAC,KAAK,CAAC,0BAA0B,CAAC,EAAE,CAAC,CAAC;QAC5C,IAAA,qBAAY,EAAC,IAAI,CAAC,SAAS,CAAC,EAAE,CAAC,EAAE,CAAC,CAAC,CAAC;QACpC,OAAO;IACX,CAAC;IAED,MAAM,SAAS,GAAW,KAAK,CAAC,eAAe,IAAI,SAAS,CAAC;IAC7D,MAAM,WAAW,GAAW,GAAG,UAAU,sBAAsB,SAAS,gBAAgB,CAAC;IACzF,IAAA,mBAAU,EAAC,GAAG,UAAU,sBAAsB,SAAS,cAAc,CAAC,CAAC;IAEvE,MAAM,UAAU,GAAW,GAAG,UAAU,sBAAsB,SAAS,EAAE,CAAC;IAC1E,wEAAwE;IACxE,wEAAwE;IACxE,IAAA,4BAAY,EAAC,UAAU,EAAE,KAAK,CAAC,UAAU,IAAI,SAAS,CAAC,CAAC;IAExD,MAAM,KAAK,GAAuB;QAC9B,GAAG,IAAA,oBAAU,EAAC,WAAW,CAAC;QAC1B,IAAI,EAAE,eAAe;QACrB,SAAS,EAAE,IAAI,CAAC,GAAG,EAAE;QACrB,UAAU,EAAE,SAAS;QACrB,MAAM,EAAE,QAAQ;QAChB,MAAM,EAAE,SAAS;KACpB,CAAC;IAEF,MAAM,IAAA,sBAAY,EAAC,WAAW,EAAE,KAAK,CAAC,CAAC;IACvC,MAAM,IAAA,qCAAqB,EAAC,UAAU,EAAE,WAAW,EAAE,sBAAY,CAAC,CAAC;IACnE,MAAM,IAAA,6BAAiB,EAAC,QAAQ,EAAE,SAAS,EAAE,IAAA,+BAAsB,EAAC,IAAA,mBAAU,EAAC,UAAU,CAAC,CAAC,CAAC,CAAC;IAC7F,eAAM,CAAC,KAAK,CAAC,kBAAkB,SAAS,EAAE,CAAC,CAAC;IAE5C,MAAM,WAAW,GAAW,IAAI,CAAC,SAAS,CAAC;QACvC,UAAU,EAAE,SAAS;QACrB,MAAM,EAAE,MAAM;QACd,YAAY,EAAE,CAAC,qCAAqC,CAAC;QACrD,MAAM,EAAE,CAAC,2BAA2B,EAAE,0BAA0B,CAAC;QACjE,cAAc,EAAE,CAAC;QACjB,gBAAgB,EAAE,CAAC;KACtB,CAAC,CAAC;IACH,MAAM,WAAW,GAAW,IAAI,CAAC,SAAS,CAAC;QACvC,UAAU,EAAE,SAAS;QACrB,MAAM,EAAE,MAAM;QACd,YAAY,EAAE,CAAC,qCAAqC,CAAC;QACrD,MAAM,EAAE,CAAC,cAAc,EAAE,4BAA4B,CAAC;QACtD,cAAc,EAAE,CAAC;QACjB,gBAAgB,EAAE,CAAC;QACnB,MAAM,EAAE,CAAC,iCAAiC,EAAE,sBAAsB,CAAC;KACtE,CAAC,CAAC;IAEH,MAAM,OAAO,GAAW;cACd,SAAS;;;;;;;;UAQb,WAAW;;;UAGX,WAAW;;;;2FAIsE,CAAC;IAExF,MAAM,MAAM,GAA6B;QACrC,kBAAkB,EAAE,OAAO;KAC9B,CAAC;IACF,IAAA,qBAAY,EAAC,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,EAAE,CAAC,CAAC,CAAC;AAC5C,CAAC"}
+{"version":3,"file":"session-start.js","sourceRoot":"","sources":["../../../../src/clients/cursor/hooks/session-start.ts"],"names":[],"mappings":";AAAA;;;;;;GAMG;;AAuBH,kBAmEC;AAxFD,yDAA2F;AAC3F,qEAAwF;AACxF,gDAAyE;AACzE,gDAAyD;AACzD,gDAAmD;AACnD,8CAA+C;AAC/C,sDAA2D;AAepD,KAAK,UAAU,GAAG,CAAC,UAAkB;IACxC,IAAI,KAA8B,CAAC;IACnC,IAAI,CAAC;QACD,KAAK,GAAG,IAAI,CAAC,KAAK,CAAC,IAAA,iBAAS,GAAE,CAA4B,CAAC;IAC/D,CAAC;IAAC,OAAO,CAAU,EAAE,CAAC;QAClB,eAAM,CAAC,KAAK,CAAC,0BAA0B,CAAC,EAAE,CAAC,CAAC;QAC5C,IAAA,qBAAY,EAAC,IAAI,CAAC,SAAS,CAAC,EAAE,CAAC,EAAE,CAAC,CAAC,CAAC;QACpC,OAAO;IACX,CAAC;IAED,MAAM,SAAS,GAAW,KAAK,CAAC,eAAe,IAAI,SAAS,CAAC;IAC7D,MAAM,WAAW,GAAW,GAAG,UAAU,sBAAsB,SAAS,gBAAgB,CAAC;IACzF,IAAA,mBAAU,EAAC,GAAG,UAAU,sBAAsB,SAAS,cAAc,CAAC,CAAC;IAEvE,MAAM,UAAU,GAAW,GAAG,UAAU,sBAAsB,SAAS,EAAE,CAAC;IAC1E,wEAAwE;IACxE,wEAAwE;IACxE,IAAA,4BAAY,EAAC,UAAU,EAAE,KAAK,CAAC,UAAU,IAAI,SAAS,CAAC,CAAC;IAExD,MAAM,KAAK,GAAuB;QAC9B,GAAG,IAAA,oBAAU,EAAC,WAAW,CAAC;QAC1B,IAAI,EAAE,eAAe;QACrB,SAAS,EAAE,IAAI,CAAC,GAAG,EAAE;QACrB,UAAU,EAAE,SAAS;QACrB,MAAM,EAAE,QAAQ;QAChB,MAAM,EAAE,SAAS;KACpB,CAAC;IAEF,MAAM,IAAA,sBAAY,EAAC,WAAW,EAAE,KAAK,CAAC,CAAC;IACvC,MAAM,IAAA,qCAAqB,EAAC,UAAU,EAAE,WAAW,EAAE,sBAAY,CAAC,CAAC;IACnE,MAAM,IAAA,6BAAiB,EAAC,QAAQ,EAAE,SAAS,EAAE,IAAA,+BAAsB,EAAC,IAAA,mBAAU,EAAC,UAAU,CAAC,CAAC,CAAC,CAAC;IAC7F,eAAM,CAAC,KAAK,CAAC,kBAAkB,SAAS,EAAE,CAAC,CAAC;IAE5C,MAAM,WAAW,GAAW,IAAI,CAAC,SAAS,CAAC;QACvC,UAAU,EAAE,SAAS;QACrB,MAAM,EAAE,MAAM;QACd,MAAM,EAAE,CAAC,2BAA2B,EAAE,0BAA0B,CAAC;KACpE,CAAC,CAAC;IACH,MAAM,WAAW,GAAW,IAAI,CAAC,SAAS,CAAC;QACvC,UAAU,EAAE,SAAS;QACrB,MAAM,EAAE,MAAM;QACd,MAAM,EAAE,CAAC,cAAc,EAAE,4BAA4B,CAAC;QACtD,MAAM,EAAE,CAAC,iCAAiC,EAAE,sBAAsB,CAAC;KACtE,CAAC,CAAC;IAEH,MAAM,OAAO,GAAW;cACd,SAAS;;;;;;;;UAQb,WAAW;;;UAGX,WAAW;;;;2FAIsE,CAAC;IAExF,MAAM,MAAM,GAA6B;QACrC,kBAAkB,EAAE,OAAO;KAC9B,CAAC;IACF,IAAA,qBAAY,EAAC,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,EAAE,CAAC,CAAC,CAAC;AAC5C,CAAC"}

package/dist/clients/cursor/platforms/command-verify.backend.md

@@ -2,7 +2,7 @@
 
 ## Backend Mode (when `backend.verifyPatterns` matches an edited file)
 
-If the project has the backend protocol cycle enabled (`ironbee backend enable` once at setup) and your edits touch matching paths (e.g. `server/**`, `api/**`, `routes/**`, `controllers/**`), the Stop hook also enforces a Backend cycle. The same `verification-start` covers every active cycle; the same verdict file carries fields for all of them.
+If the project has the backend protocol cycle enabled (`ironbee backend enable` once at setup) and your edits touch matching paths (e.g. `server/**`, `api/**`, `routes/**`, `controllers/**`), the Stop hook also enforces a Backend cycle. The same `verification-start` covers every active cycle; one platform-agnostic verdict covers them all.
 
 This cycle is **runtime- and language-agnostic** — it works for Node, Java, Python, Go, Rust, Ruby, .NET, PHP, Elixir, Kotlin, Scala. The agent makes real protocol calls (HTTP / gRPC / GraphQL / WebSocket) against the running service, inspects logs, OR reads database state; it never attaches to a process.
 
@@ -45,46 +45,21 @@ The cycle is satisfied by ANY ONE of three evidence paths: protocol-call (you dr
 5. **Trace correlation (optional, `o11y_*` primitives):** IronBee already pins the verification cycle's traceId on every backend tool call via `_metadata.traceId` (outranks any session pin), so the orchestrator's correlation root is authoritative. Use `MCP:bedt_o11y_get-trace-context` to read it, then pass it to `MCP:bedt_log_read { pattern: "<traceId>" }` to slice logs for one flow. `MCP:bedt_o11y_new-trace-id` / `MCP:bedt_o11y_set-trace-context` are available when you want to anchor a flow under an explicit id (e.g. integration-test runs).
 6. **Submit verdict** including the fields matching the path(s) you exercised. If browser and/or node cycles are also active, include their fields in the SAME verdict — do not submit two verdicts.
 
-### Verdict (backend-cycle fields)
+### Verdict (platform-agnostic)
 
-Protocol-call path:
-```json
-{
-  "session_id": "...",
-  "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"]
-}
-```
-
-Log-evidence path:
-```json
-{
-  "session_id": "...",
-  "status": "pass",
-  "checks": ["api-server logged 'order 42 created' on POST /api/orders", "no ERROR-level lines after the change"],
-  "backend_log_sources_read": ["api-server"]
-}
-```
+The verdict shape is the same regardless of which evidence path (protocol-call / log / db) you took — `status` + `checks` (+ `issues` / `fixes` as needed):
 
-DB-evidence path:
 ```json
 {
   "session_id": "...",
   "status": "pass",
-  "checks": ["users table has new email_verified column with default false", "row count unchanged after migration"],
-  "backend_db_connections_read": ["app"]
+  "checks": ["POST /api/orders returned 201 with order id", "GET /api/orders/:id reflects new order"]
 }
 ```
 
-At least one of `backend_endpoints_called`, `backend_log_sources_read`, or `backend_db_connections_read` must be non-empty. `backend_response_statuses` and `backend_traces_collected` are optional but strongly recommended on the protocol-call path — same order as `backend_endpoints_called`. There is no automatic pass-criteria override on this cycle: if `status: pass` and the evidence is structurally valid, the gate honors it.
+The gate requires that AT LEAST one evidence path was actually exercised in your tool calls — `MCP:bedt_request_*` for protocol-call, `MCP:bedt_log_register-source` + `MCP:bedt_log_read*` / `_follow` for log-evidence, or `MCP:bedt_db_connect` + a read/diff/snapshot/get-changes for DB-evidence. If none were used, the gate will reject.
 
-For a multi-cycle pass (browser + backend, or browser + node + backend), every active cycle's evidence must be present — claiming `pass` without one cycle's fields will be overridden to fail.
+For a multi-cycle pass (browser + backend, or browser + node + backend), every active cycle's pass criteria must hold.
 
 ---
 

package/dist/clients/cursor/platforms/command-verify.browser.md

@@ -38,8 +38,8 @@ If no argument is given, use **default** mode. `default` and `full` apply to eve
 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`
+    - Pass: `echo '{"session_id":"...","status":"pass","checks":["..."]}' | ironbee hook submit-verdict`
+    - Fail: `echo '{"session_id":"...","status":"fail","checks":["..."],"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
 

package/dist/clients/cursor/platforms/command-verify.node.md

@@ -4,7 +4,7 @@
 
 > **Precondition: the backend must actually be Node.js.** If you see `pom.xml`, `build.gradle`, `requirements.txt`, `pyproject.toml`, `go.mod`, `Cargo.toml`, etc., this section does NOT apply — `MCP:ndt_*` tools won't connect to non-Node processes. Just do browser verification.
 
-If the project has node backend verification enabled (`ironbee node enable` once at setup, by an operator who confirmed the backend is Node.js) and your edits touch matching paths (e.g. `server/**`, `pages/api/**`), the stop hook also enforces a Node cycle. The same `verification-start` covers both cycles; the same verdict file carries fields for both.
+If the project has node backend verification enabled (`ironbee node enable` once at setup, by an operator who confirmed the backend is Node.js) and your edits touch matching paths (e.g. `server/**`, `pages/api/**`), the stop hook also enforces a Node cycle. The same `verification-start` covers both cycles; one platform-agnostic verdict covers both.
 
 ### Mode behavior (node cycle)
 - **default** (no arg or `default`): probe / log only the code paths your diff touched. Map each changed file → the handler(s) it affects → place probes there.
@@ -16,26 +16,20 @@ If the project has node backend verification enabled (`ironbee node enable` once
 2. **Connect**: `MCP:ndt_debug_connect` with one of `pid` / `processName` / `containerId` / `containerName` / `inspectorPort` / `wsUrl`. Inspector is auto-activated via SIGUSR1 if needed.
 3. **Pick an evidence path** for each changed code path:
    - **Probe path** (proves the code path executed): `MCP:ndt_debug_put-tracepoint` (or `put-logpoint` / `put-exceptionpoint`) at the changed code, exercise the path (e.g. trigger the API call from the browser), then `MCP:ndt_debug_get-probe-snapshots`. At least one probe must come back with `triggered: true`.
-   - **Log path** (proves no errors): exercise the path, then `MCP:ndt_debug_get-logs` with the error level filter. `node_log_errors` must be empty for `status: pass`.
+   - **Log path** (proves no errors): exercise the path, then `MCP:ndt_debug_get-logs` with the error level filter.
 4. **Disconnect** (optional): `MCP:ndt_debug_disconnect`.
-5. **Submit verdict** including `node_*` fields. If browser cycle is also active, include browser fields in the SAME verdict — do not submit two verdicts.
+5. **Submit verdict** — platform-agnostic, just status + checks (+ issues/fixes).
 
-### Verdict (node-cycle fields)
+### Verdict (platform-agnostic)
 ```json
 {
   "session_id": "...",
   "status": "pass",
-  "checks": ["POST /api/orders returned 201", "tracepoint at handler.ts:42 fired once"],
-  "node_processes_connected": ["pid:12345 (next-server)"],
-  "node_probes_set": [
-    { "type": "tracepoint", "location": "src/api/orders.ts:42", "triggered": true }
-  ],
-  "node_probe_snapshots_collected": 1,
-  "node_log_errors": []
+  "checks": ["POST /api/orders returned 201", "tracepoint at handler.ts:42 fired once"]
 }
 ```
 
-For a multi-cycle pass, both browser and node criteria must hold — claiming `pass` without one cycle's evidence will be overridden to fail by the gate.
+For a multi-cycle pass, both browser and node pass criteria must hold.
 
 ---
 
@@ -54,7 +48,7 @@ Focus on the code you changed — not the entire Node service.
 - **Exercise the path end-to-end** (trigger from browser, curl, or the backend cycle if active)
 - **Each touched probe must report `triggered: true`** in `MCP:ndt_debug_get-probe-snapshots`
 - **Check one edge case per new branch** — invalid input, missing field, auth failure, …
-- **Logs** — `MCP:ndt_debug_get-logs` at error level; `node_log_errors` must be empty for `pass`
+- **Logs** — `MCP:ndt_debug_get-logs` at error level; no ERROR-level entries are expected for `pass`
 
 ---
 
@@ -64,4 +58,4 @@ Probe every Node code path reachable from files matching `node.verifyPatterns`,
 
 - Place probes at every handler / route / service entry point in scope, plus key internal branch points (early returns, error catches, conditional middleware)
 - Exercise each path with at least one happy-path call AND one failure-path call
-- `node_log_errors` must be empty after the full run — any unexpected log error is a fail, regardless of when it was introduced
+- No ERROR-level log entries are expected after the full run — any unexpected log error is a fail, regardless of when it was introduced

package/dist/clients/cursor/platforms/rule.backend.md

@@ -16,7 +16,7 @@ These attach to the **Required steps** above — they don't replace any step. Nu
   - **Protocol-call** — identify the affected endpoint(s) → call the matching protocol tool (`bedt_request_http` / `bedt_request_grpc` / `bedt_request_graphql` / `bedt_request_websocket-open` / `bedt_request_replay`) → inspect status / body / `traceId` → chain follow-up calls when verifying side effects. **A 4xx / 5xx response is a normal result, not an error** — only transport failures populate the `error` field.
   - **Log evidence** — `bedt_log_register-source` (file / docker / kubernetes) → `bedt_log_read` (point-in-time, supports `tail` / `since-until` / `pattern` / `level` / `parseJson` + `jsonFilter` / `contextBefore-After` / `select` / `coalesce`) OR `bedt_log_follow` + `bedt_log_get-followed` (streaming). Fit for jobs / queue workers / async handlers, or any case where an external driver is hitting the endpoint and you only need to verify what the server logged. `bedt_log_register-source` is mandatory on this path (the gate counts it as the setup step).
   - **DB evidence** — `bedt_db_connect` (named, `connectionStringEnv` preferred, default readonly) → ONE of `bedt_db_query` / `bedt_db_describe-table` / `bedt_db_list-tables` / `bedt_db_snapshot` (+ optional `bedt_db_diff`) / `bedt_db_get-changes`. Fit for migrations, seed-data changes, query-result regressions, and any code change whose side effect lives in a relational DB. `bedt_db_connect` is mandatory on this path (same anti-fluke rule as `log-evidence` — the connection name is on the wire).
-- **Within step 6 (submit verdict):** include `backend_endpoints_called` for protocol-call evidence (optionally with `backend_response_statuses` and `backend_traces_collected`), `backend_log_sources_read` for log-evidence, and/or `backend_db_connections_read` for db-evidence. **At least one** of those three arrays must be non-empty. One verdict carries fields for every active cycle.
+- **Within step 6 (submit verdict):** submit one platform-agnostic verdict (`status` + `checks` + optionally `issues` / `fixes`). The gate requires that at least one evidence path (protocol-call, log-evidence, or DB-evidence) was exercised in your `MCP:bedt_*` tool calls.
 
 ### Trace correlation (`o11y_*` is auxiliary, not evidence)
 
@@ -26,7 +26,7 @@ IronBee already injects the active verification `traceId` into every backend too
 
 - Calling `bedt_*` tools without first opening a verification cycle (`ironbee hook verification-start`).
 - Treating a 4xx / 5xx response as a transport failure when the test was specifically asking for that error condition (e.g. "POST should reject malformed body with 400"). Decide PASS/FAIL based on the test's intent, not the status code's HTTP-class default.
-- Submitting a backend verdict that omits ALL of `backend_endpoints_called`, `backend_log_sources_read`, and `backend_db_connections_read` — at least one of those evidence arrays must be non-empty.
+- Claiming `status: pass` for a backend cycle without exercising at least one evidence path (no `MCP:bedt_request_*` call, no `MCP:bedt_log_register-source` + read, no `MCP:bedt_db_connect` + read). The gate will reject.
 - Inferring backend behavior by reading code without exercising any evidence path. The cycle is satisfied only by making a real protocol call, reading real logs, or inspecting real DB state on the running service.
 - Reading a pre-existing log source / DB unrelated to your task to fake the log-evidence or db-evidence path. `bedt_log_register-source` and `bedt_db_connect` are required setup steps on those paths so the registration / connection is on the wire.
 - Opening a DB connection with `allowWrites: true` to "set up" verification data without an explicit need (seed / migration). Read-only is the default for a reason — flipping it widens the blast radius if a query goes wrong.

package/dist/clients/cursor/platforms/rule.browser.md

@@ -9,7 +9,7 @@
 Run the **Browser cycle** flow when an edited file activates it: navigate (`MCP:bdt_navigation_go-to`) → functionally test → screenshot (`MCP:bdt_content_take-screenshot`) → accessibility (`MCP:bdt_a11y_take-aria-snapshot`) → console (`MCP:bdt_o11y_get-console-messages`). All four are MANDATORY.
 
 - If `recording.enable` is on, the gate forces `MCP:bdt_content_start-recording` BEFORE the steps above and rejects the verdict if you don't call `MCP:bdt_content_stop-recording` AFTER them. Always pair start/stop around the steps above.
-- Pass verdict carries `pages_tested`, `checks`, `console_errors`, `network_failures`. `status: pass` requires `console_errors === 0` AND `network_failures === 0`.
+- The verdict you submit carries only semantic judgment (`status`, `checks`, optionally `issues` / `fixes`). The gate enforces that the required `MCP:bdt_*` tools were called and that `checks` is non-empty.
 
 ## Browser-cycle BANNED