console: System Hub 的 Organizations / Permissions 卡片计数永远显示 0 —— 查的是框架里不存在的对象 `sys_org` / `sys_permission`

[yinlianghui]

越界发现,记录于 #3655(补齐 System Hub 五个入口的路由)期间,为确定重定向目标而逐个核对框架真实对象名时。按纪律只报不改,单独立单,未认领,留给 PM 分诊。

基线:origin/main @ dae1ac41e;框架侧 ../objectstack 同期 checkout。

事实

apps/console/src/pages/system/SystemHubPage.tsx:76-82 为五张卡片各拉一次全量列表当计数:

dataSource.find('sys_user').catch(() => ({ data: [] })),
dataSource.find('sys_org').catch(() => ({ data: [] })),
dataSource.find('sys_position').catch(() => ({ data: [] })),
dataSource.find('sys_permission').catch(() => ({ data: [] })),
dataSource.find('sys_audit_log').catch(() => ({ data: [] })),

其中 sys_org 与 sys_permission 在框架里不存在:

• 组织对象叫 sys_organization(packages/platform-objects/src/identity/sys-organization.object.ts:14,Setup 导航 nav_organizations / nav_organization 也用这个名字)。全仓 grep 'sys_org' 作为对象名:零命中。
• 权限侧框架拆成两个对象:sys_capability(packages/plugins/plugin-security/src/objects/sys-capability.object.ts:27)与 sys_permission_set(同目录 :16)。前者的 docblock 明写「Named sys_capability (not sys_permission as the ADR loosely floats)」。全仓 grep 'sys_permission'(精确、不含 _set):零命中。

每个 find 都挂了 .catch(() => ({ data: [] })),所以 404 被静默吞掉,counts.orgs / counts.permissions 落成 0。屏幕上的结果不是错误提示,而是两个看上去正常的 0 —— 与「确实一条都没有」无法区分。

sys_user / sys_position / sys_audit_log 三个名字是对的,所以同一张卡片墙上三个数真、两个假。

影响面

System Hub(/apps/setup/system)是 SystemHubPage.tsx:132 注释所称「System admin cards (non-metadata, always present)」的那一屏,有应用时也照常可达。管理员看到 Organizations = 0 会合理推断「还没建组织」,而单组织部署里 sys_organization 至少有一行。

与在途工作的关系

• console: 系统导航 / System Hub 的 users / organizations / roles / positions / permissions 五个入口没有对应路由 —— 两个落 "Page not found",三个跳进不存在对象 system 的记录页 #3655 / 其 PR 不动这里 —— 那单的文件面是路由声明,且 SystemHubPage.tsx 当时挂着 ⛔(导航仍有 4 处生产端在生成已废弃的 component/metadata 别名(SystemHub 两张卡片 + 两个 sidebar),各多绕一跳 #3660 在途)。console: 系统导航 / System Hub 的 users / organizations / roles / positions / permissions 五个入口没有对应路由 —— 两个落 "Page not found",三个跳进不存在对象 system 的记录页 #3655 只是在核对重定向目标时把这两个名字查实了。
• 与 导航仍有 4 处生产端在生成已废弃的 component/metadata 别名(SystemHub 两张卡片 + 两个 sidebar),各多绕一跳 #3660 同文件但不同范围 —— 导航仍有 4 处生产端在生成已废弃的 component/metadata 别名(SystemHub 两张卡片 + 两个 sidebar),各多绕一跳 #3660 改的是 :118 / :126 两张卡片的 href(废弃的 component/metadata 别名),本单是 :76-82 的数据查询。不构成子任务关系,故独立立单;真要一起做的话两者会在同一文件相邻区域相遇,合并时注意。
• 与 console: 系统导航 / System Hub 的 users / organizations / roles / positions / permissions 五个入口没有对应路由 —— 两个落 "Page not found",三个跳进不存在对象 system 的记录页 #3655 里悬而未决的「system/permissions 到底等价于 sys_capability 还是 sys_permission_set」是同一个歧义的两个面:定了那个,这里的计数对象也就定了。

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

