Name the lead, and have it take over a finished issue

A finished issue's agent is gone, so left in fixing it goes stale; the lead
takes it over until the feature is delivered. One repository is one
delivery, not a group; readiness comes from depends-on links (review
comment 12466).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

00-META/process/07-feature-branches.md

@@ -26,6 +26,7 @@ One feature is **one branch name**, **one worktree per repo**, **one MR per repo
 1. **Name the feature once.** `feat/<slug>`. The *same* branch name in every repo the feature
    touches — never a different name per repo, never a fresh branch per increment within the
    feature.
+
    The feature branch is never protected and takes no pull request until step 4: a protected
    branch forces a merge check on every merge into it, which is the waiting this playbook avoids.
 
@@ -47,15 +48,18 @@ One feature is **one branch name**, **one worktree per repo**, **one MR per repo
    ```
 3. **Commit as you go — locally.** Increments land on the one branch. Nothing is pushed and no
    MR is opened mid-feature.
+
    The unit of work is an **issue**. Each commit message names the issue it fixes, such as
    "Keep the assignments on the bus (issue 652)". No pull request, merge check, review or delivery
    per issue.
 
 4. **Finish, then publish.** When the whole feature is done — every repo, tests green — push
    every branch and open **one MR per touched repo**, together.
+
    Each repository's change gets one independent review before its MR opens; the checks run once,
-   on those MRs, and the feature is delivered as one delivery plan (the MRs share the branch name,
-   so they are one delivery group, ADR 0239).
+   on those MRs, and the feature is delivered as one delivery plan. MRs in two or more repositories
+   that share the branch name are one delivery group (ADR 0239 §2); a feature in one repository is
+   one delivery.
 
 5. **Merge promptly, once approved.** Every merge into `main` is notified and approved
    (ADR 0023); once it is, merge —
@@ -65,8 +69,9 @@ One feature is **one branch name**, **one worktree per repo**, **one MR per repo
 
 ## Working one feature with several agents
 
-A large feature (a design's whole work) is fixed by several agents at once. The lead holds the
-feature branch; the agents never push.
+A large feature (a design's whole work) is fixed by several agents at once. The **lead** is the
+session that runs the feature: it holds the feature branch, sends an agent per issue, and pushes,
+reviews and delivers at the end. The agents never push.
 
 - **One feature worktree per repository, held by the lead.** Each agent works on a local branch of
   its own, in a worktree of its own, branched from the feature branch's current head.
@@ -75,11 +80,13 @@ feature branch; the agents never push.
   feature branch under a lock (`flock <feature worktree>.lock git -C <feature worktree> merge
   --ff-only <its branch>`). If another agent landed first, it merges again and repeats.
 - **At most five issues are being fixed at once.** When one lands, the next ready issue starts at
-  once; the design's table of what waits for what says which are ready.
+  once; an issue is ready when every issue its `depends-on` links name has landed on the feature
+  branch.
 - **An issue partly done goes back to `open`** with a note naming the commits that landed and what
   is left, linked `depends-on` to what it waits for. An issue is never left in `fixing` while
-  nobody works on it. A finished issue stays in `fixing` until the feature's delivery, then is
-  resolved.
+  nobody works on it. A finished issue's agent is gone, so the lead takes it over in `fixing` (its
+  `by` names the lead) and keeps working it: it is resolved, with `fixed-by` naming the feature's
+  MRs, once the feature's delivery is done.
 - **Two issues in one file:** keep both sides' behaviour; where both added tests or list lines in
   one place, keep all of them. Never resolve code with a blind `git merge-file --union`: it can
   interleave two functions' braces. Build and test after every resolution.