chore(release): 发布 watcherobot 0.1.1

[orulink-sdk-release]

发布来源

• 来源：Codex 手动触发：发布 main 最新 SDK 到正式 PyPI
• 发布类型：stable
• 目标版本：0.1.1

门禁

• 本 PR 必须人工审查和合并
• 合并后由陆骁创建 annotated tag
• Tag 构建先发布并验证 TestPyPI
• 正式 PyPI 发布需要 GitHub Environment 人工批准

已完成的实机证据

• SDK PR fix(test-bench): 修复音频流控死锁并校验真实上行信号 #45 在 COM20 完成配对、运动、灯效、640×480 JPEG、麦克风 PCM、流式扬声器及连续三轮 RTC 双向音频验证；设备上下行统计持续增长、渲染错误为 0。对应 SDK head b4ac4131a4c00e94a81a5a05783b4345e2c8167c，merge commit f3e61efc1d7ad0f76bb4bf6ef7c651e1f94cd348。
• ESP32 PR #143 使用 ESP-IDF 6.0.2 构建并烧录 COM20，完成运动、灯效、扬声器、JPEG、麦克风和 RTC 双向媒体回归。最终验证提交 7e3bbb1b9a7d5bce5dae414c5f6450f9caebd6e7，merge commit 94bbf4df731c67d14eb1014b63851739f0417c05。
• SDK PR fix: 稳定 SDK 实时视频拥塞反馈与媒体边界 #53 记录浏览器到 ESP32-S3 v0.3.6 的 RTC 音视频及云台高动态回归通过，merge commit a68fa6ca28f33f93331658b43fcd2971bf9d5e0b。
• SDK PR fix(media-lab): 串行化普通扬声器播放与麦克风录音 #60 与 ESP32 PR #152 完成 Mac 实机普通麦克风/扬声器并发回归，冲突操作安全返回 busy，执行中的音频方向完整结束，设备保持在线且资源归零。

当前剩余的实机门禁

• 上述证据覆盖当前 main 的核心 RTC、媒体和设备控制祖先提交，但 PR feat(cli): 打通机器人首次配置与 Application 新手闭环 #63 后续新增了 watcherobot robot setup、robot pair 与 robot status 首次连接闭环；该 PR 明确要求使用未配网或已重置机器人补做 Windows 实机全链路验收。
• 2026-08-18 检查本机 Daemon 为 SDK 0.1.1a6，设备状态为离线，当前无法在无人值守条件下补做配网、六位码配对和当前候选版本的最终整机回归。
• 稳定版合并前仍需连接测试机器人，至少确认当前候选版本的配网/配对、Hello World Application、运动、灯光、相机、麦克风、扬声器和 RTC 音视频主链路；不得把历史证据冒充为当前候选版本完整验收。

[github-actions]

🤖 Luxiao PR 审查报告

⚠️ Review agent did not produce output.

[github-actions]

🤖 Luxiao PR 审查报告

🤖 PR 审查报告

PR: chore(release): 发布 watcherobot 0.1.1
变更: 2 个文件，+5 / -1

---

维度一：代码质量

🏗️ 架构视角 — ✅

本次改动仅更新包版本号和发布日志，没有改变模块结构、依赖关系或公共 API，符合版本发布 PR 应保持最小变更面的原则。

从 0.1.1a6 升级到 0.1.1 的版本号符合 PEP 440，技术上能够正确表达从预发布版本进入稳定版本。

🎨 产品视角 — ⚠️

该 PR 将版本标记为正式稳定版，但描述中明确说明尚未补充 RTC 实机验证结果。这意味着当前代码状态与“stable”对用户传达的质量承诺不一致。

对于涉及机器人硬件和 RTC 能力的 SDK，自动化测试不能完全替代实机验收。在缺少实机结果的情况下发布正式 PyPI，可能让用户获得一个尚未完成关键场景验证的稳定版本。

