OpenClaw Linux 伴侣应用的 Completeness 评分规范五大类别范围与评分流程详解【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 项目地址: https://gitcode.com/GitHub_Trending/cl/openclaw本文围绕 OpenClaw 成熟度记分卡中 Linux 伴侣应用linux-companion-app表面的 Completeness完整性评分细则展开完整解读该细则定义的五大类别范围App Distribution、Gateway Connectivity、Chat and Sessions、Desktop Capabilities、Status and Diagnostics并结合apps/linux下的 Tauri v2 应用源码、taxonomy.yaml与qa/maturity-scores.yaml中的实际数据说明每一类别的评估口径、当前实现证据与分数含义。读完本文你可以准确理解该评分规范如何套用默认评分流程、如何为每个类别收集仓库内证据以及如何解读 Linux 伴侣应用当前的 Experimental 级成熟度评分。一、细则的定位claw-score 技能下的表面完整性评分标准linux-companion-app.md 是一份评分细则rubric其开头的定位语句是在为linux-companion-app表面分配类别级 Completeness 分数时使用本细则。它隶属于 claw-score 技能该技能管理的是 OpenClaw 本地版本openclaw-local的成熟度记分卡工作流权威数据源是手工维护的 taxonomy.yaml其中定义了 surface、level、QA profile、类别、feature coverage ID、文档引用与完整性细则路径completeness_instructions聚合分数提交在 qa/maturity-scores.yaml记录 Quality、Completeness 与 LTS 审查状态细则文件本身只定义类别范围Category Scope与表面特有的评分要求通用的默认评分流程由 SKILL.md 的 Default Completeness Process 一节统一规定。在 taxonomy.yaml 中Linux 伴侣应用登记的表面信息为字段取值含义idlinux-app表面 ID细则文件名linux-companion-app与其一一对应nameLinux companion app表面展示名familyplatform-app归属于平台应用家族level/level_codeplanned/M0当前成熟度层级为规划中rationaleDocs say native Linux companion apps are planned; Gateway is the supported Linux path today.定级理由文档声明原生 Linux 伴侣应用为规划项当前 Linux 的受支持路径是 Gatewaycompleteness_instructionsreferences/completeness/linux-companion-app.md指向本文所解读的细则文件需要注意细则中的表面名linux-companion-app是评分口径的称呼taxonomy 中对应的表面 ID 是linux-app两者指同一个对象。二、细则核心内容五大类别的范围定义细则正文的全部实质内容就是 Category Scope 一节它为五个类别分别列出了需要逐条核对的能力范围。这是评估时不可删减的检查清单下面逐类别完整继承原文范围并给出仓库内的对应实现证据。2.1 App Distribution应用分发细则范围App Distribution: Native app package原生应用包、Distro package targets发行版包目标、Official release metadata官方发布元数据对应到 taxonomy.yaml 的三个 feature 及 coverage IDlinux-app.native-app-package原生 Linux 伴侣应用包的可得性与安装路径linux-app.distro-package-targets发行版包目标、desktop 文件、图标、自启动与更新元数据linux-app.official-release-metadata供下游控制台使用的官方发布元数据。仓库内的实现证据集中在 apps/linux/README.md 的 Packaging 与 Releases 一节本地打包命令同时产出.deb与 AppImage 两种 bundle产物落在target/release/bundle/{deb,appimage}/已发布的 AMD64 AppImage 基于 Ubuntu 22.04 构建要求 glibc 2.35 且libstdc提供GLIBCXX_3.4.30Ubuntu 22.04 与 Debian 12 满足该 ABI 下限RHEL 9 / Rocky 9 的 glibc 2.34 不满足解压运行也绕不开该限制发布流程通过手动派发Linux App Release Request提供既有 stable 发布 tag预发布 tag 会因 semver 后缀破坏 Debian 升级排序而被拒绝触发Linux App Release构建自经校验的 tag SHA并将 bundle 与SHA256SUMS.linux-app.txt校验和文件挂到该 tag 的发布页图标与 tray 资产有固定的再生成脚本rsvg-convert ImageMagickdesktop 集成所需的图标来源是 icon.svg托盘与 icon-tile.svg应用/包图标。2.2 Gateway Connectivity网关连接细则范围Gateway Connectivity: Local Gateway attach and status本地 Gateway 附着与状态、Gateway pairing and auth配对与认证、Remote mode远程模式、Local and remote resource boundaries本地与远程资源边界对应 featuretaxonomy.yamllinux-app.local-gateway-attach-and-status、linux-app.gateway-pairing-and-auth、linux-app.remote-mode、linux-app.local-and-remote-resource-boundaries参考文档为 docs/platforms/linux.md、docs/gateway/pairing.md、docs/gateway/remote.md。apps/linux/README.md 描述的第一次运行设置覆盖这些范围On this computer按需安装 CLI 与托管 Node 运行时然后把 Gateway 作为 systemd 用户服务启动release 构建自动安装 stable 通道开发构建则询问通道并预选 DevelopmentOn another computer不安装、不启动本地 Gateway 服务直接连接已存在的 Gateway——可选附近发现的 Gateway、手工输入 Gateway URL或选择SSH tunnel并填写usergateway-host认证方面展开Gateway authentication后可提供 Gateway token 或密码公开直连必须使用 HTTPS 或安全 WebSocket明文 HTTP/WS 只适用于回环、受信私网或 Tailnet资源边界方面有一条明确的安全策略若 Gateway 配置了 TLS 证书指纹pin由于内嵌浏览器无法强制执行证书绑定应用会安全地拒绝直连而引导走 SSH tunnel保存的远程凭据支持字面值与环境变量/文件支撑的 secret 引用其中 exec 与共享存储引用必须在所属 Gateway 主机上解析桌面伴侣不会把远程 provider secret 拷贝到本机。源码层面连接逻辑分布在 discovery.rsBonjour 发现、gateway.rs本地网关操作、gateway_ws.rsWebSocket 传输、remote_gateway.rs远程模式以及 Tauri 自动生成的命令权限文件 connect_discovered_gateway.toml、connect_remote_gateway.toml、discover_gateways.toml 等表明发现—附着—远程连接是受 Tauri capability 显式授权的受控命令集。2.3 Chat and Sessions聊天与会话细则范围Chat and Sessions: Native Linux chat window原生 Linux 聊天窗口、Transcript会话记录、Gateway chat transportGateway 聊天传输对应 featurelinux-app.native-linux-chat-window、linux-app.transcript、linux-app.gateway-chat-transport。taxonomy 对该类别的描述细化为原生聊天窗口的行为与操作员可见的验证方式transcript、composer、会话选择器、模型选择器、发送/中止/追问控制以及从 Linux 桌面客户端走 Gateway WebSocket 的聊天传输参考 docs/gateway/protocol.md 与 docs/web/webchat.md。应用侧的证据主窗口内加载 Dashboard 组件选定 Gateway 的 Control UI 在路由作用域窗口中打开可让多个 Gateway 面板同时保持连接见 docs/platforms/linux.md 的 Desktop companion 小节Quick Chat 小组件在 quickchat.rs 与 quickchat.html、quickchat.js 中实现它声明 Gateway 的inline-widgets能力把托管的show_widget结果渲染在隔开的子 WebView 中——父 Quick Chat WebView 是唯一被授予 Tauri 命令的一方widget WebView 不匹配任何 capability、因此没有 IPC 访问权限只接受能力作用域下/__openclaw__/canvas/documents/路由的 assistant 消息 widget 预览并阻止导航离开原始文档与原生客户端保持一致Quick Chat 不暴露 Control UI 的sendPrompt桥接。2.4 Desktop Capabilities桌面能力细则范围这是五个类别中范围最宽的一项Desktop Capabilities: Linux desktop permissions通知、麦克风、屏幕、摄像头、辅助功能、portal 与桌面环境 API、Secret storageGateway token、设备身份、审批 socket token 与应用设置的密钥存储、Sandbox/package postureFlatpak/Snap/AppImage 或系统包的沙箱/打包形态、Linux native node identity原生节点身份与能力通告、Host command executionsystem.run等相关桌面工具的主机命令执行、Desktop tools屏幕、摄像头、通知、Canvas 与本地命令执行、Linux native Talkpush-to-talk、语音唤醒与转写、Microphone capture麦克风/屏幕/摄像头捕获与本地媒体附件流程、Native media permissions原生媒体权限与前台/后台行为。仓库内的部分实现证据通知走各平台的系统通知服务Linux 通过notify-rust调用桌面通知服务实现见 notify.rs审批交互有 pending_approvals.rs对应 taxonomy 中引用的 docs/tools/exec-approvals.md媒体播放依赖 GStreamer 插件WebM/VP9、Opus、Vorbis、WAV 通常由plugins-good支持H.264/MP4、AAC、MP3 需要libav和/或plugins-bad.deb使用宿主插件并声明这三个包为依赖AppImage 则内带所需 GStreamer 媒体框架打包脚本 stage-appimage-gstreamer.sh 只暂存这一受控的媒体能力集防止宿主的可选插件把无关系统库带进 AppImage 依赖闭包打包形态上当前实现是.deb AppImage尚无 Flatpak/Snap这正是该类别打包/沙箱形态评估点的现状依据。2.5 Status and Diagnostics状态与诊断细则范围Status and Diagnostics: Native Linux app readiness应用就绪状态、Gateway health/status display网关健康/状态展示、Log/transcript opening日志/会话记录打开、Doctor/repair affordances诊断/修复入口、Linux tray/status item托盘/状态项、Runtime status row运行时状态行、Desktop-environment integrationGNOME/KDE/Wayland/X11 下的桌面环境集成对应 feature 覆盖linux-app.native-linux-app-readiness、linux-app.gateway-health-status-display、linux-app.log-transcript-opening、linux-app.doctor-repair-affordances、linux-app.linux-tray-status-item、linux-app.runtime-status-row、linux-app.desktop-environment-integration参考文档含 docs/gateway/doctor.md。实现证据托盘常驻窗口关闭后应用仍从系统托盘可用托盘提供Stop Gateway/Restart Gateway请求优雅停机运行中的工作可能延迟完成与Start Gateway把停机的本地 Gateway 重新拉起来实现见 tray.rs服务生命周期委托给 CLI 管理的 systemd 用户服务install/start/stop/restart 全部委托给openclaw gateway本地服务的挂接/状态判断见 gateway.rs 与 installer.rs系统休眠协同有专门实现 gateway_sleep.rs 与 gateway_sleep_logind.rs通过 logind 监听休眠并配有原生单元测试 src-tauri/tests/logind_sleep.rs更新检查在启动后不久以及托盘菜单的Check for Updates中触发AppImage 安装就地下载并校验签名更新后等待Restart to update包管理器托管的.deb安装则由系统包管理器保持所有权、改为链接到发布下载页实现见 updater.rs。三、评分流程细则如何被套用细则本身只给出类别范围真正的评分动作遵循 SKILL.md 定义的默认流程与打分问题。3.1 默认完整性流程Completeness 衡量的是面向该表面目标操作者角色的预期工作流暴露程度而不是测试广度或实现质量。对每个类别要回答的问题目标用户/操作员能否端到端完成该类别工作流taxonomy 中的 feature 是否作为受支持的能力存在而非孤立的实现碎片关键生命周期阶段是否齐备设置setup、正常运行、状态/检查、恢复recovery以及相关的升级或移除该表面的重要环境、provider、平台、渠道或安全分支是否都存在已知缺口是否造成主要用户可见能力分支缺失默认导向当类别支持完整工作流时给更高分当只有 happy path、重要分支未实现/未记录、或缺少恢复/状态路径时降分不因测试薄弱而降低 Completeness那是 Coverage 的事也不因实现脆弱而降低那是 Quality 的事。3.2 分数档位BandsClawesome95-100覆盖预期工作流、变体与恢复分支完整仅余小幅打磨缺口Stable80-95预期工作流集合大体齐备仅缺有限的分支Beta70-80主工作流存在但仍有重要分支或恢复路径缺失Alpha50-70只有部分能力集用户能完成部分核心任务而非完整预期工作流Experimental0-50类别只暴露出预期能力的碎片。3.3 Linux 伴侣应用当前的记分状态qa/maturity-scores.yaml 中linux-app表面的最新聚合结果last_score_run完成于 2026-08-02process_version: 3维度分数档位备注Quality19Experimental五个类别均为 19Completeness21Experimental五个类别均为 21LTSnone—受支持类别 0/5这一状态与 taxonomy 中plannedM0的定级相互印证细则所列五大类别的范围清单就是每轮评分时逐条核对该能力分支是否已从碎片走向完整工作流的检查表。四、证据收集与校验方式按 SKILL.md 的 Scoring Workflow评估该表面时的标准步骤读取 taxonomy.yaml 中linux-app表面定义读取本细则linux-companion-app.md的类别范围从公开仓库证据中收集文档如 docs/platforms/linux.md、源码apps/linux、测试如 apps/linux/tests/first_run.py、apps/linux/tests/packaged_runtime_smoke.py与 QA 场景元数据优先使用既有发布 profile 的qa-evidence.json工件作为已执行的证明仅依据公开或脱敏工件证据更新 qa/maturity-scores.yaml 中 Quality、Completeness 与 LTS 状态在仓库根目录运行 schema 校验通过extensions/qa-lab/src/scorecard-taxonomy.ts的readValidatedQaMaturityScoreSources校验taxonomy.yaml与qa/scenarios/index.yaml及分数源文档改动跑pnpm check:docscoverage ID 或 profile 成员变化时跑pnpm openclaw qa coverage --json。CI 侧的配套校验见 apps/linux/README.md Packaging 一节Linux Appworkflow 对受影响的 PR 执行 Rust 格式化、Linux 与 macOS 上的cargo test --locked --all-targets以及打包运行时 ABI 扫描器单测在分支上手动派发该 workflow 可进一步构建.deb与 AppImage、跑两个原生 first-run 用例与打包 AppImage 运行时冒烟产物以openclaw-linux-companionworkflow artifact 上传该验证不发布版本。五、小结从细则到分数这份 12 行的细则之所以重要是因为它把Linux 伴侣应用做得有多完整这一主观判断收敛成了五个可逐条核对的类别范围App Distribution原生包、发行版目标与发布元数据——对应.deb/AppImage 双 bundle、glibc 2.35 ABI 下限与SHA256SUMS.linux-app.txt发布链Gateway Connectivity本地附着、配对认证、远程模式与本地/远程资源边界——对应 Bonjour 发现、systemd 用户服务委托、SSH tunnel 与 TLS pin 拒绝策略Chat and Sessions原生聊天窗口、transcript 与 Gateway WebSocket 传输——对应路由作用域的 Control UI 窗口与 capability 隔离的 Quick Chat widgetDesktop Capabilities桌面权限、密钥存储、打包形态、节点身份、主机命令执行、Talk 与媒体捕获——对应notify-rust通知、pending approvals、GStreamer 媒体集等已实现项以及 Flatpak/Snap 等尚不存在的形态项Status and Diagnostics就绪状态、健康展示、日志打开、Doctor 入口、托盘与桌面环境集成——对应托盘 Stop/Restart/Start Gateway、logind 休眠协同与更新状态提示。评估时以 taxonomy 的 feature 清单为应然、以apps/linux源码与 docs/platforms/linux.md 为实然按第五节的校验命令保持分数与证据一致即可为该表面产出可复现的 Completeness 分数。当前该表面处于 M0/planned、Completeness 21Experimental的状态意味着细则所列多数能力分支仍处于碎片到完整工作流的演进中——这也正是这份评分细则持续存在的意义为每一轮能力补齐提供明确的对账清单。【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 项目地址: https://gitcode.com/GitHub_Trending/cl/openclaw创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenClaw Linux 伴侣应用的 Completeness 评分规范：五大类别范围与评分流程详解
OpenClaw Linux 伴侣应用的 Completeness 评分规范五大类别范围与评分流程详解【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 项目地址: https://gitcode.com/GitHub_Trending/cl/openclaw本文围绕 OpenClaw 成熟度记分卡中 Linux 伴侣应用linux-companion-app表面的 Completeness完整性评分细则展开完整解读该细则定义的五大类别范围App Distribution、Gateway Connectivity、Chat and Sessions、Desktop Capabilities、Status and Diagnostics并结合apps/linux下的 Tauri v2 应用源码、taxonomy.yaml与qa/maturity-scores.yaml中的实际数据说明每一类别的评估口径、当前实现证据与分数含义。读完本文你可以准确理解该评分规范如何套用默认评分流程、如何为每个类别收集仓库内证据以及如何解读 Linux 伴侣应用当前的 Experimental 级成熟度评分。一、细则的定位claw-score 技能下的表面完整性评分标准linux-companion-app.md 是一份评分细则rubric其开头的定位语句是在为linux-companion-app表面分配类别级 Completeness 分数时使用本细则。它隶属于 claw-score 技能该技能管理的是 OpenClaw 本地版本openclaw-local的成熟度记分卡工作流权威数据源是手工维护的 taxonomy.yaml其中定义了 surface、level、QA profile、类别、feature coverage ID、文档引用与完整性细则路径completeness_instructions聚合分数提交在 qa/maturity-scores.yaml记录 Quality、Completeness 与 LTS 审查状态细则文件本身只定义类别范围Category Scope与表面特有的评分要求通用的默认评分流程由 SKILL.md 的 Default Completeness Process 一节统一规定。在 taxonomy.yaml 中Linux 伴侣应用登记的表面信息为字段取值含义idlinux-app表面 ID细则文件名linux-companion-app与其一一对应nameLinux companion app表面展示名familyplatform-app归属于平台应用家族level/level_codeplanned/M0当前成熟度层级为规划中rationaleDocs say native Linux companion apps are planned; Gateway is the supported Linux path today.定级理由文档声明原生 Linux 伴侣应用为规划项当前 Linux 的受支持路径是 Gatewaycompleteness_instructionsreferences/completeness/linux-companion-app.md指向本文所解读的细则文件需要注意细则中的表面名linux-companion-app是评分口径的称呼taxonomy 中对应的表面 ID 是linux-app两者指同一个对象。二、细则核心内容五大类别的范围定义细则正文的全部实质内容就是 Category Scope 一节它为五个类别分别列出了需要逐条核对的能力范围。这是评估时不可删减的检查清单下面逐类别完整继承原文范围并给出仓库内的对应实现证据。2.1 App Distribution应用分发细则范围App Distribution: Native app package原生应用包、Distro package targets发行版包目标、Official release metadata官方发布元数据对应到 taxonomy.yaml 的三个 feature 及 coverage IDlinux-app.native-app-package原生 Linux 伴侣应用包的可得性与安装路径linux-app.distro-package-targets发行版包目标、desktop 文件、图标、自启动与更新元数据linux-app.official-release-metadata供下游控制台使用的官方发布元数据。仓库内的实现证据集中在 apps/linux/README.md 的 Packaging 与 Releases 一节本地打包命令同时产出.deb与 AppImage 两种 bundle产物落在target/release/bundle/{deb,appimage}/已发布的 AMD64 AppImage 基于 Ubuntu 22.04 构建要求 glibc 2.35 且libstdc提供GLIBCXX_3.4.30Ubuntu 22.04 与 Debian 12 满足该 ABI 下限RHEL 9 / Rocky 9 的 glibc 2.34 不满足解压运行也绕不开该限制发布流程通过手动派发Linux App Release Request提供既有 stable 发布 tag预发布 tag 会因 semver 后缀破坏 Debian 升级排序而被拒绝触发Linux App Release构建自经校验的 tag SHA并将 bundle 与SHA256SUMS.linux-app.txt校验和文件挂到该 tag 的发布页图标与 tray 资产有固定的再生成脚本rsvg-convert ImageMagickdesktop 集成所需的图标来源是 icon.svg托盘与 icon-tile.svg应用/包图标。2.2 Gateway Connectivity网关连接细则范围Gateway Connectivity: Local Gateway attach and status本地 Gateway 附着与状态、Gateway pairing and auth配对与认证、Remote mode远程模式、Local and remote resource boundaries本地与远程资源边界对应 featuretaxonomy.yamllinux-app.local-gateway-attach-and-status、linux-app.gateway-pairing-and-auth、linux-app.remote-mode、linux-app.local-and-remote-resource-boundaries参考文档为 docs/platforms/linux.md、docs/gateway/pairing.md、docs/gateway/remote.md。apps/linux/README.md 描述的第一次运行设置覆盖这些范围On this computer按需安装 CLI 与托管 Node 运行时然后把 Gateway 作为 systemd 用户服务启动release 构建自动安装 stable 通道开发构建则询问通道并预选 DevelopmentOn another computer不安装、不启动本地 Gateway 服务直接连接已存在的 Gateway——可选附近发现的 Gateway、手工输入 Gateway URL或选择SSH tunnel并填写usergateway-host认证方面展开Gateway authentication后可提供 Gateway token 或密码公开直连必须使用 HTTPS 或安全 WebSocket明文 HTTP/WS 只适用于回环、受信私网或 Tailnet资源边界方面有一条明确的安全策略若 Gateway 配置了 TLS 证书指纹pin由于内嵌浏览器无法强制执行证书绑定应用会安全地拒绝直连而引导走 SSH tunnel保存的远程凭据支持字面值与环境变量/文件支撑的 secret 引用其中 exec 与共享存储引用必须在所属 Gateway 主机上解析桌面伴侣不会把远程 provider secret 拷贝到本机。源码层面连接逻辑分布在 discovery.rsBonjour 发现、gateway.rs本地网关操作、gateway_ws.rsWebSocket 传输、remote_gateway.rs远程模式以及 Tauri 自动生成的命令权限文件 connect_discovered_gateway.toml、connect_remote_gateway.toml、discover_gateways.toml 等表明发现—附着—远程连接是受 Tauri capability 显式授权的受控命令集。2.3 Chat and Sessions聊天与会话细则范围Chat and Sessions: Native Linux chat window原生 Linux 聊天窗口、Transcript会话记录、Gateway chat transportGateway 聊天传输对应 featurelinux-app.native-linux-chat-window、linux-app.transcript、linux-app.gateway-chat-transport。taxonomy 对该类别的描述细化为原生聊天窗口的行为与操作员可见的验证方式transcript、composer、会话选择器、模型选择器、发送/中止/追问控制以及从 Linux 桌面客户端走 Gateway WebSocket 的聊天传输参考 docs/gateway/protocol.md 与 docs/web/webchat.md。应用侧的证据主窗口内加载 Dashboard 组件选定 Gateway 的 Control UI 在路由作用域窗口中打开可让多个 Gateway 面板同时保持连接见 docs/platforms/linux.md 的 Desktop companion 小节Quick Chat 小组件在 quickchat.rs 与 quickchat.html、quickchat.js 中实现它声明 Gateway 的inline-widgets能力把托管的show_widget结果渲染在隔开的子 WebView 中——父 Quick Chat WebView 是唯一被授予 Tauri 命令的一方widget WebView 不匹配任何 capability、因此没有 IPC 访问权限只接受能力作用域下/__openclaw__/canvas/documents/路由的 assistant 消息 widget 预览并阻止导航离开原始文档与原生客户端保持一致Quick Chat 不暴露 Control UI 的sendPrompt桥接。2.4 Desktop Capabilities桌面能力细则范围这是五个类别中范围最宽的一项Desktop Capabilities: Linux desktop permissions通知、麦克风、屏幕、摄像头、辅助功能、portal 与桌面环境 API、Secret storageGateway token、设备身份、审批 socket token 与应用设置的密钥存储、Sandbox/package postureFlatpak/Snap/AppImage 或系统包的沙箱/打包形态、Linux native node identity原生节点身份与能力通告、Host command executionsystem.run等相关桌面工具的主机命令执行、Desktop tools屏幕、摄像头、通知、Canvas 与本地命令执行、Linux native Talkpush-to-talk、语音唤醒与转写、Microphone capture麦克风/屏幕/摄像头捕获与本地媒体附件流程、Native media permissions原生媒体权限与前台/后台行为。仓库内的部分实现证据通知走各平台的系统通知服务Linux 通过notify-rust调用桌面通知服务实现见 notify.rs审批交互有 pending_approvals.rs对应 taxonomy 中引用的 docs/tools/exec-approvals.md媒体播放依赖 GStreamer 插件WebM/VP9、Opus、Vorbis、WAV 通常由plugins-good支持H.264/MP4、AAC、MP3 需要libav和/或plugins-bad.deb使用宿主插件并声明这三个包为依赖AppImage 则内带所需 GStreamer 媒体框架打包脚本 stage-appimage-gstreamer.sh 只暂存这一受控的媒体能力集防止宿主的可选插件把无关系统库带进 AppImage 依赖闭包打包形态上当前实现是.deb AppImage尚无 Flatpak/Snap这正是该类别打包/沙箱形态评估点的现状依据。2.5 Status and Diagnostics状态与诊断细则范围Status and Diagnostics: Native Linux app readiness应用就绪状态、Gateway health/status display网关健康/状态展示、Log/transcript opening日志/会话记录打开、Doctor/repair affordances诊断/修复入口、Linux tray/status item托盘/状态项、Runtime status row运行时状态行、Desktop-environment integrationGNOME/KDE/Wayland/X11 下的桌面环境集成对应 feature 覆盖linux-app.native-linux-app-readiness、linux-app.gateway-health-status-display、linux-app.log-transcript-opening、linux-app.doctor-repair-affordances、linux-app.linux-tray-status-item、linux-app.runtime-status-row、linux-app.desktop-environment-integration参考文档含 docs/gateway/doctor.md。实现证据托盘常驻窗口关闭后应用仍从系统托盘可用托盘提供Stop Gateway/Restart Gateway请求优雅停机运行中的工作可能延迟完成与Start Gateway把停机的本地 Gateway 重新拉起来实现见 tray.rs服务生命周期委托给 CLI 管理的 systemd 用户服务install/start/stop/restart 全部委托给openclaw gateway本地服务的挂接/状态判断见 gateway.rs 与 installer.rs系统休眠协同有专门实现 gateway_sleep.rs 与 gateway_sleep_logind.rs通过 logind 监听休眠并配有原生单元测试 src-tauri/tests/logind_sleep.rs更新检查在启动后不久以及托盘菜单的Check for Updates中触发AppImage 安装就地下载并校验签名更新后等待Restart to update包管理器托管的.deb安装则由系统包管理器保持所有权、改为链接到发布下载页实现见 updater.rs。三、评分流程细则如何被套用细则本身只给出类别范围真正的评分动作遵循 SKILL.md 定义的默认流程与打分问题。3.1 默认完整性流程Completeness 衡量的是面向该表面目标操作者角色的预期工作流暴露程度而不是测试广度或实现质量。对每个类别要回答的问题目标用户/操作员能否端到端完成该类别工作流taxonomy 中的 feature 是否作为受支持的能力存在而非孤立的实现碎片关键生命周期阶段是否齐备设置setup、正常运行、状态/检查、恢复recovery以及相关的升级或移除该表面的重要环境、provider、平台、渠道或安全分支是否都存在已知缺口是否造成主要用户可见能力分支缺失默认导向当类别支持完整工作流时给更高分当只有 happy path、重要分支未实现/未记录、或缺少恢复/状态路径时降分不因测试薄弱而降低 Completeness那是 Coverage 的事也不因实现脆弱而降低那是 Quality 的事。3.2 分数档位BandsClawesome95-100覆盖预期工作流、变体与恢复分支完整仅余小幅打磨缺口Stable80-95预期工作流集合大体齐备仅缺有限的分支Beta70-80主工作流存在但仍有重要分支或恢复路径缺失Alpha50-70只有部分能力集用户能完成部分核心任务而非完整预期工作流Experimental0-50类别只暴露出预期能力的碎片。3.3 Linux 伴侣应用当前的记分状态qa/maturity-scores.yaml 中linux-app表面的最新聚合结果last_score_run完成于 2026-08-02process_version: 3维度分数档位备注Quality19Experimental五个类别均为 19Completeness21Experimental五个类别均为 21LTSnone—受支持类别 0/5这一状态与 taxonomy 中plannedM0的定级相互印证细则所列五大类别的范围清单就是每轮评分时逐条核对该能力分支是否已从碎片走向完整工作流的检查表。四、证据收集与校验方式按 SKILL.md 的 Scoring Workflow评估该表面时的标准步骤读取 taxonomy.yaml 中linux-app表面定义读取本细则linux-companion-app.md的类别范围从公开仓库证据中收集文档如 docs/platforms/linux.md、源码apps/linux、测试如 apps/linux/tests/first_run.py、apps/linux/tests/packaged_runtime_smoke.py与 QA 场景元数据优先使用既有发布 profile 的qa-evidence.json工件作为已执行的证明仅依据公开或脱敏工件证据更新 qa/maturity-scores.yaml 中 Quality、Completeness 与 LTS 状态在仓库根目录运行 schema 校验通过extensions/qa-lab/src/scorecard-taxonomy.ts的readValidatedQaMaturityScoreSources校验taxonomy.yaml与qa/scenarios/index.yaml及分数源文档改动跑pnpm check:docscoverage ID 或 profile 成员变化时跑pnpm openclaw qa coverage --json。CI 侧的配套校验见 apps/linux/README.md Packaging 一节Linux Appworkflow 对受影响的 PR 执行 Rust 格式化、Linux 与 macOS 上的cargo test --locked --all-targets以及打包运行时 ABI 扫描器单测在分支上手动派发该 workflow 可进一步构建.deb与 AppImage、跑两个原生 first-run 用例与打包 AppImage 运行时冒烟产物以openclaw-linux-companionworkflow artifact 上传该验证不发布版本。五、小结从细则到分数这份 12 行的细则之所以重要是因为它把Linux 伴侣应用做得有多完整这一主观判断收敛成了五个可逐条核对的类别范围App Distribution原生包、发行版目标与发布元数据——对应.deb/AppImage 双 bundle、glibc 2.35 ABI 下限与SHA256SUMS.linux-app.txt发布链Gateway Connectivity本地附着、配对认证、远程模式与本地/远程资源边界——对应 Bonjour 发现、systemd 用户服务委托、SSH tunnel 与 TLS pin 拒绝策略Chat and Sessions原生聊天窗口、transcript 与 Gateway WebSocket 传输——对应路由作用域的 Control UI 窗口与 capability 隔离的 Quick Chat widgetDesktop Capabilities桌面权限、密钥存储、打包形态、节点身份、主机命令执行、Talk 与媒体捕获——对应notify-rust通知、pending approvals、GStreamer 媒体集等已实现项以及 Flatpak/Snap 等尚不存在的形态项Status and Diagnostics就绪状态、健康展示、日志打开、Doctor 入口、托盘与桌面环境集成——对应托盘 Stop/Restart/Start Gateway、logind 休眠协同与更新状态提示。评估时以 taxonomy 的 feature 清单为应然、以apps/linux源码与 docs/platforms/linux.md 为实然按第五节的校验命令保持分数与证据一致即可为该表面产出可复现的 Completeness 分数。当前该表面处于 M0/planned、Completeness 21Experimental的状态意味着细则所列多数能力分支仍处于碎片到完整工作流的演进中——这也正是这份评分细则持续存在的意义为每一轮能力补齐提供明确的对账清单。【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 项目地址: https://gitcode.com/GitHub_Trending/cl/openclaw创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考