@ironbee-ai/cli 0.8.3 → 0.9.0

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

@@ -0,0 +1,67 @@
+<!-- Node backend verification is ENABLED for this project. -->
+
+## Backend Node Mode (when `node.verifyPatterns` matches an edited file)
+
+> **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.
+
+### 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.
+- **full**: probe / log every Node code path reachable from files matching `node.verifyPatterns`, not just the changed files. Expect a much larger probe set and longer runtime.
+- `visual` / `functional`: browser-only modes; this cycle behaves as `default` when they are passed.
+
+### Steps (additive to the browser flow above)
+1. **Identify the running Node process** — note its PID, container name (`docker compose ps`), or inspector port.
+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. `backend_node_log_errors` must be empty for `status: pass`.
+4. **Disconnect** (optional): `MCP:ndt_debug_disconnect`.
+5. **Submit verdict** including `backend_node_*` fields. If browser cycle is also active, include browser fields in the SAME verdict — do not submit two verdicts.
+
+### Verdict (node-cycle fields)
+```json
+{
+  "session_id": "...",
+  "status": "pass",
+  "checks": ["POST /api/orders returned 201", "tracepoint at handler.ts:42 fired once"],
+  "backend_node_processes_connected": ["pid:12345 (next-server)"],
+  "backend_node_probes_set": [
+    { "type": "tracepoint", "location": "src/api/orders.ts:42", "triggered": true }
+  ],
+  "backend_node_probe_snapshots_collected": 1,
+  "backend_node_log_errors": []
+}
+```
+
+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.
+
+---
+
+## Default Mode (node cycle)
+
+Focus on the code you changed — not the entire Node service.
+
+### 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** for every Node file in scope (handler / route / service / middleware) — note new branches, new validations, new error paths, new external calls, changed return values
+4. Before connecting, you should be able to answer: which function(s) execute on the changed path? Where does a tracepoint prove the new code fired? What error logs would prove a regression?
+
+### 2. Verify against the running process
+- **Place a probe at each changed code site** — `MCP:ndt_debug_put-tracepoint` for "did it run", `MCP:ndt_debug_put-logpoint` for variable capture, `MCP:ndt_debug_put-exceptionpoint` for new throw branches
+- **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; `backend_node_log_errors` must be empty for `pass`
+
+---
+
+## Full Mode (`/ironbee-verify full`, node cycle)
+
+Probe every Node code path reachable from files matching `node.verifyPatterns`, not just the changed files. Do NOT run `git diff` or scope to recent changes.
+
+- 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
+- `backend_node_log_errors` must be empty 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

@@ -0,0 +1,23 @@
+<!-- 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`. -->
+
+## Backend cycle (runtime-agnostic protocol verification)
+
+When the file matches `backend.verifyPatterns`, the Stop hook ALSO requires verification through the **backend-devtools** MCP server (prefix `bedt_`). Backend-cycle verification means making a real protocol call (HTTP / gRPC / GraphQL / WebSocket) against the running service and inspecting the response — language- and framework-independent.
+
+The backend cycle and the node cycle are **independent**. Node attaches to a Node.js V8 inspector with non-blocking probes (`ndt_*`); backend drives wire protocols from outside (`bedt_*`). They can be active in the same task; both must be satisfied for `status: pass`.
+
+### Backend-cycle additions to the main flow
+
+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 backend flow: 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.
+- **Within step 6 (submit verdict):** include `backend_endpoints_called` (the only required backend field), and optionally `backend_response_statuses` and `backend_traces_collected`. One verdict carries fields for every active cycle.
+
+### Additional BANNED for backend cycle
+
+- 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-only verdict that omits `backend_endpoints_called` — any non-empty list of endpoints driven during verification is required.
+- Inferring backend behavior by reading code without making a real protocol call. The cycle is satisfied only by actually exercising the wire protocol.

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

@@ -0,0 +1,17 @@
+<!-- Browser cycle verification is ENABLED for this project. The stop hook
+     enforces a browser cycle whenever an edited file matches
+     `browser.verifyPatterns`. -->
+
+**Browser cycle** — frontend file changes (default: most code extensions). Tools come from the **browser-devtools** MCP server (prefix `MCP:bdt_*`). Verification means navigating to the affected page and FUNCTIONALLY exercising the change in the browser — clicking, typing, submitting — not just looking at it.
+
+## Browser flow steps
+
+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`.
+
+## Browser-cycle BANNED
+
+- Calling `MCP:bdt_*` tools without first opening a verification cycle (`ironbee hook verification-start`).
+- **Submitting a verdict while a browser recording is still active** — always call `MCP:bdt_content_stop-recording` BEFORE `ironbee hook submit-verdict`. The recording start/stop pair brackets the verification flow.

