Playbook 06 — one feature, one branch, one MR per repo

Records the branching-and-merging workflow for code changes across the mesh
repos, written against a failure it names: branches and MRs opened per unit of
thought, treated as done when opened not merged, and named differently per repo,
so they pile up unmerged — one session left sixteen to consolidate by hand. The
rule is one feat/<slug> shared across every repo a feature touches, isolated in
.work/<slug>/<repo> worktrees off main, pushed and opened as one MR per repo only
when the whole feature is done, then merged promptly. Adds the ground-rule
pointer in AGENTS.md and the row in the process overview.

Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF
This commit is contained in:
2026-09-05 03:40:39 +02:00
parent 36936dc7a3
commit cabe873503
3 changed files with 66 additions and 2 deletions
+8 -2
View File
@@ -6,8 +6,8 @@ today almost entirely those of **Novox Mesh**, its first product ([ADR 0028](02-
Before changing anything here, read the playbooks in
[`00-META/process/`](00-META/process/) — every workflow (research, graduation, design
amendment, issues, build handoff, constitution sync) is documented there, and agents operate
through them. Thin skills in `.claude/skills/` wrap these playbooks for invocation
amendment, issues, build handoff, constitution sync, feature branches) is documented there, and
agents operate through them. Thin skills in `.claude/skills/` wrap these playbooks for invocation
(`hq-new-research`, `hq-graduate`, `hq-new-issue`, `hq-diagnose`, `hq-amend-design`,
`hq-handoff`, `hq-sync-constitution`, `hq-status`); each defers to its playbook as
authoritative and adds only the mechanical scaffolding.
@@ -31,6 +31,12 @@ authoritative and adds only the mechanical scaffolding.
constitution page is derived from it — see playbook
[`05-constitution-sync.md`](00-META/process/05-constitution-sync.md). Never edit the
derived page directly.
- **One feature, one branch, one MR per repo.** A code change spanning one or more repos uses a
single `feat/<slug>` shared across every repo it touches, isolated in `.work/<slug>/<repo>`
worktrees off `main`; push and open MRs only when the whole feature is done, then merge
promptly and delete the branch. Per-increment branches and MRs that pile up unmerged are the
failure this prevents — see playbook
[`06-feature-branches.md`](00-META/process/06-feature-branches.md).
## This repository is public