`revenue/approvals` 的《Where to find pending approvals》(:82-:87，三语) 复刻了同一批假条目：错 label **Approval Requests**、不存在的 **Action History**，外加三个全仓零命中的视图名

[yinlianghui]

发现自 #943 / PR #953 的实施过程（把 content/docs/revenue/index*.mdx 的《Where to find things》按 src/apps/crm.app.ts 写实时，grep -rn "Action History" content/ 扫出同一批名字在本页复刻了一遍）。

基线 origin/main = b7791caf（平台 17.0.0-rc.3）。不与 #943 / PR #953 重叠：那单的面严格限于 content/docs/revenue/index*.mdx 的《Where to find things》一节，approvals*.mdx 一个字都没动。

事实

content/docs/revenue/approvals.mdx:82-:87（zh-Hans / zh-Hant 同址 :86-:87）：

## Where to find pending approvals

In the Enterprise CRM app, the **Approvals** group:

- **Approval Requests** — everything pending, with views *Pending My Approval*, *Submitted by Me*, *Recently Approved*.
- **Action History** — the full audit trail across all approvals.

对 src/apps/crm.app.ts:159-:171：

文档断言	源码实况
Approvals 分组含 Approval Requests	label 不对。group_approvals 只有 1 个 child nav_approval_requests，其 label 是 Inbox（:165）；全仓没有任何元数据叫 Approval Requests
该条目带视图 Pending My Approval / Submitted by Me / Recently Approved	三个名字全仓零命中：grep -rn 在 src/ 为 0，在已安装的 @objectstack/plugin-approvals/dist/index.js 里也是 0。nav_approval_requests 本身也没有声明 viewName
Approvals 分组含 Action History	不存在。 该分组无此条目，全仓也无此 label。审计数据本身是真的——plugin-approvals 注册了 sys_approval_action（连同 sys_approval / sys_approval_approver / sys_approval_delegation / sys_approval_request / sys_approval_token）——但本应用没有任何导航条目能打开它

为什么要紧

与 #943 同源同形：revenue/index 与 revenue/approvals 是同一目录下相邻两页，读者从前者跳到后者，两页会给出同一套错名字。PR #953 已经把 index 页写实，本页若不跟上，同一目录内会自相矛盾——一页说"只有 Inbox 一项、Action History 不存在"，隔壁页仍在教人去点 Approval Requests 和 Action History。

三个视图名的性质比 label 错更糟一档：它们不是"名字过时"，而是从未存在过（源码与插件双面零命中），文档却把它们写成可点的过滤视图，读者会以为自己装漏了什么。

边界与口径建议

• 面：content/docs/revenue/approvals{,.zh-Hans,.zh-Hant}.mdx 的《Where to find pending approvals》一节，三语同步；src/ 零改动。
• 口径直接沿用 PR docs(revenue): write the index page's "Where to find things" section to the real navigation (#943) #953 在相邻页刚落地的写法：真实条目 Inbox（简体界面显示为「待我审批」，src/translations/zh-CN.ts:1219）；Action History 保留名字并写清"数据存在于 sys_approval_action、无导航入口"；三个视图名按"全仓不存在"处理，不静默删名。
• 产品判断不预判（SLA policy matrix: per-priority × tier clocks, first-response stamping, escalation that reassigns #595 / Case intake: round-robin assignment + triage view so web-to-case never lands ownerless #596 同族）：审批收件箱该不该带这三个过滤视图、Approvals 该不该补审计轨迹条目，都是产品决定，本单只记录当前形状。

Refs #927 #932 #938 #942 #943 #953

[yinlianghui]

🔒 认领(/pm-dispatch R32)— session session_01VHrPAGEgFDoHjphqYG4BMa,分支 claude/issue-963-approvals-where-to-find。

文件面:content/docs/revenue/approvals{,.zh-Hans,.zh-Hant}.mdx 的《Where to find pending approvals》(基线 :82-:87)——fresh main 重定位。

裁定:①三个双面零命中的视图名(Pending My Approval / Submitted by Me / Recently Approved)与 Action History、错 label 按 PR #953 刚在 revenue/index 落地的同批事实写实(先读 #953 diff 抄平口径,消除相邻两页矛盾);②plugin-approvals 六个 sys_approval_* 对象「数据真、无入口」的实况沿 #953 写法;③#953 落地行零回退;#595/#596 不预判;src/ 零改动;三语同步;zh 内链不带锚。

---

Generated by Claude Code

[yinlianghui]

实施复核（PR #969，基线 4705aed5）：三条断言逐一核对，两条成立、一条部分成立。两处口径按实测微调后落地，理由如下。

