cc-viewer 1.6.182 → 1.6.183

package/concepts/en/Tool-TaskList.md

@@ -1,56 +1,62 @@
 # TaskList
 
-## Definition
+Returns every task in the current team (or session) in summarised form. Use it to survey outstanding work, decide what to pick up next, and avoid creating duplicates.
 
-Lists all tasks in the task list to view overall progress and available work.
+## When to Use
+
+- At the start of a session to see what is already tracked.
+- Before calling `TaskCreate`, to confirm the work is not already captured.
+- When deciding which task to claim next as a teammate or subagent.
+- To verify dependency relationships across the team at a glance.
+- Periodically during long sessions to re-sync with teammates who may have claimed, completed, or added tasks.
+
+`TaskList` is read-only and cheap; call it freely whenever you need an overview.
 
 ## Parameters
 
-No parameters.
+`TaskList` takes no parameters. It always returns the full task set for the active context.
 
-## Return Content
+## Response Shape
 
-Summary information for each task:
-- `id` — Task identifier
-- `subject` — Short description
-- `status` — Status: `pending`, `in_progress`, or `completed`
-- `owner` — Owner (agent ID), empty means unassigned
-- `blockedBy` — List of incomplete task IDs blocking this task
+Each task in the list is a summary, not the full record. Expect roughly:
 
-## Use Cases
+- `id` — stable identifier for use with `TaskGet` / `TaskUpdate`.
+- `subject` — short imperative title.
+- `status` — one of `pending`, `in_progress`, `completed`, `deleted`.
+- `owner` — agent or teammate handle, or empty when unclaimed.
+- `blockedBy` — array of task IDs that must complete first.
 
-**Good for:**
-- Viewing available tasks (status is pending, no owner, not blocked)
-- Checking overall project progress
-- Finding blocked tasks
-- Finding the next task after completing one
+For the full description, acceptance criteria, or metadata of a specific task, follow up with `TaskGet`.
 
-## Notes
+## Examples
 
-- Prefer processing tasks in ID order (lowest ID first), as earlier tasks usually provide context for later ones
-- Tasks with `blockedBy` cannot be claimed until dependencies are resolved
-- Use TaskGet to get full details of a specific task
+### Example 1
 
-## Original Text
+Quick status check.
 
-<textarea readonly>Use this tool to list all tasks in the task list.
+```
+TaskList()
+```
 
-## When to Use This Tool
+Scan the output for anything `in_progress` without an `owner` (stale work) and anything `pending` with an empty `blockedBy` (ready to pick up).
 
-- To see what tasks are available to work on (status: 'pending', no owner, not blocked)
-- To check overall progress on the project
-- To find tasks that are blocked and need dependencies resolved
-- After completing a task, to check for newly unblocked work or claim the next available task
-- **Prefer working on tasks in ID order** (lowest ID first) when multiple tasks are available, as earlier tasks often set up context for later ones
+### Example 2
 
-## Output
+Teammate picking the next task.
 
-Returns a summary of each task:
-- **id**: Task identifier (use with TaskGet, TaskUpdate)
-- **subject**: Brief description of the task
-- **status**: 'pending', 'in_progress', or 'completed'
-- **owner**: Agent ID if assigned, empty if available
-- **blockedBy**: List of open task IDs that must be resolved first (tasks with blockedBy cannot be claimed until dependencies resolve)
+```
+TaskList()
+# Filter to: status == pending AND blockedBy is empty AND owner is empty.
+# Among those, prefer the lower ID (tasks are typically numbered in
+# creation order, so lower IDs are older and usually higher priority).
+TaskGet(taskId: "<chosen id>")
+TaskUpdate(taskId: "<chosen id>", status: "in_progress", owner: "<your handle>")
+```
+
+## Notes
 
-Use TaskGet with a specific task ID to view full details including description and comments.
-</textarea>
+- Teammate heuristic: when multiple `pending` tasks are unblocked and unowned, pick the lowest ID. This keeps work FIFO and avoids two agents grabbing the same high-profile task.
+- Respect `blockedBy`: do not start a task whose blockers are still `pending` or `in_progress`. Work the blocker first or coordinate with its owner.
+- `TaskList` is the only discovery mechanism for tasks. There is no search; if the list is long, scan structurally (by status, then by owner).
+- Deleted tasks may still appear in the list with status `deleted` for traceability. Ignore them for planning purposes.
+- The list reflects the live state of the team, so teammates may add or claim tasks between calls. Re-list before claiming if time has passed.

