# Task Board Spec

> Canonical path: `specs/task/board.md`
> Status: active-spec-2026-04-23
> Aligns with:
>
> - `SPECS.md` Section 2.8
> - `specs/collaboration/collaboration.md` Section 7
> - `specs/task/embedded-view.md` for source-thread task references
> - `specs/identity/identity.md` Task Surface Rules
> - `specs/agent/output-review.md` for agent output review targets
> - `docs/architecture-spec.md` Section 7 (`agentteam-task`)
> - `docs/tech_design.md` Section 4.7.5 for the current implementation surface
>   Scope: workspace-level task hub, channel-bound task board, kanban presentation, task detail, review process, and agent-native task execution semantics
>   Non-goals: workspace-global ownership/ACL model, external task-provider federation, replacing chat with issue comments, turning task creation into a command language, or exploding the progress state machine

## 1. Goal

This spec defines AgentTeam's canonical task execution surface.

It makes three product decisions official:

1. Task board is a real kanban-style execution surface, not a thin task list.
2. Agent work should treat task as the primary execution object, not a side note hanging off chat text.
3. Human review must be first-class, auditable, and low-friction, rather than being represented only by a bare `in_review` status.

## 2. Position In The Canonical Specs

This spec owns:

- task board columns and board-first semantics
- task card density, filters, and secondary views
- task detail, checklist, artifact, and activity semantics
- review request as a first-class task object
- agent-native task read/write capabilities

This spec does not replace:

- `specs/collaboration/collaboration.md` for task handoff, notify scope, thread/channel boundaries, and collaboration rules
- `specs/task/embedded-view.md` for source-thread task references and quiet-thread behavior
- `specs/identity/identity.md` for display-vs-target and identity-sensitive task payload rules
- `specs/task/board-pages.md` for workspace hub and channel `List` / `Board` browse/query/pagination semantics
- `specs/agent/output-review.md` for agent output review, review context, output targets, and git compare semantics
- `docs/tech_design.md` for the current shipped handler/schema/API layout

## 3. Current Product Surface

The Task domain provides:

- top-level workspace `Tasks` hub for browsing visible tasks across channel scopes
- per-channel task board
- status-driven `todo / in_progress / in_review / done` lifecycle
- structured task create flow
- one nullable Human-or-Agent assignee, Kind, Priority, blocker, checklist,
  source refs, subtasks, artifacts, and independent review-request data
- `TaskDetailPage` as the execution center
- six agent task tools for list/get/create/update/set-claim/checkpoint

## 4. Core Product Principles

### 4.1 Task board gets a workspace-level entry, while task remains channel-bound

- every workspace exposes a task hub entry that aggregates the tasks visible to the current viewer
- every channel has exactly one task board
- DM and thread do not own separate task boards
- task ownership remains channel-bound rather than workspace-global
- the workspace task hub is an aggregation and management entry, not a new ownership or ACL layer
- tasks may be created from the workspace task hub, but must bind to exactly one channel before creation completes
- when a suitable channel does not exist yet, the product may support `create channel and bind first task` in the same create flow
- thread remains a source-context and optional discussion surface for a task, but task discussion is the default post-create execution surface and does not replace the task object
- the workspace task hub supports the same `Board / List` presentation choices over the viewer's cross-channel task set; the list preserves channel grouping and the board preserves channel identity on every card
- `Tasks` is a direct first-level workspace entry and does not own a persistent second-level navigation panel; system and saved view presets belong at the start of the task toolbar before search

### 4.2 Assignee is the single current responsibility fact

- nullable `assignee` answers who owns the Task's next step;
- Human and Agent use the same member-backed assignee shape;
- `claim` is self-assignment, not a second claim field;
- claim may fill an unassigned Task or confirm an existing self-assignment, but
  it must not silently take over a Task assigned to someone else;
- Review Request reviewer is an independent review fact and is not stored on
  the Task row or used as an assignee fallback;
- creator and execution owner remain independent facts and are not additional
  assignees.

### 4.3 Default progress is a status-driven lifecycle

The task board uses fixed lifecycle status columns:

- `todo`
- `in_progress`
- `in_review`
- `done`

Implications:

- `blocked` is a task attribute surfaced as a badge and filter, not a separate
  progress column
- `changes requested` is a review outcome, not a separate progress state
- assignee state is task metadata and filtering context, not a separate
  default board column
- `tasks.status` is the canonical lifecycle value; board columns and browse
  projections all read from it
