文档库系统性回读 ·「被遗忘的设计」对照清单

触发：义父 2026-09-21 23:4x ——「appid 是沿用主小程序；你可能也需要系统性地读一下文档库了，很多设计似乎你们都忘了」

执行：波波｜路径 /Users/lean/dev/kailash-bobo ｜核对基准：提审包 46 页 / 942.8 KB

〇、一句话结论

没忘干净，但也没全忘。 我把 design / deep-dives / white-label / contracts / specs / miniprogram-v2 六组文档的生效约定，逐条拿去和当前提审包代码对照：

对得上的：tabBar 四页纯文字、会员等级/成长值已清零、订单态禁词 0、包体远低于 2048KB
真偏离的：称谓两套并存（18 处违规）、品牌名硬编码 9 处、天气缺更新时间
压根没实现的：定位/在场双轴状态判定（设计的整套方案，代码里一处没有）
需要你裁的：membership 页的去留

另外报一个系统性隐患：文档库存在一个同名副本路径，我派的助手一开始就跑错地方，差点拿别处的旧文档当结论（详见第五节）。

一、核验为「没忘」的（保持即可）

设计约定	出处	代码现状	判定
TabBar 四页冻结、纯文字无图标（首页/玩法/在地/我的）	`design/gpt6-评审输入材料-v1` 一	`app.json` tabBar 四页，文案完全一致，零图标	✅ 一致
会员体系已砍除：禁任何等级分/成长值/积分	`design/首页接口要求-v1` §2.2	包内 46 页扫「成长值/等级分/会员等级/消费升级」= 0 命中	✅ 一致
订单态 `displayHint` 禁写「你已到场/正在体验」	`design/订单接口字段需求清单-v1` §2	扫「你已到场/正在体验/已完成体验」= 0 命中	✅ 一致
主包 ≤2048KB（按构建产物验收）	`design/状态自动判定方案-v1` §8.3-9	实测 942.8 KB（965,457 B）	✅ 余量 1.05 MB
金额对外「元」	`contracts/api-v1.md:94`	`payment-confirm:22` = `Number(o.totalPrice).toFixed(2)+' 元'`	✅ 正确

二、真偏离（建议修）

1. 称谓两套并存 —— 设计明令「一律称主理人，禁称商家/商户」

项	数
「主理人」	23 次
「商家 / 商户」	18 次

出处：deep-dives/深挖2-主理人动机经济 §1 + design/gpt6-评审输入材料 二·主理人平等。

风险：高。这是用户直接看得见的文案，提审审核也会读。

注：merchant-store 是商户层的实现载体，路径名用户看不见，作为商户详情页本来就该这么叫 —— 需要改的是上面那 18 处用户可见文案，不是这个路径。

2. 品牌名硬编码 9 处 —— 白标要求「零硬编码，全部 site-texts 注入」

命中：home（2）、login、passport、settings、privacy-auth、guide-detail、merchant-store（2 处重复计入）。

出处：white-label/前端-BFF接入清单-v1-冈子 A 表（13 类触点必须注入）+ 白标化系统方案-v2 §5 风险3。

风险：高。妨碍的对象是整套小程序被复制成另一个产品（换品牌、换域名、换模块开关），与温泉酒店无关。

概念更正（2026-09-22 义父纠偏）：我此前把「给温泉酒店做白标」当成白标目标，这是错的。

白标（模式 A 单租户复制）= 一整套小程序实例的复制：tenant.yaml + 独立 DB + 独立域名 + 品牌注入 + 模块开关，改名字改结构就变成另一个小程序。

温泉酒店是神山秘境小程序旗下的一个商户，走 merchant-store + scene 分发 + 商户详情页，不属于白标层。两者是「实例」与「实例内的内容」的关系，不能混用同一套机制。

3. 天气缺「数据更新时间」 → 误判，撤回（2026-09-22 实测更正）

昨天写「home 有来源但没有更新时间」——我错了。

