feat: sync latest workspace changes

docs/prd/tools/task-file-protocol-prd.md

@@ -14,7 +14,7 @@ Lime 当前已经具备一套轻量 task file 底座，能够覆盖：
 - `typesetting`
 - `modal_resource_search`
 
-现有协议已经解决了“任务创建、状态读取、简单重试”的基础问题，但当 Lime 开始把图片生成、图片编辑、视频生成、视频编辑、自动化工作流、Claw 动态渲染统一收口到同一条主线时，现有 task file 还存在四类缺口：
+现有协议已经解决了“任务创建、状态读取、简单重试”的基础问题，但当 Lime 开始把图片生成、图片编辑、视频生成、视频编辑、自动化工作流、聊天区动态渲染统一收口到同一条主线时，现有 task file 还存在四类缺口：
 
 1. **顶层字段不够稳定**
    - 现在更像“任务记录壳”，还不是“统一任务协议信封”
@@ -27,7 +27,7 @@ Lime 当前已经具备一套轻量 task file 底座，能够覆盖：
 
 这会直接影响后续几条主线：
 
-- Claw 对话框中的动态占位图与结果替换
+- 聊天区中的动态占位图与结果替换
 - 图片生成 / 图片编辑 / 视频生成 / 视频编辑的统一观察面
 - 队列、重试、幂等、恢复、诊断能力
 - 类似竞品“统一任务面板”的可交付体验
@@ -297,7 +297,7 @@ Lime 当前已经具备一套轻量 task file 底座，能够覆盖：
 如果每次重试都新建任务文件，会带来这些问题：
 
 - 前端需要在旧卡片和新卡片之间重新绑定
-- Claw 动态替换更复杂
+- 聊天区动态替换更复杂
 - 统一任务列表会出现大量碎片任务
 - “这其实还是同一个任务”的语义丢失
 
@@ -561,7 +561,7 @@ Lime 当前已经具备一套轻量 task file 底座，能够覆盖：
 
 ## 10. 进度、错误与 UI 提示
 
-为了支撑 Claw 动态占位与结果替换，task file 不能只提供最终状态，还必须提供“可渲染的运行时信息”。
+为了支撑聊天区动态占位与结果替换，task file 不能只提供最终状态，还必须提供“可渲染的运行时信息”。
 
 ## 10.1 `progress`
 
@@ -716,7 +716,7 @@ Lime 当前已经具备一套轻量 task file 底座，能够覆盖：
 
 流程：
 
-1. 用户在 Claw 中触发 `image_generate`
+1. 用户在聊天区中触发 `image_generate`
 2. 创建 `task_family=image / task_type=image_generate`
 3. `relationships.slot_id` 绑定正文占位块
 4. 前端先显示占位图
@@ -779,7 +779,7 @@ Lime 当前已经具备一套轻量 task file 底座，能够覆盖：
 
 并且保证：
 
-- Claw、CLI、worker 读到的是同一份状态
+- 聊天区、CLI、worker 读到的是同一份状态
 - 可以支撑统一任务面板，而不需要第二套状态系统
 
 ---
@@ -831,5 +831,4 @@ task file 应该被设计成 Lime 的统一任务协议，而不是某个业务
 - **父子任务与依赖关系**
 - **结构化进度、错误、UI 提示**
 
-这样 Lime 才能把图片生成、图片编辑、视频生成、视频编辑、Claw 动态渲染、CLI、worker、统一任务面板全部收敛到同一条主链。
-
+这样 Lime 才能把图片生成、图片编辑、视频生成、视频编辑、聊天区动态渲染、CLI、worker、统一任务面板全部收敛到同一条主链。