package/dist/clients/cursor/{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 `MCP: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 `MCP: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 `MCP: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 `MCP: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 `MCP: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/cursor/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:bedt_request_http` — full method/headers/body/query/follow-redirects support; ALPN auto-negotiates H2 on TLS, falls back to H1.1.
+   - **gRPC**: `MCP:bedt_request_grpc` — unary + 3 streaming modes; pass `.proto` text or descriptor.
+   - **GraphQL**: `MCP:bedt_request_graphql` — query/mutation, variables, persisted query support.
+   - **WebSocket** (stateful — open/send/receive/close cycle):
+     - `MCP:bedt_request_websocket-open` — establish session.
+     - `MCP:bedt_request_websocket-send` / `bedt_request_websocket-receive` — exchange frames.
+     - `MCP:bedt_request_websocket-close` — clean teardown (and `bedt_request_websocket-list` for running sessions).
+   - **Replay**: `MCP: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/cursor/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:bdt_content_start-recording`, and `submit-verdict` rejects with `"recording is still active"` unless you call `MCP: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: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:bdt_content_take-screenshot` — capture the final visual state
+4. **Accessibility**: `MCP:bdt_a11y_take-aria-snapshot` — verify page structure
+5. **Console**: `MCP: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/cursor/{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 `MCP: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 `MCP: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 `MCP: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/cursor/rules/ironbee-verification.mdc

@@ -1,15 +1,13 @@
 ---
-description: "MANDATORY verification after code changes — IronBee enforcement (browser + runtime cycles)"
+description: "MANDATORY verification after code changes — IronBee enforcement (per-cycle verification gate)"
 alwaysApply: true
 ---
 
 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 `MCP: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
 
@@ -24,11 +22,9 @@ 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 (`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 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** — `MCP: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.
@@ -46,8 +42,13 @@ Every file edit automatically clears your verdict, requiring re-verification.
 - 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 `MCP:bdt_*` tools without first opening a verification cycle (`ironbee hook verification-start`).
-- **Submitting a verdict while a browser recording is still active** — always call `MCP: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/cursor/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 `MCP: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: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:bdt_content_start-recording`, and `submit-verdict` rejects with `"recording is still active"` unless you call `MCP: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: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:bdt_content_take-screenshot` — capture the final visual state
-4. **Accessibility**: `MCP:bdt_a11y_take-aria-snapshot` — verify page structure
-5. **Console**: `MCP: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/commands/backend.d.ts

@@ -0,0 +1,17 @@
+/**
+ * `ironbee backend <subcommand>` — manage the runtime-agnostic backend
+ * protocol cycle (HTTP / gRPC / GraphQL / WebSocket via the
+ * `backend-devtools` MCP, `bedt_*` tools).
+ *
+ * Subcommands today:
+ *   - `enable`  — opt in (writes a minimal `{ "backend": {} }` block;
+ *                 multi-language code defaults flow in at runtime).
+ *   - `disable` — opt out (drops the block clean when no customizations
+ *                 + no lower-layer override; otherwise hard-kills via
+ *                 `verifyPatterns: []`).
+ */
+import { Command } from "commander";
+export declare const backendEnableCommand: Command;
+export declare const backendDisableCommand: Command;
+export declare const backendCommand: Command;
+//# sourceMappingURL=backend.d.ts.map

package/dist/commands/backend.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"backend.d.ts","sourceRoot":"","sources":["../../src/commands/backend.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AAEH,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AAqBpC,eAAO,MAAM,oBAAoB,EAAE,OAW7B,CAAC;AAEP,eAAO,MAAM,qBAAqB,EAAE,OAW9B,CAAC;AAEP,eAAO,MAAM,cAAc,EAAE,OAGS,CAAC"}

package/dist/commands/backend.js

@@ -0,0 +1,58 @@
+"use strict";
+/**
+ * `ironbee backend <subcommand>` — manage the runtime-agnostic backend
+ * protocol cycle (HTTP / gRPC / GraphQL / WebSocket via the
+ * `backend-devtools` MCP, `bedt_*` tools).
+ *
+ * Subcommands today:
+ *   - `enable`  — opt in (writes a minimal `{ "backend": {} }` block;
+ *                 multi-language code defaults flow in at runtime).
+ *   - `disable` — opt out (drops the block clean when no customizations
+ *                 + no lower-layer override; otherwise hard-kills via
+ *                 `verifyPatterns: []`).
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.backendCommand = exports.backendDisableCommand = exports.backendEnableCommand = void 0;
+const commander_1 = require("commander");
+const registry_1 = require("../clients/registry");
+const config_1 = require("../lib/config");
+const output_1 = require("../lib/output");
+const cycle_toggle_1 = require("./cycle-toggle");
+function attachToggleOptions(cmd) {
+    return cmd
+        .option("-p, --project-dir <dir>", "Project directory (default: cwd).")
+        .option("-g, --global", "Write to the global config (~/.ironbee/config.json) instead of the project.")
+        .option("--local", "Write to the gitignored project-local override (<project>/.ironbee/config.local.json). Mutually exclusive with --global.")
+        .option("--client <name>", `Only update guidance md files for this client (${(0, registry_1.clientNames)()}), or "all". Default: every registered client (per-file existsSync gate skips uninstalled ones).`);
+}
+exports.backendEnableCommand = attachToggleOptions(new commander_1.Command("enable"))
+    .description("Enable the runtime-agnostic backend protocol cycle. Writes a minimal `{ \"backend\": {} }` block — multi-language code defaults (TS/JS/Py/Go/Java/Ruby/.NET/Rust/Kotlin/Scala paths) flow in at runtime.")
+    .action((opts) => {
+    try {
+        const projectDir = opts.projectDir ?? process.cwd();
+        const target = (0, config_1.resolveConfigTargetFromFlags)(opts);
+        (0, cycle_toggle_1.applyEnableCycle)("backend", projectDir, target, opts.client);
+    }
+    catch (e) {
+        console.error(`${output_1.pc.red("✗")}  ${e instanceof Error ? e.message : e}`);
+        process.exit(1);
+    }
+});
+exports.backendDisableCommand = attachToggleOptions(new commander_1.Command("disable"))
+    .description("Disable the backend protocol cycle. Drops the entire `backend` block when no customizations + no lower-layer override exist; otherwise writes `backend.verifyPatterns: []` (hard kill, preserves customizations).")
+    .action((opts) => {
+    try {
+        const projectDir = opts.projectDir ?? process.cwd();
+        const target = (0, config_1.resolveConfigTargetFromFlags)(opts);
+        (0, cycle_toggle_1.applyDisableCycle)("backend", projectDir, target, opts.client);
+    }
+    catch (e) {
+        console.error(`${output_1.pc.red("✗")}  ${e instanceof Error ? e.message : e}`);
+        process.exit(1);
+    }
+});
+exports.backendCommand = new commander_1.Command("backend")
+    .description("Manage the runtime-agnostic backend protocol cycle (HTTP / gRPC / GraphQL / WebSocket via the `backend-devtools` MCP, `bedt_*` tools).")
+    .addCommand(exports.backendEnableCommand)
+    .addCommand(exports.backendDisableCommand);
+//# sourceMappingURL=backend.js.map

package/dist/commands/backend.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"backend.js","sourceRoot":"","sources":["../../src/commands/backend.ts"],"names":[],"mappings":";AAAA;;;;;;;;;;;GAWG;;;AAEH,yCAAoC;AACpC,kDAAkD;AAClD,0CAA2E;AAC3E,0CAAmC;AACnC,iDAAqE;AASrE,SAAS,mBAAmB,CAAC,GAAY;IACrC,OAAO,GAAG;SACL,MAAM,CAAC,yBAAyB,EAAE,mCAAmC,CAAC;SACtE,MAAM,CAAC,cAAc,EAAE,6EAA6E,CAAC;SACrG,MAAM,CAAC,SAAS,EAAE,0HAA0H,CAAC;SAC7I,MAAM,CAAC,iBAAiB,EAAE,kDAAkD,IAAA,sBAAW,GAAE,kGAAkG,CAAC,CAAC;AACtM,CAAC;AAEY,QAAA,oBAAoB,GAAY,mBAAmB,CAAC,IAAI,mBAAO,CAAC,QAAQ,CAAC,CAAC;KAClF,WAAW,CAAC,0MAA0M,CAAC;KACvN,MAAM,CAAC,CAAC,IAAmB,EAAQ,EAAE;IAClC,IAAI,CAAC;QACD,MAAM,UAAU,GAAW,IAAI,CAAC,UAAU,IAAI,OAAO,CAAC,GAAG,EAAE,CAAC;QAC5D,MAAM,MAAM,GAAiB,IAAA,qCAA4B,EAAC,IAAI,CAAC,CAAC;QAChE,IAAA,+BAAgB,EAAC,SAAS,EAAE,UAAU,EAAE,MAAM,EAAE,IAAI,CAAC,MAAM,CAAC,CAAC;IACjE,CAAC;IAAC,OAAO,CAAU,EAAE,CAAC;QAClB,OAAO,CAAC,KAAK,CAAC,GAAG,WAAE,CAAC,GAAG,CAAC,GAAG,CAAC,KAAK,CAAC,YAAY,KAAK,CAAC,CAAC,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC;QACvE,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;IACpB,CAAC;AACL,CAAC,CAAC,CAAC;AAEM,QAAA,qBAAqB,GAAY,mBAAmB,CAAC,IAAI,mBAAO,CAAC,SAAS,CAAC,CAAC;KACpF,WAAW,CAAC,mNAAmN,CAAC;KAChO,MAAM,CAAC,CAAC,IAAmB,EAAQ,EAAE;IAClC,IAAI,CAAC;QACD,MAAM,UAAU,GAAW,IAAI,CAAC,UAAU,IAAI,OAAO,CAAC,GAAG,EAAE,CAAC;QAC5D,MAAM,MAAM,GAAiB,IAAA,qCAA4B,EAAC,IAAI,CAAC,CAAC;QAChE,IAAA,gCAAiB,EAAC,SAAS,EAAE,UAAU,EAAE,MAAM,EAAE,IAAI,CAAC,MAAM,CAAC,CAAC;IAClE,CAAC;IAAC,OAAO,CAAU,EAAE,CAAC;QAClB,OAAO,CAAC,KAAK,CAAC,GAAG,WAAE,CAAC,GAAG,CAAC,GAAG,CAAC,KAAK,CAAC,YAAY,KAAK,CAAC,CAAC,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC;QACvE,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;IACpB,CAAC;AACL,CAAC,CAAC,CAAC;AAEM,QAAA,cAAc,GAAY,IAAI,mBAAO,CAAC,SAAS,CAAC;KACxD,WAAW,CAAC,wIAAwI,CAAC;KACrJ,UAAU,CAAC,4BAAoB,CAAC;KAChC,UAAU,CAAC,6BAAqB,CAAC,CAAC"}

