review-leanlisted

# review-lean Input a PR number. Output findings on the PR and a **committed verdict record** the build run's milestone 4 and the merge boundary both read. This runs as its own top-level session, and that is the entire point: the session that wrote the code does not author its own evaluation. `G` = `lean-gate.sh` in the sibling `build-lean/` skill directory. > **Tracker delta (`tracker.type: jira`, `writes: false`).** The checklist below is the > **github** default. Under jira: the issue key resolves from `Closes [<KEY>]` under > `### Jira Items` in the PR body, not `Closes #N` (2). The step-8 findings comment is > unaffected — it is a code-host write, not a tracker one, so it posts the same under both > adapters and carries the bot identity under both wherever a bot is configured. No other > checklist step differs. > [Adapter contract](../../tools/tracker/jira/README.md). ## Checklist 1. Export a review identity before anything else — `RUN_ID=review-<issue>-<round>`, charset `[A-Za-z0-9._-]+`. It is cached per-issue under the review role, never shared with the build run's. 2. `gh pr view <pr> --json number,headRefName,baseRefName,body,url` — the head branch resolves the issue key (`Closes #N` in the body) and the lean spec path. 3. Check out the PR head **by branch name** — any checkout with that branch checked out works, and a DETACHED head does not: steps 4 and 6 derive their answer from the checkout they run in. The build run's worktree is the usua