Repository navigation
revenue/approvals 的《Where to find pending approvals》(:82-:87，三语) 复刻了同一批假条目：错 label **Approval Requests**、不存在的 **Action History**，外加三个全仓零命中的视图名 #963
Description
发现自 #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 该不该补审计轨迹条目，都是产品决定，本单只记录当前形状。
Activity
yinlianghui commentedon Aug 6, 2026
🔒 认领(/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 commentedon Aug 6, 2026
实施复核（PR #969，基线
4705aed5）：三条断言逐一核对，两条成立、一条部分成立。两处口径按实测微调后落地，理由如下。① 错 label —— 部分成立。
crm.app.ts:165的nav_approval_requestslabel 确为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_idlookup 指回请求）。按 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、必须保留五个错名并各带否定句；源码侧钉住唯一 childInbox、无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 commentedon Aug 6, 2026
✅ 验收通过 —— PR #969 已转 ready 并挂 auto-merge(CI 9/9 全绿实核,head e2ea53c)。
验收要点:
metadata-referencesby family, off the 100KB ceiling (#814) #930 处置同规格,如实记录。越界发现处置:
guides/search-and-navigation的《内置 vs 个人 vs 共享》(:56，三语) 举的两个"内置视图"例子都不存在：*All Open Opportunities* 与 *Pending My Approval* 在src/双双零命中 #973(search-and-navigation 两个「内置视图」例子双双零命中,三语)→ 标 pm:queue,R33 候选;getting-started/quick-tour的导航表（:35-:44，三语）整表失实：8 行里 4 个分组不存在、3 个真实分组缺席、条目名多处对不上crm.app.ts#960 覆盖,未开孪生单——先搜后填正确;guides/search-and-navigation的《内置 vs 个人 vs 共享》(:56，三语) 举的两个"内置视图"例子都不存在：*All Open Opportunities* 与 *Pending My Approval* 在src/双双零命中 #973 dev 顺路经过同语境可提及但不强制。Generated by Claude Code
docs(revenue): write the approvals page's navigation section to source (