칸반 모드를 다루는 문서와 운영 안내는 아홉 낱말을 공유해서 씁니다 — 보드, 체인, 세션 런처 안내 어디를 펴도 같은 낱말이 나온다는 뜻입니다. 이 페이지는 그 낱말을 한 곳에 모아 정의합니다. 각 항목은 정의 한 줄과 예시 하나로 이루어져 있고, 나머지 문서들은 이 뜻을 전제로 쓰여 있습니다.

가장 자주 걸리는 지점부터: 레인 (lane) 과 칸 (column) 은 다른 말입니다. 둘의 구별은 아래에서 따로 다룹니다.

보드는 다섯 칸으로 고정되어 있습니다:

flowchart TD
    Backlog["backlog — 대기열
(주인 세션 없음)"]
    Plan["plan 칸
(plan 동반 세션)"]
    Run["run 칸
(run 동반 세션)"]
    Sync["sync 칸
(sync 동반 세션 + 리뷰 판정)"]
    Done["done — 종착
(아무것도 배차되지 않음)"]
    Backlog --> Plan --> Run --> Sync --> Done

backlog와 done에는 주인 세션이 일부러 없습니다. 가운데 세 칸이 각각 동반 세션 역할 하나에 대응하기 때문에, 배차는 결정이 아니라 조회가 됩니다 — 카드가 어느 칸에 있는지만 보면 누구에게 보낼지 정해집니다. review 칸은 존재하지 않습니다: 검토 판정은 sync 게이트가 흡수하며, sync 단계가 리뷰 렌즈를 직접 돌립니다.

칸 (column) 은 일의 단계를 가리키고, 레인 (lane) 은 그 단계들을 통과하며 카드 한 장을 나르는 주체를 가리킨다. 하나는 보드 위의 정류장이고, 다른 하나는 정류장들을 지나는 노선이다.

flowchart TD
    subgraph LaneA["레인 — 카드 t0: run 세션 + worktrees/t0"]
        A0["카드 t0"] --> A1["구현과 검증은
worktrees/t0 안에서만"]
    end
    subgraph LaneB["레인 — 카드 t1: 두 번째 run 세션 + worktrees/t1"]
        B0["카드 t1"] --> B1["구현과 검증은
worktrees/t1 안에서만"]
    end

두 레인이 같은 보드에서 동시에 흐를 수 있고, 서로의 워크트리는 끝까지 침범하지 않습니다. 그래서 병렬이 안전합니다 — 어느 레인의 커밋도 다른 레인의 작업 트리로 새어 들어가지 않습니다.

낱말 전부가 한 번씩 등장하는 실제 흐름입니다:

1. 운영자가 /moai todo "rename 힌트가 낡았다"로 카드 t0을 백로그에 넣는다.
2. 리드가 큐에서 t0을 골라 plan 동반 세션에 배차한다.
3. plan 동반 세션이 SPEC을 쓰면, 리드는 증거를 직접 읽고 카드를 다음 칸으로 넘긴다.
4. run이 워크트리 .claude/worktrees/t0에서 구현한다. 브랜치는 카드 ID가 아니라 한 일을 담은 이름을 쓴다 (WT-t0이 아니라 WT-todo-queue) — 이 세션과 워크트리의 짝이 곧 레인이고, 검증도 레인 안에서 (변경이 건드릴 수 있는 테스트만) 돌아간다. 리드가 시작할 때 알려주는 a1b2c3이 런 아이디이고, 리드 세션 이름 자체는 lead다.
5. sync 칸을 같은 방식으로 지나 — sync 게이트가 리뷰 판정을 흡수해 내린다 — sync가 PR을 올리면 카드는 done에 닿는다.

이 내내 카드의 작업은 .claude/worktrees/t0 하나에서 일어납니다. 병렬로 돌던 다른 레인의 워크트리와는 끝까지 섞이지 않습니다.

• 칸반 모드 — 진입 조건, Origin-Trail Chain 설계, 체인 단계
• /moai todo — 보드에 카드를 들이는 백로그 대기열
• 하네스 엔지니어링 — 페이즈 체이닝과 관찰이 하네스 설계 위에서 어떻게 자리잡았는가