此外，0.1.1 的 CHANGELOG 只记录了“Codex 手动触发发布”，没有说明该版本实际包含的用户功能和修复。发布方式不是面向 SDK 用户的版本变化，不能代替正式的版本说明。

📏 规范视角 — ⚠️

存在以下发布日志问题：

1. 0.1.1 章节位于 [Unreleased] 之前，不符合常见的 Keep a Changelog 排列方式。通常应保持 [Unreleased] 在最上方。
2. [Unreleased] 中仍保留了 Application 开发流程简化等用户可见变更，但没有将属于 0.1.1 的内容归档到 0.1.1 章节。
3. “Codex 手动触发”属于内部发布来源或操作记录，不是有效的用户侧变更说明。
4. 正式版本章节仍使用“待发布”。可以在合并前暂时保留，但创建正式 Tag 前应替换为实际发布日期，或由自动化流程可靠完成替换。

当前 CHANGELOG 无法准确回答“用户从上一稳定版升级到 0.1.1 能获得什么”。

⚠️ 损伤视角 — ⚠️

代码本身没有直接破坏已有功能，但发布层面存在风险：

• 稳定版本号一旦发布至正式 PyPI，通常不能覆盖或重新上传同版本文件。
• 缺少 RTC 实机验收，可能把预发布阶段尚未发现的问题带入稳定渠道。
• CHANGELOG 归档不完整，会导致正式版本的变更记录失真。
• PR 信息未证明已经满足项目发布流程要求，例如是否使用规定的 release 分支及 release 标签。
• 从 0.1.1a6 直接切换到 0.1.1，本 PR 本身无法证明 alpha 阶段累计功能已经完成完整回归。

现有 TestPyPI 验证和 GitHub Environment 人工批准能够降低误发布风险，但不能替代合并前的发布资格审查和 RTC 实机验证。

---

维度二：意图分析

🎯 意图提炼

将当前 main 中的 watcherobot SDK 从 0.1.1a6 提升为正式稳定版 0.1.1，并通过受控发布流程依次发布到 TestPyPI 和正式 PyPI。

🔀 偏离检测

发布稳定版本的意图与项目方向一致，改动范围也保持克制，没有出现功能蔓延。

但实现与意图之间存在两处偏差：

1. PR 宣称发布稳定版，但明确缺少稳定版发布所要求的 RTC 实机验收结果。
2. CHANGELOG 记录的是“如何触发发布”，而不是“该稳定版本实际发布了什么”。

因此，该 PR 当前完成了版本元数据切换，但还没有完整证明 0.1.1 已达到稳定版发布标准。

---

Merge 建议

⚠️ 有条件合并

合并前必须满足以下条件：

1. 补充 RTC 实机验证结果，至少包含测试环境、核心场景、测试结果和已知问题。
2. 将属于 0.1.1 的用户可见变更从 [Unreleased] 归档到 0.1.1 章节。
3. 将“Codex 手动触发”移出用户侧 CHANGELOG，或改写为实际功能、修复和兼容性变化。
4. 将 [Unreleased] 恢复到最新已发布版本之前。
5. 确认正式 Tag 创建前会把“待发布”替换为实际发布日期。
6. 确认该 PR 满足项目发布门禁，包括规定的 release 分支、发布标签及必要 CI 检查。
7. 合并后严格执行 annotated tag → TestPyPI 构建与安装验证 → GitHub Environment 人工批准 → 正式 PyPI 发布，不应绕过任何阶段。

如果 RTC 实机验证暂时无法完成，则不应以 stable 类型合并并发布；应继续保留预发布版本，或推迟本次正式发布。

---

总结： 版本号改动本身正确且范围清晰，但当前缺少稳定版所需的 RTC 实机验收，CHANGELOG 也未正确归档实际变更；完成上述发布门禁后方可合并。

[github-actions]

🤖 Luxiao PR 审查报告

🤖 PR 审查报告

