analytics/cubes 整页建立在「四个内置 cube」之上，而 src/datasets/ 是九个 dataset：四个名字一个都不存在，Marketing Cube 连数据源都没有 #965

来源：#936 并单实施（PR #954）过程中的卫星命中。#936 只主张本页 Service Cube 的两条首次响应措施（PR #954 已收口，并顺带改掉与之矛盾的示例问题），正文明确把本页其余条目排除在外。本单是剩下的部分。

基线 = PR #954 合并后的 content/docs/analytics/cubes*.mdx（三语同址，行号届时重定位）。

事实：四个 cube 名字，零个存在

本页的骨架是「The four built-in cubes」表加四个小节：💰 Sales Cube / 📊 Pipeline Cube / 🎧 Service Cube / 📣 Marketing Cube，每节列一串 measures 与 dimensions。

src/datasets/ 里是 九个 dataset（ADR-0021 语义层），名字与切分方式都不是这四个：

account_metrics / case_metrics / contact_metrics / event_metrics / forecast_metrics / lead_metrics / opportunity_metrics / product_metrics / task_metrics

逐条对照的结果：

• Marketing Cube 没有任何数据源。九个 dataset 里没有 campaign/campaign_member dataset，所以它列的 7 个 measure（Members enrolled、Sourced revenue、Campaign spend、Cost per lead、ROI %…）与 5 个 dimension 在语义层里一个都不可达，也无法自建。
• Sales Cube / Pipeline Cube 大体都落在 opportunity_metrics 一个 dataset 上，但页面列的 measure 有相当一部分不在其中（Win rate、Sales cycle days、Average discount %、Weighted pipeline、Days in stage、Days in pipeline、Snapshot date 维度…）。需要逐条对源核。
• Service Cube 的其余条目同样与 case_metrics 对不上：dataset 只有五个维度（Status / Priority / Origin / Type / Created，按天分桶）与三个 measure（case count / avg resolution / SLA violation rate），所以 Agent（and team）、Account（and tier）、Product、Period、CSAT score、Open/New/Resolved case count 都没有落点。其中「无 owner 维」这条事实已被 service/index 的《Standard dashboards & reports》四行全部失实：仪表盘描述里的 top agents / oldest open cases 不存在，三张报表名与 case.report.ts 的 label 都对不上 #948 的守卫（PR docs(service): write the index page's dashboards & reports section to source (#948) #955 的 test/docs-service-index-analytics.test.ts）与 PR docs(analytics,administration): write the first-response claims, the Lead reports section and two behavioural claims to source (#936, #951, #952) #954 在 reports 页分别写死。

与平台侧主张的边界（本单不预判）

本页后半段的若干说法是平台能力而不是本 app 的元数据，本单不主张它们为假，只标记需要按实测判定，建议 triage 时决定归属：

• 「cube UI：拖维度到行列 / 保存为报表 / 钉到仪表盘」这一整套交互；
• 「增量刷新每几分钟、每晚全量刷新、快照」以及「刷新状态在管理控制台可见」；
• 「AI Copilot 直接读 cube」「Admins 可审计 cube access log」；
• 「Custom cubes：管理员和开发者可新建 cube」（本仓的等价物是新增 src/datasets/*.dataset.ts，是源码改动 + 重新部署，与页面暗示的自助口径不同 —— 这一条与 docs(service): write the cases and state-machine pages' remaining claims to source (#912, #920, #925, #926) #939 / administration 两页两条枚举外行为性主张:setup:96 指向不存在的「设置 → 商机 → 阶段」配置面;state-machines:140 的「性能要好得多」无据 #952 处理过的「不存在的 Setup 屏」同型）。

为什么要紧

分析师按本页去挑 cube、按 measure 名去建报表，四个名字一个都搜不到；营销侧尤其严重 —— 整节描述的分析能力在这个 app 里没有任何数据基础。这与 #951 / #962 是同一族：读者把不存在的能力当成已有的。

修复面（未做）

三语同步，以 src/datasets/*.ts 为唯一事实来源重写「四个内置 cube」的骨架与各节 measure/dimension 清单，沿 #939 / #951 / PR #954 的口径：真实的九个 dataset 各自能答什么写清楚；不存在的逐条点名，区分「不可达但可加维度实现」与「连数据源都没有」（Marketing）。平台侧那几条按 triage 判定的归属处理，不虚构机制。

边界

• 与 「首次响应 SLA」被三处文档写成可度量的目标：setup 清单 §11 的 SLA 矩阵整列、analytics/reports 的 SLA Performance 行、analytics/cubes 的 Service Cube 措施 —— 全仓没有任何首次响应目标、达标度量或超时信号 #936（PR docs(analytics,administration): write the first-response claims, the Lead reports section and two behavioural claims to source (#936, #951, #952) #954）行集互斥：那单只收口 Service Cube 的两条首次响应 measure 与一条同名示例问题。
• 与 analytics/reports 剩下的 Sales / Revenue / Marketing 三节共 13 个报表名 src/ 里一个都没有，而真实发布的 6 份报表在整页上一次都没出现 #962（analytics/reports 剩余三节）同族不同页，可分派也可并单。
• 本单只要求把页面写到 src/，不预判是否应该新增 campaign dataset 或任何 measure（产品决策）。

Refs #936 #951 #962 #948