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 | 测试库 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 | Neo 理解大致对,但"3 处都写完整"会带来维护漂移 | 主 + 副:BD 手册主源 + 3 处链接 | 是否接受"主 + 副"方案 | 同意 | | P0-3 | 财务看板沙箱影响,要走查 | 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 | 重大颠覆: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
Todos: 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。

发现 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 完成标注后,主线再开第二轮反馈响应。