console: `SystemObjectViewPage.tsx` + `systemObjects.ts` 自 2026-04 起全仓零引用,且其内嵌对象定义用的是已废弃/不存在的对象名

[yinlianghui]

越界发现,记录于 #3655(补齐 System Hub 五个入口的路由)期间 —— 派发单要求先测量「是否已有页面组件未接线」,测量结果就是本单。按纪律只报不改,单独立单,未认领。

观察类:这两个文件今天没有任何代码路径能到达,用户看不到任何异常,代价只是构建面与阅读成本,以及下一个 agent 会像 #3655 一样把它们误读成「现成的页面,接上就行」。故打 finding、不打 pm:queue。

基线:origin/main @ dae1ac41e。

事实

apps/console/src/pages/system/ 下这两个文件:

• SystemObjectViewPage.tsx —— 导出 SystemObjectViewPage,一个基于 ObjectView 的通用系统管理页壳。
• systemObjects.ts —— 导出 systemObjects,五个硬编码的对象定义(字段、视图、列)。

全仓 grep(--include=*.ts --include=*.tsx,排除 node_modules)对 SystemObjectViewPage 与 systemObjects 的引用只落在这两个文件自己身上;没有第三处。

来历可查:它们是 3667407(把五个系统页从手写表格迁到 ObjectView)引入的共享件,消费者是 UserManagementPage / OrgManagementPage / RoleManagementPage / PermissionManagementPage / AuditLogPage 五个薄壳。cccdf84d7(Slim apps/console for third-party customisation)把五个薄壳连同其路由一起删了,提交信息写得很清楚:

