Pulse v6 GA 门禁解析：known-rc-issue-closure-for-ga 阻塞记录与 RC 已知问题关闭实践

Pulse 在 v6 正式版（GA）发布之前，把「RC 时期已知用户可见问题」的关闭状态作为一道独立的发布信任门禁 known-rc-issue-closure-for-ga。本文以 2026-04-21 的那份 blocked 阻塞记录为线索，还原这道门禁的判定逻辑、阻塞事实、解锁步骤，并结合仓库内的发布策略、预发布检查清单与后续通过记录，说明如何把「RC 问题必须逐项给出处置」的纪律落地成可审计的发布证据。读完本文，你将理解 GA 前的 RC 问题清账机制，以及如何在发布门禁体系中用「修复 + 验证 / 证明无效 / 保守 supersede」三种方式收敛历史遗留问题。

记录背景：这道门禁在发布信任体系中处于什么位置

Pulse 的发布控制体系集中在 docs/release-control/v6/internal/ 下，其中 status.json 用机器可读的方式声明了从 repo-ready、rc-ready 到 release-ready 的三级就绪规则，并把关键信任门禁挂在具体的 release_gate_ids 上。known-rc-issue-closure-for-ga 正是其中被 RA8 这条 release-ready 断言引用的门禁之一，与 rc-to-ga-promotion-readiness、self-hosted-commercial-ga-coherence 并列，用于守住「GA/stable 提升」这一最高风险动作。

这道门禁背后的产品原则，在 RELEASE_PROMOTION_POLICY.md 的稳定提升规则中被明确写死：

• 首次稳定版或 RC-required 的稳定提升，要求「面向 v6 GA 范围、已知且未解决的 RC 时代用户可见问题不能保持 open」；
• 每个此类问题必须在候选版本中被修复、用证据证明无效，或被保守地 supersede（且原始用户可见故障必须已解决或被明确收窄）；
• GA 候选必须附带一份「有日期的 RC 问题关闭记录」，把最终问题集合及其处置显式写进提升包（Required Release Artifacts 第 10 条）。

也就是说，blocked 不是「还有 bug」的笼统表态，而是「针对 GA 候选的、逐项的 RC 问题清账记录尚未达标」的精确结论。

阻塞记录全景：2026-04-21 发生了什么

被分析的这份记录位于 known-rc-issue-closure-for-ga-blocked-2026-04-21.md，核心元数据如下：

字段	值
Date	2026-04-21
Gate	known-rc-issue-closure-for-ga
Result	blocked

记录正文由三部分组成：Blocking Facts（阻塞事实）、Why The Gate Cannot Be Cleared Yet（为何不能清除）、Required Unblock Steps（解锁步骤）。下面逐一展开。

阻塞事实一：不是未标记的 RC1 漂移

记录首先排除了一种容易误判的情况：所有显式标记 affects-6.0.0-rc.1 的问题此时都已关闭，因此当时的阻塞不是「一批漏了标签的 RC1 漂移问题」。这道排除很重要——它说明门禁审查的是「显式进入 v6 范围、被用户标签确认过」的问题集合，而非对所有历史 issue 做无差别扫描。这也与 PRE_RELEASE_CHECKLIST.md 中「该记录必须枚举带 affects-6.0.0-rc.* 标签的问题，外加 owner 仍期望 v6 GA 处理的开放 RC-soak 问题」的要求对应。

阻塞事实二：唯一开放的 RC2 标记问题 #1435

当时唯一仍显式标记 affects-6.0.0-rc.2 且未关闭的问题是：

#1435（[Bug]: LXC command installing v6.0.0-rc.2）

问题内容指向：通过 LXC 命令安装时，会安装到 v6.0.0-rc.2 这个预发布版本上。对 GA 而言，这是「安装路径默认落到预发布标签」的产品正确性缺陷，直接影响 fresh Proxmox LXC 安装用户。它是这道门禁被标为 blocked 的直接触发项之一。

阻塞事实三：持续活跃的 RC-soak 问题清单

除了 #1435，记录还列举了在 v6 主线上仍然 open 的 RC soak 问题，这些是从 RC 浸泡期暴露、但尚未完成处置的用户可见问题：

编号	标题	暴露的缺陷类型
#1409	No limit devices for self-hosted / homelab	自托管安装上仍显示过期的 rc.2 容量文案（stale cap copy），当日 2026-04-21 的截图可证
#1429	missing docker info including updates	可发现性、过期容量文案、compare-plans 交接、趋势措辞等用户信任问题
#1430	Width of the Name column	Firefox 下表格列宽失控（layout 失败）
#1432	Dashbord filter	仪表盘/工作负载状态过滤行为未达预期
#1436	Better disk i/o reads for LXC containers	RC soak 期间发现的 LXC 工作负载可见性缺口

