什么时候建立使命
短小修改或问答用普通项目会话即可。需要让一个目标持续留在使命板上、让同一队伍多次推进时，建立“完善 Orbit 下载体验”这样的使命。一个使命关联自己的团队会话；抽屉和完整会话打开的是同一项工作。
说明目标与边界，不只填名称：平台选择清楚、演示文件标识明确、检查链接和可访问性，最后交付页面及检查结果。
使命、会话、任务与执行的关系
可照着填写的使命目标
检查已交付的 Orbit 下载页并运行 node verify.mjs。只新增 DELIVERY.md，记录三个平台名称、实际演示文件名、已执行的检查，以及剩余浏览器测试限制。不修改 HTML/CSS，不提交、合入、发布或联系其他队员。
从创建到推进
- 打开“使命板 → 新使命”，填写名称和描述，选择 Orbit 项目、队伍和队长；有需要时再添加来源附件或标签。
- “新建”保存记录，不立即开始工作；“开始使命”发起执行，使命板上的业务状态单独管理。
- 打开卡片，在抽屉里讨论，或展开为完整会话。检查开始请求对应的真实执行，以及需要你介入的事项。
- 需要长期跟进时建立任务，再显式向相应队员发消息。只创建任务不会启动智能体。
- 阅读最终回复与累计变更，检查交付页面，再决定使命状态和代码整合。
填写完整的使命
执行与看板状态可以不同
理解使命工作目录
Git 项目的首次执行获准后，会从主项目当时的本地 HEAD 准备受管使命工作树。使命内队员共享这个工作树，后续通常继续使用。不要假设主项目尚未提交的修改也会被复制进去。
非 Git 目录继续使用原目录，没有自动分支隔离。交给队员写文件前，确认界面显示的工作位置。
累计变更从记录的基线对比使命工作树当前内容，包含已提交、已暂存、未暂存及未跟踪变化。刷新读取当前视图，并非历史快照；手动切换分支也不会重写原基线。
清理工作区是需要安全检查的独立操作。状态改为完成不会自动清理工作树、合入代码或删除分支。遇到目录有改动或分支被使用等拒绝提示时，先处理原因。
实际推进过程
第一次使命执行检查了页面、下载文件和本地 HTTP 响应。后续查询使命服务的操作被拒绝，队员说明无法读取完整验收条件。用户在新消息中补充完整要求，把修改范围限制为 DELIVERY.md，没有重试被拒绝的操作。
后续执行创建了这一份报告，并通过 node verify.mjs；HTML/CSS 未修改，临时 HTTP 服务已停止。虽然初始请求要求英文，实际报告使用中文，源文件和截图保留了这一结果。本次没有把代码合入、正式发布或把使命标记为已完成。
活动区显示独立工作树、来源分支与固定基准。展开累计文件变更后可见新增但未提交的 DELIVERY.md。单独的“队员交付”仍为空：实际文件变化与显式登记的交付属于不同记录。
读取工作树与当前变化
检查交付报告
三种“完成”分别意味着什么
- 执行结束
- 某一次操作进入终态，可能成功、失败或被停止，需要阅读实际结果。
- 使命完成
- 目标的业务状态发生变化，不能据此证明所有检查通过或代码已进入其他分支。
- 代码已合入
- 由 Git 记录或原有审查、发布流程确认整合，需要单独查看证据。
使命内容怎么填
- 名称
- 写较大的目标，而不是某条命令；会显示为看板卡片标题。
- 说明
- 交代背景、预期结果，以及什么情况可以认为目标完成。
- 项目
- 目标依赖文件时，关联正确的工作目录或项目上下文。
- 队员和队长
- 确定参与目标的队员，以及负责协调会话的队长。
- 标签
- 用于看板筛选和查找的可选标签。