package/dist/commands/browser.d.ts

@@ -0,0 +1,19 @@
+/**
+ * `ironbee browser <subcommand>` — manage the browser verification cycle.
+ *
+ * Subcommands today:
+ *   - `enable`  — turn the browser cycle on (default-on; use this to re-enable
+ *                 after `disable`, or to strip a prior `verifyPatterns: []`
+ *                 override).
+ *   - `disable` — turn the browser cycle off (writes `verifyPatterns: []` as
+ *                 a hard kill; preserves customizations).
+ *
+ * The hierarchical `browser <verb>` shape leaves room for future per-platform
+ * commands beyond enable/disable (e.g. `browser status`, `browser inspect`,
+ * `browser test`) without name-spacing them at the top level.
+ */
+import { Command } from "commander";
+export declare const browserEnableCommand: Command;
+export declare const browserDisableCommand: Command;
+export declare const browserCommand: Command;
+//# sourceMappingURL=browser.d.ts.map

package/dist/commands/browser.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"browser.d.ts","sourceRoot":"","sources":["../../src/commands/browser.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;GAaG;AAEH,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AAqBpC,eAAO,MAAM,oBAAoB,EAAE,OAW7B,CAAC;AAEP,eAAO,MAAM,qBAAqB,EAAE,OAW9B,CAAC;AAEP,eAAO,MAAM,cAAc,EAAE,OAGS,CAAC"}