package/concepts/en/Tool-TaskOutput.md

@@ -1,40 +1,50 @@
 # TaskOutput
 
-## Definition
+Fetches the accumulated output of a running or completed background task — a background shell command, a local agent, or a remote session. Use it when you need to inspect what a long-running task has produced so far.
 
-Gets the output of a running or completed background task. Applicable to background shells, async agents, and remote sessions.
+## When to Use
+
+- A remote session (for example a cloud sandbox) is running and you need its stdout.
+- A local agent was dispatched in the background and you want partial progress before it returns.
+- A background shell command has been running long enough that you want to check on it without stopping it.
+- You need to confirm a background task is actually making progress before waiting longer or calling `TaskStop`.
+
+Do not reach for `TaskOutput` reflexively. For most background work there is a more direct path — see the notes below.
 
 ## Parameters
 
-| Parameter | Type | Required | Description |
-|-----------|------|----------|-------------|
-| `task_id` | string | Yes | Task ID |
-| `block` | boolean | Yes | Whether to block and wait for task completion, default `true` |
-| `timeout` | number | Yes | Maximum wait time in milliseconds, default 30000, max 600000 |
+- `task_id` (string, required): The task identifier returned when the background work was started. Not the same as a task-list `taskId`; this is the runtime handle for the specific execution.
+- `block` (boolean, optional): When `true` (default), wait until the task produces new output or finishes before returning. When `false`, return immediately with whatever is buffered.
+- `timeout` (number, optional): Maximum milliseconds to block before returning. Only meaningful when `block` is `true`. Default `30000`, maximum `600000`.
 
-## Use Cases
+## Examples
 
-**Good for:**
-- Checking the progress of background agents launched via Task (`run_in_background: true`)
-- Getting the execution results of background Bash commands
-- Waiting for async tasks to complete and retrieving output
+### Example 1
 
-**Not good for:**
-- Foreground tasks — foreground tasks return results directly, no need for this tool
+Peek at a remote session without blocking.
 
-## Notes
+```
+TaskOutput(task_id: "sess_01HXYZ...", block: false)
+```
+
+Returns whatever stdout/stderr has been produced since the task started (or since your last `TaskOutput` call, depending on the runtime).
 
-- `block: true` blocks until the task completes or times out
-- `block: false` is for non-blocking checks of the current status
-- Task IDs can be found via the `/tasks` command
-- Applicable to all task types: background shells, async agents, remote sessions
+### Example 2
 
-## Original Text
+Wait briefly for a local agent to emit more output.
+
+```
+TaskOutput(
+  task_id: "agent_01ABCD...",
+  block: true,
+  timeout: 10000
+)
+```
+
+## Notes
 
-<textarea readonly>- Retrieves output from a running or completed task (background shell, agent, or remote session)
-- Takes a task_id parameter identifying the task
-- Returns the task output along with status information
-- Use block=true (default) to wait for task completion
-- Use block=false for non-blocking check of current status
-- Task IDs can be found using the /tasks command
-- Works with all task types: background shells, async agents, and remote sessions</textarea>
+- Background bash commands: `TaskOutput` is effectively deprecated for this use case. When you start a background shell task the result already includes the path to its output file — read that path directly with the `Read` tool. `Read` gives you random access, line offsets, and a stable view; `TaskOutput` does not.
+- Local agents (the `Agent` tool dispatched in the background): when the agent finishes, the `Agent` tool result already contains its final response. Use that directly. Do not `Read` the symlinked transcript file — it contains the full tool-call stream and will overflow the context window.
+- Remote sessions: `TaskOutput` is the correct and often only way to stream back output. Prefer `block: true` with a modest `timeout` over tight polling loops.
+- An unknown `task_id`, or a task whose output has been garbage-collected, returns an error. Re-dispatch the work if you still need it.
+- `TaskOutput` does not stop the task. Use `TaskStop` to terminate.

package/concepts/en/Tool-TaskStop.md

@@ -1,32 +1,45 @@
 # TaskStop
 
-## Definition
+Stops a running background task — a shell command, a dispatched agent, or a remote session — by its runtime handle. Use it to reclaim resources, cancel work that is no longer useful, or recover when a task is stuck.
 
