docs(knowledge): add vLLM-Router release standard

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) | 硬门禁与质量门槛分栏，含常见失败模式 |