# V1.x 未完整实现功能清单

> Language: 简体中文
>
> English default entry: [English](../../en/planning/v1.x-incomplete-feature-inventory.md)
>
> Translation status: current

更新时间：2026-07-21

代码快照：`main` 的审计基线为 `f75a070`（2026-07-18）。本页的日期表示文档整理时间，不表示新增 release tag。

## 文档范围

本文是基于当前 `main` 代码的能力快照，用于区分 CLI 可调用行为、只存在于 library/test 的边界、alpha smoke 证据、缺失的生产集成和外部前置条件。它不是 changelog，也不会把内部 capability marker 解释成已发布版本。

已完成的实施历史归 release notes、tag 和 Git 历史维护。配套的[实施计划](V1.x真实运行时能力补齐实施计划.md)只保留剩余工作和依赖顺序。

W3-L08 macOS 本机状态更新（2026-07-27）：真实子进程回归已证明 `ProviderRunAsIdentity::Current` 保持当前 daemon EUID/EGID；macOS 显式 Unix identity 继续在 spawn 前 fail-closed；group/other-writable non-sticky Skill ancestor 在创建前被直接拒绝。该结果不替代跨 UID/root handoff、目录 TOCTOU、真实 vault authority 或三平台 production evidence。

W3-L09 macOS 本机状态更新（2026-07-27）：显式注入的 `MacosKeychainCredentialVault` 已实现 `vault://keychain/<service>/<account>` 的当前用户 Keychain 查询、严格 ref/脱敏和 Keychain 错误 leak-scan 回归；默认生产 vault 继续 fail-closed。它不构成获批 Keychain/KMS authority，也不替代跨 UID、完整 TOCTOU/leak scan 或三平台 production evidence。

## 版本与证据语义

| 信号 | 当前事实 | 不能证明 |
| --- | --- | --- |
| Cargo 与 CLI 版本 | `1.11.5-alpha` / `V1.11.5-alpha` | 已达到生产就绪 |
| Git tag | tag 到 `v1.11.5-alpha` 为止；不存在 `v1.12` 至 `v1.17` release tag | 后续内部 marker 是已发布版本 |
| `version.data.runtime_mode` | 包含直到 `v1x_closure_gate_v1.17.6` 的 capability/evidence ID | 语义版本序列或发布历史 |
| `release check` | 默认输入下返回 `status:"ready"`、7 个 warning gate 和 `closure.status:"ready_with_external_blockers"`；8 个 required gate 通过，另列 5 个 external blocker | 命令现场执行了 Cargo/CI、外部服务、平台集成或生产凭据检查 |
| 生产状态 | 仓库仍是带受控本地边界的 alpha 实现 | 生产 daemon、平台、硬件、遥测或分发已经就绪 |

`runtime_mode`、release gate 和源码标识中的 V1.12-V1.17 标签，是 `v1.11.5-alpha` tag 之后加入的 legacy 内部 evidence ID。它们为兼容性继续保留，但不能描述为已经发布的版本。

![V1.x 剩余能力地图](../../../assets/v1x-remaining-capability-map.zh-CN.svg)

## 状态口径

| 状态 | 含义 |
| --- | --- |
| 可调用 | 当前 CLI/runtime 路径会在文档边界内执行该行为 |
| Library/Test 边界 | 代码与测试存在，但生产 runtime 或 CLI 没有端到端接线 |
| 受控 Alpha | 路径仍是本地、合成、模拟、fake、fixture 或 smoke-only |
| 未实现 | 所需实现不存在 |
| 外部前置条件 | 仍需要硬件、凭据、仓库权限、平台测试设施或运维后端 |

安全拒绝不是未实现功能。例如拒绝未授权 provider、MCP tool、Lua host handle 或 hardware raw handle，是已实现的安全不变量，不属于 backlog。

## 当前缺口矩阵

