From a0e4c1fe17b57a2615e3aeaad26e809b005c0072 Mon Sep 17 00:00:00 2001 From: jochen Date: Mon, 26 Oct 2026 20:50:37 +0100 Subject: [PATCH 1/2] Playbooks 07 and 08: one release, one check, no try, push once after the review (ADR 0548) Build capacity is the mesh's scarcest resource: a try before and after the review plus a check per fix round on an open pull request spent it several times per release. --- 00-META/process/00-overview.md | 2 +- 00-META/process/07-feature-branches.md | 127 ++++++++++++++----------- 00-META/process/08-small-fixes.md | 46 ++++----- 00-META/process/playbooks.html | 44 ++++----- 4 files changed, 116 insertions(+), 103 deletions(-) diff --git a/00-META/process/00-overview.md b/00-META/process/00-overview.md index b2823d94..4e8852ed 100644 --- a/00-META/process/00-overview.md +++ b/00-META/process/00-overview.md @@ -60,7 +60,7 @@ A drawn overview of them, the cycle, a feature's steps, the review loop and an i | [05](05-constitution-sync.md) | Constitution sync | `how-we-build.md` changed a rule the mesh enforces | | [06](06-writing-a-module.md) | Writing a module | Something that runs today must run on the mesh | | [07](07-feature-branches.md) | Features | Work that changes code across issues or repositories: prepared context, local development, one review, one check, one delivery | -| [08](08-small-fixes.md) | Small fixes | One issue in one repository, about an hour of work: one try, one review, one delivery | +| [08](08-small-fixes.md) | Small fixes | One issue in one repository, about an hour of work: one review, one check, one delivery | | [09](09-cleanup.md) | Cleanup | Merged branches, stale pull requests, finished worktrees and folders: read first, delete only what the operator approves, report the rest | | [10](10-visual-design.md) | Visual design | A page the operator will use is about to be designed or rebuilt: mockups with fixed data, the operator picks, the pick is the reference | diff --git a/00-META/process/07-feature-branches.md b/00-META/process/07-feature-branches.md index 5ee73193..e88ad073 100644 --- a/00-META/process/07-feature-branches.md +++ b/00-META/process/07-feature-branches.md @@ -35,25 +35,30 @@ A small fix (one repository, one issue, about an hour of work) follows proved nothing, and dropping the field it was for passed every test. A reader of the changed record that the survey never listed ended a module's conditions at each sync. The reviewer judged the bus tests by reasoning, and wrongly, because they ran only after the review. +- **A check asked again and again.** Build capacity is the mesh's scarcest resource ("we don't have more + processing power", the operator, 2026-10-26), and a release that ran a try before its review, a try after it + and a check per fix round on an open pull request spent it several times over: every push to an open pull + request asks a new check, of every member for a group. A release runs one check ("every release should only + run 1 check or 1 try", the operator, 2026-10-26; ADR 0548). - **A module proven only after it reached the machines.** The mail modules were delivered with unit tests only, then failed live three times (issues 859, 865, 868) and took five more hours of fixes. ## The shape One feature is **one branch name**, **one worktree per repository**, **one pull request per repository**, -opened **once**, after the review. It runs in five steps, and its time is bounded. A milestone has no phases +opened **once**, after the review, and **one check** (ADR 0548). It runs in five steps, and its time is bounded. A milestone has no phases (the operator, 2026-10-17): these are its steps, and a report names the step it is in: | Step | What happens | Bound | |---|---|---| | 0. Prepare | the lead settles the open questions and writes one context file per repository | 15 minutes | -| 1. Develop | one fixing agent per repository builds every issue locally, the whole unit suite before every commit; then each branch is pushed and tried | the milestone's issues, 30 minutes each, and one try | -| 2. Review | one reviewer reads all of it with the tries' results; reports go both ways; at most 3 rounds | 15 minutes | -| 3. Check | push the reviewed heads; a head the review changed is tried again; then the pull requests are opened and the forge's merge checks run the integration tests again; no further review | at most one more try and one check run | +| 1. Develop | one fixing agent per repository builds every issue locally, the whole unit suite before every commit, the integration tests compiled; nothing is pushed | the milestone's issues, 30 minutes each | +| 2. Review | one reviewer reads all of it, the local commits, judging the integration tests by reading them against the code; reports go both ways; at most 3 rounds | 15 minutes | +| 3. Check | push the reviewed heads once and open the pull requests together; the checker's one check runs the integration tests; no further review unless the check fails | one check run | | 4. Deliver | merge; the source revision moves, each module is built once and wanted on its nodes, its canary first | until the view says the source revision `delivered` | -**One milestone is one release** (the operator, 2026-10-17). A milestone is developed whole, tried before its review, reviewed once, -opened once and delivered once. It is never cut into steps for its size or for time: every cut adds a review, a +**One milestone is one release** (the operator, 2026-10-17). A milestone is developed whole, reviewed once, +pushed once, checked once and delivered once. It is never cut into steps for its size or for time: every cut adds a review, a merge check, an Approve and a delivery of waiting, so the fewest cuts is the fastest. Nor is it cut for an order between its parts (the operator, 2026-10-22: "a milestone is a milestone, we shouldn't cut it"): which module reaches the machines before which is the assigner's rules' (a build and a composition before the want, a provider @@ -100,7 +105,10 @@ issue whether it is being fixed in between, after the delivery, or waits, and on 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 + the knowledge base, or by asking the operator. **Read what is decided before designing** (`knowledge-base.ask`): + a question about delivery, checks or builds is most likely answered in design 47 and its decisions already (the operator, + 2026-10-26: "that is simply our delivery plan and milestones, we've already researched it"); propose new research + only for what no record decides. A fixing agent that meets an undecided design question stops, and its run is spent again. 4. **Write one context file per repository**, `.work//.context.md`. It is what a fixing agent reads instead of rediscovering the code, and it is reused by every agent and every round: @@ -112,7 +120,7 @@ issue whether it is being fixed in between, after the delivery, or waits, and on - what not to touch, and what lands beside it in other repositories; - the local facts: the worktree, the branch, the check commands, a temporary directory for tests outside the home (`TMPDIR`), and the unit tests to run (never a database server: tests that need one are - integration tests, which the try (`mesh-controller.try`) and the checker's merge check run). + integration tests, which the pull request's one check runs). When the reading is large, a read-only agent on the smaller model answers the lead's exact questions with file:line, and the lead writes the file from its answers. 5. **Write the findings into the issues** (the operator, 2026-10-17: the better the content of the issues, the @@ -165,13 +173,12 @@ issue whether it is being fixed in between, after the delivery, or waits, and on (one line for every key-value bucket key and stream the work creates or starts writing; "none created" if none) Trying the switch-over on one node first (b): - - - or: the operator chose no try on one node first, on ; what that risks: - Integration level before the pull requests (c): - - - - what no try covers: + - or: the operator chose no first trial on one node, on ; what that risks: + Integration level (c): + - + - what the check does not cover: ``` - A key or stream with no one who deletes it and no time to live is a leak and is settled before work starts. Until - issue 1921 gives a group try, answer (c) with the single-repository tries and say so. + A key or stream with no one who deletes it and no time to live is a leak and is settled before work starts. 9. **Move the issues to `fixing`**, `by` naming the feature's agent for that repository. ## Step 1 — Develop (one fixing agent per repository, smaller model) @@ -189,27 +196,27 @@ issue whether it is being fixed in between, after the delivery, or waits, and on its helper alone, and dropping the field from the request passed every test); `gofmt`, `go vet` and the whole unit suite stay green. **The tests are written from the issue's acceptance criteria**: one test or more per criterion at the level it names, each test's comment citing the criterion it proves by its label (`// 1118/AC2`), and no criterion left without its test; an integration criterion is a test - that compiles and waits for the try at this step's end. The integration tests (those that start a store, a bus - or a process) are run first by that try, and again by the checker's merge check. -- **No pull request is opened in this step. When every issue is committed, the lead brings each feature branch up - to the current trunk (fetch by name, then merge), pushes it and tries it** (`mesh-controller.try`, as step 3 item 1 says), so the review reads the integration tests' real - results and judges none by reasoning (2026-10-19: a reviewer reasoned that a warning goes out at once, the - router holds it 30 s, and the try after the review found it). A failed try goes back to the same fixing agent - with its whole log, read as step 3 item 3 says, before the review starts. Never land on a red check: run the - checks, read the result, then land in a separate step. + that compiles and is run by the pull request's one check. The integration tests (those that start a store, a bus + or a process) are compiled with `go vet -tags integration ./...` while developing and run by that check, nowhere + else. +- **Nothing is pushed and no pull request is opened in this step, and there is no try** (ADR 0548; the operator, + 2026-10-26: "every release should only run 1 check or 1 try"). When every issue is committed, the lead brings each + feature branch up to the current trunk (fetch by name, then merge) and the review reads the local commits. Never call + `mesh-controller.try` or `mesh-delivery-checker.checker_try`; one is run only when the operator asks for it. A reviewer + or a session that wants the code on the forge may push a branch that has no pull request: it runs nothing. Never land + on a red check: read the result, then land in a separate step. - **The fixing agent's brief** (the lead gives it with the context file): name your issue in every step and message ("issue 805: landing in mesh-catalog"); reach the mesh only through the mesh MCP server, never ssh; - never push, open, merge or close a pull request; never write to a store's database by hand, a schema change + never push, open, merge or close a pull request; never call a try; never write to a store's database by hand, a schema change is a numbered migration and the consolidated schema; Go only unless the context file says otherwise; never - move another issue; **leave the integration tests to the try while developing** (no `go test -tags integration`, - no store or bus started by hand): compile them with `go vet -tags integration ./...` and leave the running to - the lead's try at the end of this step, where `mesh-controller.try` runs them on the pushed branch. On 2026-10-17 three fixing agents ran them anyway, one for minutes on end, because the - brief only said they wait for the check (the operator). After a failed try or check it + move another issue; **leave the integration tests to the check** (no store or bus started by hand): compile them + with `go vet -tags integration ./...`. A single integration test may be run locally against an embedded bus when + it is the fastest way to find a cause, said in the review report and the pull request. After a failed check it usually pays to run that repository's whole integration level locally (`go test -tags integration -count=1 ./...` in each - module), by the lead or by the fixing agent on the lead's word, before another try: a verdict names only the first failed - test (issue 1921), and on 2026-10-23 R4g's faults surfaced one per try until a local run listed them all in a minute (a + module), by the lead or by the fixing agent on the lead's word, before the one more push: a verdict names only the first failed + test (issue 1921), and on 2026-10-23 R4g's faults surfaced one per run until a local run listed them all in a minute (a guideline, the operator). Report back in under 150 words: commits, tests added and that they failed first, the - check results, anything you stopped on. + local results, anything you stopped on. - **An agent that finds the code differs from its context file stops and reports** (file:line); the lead settles it, updates the context file, and continues the agent. - **Two repositories that depend on each other** keep their order in the context files: the reader before the @@ -222,11 +229,11 @@ issue whether it is being fixed in between, after the delivery, or waits, and on ## Step 2 — Review (one reviewer, larger model; at most 3 rounds, about 15 minutes) -1. **The reviewed tree is the tree that was tried**: every feature branch was brought up to the current trunk - before its push and try (step 1). A try and a merge check each run on the merge with the trunk as it is then, so a +1. **The reviewed tree is the tree that is pushed**: every feature branch was brought up to the current trunk + before the review (step 1). The check runs on the merge with the trunk as it is then, so a trunk that moves later is met by the forge's merge check, not by another merge here. Every verdict names the trunk it merged onto ("pass on "), and the lead reads that trunk against the repository's main - at once: a trunk behind main means the source revision (source.main) lags, and every check and try in that + at once: a trunk behind main means the source revision (source.main) lags, and every check in that repository is judged on it until it moves, so the operator's Approve will merge nothing. Say it then, not at the merge (issue 1726: on 2026-10-24 the gate dropped two merges it heard before it held its seat, and a reviewed, approved pull request in each of the two repositories was refused at its Approve). @@ -238,7 +245,7 @@ issue whether it is being fixed in between, after the delivery, or waits, and on It says which round it is in ("round 1 of at most 3"). 3. **The report goes to the same fixing agents** that wrote the code, continued by their ids, so they fix with the context they already hold. Each answers the reviewer: what it changed, per finding, or why not. -4. **Every new integration test is read against the code it drives and against its try.** Fixing agents only compile it, and its one run before the review is the try (step 1), which shows whether it passed but not whether it proves what it says. The reviewer traces each step of each new integration test through the code (fixtures against the manifest rules, what the store keeps and reads back, who holds a seat), and says which steps it could not trace. On 2026-10-17 a new test failed on its first two runs, on a fixture and then on a fault of the change; reading it against the code after the first failure found another fault, which would have failed a run too. The reviewer also checks that each new integration test enters through the same path the live trigger takes, not through a state it writes by hand: on 2026-10-17 milestone 4's test saved its delivery plan directly, so it skipped the cut from a batch that every live plan takes, and it passed while the backup step never ran (issue 1086). +4. **Every new integration test is read against the code it drives.** Fixing agents only compile it, and no run precedes the review (step 1), so the reviewer judges it by reading; the check that follows shows whether it passed but not whether it proves what it says. The reviewer traces each step of each new integration test through the code (fixtures against the manifest rules, what the store keeps and reads back, who holds a seat), and says which steps it could not trace. On 2026-10-17 a new test failed on its first two runs, on a fixture and then on a fault of the change; reading it against the code after the first failure found another fault, which would have failed a run too. A review that finds a fault only by reading is the cheaper run. The reviewer also checks that each new integration test enters through the same path the live trigger takes, not through a state it writes by hand: on 2026-10-17 milestone 4's test saved its delivery plan directly, so it skipped the cut from a batch that every live plan takes, and it passed while the backup step never ran (issue 1086). 5. **The reviewer reads the answers and the new commits**, and approves or reports again (step 7 says what a round may ask). After round 3 the lead stops and brings the operator what is left, with a recommendation. 6. **The reviewer reads every acceptance criterion against its test**: each criterion has a test at its level @@ -255,8 +262,7 @@ issue whether it is being fixed in between, after the delivery, or waits, and on 6a. **The reviewer reads the milestone file's three answers** (step 0, item 8) against the change: it lists every bucket key and stream the diff creates or writes (search the diff for the bucket and stream names) and finds each in the lifetime answer with a deleter and event, or a time to live; it reads the switch-over answer and checks it was done as - written or that the operator's choice is recorded; it reads the integration-level answer against the tries named - in the pull request. A missing answer, or a key or stream the diff creates that the answer omits, is a change asked. + written or that the operator's choice is recorded; it reads the integration-level answer against the check the pull requests will ask. A missing answer, or a key or stream the diff creates that the answer omits, is a change asked. 7. **A finding outside the issues' done-when and their acceptance criteria is never a change asked, in any round.** More hardening, a further case, a nicer form: the reviewer opens it with `issue-tracker.open` and names the number in its report, and the round does not wait for it. What a round asks is only what makes the change wrong against @@ -278,23 +284,24 @@ issue whether it is being fixed in between, after the delivery, or waits, and on ## Step 3 — Check (no review) -1. **Push the reviewed heads, try again a head the review changed, then open one pull request per repository, - together.** **The integration tests run before the pull requests are opened**, first before the review (step 1) - and again for a head the review changed since its try: `mesh-controller.try` with the - repository and the pushed branch is a check ask of the checker (ADR 0501 §5): the checker runs the repository's tests on the - merge with the trunk's head, at the unit and the integration level, through the build module of the repository's language and by - that language's convention, as the merge check does, and answers with an id to read back. The try is an ask on the language's check - stream (ADR 0525 §1), so it waits behind the asks before it until a build node has a free slot; no script of the repository decides - it (ADR 0445, ADR 0529). A try that fails goes to step 3 item 3 as a failed check does; the pull requests are opened only - when every head's last try passed (the operator, 2026-10-18: three pushes in a row failed their first merge check on - faults a try finds in minutes). While developing, no `go test -tags integration` or store or bus started - by hand on the machine (the operator, 2026-10-18); after a failed try, a local run of the whole level is the guideline - in step 1's brief. **Before a session trusts an agent's "pushed", it reads the forge branch's head** (`git ls-remote origin refs/heads/`) and compares it with the commit reviewed; an agent may commit on a detached HEAD and report a push that never happened (2026-10-26: the first try of a reviewed fix failed "not our ref"). The try and the pull request are started only on that read head. Pull requests in two or +1. **Push the reviewed heads once, then open one pull request per repository, together** (ADR 0548; the operator, + 2026-10-26: "every release should only run 1 check or 1 try"). **No pull request, draft or not, exists before the + review approves the heads**, and no fix round is pushed to an open pull request: every push to an open pull request + asks a new check, of every member for a group, and the mesh's build capacity is spent on it ("we don't have more + processing power"). The integration tests run once, in the checker's merge check on the merge with the trunk's head, at the unit + and the integration level, through the build module of the repository's language and by that language's convention + (ADR 0445, ADR 0529); the check waits on the language's check stream until a build node has a free slot + (ADR 0525 §1). **No try:** never call `mesh-controller.try` or `mesh-delivery-checker.checker_try`, except when the + operator asks for one. While developing, no `go test -tags integration` run of a whole level, and no store or bus started + by hand on the machine (the operator, 2026-10-18). + **A group is one check.** Before the push, every member pins the group's own mesh-sdk head exactly (the checker refuses an + older commit of the same branch), then all members are pushed and opened together, so the group's check runs once. A head the review replaces + counts for nothing against a running check; say so, and ask no other until the new head is reviewed. + **Before a session trusts an agent's "pushed", it reads the forge branch's head** (`git ls-remote origin refs/heads/`) and compares it with the commit reviewed; an agent may commit on a detached HEAD and report a push that never happened (2026-10-26: the first check of a reviewed fix failed "not our ref"). The pull request is opened only on that read head. Pull requests in two or more repositories that share the branch name are one delivery group (ADR 0239 §2). **A temporary mode that merges by hand** (the lead merges because the normal Approve and merge path is not - running): before it asks the merge, the lead runs the full integration level with nothing kept, a try with tests - `.` for each repository of the group, and names those tries (ids and verdicts) in the pull request's description. - A merge asked without them is a step skipped (research 071). + running): the pull request's one check still runs the integration level, and the lead names its verdict in the + pull request's description. A try with tests `.` is asked only when the operator asks for one, and then named there with its id and verdict (research 071). Where a session pushes through the forge tool `gitea_commit` (one commit on the forge's current base), the reviewer first confirms that commit's tree equals the reviewed one. **A large change is pushed by a pusher agent** on the smaller model: `gitea_commit` patches of about 30 KB each, a file copied from another path sent as a copy (`copy_from`) @@ -319,17 +326,20 @@ issue whether it is being fixed in between, after the delivery, or waits, and on controller's unit tests against the catalogue's branch**, because those tests read the catalogue and no check of the catalogue runs them: on 2026-10-20 mesh-catalog #381 removed the old delivery module, and every controller check failed afterwards on a test of the catalogue's subjects until issue 1406 removed the name - mesh-issues still listened to. A controller try does not find it, since a check reads the catalogue's main + mesh-issues still listened to. A controller's check does not find it, since a check reads the catalogue's main (also in a delivery group that holds the catalogue's pull request); the lead runs mesh-controller's unit suite with `MESH_CHECK_BESIDE` naming a directory that holds the catalogue's branch, as mesh-controller's `internal/beside` says. 2. **The checker's merge check runs the integration tests again, as the gate** (its one status, `mesh/check`). No second review: step 2 reviewed this tree. 3. **A check that fails** goes back to the same reviewer, continued by its id, with the failure, for **one more cycle** of step 2 with - the same fixing agents; then push once again. **The failure is read from the check's whole log**, never + the same fixing agents; then push **once** again (the one more push of ADR 0548). The check is **read, never re-asked to see if it passes**: a + check asked again without a new, reviewed head spends the build capacity for nothing. **The failure is read from the check's whole log**, never reasoned from its summary: `mesh-delivery.show` names the check's build id, and `mesh-controller.builds` with `log` set to that id prints everything the builder said. A check's summary picks only some failing lines; on 2026-10-17 it showed a store test's `FAIL` without its cause, and a fix was first guessed from the code. + **A failure the check hides or loses** (a verdict naming only the first failed test, a log not kept) is a fault of the + checking tool: it is fixed there, the same turn (instruction fix-a-bug-met-twice), not asked around. **A change to the Go build module's recipe is judged by the build module the nodes run**, not by the changed one, so a test the change adds must pass under either version. **A change that needs the new recipe to judge it ships the recipe first, as a small fix of its own**, and the rest waits for its delivery: on 2026-10-17 milestone 3 of design 47 moved its @@ -351,7 +361,7 @@ issue whether it is being fixed in between, after the delivery, or waits, and on rechecks: mesh-delivery asks the Approve on Telegram, the channel that proves who answered today (ADR 0398 §3; an Approve at the terminal is issue 953), once both checks passed, for a delivery group once for all its members, naming the review record. On the Approve it merges the approved heads, a group's in one pass - (ADR 0418). A new head ends the Approve and is asked again once its checks pass. A watcher follows the checks, + (ADR 0418). A new head ends the Approve and is asked again once its checks pass, which is why a head is pushed only after its review. A watcher follows the checks, the Approve and the merge, and wakes the lead. Beyond that Approve, the operator's word is waited for only when the milestone changes what the operator sees, removes data, or needs a step only the operator's terminal can take; the lead says which before the milestone starts. @@ -626,8 +636,13 @@ issues in `fixing` that nobody works on reads to the operator as stuck work. - A running milestone's file holds the three answers of step 0 item 8 (`cat .work//milestone.md`), and the review report says it read them (step 2, item 6a): a bucket key or stream in the diff (`git diff main -- | grep -i 'bucket\|stream'`) that the lifetime answer omits is the failure of that item (research 071). -- A pull request merged by hand in a temporary mode names, in its description on the forge (`gitea.gitea_get_pull_request`), a try with - tests `.` for each repository of the group; one without is the step 3 rule skipped. +- A pull request merged by hand in a temporary mode names, in its description on the forge (`gitea.gitea_get_pull_request`), the + verdict of its one check; a try with tests `.` is named only where the operator asked for one. +- **One release, one check** (ADR 0548): `gitea.gitea_get_pull_request` shows each pull request created after its + review record's time, and `mesh-delivery.show` shows one check per head and, for a group, one head per member; a pull + request that existed before its review approved it, a second head with no failed check before it, or a check of a + head asked more than once, is this rule skipped. A call of `mesh-controller.try` or `checker_try` that the operator + did not ask for shows in the checker's asks and is the same breach. - A milestone that adds or changes a module whose pull request has no integration test that starts the module whole is the failure of the check step's fourth item. - A bed run from `.work//mesh-lab` that fails naming a `.work///…` path it cannot find is a diff --git a/00-META/process/08-small-fixes.md b/00-META/process/08-small-fixes.md index 00e2e76e..a88b4486 100644 --- a/00-META/process/08-small-fixes.md +++ b/00-META/process/08-small-fixes.md @@ -26,14 +26,15 @@ this moment): it goes alone as a small fix, and the lead's report says why. ## The aim -A small fix spends its time on the fix, and runs the long part once: **one try before the review, one review, one check run, -one delivery**. Everything before the try is local and fast. +A small fix spends its time on the fix, and runs the long part once: **one review, one push, one check run, +one delivery** (ADR 0548; the operator, 2026-10-26: "every release should only run 1 check or 1 try"; "we don't have more +processing power"). Everything before the push is local and fast, and no try is run. ## Steps 1. **Read the issue and the code it names** (the session's own model, or one read-only agent on the smaller model answering exact questions with file:line). If a design question is open, it is settled before any - code is written: on the issue, through the knowledge base, or by the operator. A fix that turns out to + code is written: on the issue, through the knowledge base (`knowledge-base.ask` first: what is decided is read before anything is designed), or by the operator. A fix that turns out to 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. **The session's own model (the larger) then writes the issue's acceptance criteria** as playbook [07](07-feature-branches.md) step 0 item 5 says: each one sentence, given, when, then, @@ -50,30 +51,30 @@ one delivery**. Everything before the try is local and fast. caught only by the review); read `git show --stat` before pushing. The tests are written from the acceptance criteria, at least one per criterion at its level, each citing the criterion it proves by its label (`/AC`, playbook 07 step 0 item 5). Commit, naming the issue. For a playbook or design edit, run the repository's own checks (in hq, - `go test ./...` at the root). Then push the branch and run `mesh-controller.try` on it, so the review reads the - integration tests' real results; a failed try goes back to the same agent before the review. -4. **One review of the commit and its try** (a reviewer that did not write it, larger + `go test ./...` at the root). The integration tests are compiled (`go vet -tags integration ./...`) and not run: + nothing is pushed, no pull request is opened and no try (`mesh-controller.try`, `mesh-delivery-checker.checker_try`) is called, unless the operator asks for + one. A single integration test may be run locally against an embedded bus when it is the fastest way to find a cause. +4. **One review of the local commit** (a reviewer that did not write it, larger model; at most 3 rounds, as playbook 07; from round 2 only what is wrong; it reads each acceptance criterion against its test, as playbook 07 step 2 item 6; a finding outside the issue's done-when and its acceptance - criteria 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 + criteria is opened as an issue of its own, never asked as a change; it judges the integration tests by reading them against the code, as playbook 07 step 2 item 4 says). 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 Approve of its merge is its review, and the review record says so. -5. **Push the reviewed head, try it again if the review changed it, and open the pull request.** The trunk is what runs and nothing holds merged work back - (ADR 0401), so a fix waits for no other change's delivery. `mesh-controller.try` on the pushed branch runs - the integration tests, and the pull request is opened only when the head's last try passed (the pushed head is read from the forge first, as playbook [07](07-feature-branches.md) step 3 item 1 says); the checker's merge check runs - them again as the gate (playbook [07](07-feature-branches.md) step 3). A failed try or check is best run locally - first: the repository's whole integration level (`go test -tags integration -count=1 ./...` in each module) shows every - failure at once, where a verdict names only the first (issue 1921) and a try per fault costs a round each (a guideline, - the operator, 2026-10-23). The failures go back to the same agent, fixed in one change where they can be, and the - reviewer reads only the change it makes, before the next try. +5. **Push the reviewed head once and open the pull request, only after the review approves.** The trunk is what runs and nothing holds merged work back + (ADR 0401), so a fix waits for no other change's delivery. No pull request, draft or not, exists before the review + approves the head, and no fix round is pushed to an open pull request: every push to an open pull request asks a new + check. The checker's merge check runs the unit and the integration level once, as the gate (playbook [07](07-feature-branches.md) step 3); the pushed head is read from the forge first, as playbook 07 step 3 item 1 says. + A failed check is read from its whole log (never re-asked to see if it passes), then the repository's whole integration level + is run locally (`go test -tags integration -count=1 ./...` in each module) so every failure shows at once, where a verdict + names only the first (issue 1921); the failures go back to the same agent, fixed in one change, the reviewer reads only the change + it makes, and the head is pushed once more. **A temporary mode that merges by hand** (the lead merges because the normal Approve and merge path is not - running): before it asks the merge, the lead runs the full integration level with nothing kept, `mesh-controller.try` - with tests `.`, and names that try (id and verdict) in the pull request's description (research 071; playbook + running): the one check still runs, and the lead names its verdict in the pull request's description; a try with tests `.` is asked only when the operator asks for one (research 071; playbook [07](07-feature-branches.md) step 3). 6. **The pull request's description carries the review record** (`Reviewed-by: at `, playbook [07](07-feature-branches.md) step 3) and the session that pushed it (`Pushed-by: `, ADR 0505 §5), and mesh-delivery asks the operator's Approve as soon as its checks pass and merges the approved head (ADR 0421); nobody marks, labels, comments or rechecks. 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 `mesh-controller.try` and the checker's merge check + integration test starting the module whole against the real bus and store, run by the checker's one merge check (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. **A fix that depends on another pull request outside its delivery group opens only once that one is delivered**, not merely merged (members of one group open together, as playbook 07 step 3 item 1 says) (a note @@ -92,7 +93,7 @@ one delivery**. Everything before the try is local and fast. 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. -**An issue opened along the way is fixed too** (the operator, 2026-10-21). A fix's review, try or delivery that +**An issue opened along the way is fixed too** (the operator, 2026-10-21). A fix's review, check or delivery that opens an issue (a remark outside the done-when, a fault met live) leaves it to the same session to fix: right after this fix's delivery, as a small fix of its own, or folded into the next one in the same repository. It waits only when another running milestone owns it, or it needs a decision or the operator first; the report then says on what. @@ -116,9 +117,8 @@ code. | Waiting on | Bound | Past the bound | |---|---|---| | building the fix | 1 hour | it is a feature: stop and plan it under playbook 07 | -| the try | 30 minutes | a try is a check ask on the language's check stream and waits behind the asks before it for a build node's free slot (ADR 0525); past the bound, read the stream's backlog and the age of its oldest ask in the delivery view | | the review | 15 minutes | ask the reviewer where it stands | -| the merge check | 15 minutes | read `mesh-delivery.show`, the check's log and the check stream's backlog in the delivery view | +| the merge check | 30 minutes (it waits behind the asks before it for a build node's free slot, ADR 0525) | read `mesh-delivery.show`, the check's log and the check stream's backlog in the delivery view | | the Approve's ask | 5 minutes after both checks pass | read `mesh-delivery.show`: an ask not raised is a fault, said to the operator | | the merge after the Approve | 5 minutes | read `mesh-delivery.show` for the delivery | | the delivery | its class's budget (3 minutes for a leaf module, 10 for a core module), at most 30 minutes | read the view's wants page, or `assigner_wants` against `node_haves`: a want held back names its rule, a `stuck` module its words | @@ -134,8 +134,10 @@ 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 pull request was opened. -- A pull request merged by hand in a temporary mode names a try with tests `.` at its head in its description +- A pull request merged by hand in a temporary mode names the verdict of its one check in its description on the forge (`gitea.gitea_get_pull_request`); one without is the step skipped. +- One fix, one check (ADR 0548): a pull request that existed before its review approved the head, or a head whose check was + asked more than once with no new reviewed head, is steps 4 and 5 skipped; so is a `mesh-controller.try` the operator did not ask for. - Its issue moves to `resolved` within the hour the view says its source revision `delivered`. - A pull request with no review record at its head (the Approve's ask says so first), a fix to a module's running pushed with no integration test of the module whole, or a review report diff --git a/00-META/process/playbooks.html b/00-META/process/playbooks.html index 60514df4..f1c02e68 100644 --- a/00-META/process/playbooks.html +++ b/00-META/process/playbooks.html @@ -75,7 +75,7 @@ code{font:12.5px ui-monospace,monospace;background:var(--soft);padding:1px 5px;b

Novox Playbooks

-

How work is done on the mesh, from an idea or a symptom to a delivered change. Drawn from hq's 00-META/process/ at main f269e83, 2026-10-19, including playbook change hq #433 (try before the review).

+

How work is done on the mesh, from an idea or a symptom to a delivered change. Drawn from hq's 00-META/process/ at main f269e83, 2026-10-19, amended 2026-10-26 for ADR 0548 (one release, one check: no try).