<!-- 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; 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.
- **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.
4. **Disconnect** (optional): `MCP:ndt_debug_disconnect`.
5. **Submit verdict** — platform-agnostic, just status + checks (+ issues/fixes).

### Verdict (platform-agnostic)
```json
{
  "session_id": "...",
  "status": "pass",
  "checks": ["POST /api/orders returned 201", "tracepoint at handler.ts:42 fired once"]
}
```

For a multi-cycle pass, both browser and node pass criteria must hold.

---

## 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; no ERROR-level entries are expected 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
- No ERROR-level log entries are expected after the full run — any unexpected log error is a fail, regardless of when it was introduced