カンバンモードを扱うドキュメントと運用メモは、9つの用語を共有しています — ボード、チェーン、セッションランチャーのガイドのどこを開いても同じ言葉が出てきます。このページはそれらの用語を一箇所に集めて定義します。各項目は定義1行と例1つで構成され、他のドキュメントはこの意味を前提に書かれています。

まず最につまずきやすい点から: レーン (lane) と列 (column) は別の言葉です。この区別は以下で別セクションとして扱います。

ボードは5つの列で固定されています:

flowchart TD
    Backlog["backlog — 待ち列
(所有セッションなし)"]
    Plan["plan 列
(plan コンパニオン)"]
    Run["run 列
(run コンパニオン)"]
    Sync["sync 列
(sync コンパニオン + レビュー判定)"]
    Done["done — 終着
(ここには何もディスパッチされない)"]
    Backlog --> Plan --> Run --> Sync --> Done

backlog と done には意図的に所有セッションがいません。中央の3列がそれぞれ1つのコンパニオン役割に対応するため、ディスパッチは決定ではなく照合になります — カードがどの列にいるかを見れば、誰に送るべきかが決まります。review 列は存在しません: レビュー判定は sync ゲートが吸収し、sync 段階がレビュー・レンズを自ら回します。

列 (column) は作業の段階を指し、レーン (lane) はその段階を通ってカード1枚を運ぶ主体を指します。一方はボード上の停留所、他方は停留所を通るルートです。

flowchart TD
    subgraph LaneA["レーン — カード t0: run セッション + worktrees/t0"]
        A0["カード t0"] --> A1["実装と検証は
worktrees/t0 の中だけ"]
    end
    subgraph LaneB["レーン — カード t1: 2 番目の run セッション + worktrees/t1"]
        B0["カード t1"] --> B1["実装と検証は
worktrees/t1 の中だけ"]
    end

2つのレーンが同じボードで同時に流れても、互いのワークツリーには最後まで入り込みません。これが並行を安全にする仕組みです — どのレーンのコミットも別のレーンの作業ツリーに漏れません。

すべての用語が一度ずつ登場する実際の流れです:

1. 運営者が /moai todo "rename hint is stale" でカード t0 をバックログに入れます。
2. リードがキューから t0 を選び、plan コンパニオンにディスパッチします。
3. plan コンパニオンがSPECを書いたら、リードは自分でエビデンスを読み、カードを次の列へ進めます。
4. run がワークツリー .claude/worktrees/t0 で実装します。ブランチはカード ID ではなく、やったことを表す名前を使います (WT-t0 ではなく WT-todo-queue) — このセッションとワークツリーの組がまさにレーンで、検証もレーンの中で (変更が影響しうるテストだけ) 走ります。リードが起動時に表示する a1b2c3 がランIDで、リードセッション名そのものは lead です。
5. sync 列も同じように通り — そこで sync ゲートがレビュー判定を吸収して下します — sync がPRを出した時点でカードはdoneに到達します。

この間ずっと、カードの作業は .claude/worktrees/t0 だけで行われます。並行して走っていた別レーンのワークツリーとは最後まで混ざりません。

• カンバンモード — 参入条件、Origin-Trail Chain の設計、チェーンの段階
• /moai todo — カードをボードに載せるバックログキュー
• ハーネスエンジニアリング — フェーズチェイニングと観測がハーネス設計の上にどう載っているか