Yujie，pql-modeling 那边我做了一次全面 review，有几件事需要你这边处理。都已经写进 GitHub 了，链接在下面，这里给你一个 5 分钟的概览。

**一、先处理这个：#15 现在的样子会误导人（PR #15）**

#15 的正文是对的——它已经被改成"只说业务需求，不规定实现"，明确写了不要照抄 `yybaroq/plg-notification` 的实现。但 `emea/README.md` 里那一行索引没跟着改，还写着 "Ports APAC's Bitable SDR-tracking pattern"。工程师扫一眼索引就会去照抄 Bitable，正好是这个 PR 想拦住的事。改一行就好。

另外 #15 和 #16 都引用了 `apac/execution/apac-scoring-model-divergence-note.md`，那个文件只在 **#17** 里，还没合。现在合 #15 会往 main 里放两个断链，而且"为什么不要抄 plg-notification"这个论据读者点不开。**建议顺序：先合 #17，再合 #15/#16，或者三个一起合。** 这三个 PR 从 7-24 挂到现在，四周没动。

**二、#14 §2 请不要照原文做（Issue #14）**

#14 §2 写的是"把 EMEA 的 Clinic API 1h `rate()` 移植到 APAC，不要重造"。采集部分照做没问题——APAC `tenant_avg_qps` 现在覆盖率是 0，不采就什么都动不了。**但那个 1 小时点采样不能直接当打分输入。**

我们自己 7-30 的数据源审计里已经记到实例了：有个租户五天内 QPS 491→1.7→0.8→1.1→462，评分 82→67→57→67→82，tier 在 P0/P1 之间来回翻，原因是它的批处理任务时好时坏地撞上采样窗口。而 `apac-pql-v1.sql` 里的判据正好是 `tenant_avg_qps >= 1 → +25`，阈值就卡在 1 上。所以：**采集用 Clinic API，打分改用 24h 均值或分位数。** 另外 IT 那边还在确认这个指标是否包含非用户流量。

还有一条硬约束：APAC 和 EMEA 的区域 1 小时快照**不能相加当全局激活率**。全局口径必须走 tenant-day rollup（就是下面第三条那个），这两件事口径不同、不能互相替代。

**三、新开了 #18，跟踪全局 QPS rollup**

`universal/REQUEST_tenant_daily_qps_view.md` 这份数据需求之前只是仓库里一个文件，没有任何 issue 跟着，容易被漏掉，现在开了 **#18**。要的是一张 `tenant_daily_qps` 表，每租户每天一行，24 小时均值。**如果现有系统里已经有这个粒度和保留期的表，指给我们就行，不用新建 pipeline。** 两个关键点：保留期至少 120 天（因为要等 cohort 成熟后回看），以及必须带 `source_status` 区分"测了是 0"和"没测到"——这两个混成 0 会让所有下游指标虚假下跌。

**四、#14 §3 的 first DDL 不是取数任务**

§3 现在指向 O11Y 的飞书 wiki，看起来像个取数活。实际不是：它需要真实客户执行日志，系统性访问要 IT + R&D + 法务三方协调，或者走 OpenClaw 的窄路径。`metadb_new.sql_editor_message` 那个 proxy 已经评估过并否掉了——它只覆盖 SQL Editor UI，看不到 driver / ORM / CDC / CLI，漏掉的恰好是我们最想识别的生产级用户。这是政策问题，别当数据任务派下去。另外 §3 里"把 `first_ddl_at` 加进 data-contract"这半件事**已经做完了**，别重做。

**五、仓库权限，这条想请你帮我判断（Issue #19）**

我查了一下：pql-modeling 是 private 没错，但有 **195 个人有读权限**（11 admin + 184 read），基本上是整个 TiDB 工程团队。对建模文档来说没问题，但仓库里还混着几样不该给这个受众看的东西：

- `EMEA-Daily-Intelligence-Brief.md` 里有两个真实客户的公司名、个人工作邮箱、国家、用量（其中一个 QPS 370）和对应的销售动作；outreach tracker 里还有第三个客户邮箱。文档需要示例，但不需要真实的——仓库其他地方已经在用 `founder@acme-data.example` 这种占位符了。
- EMEA Q1 GM→CEO brief（4 个文件），里面是全公司六大区的 Q1 转化数据、各区 signup 量、payment-ready 率。建模用不到这些。
- `emea target account/` 两个 xlsx：574 个 EMEA AI 账号（含背后的 VC 名单）+ UK/NL/SE 目标账号（估值、营收、TiDB fit 打分）。这是销售目标清单。

没有任何凭证泄露——所有 secret 都是占位符或环境变量，`.gitignore` 该挡的都挡了。纯粹是受众范围的问题。

我的建议：真实客户联系方式换成占位符（一个 commit 的事，随时可做）；然后定一个原则——这个仓库只放模型，还是模型+区域业务分析？定了之后上面几个文件的去留就自动清楚了。**或者更省事的办法：直接把 184 个 read 收窄。** 这比搬六个文件小得多，而且能一次解决大部分问题。

顺带一提，#17 要合的话也涉及这条——它会把 APAC 生产打分模型的完整快照放进这个仓库，我在 PR 里留了备注，这个你判断。

注意：从 main 删文件不等于从 git 历史里删掉。如果哪一项被判定是真的需要清除而不只是整理，那是另一个话题。

**链接**
- Issue #14 评论：https://github.com/pingcap-inc/pql-modeling/issues/14#issuecomment-5340406103
- Issue #18（新，全局 QPS rollup）：https://github.com/pingcap-inc/pql-modeling/issues/18
- Issue #19（新，仓库权限与内容）：https://github.com/pingcap-inc/pql-modeling/issues/19
- PR #15 评论：https://github.com/pingcap-inc/pql-modeling/pull/15#issuecomment-5340419683
- PR #16 / #17 评论：均已留言说明依赖关系

需要我把哪一条展开讲，或者直接把改动提上去，跟我说。