发布就绪度

当前还缺少与目标发布快照严格对应的 release gate 证据。

负责人: Engineering

下一步: 对计划发布的确切构建重新执行质量命令，并把结果挂到发布记录中。

• 存在一份带日期的发布门禁记录，且对应当前试用版快照。
• 记录中清楚区分通过、失败与豁免项。
• 另一位操作者可以按同一路径复现这份证据。

安装主路径仍缺少 fresh install、migrate、keep-existing、pinned-version 四类记录。

负责人: Release Ops

下一步: 在目标 macOS 环境中补齐四类安装路径的 smoke 结果，并统一归档。

• fresh install 路径有结果记录。
• migrate-existing 路径有结果记录。
• keep-existing 路径有结果记录。

安装、provider 配置、首条消息、工具调用、保存与恢复仍需形成可稳定复现的闭环。

负责人: Product + Engineering

下一步: 从干净环境跑一次最短成功路径，并记录到可复用的试用脚本中。

• 用户可以成功配置一个受支持 provider。
• 第一条消息能返回可用结果。
• 同一会话内至少一个工具调用成功。

所有公开页面都必须统一为猫爪品牌、`pi` 命令保留、且不宣传 strict drop-in replacement。

负责人: Product

下一步: 对照已批准的 v0.1 口径，逐页核对所有公开文档与 Web 页面。

• 公开品牌统一为猫爪。
• 保留 `pi` 命令的原因被解释清楚。
• 没有页面宣称严格替代。

版本号、changelog、release notes 与安装说明仍需锁定到同一发布值。

负责人: Release Ops

下一步: 冻结 v0.1 的实际发布号，并逐项对齐 changelog、安装说明与 release notes。

• 所有发布产物使用同一版本号。
• CHANGELOG 与 release notes 指向同一版本。
• 安装说明引用同一发布目标。

extension flag pass-through 仍然是高风险试用问题。

负责人: CLI

下一步: 先定义首批必须支持的扩展 CLI 路径，只验证这些高频路径。

• 高频扩展 flag 路径已验证。
• 不支持的路径已被明确写入限制说明。

更深层集成所需的 JSON/RPC 命令语义仍未形成完整覆盖。

负责人: Runtime

下一步: 明确试用期只支持的最小 RPC 子集，并只对这个子集做验证。

• 试用期 RPC 子集被显式列出。
• 已知语义差异被文档化。
• 首批集成用户拿到受限范围说明。

高频 slash command 仍需形成白名单级别的验证结果。

负责人: CLI

下一步: 先整理高频 slash command 白名单，再逐个补验证结果。

• 高频 slash command 有明确列表。
• 每个白名单命令都有验证结果。

从 TypeScript `pi` 迁移的体验依然是高频且高敏感路径。

负责人: Product + CLI

下一步: 用至少一条真实历史安装路径验证迁移说明与用户感知是否一致。

• 迁移叙事明确且不误导用户。
• 旧用户能清楚判断当前运行的是哪个 `pi`。
• 回滚预期被安全地文档化。