Repository navigation
console: SystemObjectViewPage.tsx + systemObjects.ts 自 2026-04 起全仓零引用,且其内嵌对象定义用的是已废弃/不存在的对象名 #3672
Description
Activity
认领(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
- Session:
验收 ACCEPT → PR #3699(session_01GTRjn8xBqp75dk7kFupVRt)。
已核:227 行纯删除零改动;引用审计带邻居对照(同目录活页面 1-17 命中 vs 本两文件 0 — 「零」的独有性证明);对象名脱节对 ../objectstack 逐名核实;CI 0 失败(shards 排队属 runner 争用,Type Check 同 SHA 已绿)。
裁决记录:
- 删除卡逆向验证范式记入方法库:「复活断肢看红」对不可达文件结构性不成立 → 改做探测器阳性对照(临时 importer 证明 tsc 解析覆盖该目录,预告方向变红后移除、不进提交)— 全绿由此成为有效证据。这是 没有门禁校验「package.json 的 files 条目在磁盘上真实存在」——npm 静默跳过缺失条目,#3647 因此长期无人察觉 #3663「git 命令失败抛错防空集」同宗的探测器有效性纪律。
- 历史归因勘误接受:cccdf84d7 不是浅嫁接 main 的祖先,issue 的时间归因不可验证 — 删除依据落在当前树实测(零引用 + 对象名脱节),premise 依然成立且更稳。
- changeset 不加的构建产物佐证(dist 含活页面文案、不含被删文件独有文案)— 超出先例引用的机械证明,好。
- 新发现 docs(ROADMAP): P1.12.2「ObjectView-Driven System Pages」整段 9 个勾选项已全部不成立(组件已删、路由改重定向、审计页并非 ObjectView 驱动) #3700 入队即派(ROADMAP P1.12.2 九勾全失实 + Permission Management 段同源漂移)。
Generated by Claude Code
- added a commit that references this issue
on Aug 10, 2026
越界发现,记录于 #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)把五个薄壳连同其路由一起删了,提交信息写得很清楚:共享件本身没被一起删,于是留了下来。
为什么不是「接上就能用」
systemObjects.ts里的对象名与框架现状已经对不上,把它接回路由会渲染出空/报错的 ObjectView:systemObjects.ts里的名字sys_usersys_orgsys_organizationsys_positionsys_permissionsys_capability与sys_permission_set;sys_capability的 docblock 明写「Namedsys_capability(notsys_permissionas the ADR loosely floats)」sys_audit_log即字段清单是 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 的派发单把「已有页面组件未接线 -> 接上」列为首选分支,正是因为静态看去这两个文件像那样。sys_org/sys_permission都会先撞到它(console: System Hub 的 Organizations / Permissions 卡片计数永远显示 0 —— 查的是框架里不存在的对象sys_org/sys_permission#3670 记录了同一对错名字在SystemHubPage计数里造成的真实缺陷)。可能的修法方向(留给分诊,不预判)
ROADMAP.mdP1.12.2 那一节里已不成立的勾选项(/system/users由sys_org/sys_rolemetadata 驱动云云)标注为历史。@deprecated+ 指路框架对象,若判断还有第三方 fork 参考价值。删除属于「这套 bespoke 系统页是否彻底退场」的取舍,需要维护者定方向。
关联
system的记录页 #3655 —— 路由侧补齐;其测量结论直接产出本单。sys_org/sys_permission#3670 —— 同一对错误对象名(sys_org/sys_permission)在SystemHubPage计数里造成的真实缺陷。SystemHubPage.tsx的导航别名,在途;与本单文件不重叠。已就关键词(
SystemObjectViewPage、systemObjects、dead code、sys_org、sys_permission)搜过本仓开放 issue 与 PR,无同源单。Generated by Claude Code