package/dist/commands/browser.js

@@ -0,0 +1,60 @@
+"use strict";
+/**
+ * `ironbee browser <subcommand>` — manage the browser verification cycle.
+ *
+ * Subcommands today:
+ *   - `enable`  — turn the browser cycle on (default-on; use this to re-enable
+ *                 after `disable`, or to strip a prior `verifyPatterns: []`
+ *                 override).
+ *   - `disable` — turn the browser cycle off (writes `verifyPatterns: []` as
+ *                 a hard kill; preserves customizations).
+ *
+ * The hierarchical `browser <verb>` shape leaves room for future per-platform
+ * commands beyond enable/disable (e.g. `browser status`, `browser inspect`,
+ * `browser test`) without name-spacing them at the top level.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.browserCommand = exports.browserDisableCommand = exports.browserEnableCommand = void 0;
+const commander_1 = require("commander");
+const registry_1 = require("../clients/registry");
+const config_1 = require("../lib/config");
+const output_1 = require("../lib/output");
+const cycle_toggle_1 = require("./cycle-toggle");
+function attachToggleOptions(cmd) {
+    return cmd
+        .option("-p, --project-dir <dir>", "Project directory (default: cwd).")
+        .option("-g, --global", "Write to the global config (~/.ironbee/config.json) instead of the project.")
+        .option("--local", "Write to the gitignored project-local override (<project>/.ironbee/config.local.json). Mutually exclusive with --global.")
+        .option("--client <name>", `Only update guidance md files for this client (${(0, registry_1.clientNames)()}), or "all". Default: every registered client (per-file existsSync gate skips uninstalled ones).`);
+}
+exports.browserEnableCommand = attachToggleOptions(new commander_1.Command("enable"))
+    .description("Enable the browser cycle. Browser is default-on; this command writes a minimal `{ \"browser\": {} }` block (no pattern materialization; code defaults flow in at runtime) OR strips a prior `verifyPatterns: []` disable-override.")
+    .action((opts) => {
+    try {
+        const projectDir = opts.projectDir ?? process.cwd();
+        const target = (0, config_1.resolveConfigTargetFromFlags)(opts);
+        (0, cycle_toggle_1.applyEnableCycle)("browser", projectDir, target, opts.client);
+    }
+    catch (e) {
+        console.error(`${output_1.pc.red("✗")}  ${e instanceof Error ? e.message : e}`);
+        process.exit(1);
+    }
+});
+exports.browserDisableCommand = attachToggleOptions(new commander_1.Command("disable"))
+    .description("Disable the browser cycle (writes `browser.verifyPatterns: []` to override the default 40+ extension fallback; preserves customizations of `alwaysRequired` / `evidencePaths` / `additionalVerifyPatterns`).")
+    .action((opts) => {
+    try {
+        const projectDir = opts.projectDir ?? process.cwd();
+        const target = (0, config_1.resolveConfigTargetFromFlags)(opts);
+        (0, cycle_toggle_1.applyDisableCycle)("browser", projectDir, target, opts.client);
+    }
+    catch (e) {
+        console.error(`${output_1.pc.red("✗")}  ${e instanceof Error ? e.message : e}`);
+        process.exit(1);
+    }
+});
+exports.browserCommand = new commander_1.Command("browser")
+    .description("Manage the browser verification cycle (DOM / console / a11y / screenshots via the `browser-devtools` MCP, `bdt_*` tools).")
+    .addCommand(exports.browserEnableCommand)
+    .addCommand(exports.browserDisableCommand);
+//# sourceMappingURL=browser.js.map

package/dist/commands/browser.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"browser.js","sourceRoot":"","sources":["../../src/commands/browser.ts"],"names":[],"mappings":";AAAA;;;;;;;;;;;;;GAaG;;;AAEH,yCAAoC;AACpC,kDAAkD;AAClD,0CAA2E;AAC3E,0CAAmC;AACnC,iDAAqE;AASrE,SAAS,mBAAmB,CAAC,GAAY;IACrC,OAAO,GAAG;SACL,MAAM,CAAC,yBAAyB,EAAE,mCAAmC,CAAC;SACtE,MAAM,CAAC,cAAc,EAAE,6EAA6E,CAAC;SACrG,MAAM,CAAC,SAAS,EAAE,0HAA0H,CAAC;SAC7I,MAAM,CAAC,iBAAiB,EAAE,kDAAkD,IAAA,sBAAW,GAAE,kGAAkG,CAAC,CAAC;AACtM,CAAC;AAEY,QAAA,oBAAoB,GAAY,mBAAmB,CAAC,IAAI,mBAAO,CAAC,QAAQ,CAAC,CAAC;KAClF,WAAW,CAAC,oOAAoO,CAAC;KACjP,MAAM,CAAC,CAAC,IAAmB,EAAQ,EAAE;IAClC,IAAI,CAAC;QACD,MAAM,UAAU,GAAW,IAAI,CAAC,UAAU,IAAI,OAAO,CAAC,GAAG,EAAE,CAAC;QAC5D,MAAM,MAAM,GAAiB,IAAA,qCAA4B,EAAC,IAAI,CAAC,CAAC;QAChE,IAAA,+BAAgB,EAAC,SAAS,EAAE,UAAU,EAAE,MAAM,EAAE,IAAI,CAAC,MAAM,CAAC,CAAC;IACjE,CAAC;IAAC,OAAO,CAAU,EAAE,CAAC;QAClB,OAAO,CAAC,KAAK,CAAC,GAAG,WAAE,CAAC,GAAG,CAAC,GAAG,CAAC,KAAK,CAAC,YAAY,KAAK,CAAC,CAAC,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC;QACvE,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;IACpB,CAAC;AACL,CAAC,CAAC,CAAC;AAEM,QAAA,qBAAqB,GAAY,mBAAmB,CAAC,IAAI,mBAAO,CAAC,SAAS,CAAC,CAAC;KACpF,WAAW,CAAC,8MAA8M,CAAC;KAC3N,MAAM,CAAC,CAAC,IAAmB,EAAQ,EAAE;IAClC,IAAI,CAAC;QACD,MAAM,UAAU,GAAW,IAAI,CAAC,UAAU,IAAI,OAAO,CAAC,GAAG,EAAE,CAAC;QAC5D,MAAM,MAAM,GAAiB,IAAA,qCAA4B,EAAC,IAAI,CAAC,CAAC;QAChE,IAAA,gCAAiB,EAAC,SAAS,EAAE,UAAU,EAAE,MAAM,EAAE,IAAI,CAAC,MAAM,CAAC,CAAC;IAClE,CAAC;IAAC,OAAO,CAAU,EAAE,CAAC;QAClB,OAAO,CAAC,KAAK,CAAC,GAAG,WAAE,CAAC,GAAG,CAAC,GAAG,CAAC,KAAK,CAAC,YAAY,KAAK,CAAC,CAAC,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC;QACvE,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;IACpB,CAAC;AACL,CAAC,CAAC,CAAC;AAEM,QAAA,cAAc,GAAY,IAAI,mBAAO,CAAC,SAAS,CAAC;KACxD,WAAW,CAAC,2HAA2H,CAAC;KACxI,UAAU,CAAC,4BAAoB,CAAC;KAChC,UAAU,CAAC,6BAAqB,CAAC,CAAC"}