这五条恰好覆盖了 RC 程序想要在发布前捕获的几类典型问题：回归（stale cap copy）、信任断裂（trust breaks）、布局失败（Firefox 表格）、功能预期缺口（dashboard filter）、指标覆盖缺口（LXC disk I/O）。它们都不是「锦上添花」，而是会让 stable 用户直接感知的行为差异。

阻塞事实四：本地修复存在，但不是充分证据

记录明确承认，pulse/v6-release 分支上已经存在若干本地修复：

• 4711d1116 对应 #1435 的修复；
• 770cceae5 以及相关的 cap-scrub 提交，对应 #1409、#1429 中反复出现的 stale self-hosted cap 回归。

但记录的结论非常明确：local fixes alone are not sufficient evidence to clear the GA issue-closure rule。原因可以从 RELEASE_PROMOTION_POLICY.md 的运行验证声明等级理解——implemented 只代表「源码变更和定向回归测试存在」，它不等于「发布产物包含该变更」，更不等于「真实硬件上行为已验证」。要清除这道门禁，需要的是一份针对实际 GA 候选、逐项记录 disposition 的 dated closure record，而非散落的提交哈希。

阻塞事实五：owner 锁定了 feature-complete 产品真相

最后一个阻塞事实是原则性的：项目 owner 此时已锁定更严格的 v6 GA 定义——Pulse v6 在 GA 时应当 feature-complete，因此已知的 RC 时代用户可见问题不能作为遗留（carryover）被接受。这条原则把「GA 前必须清账」从可选项变成了硬约束，也正是后续 policy 中「不得把 open 的 RC 时代用户可见问题当作 'post-GA cleanup' 正常化」的直接来源。

为什么这道门禁在那一刻无法清除

记录用一段话给出了门禁无法清除的根本理由，可以拆解为三层逻辑：

1. RC 程序的存在意义，就是暴露那些若不拦截就会到达 stable 用户的 bug、回归、布局失败、信任断裂与覆盖缺口；
2. 一旦把 v6 GA 定义为「对已准入 v6 范围 feature-complete」，这些 RC 问题就不能因为推广包已经演练过就被正常化为 'post-GA cleanup'；
3. 若带着开放的 RC 问题集直接发布 GA，等于让 stable 用户继承本应保护他们的验证队列（validation cohort）尚未解决的反馈。

简言之：推广流程本身（promotion packet）跑通 ≠ 产品质量达标；问题关闭证据才是门禁的判定依据。

解锁步骤：把门禁从 blocked 推进到 pass

记录给出了四条必须完成的解锁步骤，这也是任何后续 GA 候选执行清账工作的标准动作：

1. 物化并维护一份带日期的 RC 问题关闭记录，针对实际 GA 候选，枚举范围内每一个已知 RC 时代问题及其处置；
2. 对每个当前开放项（截至 2026-04-21 为 #1435、#1409、#1429、#1430、#1432、#1436）恰好执行以下三种处置之一：
   • 在候选中修复，并验证受影响的用户可见表面；
   • 用证据证明其无效；
   • 仅当原始用户可见故障确实已解决或被明确收窄时，才用关联的 canonical issue 保守地 supersede 它；
3. 不得把开放的 RC 时代用户可见问题当作可接受的 GA carryover；
4. 仅当 dated closure record 显示「面向 v6 GA 的 RC 时代问题」已无剩余开放项时，才把门禁从 blocked 改为通过。

注意第 2 步中的「exactly one」——三种处置是互斥且穷尽的，不允许「先发布、后补记录」或「标签合并即视为关闭」这类模糊操作。

处置方法论的落实：同一门禁从 blocked 到 pass 的实证

这份 blocked 记录不是孤立文档。仓库里保存了同一天稍后的通过记录 known-rc-issue-closure-for-ga-2026-04-21.md，恰好演示了上述三种处置如何落地：

