docs: add driver prompt and merge policy

Relaxes the concurrency rule to per-crate edits, records that the PR daemon
spawns land and review-pr sessions automatically, and makes the driver the
only thing that merges — skipping a stalled reviewer rather than blocking.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

CLAUDE.md

@@ -126,8 +126,30 @@ alone. The loop:
 2. Of what remains, take the lowest phase number first, then whatever
    parallelises within it.
 3. Spawn one session per issue, selecting the model from `difficulty/`.
-4. Wait for CI green on the pull request before marking the issue done and
-   recomputing the ready set.
+4. Merge on green and reviewed, then recompute the ready set.
+
+### What happens after a pull request opens
+
+The **PR daemon** (`pr-daemon.service`, org-wide over `yolo/*`) picks up every
+pull request automatically. It spawns two sessions per PR:
+
+- `<n>-<slug>` running the `land` skill — the author side, fixing CI failures
+  and addressing review comments.
+- `rev-<n>-<slug>` running `review-pr` — the reviewer side, posting findings to
+  Gitea.
+
+The driver does **not** babysit either of them, and does not re-implement what
+they do. It waits.
+
+**Neither of them merges.** That is the driver's job, and the operator does not
+review personally.
+
+Merge when CI is green and the review session has finished. If the review
+session never spawned, or is stuck — no progress for ~20 minutes, or the
+session is gone — **skip waiting and merge on CI green alone**. A stalled
+reviewer must not block the queue.
+
+Squash merge, delete the branch, close the issue.
 
 ### Model selection
 
@@ -205,9 +227,11 @@ mid-issue.
 
 ### What a driver must not do
 
-- Do not run more than one session per crate at a time. Cargo workspace
-  builds contend, and two sessions editing the same crate produce conflicts
-  that cost more than the parallelism saved.
+- Do not run two sessions **editing the same crate** at the same time. Each
+  session gets its own worktree, so the risk is merge conflicts rather than
+  build contention. In practice this means most of `phase/2-logic` is a chain,
+  since `policy`, `lang`, `hdr` and `score` all live in `arr-core`. Issues in
+  different crates parallelise freely.
 - Do not start `phase/4-movies` work until `phase/2-logic` is complete. The
   policy engine is the thing everything else calls.
 - Do not merge a pull request that skips tests to get CI green. Failing tests