① 错 label —— 部分成立。 crm.app.ts:165 的 nav_approval_requests label 确为 Inbox（zh-CN.ts:1219「待我审批」），文档把它写成 Approval Requests 属实错位。但本单正文"全仓没有任何元数据叫 Approval Requests"不成立：那正是已安装 @objectstack/plugin-approvals 给对象起的名字（sys_approval_request 的 pluralLabel = Approval Requests，label = Approval Request）。本单只 grep 了 src/。照原口径写"没有任何东西叫这个名"，页面会新造一个不准确的否定句，所以 PR 改写成"它不是导航条目，而是插件给对象起的名字"。

② Action History —— 成立。 全仓无此 label，也无任何导航条目指向 sys_approval_action；审计数据真实存在（该对象另有 Recent / By Actor / All 三个内置视图，并以 request_id lookup 指回请求）。按 PR #953 写法保留名字 + 写清"数据在、入口无"。

③ 三个视图名 —— 成立，但"按全仓不存在处理"只讲了一半。 三名在 src/ 与插件 dist 双面零命中，确认无误。但 sys_approval_request 自身内置了四个 list view——My Pending / I Submitted / Completed / All（zh-CN「我的待办」「我提交的」「已完成」「全部」）——而 nav_approval_requests 未声明 viewName，所以点 Inbox 恰好落在这四个视图都在的对象列表上。若只写"这三个不存在"，页面会在反方向变错：读者会以为审批收件箱根本没有过滤视图。PR 因此在点名说清三个假名之后改列真实四个，给出真实到达路径——也正是本单要求的"点名说清并给真实到达路径"。

新增 test/docs-revenue-approvals-navigation.test.ts（30 断言）双向钉住：文档侧必须列全插件在两个对象上的每个视图 label、必须保留五个错名并各带否定句；源码侧钉住唯一 child Inbox、无 viewName、分组默认折叠、zh-CN 标签、插件对象复数标签确为 Approval Requests、三个假名零命中、无导航指向 sys_approval_action。#595 / #596 的产品判断未预判，src/ 零改动，本页其余节未动。

顺带记录：guides/search-and-navigation 第三次复用了同一个幽灵视图名（外加同样不存在的 All Open Opportunities），已另开 #973；quick-tour 同批已由 #960 覆盖，未重复开单。

---

Generated by Claude Code

[yinlianghui]

✅ 验收通过 —— PR #969 已转 ready 并挂 auto-merge(CI 9/9 全绿实核,head e2ea53c)。

验收要点:

1. premise partial 的双向证伪是本单精华:①「全仓无 Approval Requests」不成立——那正是 sys_approval_request 的 pluralLabel(issue 只 grep 了 src/),照单写否定句会新造不准确;③三假名成立但对象自带四个真实内置视图(My Pending/I Submitted/Completed/All),只写「不存在」会让读者反向以为收件箱没有过滤视图。两处都按「点名说清它到底是什么」落笔——两个方向的新错都被拦下。
2. 新守卫 30 断言双向钉住,逆向验证 6 红全落文档侧、源码侧与中文页保持绿——回归面清晰。
3. CodeQL 红一轮按转告修复:Dirent 类型替代 statSync 的 check-then-use,不新增分支不改断言,与 refactor(test): split metadata-references by family, off the 100KB ceiling (#814) #930 处置同规格,如实记录。
4. 与 docs(revenue): write the index page's "Where to find things" section to the real navigation (#943) #953 口径对齐并补分组折叠提示;SLA policy matrix: per-priority × tier clocks, first-response stamping, escalation that reassigns #595/Case intake: round-robin assignment + triage view so web-to-case never lands ownerless #596 未预判。

越界发现处置:

• guides/search-and-navigation 的《内置 vs 个人 vs 共享》(:56，三语) 举的两个"内置视图"例子都不存在：*All Open Opportunities* 与 *Pending My Approval* 在 src/ 双双零命中 #973(search-and-navigation 两个「内置视图」例子双双零命中,三语)→ 标 pm:queue,R33 候选;
• quick-tour 命中已由 getting-started/quick-tour 的导航表（:35-:44，三语）整表失实：8 行里 4 个分组不存在、3 个真实分组缺席、条目名多处对不上 crm.app.ts #960 覆盖,未开孪生单——先搜后填正确;
• docs(revenue): write the index page's "Where to find things" section to the real navigation (#943) #953 落地行的「略过头」观察,PM 裁定:维持不动——该句在侧边栏语境下读法成立(讲的是导航条目),相邻页已有更精确版本,收紧属边际收益不付重开成本;记录在案,若 guides/search-and-navigation 的《内置 vs 个人 vs 共享》(:56，三语) 举的两个"内置视图"例子都不存在：*All Open Opportunities* 与 *Pending My Approval* 在 src/ 双双零命中 #973 dev 顺路经过同语境可提及但不强制。

---

Generated by Claude Code