laoyang
9c70dbe0ff
v34 第 34 批：观影「开始/结束时间没了」真根因修复
用户原话：
观影模块儿的开始和结束时间都给我搞没了。赶紧修复一下。
真根因（真机实测）：
app.js 的 upgradeRange() 挂上 Semi 范围控件后，会把两端**各自的包装 .field**
用 display:none 藏掉（只留范围控件）。但观影 / 旅程表单的结构是
**两端共用一个 .field.dt-range**：
<div class="field full dt-range">
<label>开始 / 结束时间（精确到秒）</label>
<div class="dt-input">开始
<div class="dt-input">结束
</div>
此时 a.closest('.field') 与 b.closest('.field') **都取到 .dt-range 本身**
=> display:none 把**整组（含刚挂好的范围控件、连标签）**藏掉
=> 用户看到「开始/结束时间整个没了」，点不到控件，提交时四个原生字段全空
=> 库里 starts_at/ends_at 为 NULL。
真机证据：{groupDisp:'none', groupVisible:false, groupH:0, rangeVisible:false}
线上数据证据：今早 08:43 新建的「神探之痕迹」两条时间都是 NULL（就在反馈前几分钟）。
服务端**完全正常**：直接 POST movies/create（带 starts_at_*/ends_at_* 四字段）
-> 库里正确落 2026-10-05 19:30:00 / 21:45:00 => 问题纯在前端渲染。
⚠️ 日程页为什么没事：它两端各在自己的 .field.ev-dt 里（两个不同包装），
分别隐藏是对的。所以这个 bug 只在"两端共用包装"的三处模板出现：
movies/form.php、trips/node_form.php、trips/_revise_form.php。
修法（assets/js/app.js）：
隐藏前先判"包装是不是就是范围组本身"：
var wrapIsGroup = (hideA === group || hideB === group || hideA === hideB);
if (wrapIsGroup) { 藏里层 .dt-input、组本身保持可见 }
else { 原行为：两端各藏自己的包装 }
（CSS 已有 .dt-range.is-semi-range > .dt-input { display:none }，与 JS 修复不冲突。）
验证：
· 新增真机探针 _fb_b34_dtrange.py：四个用时间范围的表单页
（观影新增 / 观影编辑 / 旅程节点 / 旅程改期）都断言
「组可见 + 范围控件可见 + 标签在 + 原生控件已让位 + 无 JS 报错」21/0。
· 反向验证 _fb_b34_dtrange_falsify.py：改回无条件隐藏 -> 断言必须红 4/0。
· 线上 app.js SHA256 与本地一致（含 wrapIsGroup 修复）。
· 全套：e2e 1503/0、几何 428、各批真机/反向全绿、部署静态断言空跑通过。
顺带修掉的两处探针脆弱（本轮暴露）：
· _b32_verify.py 的"真机点共享"原来是一串固定 wait_for_timeout —— 流水线里
机子忙时踩空 -> 证伪① 假失败（单独跑却 5/5 全过）。改成 wait_for_function
轮询每一步就绪 + 提交后轮询数据库落库。改后证伪 5/0。
· _b32_falsify.py：加 FB_FALSIFY_ONLY（只跑指定用例，省 80% 排查时间）+
前置清 v32 资源残留 + 每个用例的探针完整输出落盘；证伪脚本夹具起点确定化。
2026-10-09 11:03:59 +08:00
..
2026-10-08 17:41:30 +08:00
2026-10-04 08:56:40 +08:00
2026-09-29 23:48:45 +08:00
2026-10-09 11:03:59 +08:00
2026-10-04 17:42:21 +08:00
2026-09-30 00:49:53 +08:00