• #1435：修复 + 验证。由 4711d1116（Fix fresh Proxmox LXC installs defaulting to RC）修复，验证命令为 go test ./scripts/installtests，结论是 stable 安装路径不再把 fresh Proxmox LXC 安装默认导向预发布标签；
• #1409：修复 + 验证。由自托管 uncapped cap scrub（943389827）与过期权益连续性修复（770cceae5）覆盖，验证覆盖 go test ./pkg/licensing ./internal/api 与前端 ProLicensePanel、licensePresentation、pricingHandoff 等测试；
• #1429：作为伞状信任报告拆解处置。把用户可见失败分解为 stale cap copy、不可用的 compare-plans/Pulse Account 交接、令人困惑的空趋势状态、v5 到 v6 的导航缺口四块，分别由 943389827/770cceae5、429f12dec、9de093725 及 guided welcome/migration 界面覆盖，并以 tests/integration 下的升级回归用例做端到端验证；
• #1430：修复 + 浏览器证据。合并 dashboard 列模型契约、移除导致 Firefox 横向溢出的全局 CSS 宽度规则后，用托管浏览器证明 wrapperClientWidth=1320、tableScrollWidth=1320、name 表头宽度 200；
• #1432：证明已满足（invalid-as-blocker）。候选已具备按状态（All/Running/Degraded/Stopped）过滤工作负载切片的能力，由 DashboardFilter.test.tsx、workloadSelectors.test.ts 验证，因此不存在缺失的离线过滤阻塞项；
• #1436：修复 + 验证。把预取的 LXC status/current 计数器合并进两条容器轮询路径后再计算速率，复用同一快照做元数据增强，由 internal/monitoring 下的 TestMergeContainerRuntimeCounters_*、TestBuildContainerFromClusterResource_* 等测试验证。

通过记录末尾的 Outcome 也再次确认了这套纪律的边界：「GitHub issue 可能仍然 open，直到公开维护者 triage 跟上当前发布线，但 GA 候选不再明知地带着这些 RC 时代故障原样发布」。也就是说，门禁通过 ≠ 所有 issue 被关闭，而是「每个 issue 都被检查并给出了显式处置」。

与发布策略、预发布检查清单的衔接

这道门禁在操作层面的承接关系很清晰：

• RELEASE_PROMOTION_POLICY.md 的 Stable Promotion Rules 明确：首次稳定版或 RC-required 提升前，范围内不能有未解决的 RC 时代用户可见问题，且 GA 提升包必须附带 dated RC issue-closure record；
• PRE_RELEASE_CHECKLIST.md 的 RC Issue Closure 一节给出了逐项执行要点：物化 dated 记录 → 枚举 affects-6.0.0-rc.* 及额外 RC-soak 问题 → 复查最新 RC 反馈入口（新 issue、新评论、置顶反馈 hub）→ 逐项记录唯一处置 → 不把 open 项带入 GA 作为 post-GA cleanup；
• 仓库还保存了这条链路的完整历史，便于对照学习：2026-05-01 的再次 blocked 记录（known-rc-issue-closure-for-ga-blocked-2026-05-01.md，因 RC3 后期问题摄入未完全处置而继续保持 blocked）、同日针对后期 issue 摄入的通过记录（known-rc-issue-closure-for-ga-late-issue-intake-2026-05-01.md），以及 2026-07-04 面向 rc.2 到 rc.6 全量标签问题的最终通过记录（known-rc-issue-closure-for-ga-2026-07-04.md），后者还示范了「部分修复」「invalid / config-side」「记录在案的 v6 升级边界」等更细的处置分级。

从这些后续记录可以看到，处置不仅限于「修复」，还包括：把问题归因到用户配置（如 #1456 的 Proxmox 401）、把「服务器升级 ≠ 自动升级 agent」记录为文档化的 v6 升级边界（如 #1498）、以及把「非 GA 阻塞但未回复」的 issue 单独列出并要求维护者至少给出回复，避免被静默带过（如 #1493、#1485、#1441）。

参考文档

• 阻塞记录：docs/release-control/v6/internal/records/known-rc-issue-closure-for-ga-blocked-2026-04-21.md
• 同日通过记录：docs/release-control/v6/internal/records/known-rc-issue-closure-for-ga-2026-04-21.md
• 发布提升策略：docs/release-control/v6/internal/RELEASE_PROMOTION_POLICY.md
• 预发布检查清单：docs/release-control/v6/internal/PRE_RELEASE_CHECKLIST.md
• 发布门禁状态机：docs/release-control/v6/internal/status.json
• 后续 blocked 与通过记录：docs/release-control/v6/internal/records/known-rc-issue-closure-for-ga-blocked-2026-05-01.md、known-rc-issue-closure-for-ga-late-issue-intake-2026-05-01.md、known-rc-issue-closure-for-ga-2026-07-04.md