Verification types
IronBee supports three cycle types that can run in parallel:Browser cycle
The agent uses browser devtools to verify frontend and full-stack changes:- Navigates to affected pages
- Takes screenshots at key states
- Checks the browser console for errors
- Tests user interactions (clicks, forms, navigation)
- Records a browser session video
- Submits a verdict with evidence
ironbee browser disable.
Node cycle
The agent connects to a running Node.js process to verify backend changes via V8 inspector:- Connects to the Node inspector
- Sets tracepoints or logpoints at changed code paths
- Exercises those paths via API calls or UI interactions
- Reads back execution snapshots or runtime logs
- Submits verdict with backend evidence
ironbee node enable.
Backend cycle
The agent drives real HTTP, gRPC, GraphQL, or WebSocket requests against a running backend service and verifies the responses. Works for any backend runtime (Node, Java, Python, Go, Rust, and more). Evidence is collected across three domains:| Domain | Tools | What is captured |
|---|---|---|
| Protocol calls | bedt_http_*, bedt_grpc_*, bedt_graphql_*, bedt_ws_* | Request/response pairs, status codes, payloads |
| Observability logs | bedt_log_* | Runtime log lines emitted by the service during the call |
| Database queries | bedt_db_* | SQL or NoSQL queries executed as a side effect |
ironbee backend enable.
Verification status
| Status | Meaning |
|---|---|
in-progress | The agent is actively running this cycle |
pass | All evidence checks passed |
fail | One or more checks failed |
abandoned | The cycle ended before a verdict was submitted |
Retry behavior
If a verification fails, the agent must fix the issues and re-verify. By default, it gets 3 attempts (maxRetries). After the limit is reached, the session can complete but must report unresolved issues.
Each retry creates a new verification cycle, you can see the full history in the timeline.