docs: v0.23.0 agent-facing sweep — map, RAG corpus, CLAUDE.md (#468)

New map + RAG entries for the vault subsystem; sequence gate, lineage
merge, gate diff-base, CI guard, playwright MCP, dispatcher prefilter,
backup sidecar, and the 300/100 budget reflected across docs/map,
docs/rag, and CLAUDE.md; stale claims fixed (agent-ux 'no extra tools',
old budget defaults). No redirects needed — nothing publicly published
moved.

Co-authored-by: Renn F <rennf93@users.noreply.github.com>

docs/rag/roles/auditor.md

@@ -21,6 +21,7 @@
 - Record private observations via `note(text="...", scope="reflect")`
 - Attach evidence via `evidence(task_id)`
 - Search the knowledge base via `roboco_ask_mentor` / `roboco_kb_search`
+- Curate the Obsidian vault's narrative for a just-completed root task-tree via `curate_vault(task_id, narrative)` — see below (only when `ROBOCO_OBSIDIAN_VAULT_ENABLED`)
 
 ## What You CANNOT Do
 
@@ -59,16 +60,20 @@ note(
 evidence(task_id="...")  # attach the evidence trail to the finding
 ```
 
+## Vault curation
+
+When the Obsidian vault is armed, the orchestrator spawns you once per completed ROOT task (a one-shot, not something you poll for) with the task id and title named in your prompt. Read the task tree — its own content plus subtasks, notes, and outcome — and write ONE narrative paragraph capturing what actually happened and why it matters, then call `curate_vault(task_id="...", narrative="...")` exactly once. This fully re-materializes the task's vault note (parent/subtasks/dependencies resolved fresh) with your narrative filling the `## Narrative` section that a deterministic projection otherwise leaves as a placeholder — it's the one piece of vault content that isn't mechanically derivable from DB columns. The write is idempotent; a retry just re-materializes the same note.
+
 ## Tool Surface (per-spawn manifest)
 
 | MCP server            | Verbs you can call |
 |-----------------------|--------------------|
 | `roboco-flow`         | `triage`, `i_am_idle` |
-| `roboco-do`           | `note` (scope=`reflect`), `evidence`, `notify_list`, `notify_get` |
+| `roboco-do`           | `note` (scope=`reflect`), `evidence`, `notify_list`, `notify_get`, `curate_vault` |
 | `roboco-git-readonly` | `roboco_git_status`, `roboco_git_log`, `roboco_git_diff`, `roboco_git_branch_list` |
 | `roboco-optimal`      | `roboco_ask_mentor`, `roboco_kb_search` |
 
-**Read-only observer.** No `dm`, `notify`, `commit`, or any write verb is in your manifest. All `Write/Edit` and native git commands are blocked.
+**Read-only observer.** No `dm`, `notify`, `commit`, or any task-mutating write verb is in your manifest, and all `Write/Edit` and native git commands are blocked. `curate_vault` is the one narrow exception — it writes a vault markdown note, never task state, code, or git.
 
 ## Communication
 

docs/rag/roles/pr-reviewer.md

@@ -23,6 +23,12 @@ The `pr_reviewer` role also runs the **in-path gate** on the org's OWN assembled
 
 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 — the remediation hint points you at the offending `file:line` + the `pr_fail` verb (not `i_am_blocked`). 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.
 
+`pr_pass` also refuses while CI on the assembled PR's head commit is not resolvably green. Failing CI names the check(s) and points the remediation at `pr_fail(issues=['CI failing: ...'])`; pending / not-yet-scheduled / a transient GitHub API error are framed as retryable — wait and call `pr_pass` again once CI resolves, not a defect to route back to the dev via `pr_fail` unless the diff itself is also bad. A project with no CI configured at all passes through cleanly (the verdict note is stamped `ci_status: "no CI configured on this project"` so the PM can see the guard ran and deliberately did not block). Do not chase `i_am_blocked` for any of these — the reject lever is always `pr_fail`.
+
+**The per-AC evidence-walk is non-negotiable.** Do not assert "criteria met" from a skim. Walk every acceptance criterion on the parent task ONE AT A TIME and pin it to a concrete `file:line` in the assembled diff that satisfies it. A criterion you cannot pin to a line is not satisfied — treat it exactly like a missing deliverable, not a maybe: a silently dropped AC is an automatic `pr_fail`.
+
+The diff you review is resolved against the task's REAL parent branch (its recorded `branch_name`, not a string-derived guess) — so a cross-team hop (a frontend cell child of a main_pm root, for example) shows you only what this task actually added, never the inherited base-branch content underneath it.
+
 You cannot `pr_pass` / `pr_fail` an assembled PR you authored (self-review guard, same shape as QA's). A `claim_gate_review` on your own work returns `not_authorized`.
 
 ## What You CAN Do