-Stops a running background task.
+## When to Use
+
+- A background shell command has run longer than expected and you no longer need its result.
+- A local agent is looping or stalled and needs to be cut short.
+- The user changed direction and background work for the previous direction should be abandoned.
+- A remote session is about to time out or is holding a resource you need.
+- You need a clean slate before starting a new run of the same task.
+
+Prefer letting short-lived background work finish on its own. `TaskStop` is for cases where continued execution has no value or is actively harmful.
 
 ## Parameters
 
-| Parameter | Type | Required | Description |
-|-----------|------|----------|-------------|
-| `task_id` | string | No | The background task ID to stop |
-| `shell_id` | string | No | Deprecated, use `task_id` instead |
+- `task_id` (string, required): The runtime handle returned when the background task was started. This is the same identifier accepted by `TaskOutput`, not a task-list `taskId`.
 
-## Use Cases
+## Examples
 
-**Good for:**
-- Terminating long-running tasks that are no longer needed
-- Canceling erroneously started background tasks
+### Example 1
 
-## Notes
+Stop a runaway background shell command.
+
+```
+TaskStop(task_id: "bash_01HXYZ...")
+```
 
-- Returns a success or failure status
-- The `shell_id` parameter is deprecated; use `task_id` instead
+The command receives a terminate signal; buffered output written so far remains readable at its output path.
 
-## Original Text
+### Example 2
+
+Cancel a dispatched agent after a user course-correction.
+
+```
+TaskStop(task_id: "agent_01ABCD...")
+```
+
+## Notes
 
-<textarea readonly>
-- Stops a running background task by its ID
-- Takes a task_id parameter identifying the task to stop
-- Returns a success or failure status
-- Use this tool when you need to terminate a long-running task
-</textarea>
+- `TaskStop` requests termination; it does not guarantee instantaneous shutdown. Well-behaved tasks exit promptly, but a process doing blocking I/O may take a moment to unwind.
+- Stopping a task does not delete its output. For background shell tasks, the output file on disk is preserved and still readable with `Read`. For agents and sessions, whatever output was captured before the stop is still accessible via `TaskOutput`.
+- An unknown `task_id`, or a task that has already finished, returns an error or a no-op. This is safe — you can call `TaskStop` defensively without checking status first.
+- If you intend to restart the same work, stop the old task before dispatching the new one to avoid two parallel runs racing on shared resources (files, ports, database rows).
+- `TaskStop` does not affect entries in the team task list. To cancel a tracked task, update its status to `deleted` with `TaskUpdate`.

package/concepts/en/Tool-TaskUpdate.md

@@ -1,123 +1,70 @@
 # TaskUpdate
 
-## Definition
+Modifies an existing task — its status, content, ownership, metadata, or dependency edges. This is how tasks progress through their lifecycle and how work is handed off between Claude Code, teammates, and subagents.
 
-Updates the status, content, or dependencies of a task in the task list.
+## When to Use
+
+- Transitioning a task through the status workflow as you work on it.
+- Claiming a task by assigning yourself (or another agent) as `owner`.
+- Refining the `subject` or `description` once you learn more about the problem.
+- Recording newly discovered dependencies with `addBlocks` / `addBlockedBy`.
+- Attaching structured `metadata` such as external ticket IDs or priority hints.
 
 ## Parameters
 
-| Parameter | Type | Required | Description |
-|-----------|------|----------|-------------|
-| `taskId` | string | Yes | The task ID to update |
-| `status` | enum | No | New status: `pending` / `in_progress` / `completed` / `deleted` |
-| `subject` | string | No | New title |
-| `description` | string | No | New description |
-| `activeForm` | string | No | Present continuous text displayed when in progress |
-| `owner` | string | No | New task owner (agent name) |
-| `metadata` | object | No | Metadata to merge (set to null to delete a key) |
-| `addBlocks` | string[] | No | List of task IDs blocked by this task |
-| `addBlockedBy` | string[] | No | List of prerequisite task IDs blocking this task |
+- `taskId` (string, required): The task to modify. Obtain from `TaskList` or `TaskCreate`.
+- `status` (string, optional): One of `pending`, `in_progress`, `completed`, `deleted`.
+- `subject` (string, optional): Replacement imperative title.
+- `description` (string, optional): Replacement detailed description.
+- `activeForm` (string, optional): Replacement present-continuous spinner text.
+- `owner` (string, optional): Agent or teammate handle taking responsibility for the task.
+- `metadata` (object, optional): Metadata keys to merge into the task. Set a key to `null` to delete it.
+- `addBlocks` (array of strings, optional): Task IDs that this task blocks.
+- `addBlockedBy` (array of strings, optional): Task IDs that must complete before this one.
 
 ## Status Workflow
 
