Size an issue for one repository and five to ten minutes, and have a long run say where it stands, in playbook 07
mesh/merge-gate head 048f14540a50 merged into trunk c2ee44255e5b — pass: the change touches no module of the mesh's graph
mesh/repo-check head 048f14540a50 merged into trunk c2ee44255e5b — pass: its merge-check.sh passed
mesh/delivery delivered

On 2026-10-15 issues spanning one repository finished in two to four minutes, while those spanning two or
three ran for thirty to sixty, mostly merging the feature head and checking again as other agents landed.
The operator asked for agents that finish in five to ten minutes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
2026-10-15 12:37:33 +00:00
co-authored by Claude Opus 5.5
parent c2ee44255e
commit 048f14540a
+10 -3
View File
@@ -86,8 +86,11 @@ reviews and delivers at the end. The agents never push.
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 repository and the files it changes: one repository and one change, sized so an agent finishes in
five to ten minutes. The repository's own check is a floor under that: mesh-controller's, with its
store, took 6 minutes 51 seconds on 2026-10-15 (the merge check of mesh-controller #342). A change that needs readers in one repository before a writer in another is two issues,
the second depending on the first, not one agent through three repositories: each extra repository
means merging the feature head and running every check again while other agents land;
- 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;
@@ -143,7 +146,7 @@ headed exactly "Ready to build". If any line cannot be filled in, the issue is n
```
Ready to build (<lead>, <time>).
Repository: <one repository; split the issue if it needs more, or name the landing order>.
Repository: <one repository; an issue that needs another is split, the second depending on the first>.
Files: <path:function or path, each>.
Decisions it builds with: <quoted, one line each, with where each was decided>.
First test: <name and what it asserts; it fails today because …>.
@@ -191,6 +194,10 @@ the mesh manages on a machine. Use the glossary's words; the unit of work is an
fast-forward, go back to step 5.
8. Note the issue: the commits and how its done-when is proven. Leave it in `fixing`.
**Fifteen minutes.** An agent still working after fifteen minutes tells the lead, in a few lines and
without stopping, what has landed, what is left and whether part of it could be split off; the lead decides
whether it goes on or is split.
**Report back,** in under 150 words: commits per repository, the tests added and that they failed first, the check
results, and anything you stopped on or found that a later issue must know.