Neo-ZQYY/docs/_overview/04a-feedback/00-P0-feedback-response-summary.md

# P0 反馈响应总报告

> 日期:2026-05-04 / 触发:Neo 在 04a-conflicts 八条 P0 卡片上写下斜体反馈
> 主线 + 3 个子代理(D-1/2/3)调研整合产出 / 状态:**调研完成,等 Neo 拍板进入实施**

本报告聚合 8 条 P0 反馈的处理状态。每条索引指向详细产出文件。

## 一、8 条 P0 反馈处理状态总览

| # | 反馈类型 | 调研产出 | 主要发现 | 推荐方案 | 等待 Neo 决策 | *反馈* |
|---|---|---|---|---|---|
| **P0-1** | 让深入调研 | [P0-1-SPI-research.md](P0-1-SPI-research.md) | **测试库 27 = 代码 27 = BD 27 = SPEC §T3 27**,4 方一致;**只有 3 处文档写错数字** | 改 3 处文档(5 分钟) | "更新所有每日 SPI 参数"措辞需澄清(参数表无每日维度) | *因为沙箱机制的存在，配合此机制SPI参数和全部的参数，应该每天都有快照吧？如果你觉得合理，可以深入调研关联性和影响，并适当修改P20-runtime-context-sandbox.md。当然你可能会告诉我更优雅的解决方案，这个我开放讨论* |
| **P0-2** | 问理解 + 求建议 | [P0-2-feedback-resolution.md](P0-2-feedback-resolution.md) | Neo 理解大致对,但"3 处都写完整"会带来维护漂移 | **主 + 副**:BD 手册主源 + 3 处链接 | 是否接受"主 + 副"方案 | *同意* |
| **P0-3** | 财务看板沙箱影响,要走查 | [P0-3-board-vs-sandbox-analysis.md](P0-3-board-vs-sandbox-analysis.md) | **Grep 实证:三大看板 + xcx_board.py 完全没接入 runtime-clock,沙箱模式下看板仍显真实时间** | Wave 1 必修(5-7h)+ 8 条沙箱测试场景 | 选 A(Wave 1 修)还是 B(仅验证) | *同意你的实施计划，记录为待完成任务，但需要等Wave 0完成后执行，我记得Wave 1需要根据Wave 0进行更新的。* |
| **P0-4** | 已选 A 改文档 | (即将处理) | Neo 确认"PRD 落后于实施" | A 改文档,纳入 Wave 5 收口 | 已确认,无待决 |  |
| **P0-5** | 偏向 B,但要查"为什么改" | [P0-5-matching-evolution.md](P0-5-matching-evolution.md) | **重大颠覆**:FDW 已建但不能用(GUC 不透传 → RLS 失效);直连不是 over-engineering 而是真实 Bug 修复 | **绝不能选 B-1 回退 FDW**;推荐 C 维持现状 + 文档说明,坚持工程一致性可选 B-2(SECURITY DEFINER 包装,4-8h + 跨库回归) | Neo 是否调整 B → C(基于新事实) | 
*我还是倾向于坚持工程一致性，再深入一些，找到本项目当前类似情况，给个全览，并制定工程规范化和一致性的实施放方案。* |
| **P0-6** | 偏向 C,提"沙箱内 / 全局"语义 | (整合到 P0-7 SPEC 中) | clearAllTasks 在沙箱上线后需要拆"全局清空" / "沙箱内清空" | 推迟到沙箱收口后重设计交互 | 是否同意推迟到 P0-7 收口后 | *我同意，但要记录下来。* |
| **P0-7** | 让补 SPEC + 深入测试 | SPEC: [P20-runtime-context-sandbox.md](../../prd/specs/P20-runtime-context-sandbox.md)<br>Todos: [P0-7-runtime-context-todos.md](P0-7-runtime-context-todos.md) | SPEC 草稿 14 节 / 5 API 端点;**20 条收口待办**(P0×5 / P1×8 / P2×7),包括看板未接入(P0-3 是其中之一) | SPEC 直接归 docs/prd/specs/ 投入使用;todos 进入 Wave 1-5 滚动消化 | SPEC 文件名 / 编号是否接受 | *很好，我大概看了P20-runtime-context-sandbox.md。有几个问题我一直非常关心的问题，是否已经着重强调，你来帮我确认，若已落地则忽略：代码层面的 lint/typecheck 是否过，架构是否合理固然重要，是项目标准化执行的根基。但对于我而言，最终用户看到的页面/小程序是否真正达到设计目标更为重要，因为**你要对最终成功负责，而客户也最看重最终使用的效果**。那么，视角分两层：1)工程层（必要的根基）：代码结构合理、调用链路通、迁移已落库。2)成果层（我最看重的）：admin-web —— 用 Playwright MCP 打开浏览器实地走一遍（AI Dashboard / Operations / RunLogs / Triggers / RuntimeContext / TriggerManager 等 6 页 + AIPrewarm 分组）；miniprogram —— 用 weixin-devtools-mcp 打开微信开发者工具实地走（财务看板 area 切换、AI 洞察展示、runtime-clock 时间漂移行为、各页面的数据展示是否符合预期 等）3)对于小程序3大板块之一的任务板块，需要切换用户身份，在看板板块收口后，提醒我进行身份修改。* |
| **P0-8** | 已选 D | (即将处理) | DBViewer 黑名单 5 关键词漏 ALTER/CREATE/GRANT | 选项 D:白名单 + 只读账号双保险 | 已确认,纳入 Wave 1-3 修代码 |  |

