Dust

CI 工作流仅授予 contents:read，并固定多个第三方 Action 的提交版本；依赖覆盖项和漏洞披露渠道也提供了一定安全治理证据，因此最小权限和依赖安全获得部分至充分分数。但材料没有展示 Agent 运行时权限、用户确认门、秘密信息处理或完整的数据流。文件系统测试明确涉及写入、重命名、删除、跨挂载复制后删除及清理，并验证失败提交不应保留未发布字节，但这些只是特定测试行为，不能证明产品级外部影响控制或通用回滚。README、站点链接和 LICENSE 提供来源线索，不过发布者身份仍未验证。

工作流、包配置和文件系统测试在 Node/Bun、连接器及沙箱文件语义上大体一致，并使用冻结锁文件安装、固定 Node 版本和明确的运行时探测。错误路径包含缺少参数、缺少工具、非挂载点、不支持标志、并发写入和超时等具体消息，因此普通诊断较好。扣分在于没有安装执行结果、服务可用性证据或覆盖整个 Agent 平台的错误处理材料；所给 CI 也只覆盖部分目录。

README 只笼统面向希望加速工作的用户；测试则显示 Linux 沙箱、conversation/Pod 根目录、Node 或 Bun、单写者和特定文件标志等环境假设。部分不支持行为会以 ENOTSUP、EACCES、EBUSY 或 ESTALE 显式呈现，形成有限边界证据，但没有完整能力矩阵。没有展示 Agent 的触发规则、任务选择精度或误触发防护，因此 trigger_precision 为零；部署与平台适配说明也很薄。

仓库名称、工作区结构和 Dust 命名较一致，README 指向用户及开发者文档；测试本身提供了具体使用场景。完整 MIT 文本清楚且与许可证元数据一致，故许可证满分。扣分在于 README 极简，没有本地安装步骤、配置说明、FAQ、系统化限制、版本策略或变更日志；package.json 的 1.0.0 仅是版本字段。SECURITY.md 给出报告渠道，版权和站点提供有限维护线索，但无法仅凭这些确定当前维护责任人与更新承诺。

文件系统脚本产生结构化 JSON 基准结果，并对读取、写入、并发、重命名、归档和权限语义作了细致断言，说明部分基础设施输出可供工程使用。平台“加速工作”的核心价值只有一句宣传，未附 Agent 产出示例、前后对比或目标任务证据，所以边际价值仅薄弱成立。材料没有成本、延迟、资源需求或收益权衡，cost_benefit 为零。

多数技术性判断可以追溯到具体配置、工作流和测试断言；文件系统行为在 TypeScript 基准、Shell 验收脚本及共享命名空间脚本间得到一定交叉支持。代码还明确区分已验证条件、允许的跳过项及未检查事项，例如不检查 Front 保存的修订数量。扣分在于核心 Agent 产品主张缺少代码路径、产品级示例和独立来源印证，且静态审查不能确认这些测试实际通过。