| 能力域 | 当前代码边界 | 剩余生产缺口 | 优先级 |
| --- | --- | --- | --- |
| Release evidence | W0-L01 至 W0-L10 已完成：EvidenceEnvelope、真实 argv capture、platform bundle、coverage/freshness/trusted-executor policy、readback verifier 均已接线；默认 alpha 仍会展示 declaration/fixture，6 个 performance gate 仍是 `unmeasured` | 新 tag 上的 GitHub-hosted workflow 实跑、声明生产范围内的各域 measurement，以及 W10 的 scope coverage/production decision | P0 |
| Runtime、Task 与 Scheduler | W1-L01 至 W1-L12 已完成：后台 daemon/worker、heartbeat、CAS claim、effect ledger、retry/recovery、drain 和真实三平台进程级 evidence 均已存在；run `29542323581` 的三平台 aggregate 成功 | W2 的 OS service 接线、生产外部副作用的端到端演练和非幂等外部系统的查询/幂等协议 | P0 |
| Provider 与 Capability 执行 | W3-L01 至 W3-L07、W3-L10 已完成，W3-L08 代码边界已接线：真实 PID/CAS、process-group/Job cleanup、restart budget、stdio/MCP/command Skill 登记、跨进程 admission 和 run-as 传播/拒绝回归均已存在；manifest digest 已升为 v4，run `29597430669` 的 Linux/macOS/Windows admission evidence 成功。W3-L09 已接入 credential vault/session 边界、最小子进程环境、全链路脱敏和 Skill no-follow artifact 读取，并保持生产 fail-closed。W3-L10 daemon-owned supervision/drain 已由 crash-loop、真实孙进程清理/强杀、幂等 drain、credential cleanup retry、generation recovery 与跨 generation session 隔离回归收口 | W3-L08 仍需 EXT-01 原生 Linux/macOS/Windows identity evidence（macOS 显式切换当前未开放，等待受控 no-suid 或 sandbox 方案，`Current` 仍可用；代码对检测到的 non-root supplementary groups fail closed，但仍需 host attestation，另有目录 ownership，Windows 当前仅 same-SID service token）；W3-L09 仍需真实 OS/KMS vault authority、EXT-01 identity/ownership transcript、跨 UID handoff、目录 ancestor race/完整 TOCTOU 和生产 leak-scan evidence；W3-L11 三平台 production evidence 仍未完成；TLS/streaming 仍属于 W4 | P0 |
| MCP | Stdio 与 legacy `http://` JSON-RPC、tool allowlist、timeout/output limit 和 session cleanup 已可调用；W4-L01 至 W4-L06 已接入 canonical Streamable HTTP 配置、真实 rustls HTTPS/mTLS、严格 HTTP framing/session phase、增量 SSE，以及 registry-owned socket/session abort、DELETE 与 bounded join。W4-L07 现于首次 I/O 前由 daemon supervisor 接管 HTTP session 与 credential lease，以独立原子 fence 单向关闭准入，并以同一绝对 deadline 执行 socket abort、DELETE 和 reader join。MCP session cleanup 失败时同时保留已登记 session 与 credential lease 供授权重试；session 移除后若 credential release 失败，则以可重试 release task 继续保留 lease。生命周期最终析构会把 pending/failed lease 交给进程级有界 finalizer coordinator；该 coordinator 以 FIFO 队列持有 owner，最多并发 4 个 release worker，新移交 owner 立即尝试一次，失败 owner 的后续重试仅在授权 drain deadline 内执行；drain 启动的 lifecycle release worker 也会在外部 callback 紧前复查 deadline。provider drain 报告 session/reader 前后计数及 cleanup-pending after 计数，并在接受三项 after 均为 0 前要求 lifecycle credential owner 与进程级 finalizer residual 同 deadline 清零；daemon v2 evidence 仅在该 credential gate 成功后接受三项 after 均为 0，跨 runtime generation 的真实 TCP 回归不复用旧 `Mcp-Session-Id`。W4-L08 已接入调用方托管的数值 loopback server transport 及 pre-handler 只读 tool/schema 门禁。W4-L09 已完成：显式 `eva mcp compatibility measure` 通过 sealed typed Measurement 实跑 loopback server、rustls、schema/output digest 与 registry-owned abort/DELETE/join 零残留，固定 24 字段 subject；第五类 release evidence、`REL-MCP-COMPAT-001` 与三平台 capture/aggregate readback 已接线，run `29834140243` 的三平台原生门禁与 W4 readback 成功。`eva-mcp` 124/124、`eva-adapter` 125 passed/11 ignored、`eva-runtime` 125/125 与 workspace tests/Clippy 通过 | W4-L02 已完成：run `29823611739` 的 Website/docs、Linux/macOS/Windows core 与 W1 aggregate 全部成功；W4-L07 的仓库内 graceful drain/restart 与零残留已完成，但 W3-L10 仍是处于验证中的正式直接前置。registry 异常最终 Drop 只是有界 owner 销毁兜底；进程退出或 SIGKILL 后远端 session 回收仍需 EXT-03 server disconnect/TTL 合同和 W4-L10 evidence。W4-L09 已由 run `29834140243` 的三平台 capture 与独立 aggregate readback 完成。W4-L10 仍需验证中的 W4-L07，以及命名的 EXT-03 server、disconnect/TTL 合同和外部 matrix。W4-L08 的同步 handler 是调用方受信任边界，不宣称可强制取消、入站 TLS/auth 或远程暴露 | P0 |
| Backup、Snapshot 与 Restore | Alpha 已有本地 archive、pre-restore evidence、plan-gated copy/replace/delete、rollback 和 operator confirmation；这些 gate 仍明确限制在本地边界 | W5-L01 至 W5-L12：真实数据选择、持久 catalog、生产 KMS/AEAD、远程灾备、可信 plan/target-root、service-level blue-green handoff 和 drill | P0 |
| Upgrade 与 Service Manager | W2-L01/L02/L06/L07 已完成；`eva service install/status/start/stop/restart/uninstall` 已接线，Fake 仅在显式 `--dev` 下可用。生产 Adapter 安装绑定 executable/native argv/working directory/service identity 的 canonical hidden entrypoint，service manager 直接托管当前 daemon 进程而不二次 spawn；PID/state/lease identity 一致，Unix signal/Windows SCM stop token 复用既有 drain/shutdown，新 control request 绑定 lease generation，跨代残留 fail closed。macOS 当前用户域 `gui/<uid>` 与受限 root `system` lifecycle 均已通过唯一 label `/usr/bin/yes` 真实验证并零残留；三平台 Adapter 仍处于受控生命周期验证中 | W2-L03 至 L05 的 Windows/Linux transcript，以及 W2-L08 boot/restart recovery、W2-L09 三平台 destructive harness 和 W2-L10 production evidence；本机 launchd 结果不替代跨身份、crash/reboot 或三平台 cleanup evidence，真实 candidate 流量切换仍未完成 | P0 |
| Durable Storage | W1 已完成 writer ownership/CAS、TaskEnvelope、effect ledger、recovery 和 EventLog/task/audit/artifact/provider records；仍是文件系统 durable backend | 生产 WAL/compaction、覆盖所有 writer 的统一事务/ownership，以及外部非幂等副作用的可查询恢复协议 | P0 |
| Config 与 Discovery | W6-L01 至 L08、L10、L11 已完成：分层 merge、不可变 generation、watcher/preflight、原子 swap/崩溃恢复、可取消 scan、真实 PATH probe、持久 TTL cache 和 mutation inventory | W6-L09 的真实 registry TLS/auth/protocol/pagination client，以及 DEC-02 决策和真实 registry evidence | P1 |
| Memory 与 Knowledge | W8-L01 至 L04 的仓库内边界已完成：durable 模式不写 demo seed；schedule model/claim/reclaim 使用 owner+generation fence 和稳定 OS-lock anchor，owner 崩溃后 successor 可在 lease 到期后接管；默认禁用 retrieval worker 只有 `indexed` 才完成 schedule，拒绝/失败不写 durable knowledge | W8-L05/L06 的真实 retrieval source/index commit、retry/dead-letter/idempotency，以及生产数据查询与长驻 retention | P1 |
| Hardware | W7-L01 typed config、simulator safety、permission denial、lease cleanup 和 typed hotplug smoke 已有 alpha evidence | W7-L02 至 L12 的真实 OS permission、USB/serial/BLE/socket/vendor driver、长驻 watcher、I/O/reconnect 和 fixture evidence | P1 |
| Observability | W8-L07 runtime-owned OTel lifecycle 的仓库内边界已完成；单 owner、JSONL、tracing bridge、OTLP smoke、degrade、正常/错误退出 flush/shutdown 与 retention policy 均有测试 | W8-L08 至 L12：export queue/degrade/flush、真实 collector 长驻 evidence、database sink、后台 retention 和生产负载/cardinality evidence | P1 |
| Distribution | W9-L01 至 W9-L05 已完成 canonical metadata、Homebrew/Winget/Apt 生成、无凭据 validator 和三平台 CI measurement；run `29584854839` 的 W9 measurement 已回读 | W9-L06 至 L12：签名/公证、Authenticode/codesign/Apt signing、SBOM/attestation、仓库上传和上传后 clean install | P1 |

