Lane & Backlog Best Practices All Tiers
How to structure a backlog so engage can dispatch it safely: one lane per repo, phased tasks, and clean dependencies.
A "lane" is a backlog document — a markdown file with a sequence of tasks that engage dispatches. The conventions below come from how well-run lanes are actually structured in practice, not from a rulebook.
One lane, one target repo
The single most load-bearing convention: a lane targets one repo. Every task in the lane declares the same target repo and base branch up front, stated once at the top of the file rather than re-derived per task:
**Sprint ID:** T18
**Repo (run + target):** your-repo — per-task **Base:** dev
**Total: 20 Cx, 5 tasks**
**Issues this lane closes:** #123, #124, #125When a lane genuinely needs work in a different repo — a website change alongside a CLI change, say — that's a signal for a separate task with its own explicit target-repo declaration and its own verified rationale, not a silent repo-switch mid-lane. Mixing target repos inside one lane without saying so is exactly the kind of thing that turns into a hard-to-debug dispatch failure later.
Verify before you spec
A well-formed lane opens with a "verified findings" section: what's actually true in the code today, checked against a specific commit, before any task descriptions are written. This matters because specs written against stale assumptions cost more to unwind than the verification pass costs to do up front. A good verified-findings entry names the exact file, line, and function it checked — not "the parser probably handles this," but "running the parser against the exact incident file returns all 7 tasks, confirmed at backlog_parser.py:180."
The same discipline applies to architecture headroom: before assigning tasks that touch a file close to a size/complexity limit, check the current line counts and flag which files are tight. A lane that specs a feature into a file that's about to hit its error threshold is setting up a task for an avoidable failure.
Phases and dependency hygiene
Tasks in a lane declare Depends on: explicitly, and independent work says so explicitly too (Depends on: None) rather than leaving it implicit. This is what lets engage figure out real dispatch order versus stated document order — they aren't always the same thing:
| Task | Depends on | Why |
|---|---|---|
| T18.1 | None | Protects every later dispatch's parse — goes first |
| T18.2a | None | Independent of T18.1's fix |
| T18.2b | T18.2a | Needs the worktree path T18.2a introduces |
| T18.2c | T18.2a, T18.2b | Tests the combined behavior of both |
| T18.3 | None | Different target repo entirely — parallel-safe |
A task with no dependency but an implied ordering (like T18.1 needing to land first even though nothing technically blocks the others) should say so explicitly in a "Dispatch order" note, rather than relying on document order alone.
Complexity budgeting (Cx)
Each task carries a Cx (complexity) estimate and a priority (P0/P1/P2), and the lane totals them in a Delivery Summary table at the bottom. This is what makes a lane reviewable at a glance — total scope, per-task scope, and dependency shape all visible in one table before anyone reads the task bodies.
Rulings belong in the lane, not in someone's memory
When an open question gets answered by a human reviewer, the answer goes back into the lane file itself — inline where the ambiguity was, and again in a "ruled" section — rather than living only in a chat log or a comment thread. A task file is what a driver actually reads at dispatch time; a decision that only exists somewhere else doesn't reach the driver.