Merge pull request 'Add three lessons from feature mail-hardening to playbook 07' (#363) from playbook-07-lessons into main

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

@@ -64,6 +64,12 @@ One feature is **one branch name**, **one worktree per repo**, **one MR per repo
    outside a feature (a playbook, a design) goes the same way: review the local commit, then push
    once.
 
+   **One exception: a catalogue change that uses a new manifest word.** The catalogue's merge check
+   reads manifests with the controller the mesh runs — the delivered one, not `main` and not the
+   group's own branch — so such a feature is delivered in two steps, controller first: merge and
+   deliver the controller's pull request, then ask `mesh-delivery.recheck` for the catalogue's, and
+   merge it on the new verdict.
+
 5. **Merge promptly, once approved.** Every merge into `main` is notified and approved
    (ADR 0023); once it is, merge —
    do not leave it sitting. The branch is deleted on merge.
@@ -110,8 +116,11 @@ reviews and delivers at the end. The agents never push.
 - **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'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.
+  `by` names the lead) and keeps working it: for an agent that finished without committing, the lead
+  commits, merges the feature head, runs the checks and lands it; for an agent that stopped on its
+  stop rule, the lead settles the question first — then sends the issue again or lands it itself —
+  or takes the question out of the feature as its own issue, saying on the issue which of the two it
+  did. 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.
@@ -120,7 +129,7 @@ reviews and delivers at the end. The agents never push.
   agent merges a stale copy.
 - **Never land on a red check.** Run the checks, read the result, then land in a separate step; a
   command that checks and lands anyway is how a red branch lands. A manifest claiming a new seat or
-  a new manifest word lands only with, or after, the controller change that understands it.
+  a new manifest word lands only after the controller change that understands it is delivered.
 - **Review the tree that is pushed.** Before the local review, bring each feature branch up to the
   current trunk (fetch by name, then merge or rebase), so the reviewed tree is the pushed tree.
   Where an agent session pushes through the forge tool `gitea_commit` (it puts one commit on a branch
@@ -205,6 +214,12 @@ results, and anything you stopped on or found that a later issue must know.
 its worktrees, the feature branch's name, the lock files, and anything particular to the feature's
 repositories (a check that needs a gate built from another worktree, a test that is red at certain times).
 
+**A shared machine's temporary directory can be filled by other sessions.** A test then fails with
+"disk quota exceeded", which is the machine, not the code: mesh-controller's `internal/builder` test
+`TestAGoProgramsBuildSourceIsItsImportClosure` fails when its temporary directory lies inside a git
+checkout such as the home. The local facts name a temporary directory for tests outside the home, and
+every check runs with `TMPDIR` set to it.
+
 ## What this is not
 
 - **Not a licence to batch unbounded work.** A feature is a *bounded* unit; if it sprawls for