Lanes

Lanes: the coordinator/lane model

This describes how parallel work gets done on enumeratio without stepping on itself: a small number of coordinator sessions each dispatch bounded, file-scoped lanes of work to subagents, track them in a shared ledger, and land them through normal pull requests. It documents the model and its rules, not any particular session's history.

Roles

• Coordinators are long-running sessions (tagged, e.g., A, B) that own a slice of the backlog, dispatch lanes, watch for conflicts, and hold the merge queue.
• Lanes are a coordinator's unit of dispatch: one bounded piece of work, given to a subagent, scoped to a set of file globs so two lanes can run at once without touching the same files.
• The maintainer approves upstream submissions, rules on open design questions, and reviews landed work after the fact (see "Review", below).

The ledger

The ledger lives in the git common directory, under a lanes/ folder — visible from every worktree, never tracked in the repository itself, and it survives a worktree being removed. It holds:

• One JSON file per lane (<lane-id>.json), owned and edited only by the coordinator that created it: id, coordinator, owner, branch, base, the file-glob boundary, any shared paths, a status (planned | active | review | landing | landed | no-op | blocked), the PR, and a last-updated time. Lane ids are prefixed by coordinator tag so they never collide across coordinators.
• A LANDING mutex directory. A coordinator takes it by creating the directory (atomic) and recording who's holding it; only the holder merges; it's removed once the merge is done and the base branch is green.
• log.md, an append-only line per event: timestamp, coordinator, lane id, event. The ledger — not a chat message — is the source of truth; messages between coordinators are just nudges.
• BACKLOG.md, out-of-scope findings from any session (see below).
• REVIEW.md, a running list of landed, user-visible features for the maintainer to review after the fact (see below).

Rules

1. Before dispatching a lane, a coordinator reads every lane file that isn't landed or no-op. If the new lane's file-glob boundary overlaps one already active, it either narrows its own boundary or coordinates with the other coordinator first.
2. A coordinator claims a lane by writing its lane file before spawning the subagent.
3. Some generated files are legitimately touched by more than one lane at once (data tables, crosswalks, naming tables). Regeneration happens once, done by whoever holds LANDING for the last lane of a batch that touched them.
4. Merging to the base branch happens only through a pull request, only while holding LANDING, and a lane rebases onto the base branch right before taking LANDING — never mid-flight.
5. A coordinator never removes a worktree, branch, or dev server that another coordinator's lane file names as its own.
6. Coordinators ping each other over direct messages as a nudge only; the ledger, not the message, is authoritative.

Heavy jobs

Some jobs (large kernel/oracle scans, full-repo sweeps, whole-monorepo builds) are heavy enough that only one may run machine-wide at a time. A coordinator takes the HEAVY lock the same way as LANDING (create the directory, record the holder and job, remove it when done) before starting one, and runs it itself in a background shell — subagents never run heavy jobs directly.

Where subagents run

The default is a remote/cloud execution mode: a subagent pushes its branch and never opens a pull request itself — the coordinator reviews the diff and opens the PR. Work is kept local only when it genuinely needs something local (a locally licensed tool, a heavy scan, a running dev server for interactive verification). Local subagents each get their own worktree, cleaned up once the subagent has reported done.

Merging convention

Merges squash to one commit with an explicit, clean title and body — never the default generated body, since that carries co-author trailers and can carry generator/attribution lines picked up along the way. No commit, PR title, PR description, or code-review comment in this project carries any "generated by" or "co-authored by" marker of any kind, from any tool. The person landing a PR checks the final commit message before moving on.

Review backlog

Rather than reviewing every commit as it lands, the maintainer reviews landed, user-visible work in batches from REVIEW.md: every landed feature gets one entry with a precise link to the exact place to look (an anchor to the specific example or section, not just the page) — a preview build before it reaches the production site, the production site once merged. New entries go at the top. The maintainer's feedback is written back into the same file under its own heading, and coordinators read and act on it.

Backlog conventions

Work that turns up out of scope of whatever a session was actually doing — a bug spotted in passing, a design gap, a slow test — doesn't become a one-off task chip; it goes to BACKLOG.md instead, where a coordinator can schedule it deliberately. Conventions:

• Each item is BL-<n>, with a title, who found it, the date, an owner (a coordinator tag, or a specific ongoing effort), a status, and a self-contained dispatch prompt — everything a fresh subagent, with no memory of the finding session, needs to reproduce and fix it: file paths, the reproduction, the relevant design docs to read first, and what "done" looks like (tests, a branch, a PR, no attribution).
• Status is free text but tends to read as: open, in flight (with an owner and often a lane id), fixed/done (with the landing PR), closed (with the maintainer's ruling, when the "fix" turns out to be "keep current behavior").
• An item marked as needing the maintainer's call waits for his decision before any lane starts on it.
• Items judged to be roadmap-shaped rather than bug-shaped graduate to Roadmap instead of staying as backlog line items.

Memory and machine load

Because several coordinators and subagents can be active on one machine at once, the model treats memory pressure — not swap usage, which macOS keeps stale long after pressure clears — as the signal. A coordinator watches for pressure changes and processes that are unusually large or growing quickly, and responds by asking the owning session to scale back rather than killing anything out from under it. Anything that looks intrinsically heavy (a benchmark, a profiling run, an exhaustive sweep) is expected to cap its own memory use and refuse to start when pressure is already elevated. Heavy work prefers a remote/cloud session when one is available, precisely so it has zero effect on the shared machine.