W4-L07 本地状态更新（2026-07-26）：W3-L10 正式前置已完成，W4-L07 的仓库内 graceful drain/restart、cleanup retry、credential finalizer 与零残留边界也已完成。上表中“W3-L10 验证中”的旧描述由本更新取代；完整 W4-L07 仍等待 EXT-03 命名 server 的 disconnect/TTL 合同，W4-L10 外部 matrix 不变。

W4-L02 验证更新：GitHub Actions run `29788607021`（提交 `42d90e211559432cda6fa182420f8a4a14b06d1e`）的 Ubuntu core 成功，macOS/Windows 分别暴露 Unix inherited duplicated-FD 锁残留和 child-exit/failed-frame 终态竞态。当前修复已为 Unix writer guard 增加显式 unlock，为 background launcher 增加 child 退出后的终态 frame 重读，并用真实子进程回归覆盖两条路径；workspace tests、Clippy、fmt 与 Windows GNU check 通过。W4-L02 仍保持验证中，直到修复提交自身的 Linux/macOS/Windows 原生 CI 全部成功；W4-L09 在此之前继续被直接前置阻塞。

W4-L02 第二轮验证更新：GitHub Actions run `29809011161`（提交 `41a3964ba8e48dac962591d01ebf129aa032563b`）的 Linux/macOS/Windows core job 均在 workspace tests 失败，但三平台 format、Clippy 与 W1/W3 evidence 已成功。当前修复为 Unix migration lock 增加显式 unlock 和 duplicated-descriptor 回归；仅在 macOS abort 测试中接受 shutdown 竞态产生的 `InvalidInput`，其余阻塞/错误终态仍严格失败；仅扩大 Windows PowerShell fixture 与 durable 成功路径的测试预算，显式 1 毫秒 timeout 和 20 毫秒 drain 负向回归保持不变。本机 workspace tests、Clippy、fmt、Windows GNU check 和 WSL `eva-storage` 129/129 通过。W4-L02 继续验证中，W4-L09 继续被直接前置阻塞，直到新提交的三平台原生 CI 全部成功。