-```
-pending → in_progress → completed
-```
-
-`deleted` can be entered from any status and permanently removes the task.
-
-## Use Cases
-
-**Good for:**
-- Marking a task as `in_progress` when starting work
-- Marking a task as `completed` when work is done
-- Setting dependencies between tasks
-- Updating task content when requirements change
-
-**Important rules:**
-- Only mark a task as `completed` when it is fully finished
-- Keep the task as `in_progress` when encountering errors or blockers
-- Do not mark as `completed` if tests are failing, implementation is incomplete, or unresolved errors exist
-
-## Notes
-
-- Before updating, retrieve the task's latest status via TaskGet to avoid stale data
-- After completing a task, call TaskList to find the next available task
-
-## Original Text
-
-<textarea readonly>Use this tool to update a task in the task list.
-
-## When to Use This Tool
-
-**Mark tasks as resolved:**
-- When you have completed the work described in a task
-- When a task is no longer needed or has been superseded
-- IMPORTANT: Always mark your assigned tasks as resolved when you finish them
-- After resolving, call TaskList to find your next task
-
-- ONLY mark a task as completed when you have FULLY accomplished it
-- If you encounter errors, blockers, or cannot finish, keep the task as in_progress
-- When blocked, create a new task describing what needs to be resolved
-- Never mark a task as completed if:
-  - Tests are failing
-  - Implementation is partial
-  - You encountered unresolved errors
-  - You couldn't find necessary files or dependencies
+The lifecycle is deliberately linear: `pending` → `in_progress` → `completed`. `deleted` is terminal and used to retract tasks that will never be worked on.
 
-**Delete tasks:**
-- When a task is no longer relevant or was created in error
-- Setting status to `deleted` permanently removes the task
+- Set `in_progress` the moment you actually begin work, not before. Only one task at a time should be `in_progress` for a given owner.
+- Set `completed` only when the work is fully done — acceptance criteria met, tests passing, output written. If a blocker appears, keep the task `in_progress` and add a new task describing what needs to be resolved.
+- Never mark a task `completed` when tests are failing, the implementation is partial, or you hit unresolved errors.
+- Use `deleted` for tasks that are cancelled or duplicate; do not repurpose a task for unrelated work.
 
-**Update task details:**
-- When requirements change or become clearer
-- When establishing dependencies between tasks
-
-## Fields You Can Update
-
-- **status**: The task status (see Status Workflow below)
-- **subject**: Change the task title (imperative form, e.g., "Run tests")
-- **description**: Change the task description
-- **activeForm**: Present continuous form shown in spinner when in_progress (e.g., "Running tests")
-- **owner**: Change the task owner (agent name)
-- **metadata**: Merge metadata keys into the task (set a key to null to delete it)
-- **addBlocks**: Mark tasks that cannot start until this one completes
-- **addBlockedBy**: Mark tasks that must complete before this one can start
-
-## Status Workflow
-
-Status progresses: `pending` → `in_progress` → `completed`
+## Examples
 
-Use `deleted` to permanently remove a task.
+### Example 1
 
-## Staleness
+Claim a task and start it.
 
-Make sure to read a task's latest state using `TaskGet` before updating it.
+```
+TaskUpdate(
+  taskId: "t_01HXYZ...",
+  status: "in_progress",
+  owner: "main-agent"
+)
+```
 
-## Examples
+### Example 2
 
-Mark task as in progress when starting work:
-```json
-{"taskId": "1", "status": "in_progress"}
-```
+Finish the work and record a follow-up dependency.
 
-Mark task as completed after finishing work:
-```json
-{"taskId": "1", "status": "completed"}
 ```
-
-Delete a task:
-```json
-{"taskId": "1", "status": "deleted"}
+TaskUpdate(
+  taskId: "t_01HXYZ...",
+  status: "completed"
+)
+
+TaskUpdate(
+  taskId: "t_01FOLLOWUP...",
+  addBlockedBy: ["t_01HXYZ..."]
+)
 ```
 