## 二、关键发现摘要(Neo 必须知道的 5 件事)

### 发现 1:P0-1 不是数据库缺数据,是文档写错数字

**4 个权威源全部一致是 27**:测试库 / 代码 DEFAULT_PARAMS / BD 手册 / P2 SPEC §T3。
**只有 3 处文档写错**:00 数据依赖矩阵 L272 写"26"、P2 SPEC AC6 写"26"(同文件 T3 写 27 自相矛盾)、`scripts/ops/run_seed_spi_params.py` 期望 28。
**Step2 实施成本**:5 分钟改 3 处文字 + 1 份审计。Neo 反馈中"更新所有每日 SPI 参数"措辞需要澄清——cfg_index_parameters 表只有 effective_from 维度,无每日历史维度。


### 发现 2:P0-5 的 FDW 已建但是错的

Neo 原本基于"FDW 没建"的认知偏向选 B 补全 FDW。**事实**:
- `setup_fdw.sql` 用 `IMPORT FOREIGN SCHEMA app FROM ...` **已包含** v_dim_staff / v_dim_staff_ex / v_dim_assistant
- 但 FDW 跨库**不能透传** `current_setting('app.current_site_id')` GUC,远端 RLS 视图过滤失效
- 2026-03-18 21:38 AI 救火改直连,03-20 经用户批准方案 A
- **回退到 FDW = 重新引入 RLS 门店隔离失效 Bug**

**推荐**:从 Neo 原选 B 调整为**选 C(维持直连 + 补文档说明 GUC 限制)**。如确实坚持工程一致性,选 B-2(SECURITY DEFINER 包装,4-8h),不选 B-1。


### 发现 3:P0-3 沙箱看板风险确认

**Grep 实证**:小程序三大看板 + 后端 xcx_board.py **零处引用** runtime-clock / runtime_context。
**意味着**:沙箱模式下其他页(task-list 等)显示虚拟日期,看板页**仍显真实今天数据**,用户体验割裂。
**修复成本**:5-7h。**强烈推荐 Wave 1 必修**。




### 发现 4:P0-7 沙箱远未收口(实证)

