add worktree & up task、teammate etc

web/src/data/annotations/s07.json

@@ -30,17 +30,59 @@
       }
     },
     {
-      "id": "task-replaces-todo",
-      "title": "TaskManager Replaces TodoWrite",
-      "description": "TaskManager is the multi-agent evolution of TodoWrite. Same core concept (a list of items with statuses) but with critical additions: file persistence (survives crashes), dependency tracking (blocks/blockedBy), ownership (which agent is working on what), and multi-process safety. TodoWrite was designed for a single agent tracking its own work in memory. TaskManager is designed for a team of agents coordinating through the filesystem. The API is intentionally similar so the conceptual upgrade path is clear.",
-      "alternatives": "Keeping TodoWrite for single-agent use and adding TaskManager only for multi-agent scenarios would avoid breaking the single-agent experience. But maintaining two systems with overlapping functionality increases complexity. TaskManager is a strict superset of TodoWrite -- a single agent using TaskManager just ignores the multi-agent features.",
+      "id": "task-default-todo-coexistence",
+      "title": "Task as Course Default, Todo Still Useful",
+      "description": "TaskManager extends the Todo mental model and becomes the default workflow from s07 onward in this course. This 'default' is a course sequencing choice, not a universal runtime default claim. Both track work items with statuses, but TaskManager adds file persistence (survives crashes), dependency tracking (blocks/blockedBy), ownership fields, and multi-process coordination. Todo remains useful for short, linear, one-shot tracking where heavyweight coordination is unnecessary.",
+      "alternatives": "Using only Todo keeps the model minimal but weak for long-running or collaborative work. Using only Task everywhere maximizes consistency but can feel heavy for tiny one-off tasks. Reminder signals are omission-reduction hints, not implicit mode switches; Task/Todo choice should still come from workflow intent and available tools.",
       "zh": {
-        "title": "TaskManager 取代 TodoWrite",
-        "description": "TaskManager 是 TodoWrite 的多代理进化版。核心概念相同（带状态的项目列表），但增加了关键能力：文件持久化（崩溃后存活）、依赖追踪（blocks/blockedBy）、所有权（哪个 agent 在处理什么）、以及多进程安全。TodoWrite 为单 agent 在内存中追踪自身工作而设计。TaskManager 为代理团队通过文件系统协调而设计。API 刻意保持相似，使概念升级路径清晰。"
+        "title": "Task 为课程主线，Todo 仍有适用场景",
+        "description": "TaskManager 延续了 Todo 的心智模型，并在本课程 s07 之后成为默认主线。两者都管理带状态的任务项，但 TaskManager 增加了文件持久化（崩溃后可恢复）、依赖追踪（blocks/blockedBy）、owner 字段与多进程协作能力。Todo 仍适合短、线性、一次性的轻量跟踪。"
       },
       "ja": {
-        "title": "TaskManager が TodoWrite を置き換え",
-        "description": "TaskManager は TodoWrite のマルチエージェント進化版です。コア概念は同じ（ステータス付きの項目リスト）ですが、重要な追加があります：ファイル永続化（クラッシュ後も存続）、依存関係追跡（blocks/blockedBy）、所有権（どのエージェントが何を担当しているか）、マルチプロセス安全性。TodoWrite は単一エージェントがメモリ内で自身の作業を追跡するために設計されました。TaskManager はエージェントチームがファイルシステムを通じて連携するために設計されています。API は意図的に類似させ、概念的なアップグレードパスを明確にしています。"
+        "title": "Task を主線にしつつ Todo も併存",
+        "description": "TaskManager は Todo のメンタルモデルを拡張し、本コースでは s07 以降のデフォルトになる。どちらもステータス付き作業項目を扱うが、TaskManager にはファイル永続化（クラッシュ耐性）、依存関係追跡（blocks/blockedBy）、owner、マルチプロセス協調がある。Todo は短く直線的な単発作業では引き続き有効。"
+      }
+    },
+    {
+      "id": "task-write-discipline",
+      "title": "Durability Needs Write Discipline",
+      "description": "File persistence reduces context loss, but it does not remove concurrent-write risks by itself. Before writing task state, reload the JSON, validate expected status/dependency fields, and then save atomically. This prevents one agent from silently overwriting another agent's transition.",
+      "alternatives": "Blind overwrite writes are simpler but can corrupt coordination state under parallel execution. A database with optimistic locking would enforce stronger safety, but the course keeps file-based state for zero-dependency teaching.",
+      "zh": {
+        "title": "持久化仍需要写入纪律",
+        "description": "文件持久化能降低上下文丢失，但不会自动消除并发写入风险。写任务状态前应先重读 JSON、校验 `status/blockedBy` 是否符合预期，再原子写回，避免不同 agent 悄悄覆盖彼此状态。"
+      },
+      "ja": {
+        "title": "耐久性には書き込み規律が必要",
+        "description": "ファイル永続化だけでは並行書き込み競合は防げない。更新前に JSON を再読込し、`status/blockedBy` を検証して原子的に保存することで、他エージェントの遷移上書きを防ぐ。"
+      }
+    },
+    {
+      "id": "reminder-advisory-not-switch",
+      "title": "Reminder Is Advisory, Not a Mode Switch",
+      "description": "Reminder signals should be treated as omission-reduction hints, not as control-plane switches. Choosing Task vs Todo should come from workflow intent and currently available tools, while reminders only nudge usage when tracking appears stale.",
+      "alternatives": "Treating reminders as implicit mode selectors looks convenient, but it hides decision boundaries and makes behavior harder to reason about during long sessions.",
+      "zh": {
+        "title": "Reminder 是提示，不是模式开关",
+        "description": "Reminder 信号用于降低遗漏，不应当被当作控制面的模式切换器。Task/Todo 的选择应由工作流意图与可用工具决定，提醒只在追踪滞后时提供轻量提示。"
+      },
+      "ja": {
+        "title": "Reminder は助言でありモード切替ではない",
+        "description": "Reminder は取りこぼしを減らすための助言であり、制御面のモード切替として扱わない。Task/Todo の選択はワークフロー意図と利用可能ツールで決め、Reminder は追跡が滞ったときに軽く促す。"
+      }
+    },
+    {
+      "id": "todo-task-fast-matrix",
+      "title": "Todo/Task Fast Decision Matrix",
+      "description": "Use Todo for short one-session linear checklists. Use Task for cross-session work, dependencies, or teammate coordination. If uncertain, start with Task because downscoping is cheaper than migrating state mid-run.",
+      "alternatives": "Always using Todo keeps the model minimal but breaks durability and collaboration. Always using Task maximizes consistency but may feel heavy for tiny one-shot notes.",
+      "zh": {
+        "title": "Todo/Task 快速判定矩阵",
+        "description": "短时单会话线性清单用 Todo；跨会话、依赖、多人协作用 Task；拿不准时先用 Task，因为后续降级比半途迁移状态更便宜。"
+      },
+      "ja": {
+        "title": "Todo/Task クイック判定マトリクス",
+        "description": "短い単一セッションの直線タスクは Todo、セッション跨ぎや依存・協調がある作業は Task。迷うなら Task 開始が安全で、後で簡略化する方が途中移行より低コスト。"
       }
     }
   ]