-Claim a task by setting owner:
-```json
-{"taskId": "1", "owner": "my-name"}
-```
+## Notes
 
-Set up task dependencies:
-```json
-{"taskId": "2", "addBlockedBy": ["1"]}
-```
-</textarea>
+- `metadata` merges key by key; passing `null` for a key removes it. Call `TaskGet` first if you are unsure of the current contents.
+- `addBlocks` and `addBlockedBy` append edges; they do not remove existing ones. Editing the graph destructively requires a dedicated workflow — consult the team owner before rewriting dependencies.
+- Keep `activeForm` in sync when you change `subject` so the spinner text continues to read naturally.
+- Do not mark a task `completed` to silence it. If the user cancelled the work, use `deleted` with a brief rationale in `description`.
+- Read a task's latest state with `TaskGet` before updating — teammates may have changed it between your last read and your write.

package/concepts/en/Tool-TeamCreate.md

@@ -1,38 +1,53 @@
 # TeamCreate
 
-## Definition
+Establishes a new collaboration team with a shared task list and inter-agent messaging channel. A team is the coordination primitive for multi-agent work — the main session acts as leader and spawns named teammates via the `Agent` tool.
 
-Creates a new team to coordinate multiple agents working on a project. Teams enable parallel task execution through a shared task list and inter-agent messaging.
+## When to Use
+
+- The user explicitly requests a team, swarm, crew, or multi-agent collaboration.
+- A project has several clearly independent workstreams that benefit from dedicated specialists (e.g. frontend, backend, tests, docs).
+- You need a persistent shared task list that multiple agents update as they make progress.
+- You want named, addressable teammates that can exchange messages via `SendMessage` rather than one-shot subagent calls.
+
+Do NOT use for a single delegated search or a one-off parallel fan-out — plain `Agent` calls are lighter and sufficient.
 
 ## Parameters
 
-| Parameter | Type | Required | Description |
-|-----------|------|----------|-------------|
-| `team_name` | string | Yes | Name for the new team |
-| `description` | string | No | Team description/purpose |
-| `agent_type` | string | No | Type/role of the team lead |
+- `team_name` (string, required): Unique identifier for the team. Used as the directory name under `~/.claude/teams/` and as the `team_name` argument when spawning teammates.
+- `description` (string, required): Short statement of the team's objective. Shown to every teammate on spawn and written into the team config.
+- `agent_type` (string, optional): Default subagent persona applied to teammates that do not override it. Typical values are `general-purpose`, `Explore`, or `Plan`.
+
+## Examples
+
+### Example 1: Create a refactor team
 
-## What It Creates
+```
+TeamCreate(
+  team_name="refactor-crew",
+  description="Refactor the data access layer from raw SQL to Prisma, including migrations and tests.",
+  agent_type="general-purpose"
+)
+```
 
-- **Team config file**: `~/.claude/teams/{team-name}/config.json` — stores member list and metadata
-- **Task list directory**: `~/.claude/tasks/{team-name}/` — shared task list for all teammates
+After creation, spawn teammates with `Agent` using `team_name: "refactor-crew"` and distinct `name` values such as `db-lead`, `migrations`, and `tests`.
 
-Teams have a 1:1 correspondence with task lists.
+### Example 2: Create an investigation team
 
-## Team Workflow
+```
+TeamCreate(
+  team_name="perf-investigation",
+  description="Identify and rank the top three performance regressions introduced in the last release.",
+  agent_type="Explore"
+)
+```
 
-1. **TeamCreate** — create the team and its task list
-2. **TaskCreate** — define tasks for the team
-3. **Agent** (with `team_name` + `name`) — spawn teammates that join the team
-4. **TaskUpdate** — assign tasks to teammates via `owner`
-5. Teammates work on tasks, communicate via **SendMessage**
-6. **Shutdown** teammates when done, then **TeamDelete** to clean up
+Each spawned teammate inherits `Explore` as its default persona, matching the read-only investigative nature of the work.
 
-## Related Tools
+## Notes
 
