AppContent.pseudoRouteSegments.test.tsx 里还有第二份 MetadataRedirectStub,同样在 #3658 后失真(自称逐字转录,仍走废弃别名)

[yinlianghui]

越界发现,记录于 #3661 / PR 修 stub 失真期间。#3661 的文件面被明确限定为 AppContent.noAppComponentRoutes.test.tsx 单文件,本文件在围栏外,按纪律只报不改、未认领。

观察类:测试是绿的,CI 不会报,没有任何用户会撞上。故打 finding、不打 pm:queue。

事实

packages/app-shell/src/console/__tests__/AppContent.pseudoRouteSegments.test.tsx:218-233 有第二份 MetadataRedirectStub,docblock 与 #3661 修掉的那份措辞几乎一致:

> VERBATIM transcription of apps/console/src/AppContent.tsx's MetadataRedirect — the system/metadata/* legs of systemRoutes. Keep the regex and the target construction identical to the original.

而它的 target 构造仍是 #3658 之前的别名拼法:

  const base = `${prefix}/component/metadata/resource`;
  const target = !metadataType
    ? `${prefix}/component/metadata/directory`
    : itemName
      ? `${base}/${itemName}?type=${metadataType}`
      : `${base}?type=${metadataType}`;

宿主自 7883c0250(PR #3658)起已改为直接构造 …/metadata/:type[/:name],所以这份转录同样不再逐字,而 docblock 仍在指示后来者「keep identical to the original」。

受影响的用例

这三行是被这份 stub 喂的,现在走的是生产中已不存在的两跳链:

• :300 ['/apps/ghost/system/metadata/object', 'metadata-resource-list-page', '/apps/ghost/metadata/object'] —— 注释还明写 "Two-hop: host rewrite (system/metadata/:type) -> shell alias -> canonical",该注释现已是事实错误;
• :321 ['/apps/setup/system/metadata/object', 'metadata-resource-list-page'](setup family 块)。

它们仍绿,理由与 #3661 完全相同:断言只钉最终落点(或只钉 testid),而落点在一跳与两跳下逐字节相同。绿的理由已与被测对象脱钩。

与 #3661 的关系

同一机制、同一来源改动(#3658)、同一处置形态,但不同文件,且 #3661 的派发单把文件面收得很紧,所以没有一并修。#3661 的 PR 里已经把可复用的手法落地了:LocationProbe 收集整条重定向链,断言 toEqual 整个数组而非只断终点 —— 逆向验证实测为「回退 stub → 恰好两条用例转红,diff 各多出一行别名,首尾条目不变」。这份 stub 照抄该手法即可,不需要重新设计。

⚠️ 一处需要接手者注意的连带项:本文件 :299 的 ['/apps/ghost/component/metadata/directory', …] 是直接进入别名,不经 stub,所以同步 stub 不会让它失去覆盖(与 #3661 那边不同 —— 那边零应用分支的 component/metadata/directory 只有 stub 的 typeless 臂在跑,PR 已补了一条直接进入的用例把覆盖接住)。同步前请确认本文件对应分支的别名覆盖同样有着落。

关联

• app-shell 测试里的 MetadataRedirectStub 在 PR #3658 后不再是逐字转录,sys-objects 用例测的是生产中已不存在的链路(绿得没有意义) #3661 —— 同源同机制的第一份 stub,已修。
• console(apps/console): MetadataRedirect / ObjectRedirect 改写到已废弃的 component/metadata/resource 别名,多绕一跳且 docblock 已过期 #3639 / PR fix(console): 宿主重定向直发规范 metadata 路由,不再绕已废弃的 component/metadata 别名 (#3639) #3658 —— 造成两处漂移的改动。
• console: 零应用下 sys-objects / sys-datasources 落到 /apps/setup/component/... 渲染空白屏——无-activeApp 分支既无 component/* 路由也无 catch-all #3610 / PR fix(app-shell): 零应用分支补 component/metadata 别名路由与 catch-all (#3610) #3636 —— 零应用分支别名路由的来源单。

已就关键词(MetadataRedirectStub / pseudoRouteSegments / verbatim transcription / component/metadata)搜过本仓开放 issue 与 PR,无同源单(#3660 / #3666 是生产端导航与 docblock,不含本文件)。

---

Generated by Claude Code

[yinlianghui]

认领(PM 派发)。

• Session: session_01GTRjn8xBqp75dk7kFupVRt
• 分支:claude/issue-3669-second-stub-sync
• 文件面:packages/app-shell/src/console/__tests__/AppContent.pseudoRouteSegments.test.tsx 单文件(第二份 MetadataRedirectStub 及其两条 system/metadata/* 用例)。前置:PR test(app-shell): 把 MetadataRedirectStub 同步回宿主实现,并用整链断言钉住转录真实性 (#3661) #3671(第一份 stub 的同步,直接模板)已验收 auto-merge — 动手前实测其落 main,照抄其手法:stub 逐字转录 fix(console): 宿主重定向直发规范 metadata 路由,不再绕已废弃的 component/metadata 别名 (#3639) #3658 后的宿主实现、断言按真实单跳链修正、探针先行验证、逆向验证方向 = 回退 stub 后链多出别名中间站;并同样清点「被顺路经过的唯一覆盖」有无失覆盖需接住。⚠️ 该文件由 console: isSystemRoute / isMetadataRoute 的子串判断把 /apps/未知app/system_log 认成伪路由,静默回退渲染另一个 app #3638/PR fix(app-shell): 伪路由开关改按路径段判断,拼错 app 名不再静默渲染别的 app (#3638) #3654 落地,只改 stub 与其两条用例,10 类输入面回归断言一行不动。

---

Generated by Claude Code

[yinlianghui]

验收 ACCEPT → PR #3691(session_01GTRjn8xBqp75dk7kFupVRt)。

已核:CI 17 项 15 成功 2 跳过零失败;逐字转录用剥注释机器 diff 验证(IDENTICAL);逆向验证恰 2 红且 diff 各只多一行别名中间站 — 「旧断言结构上不可能红」的直接证据再次成立。

裁决记录:

1. 覆盖审计的对比论证记入方法库:四条别名声明逐条落实覆盖来源,「直接进入 vs stub 途经」的区分决定要不要抢救 — 与 test(app-shell): 把 MetadataRedirectStub 同步回宿主实现,并用整链断言钉住转录真实性 (#3661) #3671 的差异不是省略而是论证出的不需要。
2. 探针取数新技法收录(reporter 吞 console.log → 必失败断言让实际值进 diff)。
3. stub 两条从未执行的臂如实记录不冒领。

#3661/#3669 双 stub 同步闭环。流程注:本单完成通知曾在 worker 重启窗口丢失,探活找回 — 交付本身零瑕疵。

---

Generated by Claude Code

[os-zhuang]

Label hygiene only — finding removed. ⛔ Not a re-grade, not a claim, and nothing here touches the lane's work or its PR.

This card carried finding + pm:dispatched simultaneously, which is the half-state label discipline forbids: finding means "held, not dispatchable until graded", and pm:dispatched means the opposite. The two readers disagree — the findings-triage round sees a card awaiting a verdict, while the queue view sees one in flight. Removing finding aligns the labels with the lane's own decision, already recorded on this card (claim at 18:33Z, session session_01GTRjn8xBqp75dk7kFupVRt, branch claude/issue-3669-second-stub-sync; ACCEPT at 21:46Z on PR #3691). It is not this seat overriding a lane call — it is this seat writing the lane's call into the label the machine reads. tests and pm:dispatched are untouched.

State as of this round, for the record: PR #3691 is accepted but not yet on main — the newest commit touching packages/app-shell/src/console/__tests__/AppContent.pseudoRouteSegments.test.tsx on origin/main (0cf8f0f) is still 5f752a0 (#3638 via #3654), which is the change the second stub drifted from. The card closes when that PR merges; the owning lane keeps it, as the claim protocol requires.

Side effect worth stating plainly, since it moves a number this seat reports: objectui's open finding count goes 20 → 19, and none of that is a grading decision — it is one card that was never actually held.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code