<!-- Python backend verification is ENABLED for this project. -->

## Backend Python Mode (when `python.verifyPatterns` matches an edited file)

> **Precondition: the backend must actually be Python.** If you see `package.json` (with no Python manifest), `pom.xml`, `build.gradle`, `go.mod`, `Cargo.toml`, etc., this section does NOT apply — `MCP:pdt_*` tools won't connect to non-Python processes. Just do browser verification. The target's Python environment must also have `debugpy` installed (`pip install debugpy`).

If the project has python backend verification enabled (`ironbee python enable` once at setup, by an operator who confirmed the backend is Python) and your edits touch matching paths (e.g. `api/**`, `**/views.py`), the stop hook also enforces a Python cycle. The same `verification-start` covers both cycles; one platform-agnostic verdict covers both.

### Mode behavior (python cycle)
- **default** (no arg or `default`): probe / log only the code paths your diff touched. Map each changed file → the view / handler / task it affects → place probes there.
- **full**: probe / log every Python code path reachable from files matching `python.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 Python process** — note its PID, container name (`docker compose ps`), or debugpy listen port (default 5678).
2. **Connect**: `MCP:pdt_debug_connect` with one of `host`+`debugpyPort` / `pid` / `processName` / `containerId` / `containerName`. On the PID / process-name / docker paths debugpy is injected into the running process.
3. **Pick an evidence path** for each changed code path:
   - **Probe path** (proves the code path executed): `MCP:pdt_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:pdt_debug_get-probe-snapshots`. At least one probe must come back with `triggered: true`.
   - **Log path** (proves no errors): exercise the path, then `MCP:pdt_debug_get-logs` with the error level filter.
   - **Network path** (proves the expected outbound call happened): `MCP:pdt_o11y_get-http-requests` once to install the capture agent (forward-looking), exercise the path, then read it again and confirm the expected request(s) / status.
   - **Thread-dump path** (for deadlock / hang fixes): `MCP:pdt_debug_dump-threads` and confirm the expected thread states.
4. **Disconnect** (optional): `MCP:pdt_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 views.py:42 fired once"]
}
```

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

---

## Default Mode (python cycle)

Focus on the code you changed — not the entire Python 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 Python file in scope (view / handler / service / task / 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:pdt_debug_put-tracepoint` for "did it run", `MCP:pdt_debug_put-logpoint` for variable capture, `MCP:pdt_debug_put-exceptionpoint` for new raise 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:pdt_debug_get-probe-snapshots`
- **Check one edge case per new branch** — invalid input, missing field, auth failure, …
- **Logs** — `MCP:pdt_debug_get-logs` at error level; no ERROR-level entries are expected for `pass`
- **Egress changes** — capture outbound HTTP via `MCP:pdt_o11y_get-http-requests` (install first, exercise, read again) and confirm the expected request(s) / status

---

## Full Mode (`/ironbee-verify full`, python cycle)

Probe every Python code path reachable from files matching `python.verifyPatterns`, not just the changed files. Do NOT run `git diff` or scope to recent changes.

- Place probes at every view / handler / service / task entry point in scope, plus key internal branch points (early returns, exception handlers, 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