Agent worktrees live under ~/work/code/mastrix/worktrees/

operating-model/decision-log.md

@@ -40,4 +40,4 @@ Status is intentionally explicit:
 | 2026-09-28 | Confirmed | Long documents carry a table of contents with jump links | Sections with four or more `##` level headings get a TOC block right after the title. Automated tooling in projects regenerates and validates the TOC. See `working-style.md` and `agent-work-loop.md`. |
 | 2026-09-29 | Confirmed | The agent launched on a work board is a dispatcher: one fresh, clean-context sub-agent per job, one at a time, up to five jobs per run, then a full stop until a human says go. | Owner: "ideally, you want each agent to work with a clean context, then each agent is launching a sub-agent be the model then, so subagent finishes a bead and changes bead status and reports back to parent agent. parent agent at any point in only running a single sub agent. after the sub agent finished, the parent agent is lanching the next one in a loop, up to a maximum of five and then completely stop until human asks it go again for another five". The dispatcher only reads the board, claims, launches, reads the report and logs; the sub-agent does one job and makes its board transition. Refines the 2026-09-28 work-loop row: the loop and priorities stay, the agent that runs them changes. See `agent-work-loop.md` sections 2, 3, 4 and 6. |
 | 2026-09-29 | Confirmed | Projects keep their launch prompts as named, versioned files in the repo, with an index; a launch is one line naming the prompt and its path, plus parameters; the run report names the prompt version it ran. | The owner approved the lead's design ("go") for replacing pasted launch text with checked-in prompts, so a launch is repeatable and a report says which prompt version produced it. Adds to the 2026-09-29 dispatcher row. See `agent-work-loop.md` section 7. |
-| 2026-10-08 | Confirmed | The owner's cross-project rules live here in vendor-neutral words so any agent works the way the owner wants in every repository: model tiers (deep, standard, light, premium) with a vendor mapping, premium launches only on the owner's per-launch yes, ask before any new service, monitor, workflow or scheduled wakeup, never set a spend cap ($0 by default), they/them for the owner, a fresh brief for a scope change, files only under `~/work`, scratch in the harness's scratchpad or `~/work/code/mastrix/wt/<repo>-<task>-notes/`, never `/tmp`, and a vendor-neutral checkpoint procedure. | Owner, R1008-27: "n1-n8 is good", accepting decisions D1-D8 of the agent-neutrality plan as recommended, and: "any agent can work exactly like the way I want it to on the repo". Sources: the owner's rulings of 2026-09-27, 2026-10-05 and 2026-10-06 as kept in the Claude memory files. Supersedes the vendor-named tier wording of the 2026-09-21, 2026-09-23 and 2026-09-27 rows (they stay as history) and the 2026-09-27 scratch-path example. See `working-style.md` → Model tiers, `execution-and-handoffs.md` → Scratch files and agent worktrees, and `procedures/checkpoint.md`. |
+| 2026-10-08 | Confirmed | The owner's cross-project rules live here in vendor-neutral words so any agent works the way the owner wants in every repository: model tiers (deep, standard, light, premium) with a vendor mapping, premium launches only on the owner's per-launch yes, ask before any new service, monitor, workflow or scheduled wakeup, never set a spend cap ($0 by default), they/them for the owner, a fresh brief for a scope change, files only under `~/work`, scratch in the harness's scratchpad or `~/work/code/mastrix/worktrees/<repo>-<task>-notes/`, never `/tmp`, and a vendor-neutral checkpoint procedure. | Owner, R1008-27: "n1-n8 is good", accepting decisions D1-D8 of the agent-neutrality plan as recommended, and: "any agent can work exactly like the way I want it to on the repo". Sources: the owner's rulings of 2026-09-27, 2026-10-05 and 2026-10-06 as kept in the Claude memory files. Supersedes the vendor-named tier wording of the 2026-09-21, 2026-09-23 and 2026-09-27 rows (they stay as history) and the 2026-09-27 scratch-path example. See `working-style.md` → Model tiers, `execution-and-handoffs.md` → Scratch files and agent worktrees, and `procedures/checkpoint.md`. |

operating-model/execution-and-handoffs.md

@@ -269,8 +269,8 @@ description of the problem.
 | Item | Where |
 | --- | --- |
 | Files of any kind | Only under `~/work`, never `~/Desktop`, `~/Documents`, `~/Downloads`, `~/` or a `/tmp` folder you make yourself. The one exception is the scratchpad directory the harness itself provides, below. |
-| Scratch (notes, logs, PR bodies) | The harness's scratchpad directory when it gives one, in **your own subfolder** named for your task and role (e.g. `W-0012-doer/`, `PR-171-adversary/`). When it gives none: `~/work/code/mastrix/wt/<repo>-<task>-notes/`, beside the worktree. |
-| Git worktrees | `~/work/code/mastrix/wt/<repo>-<task>`, fresh from the remote's default branch, one writer per worktree, unless the harness provides the worktree. |
+| Scratch (notes, logs, PR bodies) | The harness's scratchpad directory when it gives one, in **your own subfolder** named for your task and role (e.g. `W-0012-doer/`, `PR-171-adversary/`). When it gives none: `~/work/code/mastrix/worktrees/<repo>-<task>-notes/`, beside the worktree. |
+| Git worktrees | `~/work/code/mastrix/worktrees/<repo>-<task>`, fresh from the remote's default branch, one writer per worktree, unless the harness provides the worktree. |
 
 - **Never:**
   - at the scratchpad's root, which is shared by every agent in the session;