用途：在本地开发中驱动 cmd/desktop/devserver（代理 GitHub API），对运行中的 Hive Desktop 实例模拟 GitHub 事件与 webhook 投递，用于测试 GitHub 分类流程或 webhook 接收流程。
主要能力：通过 http://127.0.0.1:7777 下的 /_ctl/ JSON 控制接口提供两类模拟。其一为代理覆盖，重写 GitHub 对某条目呈现的 state、labels、通知 reason、草稿标志或搜索可见性，即 sources.github 节点所见内容。其二为 webhook 推送，向运行中实例的 sources.webhook 监听器注入并非来自 GitHub 的事件。动作词汇刻意沿用 GitHub 自身词汇，桌面端只读取 state、updatedAt、labels 和通知 reason 四项，因此没有 approve 动作，批准以 approval-requested 活动形式到达。
使用方式：先用 curl -sf localhost:7777/_ctl/health 检查就绪状态（devserver、appConnected、requests、itemsObserved），用 /_ctl/version 比对 .revision 与 git rev-parse HEAD 判断是否为被测构建；若 health 失败需让用户用 mise run desktop:devserver 启动，不要自行以阻塞会话的方式启动。用 /_ctl/state 查找已观测条目（按 repo 和 num 定位，webhook 推送无需已观测条目）。单事件可用 /_ctl/action（如 review-requested）或 /_ctl/overlay 原始变更；多步场景 POST 到 /_ctl/scenario，步骤支持 action、set 和 wait（若每步需独立作为事件落地，wait 应超过应用 60s 轮询下限），通过 /_ctl/state 的 .scenarios 观察运行状态，坏步骤返回 422 并指明步骤字段。webhook 推送用 /_ctl/webhooks/push 提供 {url, secret} 目标与 body，目标须为回环地址，需从应用 API 的 /api/status 读取 webhook host、port、pathPrefix。验证须通过应用的 MCP 工具（refresh_sources、list_inbox）而非读取 desktop-pipeline.db；代理类操作需先强制重新轮询，再读取并重试。清理用 /_ctl/overlay/clear 或 /_ctl/overlays/clear。
限制：覆盖是全局且跨 worktree 共享的，清除也是全局的；状态存于内存，重启 devserver 会丢失全部覆盖与运行中场景，仅回到 devserver.yaml 所声明状态；仅限回环地址；不要通过编辑 devserver.yaml 来运行场景，场景须在运行时通过 /_ctl/scenario 组合。