用户特别关心数据库。我独立审了 21 个 commit，0 个新 migration，0 DDL，
新查询列映射全验过；dry-run merge 干净，Performance Engine SSO 完整保住。
只剩一个产品决策要你拍板：/share/* 的访问范围。
按性质归类。注意 src/routes/auth.ts 那个 −210 行**不是删** ——
是 stage 那边 PR #11 加了 PE SSO 中间件，test 这边从未有过，diff 反映静态差。
| 类别 | commits | 主要文件 |
|---|---|---|
| share pages MVP | 3-4 |
src/lib/share-data.ts NEW · +313src/components/share-pages.tsx NEW · +192src/routes/pages.tsx +34
|
| pm-vibe UI hotfix | 10+ |
public/app.js · public/pm-shell.css · src/components/delivery-detail-modal.tsxtab badge / hot card bubble / storyboard 多镜头 / share 间距文案 |
| 回归修 | 1 |
src/routes/v7.ts +7revise-plan 不再自动续 delivery（PR #12 已审过） |
| docs | 4 |
docs/handoff-pm-vibe-creative-gate.mddocs/product-usage-guide-update-2026-05-27.md NEW
|
| 看似删 auth.ts | 0 |
test 从未有 PE SSO middleware，stage 单独加的。 静态 diff 反映为 −210 行，但 test 没真删什么。 |
stage 和 test 的 migrations/ 目录字节级一致 ——
都到 0020_dedupe_pm_vibe_system_assets.sql。新代码只新增 SELECT 查询，
INSERT/UPDATE/DELETE 一行没加。
git diff origin/stage..origin/test -- migrations/ → 空输出。
schema 风险面 = 0。
2 个 SELECT：plan / delivery 各一。LEFT JOIN 5 张已有表（creative_boards, crawl_slots, agent_runs, users, hot_materials）。
14 个列引用全部映射到真实 DDL 定义。详见 §3 那个修复案例。
tsc 看不见 SQL 字符串内容。F97ED27 那个 bug 是 live smoke 才抓到的 —— 不是当前 bug，是后续防御点。
原来的 SELECT 写的是 d.summary，但 deliveries 表没有 summary 列
—— summary 只在 creative_boards 上。部署到 pm-vibe 后第一次访问 /share/delivery/<id> 直接 500。
// commit f97ed27 — fix(pm-vibe): /share/delivery 500 — column d.summary does not exist // before: SELECT d.summary, d.title, d.video_url, ... FROM deliveries d LEFT JOIN creative_boards cb ON cb.id = d.creative_board_id // PostgresError: column d.summary does not exist → 500 // after: SELECT cb.summary AS summary, d.title, d.video_url, ... FROM deliveries d LEFT JOIN creative_boards cb ON cb.id = d.creative_board_id // 改用 cb.summary（创意板的 summary）AS summary，前端 data.delivery.summary 不变
根因：summary 在 0001_init.sql:34 是 creative_boards.summary，
deliveries 表从来没这列。typecheck 无法发现，因为 SQL 字符串是 opaque template literal。
复制本地 repo 到 /tmp/mb-merge-dryrun，切到 stage，
跑 git merge --no-commit origin/test。
git 自动合并成功，零 conflict。我用 grep 又核了一遍 PE SSO 三处引用全部保留。
src/index.tsx:10 仍然 import { ..., performanceEngineSso } from './routes/auth'
src/index.tsx:28 仍然 app.use('*', performanceEngineSso)
src/routes/auth.ts:219 仍然 export const performanceEngineSso = ...
为什么这次安全：merge-base 是 99f886e（没 PE SSO），stage 是 base + PE SSO commits，test 是 base + 其他改动。两边没动同一个文件的同一个区，git 默认的加性合并直接保留双边。
我没信 mb-codex 的 claim，自己重跑了一遍。这是 review discipline 的要求： reviewer 不 paraphrase，自己 grep / 跑测试 / 看 diff。
F97ED27 修的那个 column-on-wrong-table 错配是已发生事实。结构性问题： tsc 不查 SQL，没有 schema-driven contract test。下次再写错列， 还是要部署到 sozai-test / pm-vibe 跑一遍才能发现。
现在审完 share-data.ts 的 SELECT 我手验了一遍 14 个列引用，全对得上。 但下次同样模式的新 SQL 上，这条防线还是空的。建议后续： 加一个 contract test 拿 schema dump 验列名 + alias 对照表。
— 不阻塞这次合并。已知 bug 已修；其他列已逐个 verify。
pages.use('/share', requireSession(...)) 任何登录的 FunPlus 成员
有链接就能查看完整 plan / delivery 数据。
viewerIsCreator 只决定 action 按钮显隐，不挡查看。
| 访问者 | 能查看？ | 能 act（按钮显？） | 当前实现 |
|---|---|---|---|
| 未登录 | 否 | 否 | → Feishu OAuth (next=back-to-share-URL) |
| 已登录 · 非创作者 | 是 | 否 | viewerIsCreator: false 隐藏按钮 |
| 已登录 · 创作者本人 | 是 | 是 | creator_user_id === viewer.id |
| 已登录 · admin | 是 | 是 | viewer.role === 'admin' |
代码里 §0.6 注释明说"用户 2026-05-28 拍板：链接级分享"。 但我作为 independent reviewer 要 double-check 一下，因为含义是： 任何登录 FunPlus 内部用户拿到链接就能看到任意 plan / delivery 的完整内容。
DB 角度无风险。dry-run merge 干净。validation 全绿。一个 risk 是 process gap（已修 bug 不阻塞）， 一个 risk 是产品决策（待你拍板）。
理由（按重要性）：
暂停点： mb-codex 现在已经把 merge/deploy 暂停，等你回答 §7 那个 /share 访问范围问题。 回了 → 立刻合。