- humans and agents move a task by updating its status, its assignee, or its review
  state through the task surface
- automation that depends on task state changes consumes task events; it does
  not own the task lifecycle

### 4.4 Task changes are task-native by default

Task changes do not automatically pollute channel chat.

Default rule:

- task mutations stay in the task's own activity/audit surface

Important distinction:

- the task detail is the canonical surface for task-relevant state, state changes, evidence, and review history
- the task detail is not meant to become the universal container for every human conversation
- most task-related progression and task-scoped discussion stay in the task detail by default
- thread/channel are reserved for a small set of necessary human decision prompts, milestone broadcasts, or wider coordination moments

Allowed explicit announce points:

- review requested
- review decision recorded
- human chooses to broadcast a milestone into thread or channel

Recommended product rule:

- when a human decision is needed or a milestone must be broadcast, AgentTeam should send an explicit thread/channel notification with a strong backlink into the task and review target, instead of forcing the whole decision flow to happen inside the task detail

### 4.5 Task detail is the execution center

A task is not just a title and a status badge.

Canonical task execution requires first-class support for:

- description / goal
- acceptance criteria
- review checklist
- context references
- artifacts
- activity history

### 4.6 Review is a first-class object

`in_review` is not sufficient by itself.

Canonical review must capture:

- who requested review
- who should review
- what evidence should be reviewed
- what the decision was
- how the review history evolved over time

## 5. Canonical Board Model

The canonical task surface has two linked layers:

- `Workspace Task Hub`
  - top-level browse/filter/group/manage entry
  - supports status-column `Board` and channel-grouped `List` presentations over the same visible cross-channel task set
  - preserves channel as task identity, filter, and navigation context in both presentations
- `Channel Task Board`
  - execution workbench for the tasks owned by one channel

### 5.1 Default columns

The default board view uses fixed lifecycle status columns:

- `Todo`
  - `todo`
- `In Progress`
  - `in_progress`
- `In Review`
  - `in_review`
- `Done`
  - `done`

This keeps the default board familiar across workspaces. `todo + assignee` and
Agent-assigned work remain visible on cards and filters, but they do not split
the default board projection into additional columns.

The channel board remains the default execution surface: cards move through
status updates, and board columns group by the lifecycle status.

Both primary workbench views are root-task-first by default:

- `Board` and `List` show only root tasks in their default task set
- child tasks remain reachable from the parent task detail and may get richer dedicated list treatments later
- subtask progress still projects back onto the root task card so the board communicates execution depth without flattening the hierarchy

During the board's initial load, the four default lifecycle columns remain
visible and each column shows one task-shaped breathing skeleton. The loading
motion respects reduced-motion preferences; the board must not collapse into a
standalone loading label while its first page is pending. The board's vertical
scroll indicator overlays the viewport instead of reserving layout width, so
replacing the skeleton with loaded cards does not shift the columns.

### 5.2 Required card fields

Each task card must be able to show, at minimum:

- task number
- title
- progress status
- assignee
- kind
- priority
- subtask or checkpoint progress
- blocked badge
- review badge / current review state
- artifact count
- last activity time

### 5.3 Filters and secondary views

The workspace toolbar exposes orthogonal filter dimensions in this order after search: channel, lifecycle status, then assignee. Kind and priority remain available in the additional filter menu. Filter option rows show labels without task counts. In dimensions that support `None`, that value is mutually exclusive with concrete values.

Dynamic channel, assignee, kind, and priority candidates come from one workspace-scoped Task filter-option discovery request, not from the currently loaded browse page and not from one request per dimension. Discovery applies the same readable-channel boundary as workspace Task browse and remains stable while the active browse filters change. Lifecycle status remains a fixed client vocabulary. A cached browse page may supply a compatibility fallback when an older server does not expose discovery, but it is not the authoritative complete candidate set.

The assignee popup supports name search across both Humans and Agents through the same Task filter-option discovery contract on explicit input; it does not add directory fan-out to first paint or introduce a second Task-specific identity search path.

Semantic slices such as `Related to me`, `Created by me`, and `Blocked` belong to system views rather than being duplicated as ordinary filter controls. Contextual channel boards may expose a smaller scope-specific filter set when no workspace View menu is present.

The default product defines a two-view primary workbench:

- `Board`
  - kanban-first execution view
- `List`
  - dense row view over the same task set

