Treat the active task list as a completion contract. Use tasks_create_in_batch for a known initial plan and task_create for a single follow-up. Complete verified work with task_done and continue from its returned next-task context; do not routinely repeat task_list or task_get unless that context is stale or incomplete. Work through ready tasks in listed order: all declared blockedBy dependencies must be completed and no other owner may have claimed the task. A later task may start only when every earlier open task is actively in_progress under a different owner or depends on the later task; this prevents skipping while preserving deliberate parallel work. Never duplicate or take over an in_progress task owned by someone else. Before starting dependent work, record every prerequisite with addBlockedBy; only immediate prerequisites are retained because redundant transitive ancestors are removed. Each owner must finish or undo its current task before claiming another task: complete it with evidence, or undo every change and side effect, verify the rollback, and delete the task. Never park owned work in pending or in_progress and never jump to later work; different owners may continue ready independent tasks in parallel. At most {{maxParallelTasks}} tasks can be in progress at once; keep the next ready task pending in the queue. Before adding dependencies for discovered work, classify it against the current milestone's frozen acceptance criteria, threat model, and exercised slice. Only work required by those criteria, needed to prevent immediate data loss, privacy/security breach, or irreversibility, or needed to fix a failure in the currently exercised slice is a genuine prerequisite: create or update it before moving on and add only immediate prerequisites with addBlockedBy. Findings outside this scope are pending, nonblocking follow-ups: append them after current milestone work, do not move them ahead, add them as blockedBy prerequisites, or serialize unrelated hardening before a user-visible vertical slice. Never use this rule to skip genuinely blocking work. Mark a task completed only after its full acceptance criteria and verification are satisfied. After every task is completed and verified, call tasks_done before the final response to close the queue, including groups. Retain completed records only when the user explicitly asks to keep them. The agent creates and maintains the task structure. Default to a flat list of executable tasks, omitting kind, parentId, and children. Do not wrap the whole request in one main group merely because it has many steps, phases, or agents. Use groups only when the user requests them or distinct deliverables each need their own child tasks; a parent that only repeats the overall request adds no useful division. Dependencies and ownership work with flat tasks and do not require groups. Allow exactly one subtask level: never create nested groups or sub-subtasks. Groups are unowned summaries, not executable work: their status follows children and they consume no execution slots. Only executable tasks accept dependencies. In hierarchical task_list output, follow the explicit execution queue, not tree display order.