chronista-club 隔離・出荷 — 並列開発2層モデル
Core principle
並列開発で本当に要るのは「実行の隔離」だけ。
ビルド・テストが互いを壊さずに走ること — これが並列性の本体で、worktree が解く。 書き込みの帰属（どの変更がどの branch か）は、専用ブランチ + ハンク単位のコミットで足りる。
2層モデル
| 層 | 道具 | 解く問題 |
|---|---|---|
| 隔離 | worktree（小タスク = session worktree / 大タスク = VP lane） | テスト・ビルドが独立に走る |
| 出荷 | GitHub native stack（gh stack） |
依存 PR の列車。bottom merge で server-side cascading rebase |
worktree は「作業ディレクトリごと分ける」ので、隔離は構造的に保証される。 1つの作業コピーに複数スコープを同居させる方式は、テストが混合状態に対して走るため採らない。
判断ルール
小タスク（1セッションで完結） → session worktree（
EnterWorktree）。lane には紐づけない。大タスク（並列 orchestration・独立したビルド/テストが必要） → 最初から VP lane（
vp flow handoff <name> --task-spec <file|->）。 VP が worktree を native 所有する（B方針）。メイン作業中に別スコープの修正が混ざった（「ここでこのバグ直しちゃえ」） → 手は止めない。そのまま直し、コミット時に
git add -pでハンク単位に割って 別ブランチへ。混ざりを咎めず、後から割る。修正の検証・出荷を委譲したい → ブランチを push →
vp flow handoffで performer へ。performer は自分の worktree で test → PR。自分は主線タスクに留まる。依存関係のある複数 PR を出す → native stack で積む。bottom merge 後の rebase はサーバー側が面倒を見る。
アンチパターン
- ❌ 小タスクを VP lane で起こす（Stand 二重起動・port 消費・
.vp/lanes/肥大） - ❌ 大タスクを単一作業コピーで並列化する（実行隔離がない）
- ❌ 1つの作業コピーに複数スコープを同居させ、そこでのテスト結果を スコープ単体の正しさの根拠にする（単体の保証は worktree か CI の per-PR ビルドで取る）
- ❌ worktree を切ったまま放置して乱立させる（gitnexus / sem のインデックスが増える。 完了したら畳む）