Reviewer-first and assignee-first views still exist, but as filter presets or secondary saved slices layered on top of the same board/list surfaces rather than as separate primary modes. Reviewer filters read Review Request facts; assignee filters read the Task row.

At the workspace task hub level, `List` groups by `channel`. `Board` groups by lifecycle status while every card retains channel identity. Search, structured filters, sorting, and presentation mode operate on the same shared view state.

Task card field visibility is one browser-local preference scoped by workspace and user. Workspace Task and every Channel Task surface read and update the same preference, so changing visible fields in any one of them is reflected in the others. Field visibility is not part of a system/saved View or a per-channel view state and is not persisted by the server.

Browse responses must echo the query semantics actually applied by the service. A client that requests filters must fail closed on a mismatched query echo rather than silently rendering an unfiltered response.

System and saved views are presets over that shared state, not navigation destinations that require a permanent sidebar. The toolbar control is labeled `View`; its system preset order is All tasks, Created by me, Related to me, then Blocked, and personal saved views follow in a separate section. Selecting a view applies its complete query and presentation state. System views are immutable. Creating a saved view opens a configuration dialog initialized from the current state, where name, layout, search, sort, channel, status, assignee, kind, and priority can be edited before saving. A changed saved view can also be updated or restored.

When the current query or presentation state diverges from a system view preset, the View control identifies the result as `Custom` while retaining the system preset as the restore baseline. A modified personal saved view keeps its saved name and exposes its unsaved state plus update and restore actions.

Detailed browse/query/pagination semantics for the workspace hub and channel `List` / `Board` live in [`specs/task/board-pages.md`](board-pages.md).

### 5.4 Workspace taxonomy and settings

`kind` and `priority` are workspace-managed field catalogs, not per-task free-form enums.

Rules:

- the canonical management surface is `/tasks/settings`
- only workspace owners and admins may add, rename, reorder, deactivate, or reactivate options
- members get a read-only view of the same settings
- the default create/edit value is `None`
- inactive options stay visible for historical tasks and filters
- inactive options are unavailable for new task creation or new task edits
- values without a current option continue to render as custom values until they are normalized

## 6. Canonical Task Object And Detail Surface

### 6.1 Task fields

The canonical task object includes the following product fields.

The task model must support, conceptually:

- stable task identity within a channel (`taskNumber`)
- `title`
- `createdBy`
- `description`
- `acceptanceCriteria`
- `reviewChecklist`
- `status`
- `assignee`
- `kind`
- `priority`
- `blockedReason`
- `sourceThreadRef`
- `lastActivityAt`
- optional `parentTaskRef`

This spec does not require a specific storage schema. It defines the product contract.

### 6.2 Access and action model

At the product level:

- any human or agent channel member may view tasks on that channel board
- any human or agent channel member may create tasks on that channel board
- any human or agent channel member with task write access may update task
  metadata; claim is self-assignment and cannot silently replace another assignee
- any human channel member with task write access may move a task between
  statuses on the board
- board drag/drop resolves to a status update on the task
- agent task tools mutate task status, assignee, blocker, and checkpoint
  state directly through the task surface
- Review Request reviewer assignment does not block another channel member from resolving or
  moving a task by default
- stricter enterprise-specific gates such as assignee ownership, reviewer-only
  approval, or terminal done semantics are not part of the base task board
  lifecycle
- deleting remains stricter than status cleanup: task deletion is limited to
  the task creator or workspace owners/admins

### 6.3 Task detail surface

Task detail is the default execution center and is a single task-native surface, not a thin tab wrapper.

同一个 task-native document 有两种 presentation，但只保留一套 canonical
execution model：

- 在至少 1024 CSS pixels 的桌面 viewport 上，除 workspace 一级 Tasks hub
  之外的上下文入口都打开居中的 route-backed dialog；这些入口包括 Thread
  related tasks、Channel Tasks Tab、Inbox rows、消息中的 Task ref、搜索结果与
  Agent/Workflow task links。
- 只有从 workspace 一级 Tasks hub 进入的任务默认打开 focused page。直接或
  分享链接、冷启动、在新标签页打开 dialog path、显式 Expand，以及窄 viewport
  也使用 focused page。

Both presentations preserve the same document order and semantics:

- `Agent Live`, when present, sits immediately after `Execution Summary`
- `Activity` 是 task-native mainline，并在共享组件内分为两个 presentation：
  `讨论` 只展示 message-backed task replies 并提供 message-style composer；`进展`
  只展示 Checkpoint、status/property transitions、review 与 artifact progression，
  使用带相对时间和具体时间的纵向时间轴；focused page 与 dialog 必须复用这两个
  views；
