From 64baa876337c0772e403128d7b8bb7df7b20d68f Mon Sep 17 00:00:00 2001 From: weichen Date: Wed, 21 Oct 2026 14:36:50 +0000 Subject: [PATCH] Record the pins-layout change behind the test-pg failure MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Why: the fail-loud assertion worked as intended and named the real cause - RDM's pins set grew from four to six, so the CI step that checks out and builds all three pins no longer sees a consistent layout. My prev_sha choice was wrong and I did not check layout consistency when writing the unit. Evidence: run 4711 job 7821 - 'rdm pin c6304224 的 pins/agent-system-frontend 未落地：缺少 go.mod'; pin layouts verified across all five commits; local build-product.sh on the delivered head succeeds. Impact: task card only. Refs: PR #682 --- .task/fix-pal-component-delivery-pins.md | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/.task/fix-pal-component-delivery-pins.md b/.task/fix-pal-component-delivery-pins.md index 7b62bbf6..ea3b5d3e 100644 --- a/.task/fix-pal-component-delivery-pins.md +++ b/.task/fix-pal-component-delivery-pins.md @@ -96,7 +96,29 @@ Development-Manager PR #32（`2c2e372`）为 `admit` 增加「权威基线内容 已核实的成因：RDM `bc8db88` 的 `go.mod` 用本地路径 replace `agent-document-renderer => pins/agent-document-renderer`，因此其 `go.sum` 中**没有任何** agent-document-renderer 条目（实测计数 0）。Dev 侧构建会把 RDM 的 backend replace 重写到 `../backend`（即 Dev 的 `modules/backend`，当前 `f084d10`），而该 backend 直接 import document-renderer 的上述包，于是 RDM 的模块图无法提供对应条目。另注：RDM 自身钉的 backend 是 `bd640df`，与 Dev 的 `f084d10` 已分叉。 -这正是「只有真实组合门禁才能发现」的那一类不兼容——`make test` 全绿（exit 0）也照样漏掉。属跨仓组合问题，需要决定修法（Dev 侧注入 go.sum 条目 / 对齐两侧 backend pin / 调整 RDM 物化步骤），不宜在本 PR 内猜测实现，故如实标 blocked。 +这正是「只有真实组合门禁才能发现」的那一类不兼容——`make test` 全绿（exit 0）也照样漏掉。 + +### 根因（已定位，非制品缺陷） + +同一份 RDM 在本地跑 `scripts/build-product.sh` **成功**（产物 `9ea3fcc8cef0df8a`），说明 RDM 制品无缺陷。报错只出现在 CI，原因是 **RDM 的 pins 布局从 4 个变成 6 个**（新增 `pins/agent-document-renderer`、`pins/agent-system-kb-regulations`）： + +| 提交 | pins 数量 | +|---|---| +| `legacy_sha` 72bb1fec | 4 | +| 旧 `prev_sha` 3484ec2 | 4 | +| 旧 `sha` c6304224 | 4 | +| 新 `sha` bc8db88 | **6** | +| bc8db88 的第一父 59b3624 | 6 | + +CI 步骤逐个检出并构建三个 pin，依赖三者布局一致。新 `sha` 是 6-pin，而 `prev_sha`/`legacy_sha` 仍是 4-pin，布局不再一致；本次 fail-loud 断言直接点名：`rdm pin c6304224 的 pins/agent-system-frontend 未落地：缺少 go.mod`。 + +我先前把 `prev_sha` 设成旧 `sha`（c6304224）是错的——它是 4-pin 布局，且我在单元包与注释里都未核对布局一致性，这是本次返工的直接原因。 + +### 未决（需决策） + +- `prev_sha` 应取 bc8db88 的第一父 `59b3624`（6-pin、与新 sha 布局一致、紧邻交付）；但这样 `prev_sha` 与 `sha` 仅隔一个合并，生命周期套件的「来回部署身份稳定性」覆盖力度下降。 +- `legacy_sha` 必须保持「无身份」语义，因而必然是老提交（4-pin）。构建循环是否应继续要求三个 pin 都可构建？若否，则该步骤对 `legacy_sha` 应放宽断言或单独处理——这属于 CI 步骤语义的设计取舍，不宜由实现侧默定。 + ### 其余验证