Repository navigation
console: SystemObjectViewPage.tsx + systemObjects.ts 自 2026-04 起全仓零引用,且其内嵌对象定义用的是已废弃/不存在的对象名 #3672
Description
越界发现,记录于 #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 指向它们。真实代价有两条:
- 误导性:文件名读起来像「系统对象页的现成实现」,与
SystemHubPage的@deprecated注释(「新的管理面必须做成 nav item,不要在这里加 bespoke cards/pages」)方向相反。console: 系统导航 / System Hub 的 users / organizations / roles / positions / permissions 五个入口没有对应路由 —— 两个落 "Page not found",三个跳进不存在对象system的记录页 #3655 的派发单把「已有页面组件未接线 -> 接上」列为首选分支,正是因为静态看去这两个文件像那样。 - 一份与框架对不上的对象名副本留在仓里,任何人 grep
sys_org/sys_permission都会先撞到它(console: System Hub 的 Organizations / Permissions 卡片计数永远显示 0 —— 查的是框架里不存在的对象sys_org/sys_permission#3670 记录了同一对错名字在SystemHubPage计数里造成的真实缺陷)。
可能的修法方向(留给分诊,不预判)
- 删掉两个文件(cccdf84 的清扫收尾),同时把
ROADMAP.mdP1.12.2 那一节里已不成立的勾选项(/system/users由sys_org/sys_rolemetadata 驱动云云)标注为历史。 - 保留但明确标注
@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
Activity
yinlianghui commentedon Aug 7, 2026
认领(PM 派发),处置裁决:enforce-or-remove → remove(全仓零引用自 2026-04、内嵌对象名与框架脱节且缺 ADR-0090 D3 改名 — 三重死证;留着的唯一效果是把下一个 agent 引向「现成页面接上就行」的错误分支,#3655 差点中招)。
session_01GTRjn8xBqp75dk7kFupVRtclaude/issue-3672-remove-orphan-system-pagesapps/console/src/pages/system/SystemObjectViewPage.tsx+systemObjects.ts删除 + 孤立 import/导出清理(先全量测量引用面:grep 两文件名与其导出符号,零命中为前提,有命中停手报告)。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 commentedon Aug 7, 2026
验收 ACCEPT → PR #3699(session_01GTRjn8xBqp75dk7kFupVRt)。
已核:227 行纯删除零改动;引用审计带邻居对照(同目录活页面 1-17 命中 vs 本两文件 0 — 「零」的独有性证明);对象名脱节对 ../objectstack 逐名核实;CI 0 失败(shards 排队属 runner 争用,Type Check 同 SHA 已绿)。
裁决记录:
Generated by Claude Code
chore(console): remove the orphaned SystemObjectViewPage + systemObje…