Skip to content
LumenFlow

Lanes

Lanes are parallel work streams that organize work by domain and prevent overload through WIP (Work-in-Progress) limits.

Why Lanes?

Section titled “Why Lanes?”

Without lanes:

  • Everything competes for attention
  • Context switching kills productivity
  • Bottlenecks form unpredictably

With lanes:

  • Work is organized by domain
  • Each lane has focused attention
  • WIP limits prevent overload

Defining Lanes

Section titled “Defining Lanes”
.lumenflow.config.yaml
lanes:
  - name: Core
    wip_limit: 1
    code_paths:
      - src/core/**
      - src/domain/**


  - name: UI
    wip_limit: 1
    code_paths:
      - src/components/**
      - src/pages/**


  - name: Infrastructure
    wip_limit: 1
    code_paths:
      - infra/**
      - .github/**


  - name: Documentation
    wip_limit: 1
    code_paths:
      - docs/**

WIP Limits

Section titled “WIP Limits”

WIP (Work-in-Progress) limits enforce one active WU per lane (WIP=1). This prevents:

  • Context switching between multiple incomplete tasks
  • Merge conflicts from parallel work in the same domain
  • “Started but not finished” pile-ups

Current behavior: WIP=1 is enforced for all lanes. Attempting to claim a WU in an occupied lane will be blocked.

Parallel work: Use multiple lanes to work in parallel. Each lane can have one active WU, enabling concurrent work across different domains.

Why WIP=1 Matters

Section titled “Why WIP=1 Matters”
High WIP (anti-pattern):
→ Multiple things started, none finished
→ Context switching overhead
→ Long cycle times
→ Merge conflicts


WIP=1 (LumenFlow default):
→ Finish one thing
→ Start the next
→ Steady flow
→ Clean merges

Lane Selection

Section titled “Lane Selection”

When claiming a WU, specify the lane:

Terminal window
pnpm wu:claim --id WU-042 --lane UI

The WU spec should already have a lane assignment:

WU-042.yaml
id: WU-042
title: Add email validation
lane: UI # ← Lane defined in spec

Auto-Detection via Paths

Section titled “Auto-Detection via Paths”

LumenFlow can auto-detect lanes based on file paths:

lanes:
  - name: Core
    paths:
      - src/core/**

If a WU’s code_paths match, it’s assigned to that lane.

Multiple Lanes

Section titled “Multiple Lanes”

A WU should belong to one lane. If work spans multiple domains:

  1. Split the WU – One WU per lane
  2. Choose primary – Assign to the most affected lane

Example: Feature Spanning UI + Core

Section titled “Example: Feature Spanning UI + Core”

Instead of one WU: ❌ “Add user preferences (UI + API + DB)”

Split into: ✅ WU-100: “Add preferences API” (lane: Core) ✅ WU-101: “Add preferences UI” (lane: UI) ✅ WU-102: “Add preferences schema” (lane: Infrastructure)

Visualizing Lanes

Section titled “Visualizing Lanes”

The status file shows lane state:

# Status


## 🔧 In Progress


- [WU-101 — Add preferences UI](wu/WU-101.yaml) (lane: UI)
- [WU-100 — Add preferences API](wu/WU-100.yaml) (lane: Core)


## 🚀 Ready


- [WU-103 — Add dark mode toggle](wu/WU-103.yaml) (lane: UI) ← blocked (UI lane occupied)
- [WU-104 — Add export feature](wu/WU-104.yaml) (lane: Infrastructure) ← can claim


## ⛔ Blocked


(none)

Note: WU-103 cannot be claimed because UI lane already has WU-101 in progress.

Next Steps

Section titled “Next Steps”