W4-L02 第三轮验证更新：GitHub Actions run `29811744322` 在提交 `126f2dde5d3f085f5d517e9de443767c728993af` 上的 Ubuntu、macOS core 与 Website/docs job 成功；Windows core 在 W1 ignored process evidence `w1_real_process_evidence_covers_required_scenarios` 失败，W1 aggregate 因此前置失败。successor daemon 在接管时返回 `timeout`，随后 cleanup 因旧 PID projection 报 identity conflict；根因是 `FileSystemScheduleStore` 的 create-new 锁文件可在 owner 被强杀后残留，而 60 秒 stale-file 回收窗口长于 daemon lease，导致新 generation 在 schedule claim 前耗尽锁预算。当前修复改为稳定 per-schedule anchor 上的 OS file lock：进程死亡后由内核释放锁所有权，正常 Drop 显式 `unlock()` 且不删除 anchor；新增 `preexisting_lock_anchor_is_reusable_after_owner_exit` 单元回归与 `restart_reuses_schedule_lock_anchor_left_by_a_crashed_owner` 真实 daemon 强杀后遗留 anchor 的重启回归，验证 successor 在 lease 到期后无需等待 stale-file 回收即可接管。W4-L02 继续验证中，W4-L09 继续被直接前置阻塞，直到该修复提交自身的 Linux/macOS/Windows 原生 core 与 W1 aggregate 全部成功。

