diff --git a/00-META/process/07-feature-branches.md b/00-META/process/07-feature-branches.md index d4dc35f5..260fb2fa 100644 --- a/00-META/process/07-feature-branches.md +++ b/00-META/process/07-feature-branches.md @@ -125,18 +125,20 @@ never into the running one, unless it blocks the running one. after; `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 check step. The integration tests (`merge-check.sh` with the store and the - bus) wait for the check step. + that compiles while you work and runs in the one merge check before the push. - **Nothing is pushed** and no pull request is opened in this step. Never land on a red check: run the checks, 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 is a numbered migration and the consolidated schema; Go only unless the context file says otherwise; never - move another issue; **never run an integration test locally** (no `go test -tags integration`, no `merge-check.sh`, - no bus or store test run): compile them with `go vet -tags integration ./...` and leave the running to the - forge's merge check. 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). Report back in under 150 words: commits, tests added and that they failed first, the + move another issue; **run the integration tests once before every push, not while developing** (the + operator, 2026-10-18): compile them with `go vet -tags integration ./...` while you work, and before the push + run the repository's whole merge check with `mesh-controller.try` on the pushed branch (the store and bus a + pull request's check gets) or `merge-check.sh` against a throwaway store, and push only on its pass. On + 2026-10-18 three pushes in a row failed their first merge check on faults an integration run finds in a + minute (mesh-catalog #361, mesh-controller #380's stale keys, #381's 400 tests without the layout marker), + each costing a check, a fix and another check. Report back in under 150 words: commits, tests added and that they failed first, the check 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. @@ -175,8 +177,7 @@ never into the running one, unless it blocks the running one. ## Step 3 — Check (no review) 1. **Push every feature branch and open one pull request per repository, together.** - The integration tests - run only in the merge check (the operator, 2026-10-16), never before. Pull requests in two or + The integration tests ran once before the push (step 1); the merge check runs them again as the gate. Pull requests in two or more repositories that share the branch name are one delivery group (ADR 0239 §2). 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. **Each pull request's description carries diff --git a/00-META/process/08-small-fixes.md b/00-META/process/08-small-fixes.md index 23015e89..ba9f7e29 100644 --- a/00-META/process/08-small-fixes.md +++ b/00-META/process/08-small-fixes.md @@ -35,7 +35,7 @@ one delivery**. Everything before the push is local and fast. 3. **Build on a local branch** `fix/-`, in a worktree of its own branched from `main`, never in the repository's own clone, which stays on `main` (playbook [07](07-feature-branches.md), step 0, item 2). Write the test that fails today first; make the change; keep `gofmt`, `go vet` and the repository's whole unit suite green - before every commit (each test well under a second; never a merge check or a database locally: how-we-build §5, ADR 0391). + before every commit (each test well under a second; no database in the unit tests: how-we-build §5, ADR 0391); before the push the repository's merge check runs once, integration tests included, through `mesh-controller.try` or `merge-check.sh` against a throwaway store, as playbook 07 step 1 says. 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, `sh merge-check.sh`). @@ -46,9 +46,8 @@ one delivery**. Everything before the push is local and fast. 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 once 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. The forge's merge - check runs the integration tests, the only - place they run (the operator, 2026-10-16). A failed check + (ADR 0401), so a fix waits for no other change's delivery. The integration tests ran once + before the push (step 3); the forge's merge check runs them again as the gate. A failed check goes back to the same agent with the failure, and the reviewer reads only the change it makes. 6. **The pull request's description carries the review record** (`Reviewed-by: at `, playbook [07](07-feature-branches.md) step 3), and mesh-delivery asks the operator's Approve as soon as its