[Dogfooding] 完善设备日常任务体验：常用能力、有限授权与可信执行反馈

[Disdjj]

目标

让用户和 agent 在设备接入后，能够清楚地知道：当前能做什么、授权开放了什么、操作是否完成，以及如何调整或停止。

目前日常使用还可能要求用户自己发现工具、组合调用、解读机器返回值，并推断等待、权限和取消的含义。本 issue 跟踪一套更简单、易用、安全的日常任务体验：系统承担内部协调，用户保留对目标、资源范围和重要后果的决定权。

这是经产品讨论确认的方向性 issue，应分阶段交付。下列产品方案需要交互和实机验证；代码风险来自静态审阅，尚未作为真实设备故障复现。不要求在一个 PR 中实现全部方向。

代表性用户任务

让指定 agent 在接下来 30 分钟检查家庭服务器上的一个项目。只读取相关服务状态、指定目录和必要日志；需要重启时另行确认。我希望知道进度、拿到清楚的结果，离开页面后也能继续查看，并能结束这次授权。

用户应能完成这个任务，而无需手写多个路径 scope、逐条发现诊断命令、搬运完整日志或凭 JSON 判断是否成功。

一、提供少量可以直接使用的常用任务

首批候选：查看指定项目文件、检查指定服务健康、重启指定服务并检查恢复状态。通过实际 dogfooding 确定首批清单。

每项任务应具有明确的资源选择、参数、权限范围、环境前提、结果与失败解释。系统复用结构化命令及现有能力，完成必要的组合和结果整理；普通用户无需先手写 command profile。

例如，“检查服务健康”返回运行状态、资源摘要和相关错误，而不是要求用户找到五个工具再拼接判断。“重启并检查”需要区分重启动作的结果和后续健康检查结果。

安全性来自设备端可验证的命令及资源边界，不从任务名称或 shell 文本猜测。首期先交付少量完整任务，暂不扩展为通用工作流编辑器或任务市场。

二、按任务说明当前可用性和等待原因

设备在线不能单独证明某件事能完成。任务入口应综合实际可见能力、授权、目录范围和可验证的本机前提，给出具体状态与下一步：

• 可以尝试运行。
• 需要设备所有者开放指定范围。
• 缺少程序或配置。
• 等待设备连接或处理。
• 暂时无法确定，需要进一步检查。

检查结果须标明观测时间和适用范围；预检不能保证之后执行必然成功。内部的 delivery policy、TTL 等可放入高级项，常规交互用明确的执行时机和到期后果表达。

对接受的任务要有可解释的调度承诺：什么时候尝试、为什么仍在等待、何时过期、用户可以做什么。具体采用何种唤醒或消费机制由实现评审决定，不能用“在线”暗示“正在执行”。

三、按一次任务授权，减少永久放权和反复确认

把调用者、设备、资源、固定操作集合和有效期组合为一段可理解的授权摘要。用户批准后，范围内操作按同一规则执行；扩权和需要额外确认的动作重新征得授权。

首期从“单个项目 + 固定任务集合 + 有效期”开始，不引入要求用户编写的策略语言。使用现有限权/到期能力作为基础，设备本地授权始终是执行上限。

必须分别定义授权结束后对新请求、待执行任务、运行中任务的处理。界面显示“授权已结束”时要说明已经阻止或取消的部分，以及仍无法确认停止的部分。不能仅通过撤销 caller Key 就声称所有工作已停止。

四、以少读、少传作为默认任务行为

只读操作也可能返回私人文件、密钥或完整日志。“检查服务状态”的默认输出应限于必要信息：

• 优先状态摘要、相关错误和有限时间窗口。
• 明确允许访问的目录、字段、日志范围与输出上限。
• 按需获取详细资料，避免首次调用就拉取全部内容。
• 授权说明交代会读取什么、向谁返回，以及结果如何保留。

限制应在执行和数据返回边界实施；UI 折叠原文不构成数据最小化。脱敏只能声明可验证的范围，不能承诺任意日志绝不含敏感数据。

摘要要保留足够的证据和按需深入路径，防止为了简洁丢失关键诊断信息。较小的已授权范围内无需每多取一行都重复确认。

五、提供可信、可回看和可交接的任务结果

明确区分请求已接收、排队、执行中、程序执行失败、超时、中断、结果未知，以及经验证的业务完成。对无法解释的通用工具结果保留原始输出及不确定性，不凭文字或 HTTP 成功推断业务成功。

任务记录应帮助用户或下一位 agent 接手：谁发起、目标设备与资源、何时执行、做了什么、验证了什么、结果和产物在哪里。

• 从发起处可以继续找到结果，离开弹窗或刷新后可按所支持的持久化语义恢复查看。
• 历史结果标明时间，不冒充当前健康状态；提供独立的“检查当前状态”操作。
• 业务操作与检查结果分别记录，检查失败不能诱导盲目重复有副作用的操作。
• 结果可分享或交接的范围受权限约束；留存期限、大小和删除行为明确。
• 普通调用先定义最小必要元数据和受控结果，不默认永久保存全部 stdout、参数或敏感内容。

六、让多人使用、冲突和停止行为可理解

设备详情可以呈现当前用户有权查看的活跃任务、发起者和涉及资源。同一项目已有高影响操作时，告知具体冲突；对少数有明确资源语义的结构化操作，再设计串行或冲突拒绝规则。

