用途：管理 hex-relay 作为独立产品部署到单个项目环境，覆盖部署、重部署、验证、迁移与 Telegram 用户同步。
主要能力：四种模式——initial_deploy 将 agents/hex-relay/ 部署进已有项目运行时；redeploy 替换 VPS 源码、重建、重启服务并验证健康；verify_only 只读检查服务、数据库、钩子与 Telegram 命令状态；sync_users 按声明的 Telegram 用户/角色进行对账。
使用方式：输入 mode、项目/VPS 变量、Telegram 变量，可选 declared users、dry_run、runId、summaryArtifactPath。流程分六阶段：预检（Telegram 启用、${PROJECT_NAME}、${SERVICE_PREFIX}、${PROJECT_DIR}、${RELAY_HOOK_PORT} 已设置、项目运行时存在、secrets.env 存在但不打印密钥值、本地源码可用）；兼容性检测旧 ${SERVICE_PREFIX}-relay-bot.service 与 /opt/${SERVICE_PREFIX}-relay-bot，须先禁用或迁移旧 relay，禁止新旧单元同时运行；部署或重部署（安装 /opt/${SERVICE_PREFIX}-hex-relay、${SERVICE_PREFIX}-hex-relay.service、项目级钩子、Telegram 命令注册；重部署按 redeploy.md 打包源码、上传、npm ci && npm run build、重启）；用户与 Telegram 对账；健康检查（服务、GET /health、relay.db schema、outbox/dispatch/todo 冒烟、Stop 钩子镜像最终回复）；输出摘要。
限制与规则：源码归 agents/hex-relay/ 所有；不得编辑 VPS 上的 dist/；不得上传 node_modules/；不得打印或存储 Telegram/provider token 值；dry_run=true 与 verify_only 不改变远端状态。若提供 summaryArtifactPath 则写入同一摘要 JSON，否则内联返回并写入运行级路径；runId 缺失时生成独立 run_id。
适用场景：VPS 上 hex-relay 控制平面的部署与运维。具体产品行为见 agents/hex-relay/README.md。版本 1.0.0，最后更新 2026-05-05。