这 5 个项目现在处于什么状态，接手后应该先做什么

负责把内容通过 Browser Relay 分发到多个社交平台，同时用 markdown ledger 管理账号、验证状态、任务队列和结果。

• 真实执行仍依赖 Browser Relay 附着和正确账号登录，这是当前最常见的失败点。
• 部分 workflow 只有模板级或提交流程级验证，不能直接当成稳定可用。
• cluster 现在虽有 readiness 检查和 retry / requeue，但最后一公里仍是环境联调问题。

• 先跑 `cluster_status --include-readiness`，确认 worker 当前就绪状态。
• 优先盯住 `docs/cluster/` 和 `docs/matrix/verification-matrix.md`，不要只看 workflow 模板。
• 接着尝试跑一轮最小 cluster 真机任务，先解决 relay / 登录态问题，再扩平台覆盖。

给产品和工程团队一个可运行的陪伴式 Web MVP，支持 mock fallback，也支持接入 OpenAI 兼容服务。

• `CompanionShell` 的 TTS 编排仍是最值得继续收口的点。
• 图片生成与资源缓存虽已可用，但在真实服务配置下还需要继续回归验证。
• 当前更适合拿来验证体验，不适合直接按正式生产产品预期使用。

• 先在 mock 模式跑通，再切到真实 OpenAI 兼容配置做差异回归。
• 优先梳理 TTS 自动播放、重播和缓存回退链路。
• 把文档里提到的 MVP 边界继续固化到测试或验收清单里。

验证“营销落地页 -> 生成器 -> 素材库 -> 额度购买 -> 支付回写”这条业务闭环是否成立。

• 系统依赖 Supabase、Stripe 和图片供应商三条外部链路，联调成本较高。
• mock provider 适合本地开发，但不能代替真实商用质量验证。
• 目前更像产品验证中的 MVP，还不是稳定 SaaS 形态。

• 先确认 Stripe / Supabase / 图片 provider 的真实联调环境是否可用。
• 把出图质量、额度扣减和退款边界做成更明确的回归清单。
• 优先从真实供应商环境下的生成结果和支付回写稳定性入手。

把安装、修复、更新、日志查看和配置管理做成桌面应用，降低最终用户部署 OpenClaw 的门槛。

• 实际可用发布产物仍受构建环境、平台权限和系统安全策略影响。
• GUI 与脚本是并行维护状态，后续要注意行为一致性。
• 目前的风险不在“有没有功能”，而在“交付链路是否足够稳”。

• 先验证最近一轮打包和安装文档能否对应上真实产物。
• 优先收口发布流水线、签名和平台差异问题。
• 把 README 里的能力边界持续和发布事实对齐，避免文档先于产物。

让客户机器临时开启可回收的远程支持入口，尽量避免把 SSH 直接暴露到局域网，通过 relay 模型完成支持会话。

• Windows 仍依赖 OpenSSH Server，在离线或被策略限制的环境中会更复杂。
• macOS 仍依赖 `sudo` 权限和系统远程登录能力。
• 现在更像交付脚本仓库，不像有完整回归体系的应用仓库。

• 先按 README 的 Windows / macOS 路径各走一遍，确认文档与打包产物一致。
• 优先补离线安装和 recover 流程的 smoke 验证。
• 如果要继续演进，先围绕交付稳定性补脚本级验证，而不是急着扩新特性。