mesh/merge-gate head e7417cf1248c merged into trunk c22b58143b74 beside mesh-host#116@bff1ac14 — pass: the change touches no module of the mesh's graph
From the delivery-time audit of 2026-10-16: seven review rounds on issue 704, a feature branch's first
check failing on 29 problems, mesh-catalog #300 waiting 12 h unmarked, the mail modules failing live,
98 issues held in fixing.
The research playbook named acceptance tests the milestones carry, which
playbooks 02 and 04 did not know; its pre-check also disagreed with the
knowledge base's deferral rule.
Proposing records one after another serialises their reviews and the
operator's asks; retyping the effort's findings into each record makes them
long and gives the review more to send back.
Research 053's identity part took six versions and about two hours: options
that broke the mesh's own rules were offered and argued back, a version was
proposed after every answer, and reviews returned findings a pre-check
would have caught. A lab run was planned where an in-process test answered.
The operator found 04 odd on 2026-10-15: it went from a settled design straight to building,
with no work breakdown, and contradicted playbook 07 on pull requests. 01 now starts from the
operator's idea with setup questions, findings and a direction the operator confirms; 02
graduates that direction into one record per reversible choice and hands the design on; 04
breaks it into milestones usable on their own, one issue per repository part, each milestone
one feature step of 07. 01 notes the knowledge base's insight-only rule for an active effort
until issue 844 is delivered.
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>
2026-10-13 23:12:23 +00:00
6 changed files with 154 additions and 18 deletions
@@ -31,22 +31,34 @@ one delivery**. Everything before the push is local and fast.
Commit, naming the issue. For a playbook or design edit, run the repository's own checks (in hq,
`sh merge-check.sh`).
4.**One review of the local commit, before anything is pushed** (a reviewer that did not write it, larger
model; at most 3 rounds, as playbook 07; from round 2 only what is wrong). The reviewer's findings go back to the same agent that wrote the fix, continued by
model; at most 3 rounds, as playbook 07; from round 2 only what is wrong; a finding outside the issue's
done-when is opened as an issue of its own, never asked as a change). The reviewer's findings go back to the same agent that wrote the fix, continued by
its id, so the fix keeps its context. A playbook or design edit of a few lines may skip the reviewer: the
operator's word on the pull request is its review.
5.**Push once and open the pull request.** The forge's merge checks run the integration tests. A failed check
operator's word on the pull request is its review, and the lead marks it ready on that word.
5.**Push once and open the pull request, once the coast is clear** (playbook [07](07-feature-branches.md), *Is
the coast clear?*: no release branch in flight in the repository that shares a file with the fix). The forge's merge
check runs the integration tests, the only
place they run (the operator, 2026-10-16). A failed check
goes back to the same agent with the failure, and the reviewer reads only the change it makes.
6.**Mark it ready** (`mesh/ready` and `ready at <full sha>`) once the operator's word is given; mesh-delivery
merges it when its checks pass.
6.**The reviewer marks it ready at once** (for an edit that skipped the reviewer, the lead, on the
operator's word) (`mesh/ready` and `ready at <full sha>`, the head it approved);
mesh-delivery merges it when its checks pass. A fix to a module that changes how it runs carries an
integration test starting the module whole against the real bus and store, run by the forge's checks
(ADR 0391 §1, §6); unit tests alone are not that proof, and the lab is not used. The operator's word is waited for only when the fix changes what the operator sees, removes data,
or needs the operator's terminal.
7.**Follow its delivery plan to done** (`mesh-controller.plans` with `wait` and `until: done`), prove the fix on
the mesh (the symptom gone, measured), and resolve the issue with `located-in` and `fixed-by` the same hour.
A fix that stops before its delivery moves its issue back to `open` with a note saying how far it got
(branch, last commit, what is left), as playbook [07](07-feature-branches.md) says.
## Bounds
| Waiting on | Bound | Past the bound |
|---|---|---|
| building the fix | 1 hour | it is a feature: stop and plan it under playbook 07 |
| the review | 15 minutes | ask the reviewer where it stands |
| the ready mark | 15 minutes after the review approved | the reviewer marks it, or the lead does |
| the merge check | 15 minutes | read `mesh-controller.queue` and the check's log |
| the merge after ready | 5 minutes after the checks pass | read `mesh-delivery.show` for the delivery |
| the delivery plan | its class's budget (`mesh-delivery.times`), at most 30 minutes | read `mesh-controller.plans`, then `mesh-delivery.stalled` |
@@ -63,3 +75,8 @@ reading itself and uses one subagent only for the review.
- A small fix has one pull request with one or few commits naming its issue, opened after its review: a pull
request with many heads is a fix reviewed after its push.
- Its issue moves to `resolved` within the hour its delivery plan ends.
- A pull request reviewed and green but unmarked
for more than 15 minutes, a fix to a module's running marked ready with no integration test of the module whole, or a review report
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
**Replaced by WP9.** ADR 0394 supersedes ADR 0310: `node-files` takes over every read below, with the same
bounds, content rule and refusal of secret places; once `node-files` is held on every node, the next delivery
removes `node-reads` and `mesh-reads`.
ADR 0268 §5 has narrow read tools take the common reads over from `execute`, so that an approval is asked for an
act and not for a read, and ADR 0286 §44 sets the approval mark on `execute` only once those reads have a tool on
every node. Two had none: reading or searching a file, and looking up an account or a group.
@@ -366,3 +372,38 @@ under the same issue.
`mesh-sdk` test of the content rule and one in each of its users; `mesh_search` for `cat`, `grep` and
`getent passwd` finding the verbs. Live, the kernel's RAID status file is read through the seat on the home
server, and the agent's credentials file on the laptop is refused.
## WP9 — Every file on a node is managed through `node-files`
*`mesh-catalog`, `mesh-controller`. ADR 0394; tracked by issue 900.*
`node-reads` only reads, and as an account that cannot open a person's home, so nothing in the mesh could copy,
move, write or delete a file, and a cleanup needed a shell on the machine. Most files belong to no module: homes,
project folders, downloads, logs, scratch.
- **A node seat, `node-files`, on every node**, held by a module of its own, `mesh-files`, beside `mesh-reads`
in the catalogue; the controller holds the seat's definition beside the other node seats. It has a verb for each file action: list,
stat, readlink, read, search, write, copy, move, delete, make a folder, change mode, change owner, account and group
lookup, and the trash's list and restore. Each says what it replaces (ADR 0245): `ls`, `stat`, `readlink`, `cat`,
`grep`, `cp`, `mv`, `rm`, `mkdir`, `chmod`, `chown`, `getent passwd`, `getent group`, `id`, and `ssh <node> cp` for a
copy between nodes.
- **It may touch every file.** It declares no account of its own: the tool runner starts it as the node's
operator account, which has sudo without a password, and it uses `sudo -n` only where that account's own rights
do not reach. It keeps each file's owner and modes as well as it can: a copy or a move keeps them, a new file
takes its folder's owner. Which files to touch is the caller's responsibility; it judges no permission.
- **Nothing is lost at once.** A file deleted or overwritten goes to the node's trash with who asked and why, is
restorable for 7 days, and is emptied after.
- **A path a module owns is refused**, naming the module and its tool, unless the call says `override` with a
reason; an override is recorded and said to the operator.
- **It replaces `node-reads`.** Its reads keep WP8's bounds, content rule and kernel reads. Every node is
assigned `mesh-reads`, so `node-reads` and `mesh-reads` are removed by the next delivery, once `mesh-files`
holds `node-files` on every node.
- **No Approve is asked**; every act is recorded with its caller. Read and search never return the content
of a known credential file or a secret place (the mesh never prints a token); copying or moving one is
allowed.
**Proof.** The module's tests: each verb against a temporary tree keeps owner and modes, a new file takes its
folder's owner, a delete is restorable from the trash and gone after 7 days, an owned path is refused and an
override recorded, a credential file's content is never returned. Live: the operator's `~/.claude` on a workstation is listed, a file in `/etc` is read through sudo, and a file copied from one node to another
arrives with its owner and modes.
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
jschoubben
mesh-tools
jochen
mesh-admin