open-octo/octo-agent

中文读者：这是一个"认领制"的伞形 issue。 每个平台都是独立的一份适配器， 互不干扰，有两份现成参考实现（telegram / discord，各约 1000 行）。 在下面留言说你要做哪个平台，我回复确认，避免撞车。 Context octo's IM bridge is one of its differentiators: put a task in from your desk, follow up from your phone, and the work is done when you get home. Six platforms ship today: feishu · dingtalk · wecom · weixin · telegram · discord Adding a seventh is well-bounded, parallelisable work: one directory, one interface, no changes to the agent core. The extension point Implement channel.Adapter (internal/channel/adapter.go) and register it from your package's init(): func init() { channel.Register(platformName, New) } The interface is 13 methods, and it is worth reading the doc comments in full before you start — they encode lessons already paid for. The capability flags matter most: Method Why it exists Su

中文读者：这是全项目最硬的一块，前沿探索性质，不是"照着文档写"的任务。 设计文档已有完整的可行性分析，但结论是"有明确用例再做"。 想啃这个的，请先在这个 issue 里聊设计，不要直接埋头写代码。 Context octo's differentiated pillar is record → replay → self-heal: demonstrate a task once, get an editable semantic skill, replay it deterministically with per-step verification, and hand a failed step to an LLM only to repair it. Today that pillar is browser-only (internal/browser, native CDP, cross-platform). The question this issue opens: can the same loop drive native desktop applications? dev-docs/desktop-computer-use-design.md is a full feasibility analysis. Read it first — it is a proposal, not a spec of committed work. The core difficulty The design doc's framing, which is worth internalising before you start: The paradigm is portable. The record→distill→replay→heal loop, the skill-as-editab

中文读者：这个适合喜欢做 App 的人——要写 Swift / Kotlin + Capacitor 插件。 服务端和 relay 侧已经做完了，缺的是 App 这一端。想认领的在下面留言。 Context mobile/ is octo's iOS + Android client: a thin remote client of an octo serve instance, not a second agent. It wraps the existing web frontend in a Capacitor shell and adds the native pieces a browser cannot provide — the Noise XX tunnel plugin being the main one. Both platforms are already verified end to end from a from-scratch build: paired to a local octo serve --tunnel + octo-relay over a real Noise session, with the mobile UI driving /api and /ws through the tunnel. What is missing is the part that makes the app actually usable as a remote control when it is not in the foreground. Problem — a killed app cannot be woken Push wakeups are half-built by design, and the missing half is app-side: ✅ Host + relay side ships: the wakeup frame in internal/tunnel, and push delivery in