PR: chore(release): 发布 watcherobot 0.1.1
变更: 2 个文件，+29 / -23

---

维度一：代码质量

🏗️ 架构视角 — ✅

本次变更仅更新 SDK 版本号和发布日志，没有修改运行时代码、模块依赖或公共 API，符合版本发布 PR 应保持最小变更面的原则。

src/watcherobot/__init__.py 中的版本从预发布版 0.1.1a6 提升为稳定版 0.1.1，符合 Python/PEP 440 版本语义。

🎨 产品视角 — ⚠️

0.1.1 发布日志能够从 SDK 用户视角说明安装流程、机器人配对、RTC Media Lab、音频资源仲裁及运行时诊断等变化，内容覆盖较完整。

但 PR 已明确说明：

• 当前只准备版本元数据；
• 尚未补充 RTC 实机验证结果；
• 目标是发布到正式 PyPI 的稳定版本。

RTC 双向媒体、资源恢复及设备端 AEC 均依赖真实硬件环境。缺少实机结果时，无法确认发布日志中描述的能力已经达到稳定版标准。TestPyPI 验证只能证明构建、安装和包内容基本正常，不能代替机器人端验收。

📏 规范视角 — ⚠️

版本号修改清晰、范围合理，但 CHANGELOG.md 存在发布状态冲突：

## [0.1.1] - 2026-08-18
...
## [0.1.1a6] - 待发布

正式版 0.1.1 已进入发布条目后，其预发布版本 0.1.1a6 不应继续标记为“待发布”。这会让读者误以为 0.1.1a6 仍是未来版本，也无法判断它是否实际发布过。

建议合并前至少完成以下一种处理：

1. 若 0.1.1a6 已发布，补充实际发布日期；
2. 若从未发布且已被正式版取代，删除该独立条目，或明确标注为“未发布/已取消”；
3. 若该条目仍有保留价值，说明它与正式版 0.1.1 的关系。

另外，0.1.1a6 条目中的“用户明确要求”属于内部发布过程信息，不是 SDK 使用者可理解的产品变更，建议从面向用户的 CHANGELOG 中移除或改为实际变更摘要。

⚠️ 损伤视角 — ⚠️

代码层面没有直接功能损伤，但发布层面的风险较高：

• 0.1.1 是稳定版本号，一旦正式上传 PyPI，通常不能覆盖或重新上传同版本制品；
• 当前缺少 PR 声明中要求的 RTC 实机验收结果；
• 发布日志声称具备真实双向媒体诊断、AEC 指标及重复启停资源恢复能力，但本 PR 本身没有提供对应验收证据；
• 若合并后立即创建 Tag，版本发布流程将进入不可轻易回退的阶段。

GitHub Environment 人工审批降低了误发正式 PyPI 的风险，但不能代替合并前的稳定版质量判断。

---

维度二：意图分析

🎯 意图提炼

将当前 main 上的 WatcheRobot Python SDK 从 0.1.1a6 预发布状态提升为 0.1.1 稳定版，并准备后续 annotated tag、TestPyPI 验证和正式 PyPI 发布流程。

🔀 偏离检测

整体意图与项目的 SDK 发布流程一致，变更范围也集中在版本元数据和发布日志，没有发现功能蔓延。

但实现状态与“稳定版发布”意图尚未完全匹配：版本号和 CHANGELOG 已声明稳定版，而 PR 描述同时承认关键 RTC 实机验收尚未完成。这意味着当前变更更接近“稳定版候选准备”，还不足以证明可以正式发布。

此外，0.1.1a6 - 待发布 与新增的 0.1.1 正式版条目存在发布状态偏离，应在合并前统一。

---

Merge 建议

⚠️ 有条件合并

合并前必须满足：