- 两个 view 由无额外 section title 的 underline tabs 切换；`讨论`
  必须复用 MessageList 的 author identity/avatar resolution，包括 Human、Agent 与
  App service avatar；两个 view 的 avatar size、author typography、timestamp
  typography 与 item spacing 必须复用应用的 message tokens 并保持一致；view
  content 相对 radio group 轻微内缩 8px，讨论 item 之间不显示 divider，而以 compact
  row padding 与 12px vertical whitespace 分组；`进展` 将相邻且 author identity
  相同的 typed activities 合并为一个 author group，只展示一次 32px avatar 与作者名；
  group 内从 message body 的左缩进起展示轻量纵向时间轴，每个节点默认只占一行，
  依次显示 relative time 与 action，不能把 timestamp 推到远端造成横向跳读；节点
  有 checkpoint 等 detail 时默认折叠，只有点击该节点才在其下展开 detail；timestamp
  的 hover tooltip 始终显示完整 absolute time；discussion entry 会中断 author group，
  后续 progress 重新按相邻 author identity 分组；
- dialog presentation must not invent a second summary, discussion system,
  query, cache, or mutation boundary;
- dialog 始终采用 title 下方展示 properties 的单栏 document layout，不读取
  focused page 的 sidebar preference，也不显示横向/纵向 properties layout
  toggle；loading skeleton 必须使用同一结构；
- dialog 的 task discussion composer 默认是一行、随内容自动增高，action
  buttons 保持在右侧，不使用分隔线拆出第二个 action row，并复用 message
  composer 的细 focus border。

Task collaboration（智能体协作者管理）在两种 presentation 中有不同的暴露方式：

- focused page 在 header 中提供 Thread members 风格的 toggle（`Users` icon +
  collaborator count badge，位于 Watch action 与 more menu 之间），点击开启
  inline right side panel；panel 复用 Thread/Channel members sidebar 的
  `ConversationSidePanel`（desktop，resizable）与 mobile `Sheet` 表面，并占用
  watcher roster 相同的 side-panel 槽位——两种 panel 互斥，sidebar property
  layout 下 panel 临时替换右侧 properties panel；
- panel 复用 Thread members 的人员分组：`People` 管理 collaborator grants，Agent
  rows 就地承载 self / owned-agent notification policy，不再增加独立 `Wake` 或
  `Sync` section；
- focused page 在 `Subtasks` 与 `Activity` 之间提供独立的显式来源公告 section。
  section 默认折叠，header 使用单个 right/down disclosure icon + `来源更新`，不能
  再叠加公告 icon；展开后用一句短说明标明发送目标，再以单行复合控件承载
  announcement intent 下拉、正文输入框和纯文字 `发送` action；不得使用含义抽象的
  `同步` 标题或解释性口号；
- dialog presentation 的 header 不提供 collaboration toggle，正文也不渲染
  collaboration section，也不渲染来源公告 composer；管理 collaboration 或向来源
  发布显式公告必须通过现有 Expand action 进入 canonical focused page。

Focused page 的 channel-owned canonical URL 是
`/channels/:channelId/tasks/:taskNumber`。Dialog 使用独立路径
`/tasks/:channelId/:taskNumber`，并依赖当前 tab 的 runtime-valid
background-location state。Dialog 来源 surface 保持 mounted、`inert` 与
`aria-hidden`，从而保留 scroll、draft、reply thread 与 live subscriptions。
Browser Back 关闭一个 dialog history step；Escape 与显式 close action 回到原始
source。Parent/child drill-down 从已打开的 dialog push 下一个 dialog URL，连续的
previous/next browsing 可以 replace 当前 dialog URL。

同一 tab reload 会保留 browser history state 与 session runtime identity，因此
恢复 dialog 及其 background source。缺少有效 background state 的 cold/direct
dialog path 必须 replace 到对应 canonical focused URL；这包括手工输入或在新
tab 打开 `/tasks/:channelId/:taskNumber`。Expand 清除 transient presentation
state、retire 当前 dialog drill chain，并 replace 到 canonical focused URL，因此
Browser Back 不能把已展开的历史 Task 再打开为 dialog。Focused page header Back
action 对 Inbox-owned route replace 到 Inbox origin，对 channel-owned route
replace 到 `/tasks/views/all-tasks`。Copy Link 始终复制 workspace-scoped canonical
URL，且不得序列化 dialog state。

