docs: 历史接口的 step 字段

src/content/dev/theme.mdx

@@ -75,7 +75,9 @@ hub 1.3.0 及更早的版本不做这项检查，所以以前装得上的包，
 - `points=W`：图表能画下的点数，60–1440。只会让 hub 抽得更稀，不会更密
 - `series=metrics|ping`：只取要画的那一类，另一类占响应的三分之一到三分之二
 
-`metrics` 的每一行描述一段时间，`minutes` 是其中有数据的分钟数，满额是点距除以 60：
+响应顶层的 `step` 是每个点覆盖的秒数：7 天以内是 60 的倍数，更宽的窗口是 3600 的倍数。
+
+`metrics` 的每一行描述一段时间，`minutes` 是其中有数据的分钟数，满额是 `step` ÷ 60：
 
 - `cpu`、`mem_used`、`disk_used`、`net_rx` / `net_tx` 是这些分钟的平均值。网速乘以 `minutes` × 60 秒
   就是这段时间的流量
@@ -84,11 +86,12 @@ hub 1.3.0 及更早的版本不做这项检查，所以以前装得上的包，
   到过多高就读这几个 key
 - `minutes` 不满额，说明节点这段时间有一部分不在线，可以用来画在线率。agent 每次连上的第一分钟不单独
   记一行，所以算出的在线率会比实际略低
+- 最后一个点是还没过完的时段，`minutes` 只算到当前，不满额不代表离线
 - 以上按 agent 每分钟至少上报一次而言（默认每秒一次）。`--interval` 超过 60 秒时，hub 只在收到上报的那一
   分钟记一行，`minutes` 按比例偏小，300 秒时只有满额的五分之一，积分出的流量和在线率都会偏低。累计流量
   以 `/api/nodes` 返回的为准
 
-hub 1.3.0 及更早没有 `net_rx_max` / `net_tx_max`，1.3.1 及更早没有 `cpu_max` 和 `minutes`。
+hub 1.3.0 及更早没有 `net_rx_max` / `net_tx_max`，1.3.1 及更早没有 `cpu_max`、`minutes` 和 `step`。
 
 延迟监控的名称在响应的 `probes` 里随数据一起返回，匿名可读，画延迟图不需要第二个请求，也不需要登录。