W4-L02 第四轮验证更新：GitHub Actions run `29820120079` 在提交 `dec82417de99a56f53cf938d2ed7f87f8539cb68` 上的 Ubuntu/Windows core、Website/docs 与 W1 aggregate 成功，schedule crash-takeover 修复已越过 Windows 原生 W1 process evidence；macOS core 仅在 workspace tests 的既有 `reader_done_signal_does_not_bypass_the_join_deadline` 失败。该测试让 reader 报告 done 后固定 sleep 200 毫秒，再以 `started.elapsed() < 150ms` 判断 20 毫秒 join deadline 未被绕过，runner 调度延迟会产生假失败。当前修复改用零容量 channel 屏障：reader 报告 done 后在显式 release 前保持未结束，第一次 20 毫秒等待必须返回 `mcp_stream_reader_join_timeout` 且 `JoinHandle` 未完成，release 后第二次有界等待必须成功 join；精确回归连续 30/30、`eva-mcp` 123/123、workspace tests、Clippy、fmt 与 Windows GNU check 通过。W4-L02 继续验证中，W4-L09 继续被直接前置阻塞，直到该测试修复提交自身的 Linux/macOS/Windows 原生 core 与 W1 aggregate 全部成功。

W4-L02 第五轮验证更新：GitHub Actions run `29821349222`（提交 `d6e2ef76e1a8dca66ac5984f7f7c0c585d765142`）的 Website/docs、Ubuntu core、macOS core 与 W1 aggregate 成功；Windows core 仅在 `artifact_collection_rejects_uncontrolled_relative_paths` 和 `process_skill_runner_collects_artifacts_and_redacts_env` 失败，两个外部 PowerShell fixture 均在 30 秒超时。当前修复改用当前 Rust test binary 的四个精确 ignored helper，仍覆盖 stdin EOF、stdout/stderr、artifact、secret/session-token 脱敏、非零退出与 timeout；两个原失败测试循环合计 40/40，`cargo test -p eva-adapter --all-targets` 为 125 passed、11 ignored。W4-L02 仍为验证中，W4-L09 仍为已阻塞，待该 native Rust helper 修复提交的 Website/docs、三平台 core 与 W1 aggregate 全部成功后再更新。

W4-L02 第六轮完成验证：GitHub Actions run `29823611739`（提交 `0ab9678778e2c36156fa6ded704124b5806c9f6c`）的 Website/docs、Windows/Ubuntu/macOS core matrix 与 W1 aggregate 全部成功。W4-L02 已完成，W4-L09 已解除直接前置并可开始；W4-L10 仍需命名的 EXT-03 server、disconnect/TTL 合同和外部 matrix。