`/inbox/tasks/:channelId/:taskNumber` 仍是窄 viewport 或其他 focused fallback
使用的 Inbox route projection，使 focused Task document 在主内容区渲染并保留
level-2 Inbox sidebar。它与其他 presentation 复用同一个 Task detail component、
data、mutations、cache 与 unread behavior，不得成为第二套 Task detail UI。

### 6.4 Execution Summary, Description, and Task Contract

`Execution Summary`, `Description`, and `Task Contract` together show and edit the task's own execution contract:

- title
- description / goal
- acceptance criteria
- review checklist
- assignee
- current Review Request summary, when one exists
- priority
- kind
- blocked reason

The description should appear ahead of the metadata-heavy contract fields so the task opens with its working narrative before the longer reference fields. Acceptance criteria and review checklist remain first-class task data, not incidental prose hidden in the title or chat history.

Inside `Execution Summary`, the default mainline order is:

1. `Goal`
2. `Progress`
3. `Current focus`
4. `Blocker`
5. `Latest deliverable / latest conclusion`
6. `Next step`
7. `Review status`

These summary blocks are deterministic presenter output derived from the existing task object, subtasks, discussion, artifacts, and review history. Metadata such as assignee, current Review Request reviewer, kind, priority, source thread, and timestamps belongs in the compact property rail rather than the main summary blocks.

### 6.5 Discussion and context refs

Task discussion is the default post-create collaboration surface for the task itself. It remains task-native even when the UI chooses to expose it inside `Activity` rather than as a standalone top-level section.

Rules:

- task discussion entries are task-native and do not auto-create channel or thread chat messages
- task discussion is intentionally a flat chronological task-native stream; task detail does not host nested reply trees or a second thread system
- a Task Message computes attention from explicit watchers, the current assignee,
  and that Message's direct mentions, excluding the author
- an Agent assignee is therefore woken by a plain comment even without a fresh
  explicit `@agent`; this responsibility is derived from assignee, not persisted as Watch
- `@agent` is a one-event wake that penetrates `no-wake` without changing the
  Agent's Watch setting
- if the same member is watcher, assignee, and direct mention, the durable
  recipient snapshot and runtime delivery must dedupe it
- thread and channel remain optional places to announce milestones or gather broader context, not the required default follow-up surface

Product nuance:

- task discussion is for task-scoped continuation, clarification, and handoff
- most task-related progression remains in task detail, even when humans are involved
- if a task-related conversation needs true branching discussion semantics, broader audience visibility, or a long side thread, AgentTeam should reuse the existing thread/channel surfaces rather than nesting that branch inside task discussion
- thread/channel are reserved for the small number of necessary human decision prompts, milestone broadcasts, and wider coordination moments
- task detail should show the resulting references, state transitions, and jump-back affordances rather than duplicating full thread/channel conversations

Task source refs still gather the task's working context:

- source thread (immutable origin lineage: the channel reply thread the task
  was created from, recorded automatically when creation context is a thread)
- pinned messages
- relevant URLs
- workspace file or doc references

Recommended product rule:

- task discussion belongs to the task's own `tsk_` scope; the source thread
  records where the task came from and never becomes the discussion home

### 6.6 Activity

Task activity is append-only and task-native, but its timeline side effects are not feature-local writes. The timeline combines message-backed task-scope items with typed activity intents through the task timeline contract; feature code must not write activity rows, allocate task-event ids or seqs, or update activity unread/inbox projections outside the task timeline writer.

On page task detail, `Activity` is the canonical task-state mainline for review state, task-native discussion, artifact progression, and the durable task history. Pending review should stay visibly anchored there until it resolves. Live execution presence should remain visually coupled to that mainline, but it may be exposed as a dedicated `Agent Live` section immediately after `Execution Summary` so long-running execution stays obvious without burying it inside the feed.

Typical events include:

- created
- assignee changed
- claimed (self-assigned)
- unassigned
- status changed
- blocked
- unblocked
- review requested
- review approved
- review changes requested
- artifact added
- checklist updated

This timeline complements chat; it does not replace chat. Message-backed entries continue to use message authority for content, delivery, reactions, search, and visibility; typed activities continue to use task authority for state and audit facts.

### 6.7 Artifacts

Artifacts are structured review and execution evidence.

Canonical artifact kinds include:

- thread ref
- message ref
- URL
- workspace file
- agent review target
- attachment
- test summary