web/src/data/annotations/s12.json

@@ -0,0 +1,103 @@
+{
+  "version": "s12",
+  "decisions": [
+    {
+      "id": "shared-board-isolated-lanes",
+      "title": "Shared Task Board + Isolated Execution Lanes",
+      "description": "The task board remains shared and centralized in `.tasks/`, while file edits happen in per-task worktree directories. This separation preserves global visibility (who owns what, what is done) without forcing everyone to edit inside one mutable directory. Coordination stays simple because there is one board, and execution stays safe because each lane is isolated.",
+      "alternatives": "A single shared workspace is simpler but causes edit collisions and mixed git state. Fully independent task stores per lane avoid collisions but lose team-level visibility and make planning harder.",
+      "zh": {
+        "title": "共享任务板 + 隔离执行通道",
+        "description": "任务板继续集中在 `.tasks/`，而文件改动发生在按任务划分的 worktree 目录中。这样既保留了全局可见性（谁在做什么、完成到哪），又避免所有人同时写同一目录导致冲突。协调层简单（一个任务板），执行层安全（多条隔离通道）。"
+      },
+      "ja": {
+        "title": "共有タスクボード + 分離実行レーン",
+        "description": "タスクボードは `.tasks/` に集約しつつ、実際の編集はタスクごとの worktree ディレクトリで行う。これにより全体の可視性（担当と進捗）を維持しながら、単一ディレクトリでの衝突を回避できる。調整は1つのボードで単純化され、実行はレーン分離で安全になる。"
+      }
+    },
+    {
+      "id": "index-file-lifecycle",
+      "title": "Explicit Worktree Lifecycle Index",
+      "description": "`.worktrees/index.json` records each worktree's name, path, branch, task_id, and status. This makes lifecycle state inspectable and recoverable even after context compression or process restarts. The index also provides a deterministic source for list/status/remove operations.",
+      "alternatives": "Relying only on `git worktree list` removes local bookkeeping but loses task binding metadata and custom lifecycle states. Keeping all state only in memory is simpler in code but breaks recoverability.",
+      "zh": {
+        "title": "显式 worktree 生命周期索引",
+        "description": "`.worktrees/index.json` 记录每个 worktree 的名称、路径、分支、task_id 与状态。即使上下文压缩或进程重启，这些生命周期状态仍可检查和恢复。它也为 list/status/remove 提供了确定性的本地数据源。"
+      },
+      "ja": {
+        "title": "明示的な worktree ライフサイクル索引",
+        "description": "`.worktrees/index.json` に name/path/branch/task_id/status を記録することで、コンテキスト圧縮やプロセス再起動後も状態を追跡できる。list/status/remove の挙動もこの索引を基準に決定できる。"
+      }
+    },
+    {
+      "id": "lane-cwd-routing-and-reentry-guard",
+      "title": "Lane-Scoped CWD Routing + Re-entry Guard",
+      "description": "This course runtime uses lane-scoped cwd routing (`worktree_run(name, command)`). Other runtimes may choose session-level cwd switches. The design goal is predictable lane context with a re-entry guard when already inside an active worktree context.",
+      "alternatives": "Global cwd mutation is easy to implement but can leak context across parallel work. Allowing silent re-entry makes lifecycle ownership ambiguous and complicates teardown behavior.",
+      "zh": {
+        "title": "按通道 cwd 路由 + 禁止重入",
+        "description": "本课程运行时采用按通道 `cwd` 路由（`worktree_run(name, command)`）。其他运行时也可能选择会话级 cwd 切换。设计目标是让并行通道可预测，并在已处于 active worktree 上下文时通过重入保护避免二次进入。"
+      },
+      "ja": {
+        "title": "レーン単位 cwd ルーティング + 再入防止",
+        "description": "本コース実装では `worktree_run(name, command)` によるレーン単位 cwd ルーティングを採用する。実装によってはセッション単位で cwd を切り替える場合もある。狙いは並列レーンの予測可能性を保ち、active な worktree 文脈での再入を防ぐこと。"
+      }
+    },
+    {
+      "id": "event-stream-observability",
+      "title": "Append-Only Lifecycle Event Stream",
+      "description": "Lifecycle events are appended to `.worktrees/events.jsonl` (`worktree.create.*`, `worktree.remove.*`, `task.completed`). This turns hidden transitions into queryable records and makes failures explicit (`*.failed`) instead of silent.",
+      "alternatives": "Relying only on console logs is lighter but fragile during long sessions and hard to audit. A full event bus infrastructure is powerful but heavier than needed for this teaching baseline.",
+      "zh": {
+        "title": "追加式生命周期事件流",
+        "description": "生命周期事件写入 `.worktrees/events.jsonl`（如 `worktree.create.*`、`worktree.remove.*`、`task.completed`）。这样状态迁移可查询、可追踪，失败也会以 `*.failed` 显式暴露，而不是静默丢失。"
+      },
+      "ja": {
+        "title": "追記型ライフサイクルイベント",
+        "description": "ライフサイクルイベントを `.worktrees/events.jsonl` に追記する（`worktree.create.*`、`worktree.remove.*`、`task.completed` など）。遷移が可観測になり、失敗も `*.failed` として明示できる。"
+      }
+    },
+    {
+      "id": "hook-style-extension",
+      "title": "Hook-Style Extensions via Event Triplets",
+      "description": "Treat `before/after/failed` lifecycle emissions as extension points. Keep source-of-truth state writes in task/worktree files, and run side effects (audit, notification, policy checks) in event consumers.",
+      "alternatives": "Embedding every side effect directly in create/remove logic couples concerns tightly and makes failure handling harder. Moving source-of-truth to event replay is also risky without strict idempotency/repair semantics.",
+      "zh": {
+        "title": "通过三段事件实现 Hook 风格扩展",
+        "description": "把 `before/after/failed` 生命周期事件当作扩展插槽。真实状态写入仍留在 task/worktree 文件，审计、通知、策略检查等副作用交给事件消费者。"
+      },
+      "ja": {
+        "title": "三段イベントによる Hook 風拡張",
+        "description": "`before/after/failed` ライフサイクルイベントを拡張ポイントとして使う。正準状態は task/worktree ファイルに残し、副作用（監査・通知・ポリシーチェック）はイベント購読側で処理する。"
+      }
+    },
+    {
+      "id": "task-worktree-closeout",
+      "title": "Close Task and Workspace Together",
+      "description": "`worktree_remove(..., complete_task=true)` allows a single closeout step: remove the isolated directory and mark the bound task completed. In this course model, closeout remains an explicit tool-driven transition (`worktree_keep` / `worktree_remove`) rather than hidden automatic cleanup. This reduces dangling state where a task says done but its temporary lane remains active (or the reverse).",
+      "alternatives": "Keeping closeout fully manual gives flexibility but increases operational drift. Fully automatic removal on every completion risks deleting a workspace before final review.",
+      "zh": {
+        "title": "任务与工作区一起收尾",
+        "description": "`worktree_remove(..., complete_task=true)` 允许在一个动作里完成收尾：删除隔离目录并把绑定任务标记为 completed。在本课程模型里，收尾保持为显式工具驱动迁移（`worktree_keep` / `worktree_remove`），而不是隐藏的自动清理。这样可减少状态悬挂（任务已完成但临时工作区仍活跃，或反过来）。"
+      },
+      "ja": {
+        "title": "タスクとワークスペースを同時にクローズ",
+        "description": "`worktree_remove(..., complete_task=true)` により、分離ディレクトリ削除とタスク完了更新を1ステップで実行できる。本コースのモデルでは、クローズ処理は `worktree_keep` / `worktree_remove` の明示ツール遷移として扱い、暗黙の自動清掃にはしない。完了済みタスクに未回収レーンが残る、といったズレを減らせる。"
+      }
+    },
+    {
+      "id": "event-stream-side-channel",
+      "title": "Event Stream Is Observability Side-Channel",
+      "description": "Lifecycle events improve auditability, but the source of truth remains task/worktree state files. Events should be read as transition traces, not as a replacement state machine.",
+      "alternatives": "Using logs alone hides structured transitions; using events as the only state source risks drift when replay/repair semantics are undefined.",
+      "zh": {
+        "title": "事件流是观测旁路，不是状态机替身",
+        "description": "生命周期事件提升可审计性，但真实状态源仍是任务/工作区状态文件。事件更适合做迁移轨迹，而不是替代主状态机。"
+      },
+      "ja": {
+        "title": "イベントは観測サイドチャネルであり状態機械の代替ではない",
+        "description": "ライフサイクルイベントは監査性を高めるが、真の状態源は task/worktree 状態ファイルのまま。イベントは遷移トレースとして扱い、主状態機械の代替にしない。"
+      }
+    }
+  ]
+}