home.ts:73 有 updateText: pub ? pad2(...) + ' 更新' : '—'，取值自 w.published_at；.source-line 渲染 weather.sourceText，取值自 w.sourceName
实测 GET /api/miniapp/weather/today（HTTP 200）：published_at: "2026-09-22T00:23:57.399805+08:00"、sourceName: "西藏自治区气象服务中心" ⇒ 来源机构名 + 更新时间双挂，契约一致，真有值
教训：我昨天只在 wxml 里搜"更新时间"字面，既没回溯 ts 的字段构造，也没真调接口就下了结论。和 refundAmount 那次正好相反 —— 那回是过度怀疑，这回是没验证就定罪
现已增补 check_v2_design_redlines.py R3 规则：以后这条由脚本判，不靠我记得

4. 定位/在场双轴状态判定 —— 完全没实现

设计有一整套方案（design/状态自动判定方案-v1 + 状态判定-订单与定位双轴-v1）：UNKNOWN / OUTSIDE 分流、Presence / HomeMode / ModeOverride 三类型分离、禁止用 IP/扫码/分享参数充当到场证明。

现状：包内 46 页扫 UNKNOWN|OUTSIDE = 0 命中，整套机制不在代码里。

风险定性：不是 bug，是没建。要先确认这是「待建」还是「已废弃」——如果是后者，那两份文档该标作废，否则会一直被当成漏做。

三、查清但不是问题（避免误判的记录）

退款预览的 /100 兜底：order-refund-preview:66 把 refundAmount 当「分」除 100，看着像资损。核后端 backend/app/routers/miniapp_orders.py:1182 后确认 —— 响应结构只有 cashRefundYuan / keyRefundYuan（元），根本没有 refundAmount 字段 ⇒ 该兜底永不触发，显示正确。定性：契约漂移的哑弹，建议清掉避免将来误用。
kora-timer 的 /100：毫秒转秒的时间格式化，与金额无关，误报排除。
membership 页：见下一节。

四、待你裁定

membership 页仍在 46 页提审包内。 页面本身很薄（29 行 wxml / 2 处后端调用），内容是会员身份与权益列表，不含等级分、成长值、付费解锁，所以不违反具体禁令。但文案里有一句「购买与续费以平台公示规则为准」，而设计写的是「会员体系已砍除，护照不得做成消费等级（无付费解锁、无消费升级）」。

两条路：A 留着，但去掉那句带「购买」语义的文案；B 摘出提审包（源文件保留）。我没擅自处理。

五、一个系统性隐患（必须报）

我派的助手一开始读错了根目录 —— 它跑去了 /Users/lean/WorkBuddy/2026-08-29-15-03-56/kailash/docs/，而不是 /Users/lean/dev/kailash-bobo/docs/。后果很实在：它据此报告「deep-dives 目录不存在」，而正确路径下那 6 篇定稿（定价与信任 / 主理人动机经济 / 安全责任边界 / 福钥经济 / 纠纷与秩序 / 运营与淡季）就好好地躺在库里 —— 福钥是本项目核心经济机制，差点整篇被漏掉。

这说明：文档库存在同名不同内容的副本，任何人按名字找都可能读到旧的那份。 建议明确「唯一真源」，其余副本标注只读快照或直接归档。这不是小事 —— 一个记错的路径就能让整份设计被当成"不存在"。

另外，两份台账（miniprogram-v2/缺口矩阵-2026-09-13、长线任务报告-硬编码治理）都自带时效标注「口径以 TASKS 现行与契约 v1.3 为准」，且缺口矩阵表体已作废（抬头说 19 页全补完了，表体还列着「未开始」）。这类文档今天还会被当成待办清单读。

六、建议：把「会被忘的」变成门禁

这次的偏离清一色是静态可扫的，完全可以做成脚本，不靠人记：

check_v2_terms.py —— 禁「商家/商户」，要求「主理人」（白名单机制，逐个词豁免）
check_v2_brand_hardcode.py —— 品牌名必须走 texts，硬编码即退出码非 0
check_v2_weather_meta.py —— 天气必须同时有来源 + 更新时间
加进每日 08:00 自动体检

要我动手就说一声。在你点头前，我一行代码没改。

*署名：波波｜ 2026-09-21 23:5x*