不能从命令字符串猜测资源冲突，也不能把“显示了任务列表”当作已经提供互斥。任务与日志的可见权限和调用权限分别处理，共享任务能力不等于共享个人长期 Key。

提供容易找到的控制入口：暂停接受新任务、取消待执行任务、请求停止运行中任务、撤销访问。常用动作可以统一编排，但须展示实际达到的效果及未确认部分。恢复使用前说明哪些任务仍会执行；停止请求不代表外部副作用已被撤销。

七、呈现配置生效状态，并提供有依据的诊断

设置修改后区分“已保存”“等待设备应用”“已生效”“应用失败”。设备离线时不能提前声称新设置已经生效。

常用任务或预设升级时，展示权限、数据范围和依赖的变化；既有授权不能被解释为批准未来版本的全部新增能力。对收藏入口、已填写表单及待执行任务的影响也应可见。

提供受限的诊断入口，分别检查网关可达性、凭证/授权、后台服务、目标能力和必要依赖。建议必须来自当前证据；无法区分具体根因时明确未知。诊断资料经过数据裁剪并由用户控制分享，不收集无关文件或完整环境信息。

已有事实和待验证风险

审阅基线：7201827。以下用于确定优先级，不代表本轮做过实机复现：

1. deviceRuntime 主要在连接进入 ready 时触发 Mailbox drain。设备持续在线、一次 drain 结束后新增任务的消费时机需要验证；不能把已接收或在线状态等同于立即执行。
2. ResultView 对非错误响应使用绿色勾和 RESPONSE，没有据业务退出码解释结果。Mailbox processor 在 handler 正常返回后记录 succeeded，返回值内部仍可能含业务失败。需要清楚区分各层成功的含义。
3. 现有 Mailbox 契约 已明确 caller 授权在入队时快照，之后吊销 caller SK 不自动取消 operation；claimed cancellation 是协作式。任务授权及停止功能必须准确处理这些语义。
4. Dashboard 现状 的最近调用是本机/profile 历史；daemon 已有配置 revision 和保存后的 profile。新功能应复用现有基础，补齐产品层语义，不宣称从零实现。

分阶段交付与验收

阶段 A：让状态和结果可信

• 复现并验证“持续在线设备在 drain 结束后收到新 Mailbox 任务”的时序，明确消费、等待和过期行为；修复必要问题并提供回归证据。
• 对正常退出、非零退出、超时、结果未知及业务检查失败分别给出准确展示；Dashboard、CLI 与 agent 消费的事实一致。
• 任务从提交到终态可以被连续找到，历史结果有时间和目标，“检查当前状态”不会重新执行原有写操作。
• 停止操作区分已取消、已请求停止及无法确认，覆盖已排队和运行中任务。

阶段 B：交付少量有明确边界的常用任务

• 确定并交付至少三个实际高频任务，覆盖受限读取、服务诊断和一个需要授权的维护动作；用户无需手写 profile 或自行组合底层调用。
• 用真实设备验证完整任务：选择资源、查看范围、执行、解释结果、进一步诊断。
• 使用含模拟敏感数据的 fixture 验证读取范围、输出字段/大小、详细信息升级和结果留存边界。默认摘要之外的原始数据不能提前传到调用方再仅由 UI 隐藏。
• 配置保存、等待应用、生效、失败均可辨认；预设更新不能静默扩大授权。

阶段 C：以真实委托任务验证授权和协作

• 完成上述“指定 agent、单项目、30 分钟诊断”的代表性任务，明确范围内操作、扩权确认、授权结束和续期。
• 验证授权结束时的新请求、待执行与运行中任务；对既有快照语义的任何变更显式评审和说明。
• 验证两位调用者使用同一项目的场景：归属和潜在冲突可见，已定义串行约束的操作确实遵守约束；未提供的协调保证明确说明。
• 由未参与实现的人完成任务并解释授权范围、结果状态和停止效果，记录求助点、界面切换、重复输入及失败返工量。

各阶段都须保持 API/tb/Dashboard 对等，不产生管理旁路。实现按仓库要求通过 pnpm verify 与 pnpm turbo run build；真实外部资源验证每轮最多一次并留证据。完成标准是阶段验收与端到端用户任务成立，不能仅以组件、接口或脚本分别可运行替代。

与已有 issue 的分工

Issue	负责范围
#129	Dashboard 工作区、通用入口、导航和视觉交互；本 issue 定义其中任务、状态和结果应表达的产品语义
#130	设备快速配对、接入和能力配置；本 issue 延伸到接入后的长期任务使用
#108	结构化设备操作、进程及文件能力等执行基础；本 issue 将这些能力组织成完整用户任务
#112	agent-safe 机器可验证的 conformance/readiness；本 issue 负责面向日常使用的任务、授权与反馈体验，复用其事实来源
#110 / #111	安全元数据和策略注解；本 issue 的权限及结果说明消费这些契约
#117（已完成）	durable mailbox；复用已有任务状态、取消及持久化能力

实施时将具体变更关联到对应 issue/PR；已有 workstream 的交付可作为本 issue 的验收证据，不重复创建同一底层能力。

设计参考：Microsoft 人机交互指南 对能力说明、纠正与退出、操作后果及长期变化的建议，可用于评审本 issue 的用户流程。