D-3 子代理调研发现 **20 条待办**,涉及:
- P0-3 看板未接入(本报告第 3 项)
- BD_Manual 与代码冲突(`paused_by_sandbox` 字段文档说有代码已删)
- 多门店并行 sandbox 未验证(GUC 串扰)
- 清理脚本缺失(sandbox 长用会膨胀 6 张表)
- `tests/` 下无 runtime_context pytest

**收口路径**:9 步,跨 Wave 1-5。SPEC 已起草到 [`P20-runtime-context-sandbox.md`](../../prd/specs/P20-runtime-context-sandbox.md)。



### 发现 5:P0-6 应推迟而不是立即修

Neo 反馈 P0-6 选 C(按 site_id 清 + 二次确认),但同时指出"沙箱上线后清空可能含全局/沙箱内两个语义,需要确认"。
**意味着**:P0-6 的最终交互形态依赖 P0-7 沙箱收口。**推荐推迟到 P0-7 收口后再设计 P0-6 交互**,避免反复改。
当前可以先在 admin-web 加一个"二次确认弹窗 + 输入门店简称"的临时守卫(1h 工作量),作为临时止血。



## 三、按 Wave 分配的执行清单

| Wave | 主题 | P0 反馈分配 |
|---|---|---|
| **Wave 1** | Runtime Context 沙箱 | **P0-3 看板接入(必修)** + P0-7 SPEC 投入使用 + 8 条沙箱场景 + 20 条 todos 消化(P0×5 项) |
| **Wave 1-3** | 代码 D Bug | **P0-8 DBViewer 白名单**(后端) + P0-6 临时守卫(可选,推迟到沙箱收口后正式重设计) |
| **Wave 4** | DWS / RLS / 数据正确性 | 4.1 财务看板 5 项 P2 修复(原 P0-3 主体)+ P0-7 todos 消化(P1×8 项) |
| **Wave 5** | 部署 + 文档收尾 | **P0-1 改 3 处文档**(SPI 26→27)+ **P0-2 BD 手册主权威 + 3 处链接**(confirmed_income 术语)+ **P0-4 改 PRD**(备注评分 2 字段)+ P0-5 文档说明(直连原因 + GUC 限制)+ P0-7 todos 消化(P2×7 项) |
| **跨 Wave** | 上线门槛 | 满足"看板沙箱接入(Wave 1) + 5 项 ETL 数据准确(Wave 4)"才推 P11 |

## 四、给 Neo 的决策提问(本会话剩余可处理的项)

| 问题 | 类型 | 建议 |
|---|---|---|
| P0-1 "每日 SPI 参数" 措辞要澄清 | 措辞 | 改为"刷新 BD 手册描述 + 数据依赖矩阵 + run_seed_spi_params.py 注释",移除"每日"用词 |
| P0-2 "主 + 副"方案是否接受 | 是非 | 是 → Wave 5 落地 / 否 → 仍三处都写 |
| P0-3 看板沙箱接入选 A 还是 B | 路径 | A(Wave 1 修)|
| P0-5 基于新事实是否调整为 C 或 B-2 | 路径 | C(维持现状)|
| P0-6 是否同意推迟到 P0-7 收口后正式重设计 | 路径 | 同意,临时加二次确认守卫 |
| P0-7 SPEC 文件名 / 编号 P20 是否接受 | 命名 | 接受,后续可调 |

回答这 6 个问题后,P0 全部进入实施轨道。

## 五、产出文件索引

```
docs/_overview/04a-feedback/
├── 00-P0-feedback-response-summary.md       (本文)
├── P0-1-SPI-research.md                     (D-1 调研)
├── P0-2-feedback-resolution.md              (主线建议)
├── P0-3-board-vs-sandbox-analysis.md        (主线分析)
├── P0-5-matching-evolution.md               (D-2 调研)
└── P0-7-runtime-context-todos.md            (D-3 todos)

docs/prd/specs/
└── P20-runtime-context-sandbox.md           (D-3 SPEC 草稿)
```

---

> 04b / 04c 反馈处理待 Neo 完成标注后,主线再开第二轮反馈响应。