better-dsh 0.2.5 → 0.3.0

package/docs/80_upstream-docs-and-skills/hermes-dev-skill/src/i18n/zh-Hans/guides/oauth-over-ssh.md

@@ -1,96 +0,0 @@
----
-sidebar_position: 17
-title: "SSH / 远程主机上的 OAuth"
-description: "当 Hermes 运行在远程机器、容器或跳板机后面时，如何完成基于浏览器的 OAuth（Spotify、MCP 服务器）"
----
-
-# SSH / 远程主机上的 OAuth
-
-部分 Hermes 提供商——**Spotify** 和 **远程 MCP 服务器**（Linear、Sentry、Atlassian、Asana、Figma 等）——使用*回环重定向（loopback redirect）* OAuth 流程。认证服务器将浏览器重定向到 `http://127.0.0.1:<port>/callback`，由 Hermes 启动的小型 HTTP 监听器获取授权码。
-
-当 Hermes 和浏览器在同一台机器上时，这一切运行正常。一旦两者不在同一台机器上就会出问题：你笔记本上的浏览器试图访问**你笔记本**上的 `127.0.0.1`，但监听器绑定的是**远程服务器**上的 `127.0.0.1`。
-
-解决方法是一行 SSH 本地端口转发。对于交互式终端上的 MCP 服务器，通常也可以直接粘贴重定向 URL（无需隧道）。
-
-**xAI Grok OAuth（`xai-oauth`）使用 OAuth 设备代码**，不是回环回调——在任意浏览器中打开打印的验证 URL，Hermes 轮询直到批准即可，无需 SSH 隧道。请参阅 [xAI Grok OAuth](./xai-grok-oauth.md)。
-
-## 快速概览
-
-```bash
-# 在你的本地机器（笔记本）上，另开一个终端：
-ssh -N -L 43827:127.0.0.1:43827 user@remote-host
-
-# 在远程机器的现有 SSH 会话中：
-hermes auth add spotify --no-browser
-# → Hermes 打印授权 URL，在笔记本的浏览器中打开。
-# → 浏览器重定向到 127.0.0.1:43827/callback，隧道转发到远程监听器，登录完成。
-```
-
-Hermes 会在 `Waiting for callback on ...` 一行打印实际绑定的端口——从那里复制。Spotify 默认端口为 `43827`。
-
-## 哪些提供商需要此操作
-
-| 提供商 | 回环端口 | 需要隧道？ |
-|----------|---------------|----------------|
-| Spotify | `43827`（默认） | 是，当 Hermes 在远程时 |
-| MCP 服务器（`auth: oauth`） | 每台服务器自动选择 | 是（或粘贴重定向 URL） |
-| `xai-oauth`（Grok SuperGrok） | 不适用 | 否——设备代码流程 |
-| `anthropic`（Claude Pro/Max） | 不适用 | 否——粘贴代码流程 |
-| `openai-codex`（ChatGPT Plus/Pro） | 不适用 | 否——设备码流程 |
-| `minimax`、`nous-portal` | 不适用 | 否——设备码流程 |
-
-如果你的提供商不在表中，则不需要隧道。
-
-## 为什么监听器不能直接绑定 0.0.0.0
-
-Spotify 和大多数 MCP OAuth 服务器会根据白名单验证 `redirect_uri` 参数，并要求回环形式（`http://127.0.0.1:<精确端口>/callback`）。将监听器绑定到 `0.0.0.0` 或使用不同端口会导致认证服务器以 redirect_uri 不匹配为由拒绝请求。SSH 隧道可以端到端保持回环 URI 不变。
-
-## 分步操作：单次 SSH 跳转
-
-### 1. 从本地机器启动隧道
-
-```bash
-# Spotify（端口 43827）
-ssh -N -L 43827:127.0.0.1:43827 user@remote-host
-```
-
-`-N` 表示「不打开远程 shell，仅保持隧道」。登录期间保持此终端运行。
-
-### 2. 在另一个 SSH 会话中运行认证命令
-
-```bash
-ssh user@remote-host
-hermes auth add spotify --no-browser
-```
-
-Hermes 检测到 SSH 会话，跳过自动打开浏览器，并打印授权 URL 以及 `Waiting for callback on http://127.0.0.1:<port>/callback`。
-
-### 3. 在本地浏览器中打开 URL
-
-从远程终端复制授权 URL，粘贴到笔记本的浏览器中。批准同意后，认证服务器重定向到 `http://127.0.0.1:<port>/callback`。浏览器经隧道访问，请求转发到远程监听器，Hermes 打印 `Login successful!`。
-
-看到成功提示后即可关闭隧道（在第一个终端按 Ctrl+C）。
-
-## 通过跳板机
-
-如果通过堡垒机 / 跳板机访问 Hermes，使用 SSH 内置的 `-J`（ProxyJump）：
-
-```bash
-ssh -N -L 43827:127.0.0.1:43827 -J jump-user@jump-host user@final-host
-```
-
-## 故障排除
-
-### `bind [127.0.0.1]:43827: Address already in use`
-
-笔记本上已有进程占用该端口。结束占用进程后重试 `ssh -L`。
-
-### 等待本地回调超时
-
-重定向未到达远程监听器。确认隧道仍在运行，并使用最新一次 `Waiting for callback on ...` 中的端口（首选端口被占用时 Hermes 可能自动递增）。
-
-## 另请参阅
-
-- [xAI Grok OAuth](./xai-grok-oauth.md)——设备代码；无需 SSH 隧道
-- [Spotify（SSH 上运行）](../user-guide/features/spotify.md#running-over-ssh--in-a-headless-environment)
-- [原生 MCP 客户端（OAuth 部分）](../user-guide/features/mcp.md#oauth-authenticated-http-servers)

package/docs/80_upstream-docs-and-skills/hermes-dev-skill/src/i18n/zh-Hans/guides/operate-teams-meeting-pipeline.md

@@ -1,288 +0,0 @@
----
-title: "操作 Teams 会议流水线"
-description: "Microsoft Teams 会议流水线的运行手册、上线检查清单及操作员工作表"
----
-
-# 操作 Teams 会议流水线
-
-本指南适用于已通过 [Teams Meetings](/user-guide/messaging/teams-meetings) 启用该功能之后的操作阶段。
-
-本页内容：
-- 操作员 CLI 流程
-- 日常订阅维护
-- 故障排查
-- 上线检查
-- 上线工作表
-
-## 核心操作员命令
-
-### 验证配置快照
-
-```bash
-hermes teams-pipeline validate
-```
-
-每次配置变更后首先执行此命令。
-
-### 检查 token 健康状态
-
-```bash
-hermes teams-pipeline token-health
-hermes teams-pipeline token-health --force-refresh
-```
-
-当怀疑 auth（认证）状态过期时，使用 `--force-refresh`。
-
-### 检查订阅
-
-```bash
-hermes teams-pipeline subscriptions
-```
-
-### 续期即将到期的订阅
-
-```bash
-hermes teams-pipeline maintain-subscriptions
-hermes teams-pipeline maintain-subscriptions --dry-run
-```
-
-### 自动化订阅续期（生产环境必须配置）
-
-**Microsoft Graph 订阅最多 72 小时后过期。** 若无任何续期操作，会议通知将在 3 天后静默停止，流水线看起来像是"故障"。这是所有基于 Graph 的集成中最常见的运维故障模式。
-
-你**必须**按计划运行 `maintain-subscriptions`。从以下三种方式中选择一种：
-
-#### 方式一：Hermes cron（若已运行 Hermes gateway，推荐此方式）
-
-Hermes 内置 cron 调度器。`--no-agent` 模式以脚本作为任务执行（而非使用 LLM），`--script` 必须指向 `~/.hermes/scripts/` 下的文件。首先创建脚本：
-
-```bash
-mkdir -p ~/.hermes/scripts
-cat > ~/.hermes/scripts/maintain-teams-subscriptions.sh <<'EOF'
-#!/usr/bin/env bash
-exec hermes teams-pipeline maintain-subscriptions
-EOF
-chmod +x ~/.hermes/scripts/maintain-teams-subscriptions.sh
-```
-
-然后注册一个每 12 小时运行一次的纯脚本 cron 任务（相对于 72 小时过期窗口有 6 倍余量）：
-
-```bash
-hermes cron create "0 */12 * * *" \
-  --name "teams-pipeline-maintain-subscriptions" \
-  --no-agent \
-  --script maintain-teams-subscriptions.sh \
-  --deliver local
-```
-
-验证注册情况并查看下次运行时间：
-
-```bash
-hermes cron list
-hermes cron status        # 调度器状态
-```
-
-#### 方式二：systemd timer（推荐用于 Linux 生产部署）
-
-创建 `/etc/systemd/system/hermes-teams-pipeline-maintain.service`：
-
-```ini
-[Unit]
-Description=Hermes Teams pipeline subscription maintenance
-After=network-online.target
-
-[Service]
-Type=oneshot
-User=hermes
-EnvironmentFile=/etc/hermes/env
-ExecStart=/usr/local/bin/hermes teams-pipeline maintain-subscriptions
-```
-
-以及 `/etc/systemd/system/hermes-teams-pipeline-maintain.timer`：
-
-```ini
-[Unit]
-Description=Run Hermes Teams pipeline subscription maintenance every 12 hours
-
-[Timer]
-OnBootSec=5min
-OnUnitActiveSec=12h
-Persistent=true
-
-[Install]
-WantedBy=timers.target
-```
-
-启用：
-
-```bash
-sudo systemctl daemon-reload
-sudo systemctl enable --now hermes-teams-pipeline-maintain.timer
-systemctl list-timers hermes-teams-pipeline-maintain.timer
-```
-
-#### 方式三：普通 crontab
-
-```cron
-0 */12 * * * /usr/local/bin/hermes teams-pipeline maintain-subscriptions >> /var/log/hermes/teams-pipeline-maintain.log 2>&1
-```
-
-确保 cron 环境中包含 `MSGRAPH_*` 凭据。最简单的方法：在 crontab 调用的包装脚本顶部 source `~/.hermes/.env`。
-
-#### 验证续期是否正常工作
-
-设置好计划任务后，在首次计划运行后检查续期活动：
-
-```bash
-hermes teams-pipeline subscriptions   # 应显示 expirationDateTime 已推进
-hermes teams-pipeline maintain-subscriptions --dry-run   # 大多数时候应显示"0 expiring soon"
-```
-
-如果你发现 Graph webhook 在恰好约 72 小时后神秘地"停止工作"，这是首先要检查的地方：续期任务是否实际运行了？
-
-### 查看最近的任务
-
-```bash
-hermes teams-pipeline list
-hermes teams-pipeline list --status failed
-hermes teams-pipeline show <job-id>
-```
-
-### 重放已存储的任务
-
-```bash
-hermes teams-pipeline run <job-id>
-```
-
-### 干运行会议产物拉取
-
-```bash
-hermes teams-pipeline fetch --meeting-id <meeting-id>
-hermes teams-pipeline fetch --join-web-url "<join-url>"
-```
-
-## 日常运行手册
-
-### 首次设置后
-
-按顺序执行：
-
-```bash
-hermes teams-pipeline validate
-hermes teams-pipeline token-health --force-refresh
-hermes teams-pipeline subscriptions
-```
-
-然后触发或等待一个真实的会议事件，并确认：
-
-```bash
-hermes teams-pipeline list
-hermes teams-pipeline show <job-id>
-```
-
-### 每日或定期检查
-
-- 运行 `hermes teams-pipeline maintain-subscriptions --dry-run`
-- 检查 `hermes teams-pipeline list --status failed`
-- 确认 Teams 投递目标仍为正确的聊天或频道
-
-### 变更 webhook URL 或投递目标前
-
-- 更新公共通知 URL 或 Teams 目标配置
-- 运行 `hermes teams-pipeline validate`
-- 续期或重新创建受影响的订阅
-- 确认新事件落入预期的接收端
-
-## 故障排查
-
-### 未创建任何任务
-
-检查：
-- `msgraph_webhook` 是否已启用
-- 公共通知 URL 是否指向 `/msgraph/webhook`
-- 订阅中的 client state 是否与 `MSGRAPH_WEBHOOK_CLIENT_STATE` 匹配
-- 订阅是否在远端仍然存在且未过期
-
-### 任务停留在重试状态或在摘要生成前失败
-
-检查：
-- 转录权限及可用性
-- 录制权限及产物可用性
-- 若启用了录制回退，检查 `ffmpeg` 是否可用
-- Graph token 健康状态
-
-### 摘要已生成但未投递到 Teams
-
-检查：
-- `platforms.teams.enabled: true`
-- `delivery_mode`
-- webhook 模式下的 `incoming_webhook_url`
-- Graph 模式下的 `chat_id` 或 `team_id` 加 `channel_id`
-- 若使用 Graph 发帖，检查 Teams auth 配置
-
-### 重复或意外的重放
-
-检查：
-- 是否手动通过 `hermes teams-pipeline run` 重放了任务
-- 该会议的 sink 记录是否已存在
-- 是否在本地配置中有意启用了重发路径
-
-## 上线检查清单
-
-- [ ] Graph 凭据已存在且正确
-- [ ] `msgraph_webhook` 已启用且可从公网访问
-- [ ] `MSGRAPH_WEBHOOK_CLIENT_STATE` 已设置且与订阅匹配
-- [ ] 转录订阅已创建
-- [ ] 若需要 STT 回退，录制订阅已创建
-- [ ] 若启用录制回退，`ffmpeg` 已安装
-- [ ] Teams 出站投递目标已配置并验证
-- [ ] Notion 和 Linear 接收端仅在实际需要时配置
-- [ ] `hermes teams-pipeline validate` 返回 OK 快照
-- [ ] `hermes teams-pipeline token-health --force-refresh` 执行成功
-- [ ] **`maintain-subscriptions` 已配置计划任务**（Hermes cron、systemd timer 或 crontab——参见[自动化订阅续期](#automating-subscription-renewal-required-for-production)）。若未配置，Graph 订阅将在 72 小时内静默过期。
-- [ ] 一个真实的端到端会议事件已生成存储任务
-- [ ] 至少一条摘要已到达预期的投递接收端
-
-## 投递模式决策指南
-
-| 模式 | 适用场景 | 权衡 |
-|------|----------|----------|
-| `incoming_webhook` | 仅需简单地向 Teams 发帖 | 配置最简单，控制较少 |
-| `graph` | 需要通过 Graph 向频道或聊天发帖 | 控制更多，auth 和目标配置更复杂 |
-
-## 操作员工作表
-
-上线前填写：
-
-| 项目 | 值 |
-|------|-------|
-| 公共通知 URL | |
-| Graph 租户 ID | |
-| Graph 客户端 ID | |
-| Webhook client state | |
-| 转录资源订阅 | |
-| 录制资源订阅 | |
-| Teams 投递模式 | |
-| Teams 聊天 ID 或团队/频道 | |
-| Notion 数据库 ID | |
-| Linear 团队 ID | |
-| Store 路径覆盖（如有） | |
-| 每日检查负责人 | |
-
-## 变更审查工作表
-
-变更部署前使用：
-
-| 问题 | 答案 |
-|----------|--------|
-| 是否正在变更公共 webhook URL？ | |
-| 是否正在轮换 Graph 凭据？ | |
-| 是否正在变更 Teams 投递模式？ | |
-| 是否正在迁移到新的 Teams 聊天或频道？ | |
-| 订阅是否需要重新创建或续期？ | |
-| 是否需要重新进行端到端验证？ | |
-
-## 相关文档
-
-- [Teams Meetings 设置](/user-guide/messaging/teams-meetings)
-- [Microsoft Teams bot 设置](/user-guide/messaging/teams)

package/docs/80_upstream-docs-and-skills/hermes-dev-skill/src/i18n/zh-Hans/guides/pipe-script-output.md

@@ -1,217 +0,0 @@
----
-sidebar_position: 12
-title: "将脚本输出推送到消息平台"
-description: "使用 `hermes send` 将任意 shell 脚本、cron 任务、CI hook 或监控守护进程的文本发送到 Telegram、Discord、Slack、Signal 等平台。"
----
-
-# 将脚本输出推送到消息平台
-
-`hermes send` 是一个轻量、可脚本化的 CLI，能将消息推送到 Hermes 已配置的任意消息平台。可以把它理解为跨平台的通知专用 `curl`——无需运行中的 gateway，无需 LLM，也无需在每个脚本里重复粘贴 bot token。
-
-适用场景：
-
-- 系统监控（内存、磁盘、GPU 温度、长时任务完成通知）
-- CI/CD 通知（部署完成、测试失败）
-- 需要将结果推送给你的 cron 脚本
-- 从终端发送一次性消息
-- 将任意工具的输出管道到任意平台（`make | hermes send --to slack:#builds`）
-
-该命令复用 `hermes gateway` 已有的凭据和平台适配器，无需维护第二套配置。
-
----
-
-## 快速开始
-
-```bash
-# 向某平台的默认频道发送纯文本
-hermes send --to telegram "deploy finished"
-
-# 将任意命令的 stdout 通过管道传入
-echo "RAM 92%" | hermes send --to telegram:-1001234567890
-
-# 发送文件
-hermes send --to discord:#ops --file /tmp/report.md
-
-# 附加主题/标题行
-hermes send --to slack:#eng --subject "[CI] build.log" --file build.log
-
-# 指定线程目标（Telegram 话题、Discord 线程）
-hermes send --to telegram:-1001234567890:17585 "threaded reply"
-
-# 列出所有已配置的目标
-hermes send --list
-
-# 按平台过滤
-hermes send --list telegram
-```
-
----
-
-## 参数参考
-
-| 标志 | 说明 |
-|------|-------------|
-| `-t, --to TARGET` | 目标地址。参见[目标格式](#target-formats)。 |
-| `message`（位置参数） | 消息文本。省略时从 `--file` 或 stdin 读取。 |
-| `-f, --file PATH` | 从文件读取消息体。`--file -` 强制从 stdin 读取。 |
-| `-s, --subject LINE` | 在消息体前添加标题/主题行。 |
-| `-l, --list` | 列出可用目标。可选位置参数用于按平台过滤。 |
-| `-q, --quiet` | 成功时不输出到 stdout（仅返回退出码——适合脚本使用）。 |
-| `--json` | 输出发送结果的原始 JSON。 |
-| `-h, --help` | 显示内置帮助文本。 |
-
-### 目标格式 {#target-formats}
-
-| 格式 | 示例 | 含义 |
-|--------|---------|---------|
-| `platform` | `telegram` | 发送到该平台配置的默认频道 |
-| `platform:chat_id` | `telegram:-1001234567890` | 指定数字 chat / 群组 / 用户 |
-| `platform:chat_id:thread_id` | `telegram:-1001234567890:17585` | 指定线程或 Telegram 论坛话题 |
-| `platform:#channel` | `discord:#ops` | 易读的频道名称（通过频道目录解析） |
-| `platform:+E164` | `signal:+15551234567` | 以电话号码寻址的平台：Signal、SMS、WhatsApp |
-
-Hermes 附带适配器的所有平台均可作为目标：
-`telegram`、`discord`、`slack`、`signal`、`sms`、`whatsapp`、`matrix`、
-`mattermost`、`feishu`、`dingtalk`、`wecom`、`weixin`、`email` 等。
-
-### 退出码
-
-| 码 | 含义 |
-|------|---------|
-| `0` | 发送（或列出）成功 |
-| `1` | 平台层面投递失败（认证、权限、网络） |
-| `2` | 用法 / 参数 / 配置错误 |
-
-退出码遵循标准 Unix 惯例，脚本可以像处理 `curl` 或 `grep` 一样对其进行分支判断。
-
----
-
-## 消息体解析顺序
-
-`hermes send` 按以下顺序解析消息体：
-
-1. **位置参数** — `hermes send --to telegram "hi"`
-2. **`--file PATH`** — `hermes send --to telegram --file msg.txt`
-3. **管道 stdin** — `echo hi | hermes send --to telegram`
-
-当 stdin 是 TTY（无管道）时，Hermes **不会**等待输入——你会收到明确的用法错误提示。这可以防止脚本在意外省略消息体时挂起。
-
----
-
-## 实际使用示例
-
-### 监控：内存 / 磁盘告警
-
-用一行简洁的代码替换 watchdog 脚本中的 `curl https://api.telegram.org/...` 调用：
-
-```bash
-#!/usr/bin/env bash
-ram_pct=$(free | awk '/^Mem:/ {printf "%d", $3 * 100 / $2}')
-if [ "$ram_pct" -ge 85 ]; then
-  hermes send --to telegram --subject "⚠ MEMORY WARNING" \
-    "RAM ${ram_pct}% on $(hostname)"
-fi
-```
-
-由于 `hermes send` 复用你的 Hermes 配置，同一脚本可在任何安装了 Hermes 的主机上运行——无需手动将 bot token 导出到每台机器的环境变量中。
-
-:::tip 不要用 gateway 监控自身
-对于可能在 gateway 本身出现问题时触发的 watchdog（OOM 告警、磁盘满告警），请继续使用最简单的 `curl` 调用，而非 `hermes send`。如果 Python 解释器因机器抖动无法加载，你仍然希望告警能发出去。
-:::
-
-### CI / CD：构建与测试结果
-
-```bash
-# 在 .github/workflows/deploy.yml 或任意 CI 脚本中
-if ./scripts/deploy.sh; then
-  hermes send --to slack:#deploys "✅ ${CI_COMMIT_SHA:0:7} deployed"
-else
-  tail -n 100 deploy.log | hermes send \
-    --to slack:#deploys --subject "❌ deploy failed"
-  exit 1
-fi
-```
-
-### Cron：每日报告
-
-```bash
-# Crontab 条目
-0 9 * * * /usr/local/bin/generate-metrics.sh \
-  | /home/me/.hermes/bin/hermes send \
-      --to telegram --subject "Daily metrics $(date +%Y-%m-%d)"
-```
-
-### 长时任务：完成后推送通知
-
-```bash
-./train.py --epochs 200 && \
-  hermes send --to telegram "training done" || \
-  hermes send --to telegram "training failed (exit $?)"
-```
-
-### 脚本中使用 `--json` 与 `--quiet`
-
-```bash
-# 投递失败时让脚本硬失败；成功时不污染日志
-hermes send --to telegram --quiet "keepalive" || {
-  echo "Telegram delivery failed" >&2
-  exit 1
-}
-
-# 捕获消息 ID 以便后续编辑 / 回复线程
-msg_id=$(hermes send --to discord:#ops --json "build started" \
-  | jq -r .message_id)
-```
-
----
-
-## `hermes send` 需要 gateway 运行吗？
-
-**通常不需要。** 对于所有基于 bot token 的平台——Telegram、Discord、Slack、Signal、SMS、WhatsApp Cloud API 等——`hermes send` 直接使用 `~/.hermes/.env` 和 `~/.hermes/config.yaml` 中的凭据调用平台的 REST 接口。它是一个独立的子进程，消息投递完成后即退出。
-
-只有依赖持久适配器连接的**插件平台**才需要运行中的 gateway（例如，某个保持长连接 WebSocket 的自定义插件）。此时你会收到明确的错误提示，指引你启动 gateway；执行 `hermes gateway start` 后重试即可。
-
----
-
-## 列出与发现目标
-
-在向特定频道发送消息之前，可以查看可用目标：
-
-```bash
-# 列出所有已配置平台的所有目标
-hermes send --list
-
-# 仅列出 Telegram 目标
-hermes send --list telegram
-
-# 机器可读格式
-hermes send --list --json
-```
-
-列表数据来源于 `~/.hermes/channel_directory.json`，gateway 运行期间每隔几分钟刷新一次。如果看到"尚未发现频道"，请先启动一次 gateway（`hermes gateway start`）以填充缓存。
-
-易读名称（`discord:#ops`、`slack:#engineering`）在发送时通过该缓存解析，无需记忆数字 ID。
-
----
-
-## 与其他方案的对比
-
-| 方案 | 多平台 | 复用 Hermes 凭据 | 需要 gateway | 最适合 |
-|----------|----------------|---------------------|---------------|----------|
-| `hermes send` | ✅ | ✅ | 否（bot token） | 以下所有场景 |
-| 对各平台直接 `curl` | 各自单独编写 | 手动管理 | 否 | 关键 watchdog |
-| 带 `--deliver` 的 `cron` 任务 | ✅ | ✅ | 否 | 定时 agent 任务 |
-| `send_message` agent 工具 | ✅ | ✅ | 否 | agent 循环内部 |
-
-`hermes send` 有意保持最简接口。如果需要 agent 决定说什么，请在对话或 cron 任务中使用 `send_message` 工具。如果需要定时运行并生成 LLM 内容，请使用带 `deliver='telegram:...'` 的 `cronjob(action='create', prompt=...)`。如果只需要管道传输原始字符串，直接用 `hermes send`。
-
----
-
-## 相关文档
-
-- [用 Cron 自动化一切](/guides/automate-with-cron) —
-  输出自动投递到任意平台的定时任务。
-- [Gateway 内部机制](/developer-guide/gateway-internals) —
-  `hermes send` 与 cron 投递共享的投递路由器。
-- [消息平台配置](/user-guide/messaging/) —
-  各平台的一次性配置说明。