1. 补充并审查 RTC 实机验证结果，至少覆盖：

   • 电脑麦克风到 Watcher 扬声器；
   • Watcher 麦克风到浏览器播放器；
   • 音频、视频及音视频模式切换；
   • 重复启动、停止后的媒体资源恢复；
   • 普通播放、录音与 RTC 共享音频运行时的冲突处理；
   • 验收环境、设备固件版本和明确的通过/失败结论。

2. 修正 CHANGELOG.md 中 0.1.1a6 - 待发布 与 0.1.1 正式版并存的状态冲突。

3. 将 0.1.1a6 条目中的内部过程描述改为用户可理解的实际变更，或删除该条目。

4. 合并后按既定门禁执行：

   • 从经审查的 merge commit 创建 annotated tag；
   • 确认 Tag 对应代码中的版本确实为 0.1.1；
   • 先完成 TestPyPI 构建、安装和版本验证；
   • TestPyPI 与实机验收均通过后，再批准正式 PyPI Environment。

---

总结： 版本元数据修改本身正确且范围克制，但 RTC 实机验收缺失和 CHANGELOG 发布状态冲突尚未达到稳定版发布标准，完成上述条件后方可合并。

[github-actions]

🤖 Luxiao PR 审查报告

🤖 PR 审查报告

PR: chore(release): 发布 watcherobot 0.1.1
变更: 2 个文件，+29 / -23

---

维度一：代码质量

🏗️ 架构视角 — ✅

本次变更保持了版本发布 PR 的最小职责：

• 将 src/watcherobot/__init__.py 中的版本从预发布版 0.1.1a6 提升为稳定版 0.1.1。
• 将预发布阶段积累的用户可见变化整理到 CHANGELOG.md 的正式版本条目中。
• 未混入功能实现、协议调整或重构，便于审查、回滚和定位发布快照。
• 符合“版本 PR 合并后，在该 merge commit 上创建 annotated tag”的发布架构。

从 Diff 看，没有引入新的模块耦合或架构偏移。

🎨 产品视角 — ⚠️

0.1.1 的更新日志覆盖了本次版本的主要用户价值：

• Application 首次开发闭环；
• 机器人配网、配对和状态确认；
• RTC 音视频与媒体资源仲裁；
• Daemon、Runtime 和跨平台诊断改进。

更新日志整体能够向 SDK 使用者解释稳定版相对 0.1.0 的变化。

但稳定版当前缺少最关键的新用户路径验收：PR #63 新增的 robot setup、robot pair、robot status 正是首次使用闭环的一部分，却尚未在当前候选版本上使用未配网或重置机器人完成 Windows 实机验证。

这不是普通的补充测试缺口。配网或六位码配对失败会直接导致新用户无法进入后续 Hello World、设备控制和媒体功能。现有 RTC、媒体和设备控制历史证据不能替代该入口链路的候选版本验收。

📏 规范视角 — ✅

版本号符合 PEP 440 的稳定版格式，CHANGELOG 结构清晰，正式版本日期明确。

做得较好的地方：

• Unreleased 与正式发布条目分离；
• 0.1.1a6 补充了实际发布日期，不再保留“待发布”状态；
• 正式版条目聚合了各预发布版本及后续功能变化；
• 没有把内部 commit、串口编号或测试过程细节写入面向用户的 CHANGELOG；
• 版本修改范围集中，没有无关格式化或代码改动。

需要在合并门禁中确认，但不一定要求修改本 PR：

• 构建产物读取的版本源确实是 watcherobot.__version__，不存在 pyproject.toml、构建配置或其他版本文件仍停留在 0.1.1a6 的情况；
• v0.1.1 在仓库、TestPyPI 和正式 PyPI 均不存在，避免版本或 Tag 冲突；
• 版本 PR 带有唯一且正确的 release:version 标签，并来自规定的 release/watcherobot-0.1.1 分支。

⚠️ 损伤视角 — 🔴

代码 Diff 本身风险低，但发布语义风险高。

一旦本 PR 合并并进入正式发布流程：

