A feature waited a day for its last issue, each small issue paid for its context again, and
waits nobody saw cost the most time. The operator set the flow on 2026-10-15: prepared context
per repository, one to two hours of local development on unit tests, one review of at most three
rounds back to the same agents, one push for the integration checks, then the delivery plan;
steps for a larger feature; a separate playbook for small fixes; models per step; a wait list
with bounds; a prepared clear at each phase end.
A temporary-directory quota failure, a delivery group's manifest-check
ordering, and an agent that stops or finishes without committing each cost
time during that feature because the playbook did not yet say what to do.
Writing them down so the next feature avoids the same detours.
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>
They lived in a file on one machine that only one session's agents read. They are how every feature's
agents work, so they belong with the method; a feature keeps only its local facts (paths, branch, locks).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The operator, 2026-10-15: the smaller model is as good as free against the weekly allowance, so the
limit that matters is how many agents the lead can settle and follow (three to five); subagents on the
larger model stay at two at most and as rare as possible.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A reviewer that does not know its round keeps finding the next smaller thing: one decision record went
through nine rounds on 2026-10-15, each spending the operator's shared weekly allowance. The operator
asked for three to five rounds, the round told to the reviewer, and the allowance in every report.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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 <noreply@anthropic.com>
Huge pages at always flooded the control-node's spinning disks with journal
write-back and cost the controller its lease; the setting needs an owner,
and the kernel module is the one to-be 42 already names for the kernel.
Redoes the design-48 edit of the unmerged pull request 284, which cited the
record under its file number 0280; the record now lives in the knowledge base
as ADR 0368.
A push starts the forge's checks, which build the modules and run every
test for up to a quarter of an hour, so a review finding fixed after the
push costs another full run (the operator, 2026-10-14).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
Feature 57 was first worked as a pull request per issue into protected
branches and lost most of a day waiting on merge checks. Record the issue
as the unit, a review and checks once at the end, landing by fast-forward
under a lock, and the lessons met on the way.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A machine that says nothing is often asleep; its builds wait for the
backlog walk (ADR 0360 clause 10), so no new pull request is needed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The pull requests' checks still run before the walk, and by then the
release's branches have reached main. Name the silent machine too, and
list ADR 0360, which the passages rest on (review comment 12348).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ADR 0360 sends a merge's builds to every machine at once, so release 57
has no first node to hold it and P6 can no longer wait at a gate. ADR 0362
moves the wait for the provisioner to the walk's end.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The word setting waits for R2, P3 waits for F3, the group's order is declared with after: lines, and a stop's fix is a new merge.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Role names instead of node names, the failure rule as ADR 0276 and 0299 have it, readiness and adoption of existing credentials said exactly, and the counts and refusals corrected.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The operator chose one delivery over one per package; the packages meet on one branch per repository and reach main as one delivery group.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
So config and provisioning are built in small, provable steps with at most five worked at once.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The operator would not read the Telegram asks: the ADR 0343 ask was thirty plain lines, a settings
proposal a wall of masked values. The design takes ADR 0345: the asker's summary and points are the body,
everything else a note the channel shows apart, and an ask's values whole on a proving channel.
mesh-tools
jschoubben
jochen
mesh-admin