Fleet 0.2.230

Added

• 派工确认卡：新建 Worker 的首个任务、以及涉及既有产物（修改/复刻/参考）、带底本或规范锚点、带待确认问题或带派单方新增约束的任务，派工前会先给你一张卡。卡上逐字保留你的原话，并列出目标项目/目录、底本、规范、不可改动边界和交付形态；不确定点用与提问相同的单选/多选/自由填写选项呈现，必答项没答完不能点「确认派工」。你确认之后才创建 Worker 或投递任务，点了「拒绝派工」则不会创建 Worker、任务直接取消。
• 合同锚点校验：声明要修改/复刻/参考既有产物时，底本与规范必须真实存在（路径或 Fleet 记录引用），否则直接拒绝派工，不再把「底本在哪」丢给 Worker 猜。答案会原样写入任务合同，并随任务一起交给 Worker。
• 「我加的」约束标记：不是从你原话中来的约束，卡上会标为「我加的」，每一条都要你明确点「允许」才会进入合同；派单方自己写「已允许」或提前替你答题都会被拒绝。
• 派工记录：任务详情可以看到派工卡、你提交的原始答案、产物类型、底本/规范、约束来源。收件箱会在新卡出现时提醒一次，确认或拒绝后自动消项。
• 交付物写权租约：任务合同可以声明具体输出路径（deliverable_paths），同一路径同一时刻只允许一个在飞 Assignment 持有写权。第二个派工会被明确拒绝（DELIVERABLE_LEASE_HELD，并列出持有人与到期时间），不会创建任务；只有派单方显式写 lease_takeover 并说明理由才能接管，旧持有人和接管理由都会留档。确认卡期间由卡持有写权，你确认后转给任务合同；完成、失败、取消自动释放，崩溃或漏释放由启动对账、24 小时有效期和获取时的懒清理兜底，不会永久锁住一个路径。
• 完成指纹：done 声明可以把产物写成 {path, sha256, bytes, pages?}。修改/复刻/参考既有产物时，声明了交付路径却没有 sha256 会被直接拒绝；全新产物缺指纹会产生可见警告事件。同一路径已经由别的 Assignment 交付过、内容哈希不同时拒绝（相同内容放行），字节数对不上也拒绝；旧的纯字符串产物声明保持兼容。派工卡上会显示本次占用的交付路径与显式接管信息。
• 人读交付等你看过才算完成：artifact_class=human-readable 的任务（或 Worker 主动给出消费入口的交付）在 done 后不再直接标完成，而是停在「待你验收」。done 必须带 consumption_entry（工作区内真实存在、可打开的文件或 http(s) 链接；PDF 必须写页数），脚本输出、日志和测试摘要不能冒充入口。终态通知第一行固定为「打开看：<路径/链接>（N 页）」，tsc/单测等验证信息只能排在后面。任务列表里点「确认交付」才算 done；点「退回修改」会转成部分完成并保留你写的原因，同一 Worker 继续改。待验收期间不会自动续派、不计入已完成，也不会释放交付写权。
• 派工确认卡改为聊天消息流内联卡：卡片作为消息列表的最后一段随对话一起滚动，不再悬浮在聊天上方、不遮挡输入框；配色、字体、间距和圆角沿用现有对话样式。桌面和手机视口都保持输入框可见。
• 显式「自动通过」权限：用户在本次指令里明确写“自动通过”时，send_task / spawn_agent 可以携带用户原话作为一次性授权。它只跳过没有 decision_points、也没有 origin=agent（“我加的”）约束的纯确认卡；有必答项、可选问题或我加的约束时仍在消息流里弹卡。每次授权单独记账（原话、时间、卡片/任务 ID、跳过原因），同一次派工重复投递或超过 10 分钟即失效，新的一次用户指令重新生效；“不要自动通过”“自动通过吗”这类否定/疑问不算授权。锚点校验、写权租约和合同校验从不会被跳过。
• 修复类任务的前后对比：Assignment 可以声明 symptom_path（你在界面上看到问题的具体路径/路由/链接）。声明后 done 必须带 symptom_reproduction，其中 path 必须与症状路径一致，before/after 都必须非空且不同；缺失、换了路径或前后相同都会被拒绝。派工确认卡会显示「症状路径」让你先确认复现口径。

Fixed

• 派工确认卡确认后能真正拉起新 Worker。以前确认一张“新建 Worker”的卡，Worker 启动前的合同校验会把刚由你确认的答案当成派单方自答，返回 DECISION_ANSWER_NOT_AUTHORED，卡回到待确认、Worker 不会启动；现在只有带“已经过人确认”标记的启动路径允许携带答案，未经确认的派工仍会被拒绝。新增回归测试覆盖两种情况。
• 手机端 PDF 在线阅读器恢复可用。真实手机（Android 14 / Chrome 107）缺少 Promise.withResolvers 和 AbortSignal.any，PDF.js 6 在创建 worker 前就抛错，页面只显示“PDF 阅读器加载失败，可下载后查看”，连 worker 都不会请求；现在在加载 PDF.js 前安装这两个标准 API 的兼容实现，PDF.js worker 也套同一层兼容脚本。PWA 的 Service Worker 版本升到 beidou-v19（内联派工卡、自动通过与人读验收也随这次壳更新进入手机），并让 PDF.js 资源走网络优先、只缓存成功响应，旧的坏缓存不会再挡住新 worker。
• 北斗开新对话时用当前 Beidou.md 生成的指令。以前控制面接上执行宿主里正在运行的北斗会话后，把那个会话的指令版本记成了自己的“当前版本”，之后每次开新对话都按它生成启动规格；宿主会话跨控制面重启一直活着，所以 10-19 以后新开的北斗对话全停在 10-19 的指令上，期间 Beidou.md 的修改都没有进入北斗。现在新对话按开对话那一刻的 Beidou.md 生成指令，续接的对话仍保持出生时的版本（D14）。新增回归测试：宿主上已有旧版本会话、控制面重启后开新对话，新会话的版本、宿主清单与 CLAUDE.md 都是当前版本。

Security

• 升级存在已公开漏洞、会挡住发布审计的依赖：前端 DOMPurify 3.4.17（严重）；后端 body-parser 2.4.0、zod 4.6.7（均为高危），以及 fastify、fast-uri、ip-address、qs 的补丁版本。Fleet 工具的入参校验改用 zod 4 自带的 v3 接口，北斗和 Worker 拿到的工具清单与升级前逐字节一致。