docs(knowledge): add vLLM-Router release standard (#444)

## Summary

Extends the `knowledge/repos/vllm-router/` slice, which #445 created and
has since merged, with CI and release knowledge. It also merges the
repository entry so one page routes both the `bug/` and `ci/` work
topics, and brings the shared DI rule in line with the review feedback
on this PR.

Router statements are checked against `main@ddf78218` (2026-11-09) and
against the published channels: PyPI, Docker Hub, and GitHub Releases.

## Contents

1. `_index.md` — merged repository entry. Routes issue triage to `bug/`
and release work to `ci/`, keeps the package, module, and alias mapping,
records the audited `main` revision, and states that no component owners
or `_routes.yaml` exist yet.
2. `ci/_index.md` — CI entry. Describes the four Buildkite lanes with
their real upload gates (non-default branch plus `ready`; default
branch, merge queue, or `merge-test`; default branch with `NIGHTLY=1` or
`nightly-test`), the jobs each lane runs (P/D smoke, kv_aware e2e, gRPC
P/D, GSM8K, gRPC prefix-KV perf, L1 encode perf, ROCm xGMI and RDMA
matrices), the pytest markers, and the hardware presets.
3. `ci/release-gates.md` — release standard:
1. Version sources: `pyproject.toml` is the only value `version-check`
reads, while four files must be bumped together.
2. Published-artifact cross-check: git tags, PyPI versions, Docker Hub
tags, and GitHub Releases side by side, including tags without artifacts
(`v0.1.11`, `v0.1.13`, `v0.1.14`) and the Docker-only `v0.1.16.1`.
3. Hard gates: tag-to-`pyproject.toml` equality; x86_64 and aarch64
manylinux_2_28 builds with `auditwheel`; binary and wheel smoke tests;
the `twine` PyPI chain; the Docker confirmation sequence; nightly image
publication and 14-tag retention.
4. Quality gates and evidence rules: L2 and L3 results; Python coverage
read from the router coverage dashboard, with Rust coverage gated on a
self-built collector agreed at kickoff; per-scenario performance
comparison; requirement completion; remaining DI; critical-issue
ownership.
5. Failure modes and release steps, including manual GitHub Release
authoring because no pipeline step creates releases.
4. `knowledge/general/bug/guides/di-calculation.md` and
`knowledge/general/bug/_index.md` — shared DI rule refresh: DI is no
longer accumulated by days open; breaching the SLO escalates the issue
one severity level and DI takes the new level's base value. Severity
criteria for critical, high, medium, and low are recorded there so the
router page can link instead of restating them.

## Metadata

No additional metadata changes in this diff. The `vllm-router` ownership
tag and the `repos/_index.md` row landed with #445; this PR reuses them
and only merges the entry page.

## Validation

1. `python knowledge/tools/check_knowledge_tree.py` — no errors and no
warnings for the merged entry, the CI pages, or the two updated DI
pages. Three pre-existing errors remain for three `rules.md` pages
elsewhere in the tree on a local Windows autocrlf checkout; their LF
blobs are under the 32768-byte threshold, so these are line-ending
artifacts of the local checkout and are unrelated to this change.
2. `python knowledge/tools/check_wiki_lint.py` — no errors and no
warnings across 1531 pages.

## Boundary

The vLLM Router slice covers issue triage, CI, and release knowledge
only. `components/`, `models/`, and `_routes.yaml` are not established,
and `adapters/vllm_router` only injects the triage briefing, so the
release page must not be treated as a code owner during review.

Author: KaisennHu

knowledge/general/bug/_index.md

@@ -1,7 +1,7 @@
 ---
 title: "Bug"
 created: 2026-08-07
-updated: 2026-08-07
+updated: 2026-11-09
 type: index
 tags: [general, bug]
 sources: []
@@ -22,5 +22,5 @@ sources: []
 
 | 遇到什么 | 查看哪里 | 说明 |
 |---|---|---|
-| 按优先级与 SLO 计算 DI | [DI 计算说明](guides/di-calculation.md) | 分级表、偶现降级、按 SLO 累加 |
+| 按优先级与 SLO 计算 DI | [DI 计算说明](guides/di-calculation.md) | 分级表、偶现降级、达到 SLO 升一级 |
 | 查找其他 Bug 专项 | [guides 索引](guides/_index.md) | 当前有效的 Bug 方法入口 |

knowledge/general/bug/guides/di-calculation.md

@@ -1,40 +1,42 @@
 ---
 title: "DI 计算说明"
 created: 2026-08-07
-updated: 2026-09-22
+updated: 2026-11-09
 type: guide
 tags: [general, bug]
-sources: []
+sources: ["PR #444 review 2026-11-09"]
 ---
 
 # DI 计算说明
 
-按 Bug 优先级给出基础 DI（Defect Intensity）与 SLO，并说明偶现降级与按 SLO 累加的计算方式。
+按 Bug 优先级给出基础 DI（Defect Intensity）与 SLO，并说明偶现降级与 SLO 升级的计算方式。
+现行口径不按未关闭天数累加：issue 达到 SLO 后严重度升一级，DI 取升级后级别的基础值。
 相关入口：[bug 主题](../_index.md)、[调试](../../debug/_index.md)、[测试与 CI](../../ci/_index.md)。
 
 ## Bug 分级标准
 
 | Bug 优先级分类 | 划分标准 | DI 值 | SLO |
 |---|---|---|---|
-| critical | 高优先级 | 10 | 1 天 |
-| high priority | CI Failure | 3 | 5 天 |
-| medium priority | 中优先级 | 1 | 10 天 |
-| low priority | 低优先级 | 0.1 | 14 天 |
+| critical | 数据损坏或结果错误、服务不可用、安全或凭据问题、静默路由错误 | 10 | 1 天 |
+| high priority | 默认分支 CI 失败、主路径功能不可用、明确的精度或性能回退 | 3 | 5 天 |
+| medium priority | 功能受损但存在可用绕过、非主路径报错 | 1 | 10 天 |
+| low priority | 体验、日志、文档和提示类问题 | 0.1 | 14 天 |
 | invalid | 非问题 | 0 | / |
 
-## 其他规则
+定级由 issue 负责人按上表判定；同一个问题同时满足多行时取最高一级，并以仓库实际使用的
+severity label 或发布记录留痕。
 
-1. **偶现降级**：若为偶现问题，分类等级自动降低一级。
-2. **按 SLO 累加**：每达到一次 SLO，DI 值累加一次。
+## 其他规则
 
-### 累加示例
+1. **偶现降级**：偶现问题在初始级别上降一级。
+2. **SLO 升级**：DI 不按天数累加；issue 未关闭时间达到 SLO 后严重度升一级，DI 取升级后级别
+   的基础值。重复升级的粒度以当期发布说明为准，最高不超过 critical。
+3. **invalid 恒为 0**：不参与剩余 DI 汇总。
 
-critical 等级 bug（基础 DI = 10，SLO = 1 天）：
+### 升级示例
 
-| 未关闭天数 | 达到的 SLO 次数 | DI |
-|---|---|---|
-| 第 1 天 | 1 | 10 |
-| 第 2 天 | 2 | 20 |
-| 第 3 天 | 3 | 30 |
+medium 级 issue（基础 DI = 1，SLO = 10 天）在第 10 天仍未关闭时升为 high，DI 取 3；若继续
+跨过 high 的 SLO，则再升为 critical，DI 取 10。
 
-通式：`DI = 基础 DI × ⌈未关闭天数 / SLO 天数⌉`（`invalid` 始终为 0）。
+通式：`DI = 基础 DI(当前级别)`，`当前级别 = 初始级别 + 已跨过的 SLO 次数`（上限 critical，
+`invalid` 始终为 0）。

knowledge/repos/vllm-router/_index.md

@@ -4,31 +4,45 @@ created: 2026-11-10
 updated: 2026-11-10
 type: index
 tags: [vllm-router]
-sources: []
+sources: [pyproject.toml, .buildkite/README.md, "vllm-project/router@ddf78218cffdb6361579d3babd69a90ba6d63aaa"]
 ---
 
 # vLLM Router 仓库知识入口
 
 ## 仓库和适用范围
 
-- 上游仓库：`vllm-project/router`。
+- 上游仓库：`vllm-project/router`。PyPI 包 `vllm-router`，Python 模块 `vllm_router`，console
+  script 与 Rust 二进制都叫 `vllm-router`；默认分支 `main`，tag 形如 `v0.1.17`。
 - Canonical slug：`vllm-router`。别名包括 `vllm_router` 与 GitHub 仓库名 `router`。
-- 适用范围：该仓库的 issue 分诊与优先级打标。
+- 适用范围：该仓库的 issue 分诊与优先级打标，以及 CI 与发布知识；发版事实按
+  `main@ddf78218` 与 tag `v0.1.17` 核对。
 
 ## 什么时候查这里
 
 - 用户给出 `vllm-project/router`、`vllm-router` 或 `router`，需要映射到本目录。
 - 为该仓库的 issue 选择致命、高、中、低。
+- 判断本仓库怎么发版：tag 形态、版本号要同步哪几份文件、PyPI/镜像产物哪些是硬门禁。
+- 区分 L1 ready / L2 merge / L3 nightly 与 `release` 四条 Buildkite 通道的适用范围。
 
 ## 不放什么
 
-- 换仓库仍然成立的方法放 [general](../../general/_index.md)。
+- 换仓库仍然成立的方法放 [general](../../general/_index.md)，包括通用的发版、CI 和 DI 口径。
 - 其他仓库的调度实现、模型或 CI 经验。
 - 单次 issue 的调查时间线、PR 复盘和评测记录。
+- 机器地址、queue 凭据、本地 checkout 路径 → Git 忽略的 `local/`。
 
 ## 目录内容
 
 | 遇到什么 | 查看哪里 | 说明 |
 |---|---|---|
 | 给 `vllm-project/router` 的 issue 定级或打标 | [issue 分级规则](bug/rules.md) | 致命 / 高 / 中 / 低；先看影响，再看特性 |
 | 查看本仓库的 Bug 主题入口 | [bug](bug/_index.md) | 只路由到分级规则 |
+| 发版门禁、tag 与版本号同步、PyPI/Docker/GitHub Release 产物核对和常见失败 | [发布规范](ci/release-gates.md) | `release-pipeline.yml` 真实执行的门禁 + 发布前质量门槛 |
+| L1/L2/L3 通道、pytest marker、GPU preset、nightly 与 release 的分工 | [CI 入口](ci/_index.md) | 只写本仓库相对通用 CI 的差异 |
+
+## 当前边界
+
+本切片目前只有 `bug/` 与 `ci/` 两个工作主题。`components/`、`models/` 和代码 owner 路由
+（`_routes.yaml`）尚未建立；`adapters/vllm_router` 只在 issue 分诊时注入 briefing，不提供代码
+owner 路由。审查本仓库代码时不能把发布页当代码 owner，必须按 live 源码和 PR changed files
+自行定位。

knowledge/repos/vllm-router/ci/_index.md

@@ -0,0 +1,57 @@
+---
+title: "vLLM-Router CI"
+created: 2026-11-06
+updated: 2026-11-09
+type: index
+tags: [vllm-router, ci]
+sources: [.buildkite/README.md, .buildkite/pipeline.yml, .buildkite/test-ready.yml, .buildkite/test-merge.yml, .buildkite/test-nightly.yml, .buildkite/release-pipeline.yml, .buildkite/ci_mirror_hardwares.yml, .buildkite/scripts/build-ci-image.sh, pytest.ini, tests/python/helpers/mark.py, "vllm-project/router@ddf78218cffdb6361579d3babd69a90ba6d63aaa"]
+---
+
+# vLLM-Router CI
+
+## 什么时候查这里
+
+- 判断某类改动该进 L1 ready、L2 merge 还是 L3 nightly，或核对某个 job 的实际触发条件。
+- 发版前确认默认分支上哪条通道的结果才算证据 → 见下面目录里的发布规范。
+
+## 不放什么
+
+- 跨仓库通用的测试选择方法 → [通用 CI](../../../general/ci/_index.md)。
+- 具体 job 的历史失败复盘；需要时看对应 Buildkite build。
+
+## 上传条件
+
+`pipeline.yml` 先构建 Rust release 二进制、wheel 和 NVIDIA CI 镜像，再按分支和 label 上传三个
+测试文件。上传只依赖 `build` 组，彼此不依赖；GPU job 还要等 `image-build`。CI 镜像由
+`docker/Dockerfile.ci` 推到共享 ECR，tag 里带 `router-<commit>`，不会顶掉同 commit 的其他项目镜像。
+
+| 通道 | 触发 | 内容 | 证据边界 |
+|---|---|---|---|
+| L1 ready | 非默认分支带 `ready` label（fork 也跑） | Rust 单测/集成（`--features cpu,ready`）、Python 单测（`-m "ready and cpu"`，`--ignore=tests/python/e2e`，产出 `coverage.xml`）、P/D smoke（4×L4，`SKIP_LM_EVAL`，1 条 sanity）、kv_aware e2e（2×L4）、gRPC P/D smoke（4×L4，`RUN_LM_EVAL=0`） | 只证明该 PR 自身可合并，不能当默认分支健康度 |
+| L2 merge | 默认分支 push（`NIGHTLY != 1`）、merge queue（base 为默认分支）、或 `merge-test` label | xGMI smoke（`read_mode=true`、GSM8K `LM_EVAL_LIMIT=20`、基线 0.38 允许 −0.03）、RDMA `SMOKE_ONLY`（两节点） | 默认分支健康度与 ROCm 平台基线 |
+| L3 nightly | 默认分支 `NIGHTLY=1`，或 `nightly-test` label | 单测（PR 同时带 `ready` 时整组跳过）、P/D 全量 GSM8K（HTTP 与 gRPC）、gRPC prefix-KV perf（`rust_grpc` + `python_http`，`c16-r32`、`hit99-c4`、`hit99-c64`，2×H100）、L1 encode perf（Qwen3-0.6B，1×L4，`hit0.30`/`hit0.99999` × `c4`/`c16`，L1 on/off）、ROCm xGMI 与 RDMA 的 read true/false 矩阵 | 覆盖最广，但不阻塞 PR，过期结果不能当发版证据 |
+| release | `v*` tag 或手动触发 | 只构建 wheel/二进制、smoke、发 PyPI、发镜像 | 不跑 L1–L3，见发布规范 |
+
+几处窄 gate 容易漏：L1 与 L3 的 NVIDIA GPU job 在 `ROCM_ONLY=1` 时跳过；L3 的 xGMI 还接受
+UI/API 加 `RUN_ROCM_XGMI=1`，RDMA 只接受 schedule 加 `NIGHTLY=1`、`nightly-test` label，或
+UI/API 加 `RUN_ROCM_RDMA=1`。
+
+## 测试分级标记
+
+- 层级与机器用 pytest marker 表达：`ready`、`L4`、`MI300`、`cpu`、`cuda`、`rocm`、`gpu`、
+  `cards_{1,2,4}`，登记在 `pytest.ini`；`hardware_test(res=..., num_cards=N)` 会派生对应
+  SKU/平台/卡数 mark（`tests/python/helpers/mark.py`）。
+- 新增或改动测试必须带层级和机器标记，`pre-commit` 的 `check-mark`
+  （`tools/pre_commit/check_test_marks.py`）会拦缺标记的 PR；Rust 侧用 Cargo feature（`cpu`、`ready`）。
+- L3 的 Rust 与 Python 单测和 L1 用同一组 `--features cpu,ready` / `-m "ready and cpu"`，单测覆盖
+  不随层级变大；L3 多出来的是 GPU/ROCm 矩阵、GSM8K 和两个 perf job。
+- GPU job 在 `ci_mirror_hardwares.yml` 里按 preset 取机器：`l4_1`（L1 encode perf）、
+  `l4_2`（kv_aware）、`l4_4`（P/D 与 gRPC）、`h100_2`（prefix-KV perf）、`mi300_2`（xGMI）、
+  `mi300_rdma`（两节点 RDMA）。job 写 `mirror_hardwares`，由 `scripts/upload_pipeline.py` 展开成
+  agents 和 plugins。
+
+## 目录内容
+
+| 遇到什么 | 查看哪里 | 说明 |
+|---|---|---|
+| 发版门禁、tag/版本一致性、PyPI 与 Docker 发布顺序、发布产物核对 | [发布规范](release-gates.md) | 硬门禁与质量门槛分栏，含常见失败模式 |