docs: refresh user-facing docs for the features shipped since 0.8.0

Documentation had drifted behind the post-0.8.0 work. Adds a CHANGELOG [Unreleased] section, documents the three new feature flags in the config reference (and removes the retired ROBOCO_RAG_USE_HYDE), a new Architectural Conventions Standard page, the provider-overload break in CLAUDE.md, the >=3.13 Python floor + feature flags in the README, and the toolchain/conventions delivery gates + structured-note model across the developer / QA / PR-reviewer role docs and the task-model doc.

docs/rag/roles/developer.md

@@ -80,6 +80,12 @@ There is **no** `roboco_git_commit / _push / _create_pr / _merge_pr / _checkout`
 5. **Reflect:** `note(text="...", scope="reflect")` on what changed and why — useful for QA's diff review.
 6. `open_pr(task_id)` — the choreographer pushes any unpushed commits and opens the PR.
 
+## Delivery gates
+
+When toolchain matching is enabled, `i_am_done` is refused if the project's test suite cannot be collected under the interpreter the workspace was provisioned with (a "broken" toolchain). The fix is to call `i_am_blocked(reason='toolchain')` so the environment is rebuilt — never to pass on a source read.
+
+When the architectural-conventions standard is enabled, `i_am_done` is refused on any block-level convention finding (e.g. a model defined in a router), reported with the offending `file:line` and a fix hint. A genuine false positive is cleared by committing a waiver in `.roboco/conventions.yml`.
+
 ## A2A Collaboration
 
 ```python

docs/rag/roles/pr-reviewer.md

@@ -19,6 +19,10 @@ The org's own in-flight integration PRs are skipped by the **inbound** poll abov
 
 The `pr_reviewer` role also runs the **in-path gate** on the org's OWN assembled delivery PRs — the merge-level review QA does not do. When a cell PM bubbles up its cell→root PR (`submit_up`) or the Main PM opens the root→master PR (`submit_root`), the task enters `awaiting_pr_review`. The cell reviewer (be/fe/ux-pr-reviewer) reviews its cell's assembled PR; pr-reviewer-1 reviews the root→master PR for the cross-cell integration seam (the bug class that lives where the FE and BE meet). Workflow: `claim_gate_review(task_id)` → review the assembled diff against the parent objective + every acceptance criterion + the FE↔BE contract → `note(scope="learning", ...)` → `pr_pass(task_id, notes)` (moves it on to the PM merge) or `pr_fail(task_id, issues)` (sends it back to `needs_revision`, like a QA fail). Either verdict is also posted on the assembled PR itself as a GitHub review (server-side, via the bot account) so the decision is visible on the PR the PM merges: `pr_pass` posts an APPROVE and `pr_fail` a REQUEST_CHANGES — except on the root→master PR, which only ever gets a plain COMMENT because only the CEO acts on `master`. This gate gives the merge level the reject teeth the PM otherwise lacks. Leaf dev tasks and branchless coordination roots skip the gate.
 
+### Gate enforcement
+
+When the architectural-conventions standard is enabled, `pr_pass` is refused on any block-level convention finding, the same way the developer's `i_am_done` is. When toolchain matching is enabled, `pr_pass` is likewise refused on a "broken" toolchain status. Your verdict note is a mandatory structured field (`pr_reviewer_notes`) written at `pr_pass` / `pr_fail`; it is persisted structured with a derived text mirror.
+
 ## What You CAN Do
 
 - Pull an inbound-PR review task via `give_me_work()` and claim it via `claim_pr_review(task_id)`.

docs/rag/roles/qa.md

@@ -83,6 +83,12 @@ pass(
 
 `notes` must be substantive — the enforcement layer rejects empty or near-empty notes. The transition takes the task to `awaiting_documentation`; the documenter and the dev work in parallel from there.
 
+Your pass/fail note is a mandatory structured note (a QaNote) carrying substantive findings, not an empty string. It is persisted structured, and the legacy `qa_notes` text column is derived from it.
+
+## Conventions in Review Evidence
+
+When the architectural-conventions standard is enabled, the evidence returned on `claim_review` includes `convention_findings` for the work under review — surface them in your verdict alongside the acceptance-criteria check.
+
 ## Failing QA
 
 ```python