fix session doc

docs/en/s07-task-system.md

@@ -1,36 +1,52 @@
-# s07: Tasks
+# s07: Task System
 
 `s01 > s02 > s03 > s04 > s05 > s06 | [ s07 ] s08 > s09 > s10 > s11 > s12`
 
-> *"State survives /compact"* -- file-based state outlives context compression.
+> *"Break big goals into small tasks, order them, persist to disk"* -- a file-based task graph with dependencies, laying the foundation for multi-agent collaboration.
 
 ## Problem
 
-In-memory state (TodoManager from s03) dies when context compresses (s06). After auto_compact replaces messages with a summary, the todo list is gone. The agent can only reconstruct from summary text -- lossy and error-prone.
+s03's TodoManager is a flat checklist in memory: no ordering, no dependencies, no status beyond done-or-not. Real goals have structure -- task B depends on task A, tasks C and D can run in parallel, task E waits for both C and D.
 
-File-based tasks solve this: write state to disk, and it survives compression, process restarts, and eventually multi-agent sharing (s09+).
+Without explicit relationships, the agent can't tell what's ready, what's blocked, or what can run concurrently. And because the list lives only in memory, context compression (s06) wipes it clean.
 
 ## Solution
 
+Promote the checklist into a **task graph** persisted to disk. Each task is a JSON file with status, dependencies (`blockedBy`), and dependents (`blocks`). The graph answers three questions at any moment:
+
+- **What's ready?** -- tasks with `pending` status and empty `blockedBy`.
+- **What's blocked?** -- tasks waiting on unfinished dependencies.
+- **What's done?** -- `completed` tasks, whose completion automatically unblocks dependents.
+
 ```
 .tasks/
-  task_1.json  {"id":1, "status":"completed", ...}
+  task_1.json  {"id":1, "status":"completed"}
   task_2.json  {"id":2, "blockedBy":[1], "status":"pending"}
-  task_3.json  {"id":3, "blockedBy":[2], "status":"pending"}
+  task_3.json  {"id":3, "blockedBy":[1], "status":"pending"}
+  task_4.json  {"id":4, "blockedBy":[2,3], "status":"pending"}
 
-Dependency resolution:
-+----------+     +----------+     +----------+
-| task 1   | --> | task 2   | --> | task 3   |
-| complete |     | blocked  |     | blocked  |
-+----------+     +----------+     +----------+
-     |                ^
-     +--- completing task 1 removes it from
-          task 2's blockedBy list
+Task graph (DAG):
+                 +----------+
+            +--> | task 2   | --+
+            |    | pending  |   |
++----------+     +----------+    +--> +----------+
+| task 1   |                          | task 4   |
+| completed| --> +----------+    +--> | blocked  |
++----------+     | task 3   | --+     +----------+
+                 | pending  |
+                 +----------+
+
+Ordering:     task 1 must finish before 2 and 3
+Parallelism:  tasks 2 and 3 can run at the same time
+Dependencies: task 4 waits for both 2 and 3
+Status:       pending -> in_progress -> completed
 ```
 
+This task graph becomes the coordination backbone for everything after s07: background execution (s08), multi-agent teams (s09+), and worktree isolation (s12) all read from and write to this same structure.
+
 ## How It Works
 
-1. TaskManager: one JSON file per task, CRUD with dependency graph.
+1. **TaskManager**: one JSON file per task, CRUD with dependency graph.
 
 ```python
 class TaskManager:
@@ -48,7 +64,7 @@ class TaskManager:
         return json.dumps(task, indent=2)
 ```
 
-2. Completing a task clears its ID from every other task's `blockedBy` list.
+2. **Dependency resolution**: completing a task clears its ID from every other task's `blockedBy` list, automatically unblocking dependents.
 
 ```python
 def _clear_dependency(self, completed_id):
@@ -59,7 +75,7 @@ def _clear_dependency(self, completed_id):
             self._save(task)
 ```
 
-3. `update` handles status transitions and dependency wiring.
+3. **Status + dependency wiring**: `update` handles transitions and dependency edges.
 
 ```python
 def update(self, task_id, status=None,
@@ -84,16 +100,17 @@ TOOL_HANDLERS = {
 }
 ```
 
-From s07 onward, Task is the default for multi-step work. Todo remains for quick checklists.
+From s07 onward, the task graph is the default for multi-step work. s03's Todo remains for quick single-session checklists.
 
 ## What Changed From s06
 
 | Component | Before (s06) | After (s07) |
 |---|---|---|
 | Tools | 5 | 8 (`task_create/update/list/get`) |
-| State storage | In-memory only | JSON files in `.tasks/` |
-| Dependencies | None | `blockedBy + blocks` graph |
-| Persistence | Lost on compact | Survives compression |
+| Planning model | Flat checklist (in-memory) | Task graph with dependencies (on disk) |
+| Relationships | None | `blockedBy` + `blocks` edges |
+| Status tracking | Done or not | `pending` -> `in_progress` -> `completed` |
+| Persistence | Lost on compression | Survives compression and restarts |
 
 ## Try It
 
@@ -105,4 +122,4 @@ python agents/s07_task_system.py
 1. `Create 3 tasks: "Setup project", "Write code", "Write tests". Make them depend on each other in order.`
 2. `List all tasks and show the dependency graph`
 3. `Complete task 1 and then list tasks to see task 2 unblocked`
-4. `Create a task board for refactoring: parse -> transform -> emit -> test`
+4. `Create a task board for refactoring: parse -> transform -> emit -> test, where transform and emit can run in parallel after parse`