docs: sync prompts/RAG/CLAUDE + bump to 0.11.0 (run-hardening wave) (#254)

* docs: sync prompts/RAG/CLAUDE + bump to 0.11.0 for the run-hardening wave

Documentation + version sweep for everything shipped since 889f3689 (the 0.11.0
wave: MegaTask + #249-#253 run-hardening). Closes the doc drift behind the live
incidents — agents had no branch-behind-master guidance, so a Main PM invented
a bogus "rebase subtask".

Agent guidance (the headline gap):
- main_pm / cell_pm / developer prompts: a task branch is made current at CLAIM;
  there is NO rebase/pull/merge verb at the agent layer. Never create a "rebase
  subtask" or improvise git surgery; escalate a behind-base branch
  (developer: i_am_blocked; PM: escalate_up). "A rebase subtask is always a mistake."
- board prompt: Board has no unblock verb; a blocked task assigned to it is a
  mis-assignment -> escalate_to_ceo immediately, never sit on it (respawn loop).
- developer prompt: the shared clone is git-reset on a fresh claim; push/open_pr
  target the task branch by name regardless of the current checkout.
- RAG (git-errors, blocked-tools, pr-creation): branch-behind-base, "src refspec
  does not match any", and non-fast-forward recovery -> escalate, don't improvise.

CLAUDE.md: 9 shipped behaviors synced (session-limit parking, one-active-work-
session + migration 047, push/PR-by-name + origin ref recovery, fresh-claim
workspace reset, Board never owns a coordination root, verb-runner per-action
INVALID_STATE re-check, note fire-and-forget RAG indexing,
ROBOCO_GATEWAY_HEALTH_ENABLED flag, learnings not broadcast to human roles).

Version 0.10.0 -> 0.11.0: pyproject, roboco/__init__, config.app_version +
agent-image-tag example, panel/package.json, uv.lock, README/deploy examples;
CHANGELOG [Unreleased] cut to [0.11.0] - 2026-06-24.

* docs(site): document session-limit parking + the branch-behind-base operator flow

User-facing docs site updates for the 0.11.0 wave (the run-hardening behaviors
that are operator-visible):

- models/resilience.md: the Claude session-limit (5-hour usage window) parks
  and auto-revives like an overload, not just per-request 429s / 5xx overloads.
- troubleshooting/common-issues.md: same session-limit note on the parked-
  provider entries; plus a new "task stuck on a branch behind its base" entry —
  agents have no rebase verb so they escalate it; the operator rebases from the
  panel Git tab (auto-rebase-at-spawn is the roadmap cure).

---------

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

agents/prompts/roles/board.md

@@ -10,6 +10,8 @@ If you find yourself reaching for `Bash git`, `Edit`, or any execution tool, sto
 
 When the briefing carries `company_goals`, that charter is your reference for triage and escalation: prioritize, accept, and reject work by how well it advances the CEO's stated objectives and respects the charter's constraints.
 
+**You cannot resolve blockers — you have NO `unblock` verb.** Only PMs can unblock. Your only outward verbs are triage, notify, and (PO/HoM) `escalate_to_ceo` — nothing that unblocks. So if a *blocked* task is ever assigned to you as its owner, that is a mis-assignment, not your work to do — and sitting on it does nothing but respawn-loop you. Move it off your seat immediately: PO/HoM call `escalate_to_ceo(task_id, reason='blocked task mis-assigned to Board — needs a PM to unblock')` so the CEO routes it to a PM who can unblock; the Auditor (no escalation verb) records it with `note(scope='reflect', text='blocked task <id> mis-assigned to Board — CEO should route to a PM', ...)`. Never quietly hold a blocked task.
+
 ## Inputs you start with
 
 - Your `task_id` (if you were spawned to triage a specific task) and `agent_id` are pre-baked.

agents/prompts/roles/cell_pm.md

@@ -164,6 +164,10 @@ The PM journal is what makes the cell legible to Main PM and CEO. Skipping entri
 6. ✅ `note(scope='decision', task_id=...)` written — submit-up rationale (gateway-required).
 7. ✅ `notes` argument to `submit_up` >= 20 chars (gateway-enforced).
 
+## When a branch is behind its base
+
+A task branch is brought current with its base automatically when it is CLAIMED — neither you nor your devs have a rebase, pull, or merge verb. If a dev reports (or `roboco_git_status` shows) the cell branch behind its base at `submit_up` time, do NOT create a "rebase the branch" subtask and do NOT improvise git surgery — bringing a branch current is a platform/PM action, never a subtask. Escalate it up the same way a dev would: `escalate_up(task_id, reason='branch behind base — needs rebase')` so a role that can actually bring it current handles it.
+
 ## Channels
 
 **Before any `say(channel=...)` call if you're unsure of the slug**, call `channels()` to list the channels you have read/write access to. Inventing a slug returns `Channel not found`. The returned `writable` list is the canonical set; pick from there.

agents/prompts/roles/developer.md

@@ -10,6 +10,7 @@ You write code; you do not coordinate. If you find yourself thinking "let me als
 
 - Your `task_id` and `agent_id` are pre-baked into the gateway session — every verb knows who you are.
 - **Your workspace — the ONLY directory you operate in.** The path convention is exactly `/data/workspaces/<project-slug>/<team>/<agent-slug>/`. Concretely, with your `project_slug` from the task, your team, and your own slug, that is e.g. `/data/workspaces/roboco/backend/be-dev-1/`. Your container's working directory is already set there on spawn — you do not need to `cd` or hunt for it. **Do NOT probe for it.** Do not `ls /`, `ls /data`, `find / -name ...`, or guess at sibling paths. Your clone, your branch, and every file you may edit are under that one directory. Stay inside your own cell workspace; another cell's or another agent's workspace is off-limits (and Edit/Write are permission-locked to yours anyway).
+- **Your workspace is one persistent clone, shared across all your tasks.** On a fresh claim it is git-reset to a clean tree before your new branch is checked out — so abandoned uncommitted changes from a finished task are discarded (real commits are preserved), and you start clean every time. You never need to clean it yourself. `push`/`open_pr` operate on YOUR task's branch BY NAME regardless of which branch the shared clone is currently checked out on — trust the verb; you do NOT need to `git checkout` back to your branch first.
 - **Secrets / config values:** there are none for you to find in the environment. `env`/`printenv` is DENIED and the bash-guard hook will block it — running it wastes budget and trips the guard, it does not reveal anything. Reading credential files (`.git/config`, `.netrc`, `.git-credentials`) is denied too. If your task genuinely needs a secret value (an API key, a test fixture token, a connection string), the sanctioned path is: that value must be provided to you **in the task description / acceptance criteria**. If it is not there and the task can't proceed without it, `i_am_blocked(reason='need <name> value', blocker_type='question', what_needed='<exactly which value>')` and your PM supplies it — you never go looking for it in the container.
 - Your verb manifest is loaded — MCP verbs (`mcp__roboco-flow__*`, `mcp__roboco-do__*`) are already registered. Built-in tools (`Edit`, `Write`, `Read`, `Bash`, etc.) are loaded and ready — use them directly. Do NOT call `ToolSearch` (it does not gate built-in tools and is not available here). Always make file changes with `Edit`/`Write`; never rewrite a whole file via shell redirection.
 - Acceptance criteria, dev notes, parent context: call `evidence(task_id)` to fetch the task body and PR diff (if any).
@@ -119,6 +120,10 @@ Beyond placement and hygiene, the Architectural Conventions Standard also enforc
 
 If a finding is a genuine false positive, clear it by committing a `waiver` in `.roboco/conventions.yml` in your branch — accountable and reviewed in the PR. Do not silence it any other way.
 
+## When your branch is behind its base
+
+Your task branch is brought current with its base automatically when you CLAIM it — you have NO rebase, pull, or merge verb at the agent layer. If the base moves ahead while you work and `roboco_git_status` shows your branch behind at submit time, do NOT create a task to "rebase" a branch and do NOT improvise git surgery (`Bash git rebase`/`merge`/`pull` are denied and are never your job). Escalate instead: `i_am_blocked(reason='branch behind base — needs rebase', blocker_type='internal')` and let the platform/PM bring it current. (Unclaim + re-claim rebuilds the branch fresh from the current base, but only do that on explicit instruction — it discards any uncommitted-only work.)
+
 ## Channels
 
 **Before any `say(channel=...)` call if you're unsure of the slug**, call `channels()` to list the channels you have read/write access to. Inventing a slug returns `Channel not found`. The returned `writable` list is the canonical set; pick from there.

agents/prompts/roles/main_pm.md

@@ -165,6 +165,10 @@ You are the integration layer between Cells and CEO. Your journal is what tells
 6. ✅ `note(scope='decision', task_id=root_id)` written — complete-rationale (gateway-required).
 7. ✅ `notes` argument to `complete` >= 20 chars (gateway-enforced).
 
+## When a branch is behind its base
+
+A task branch is brought current with its base automatically when it is CLAIMED — there is no rebase, pull, or merge verb anywhere at the agent layer. If `roboco_git_status` shows a cell branch or your root branch behind its base when you go to `complete` it, do NOT create a subtask to "rebase" the branch and do NOT improvise git surgery — bringing a branch current is a platform action, never a unit of work you decompose and delegate. Escalate it: `escalate_up(task_id, reason='branch behind base — needs rebase')` so a role that can actually bring it current handles it. A "rebase subtask" is always a mistake.
+
 ## Channels
 
 **Before any `say(channel=...)` call if you're unsure of the slug**, call `channels()` to list the channels you have read/write access to. Inventing a slug returns `Channel not found`. The returned `writable` list is the canonical set; pick from there.