W4-L09 首轮三平台验证更新：GitHub Actions run `29830963921`（提交 `a6e7b11f7e7c7626f50db475867353b0b67cefd7`）的 Linux/Windows/macOS 原生 core（含 compatibility capture）与 W1 aggregate 均成功；W4 MCP compatibility evidence readback job `88636979018` 在 Linux aggregate 上以 `[mcp-compatibility-evidence] reason=capture_argv_invalid detail=Windows` 失败。Windows capture 与 Measurement 均有效，根因是 validator 在 Linux 上使用 `[System.IO.Path]::GetFileName()` 解析 Windows 反斜杠路径时未能提取 portable basename。当前修复新增同时识别 `/` 与 `\` 的 `Get-PortableFileName`，合同 fixture 改用真实 Linux/macOS/Windows runner capture 路径，并新增错误 Windows basename 必须被拒绝的回归；修复后的合同以及从该 run 下载的三平台真实制品本地 aggregate 回读均通过。W4-L09 保持验证中，等待修复提交自身的三平台 core/capture 与独立 aggregate readback 成功。

W4-L09 完成验证：GitHub Actions run `29834140243`（提交 `606d915e4ce1e132f4391a55ebdc069ad03fdb1d`）的 Website/docs、Linux/Windows/macOS 原生 core（含 compatibility capture）、W1 aggregate 与 W4 MCP compatibility evidence readback job `88647694561` 全部成功；三平台 capture/upload/contract steps 生成聚合制品 `w4-mcp-compatibility-verified-29834140243-1`。portable basename 修复已越过真实跨平台回读门禁，W4-L09 更新为已完成；W4-L10 仍受 W4-L07 和 EXT-03 阻塞。

W4-L09 完成后的 W1 并发启动加固：文档状态提交 `cb4b74198c9c3de12a2d1d1b6d7c65f9be6a065a` 的 GitHub Actions run `29835795054` 中，Website/docs、Linux/macOS core、W1 aggregate 与 W4 MCP compatibility readback job `88653083366` 均成功，因此 run `29834140243` 对 W4-L09 的完成结论不回退。Windows core job `88651678702` 仅在 workspace test `concurrent_launchers_publish_exactly_one_background_owner` 失败：两个 child 均在 lease 发布前返回 `conflict`，成功 owner 为 0。根因是观察性 probe 会短暂持有固定 anchor，而真实 claim 将任何锁占用都视为 live owner；冷启动 loser 的无 lease 清理再次 probe 后，可让两个候选依次误判冲突。修复删除 start 前置 probe，以 `DurableRuntimeLeaseGuard::acquire` 作为唯一 claim 线性化点；anchor 已锁但尚无未过期 active lease 时最多等待 1 秒让 observer/pre-lease owner 收敛，精确 failed-start reclaim 只在 lease record 仍为 active 且 identity 精确匹配时等待 anchor 的短暂占用；未取得 lease 的 cleanup 在读取 PID/state 后再次确认 lease 仍缺失，且不再探测 anchor。新增 `runtime_lease_acquire_waits_out_a_transient_anchor_observer`、`failed_start_reclaim_waits_out_a_transient_anchor_observer`、`unclaimed_cleanup_does_not_probe_an_inflight_prelease_owner` 与 `no_lease_cleanup_rechecks_after_a_successor_publishes`；250 毫秒窗口在第 47 轮重新复现零赢家，恢复 1 秒窗口后原并发 launcher 回归连续 100/100；workspace tests、workspace Clippy `-D warnings` 与 fmt 均通过。本次只加固已完成的 W1-L03/W1-L04，W4-L09 保持已完成，W4-L10 的 W4-L07/EXT-03 阻塞不变。修复提交 `9c7b5ea19a61ec07ba77ea157f14a800a965038a` 的 GitHub Actions CI run `29842792837` 中 Website/docs job `88675649507`、Ubuntu/Windows/macOS core jobs `88675649684`/`88675649655`/`88675649624`、W1 runtime process evidence aggregate job `88677542860` 与 W4 MCP compatibility evidence readback job `88677542765` 全部成功；Deploy website run `29842793043`（build `88675649885`、deploy `88675742406`）也成功。原 Windows 零赢家门禁已在同一平台修复通过，状态统计不变。

## 外部前置条件

`release check` 当前输出以下五个 closure blocker。它们是生产闭环标签，不代表对应 Work Package 的全部代码都缺失；实现状态与外部证据必须分开记录。

| 报告中的 blocker | 外部输入 | 仍需实现的代码 |
| --- | --- | --- |
| `production_signing_attestation_credentials` | CI OIDC、KMS/HSM、签名与公证身份 | W9-L06 至 L10 的 signer、notarization、attestation 与最终 digest 接线 |
| `homebrew_winget_apt_repository_credentials` | 仓库所有权和 publish token、干净安装 runner | W9-L11/L12 的幂等上传、公开下载校验与 clean install |
| `platform_service_manager_test_environment` | 受控 Windows/Linux/macOS service host、提权/登录权限 | W2-L03 至 L05 的真实 host transcript，W2-L08 至 L10 的 boot/recovery/harness/gate，以及 W3-L08/L11 identity/evidence；W2-L06 CLI 与 W2-L07 direct entrypoint 代码/契约已在仓库内验证 |
| `real_or_virtual_hardware_fixture` | 稳定的真实硬件或虚拟设备 fixture、平台权限 | W7-L02 至 L12 的 permission、driver、I/O、hotplug 与 fixture evidence |
| `production_database_sink_and_retention_scheduler` | Database 选型、凭据、schema、collector 和运维策略 | W8-L09 至 L12 的 database sink、retention worker、retrieval/telemetry 生产 evidence |

## 理解 `release check`

> `eva release check` 聚合编译进代码的 alpha checklist 声明和可选的 operator evidence file。它不会现场运行 Cargo 或 CI、连接外部服务、验证 OS 集成或确认生产凭据。`status:"ready"` 只表示当前输入下没有 required gate object 被标为 blocked，不代表生产就绪。

- `release check` 会消费已编译的 alpha declaration、fixture 和显式 operator evidence；它不会替代 W0/W10 的生产 scope verifier。
- W0 已实现真实 command capture、manifest/readback、coverage/freshness/trusted-executor policy，但默认命令没有现场运行 Cargo、CI、外部服务、OS 集成或生产凭据检查。
- MCP compatibility 使用字段预设为支持状态的仓库 fixture，不会运行外部 server。
- Artifact、distribution、scanner 和 benchmark 只有显式传入相应文件后才由 evidence 驱动。
- Gate evidence 中列出的命令仍可能只是建议命令字符串；只有带 provenance 的 measurement envelope 才是执行证据。

## 已知风险

| 风险 | 当前行为 | 所需修正 |
| --- | --- | --- |
| 版本歧义 | 公开版本是 `1.11.5-alpha`，内部 ID 却使用 V1.12-V1.17 标签 | 在 CLI、release、website 和 planning 文案中持续明确区分 |
| Doctor 边界 | `doctor` 已按当前 AdapterRuntime 更新为受控 list/probe 诊断，并明确不执行 provider 或验证生产 transport 依赖 | 继续由独立 evidence 验证凭据、可执行文件、网络 endpoint 与硬件 |
| Retry evidence | W1 worker/recovery 已拥有 handler、claim、effect 和 ACK 边界；旧的“临时 mailbox 直接 ACK”风险已由当前实现覆盖，但 MCP/外部 provider 仍未达到生产 transport | 继续用有 owner 的 worker 和真实 provider evidence 验证非幂等恢复，不把 alpha routing smoke 当生产执行 |
| Demo 数据变更 | `memory context --durable-backend` 已不再写入 demo seed；无 durable backend 的内存示例路径仍可用于示例 | 保持 operator durable store 与 example path 分离，并为 retrieval worker 保留默认禁用边界 |
| Restore 信任边界 | Plan 未签名，且可以指定绝对 target root | 扩大使用范围前增加可信 plan provenance 和显式 target-root policy |
| Gate 过度可信 | W0 capture/readback 与 policy 已实现，但默认 alpha 仍可由 declaration/fixture 得到 `ready`，6 个 performance gate 未测量，W10 production scope 尚未启用 | 在新 tag workflow 和各生产域实测 evidence 齐备后启用 W10；保持 freshness、trusted executor、scope coverage 和 artifact digest 门禁 |

## 验证入口

从仓库根目录执行：

```powershell
cargo run -q -- version --output json
cargo run -q -- release check --output json
cargo run -q -- doctor --output json
cargo test --workspace
./scripts/validate-cli-json-contracts.ps1
./scripts/validate-version-management.ps1
```

这些命令只证明本地代码与 contract 行为。平台 service、hardware、外部 MCP server、生产 telemetry、签名和仓库发布仍需要独立环境与证据。

## 维护规则

- 只有阅读 owning code path 和当前测试后才能更新矩阵。
- 不追加逐 commit 或逐 marker 完成日志；历史写入 release notes 和 Git。
- 将受控基线与生产缺口拆成两项，不再把混合状态写为 `Done`。
- 始终区分 release evidence、runtime 执行、library/test 边界和外部前置条件。
- 同一变更中同步两种 locale、本地化插图、website card 和 `docs/_i18n/manifest.json`。

## 相关资料

- [真实运行时能力补齐实施计划](V1.x真实运行时能力补齐实施计划.md)
- [进程升级与恢复边界](../operations/进程级停机升级架构方案.md)
- [备份、快照与恢复边界](../operations/备份迁移包与ReleaseSnapshot架构方案.md)
- [项目配置边界](../operations/项目配置方案.md)
- [项目发布方案](../release/项目发布方案.md)
- [版本管理方案](../release/版本管理方案.md)