• 0.1.1 将成为不可覆盖的 PyPI 稳定版本；
• 配网、配对或首次运行问题无法通过重新上传同版本修复；
• 用户会默认稳定版本已经完成当前代码快照的关键链路验收；
• 如果仅依据祖先提交的历史测试发布，会形成“CHANGELOG 声明能力已稳定，但当前候选版本未完整验证”的证据断层。

PR 描述已经明确承认以下阻塞事实：

• 当前本机 Daemon 仍是 0.1.1a6，不是最终稳定候选版本；
• 设备离线；
• PR feat(cli): 打通机器人首次配置与 Application 新手闭环 #63 新增的首次连接闭环尚未补做 Windows 实机验收；
• 历史媒体和控制证据不能冒充当前候选版本的完整验收。

因此，在实机门禁完成前合并，会把一个已知且直接影响首次使用的风险推进到稳定版发布流程。即使正式 PyPI 仍有人工作为 Environment 审批，版本 PR 也不应在已知核心门禁未完成时提前合并。

未从当前材料中看到安全漏洞或性能退化，但发布不可变性使该验收缺口构成合并阻塞项。

---

维度二：意图分析

🎯 意图提炼

本 PR 将 SDK 从 0.1.1a6 预发布阶段提升为正式稳定版 0.1.1，汇总该版本的用户可见变化，并触发后续 annotated tag、TestPyPI 验证和人工批准的正式 PyPI 发布流程。

🔀 偏离检测

意图与项目发布方向一致，变更范围也严格限定在版本号和更新日志，没有功能蔓延。

实现与发布意图之间存在一处关键不一致：

• 代码和 CHANGELOG 已将当前快照声明为稳定版；
• 当前证据只能证明若干祖先提交上的 RTC、媒体、设备控制能力；
• 最新加入的首次连接闭环尚未在当前候选版本上完成要求中的 Windows 实机验证。

因此，这不是功能范围偏离，而是“稳定版声明早于稳定版门禁完成”。PR 的发布意图合理，但当前合并时机不成立。

---

Merge 建议

🔴 当前不建议合并

阻塞原因是当前候选版本缺少首次连接核心链路的实机验收，而不是 Diff 本身存在实现错误。

转为可合并前，至少需要完成并记录以下条件：

1. 使用未配网或已重置的测试机器人，在 Windows 环境验证当前 main 对应的候选代码，而不是仅验证已安装的旧版 0.1.1a6。
2. 完成以下首次连接闭环：
   • watcherobot robot setup
   • 蓝牙发现和 Wi-Fi 配网
   • watcherobot robot pair
   • 六位码配对
   • watcherobot robot status
   • 设备在线与连接状态确认
3. 使用同一候选版本完成 Hello World Application 初始化和运行。
4. 回归运动、灯光、相机、麦克风、扬声器以及 RTC 音视频主链路，并确认结束后设备保持在线、媒体资源正确归零。
5. 记录被验证的准确 commit、SDK 版本、Daemon 版本、机器人固件版本、操作系统及结果，确保测试证据能够追溯到最终发布快照。
6. 确认 CI 和版本一致性检查通过，v0.1.1、TestPyPI 0.1.1、PyPI 0.1.1 均不存在冲突。
7. 满足上述条件后再人工合并；随后只在本 PR 的 merge commit 上创建 annotated v0.1.1 tag。
8. Tag 构建必须先完成 TestPyPI 发布、安装和版本验证；正式 PyPI 发布继续由负责人通过 GitHub pypi Environment 人工批准。

这些门禁完成且结果通过后，本 PR 的代码范围和版本内容可以转为 ✅ 建议合并，无需因当前审查结论额外扩大代码改动。

---

总结： 版本与 CHANGELOG 修改本身清晰、规范且符合发布架构，但当前候选版本尚未完成新增配网与配对首次连接闭环的实机验收；稳定版不可覆盖，因此在该核心门禁补齐前不建议合并。