Delete bespoke /system/* wrapper pages (User/Role/Permission/Audit/Org) and the EmptyStateSystemRoutes test — these objects are now contributed by framework plugins (plugin-auth, -security, -audit) into the Setup app navigation and resolved via the generic /apps/setup/{object_name} route.

共享件本身没被一起删,于是留了下来。

为什么不是「接上就能用」

systemObjects.ts 里的对象名与框架现状已经对不上,把它接回路由会渲染出空/报错的 ObjectView:

systemObjects.ts 里的名字	框架现状
sys_user	✅ 存在
sys_org	❌ 不存在 —— 是 sys_organization
sys_position	✅ 存在(由 plugin-security 拥有)
sys_permission	❌ 不存在 —— 框架拆成 sys_capability 与 sys_permission_set;sys_capability 的 docblock 明写「Named sys_capability (not sys_permission as the ADR loosely floats)」
sys_audit_log	✅ 存在(由 plugin-audit 拥有)

即字段清单是 2026-03 的一份本地手抄,框架侧对象早已各自演进(且 ADR-0090 D3 把 sys_role 改名成了 sys_position,这份抄件里连 sys_role 都没有,却也没有跟上其余变更)。#3655 正是据此判定「不存在可接线的现成页面」,改走路由重定向到框架对象。

影响面

零运行时影响 —— 没有任何 import 指向它们。真实代价有两条:

1. 误导性:文件名读起来像「系统对象页的现成实现」,与 SystemHubPage 的 @deprecated 注释(「新的管理面必须做成 nav item,不要在这里加 bespoke cards/pages」)方向相反。console: 系统导航 / System Hub 的 users / organizations / roles / positions / permissions 五个入口没有对应路由 —— 两个落 "Page not found",三个跳进不存在对象 system 的记录页 #3655 的派发单把「已有页面组件未接线 -> 接上」列为首选分支,正是因为静态看去这两个文件像那样。
2. 一份与框架对不上的对象名副本留在仓里,任何人 grep sys_org / sys_permission 都会先撞到它(console: System Hub 的 Organizations / Permissions 卡片计数永远显示 0 —— 查的是框架里不存在的对象 sys_org / sys_permission #3670 记录了同一对错名字在 SystemHubPage 计数里造成的真实缺陷)。

可能的修法方向(留给分诊,不预判)

1. 删掉两个文件(cccdf84 的清扫收尾),同时把 ROADMAP.md P1.12.2 那一节里已不成立的勾选项(/system/users 由 sys_org / sys_role metadata 驱动云云)标注为历史。
2. 保留但明确标注 @deprecated + 指路框架对象,若判断还有第三方 fork 参考价值。

删除属于「这套 bespoke 系统页是否彻底退场」的取舍,需要维护者定方向。

关联

• console: 系统导航 / System Hub 的 users / organizations / roles / positions / permissions 五个入口没有对应路由 —— 两个落 "Page not found",三个跳进不存在对象 system 的记录页 #3655 —— 路由侧补齐;其测量结论直接产出本单。
• console: System Hub 的 Organizations / Permissions 卡片计数永远显示 0 —— 查的是框架里不存在的对象 sys_org / sys_permission #3670 —— 同一对错误对象名(sys_org / sys_permission)在 SystemHubPage 计数里造成的真实缺陷。
• 导航仍有 4 处生产端在生成已废弃的 component/metadata 别名(SystemHub 两张卡片 + 两个 sidebar),各多绕一跳 #3660 —— 同目录 SystemHubPage.tsx 的导航别名,在途;与本单文件不重叠。

已就关键词(SystemObjectViewPage、systemObjects、dead code、sys_org、sys_permission)搜过本仓开放 issue 与 PR,无同源单。

---

Generated by Claude Code

[yinlianghui]

认领(PM 派发),处置裁决:enforce-or-remove → remove(全仓零引用自 2026-04、内嵌对象名与框架脱节且缺 ADR-0090 D3 改名 — 三重死证;留着的唯一效果是把下一个 agent 引向「现成页面接上就行」的错误分支,#3655 差点中招)。

• Session: session_01GTRjn8xBqp75dk7kFupVRt
• 分支:claude/issue-3672-remove-orphan-system-pages
• 文件面:apps/console/src/pages/system/SystemObjectViewPage.tsx + systemObjects.ts 删除 + 孤立 import/导出清理(先全量测量引用面:grep 两文件名与其导出符号,零命中为前提,有命中停手报告)。
• 验证:删除后 apps/console 全量测试 + type-check + build 绿(零引用的机械证明);逆向验证不适用(删除卡),以引用面测量代替。changeset 按 chore(deps): 删除未接线的 prettier devDependency (#3657) #3681 框架判断(app 内部死代码删除,零发布物影响,倾向不加,写明)。
• ⚠️ 与在途 console: System Hub 的 Organizations / Permissions 卡片计数永远显示 0 —— 查的是框架里不存在的对象 sys_org / sys_permission #3670 的 PR fix(console): System Hub 的 Organizations 计数改查框架真名 sys_organization,Permissions 半只钉不修 (#3670) #3680(SystemHubPage.tsx)同目录不同文件,零相交已核;动手前 fetch 最新 main。

---

Generated by Claude Code

[yinlianghui]

验收 ACCEPT → PR #3699(session_01GTRjn8xBqp75dk7kFupVRt)。

已核:227 行纯删除零改动;引用审计带邻居对照(同目录活页面 1-17 命中 vs 本两文件 0 — 「零」的独有性证明);对象名脱节对 ../objectstack 逐名核实;CI 0 失败(shards 排队属 runner 争用,Type Check 同 SHA 已绿)。

裁决记录:

1. 删除卡逆向验证范式记入方法库:「复活断肢看红」对不可达文件结构性不成立 → 改做探测器阳性对照(临时 importer 证明 tsc 解析覆盖该目录,预告方向变红后移除、不进提交)— 全绿由此成为有效证据。这是 没有门禁校验「package.json 的 files 条目在磁盘上真实存在」——npm 静默跳过缺失条目,#3647 因此长期无人察觉 #3663「git 命令失败抛错防空集」同宗的探测器有效性纪律。
2. 历史归因勘误接受:cccdf84d7 不是浅嫁接 main 的祖先,issue 的时间归因不可验证 — 删除依据落在当前树实测(零引用 + 对象名脱节),premise 依然成立且更稳。
3. changeset 不加的构建产物佐证(dist 含活页面文案、不含被删文件独有文案)— 超出先例引用的机械证明,好。
4. 新发现 docs(ROADMAP): P1.12.2「ObjectView-Driven System Pages」整段 9 个勾选项已全部不成立(组件已删、路由改重定向、审计页并非 ObjectView 驱动) #3700 入队即派(ROADMAP P1.12.2 九勾全失实 + Permission Management 段同源漂移)。

---

Generated by Claude Code