### 6.8 Subtasks

Tasks may be split into one level of subtasks.

Rules:

- one broad request that still leads to one deliverable should default to one root task plus subtasks, not several sibling root tasks
- parent/child stays inside the same channel board
- each child task keeps its own nullable assignee
- parent progress may summarize child progress, but child tasks remain independently executable objects
- default UX stays parent-review-first: child tasks remain execution objects, but request-review should not be the primary affordance on every child by default when the human only needs to review the rolled-up parent deliverable
- deleting a parent task with subtasks must require an explicit subtask handling choice: either delete only the selected parent and promote direct subtasks to root tasks, or delete the selected parent and its direct subtasks together. The delete-together path must still apply normal delete authorization to each deleted direct subtask. The system must not leave child tasks pointing at a deleted parent.

## 7. Review Model

### 7.1 Review request is first-class

Each task may have a current review request and a preserved review history.

The canonical review request model includes, conceptually:

- `taskRef`
- `requestedBy`
- `reviewer`
- `status`
  - `requested`
  - `approved`
  - `changes_requested`
  - `cancelled`
  - `superseded`
- `summary`
- `questions`
- `decision`
- `requestedAt`
- `decidedAt`
- `reviewTargetType`
- `reviewTargetPayload`

### 7.2 Review targets

Review target expresses what the reviewer should inspect.

Canonical review target types include:

- `agent_output_working_tree`
- `agent_output_branch_compare`
- `task_artifact_set`
- `thread_only`

### 7.3 Review process

Canonical review actions:

- `Request review`
  - creates a new current review request
  - records summary/evidence/questions
  - moves the task into `in_review`
- `Approve`
  - marks the current review request `approved`
  - moves the task into `done`
- `Request changes`
  - marks the current review request `changes_requested`
  - moves the task back to `in_progress`
- `Reassign reviewer`
  - changes the active reviewer without creating a new task
- `Mark not reviewable yet`
  - cancels or supersedes the active review request and returns the task to `in_progress`

### 7.4 Review surface

The review surface must let a reviewer see, in one place:

- review summary
- acceptance criteria
- checklist
- linked thread
- artifacts
- compare target / diff target
- previous review decisions

If the review target is an agent output compare, the task review surface should reuse the existing review viewer rather than inventing a separate diff experience.

## 8. Agent-Native Task Surface

### 8.1 Structured task packet

Task create-with-assignee and later assignee changes remain human-auditable
typed Activities. A recipient Agent receives a structured Task packet from the
same Activity attention outbox rather than relying on system-message prose.

The packet must be able to carry:

- `taskId`
- `taskScopeId`
- `taskNumber`
- `channelRef`
- `title`
- `description`
- `acceptanceCriteria`
- `reviewChecklist`
- `assigneeProfile`
- `sourceThreadRef`

### 8.1.1 Workbench create flow

The canonical task-board create flow is one operation:

- `Create`
  - creates the Task with an optional `assigneeRef`;
  - does not encode status transition or a separate dispatch mode;
  - if the creator assigns another Agent, the committed Activity attention
    projection wakes that assignee;
  - if the creator is also the assignee, actor exclusion prevents self-wake.

### 8.2 Canonical task-native tool surface

The model-visible task tool surface is:

- `task_list`
- `task_get`
- `task_create`
- `task_update`
- `task_set_claim`
- `task_checkpoint`

`task_get` is the canonical "open the task before working" primitive and must be treated as first-class.
`task_update` carries status, assignee and other Task properties.
`task_set_claim` (or the transport's claim / unclaim commands) is a narrow
self-assignment facade over canonical assignee mutation; it does not own a
separate claim field.

### 8.3 Checkpoints

Agents must be able to write progress without spamming chat.

`task_checkpoint` is used for:

- what was done
- what is next
- what risks were found

### 8.4 Review and queue awareness

Agents should be able to understand:

- what work is assigned to them
- what work is suggested to them
- what review is waiting on them

Task work must not depend on parsing free-form system-message wording when structured task state already exists.

## 9. Product Boundaries

### 9.1 Task creation stays lightweight

Task creation remains quick-create plus optional assignment/start dispatch.

Richer task metadata belongs in task detail, not in a chat command grammar.

### 9.2 External issue federation is out of scope here

Integrations with Jira, ONES, Linear, Trello, or other external task providers are not part of this spec.

If AgentTeam later defines link/mirror/managed federation with external issue systems, that must live in a separate canonical spec.