1. 直接改名:sys_org -> sys_organization;sys_permission -> 由上面那个歧义的裁决决定。
2. 顺带质疑这套计数本身:每张卡片拉一次全量列表只为取 data.length,代码里已有 // TODO: Replace with count-specific API endpoint when available。
3. 更彻底的一条:SystemHubPage 自己的 docblock 标了 @deprecated(「superseded by the metadata-driven left-side menu … New admin surfaces must be added as nav items, NOT as bespoke cards/pages here」)。如果这一屏本就该退场,修计数只是延寿。

属于「先定权限语义、再定这一屏去留」的取舍,需要维护者定方向。

已就关键词(sys_org、sys_permission、SystemHubPage、fetchCounts、counts)搜过本仓开放 issue 与 PR,无同源单。

---

Generated by Claude Code

[yinlianghui]

认领(PM 派发,拆半交付)。

• Session: session_01GTRjn8xBqp75dk7kFupVRt
• 分支:claude/issue-3670-hub-card-counts
• 文件面:apps/console/src/pages/system/SystemHubPage.tsx(计数查询)+ 测试 + changeset。前置已落:PR fix(nav): 导航侧最后 4 处生产端直发规范 metadata 路由,不再绕已废弃的 component/metadata 别名 (#3660) #3668(导航仍有 4 处生产端在生成已废弃的 component/metadata 别名(SystemHub 两张卡片 + 两个 sidebar),各多绕一跳 #3660,同文件两卡片 href)已在 main(d2fd044),障碍解除。
• 处置:
  1. Organizations 半即修:计数对象 sys_org → sys_organization(框架真名,fix(console): 把已退场的 system/{users,organizations,roles,positions} 四条 URL 声明为重定向,直达框架系统对象 (#3655) #3673 已考证)。
  2. Permissions 半只钉不修:sys_permission 查询保持原样 + MEASUREMENT 钉住「该卡计数恒 0」现状,注释指向 console: 系统导航 / System Hub 的 users / organizations / roles / positions / permissions 五个入口没有对应路由 —— 两个落 "Page not found",三个跳进不存在对象 system 的记录页 #3655 的 A/B/C 决策(改查询目标会预定维护者未做的选择)。
  3. .catch 吞 404 使「恒 0」与「确实没有」不可分 — 本单只测量记录该行为(修前后写报告),不改错误处理形态(那是另一个类,有发现就立单)。

---

Generated by Claude Code

[yinlianghui]

部分验收 ACCEPT → PR #3680(session_01GTRjn8xBqp75dk7kFupVRt),Fixes-part-of 正确 — permissions 半继续等 #3655 裁决。

已核:CI 18 项 0 失败;五卡对象名全量审计(第三错名 = 无);逆向验证 3 红 3 绿逐条命中,连带红照实预测不假装无关;调用清单审计用例的锚点修正(红在证据 diff 上而非邻居徽章)是证据指向性的正确打磨。

裁决记录:

1. 机制归因订正采纳:「.catch 吞 404」被实测推翻 — 404 在适配器层被有意 resolve 空(missingResources 设计),.catch 唯一覆盖 500/401/403/断网并塌成确定 0,外层 null 降级为死路径。三行行为矩阵完整,这正是「只能改名、加错误处理不会让它变响」的依据。
2. 新单 console: System Hub 计数的 .catch(() => ({ data: [] })) 把 500 / 401 / 403 / 断网都渲染成一个确定的 0（404 根本到不了它） #3679 定级 bug 入队(错误态渲染成确定 0,最易复现:单对象权限拒绝)— ⚠️ 同文件串行等本 PR 落 main;与 console: 系统导航 / System Hub 的 users / organizations / roles / positions / permissions 五个入口没有对应路由 —— 两个落 "Page not found",三个跳进不存在对象 system 的记录页 #3655 决策正交,不互阻。
3. systemObjects.ts 的同名错误归 console: SystemObjectViewPage.tsx + systemObjects.ts 自 2026-04 起全仓零引用,且其内嵌对象定义用的是已废弃/不存在的对象名 #3672 不越界碰,对。

---

Generated by Claude Code