Merge pull request 'Playbooks 07 and 08: a repository's own clone stays on main (issue 1010)' (#399) from fix/1010-clone-stays-on-main into main

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

@@ -68,7 +68,9 @@ never into the running one, unless it blocks the running one.
 2. **Make the worktrees:** one per touched repository under `.work/<slug>/<repo>`, branched off `main`
    (`git worktree add .work/<slug>/<repo> -b feat/<slug> origin/main`). The lab beds find the other
    repositories by sibling path, so add the untouched siblings the lab reads as detached worktrees on
-   `main` (`git worktree add --detach .work/<slug>/mesh-tools main`), never symlinks.
+   `main` (`git worktree add --detach .work/<slug>/mesh-tools main`), never symlinks. **A repository's own
+   clone stays on `main`** (the operator, 2026-10-17): no work is done in it and no branch is checked out
+   there, so a session that opens in it reads what holds now; fetch and fast-forward it before reading.
 3. **Settle every open question** in the feature's issues before any agent starts: on the issue, through
    the knowledge base, or by asking the operator. A fixing agent that meets an undecided design question
    stops, and its run is spent again.
@@ -272,6 +274,8 @@ issues in `fixing` that nobody works on reads to the operator as stuck work.
   request into a feature branch exists. A pull request per issue, or an agent waiting on a merge check in
   phase 1, is the failure this playbook prevents.
 - A context file exists per touched repository under `.work/<slug>/` while the feature runs.
+- Every repository's own clone says `main` (`git -C <clone> branch --show-current`); another branch there is
+  work done outside a worktree (issue 1010).
 - After a feature's delivery, `git branch -r | grep feat/<slug>` and `git worktree list` return nothing for it.
 - A design whose milestone issues are partly resolved says `in-progress`, and one whose issues are all
   resolved and delivered says `implemented`: read its Milestones section against `issue-tracker.get` for each

00-META/process/08-small-fixes.md

@@ -29,7 +29,8 @@ one delivery**. Everything before the push is local and fast.
    need a second repository, or more than about an hour, stops here and becomes a feature; one that needs a
    decision stays a small fix.
 2. **Move the issue to `fixing`** with `by` as who@node.
-3. **Build on a local branch** `fix/<issue>-<slug>`, in a worktree of its own branched from `main`. Write the
+3. **Build on a local branch** `fix/<issue>-<slug>`, in a worktree of its own branched from `main`, never in
+   the repository's own clone, which stays on `main` (playbook [07](07-feature-branches.md), phase 0 step 2). Write the
    test that fails today first; make the change; keep `gofmt`, `go vet` and the unit tests of what changed green
    (each well under a second; never a merge check or a database locally: how-we-build §5, ADR 0391).
    Commit, naming the issue. For a playbook or design edit, run the repository's own checks (in hq,
@@ -99,3 +100,5 @@ reading itself and uses one subagent only for the review.
   asking a change outside the issue's done-when, is the failure of steps 4 to 6.
 - An issue in `fixing` with nobody on it shows in `issue-tracker.list` with `flag: abandoned`; a stopped fix
   moves it back to `open` with its note.
+- The repository's own clone says `main` (`git -C <clone> branch --show-current`); another branch there is a
+  fix built outside a worktree (issue 1010).