Issues
Issue 保存一项工作的上下文、负责人、状态和执行记录。
Issue 是 trackica 中安排工作的基本单位：一项功能、一个 bug、一次调研，任何需要成员或智能体负责推进的工作。围绕它的讨论、状态变化和每次执行都留在同一处，无需再从聊天记录或终端日志中拼接上下文。
Issue 的组成
| 内容 | 用途 |
|---|---|
| 标题和描述 | 目标、背景、要求和验收条件。 |
| 状态和优先级 | 工作处于哪个阶段，先处理什么。 |
| 负责人 | 工作区成员、智能体或小队。 |
| 日期、标签和自定义属性 | 计划、分类和团队自己的字段。 |
| 项目和父子关系 | 归入更大的工作范围，或拆成子 issue。 |
| 动态和执行日志 | 评论、状态变化、执行任务和智能体返回的结果。 |
创建 issue
在 Issues 页面或项目中新建，填写标题即可，其余属性随时补充。
每个 issue 有一个编号，例如 TRK-123。数字在工作区内递增；管理员修改工作区的 issue 前缀后，编号会用新前缀显示。详见工作区。
选择负责人
| 负责人 | 效果 |
|---|---|
| 成员 | 由这位成员负责跟进，不创建执行任务。 |
| 智能体 | 为该智能体创建一条执行任务。 |
| 小队 | 由小队 leader 接收，再决定交给谁处理。 |
分配给智能体或小队时，issue 不在 backlog 就会立即入队；运行时离线时，任务留在队列中等待。已归档的智能体和小队不能被分配。
分配不会绕过智能体的访问范围（Access）；分配给小队时，校验的是 leader 的 Access。详见分配 issue 给智能体。
状态
每个工作区都自带 7 个内置状态。它们同时也是 7 个分类——trackica 认识的那组行为，数量固定——每个内置状态就是它自己所在分类的名字。
| 状态 | 含义 |
|---|---|
backlog | 暂不启动。已分配给智能体的 issue 需离开 backlog 后才会创建执行任务。 |
todo | 已明确，等待开始。 |
in_progress | 正在处理。 |
in_review | 已有结果，等待检查。 |
done | 已完成。 |
blocked | 暂时无法继续。 |
cancelled | 不再继续，保留记录。 |
状态之间没有固定流转，成员和智能体都可以直接修改。
智能体随着工作对 issue 的实际影响写入状态：开始产出 issue 本身要求的东西时立刻推到 in_progress——不论形式是代码、调研、设计，还是 issue 本身要求的 review——让看板在工作进行中就能反映出来；交付后推到 in_review；工作跨轮继续则保持 in_progress；没有产出本 issue 交付物的轮次（答疑、给别处的工作做咨询）则全程不改状态。这些状态变更由智能体在运行中通过 trackica CLI 显式写入——task 开始或完成时，服务端不会自动改 issue 状态（下面两个系统例外除外）。done 通常留给人工确认，或由集成完成（例如带关闭意图的 PR 合并）。
两个变化由系统执行：
- 执行失败，且该 issue 没有其他执行、也没有触发重试时，
in_progress回到todo。 - 关联的 GitHub PR 带关闭意图合并，且没有其他仍处于 open 或 draft 的关联 PR 时，issue 变为
done。
自定义状态
工作区的 owner 或 admin 可以在设置 → 任务状态里添加自己的状态，比如 Code Review、QA、Rework。每个新状态都要选定一个分类，并完整继承该分类的行为：
| 分类 | 该分类下的状态都会这样 |
|---|---|
backlog | 停着不动：分配给智能体不会启动执行。把 issue 移出这个分类才会启动，除非目标是 done 或 cancelled。 |
todo | 排队等待开始。和 backlog 不同，处于这个分类的 issue 一分配智能体就立即启动执行。 |
in_progress | 算作正在处理：执行失败且没有其他执行在进行时，issue 回到 todo。 |
in_review | 算作已交付、等待检查：会结束自动化的运行，之前的"执行失败"通知也会自动归档。 |
done | 算作已完成：会结束子 issue 的一个阶段，并计入父 issue 的进度。 |
blocked | 卡在外部依赖上，不会自行恢复。 |
cancelled | 不再继续但保留记录；同样是子 issue 阶段的终态。 |
所以 in_review 分类下的 Code Review 状态，结束自动化运行的方式和 in_review 完全一样；把 issue 从 backlog 移到 todo 分类下的 Rework 状态，启动智能体的方式也和移到 todo 完全一样。
名字是给团队看的，平台真正依据的是分类。文档其他地方说某个状态会触发什么时，这条规则属于它所在的分类，该分类下的自定义状态同样适用。反过来不成立：平台自己写入状态时——上面失败回滚到 todo、PR 合并置 done——写的都是内置状态，不会写成该分类下的某个自定义状态。
由此有四点：
- 状态一旦创建，分类就不能再改。 改分类等于悄悄重写所有已经在该状态上的 issue 的行为，所以编辑时分类是只读的。先想清楚要什么行为，再取名字。
- 看板的列是分类，不是状态。 新增状态不会多出一列——每个分类一列。自定义状态归入它所属分类的那一列，卡片上带一个写着状态名的小标签，这样 In Review 列里的
Code Review和QA仍然分得清。 - 内置状态是锁死的。 名称、颜色、分类都不能改，也不能归档——从不打开这个页面的工作区，看板和原来一模一样。
- 归档是停用，不是删除。 已经在该状态上的 issue 保持不变，名称、颜色和行为都不变，只是之后再设置状态时不再出现这个选项。
内置状态会按界面语言翻译，自定义状态则始终显示你填的名字。API 和 CLI 通过 key 引用它：trackica issue status TRK-42 code_review。设置页里的 key 由名字生成；API 可以显式指定，省略时才自动生成。无论哪种方式，key 在创建时就定下来了——之后改名字不会改 key。
Issue 与执行任务
Issue 是持续存在的工作记录；执行任务（task）是智能体的一次具体执行。一个 issue 可以先后产生多条执行任务——第一次实现、补充修改、再次检查。执行任务"已完成"只表示这一次执行结束；issue 是否完成，以 issue 的状态为准。
项目和子 issue
一个 issue 最多属于一个项目，项目为其中的执行提供共享说明和资源；移到另一个项目不会产生副本。
较大的工作可以拆成子 issue：父 issue 保留整体目标，子 issue 各自独立推进。父子状态互不联动。
子 issue 可以设置阶段（stage），按 1、2、3 分批推进。当前最早未完成阶段的全部子 issue 到达 done 或 cancelled 时，父 issue 会收到"子任务完成"通知；父 issue 的负责人是智能体时，它会被唤醒并决定是否推进下一阶段。未设置阶段的子 issue 视为同一批，全部结束时通知一次。
切换视图
Issues 页面提供列表、看板、表格、甘特图和泳道五种视图，可按状态、负责人、项目和其他属性筛选、排序，展示的都是同一批 issue。
删除 issue
任何工作区成员都可以删除 issue。
删除不可恢复：issue 及其评论、附件和关联记录会被永久移除，尚未结束的执行任务会被取消。不再继续时把状态改为 cancelled，讨论和结果仍可查阅。
接下来
- 项目 — 组织需要多条 issue 一起完成的工作。
- 评论 — 围绕 issue 讨论、回复和 @提及。
- 分配 issue 给智能体 — 把工作交给智能体并开始第一次执行。
- 执行任务 — 了解排队、运行、重试和取消。