-| Tool | Purpose |
-|------|---------|
-| `TeamDelete` | Remove team and task directories |
-| `SendMessage` | Inter-agent communication within the team |
-| `TaskCreate` / `TaskUpdate` / `TaskList` / `TaskGet` | Manage the shared task list |
-| `Agent` | Spawn teammates that join the team |
+- Only one team can be led at a time from a given session. Finish or delete the current team before creating another.
+- A team is 1:1 with a shared task list. The leader owns task creation, assignment, and closure; teammates update the status of tasks they are working on.
+- Team configuration is persisted at `~/.claude/teams/{team_name}/config.json`, and the task directory lives alongside it. These files survive across sessions until explicitly removed with `TeamDelete`.
+- Teammates are spawned using the `Agent` tool with matching `team_name` plus a distinct `name`. The `name` becomes the address used by `SendMessage`.
+- Pick a `team_name` that is filesystem-safe (letters, digits, dashes, underscores). Avoid spaces or slashes.
+- Write the `description` so that a brand-new teammate, reading it cold, would understand the team's goal without further context. It becomes part of every teammate's startup prompt.

package/concepts/en/Tool-TeamDelete.md

@@ -1,30 +1,44 @@
 # TeamDelete
 
-## Definition
+Tears down the currently active team, removing its configuration directory and shared task directory. This is the cleanup counterpart to `TeamCreate` and is typically called after the team's objective has been achieved and all teammates have shut down.
 
-Removes a team and its associated task directories when multi-agent collaboration work is complete. This is the cleanup counterpart to TeamCreate.
+## When to Use
 
-## Behavior
+- The team has completed its work and the final report has been delivered to the user.
+- The team was created in error or its scope has changed so drastically that starting fresh is cleaner than continuing.
+- You need to create a new team but one is already active — delete the old one first, since only one team can be led at a time.
+- A team has become stale across sessions and its persisted state under `~/.claude/teams/` is no longer needed.
 
-- Removes the team directory: `~/.claude/teams/{team-name}/`
-- Removes the task directory: `~/.claude/tasks/{team-name}/`
-- Clears team context from the current session
+Do NOT call while teammates are still running — shut them down first via `SendMessage` with a `shutdown_request`, wait for every `shutdown_response`, then delete.
 
-**Important**: TeamDelete will fail if the team still has active members. Teammates must be gracefully shut down first via SendMessage shutdown requests.
+## Parameters
 
-## Typical Usage
+`TeamDelete` takes no parameters in its typical invocation. It operates on the currently active team owned by the calling session.
 
-TeamDelete is called at the end of a team workflow:
+## Examples
 
-1. All tasks are completed
-2. Teammates are shut down via `SendMessage` with `shutdown_request`
-3. **TeamDelete** removes team and task directories
+### Example 1: Routine shutdown after success
 
-## Related Tools
+1. Broadcast a shutdown request to the team:
+   ```
+   SendMessage(to="*", message={ "type": "shutdown_request" })
+   ```
+2. Wait for each teammate to reply with a `shutdown_response`.
+3. Call `TeamDelete()` to remove the team directory and task directory.
 
-| Tool | Purpose |
-|------|---------|
-| `TeamCreate` | Create a new team and its task list |
-| `SendMessage` | Communicate with teammates / send shutdown requests |
-| `TaskCreate` / `TaskUpdate` / `TaskList` / `TaskGet` | Manage the shared task list |
-| `Agent` | Spawn teammates that join the team |
+### Example 2: Replacing a misconfigured team
+
+If `TeamCreate` was called with the wrong `agent_type` or `description`, first ensure no teammates have been spawned yet (or shut them down), then:
+
+```
+TeamDelete()
+TeamCreate(team_name="...", description="...", agent_type="...")
+```
+
+## Notes
+
+- `TeamDelete` fails if any teammate is still active. The error response lists the live teammates — send each one a `shutdown_request` via `SendMessage`, await their `shutdown_response`, and retry.
+- Deletion is irreversible from the tool's perspective. The team's config at `~/.claude/teams/{team_name}/config.json` and its task directory are removed from disk. If you need the task list preserved, export or copy the directory before deleting.
+- Only the leader session that created the team can delete it. A spawned teammate cannot call `TeamDelete` on its own team.
+- Deleting the team does not roll back any filesystem changes that teammates made in the repository. Those are ordinary git-tracked edits and must be reverted separately if unwanted.
+- After `TeamDelete` returns successfully, the session is free to call `TeamCreate` again for a new team.