From 912fd428fb892d4d33441dab4d641aa915849c93 Mon Sep 17 00:00:00 2001 From: mesh-tools Date: Wed, 14 Oct 2026 23:24:14 +0000 Subject: [PATCH] Have the lead settle an issue's questions before a smaller-model agent builds it, two at a time Five agents at once, each stopping on an undecided design question and restarting, spent a week's allowance in a night. Also write down the lessons of feature 57: never land on a red check, a new manifest word lands with the controller that reads it, and review the tree that is pushed. Co-Authored-By: Claude Opus 5.5 --- 00-META/process/07-feature-branches.md | 30 +++++++++++++++++++++++--- 1 file changed, 27 insertions(+), 3 deletions(-) diff --git a/00-META/process/07-feature-branches.md b/00-META/process/07-feature-branches.md index 8419316f..5a4acb24 100644 --- a/00-META/process/07-feature-branches.md +++ b/00-META/process/07-feature-branches.md @@ -82,9 +82,24 @@ reviews and delivers at the end. The agents never push. runs the repository's tests and `merge-check.sh` in its own worktree, then fast-forwards the feature branch under a lock (`flock .lock git -C merge --ff-only `). 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 +- **The lead decides, a fixing agent builds.** Before an issue goes to an agent, the lead reads it and + the code it touches, finds every open question and settles it: decided on the issue, through the + knowledge base, or by the operator. An agent that meets an undecided design question stops, and its + whole run is spent again when it restarts. The issue the agent gets then says, in its own text: + - the repository and the files it changes, one repository where it can be (split an issue along + repository lines rather than send one agent through three); + - the decisions it builds with, quoted, never "read notes 8 to 12"; + - the test to write first, which fails before the change; + - its done-when, in one sentence; + - what it must not touch, and what is landing beside it. + An agent that finds the code differs from its issue stops and reports; it does not design around it. +- **Spend the operator's allowance on judgement.** Every agent the mesh runs draws on one weekly + allowance shared by every session. A fixing agent runs on the smaller model (Sonnet); the lead, the + independent reviews and the decision records run on the larger one, where judgement is the work. +- **At most two issues are being fixed at once.** When one lands, the next ready issue starts at once; an issue is ready when every issue its `depends-on` links name has landed on the feature - branch. + branch and the lead has settled its open questions. (Five at once, with restarts, spent a week's + allowance in a night.) - **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 @@ -96,7 +111,16 @@ reviews and delivers at the end. The agents never push. - **Fetch by name.** In a shared clone a plain `git fetch` may update only `main`. Fetch the feature branch with an explicit refspec before branching from it or comparing against it, or an agent merges a stale copy. -- **Report every ten minutes,** short, as a tree or a table: the issues done (of the total), each +- **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. +- **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 + through the forge, as step 4's push), that commit is a new one on the forge's current base: the + reviewer confirms the forge commit's tree equals the reviewed one before posting its verdict on the + pull request. +- **Report every ten minutes, and at once when something lands or needs the operator,** short, as a tree or a table: the issues done (of the total), each issue being fixed with its active time (minutes since its agent was sent, from a start time written down then, never guessed), the issues ready next, the ones waiting, and anything that needs the operator. Times are local and absolute.