bearing-prlisted

# Writing a PR someone can actually review <!-- BEGIN GENERATED: graph-uncertainty — bearing regenerates this block; edits here are replaced on update --> ## The graph can be wrong A zero is not absence; a near-0.5 `r.confidence` edge is a lead, not proof (~92% of `USES`); a count can be a floor — `impact` says which in `epistemic`. Before a conclusion that matters, confirm with a scoped `Grep` (allowed here, not a gate violation) and say which check you ran. <!-- END GENERATED: graph-uncertainty --> It matters more here than anywhere else: a PR body states the blast radius **to the team**, in writing, and you cannot take it back. If `epistemic` is not `"exact"`, write the number as a floor. ## The problem this solves A reviewer's real questions are *what breaks if this is wrong*, *what else does it touch*, and *how do I check it*. The default PR body — a bulleted list of what changed — answers none of them, and answering them from the diff is the reviewer's most expensive work. Do it once, as the author, while you still remember why. ## Step 0 — Follow the house style if there is one **Never impose this structure on a repo that has its own.** In order: 1. `.github/pull_request_template.md`, `.github/PULL_REQUEST_TEMPLATE.md`, or any file under `.github/PULL_REQUEST_TEMPLATE/` → fill it in, exactly as written. Do not add sections it omits. 2. No template → read the **three most recently merged PRs** for their shape: `gh pr list --state merged --limit 3 --json t