tamakyi/rond-with-you
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
84 Commits 1 Branch 0 Tags
9cf3d89c3c648b84dafa47c2b05e1f5e82bdab10
Commit Graph
84 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
tamakyi 9cf3d89c3c 记忆：本仓库推送要认证，非交互环境会卡在凭据弹窗（fetch 匿名） 2026-10-12 18:52:52 +08:00
tamakyi bf7121f11b 记忆索引：补数字框 step 那条（9030） 2026-10-12 18:14:20 +08:00
tamakyi d795c6b579 记忆：input[number] 的 step 相对 min 递增（原生提示 JS 拦不到）+ 通配守卫 2026-10-12 18:13:44 +08:00
tamakyi 9c76437a76 修：显示区半径输入框被浏览器原生校验误判 
现象：输入任意正常半径（3、3.5、7.25…）提交时弹
「请输入有效值。两个最接近的有效值分别为 2.55 和 3.05」。

根因：<input type="number"> 的 **step 是相对 min 递增**的，不是「step 的整数倍」。
min=0.05 + step=0.5 ⇒ 合法值只有 0.05 / 0.55 / 1.05 …，于是 3 和 3.5 全被判非法。
而这是**浏览器原生**提示：JS 与后端都拦不到（我们自己的校验根本没机会说话）。

实测对照（同一元素换 step，其余不动）：
  step=0.5  ：0.05✓ 1✗ 3✗ 3.5✗ 7.25✗ 13.37✗
  step=0.05 ：0.05✓ 1✓ 3✓ 3.5✓ 7.25✓ 13.37✗   ← 仍会拦任意小数
  step=any  ：全 ✓                              ← 采用
保留 min/max（真实边界，且给 spinner 范围），只把 step 放开交给 JS/后端校验，
理由与写法都记在模板注释里。

同一 bug 类加了通配守卫，防的是下次换个页面又踩：
- TestNumberInputStepNeverMismatchesMin：扫**所有**模板的数字框，
  凡「有 min 且有数值 step」就要求 min 是 step 的整数倍（或改用 any）；
- TestTopicAreaRadiusInputAllowsAnyStep：列表里的输入框是 JS 动态建的，模板扫不到，
  单独钉住 step='any'。
变异验证过：把 step 改回 0.5，守卫立刻红。

实测（无头）：输入 3.5 后 validationMessage 为空、form.checkValidity() 为真 ⇒
回车提交不再弹气泡；隐藏字段正确更新为 radiusKm:3.5；越界值只给我们的中文提示
（stepMismatch=false、rangeUnderflow=true，说明「step 误判」这一类已消除）。
全站其它数字框（如迷雾遮罩的 radius_m，min=50/step=50）本来就合法，未改动。
 2026-10-12 18:11:53 +08:00
tamakyi 829a318400 记忆：后台显示区编辑器（地图点选）+ HasMap 陷阱 + 记忆索引压缩到 8919 2026-10-12 17:35:55 +08:00
tamakyi 7ab33227a5 专题显示区改成在地图上点选（后台编辑器） 
用户诉求的后半：不该让他手填经纬度和半径，应该在地图上圈。三个手填输入框
换成地图 + 圆列表：点地图加圆、拖圆心移动、拖圆边改半径、列表里可改半径/
定位/删除、可一次清空；改动立刻写进隐藏字段 areas(JSON) 与 crs，随专题表单
一起提交。

- 复用 /admin/fog-mask 那套约定：/api/map-config 取底图、底图坐标系随表单带上、
  后端换算成 GCJ-02。不另起炉灶。
- areas 的初值**渲染进隐藏字段**（不是只塞给 JS）：脚本没加载上时提交的仍是原值，
  否则一次保存就把已有显示区静默清空。
- 地图初始视野取生效数据集的地点包围盒（placesBounds），一上来就落在自己的地界上，
  而不是全国视野。
- 上限（20 个 / 0.05~2000 km）前端也校验一份，并**禁用提交**；两边数字用守卫比对，
  免得出现「前端放行、后端拒绝，用户不知道改哪里」。

实测抓到并修掉的 bug：/admin/topics 没设 p.HasMap ⇒ 布局不引入 Leaflet，
表现是脚本加载了、rondTopicAreas 也在，就是 window.L 永远 undefined，init 静默
返回、控制台不报错、页面像「什么都没发生」。已加守卫钉住这一点。

其余：
- topic-areas.js 只暴露纯函数（校验/序列化/增删改的不可变性/几何换算）供 node 单测，
  另加一个最小测试钩子 api._map 供无头验证（同 window.rondMap._state 惯例）。
- CSS 用定宽容器装半径输入框：站点全局 input 规则是 width:100% 且带 10 个 :not()
  （特异性 (0,11,1)），直接给 input 写宽度压不过。
- gofmt：文档注释里的缩进列表按 Go 1.19 的规则重排；顺带把工作区的 CRLF 归一到 LF
  （.gitattributes 早就声明 eol=lf，blob 本来也是 LF，所以 git diff 无额外噪声）。

验证：
- topic-areas.test.js 44 条（含「增删改返回新数组不原地改」、半径换算自洽性）。
- 三个新守卫：两边上限一致、模板契约（旧输入框必须没了 + 挂点齐全 + 初值来源）、
  topicsAdminPage 必须设 HasMap。
- 无头端到端：两击成两圆 → 改半径 7.5 → 删第 1 个 → 越界半径被拦且禁用提交 →
  提交 200 且落库 areas=[{lat:24.72,lon:108.1,radiusKm:7.5}]（废弃列镜像 7.5）；全程无 JS 报错。
 2026-10-12 17:35:00 +08:00
tamakyi 48938e6ae1 记忆索引压缩：两节合并 + 理由下沉 details，9285 → 见正文 2026-10-12 17:23:09 +08:00
tamakyi 2d46b8a0ca 记忆索引：收紧专题显示区那条（自己成了最长行） 2026-10-12 16:47:21 +08:00
tamakyi b40160867e 记忆：专题显示区一组圆（存储/查询/裁剪纪律）+ 前端单测挂进 verify.sh 2026-10-12 16:46:53 +08:00
tamakyi 44763dfc3f 专题的多圆显示区：前台按并集裁剪迷雾 
上一批把显示区改成了「一组圆」，这一批让前台真正认多个圆。

- clip-path 从 circle() 换成 path()：circle() 只表达得了一个圆。每个圆一段
  圆弧子路径、**同绕向**（sweep=0），nonzero 填充规则下多段自然取并集，
  重叠处不会互相挖洞。
- 拼路径的活单独放 fog-clip.js（rond-map.js 是个大 IIFE，函数取不出来），
  这样能直接跑 node 单测；layout 里必须排在 rond-map.js 之前加载。
- 顺带清掉已经死掉的 fitCircle：多圆之后「圆心 + 半径」表达不了，留着就是
  两套并行的贴合口径。fitParams 现在只给 fitBBox（单圆时外接矩形正是那个
  圆的外接正方形，视野等价）。
- 守卫改名 TestTopicFogIsClippedToAreas，钉住两端（模板发 fogAreas ↔ 脚本认
  fogAreas）与两处顺序（裁剪注册在 applyFit 之后、fog-clip.js 在 rond-map.js
  之前）；fogAreas 必须**无条件**下发（空数组 = 不限区域），不要包在条件里。
- verify.sh 挂进前端单测：以前只靠人记得手动跑 = 等于没有。找不到 node 直接
  失败而不是跳过（跳过会让验收看着全绿、实际一行前端脚本都没验）。

验证（临时两圆专题，SQL 造的，已删）：
- fog-clip.test.js 15 条：把生成的 path 解析回圆弧再验几何，含绕向一致性与
  半径 0/负数的夹取。
- 端到端像素验证：自校准出「CSS 容器坐标 → 图像像素」（scale≈2、offset≈19.2，
  正是 site_cdp 的 --clip 外扩 10px×scale，别再手算）；三张掩码图证明并集语义
  —— A 独有点只有 A 亮、B 独有点只有 B 亮、**重叠中心两圆都亮且并集也亮
  （无洞）**，整体集合差异 0.013%。
- 迷雾掩码：86,776 个像素，按两圆并集的解析式判 **圆外 0 个**；两个圆内分别
  有 52,609 / 46,757 个迷雾像素 ⇒ 第二个圆真的被认了，不是只看第一个。
 2026-10-12 16:44:55 +08:00
tamakyi 1bb35dbbc9 专题显示区改为一组圆（后端与查询层） 
把专题的「一个圆」换成「一组圆」（areas jsonb 数组）：落在任一圆内即算在
区域内（SQL 里的 OR）。这一批只动后端与查询层，前台渲染与后台地图编辑器
分别跟进；后台表单暂时沿用原来的三个坐标输入框，保存时合成一个圆写进
areas，所以现有交互不受影响。

- topics.areas JSONB + 存量回填：老的单圆搬进去，之后 areas 是唯一权威。
  废弃的 center_lat/center_lon/radius_km 保留（写入时镜像第一个圆），
  一是回滚旧二进制时还能退化显示成第一个圆，二是回填的输入。
- Topic.AreaList() 归一：Areas 为空时退回老的三列，未回填的老行与直接构造
  Topic 的调用方都继续工作。
- topicAreaCond 改成 N 个圆的 OR；每个圆占 3 个占位符，编号纪律照旧
  （写错就是「专题内容全变 0」那种难查的事故）。
- fitParams 改用所有圆的并集外接矩形：多圆之后「圆心+半径」表达不了，
  统一走 fitBBox；单圆时外接矩形就是这个圆的外接正方形，与原路径等价。
- 坐标系：编辑器提交的圆心若是 WGS-84 底图上点的，存前换算成 GCJ-02
  （地点过滤要拿它跟 places 的 GCJ-02 坐标比距离）。

测试：
- 表单解析（两个入口同一套校验）、wgs84 换算、半径为 0/空 = 不限区域、
  坏 JSON/越界必须报错、上限 20 个。
- 占位符纪律：本段引用的 $n 必须恰好是 [prefix+1, len(args)] 连续区间，
  最大值必须等于参数个数。
- 多圆并集语义（DB 门控）：两圆专题的地点集合必须恰好等于两个单圆专题的
  并集 —— 定义性不变量，变异验证过（只认第一个圆 ⇒ 两个用例同时红）。
 2026-10-12 16:29:46 +08:00
tamakyi cc37c9d1c9 记忆：迷雾收口的像素级验证方法 + --clip 截图 pad 偏移坑 2026-10-10 10:51:51 +08:00
tamakyi eb35abb7f2 专题页的迷雾按专题圈的区域收口 
以前专题的中心/半径只用来定视图，迷雾图层一直是全局的；管理页那句
「迷雾由地图按视野自动呈现，不需要单独圈选」其实是把「没做」写成了
「不用做」。现在专题圈了区域时，迷雾只在那个圆内显示。

做法是给迷雾单独一个 pane（zIndex 250，底图 200 之上）再对该 pane 做
clip-path: circle()——不能直接裁 tilePane，底图也在里面，会把地图一起挖空。

两个坑：
- 圆心必须先 project() 到底图坐标系（与 fitCircle 一致），否则整体偏移；
- 裁剪圆的注册必须排在 applyFit() 之后：视图未定时 latLngToContainerPoint()
  会抛「Set map center and zoom first.」，把后续图层添加一起打断——实测
  表现是 pane 建好了、迷雾瓦片一张都不出来，而且不报错。

迷雾是累积快照、没有时间维度，所以只按区域收口，不按专题的时间范围收口。
守卫 TestTopicFogIsClippedToArea 钉住两端与注册顺序。
 2026-10-10 10:41:27 +08:00
tamakyi cd69efe8f1 日历改中文、修掉头部重叠；统计页那两张体量悬殊的卡不再并排 
用户反馈：日历「空间显示有点异常」且是英文、和项目割裂；类型分布与一天中的分布仍是一左一右、
右边下面一大片空白。两件事的根因都不是表面看到的那个。

一、日历英文
- `flatpickr.localize(l10ns.zh)` 原先只写在三个后台页的 whenReady 里；上一批把 flatpickr 放到
  公共页（筛选区）之后就漏了 ⇒ 日历全是 Sun/Mon/January…
- 修法：移到 datetime-input.js 的 attachPicker 里（localizeOnce()，全局只调一次），
  三个后台页那三行重复调用删掉。

二、日历头部重叠（就是用户说的「空间异常」）
- 月份下拉被撑满整行、压在年份输入上。根因是**站点全局的 input/select 样式扫进了日历内部**：
  那条规则带 width:100%、内边距、边框与 16px 控件字号，而日历内部的
  `input.numInput`（type=number）与 `select.flatpickr-monthDropdown-months` 都躲不开。
- ⚠️ 第一版修法（在后面补一条 `.flatpickr-calendar input{...}` 对冲）**是错的**：全局选择器带
  10 个 :not([type=…])、特异性 (0,10,1)，普通对冲压不过，实测年份框仍是站点样式。
  正确做法是在**全局规则里排除** `input…:not(.numInput)` / `select:not(.flatpickr-monthDropdown-months)`，
  `input:focus` 的焦点环同理（否则年份框上套一圈主色光圈）。
- 实测：星期「周日 周一 …」、月份「十月」、月份与年份 overlap=0、无 JS 报错。

三、统计页排版
- `align-items: start` 只消掉了卡内空白，消不掉并排本身的空：类型分布 1411px 与
  一天中的分布 256px 并排，右侧下面必然空一片。改成单列（`<div class="grid">`），
  两张卡各占整行 1080px —— 24 根柱终于有宽度可用，列表也像「城市排行」那样横铺。

回归：./scripts/verify.sh PASS=349 FAIL=0 SKIP=0；JS 单测 45/45；移动端 390 溢出全 0；
桌面 1440 与改前一致（−15 是滚动条宽）。
 2026-10-10 09:45:32 +08:00
tamakyi b19f27ab69 日期框补上日历弹层：flatpickr 改为无条件加载 
用户实测：筛选区日期框换成文本框后手机上没了日历弹层、不好操作；多 18KB gzip 可以接受。

- layout.html 里 flatpickr（js + css + l10n）与 datetime-input.js 都改为**无条件加载**，
  不再用 {{if .Flatpickr}} 按页开关 —— 「按页开开关」正是 2026-10-09 日期框 bug 的根源
  （只给 type=datetime-local 挂了控件，后来加的 type=date 没人管）。
- 顺手删掉 `Page.Flatpickr` 字段与三处 `p.Flatpickr = true`（开关没了就不可能再漏设）。
- 守卫 TestDateInputsGoThroughAttachAll 相应改成：钉住「layout 无条件引入 flatpickr +
  datetime-input + attachAll」、并禁止再出现 {{if .Flatpickr}}。

实测（展开筛选面板后）：390/320 下 /stats /map /places 的日历都在最上层（z-index 99999）、
完全在视口内、elementFromPoint 命中日历本身；打字 20260606 → 2026-06-06 不变。

回归：./scripts/verify.sh PASS=349 FAIL=0 SKIP=0；JS 单测 45/45；320/390/1440 溢出与改前一致。
 2026-10-09 19:09:42 +08:00
tamakyi b69b827d6e 日期框换成自控输入（原生 date 会吞位）+ 气温图桌面端铺满 + 同行卡片不再被拉伸 
三件事都由用户实测反馈，前两件先复现再动手。

一、日期框：敲 20260606 变成 202606/06（用户要「永远解决」）
- **实测复现**：写了个真实按键工具（CDP Input.dispatchKeyEvent 每字符带 text；
  技能里的 `--press` 只给 Enter 带 text，数字敲不进去）。在 /stats 的「起始日期」上敲 20260606：
  敲之前 `INPUT|date|`、attached=false；敲完显示 `202606/06`、`el.value` 是**空**（非法）—— 截图为证。
- **根因**：筛选区的起止日期是原生 `<input type="date">`，而挂载代码只写了
  `querySelectorAll('input[type=datetime-local]')` ⇒ **type=date 从没人管**。
  Chrome 的年段允许超过 4 位数字（年份上限 275760），8 位被切成 年=202606 + 月=06。
  原生分段状态读不到、`setSelectionRange` 对 date 类输入直接抛 ⇒ 修不了，只能换控件
  （用户也说了「如果当前控件无法实现就换别的」）。
- **做法**：`datetime-input.js` 加「只日期」模式（`SPEC.date`：年/月/日三段，输出 `Y-m-d`），
  并提供**统一入口 `attachAll(root)`** 按 `el.type` 分派；`attach` 里先把控件换成 `text`
  （引导会写 `2026-06-` 这种半成品，而原生控件对非法值一律置空）。
  `datetime-input.js` 改为**无条件引入**（公共页筛选区也要用；flatpickr 仍按需加载 ——
  没有它时只挂输入引导、不给日历，省 60 多 KB），挂载在 body 末尾**立刻**跑一次
  （别只等 DOMContentLoaded，否则会先露出原生框再变文本框）。三个后台页改用 `attachAll`，
  顺带覆盖行程筛选的 `mfrom/mto`（date 类走 `enableTime:false`，实测无时间选择器）。
- **验证**：真实按键敲 20260606 → `value="2026-06-06"`；端到端 `from=2025-08-01&to=2025-08-31`
  筛出 **186 次**，与月度图峰值月（186）完全吻合（排除「解析成空导致恒 0」）。
  门禁 `TestDateInputsGoThroughAttachAll`：模板里再出现按 type 挑的选择器即红（做过变异验证）；
  JS 单测补 11 条逐键模拟（45/45）。

二、逐月平均气温图在桌面端很小
- 量出来的：10 个月固定 36px 宽，只占 1042px 里的 **396px**，右边 600 多像素全空。
- 窄屏保持「固定 36px + 横滚」（挤在一起月份标签会糊），宽屏改 `flex: 1 1 36px; max-width: 96px`
  并把轨道从 84px 加到 130px、字号提到 `--fs-sm`。

三、类型分布与一天中的分布同行高度不齐
- grid 默认 `align-items: stretch`，把 256px 的「一天中的分布」拉到与 1411px 的「类型分布」一样高，
  卡片内部留一大片空白。改成 `.grid { align-items: start }`。

回归：./scripts/verify.sh **PASS=349 FAIL=0 SKIP=0**；移动端 390 / 桌面 1440 溢出与改前一致。

⚠️ 两个验证纪律（都写进 details 三十二）：
- 验收跑着的时候别并发跑测试/变异实验（两次踩到，其中一次变异正好被验收抓到，那轮结果作废）。
- **变异验证「内嵌文件」（templates/static）之后必须 `go clean -cache`**：`//go:embed` 的内容
  在「改坏→还原」后，构建缓存会继续给出变异期间编译的那份 —— 实测同一个测试
  `go test ./internal/web/` 绿、`go test ./...` 红，`go clean -testcache` 不管用。
 2026-10-09 18:29:55 +08:00
tamakyi 3077250a82 记忆：完整回归结论 + 验收必须在安静环境跑 
- 记下本次完整验证链：verify.sh 348 例 0 skip、fog 包 -race 22 例、JS 34/34、320/390 溢出全 0。
- ⚠️ 新纪律（details 三十二）：`db.Open` 的 ping 写死 10s，库被压着时
  `TestOpenCreatesMissingDatabase` 会以「建库后首次连接超时」失败 —— 实测与 CDP 审计并发时 10.02s 超时，
  停掉审计单独跑 4.1s 就过。这条测试失败还会把临时库 `rond_test_autocreate_*` 留在库里
  （清库的 defer 在 Open 成功之后才注册），要手动 DROP 清掉。
- 记下「原有代码受影响」专项检查的方法与结果（自定义属性 0 处用了没定义、模板函数无真孤儿、
  19 个模板 diff 只有预期改动；`.g3/.g4` 是 HEAD 里的既有死类）。
 2026-10-09 17:02:05 +08:00
tamakyi ab7ccd22ce 前端改造：设计令牌 + 卡片层级 + 图表可读性 + 类型色收口 + 窄屏导航 
先出方案（frontend-plan-2026-10-09.md）再动手，四批按顺序落地。方法上先存基线、再用同一份
探针在改动前后逐值 diff —— 这批里有 6 处问题只有「量」才看得见，看截图全是正常的。

A 设计令牌（app.css 为主）
- 字阶收敛到 6 档 --fs-xs/sm/md/lg/xl/2xl = 11/13/15/21/26/34px。原来 app.css 有 19 种字号、
  模板里另有 54 处内联字号，光 12~15px 之间就挤了 4 档 —— 层级挤不出来，只能靠加粗硬顶。
- 两个「字外档」不是漏的：--fs-control: 16px（窄屏表单控件必须 ≥16px，否则 iOS 聚焦放大整页，
  属功能约束）；--glyph-*（✕/箭头/空态图标按控件尺寸定，硬塞进字阶只会把按钮撑坏）。
- 字重收敛到 400/500/600（删掉 650 与 700）。
- 圆角 4 档 --r-*、阴影 3 档 --sh-1/2/3（暗色整套覆盖）、间距 --sp-1..5、
  卡片内边距单列 --card-pad（与折叠卡片标题行的负 margin 绑在一起，改一个即改两处）。
- 门禁 TestNoBareFontSizePx：静态扫 app.css 与全部模板，出现 font-size: <数字>px 即红。

B 卡片分主次
- .card--hero / .card（默认）/ .card--quiet 三档。quiet 走「页面底色 + 细边 + 无阴影」——
  第一版拿 --bg-2 当底色，实测它与页面底 #f6f7f8 只差 4/255，看不出边界、像破了个洞。
- 首屏 KPI 从「4×2 等重白盒」改成 .kpi-lead（主数 + 一行上下文）+ 5 个常规指标，8 个数字一个没少。

C 图表说人话
- 月度分布：柱底加基线；峰值柱不透明拉满、柱顶标次数（.pv），副标题里不再重复写「最高 N 次」。
- 一天中的分布：把「0/6/12/18 四个数字」换成 6 小时一段的标尺（深夜/上午/下午/晚上），
  用同一套 24 列网格，段边界与柱子严格对齐。
- 首页月度图同样加峰值锚点（给 HomeData 补 MaxMonthly，与统计页同口径 maxOf）。
- 空态没动：查下来已经统一（8 页共用 emptystate、局部走 .empty）。

D1 类型色语义化（结论与计划不同，按实测改了）
- 先算对比度：白底上 yellow 1.87 / mint 2.12 / orange 2.20 / green 2.22 / cyan 2.54 / teal 2.57，
  6 个色连图形对象 3:1 都到不了；暗底只有 indigo 2.90 不够。
- 所以**没有**把类型色用到 chips / 表格类型列 / KPI 强调 —— 那几处要的是文字色，只会更难读。
  这也解释了全站为什么一直只用 8px 小圆点做身份标记。浅色那 6 个色一个没动：
  它们是手机端与地图上的同一套身份色，改暗会破坏对应关系。
- 实际做的：色值收口成 --cat-* / --cat-*-soft（26 个变量）；模板 colorof → csscolor / csssoft（19 处）；
  暗色只提亮 indigo（2.90 → 3.55:1）；colorOf 成了死代码，删掉。
- ⚠️ 返回值必须是 template.CSS：html/template 的 CSS 过滤器不认识 var()，普通 string 会被静默
  换成 ZgotmplZ —— 页面上所有圆点当场变透明，而且不报错、模板测试照过。挂了它等于关掉那道过滤，
  所以数据侧色值先过严格校验（只有 # + 6 位 hex 放行），否则 #"><img… 能逃出 style 属性。
  守卫 TestCSSColorSurvivesTemplateSanitizer 把两个方向都钉住（做过变异验证）。

D2 窄屏导航
- 改前 ≤620px 靠横向滚动兜底：390 溢 63px、320 溢 133px，「统计」被切成半个字紧贴后面的按钮，
  渐隐提示实际看不出来。现在链接本体抽成 {{define "navitems"}} 渲染两遍：桌面 .nav-links 平铺、
  窄屏 .nav-menu（原生 <details>，不靠 JS 也能开合）；JS 只补点外面 / Esc / 点链接后收起。
- ⚠️ 顶栏 --z-nav 抬到 1200：菜单是 .nav 的子元素、自己抬不动层叠上下文，不抬就会被地图页的
  --z-map-overlay(1100) 盖住。已在 /map 上用 elementFromPoint 实测。
- 守卫 TestNarrowNavCollapsesToMenu 钉「CSS 两半 + 模板两个类 + 渲染两遍」的成对关系。

途中发现并一并修掉的（都只有量 DOM 才看得见）
- Leaflet 的 .leaflet-container 字号是 0.75rem、跟着根字号漂：根 14 → 13px 后地图署名/比例尺
  掉到 9.8px（低于本站 11px 下限）、弹窗正文也跟着缩。已按自己的字阶钉死。
- h1..h4 原来只设了字重与 margin、没设字号，靠浏览器默认的 2em/1.5em/1.17em —— 同样跟着根字号漂：
  /stats 那两个 h2 从 21px 变成 19.5px，比同页卡片标题大一圈。已显式给出字号。
- <b>/<strong> 浏览器默认 700，比全站最高层级（标题 600）还重，已钉成 600。

回归
- ./scripts/verify.sh：PASS=348 FAIL=0 SKIP=0
- internal/fog 加 -race：PASS=22 FAIL=0 SKIP=0
- JS 单测 34/34
- 移动端 320 / 390 溢出全 0（改前 /admin 在 320 还溢 34px）；桌面 1440 与改前一致（−15 是滚动条宽）
- 全站 7 个页面都没有低于 11px 的文字

说明：A/B 与 C/D 本想拆两笔提交，但 app.css / layout.html / view.go 里两批改动交织，按文件拆不开、
按 hunk 拆又容易做出「中间那笔编译不过」的历史，所以合成一笔、在消息里分段。
 2026-10-09 17:01:08 +08:00
tamakyi d4e4257a23 启动模板自检 + 站长导航放行 + 统计脚本关口收紧 
排查：/admin/settings 渲染到一半就断
- 现象：页面在「统计脚本」那张卡片处截断，没有保存按钮、没有 </form></html>，而 HTTP 仍是 200。
- 根因：跑的是旧二进制（改动前编译），磁盘上的模板却是新的。debug=true 下 pageSet()
  每次渲染都从磁盘重解析模板，于是新 settings.html 引用了旧 setting.Settings 里没有的
  TrackEnabled —— 执行期报错，而 render 只把错误写进日志，客户端只看到半张页面。
- 判据：strings <二进制> | grep -c cleanTrackScript（旧 0 / 新 2）。别用 strings | grep
  TrackScript —— config 里本来就有这个名字，旧二进制也命中，是个假信号。

启动自检（防复发）
- template_smoke.go：pageProbe 给 24 个页面各配一份最小可用数据，New() 里全部渲染一遍，
  任一页失败就拒绝启动。pageProbe 与 pageFiles 双向校验，新加页面必须补探针，
  漏配按失败处理（不是省事）。
- smokeOne 用 recover 兜住方法里的 panic，报「哪一页坏了」而不是崩栈。
- 实测：往 settings.html 插一个不存在的字段 → 启动即报
  「模板自检未通过…admin/settings: can't evaluate field …」，退出码 1。
- 门禁 template_smoke_test.go：一条跑全量自检，一条变异验证（探针换成字段更少的类型
  必须报错且点名该页）。

站长导航被页面开关误伤
- guardPage 只拦访客（站长始终能访问全部公开页），但导航写的是 {{if .Settings.HasPage "x"}}，
  没有 IsAdmin 分支 ⇒ 页面开关一关，站长自己也只剩「主页」一个入口 —— 能访问却点不到。
  改成 {{if or .IsAdmin (.Settings.HasPage "x")}}（map/places/timeline/stats/report 五处）。
- 门禁 nav_visibility_test.go：三向不变量（站长仍有全部入口 / 访客一个都没有 /
  全开放时访客也看得到），做过变异验证。
- 访客侧「只有主页」是按后台配置应有的状态，没有动数据。

统计脚本关口收紧（cleanTrackScript）
- src= 只在 <script …> 开标签内部找。原来对整段做 strings.Index，脚本体里一句
  `img.src=u` 就被命中、整段被判危险而清空 —— 页面照样提示「设置已保存」，站长看不出没挂上。
- 开闭标签从「只拒 shut > open」改成严格配平：末尾未闭合的 <script> 会把页面收尾整段吞进脚本。
- 不再静默：签名改成 (script, warn)，说明码经 ?warn= 回显成人话；判为危险时整段不采纳、
  库里原脚本与开关都不动（把站长手上好用的脚本一并清掉更糟）。
- 门禁 TestCleanTrackScript 重写：逐条边界 + 定义性不变量（采纳了非空结果时，
  里面开闭标签数必定相等）+ TestTrackWarnMessage（未识别码不得回显）。变异验证做过。
- 文案订正：settings.html 的「conf/app.ini 的 track_script 会作为这里的默认值」有歧义 ——
  它不回填文本框，而是「这个框留空时、注入那一刻才回落到 ini」。

其余
- bin/ 目录删除（15 个 exe / 412MB），二进制只留仓库根 rond.exe；
  技能 rond-web-verify 与 memory details 十八里 bin/rond.exe 的写法同步改掉。
- 验收：./scripts/verify.sh 全绿且 0 skip（PASS=346 FAIL=0 SKIP=0）。
 2026-10-09 11:06:41 +08:00
tamakyi 4015ddf373 时间框跳段 + 弹窗不再脏地址栏 + 统计脚本做成后台开关 
时间框（flatpickr allowInput 的手输体验）
- flatpickr 把 <input type=datetime-local> 就地改成 type=text，原生分段编辑器被替换掉；
  allowInput 又是「整串解析」语义：实测 parseDate('2026') 只出年份、'202666' 才出月份，
  于是「年份很长才跳下一位」；'20260606' 还会被静默错解成 2030-12-06 且不报错。
- 新增 static/js/datetime-input.js：自定义 parseDate（纯数字只收 4/6/8/12/14 位，
  歧义与非法日期一律拒）+ 输入引导（段满即补分隔符，敲完 4 位年份立刻跳月份位）。
  按标准格式不做自动补零、不前滚；越界值原样保留交报错，不静默改成合法值。
- 三处页面（编辑/照片/专题）共用 attachPicker，配置与原先一致，模板净减 5 行。

弹窗
- window.prompt 会把提示文本与默认值写进地址栏并留进历史（confirm/alert 无此问题）。
- 新增 static/js/prompt-box.js 替代：原生 <dialog>.showModal()，遮罩/Esc/焦点齐全，
  旧浏览器降级成页面顶部一条。已换 report.html 复制链接兜底与 edit.html 活动改名。
- 门禁 no_prompt_test.go：静态扫模板禁止 prompt(，并钉住 JS 与 CSS 都在。

统计脚本
- 原来只能改 conf/app.ini（要重启），现在后台「站点设置」可开关 + 填写，默认关闭。
- cleanTrackScript 挡住注入面：开闭 <script> 标签数不配平（提前闭合会让页面散架）、
  src 的 javascript:/data: 伪协议、超长截断。注意不能用「出现 </script 就拒」当规则——
  百度统计、Umami 贴的就是完整 HTML，正常用法会被挡死。

门禁
- datetime-input.test.js：34 条断言（node 直跑，无依赖）。
- TestCleanTrackScript：逐条边界 + 定义性不变量（任何输入都不得产出含 </script 的非空结果）。
- 三项均做过变异验证，改坏实现都会被对应测试抓到。

实测：真实站点逐键 2→20→202→2026-→2026-06-→2026-06-06T；
统计脚本六个场景（默认关/只填不开/开+URL/后台与登录页不挂/危险输入/关掉恢复）全部符合预期。
全量 internal/web 204 例 0 skip，其余包全绿，gofmt 干净。
 2026-10-08 18:27:59 +08:00
tamakyi 5c7cf1a0e1 对访客公开的措辞按身份分支：访客不该看到「我的结论」 
用户发现未登录也显示「推荐 & 踩雷（我的结论）」，访客没法解读「谁的我的」。
顺着把访客可见模板与 static/js 全过了一遍，同病共四处——都是**写模板时站在站长视角下笔、
而那一块又对访客公开**：

1. stats.html：标题 → {{if .IsAdmin}}我的结论{{else}}站长结论{{end}}；
   副标题「只统计你自己…」→ 站长「你自己」/ 访客「站长」；两列「我推荐/我踩雷的地点」同理。
2. stats.html 访客块：「与我的结论互不影响：你标你的，访客投访客的」——对访客说不通，
   改成对两边都成立的「与上面的站长结论互不影响：各存各的表，谁也不会覆盖谁」。
3. home.html：「我的标签」→「足迹标签」（同级卡片全是中性的：足迹地图/城市足迹/天气足迹…）。
4. report.html：「这一年里，你第一次踏足的这些城市」→ 去掉人称（年报是站长的回顾）。

已经写对的照它学：place.html 的投票区早就是 {{if .IsAdmin}} 分支（站长「我的结论」、
访客「大家怎么说」），rond-map.js 的气泡同理；「含家/工作」chip 与一串「只有你自己能看到」
本来就在站长分支里。

门禁 TestVisitorPagesUseThirdPersonCopy：以**访客 ctx（无 user）**渲染 /、/stats、/report，
逐个禁用词断言，同时断言站长那份**仍旧说「我的」**（别把站长自己的视角也改掉）；
前置需打开 marks_public（访客才看得到那一块），用完还原。

⚠️ 变异验证时踩了老坑：直接 `go test -run …` 因缺 ROND_TEST_CONF/ROND_SRC 会**静默 skip 并报 ok**
（0.17s 就 ok，一眼假绿）。改用 ./scripts/verify.sh 后变异被正确抓住
（visitor_copy_test.go:85 报「我的结论」），还原后转绿。

全量验收 PASS=339 FAIL=0 SKIP=0。
 2026-10-01 02:15:49 +08:00
tamakyi ff46a9cbb8 统计页把「我的结论」与「访客点赞」拆成两块 
用户问「数据统计处的推荐地点和踩雷地点只针对站长吗？应该分开，用户的点赞点踩单独做一块」。
他看到的没错：那张卡的**列表全是站长结论**（verdictPlaces = place_votes），访客票只在副标题里
露了个总数（👍 N · 👎 M）——既看不出哪几个地点被顶上去，也容易被当成两者合并的榜。

- 新增 votes.TopVisitorVoted：按访客票数列地点榜。HAVING 只算**至少有一票的那个方向**，
  否则 0 票的地点会把榜塞满；同票数按 visit_count DESC, p.id 排，刷新之间顺序不跳。
  票按坐标键挂，所以 join 回当前数据集的地点才定位得到（与 Tallies/verdictPlaces 同一口径）。
- 「推荐 & 踩雷（我的结论）」只讲站长，副标题只留「推荐 N · 踩雷 M」，标题与列表都改成「我」的口吻。
- 新增「访客点赞」卡：副标题总票数，两列列 👍/👎 票最多的地点并带票数，各有空态。
- 加载拆成两个 pageJob（verdicts / visitorvotes）并行，两块互不依赖就不该串着等。
- 两块共用同一个可见性开关（IsAdmin || Settings.MarksPublic），与地点页投票区一致。

用例（stats_votes_split_test.go）按卡片标题切出两段 HTML，断言「我标的地点只出现在站长块、
访客顶的地点只出现在访客块」，并核对两边各自的计数——比单看总数更能证明没串台。

⚠️ 又一次同一个坑：两张票表都按坐标键读、与数据集无关，place_visitor_votes 还没有 user_id、
不随删用户清理 ⇒ 上一轮跑剩的票会被算进来、票数越堆越多。新增 isolateVoteState 按 place_key
清两张表（前置 + cleanup 各一次）。

顺带订正 README：那里还写着站长结论「按 src_pk 存」，其实早就是坐标键了。
全量验收 PASS=338 FAIL=0 SKIP=0。
 2026-10-01 01:47:48 +08:00
tamakyi 4c3032cf48 防复发：把「删数据集带走站点自建数据」做成结构性门禁 + 常驻体检 
用户放弃继续救那批旧图，要求的是「别再发生同类事件」。所以不靠记性，靠结构：

1) 归属铁律（写进 schema.sql 抬头 + README 新章节）
   判断标准只有一句：**这份记录能不能从备份重新导入？**
   能（places/visits/movements/weather/activities/tags/entity_raw）⇒ 可挂
   `REFERENCES datasets(id) ON DELETE CASCADE`；
   不能（place_images/place_notes/place_votes/topics）⇒ 只留 dataset_id 当出处、**不许挂外键**。

2) 两道门禁（dataset_ownership_test.go），都做了变异验证：
   - 运行时：查 pg_constraint，凡挂 datasets 的表必须在白名单里；**反向也查**
     （白名单里的表不许被顺手摘掉，否则删数据集会留成片孤儿行）。
   - 静态：扫 schema.sql 的 CREATE TABLE。只看运行时有盲点——新建的库走 CREATE TABLE，
     开发库可能压根没跑过那次迁移。变异（把 topics 的 CASCADE 补回去）当场红。
   - 变异验证顺带发现：扫描必须先跳过 `--` 注释行，规矩的说明文字里就写着
     `REFERENCES datasets(id)`，不跳过会把自己写的文档当成违规。
   - 还发现运行时那道单独看**不够**：夹具每次跑迁移，迁移自己就把坏外键摘了，
     它永远不会在不健康的库上报警 ⇒ 补了「注入事故原样的外键再跑迁移，断言被摘掉」
     的自愈用例（并先确认变异真的生效，防假绿）。

3) 常驻体检：后台首页显示「库里 N 张 / 本地盘上 M 个 / 落单 K 个」，落单 >0 直接报警。
   事故的本质不是「删数据集」本身，而是**行与对象悄悄对不上、没人发现**，等照片看不见了才追。

自愈用例又抓出一个此前漏掉的缺口：place_notes / place_votes 上的同类外键迁移并不会摘
（原先只写了 place_images 与 topics 两句 DROP）⇒ 补成五张自建数据表全覆盖。

⚠️ 排序坑（本项目第二次踩）：摘外键那段最初放在 place_images 建表**之前**，
开发库毫无症状、**全新库起不来**（ALTER 报「关系不存在」），被
TestFreshDatabaseServesAppQueries 抓住。整段已挪到 place_images 之后，并把坑写进注释。

顺带订正「删除数据集」的二次确认文案（专题改完之后它还在说专题会一起删）。
全量验收 PASS=336 FAIL=0 SKIP=0。
 2026-10-01 01:15:04 +08:00
tamakyi 6b665b6056 图片恢复：坐标来源全部合并，认不出时说清已查过哪些来源 
真数据实测（扫描 40 个对象、只挂回 7 张）暴露了第一版的漏洞：
报错「数据集 #1 里没有编号 389 的地点」——来源能读出来，却不是上传那会儿的编号空间。

根因：srcPKCoords 是「第一个能读到的来源就返回」，而**换基线会覆盖 baselines/<id>.sqlite**，
当前那份未必是当年上传时用的编号；旧编号往往还躺在同一份底座的 .bak 留档里。
教训很直白：**「能读出数据」不等于「读对了那一版」**。

改了三处：
1. 来源全部读入合并（先读的优先）：库里 places → entity_raw 里 ZLOCATION 的整行留档
   （站点上删掉的地点，places 没了、留档可能还在）→ baselines/<id>.sqlite 及其每一份 .bak-*。
   读不动的文件跳过换下一个，不再「第一份成功就返回」。
2. 同一个编号保留多组候选坐标，逐个试到能在当前数据集里对上为止
   （站点纠过偏、或不同来源算出的坐标不一样，只认第一组会白白认不出）。
3. 认不出要能排查：理由写明「已查来源 …」与试过的坐标；提示条按**数据集归并**上报
   （「数据集 #1：31 张（编号 389、390…），已查来源 …」），不再刷「另有 31 张」；
   完整清单（前 30 条）进服务端日志。

新增用例：当前底座缺编号、换基线留档里才有（正是用户遇到的形状）⇒ 必须救得回；
以及「真的认不出」时要带出已查来源。全量验收 PASS=332 FAIL=0 SKIP=0。
 2026-10-01 00:11:04 +08:00
tamakyi 770e752a7a 图片恢复支持对象存储（R2）；专题也改成归人不归数据集 
R2 上的图怎么救：库里的行没了就只剩桶里有那些键，不列桶无从得知它们叫什么。
给 internal/media 加了 ListObjects（ListObjectsV2 + SigV4 + 自动翻页 + XML 解析）：
- 路径式访问、请求只到桶；查询串必须**先百分号编码再签名**（canonicalQuery 按原样取
  RawQuery，两边得是同一份字节，prefix 里的 / 要写成 %2F）。
- ⚠️ R2 的 API Token 默认只给对象读写，没有 s3:ListBucket 就 403。列桶失败**不让整个
  恢复失败**：本地那半照救，原因进 Warnings、页面用红色提示条显示（否则站长会以为恢复完了）。
- 候选对象 = 本地目录 ∪ 桶里 .webp（同键以本地为准）；行的 storage 按「对象实际在哪」写，
  bytes 用桶里报的 Size。另加一条 warning：挂回了却没配 s3_public_base ⇒ 行有了页面空白，
  这比「没恢复」更难懂。

专题（用户拍板「一并做」）：topics.dataset_id 同样带 CASCADE，删数据集带走专题，而专题
只存在这张表里、没有恢复来源。外键摘掉，所有查询 dataset_id → user_id（loadTopics、
topicPage、保存/删除/开关、pageBase.HasTopics）；**内容仍照当前生效数据集算**
（topicContent 不动）——变的是「这份定义归谁」。Dataset 补 UserID 供前台按属主定位
用户级数据；管理专题不再要求有生效数据集。

导出链路未改动：place_images / topics / Dataset.UserID 都不参与 .rondbackup 导出，
全量验收（含导出保真、ZRAW 夹取、编号对齐那批）PASS=331 FAIL=0 SKIP=0。
 2026-09-30 23:31:17 +08:00
tamakyi 496c992e5e 图片不再随数据集删除：加「图片挂载恢复」，place_images 摘掉外键 
用户报「之前上传的照片找不到了，应该是因为清了应用数据换基线」。查下来与 App 侧无关，
是站点自己两套口径打架：

- place_images.dataset_id 带 ON DELETE CASCADE，而读取按 place_key 坐标键、跨数据集。
- 于是删掉旧数据集时图片**行**被级联删了，**文件却留在 media 目录里**。
- 实测（本机）：datasets 只剩 155 号、place_images 0 行、盘上 4 个 .webp 好端端躺着。
  同一批附属数据里备注（17）与结论（3+1）因为早就迁到坐标键，毫发无损——只有图片倒霉。

三件事：

1) 恢复：后台首页「图片挂载恢复 → 扫描并恢复」（POST /admin/images/recover，
   internal/web/image_recovery.go）。只插行、不删文件、不看数据集，按 object_key 判重可反复点。
   认地点两处来源：数据集还在就查它的 places；数据集已删就读它留下的 baselines/<id>.sqlite
   还原「地点号 → 坐标」。对象键两种历史布局都认（<ds>/<YYYYMM>/<srcPK>-<hash>.webp 与
   <ds>/<srcPK>/<hash>.webp）；判据先看文件名有没有 `<数字>-` 前缀，再看中间目录——
   地点号也可能刚好 6 位，只看位数会认错。

2) 防复发：CREATE TABLE place_images 去掉外键 + 幂等 DROP CONSTRAINT；删图接口不再按
   dataset_id 过滤（数据集删了也得能删图）；「删除数据集」的二次确认文案改成实话。

3) 报告同类陷阱（未改）：topics 仍带 CASCADE，专题随数据集一起删且没有恢复来源。

测试踩到的坑：图片「按坐标键跨数据集读」+「按 object_key 判重」都不看数据集，用例之间会
互相污染两处——盘上文件（报「应当 2 张、实际 10 张」）与库里的行（Already:1 让兜底分支
根本没跑到，用例差点假绿）。加 isolateImageState（换空 DataDir + 按 place_key 清历史行），
并给夹具补收尾清理（外键没了必须自己清）。

新增用例 4 条；验收：./scripts/verify.sh 全量 PASS=323 FAIL=0 SKIP=0。
 2026-09-30 19:45:51 +08:00
tamakyi 52a82631da 换基线：说清「新底座里多出来的到访不会进导出包」，并把它钉成用例 
写文案时去核这条，先把一条写错的断言纠正了：导出条数本来就不等于站点条数。

tableWriter.finish() 是两段：先删「基线里有、PG 已没有」的行（known − seen），
再把「导入时进不了 PG 但留档还在」的行（w.skipped × raws）按原样补回——否则
「导入→导出」一趟会凭空少数据。实测 823 条到访的数据集导出包里是 824 条，差值正常。
（第一版成功路径用例断言「导出 == 站点」，红在 824 != 823 就是这个原因；已改成更锋利的
「换底座前后导出包里 ZVISIT 的 UUID 集合逐条一致」。）

同一段代码定下了换基线的语义：新底座里站点没有的行会被清掉（进 known 没进 seen）。
所以换一份更新的手机包**不会**把手机新记录带进导出包，要带得先走「分析差异」合并。
页面提示与 flash 文案都写明了这点，并新增用例
TestSwapBaselineDoesNotCarryRowsTheSiteDoesNotHave 钉住它（站内补一条到访 → 导成包 →
从站内删掉 → 换底座 → 断言导出里既没有那条的派生 UUID、UUID 集合也与换之前逐条一致）。

验收：./scripts/verify.sh 全量 PASS=319 FAIL=0 SKIP=0。
 2026-09-30 19:15:48 +08:00
tamakyi 6ff6f944a1 换基线：把「底座换代」做进后台（站点数据一行不动） 
导出是「底座为底 + 只覆盖托管表」，所以底座必须是手机导出的包。底座跟着数据集走，
手机重新导出后想换代，以前只能整包重新导入成新数据集（站点补录的行、主题、备注都得重收拾）。
新动作 /admin/baseline（后台首页加入口）就是给同一份数据的底座换代用的。

三道闸，顺序不能挪：
1. 重合判据：新包里的到访 UUID 与站点侧带 UUID 的到访比。一条都对不上直接拒
   （连 force 也不给过）——干跑只验结构，一份不相干的包照样导得出，但换下去站点
   每行都在新底座里认不出身份，全按新行插到最大编号之后，真机上就是「这些到访
   全变成新的」。重合率不到一半要显式确认；判据没过不当场报错了事：包已经收进
   uploads，页面给一个「我确认，强制替换」按钮，不必重传几十 MB。
2. 干跑导出：底座缺表/缺实体编号在这步挡住，不会出现「换完了才发现导不出、
   原来那份已经不知去哪」。
3. 旧底座留档 + 记档，换错了可一键回滚。

两个坑：
- 留档名不能只用秒级时间戳。「替换后紧接着回滚」落在同一秒时，回滚那次 rename 会把
  刚生成的留档覆盖掉，于是回滚回了个寂寞（TestRollbackBaselineRestoresPrevious 当场红）。
  改用 baselineBackupName()：20060102-150405 + 冲突自增。
- ensureBaseline 必须先看记档。只认 datasets.sha256（= 最初那份包）的话，底座一丢就静默
  重建回旧包，上一次换基线白做且毫无提示。抽出 ensureBaselineTo(ctx, dsID, dst) 共用；
  「重建」入口写临时文件再 rename，不做破坏性删除。

回归用例 7 条（internal/web/baseline_swap_test.go）：成功路径断言「换底座前后导出包里
ZVISIT 的 UUID 集合逐条一致」——编号会换、身份不该换，谁在底座里没对上立刻亮；
记档优先重建带反证（清掉记档后同一条路必须走不通）；部分重合需确认、完全对不上 force
也不给过、非包文件第一步就挡住、回滚还原且当前那份也留档、页面渲染到底。

验收：./scripts/verify.sh 全量 PASS=318 FAIL=0 SKIP=0。
 2026-09-30 19:00:18 +08:00
tamakyi 11e00a5b60 记忆：记下本次抽出的跨项目技能 workbuddy-memory-versioning 2026-09-30 18:32:14 +08:00
tamakyi 3f1b737a78 记忆：把 .workbuddy/memory 纳入版本控制 
用户要求这份记忆跟着仓库走，而不是只留在本机。

.gitignore 里挡路的是 `.workbuddy/`。改成反忽略六行，并且**只放行 .md**：
别用 `!.workbuddy/memory/**`——它会把 memory 下任何文件都放行，本项目真发生过
`web.test.exe` 混进暂存。复核用 `git check-ignore -q --no-index` 逐条打靶：
memory/*.png、memory/sub/x.md、memory/MEMORY.md.bak、plans/a.md 全 IGNORED，
17 个 .md 全 included；`git add -An .workbuddy/` 恰好 16 个文件。
其余 .workbuddy 内容（计划、本地设置、临时产物）继续忽略。记忆里没有真凭据
（唯一命中是 2026-09-14.md 里的 `password=rond-admin`，那是项目默认口令）。

顺带做两件整理：

1. 取证了注入上限。以前按「字节数」判断 MEMORY.md 是否超限是错的：
   WorkBuddy 的 `getWorkingMemoryContent()` 用 `MAX_MEMORY_CHARS = 1e4` 比 JS
   `content.length`，即**字符数**（中文 1 字算 1）；超了 substring 截断、尾部静默丢失。
   本 details 与每日日志都不参与注入，只有 MEMORY.md 受约束。
   现已从 6604 字符收到上限的 66%，并把这条上限写进索引抬头。
2. 把「备份合并」「导出/恢复三条铁律」两段长文迁进 MEMORY-details.md 的卅一/卅二节，
   索引只留关键词指针。行尾统一为 LF（仓库 .gitattributes 是 `* text=auto eol=lf`）。
 2026-09-30 18:31:08 +08:00
tamakyi d99c63fa4f 导出：把 ZVISIT.ZRAW 夹到包内采样行数以内（越界会让真机整包拒收） 
ZVISIT.ZRAW 是「这次到访由多少个原始采样点归并而来」的缓存计数，而采样点表 ZRAWVISIT 是
**不托管实体**（只从基线原样带过来）。合并进来的到访带着源包的计数、源包的那些采样行站点
没留下 ⇒ 计数会超过包里实际有的采样行数。

2026-09-30 逐行二分定位：生产导出被真机拒收（「备份恢复失败，你的当前数据未被修改」），
罪魁是单条 `ZVISIT #1000`——它声称 2305 个采样点，而包里只有 2246 行 ZRAWVISIT；
把这一列改成 1421 后同一份包立刻能导入。旁证：被真机接受过的三份包（09-14 基线、
09-20 A 包、验收纯净往返包）的 ZRAW 最大值都恰好 ≤ 采样行数，而它们 ZRAW 为 NULL/0 的行
本来就有 39~139 条 ⇒ 往下夹是安全的、夹取只降不升。

顺带：`readDupBaseline` 先 os.Stat 再开库——sql.Open 默认 READWRITE|CREATE，路径不存在时
会静默建一个空库，报出来的是「no such table」而不是「没有基线」，很难查。

用例 `TestExportClampsRawSampleCount`：造一条声称 999999 个采样点的到访，导出后断言
「任何一行的 ZRAW 都不超过包内采样行数」且该行仍在（只改计数、不丢记录）；变异验证：
关掉夹取立刻红。
 2026-09-30 17:35:59 +08:00
tamakyi 9e112d55f9 工具：tools/bisect_export.py —— 把被真机拒收的导出包做行级二分 
生产导出被拒（「备份恢复失败，你的当前数据未被修改」），但同一台设备导入「纯净往返包」成功
⇒ 导出链路与 App 都没问题，问题在数据集的数据里。静态把技能里记的全部判据都查了一遍
（打包层位标志、Core Data 骨架逐字节、逐列空值画像、关系完整性、类型分布、Z_OPT/UUID/BLOB、
行级时间不变量、取值域与数值范围、SQLite 文件头）——一处违规都没有，只能靠真机二分。

脚本以被拒的包为底生成三个对照包（都清了悬空引用、按 zip.Store 带长度与 CRC 重新打包）：
  V1 去掉站内新建的到访；V2 = V1 + 去掉站内新建的地点；V3 手机里也有的行按手机原值重置。
README 与记忆里记了怎么读这三个结果（哪一版开始能进，问题就在上一版删/改掉的那一类里）。
 2026-09-30 16:59:00 +08:00
tamakyi 0e670aa1cf 文档：补「重复到访」两类成因（站点侧副本 / 补录行被合并回来） 2026-09-30 16:58:59 +08:00
tamakyi c9ebb3aebd 修性能回归：把「已并入 / 子段」判据做成派生列（visits.is_merged） 
昨天给「已并入 / 子段」做的收口写成每行去 entity_raw 判
`raw->>'ZMERGEDTO' IS NOT NULL OR raw->>'ZPARENT' IS NOT NULL`，而 entity_raw.raw 是
**TOAST 过的整行 Core Data JSON**：一次探针要取回并解析整行。地点库「每个地点 × 5 个子查询」
的量级下 —— 实测 /places 70.1 秒、首页 43.6 秒才出页面（而库里没有任何一条 SQL 超过 1 秒：
时间全花在成千上万次「取整行再解析」上，进程 CPU 只用了 3s/135s）。

这批「渲染若干页面」的布局用例因此从 20 秒涨到 226~309 秒，整套验收从 6 分钟变 20+ 分钟。

- schema.sql：加派生列 visits.is_merged + 回填 + 给回填用的部分索引
  （只索引确实带合并标记的那几十行，不用取回 raw）。
- stats.SoloVisitSQL 改成读这一列（判据仍然只此一份，读侧全部经由它）。
- 写入侧跟着刷：ingest 在 insertEntityRaw 之后、backup_merge 的 recountPlaces 里，
  共用 stats.RefreshMergedFlagsSQL。
- 直接改留档里的合并标记（工具脚本 / 用例）之后也要刷一次，schema.sql 与函数注释都写明了。

实测：/places 70084ms → 206ms，/ 43633ms → 698ms（比「关掉判据」的对照还快）。
新增 page_render_budget_test.go：给 7 个关键页卡 10 秒上限的灾难探测器
（功能全对、只是慢的那种退化，之前没有任何用例会红）。
 2026-09-30 16:18:52 +08:00
tamakyi 5b8699a03a 重复到访：第二类（补录行被合并回来）不依赖基线，基线不可用时也照样能清 
「补录行被合并回来」这一类的判据全在站点自己这边（派生 UUID 命中），本来不需要基线；
但原先的实现在读基线之前就 return 了，于是基线缺失 / 对不上的数据集连这一类都清不了。
现在先判第二类，基线的可用性检查只挡住第一类（站点侧副本），不可用时把说明补在卡片里
（有第二类就列出来 + 一行说明，没有就只给说明）。

模板相应合并成一个卡片：标题带对数、说明行只在有对时出现、判不了第一类时补一行灰字。
 2026-09-30 15:19:42 +08:00
tamakyi aaf65f654a 格式：补回 diff_test.go 里被并掉的换行（gofmt） 2026-09-30 15:03:20 +08:00
tamakyi 8dec973db1 修「补录行被合并回来」的重复：对账时认它的派生 UUID 
成因链：站点补录的到访没有留档行（entity_raw 里没有它），也就没有 UUID；导出时会被补上
一个确定性 UUID v5("ZVISIT/<src_pk>") 写进包里，手机于是把它当成一条真记录；这份包再
合并回站点时，站点这侧没有 UUID 可对齐，DiffVisits 直接判成「备份新增」又插一条 ——
时间线上出现两条一模一样的到访（实测数据集 9 有 43 对，生产时间线一屏就有 53 对）。

- rond：把派生 UUID 抽成 DerivedUUID / DerivedVisitUUID / VisitMatchUUID（导出侧 coreDataUUID
  复用同一个函数），差异与合并都拿它当对账键（diff.go 的 byUUID、backup_merge 的 storedByUUID）。
- 「时间 + 地点」兜底配对补 used 检查：同一条站点行现在两个索引里都有，不查会被 classify 两次。
- 数据编辑页的「重复到访」卡片认得这类（成因标「你补录的那条被合并回来的一份」），
  清理时把副本名下的位移 / 天气**改挂**到保留项——补录行自己名下没有位移，跟着删就白丢里程；
  派生 UUID 判定排在「站点侧副本」之前（证据更强）。

用例：rond 两条（正例 + 派生 UUID 不相配的反例）、web 一条端到端（造补录行与副本 → 检出 →
清理 → 断言位移与天气改挂、留档被清）。变异验证：去掉改挂语义、关掉该判定，两条都立刻红。
 2026-09-30 15:02:45 +08:00
tamakyi 881f2933ff 收尾：验收脚本自动清死元组、城市圈首末到访按可见到访算、补使用说明 
verify.sh：测试库 ≥ VACUUM_MIN_MB（默认 200MB）时先 VACUUM (ANALYZE)——一轮全量会留几百 MB
死元组，级联删除随之变慢（同一夹具用例实测 13.6s → 10.2s）。只用普通 VACUUM：FULL 要
ACCESS EXCLUSIVE 锁，有别的服务连着测试库时会把验收整段卡住。

/api/cities 的首末到访改成按可见到访的到达时间算（内层 min/max(v.arrival)），不再取
places.first/last_visit_at——那两列是全量的，会被已并入 / 子段的到访推早推晚。

README 补两节：「数据编辑页上的重复到访」（判定口径与清理范围）、「为什么有些到访在页面上看不到」
（已并入 / 子段不计入显示与统计，但导出必须原样带着），并在开发提示里记下验收环境的死元组与
is_active 两个坑。

回归：city_agg_test.go 补了一段能区分的断言——把某地点最晚那次到访标成已并入后，城市最近到访
必须从 09-13 退到 09-08（原先只比对同口径时，两种算法在夹具数据上结果一样，是条假绿的断言）。
 2026-09-29 23:49:39 +08:00
tamakyi 3d03aae018 修地图城市圈的聚合口径：先按地点汇总，再按城市汇总 
/api/cities 原来把聚合打在 places ⋈ visits 上：一个地点有 N 条到访，它的 visit_count 与
dwell_minutes 就被累加 N 次，count(*) 数出来的到访条数又被当成「地点数」显示——实测最大的
那个城市气泡写着「到访 72661 次 · 568 个地点」，真值是 568 次 / 86 个地点（差 128 倍）。
改成内层按地点 GROUP BY、外层按城市 sum/count，并补上「已并入 / 子段不算数」的判据，
圈的位置、排序与返回列序都不变。

回归 city_agg_test.go：手写同口径 SQL 对账 + 「地点数不可能多于到访数」的不变量；
变异验证（sum(pa.visits) *2）立刻红。
 2026-09-29 22:07:23 +08:00
tamakyi 4597047989 口径：已并入 / 子段的到访不再计入时间线与统计（导出侧一个字节不动） 
真机里两行到访可能「不独立成立」：ZMERGEDTO 指向它被并入的那条、ZPARENT 说明它只是某个
父段的一部分。app 对这两种行既不显示也不计数，本站以前当成普通到访 ⇒ 时间线上出现
「同一时刻同一地点两条」、日停留重复计入（实测数据集 9 有 64 条，26 条到达时间与原件相同）。
这些行**不能删**——导出要靠它们认这次合并发生过，所以判据只立一份 stats.SoloVisitSQL，
在读的一侧收口：visitsWhere / VisitsByPlace / Bookmarked / placeCols 子查询、首次到达城市、
地图极值点、专题（详情 + 列表批量）、三处聚合的 visit_count 与 dwell_minutes，
外加 schema.sql 一段幂等回填把存量库拉正。

天气与位移**不收口**（那几小时、那段路真实发生过）；导出侧一个字节不动（rond 只读
places.last_visit_at，保持全量，压根不读 visit_count / dwell_minutes）。编辑页照样列出
这些行，但打上「已并入 #562 / 子段 #374」，免得以为数据丢了。

顺带修两个自测抓出来的问题：
- ingest 的地点聚合回填排在 insertEntityRaw 之前 ⇒ 判据读到空留档 ⇒ 每行都算独立到访
  （整整多算一个「已并入」的量）。
- 收口后 last_visit_at 保持全量，会凑出「0 次却有最近到访」（数据集 9 有 4 个地点），
  展示侧按可见到访数兜住。

验收：304 PASS / 0 FAIL / 0 SKIP（新增 3 个用例：标记后导出仍带该行、存量回填拉正、
判据只出现在读侧）。
 2026-09-29 21:15:25 +08:00
tamakyi 152af81f6a 编辑页：新增「重复到访」卡片 —— 以基线（手机包）为参照清掉站点侧的历史副本 
站点库里有一批「到达时间 + 地点与手机包里某条完全相同、但 UUID 不同」的到访副本，
合并/差异按 UUID 认人会把它们当成备份新增，导出到 rond 就成了成对的两条重复记录。
判定与 tools/dedup_site_visits.py 同一套语义：UUID 是前提（只按时间+地点判会误删手机包
自身合法的成对条目）；基线跟本站一条都对不上时只给说明、不给按钮。清理在单事务里删
副本 + 其位移/天气/留档，并把指向副本的 ZMERGEDTO/ZPARENT 改指到保留项——只动本来
就有的那个键，工具那版会凭空补出一个 ZMERGEDTO（真机里是「已并入别处」，会白丢记录）。

顺带修一个「一补录天气就整包导出失败」的洞：rond 导出把 weather.is_daylight 扫进裸 bool，
而站点「新增天气」不写这一列 ⇒ NULL ⇒ sql.Scan 报错。改成 COALESCE(is_daylight,false)，
与导入侧读真机包同口径。

验收：301 PASS / 0 FAIL / 0 SKIP（新增 4 个用例，含变异验证：去掉 UUID 前提/改回
create_if_missing=true/不删副本位移，三种改法都被用例抓到）。
 2026-09-29 19:17:29 +08:00
tamakyi 40441ba900 工具：tools/dedup_site_visits.py —— 以手机包为参照清掉站点侧的历史重复到访 
站点数据里有一批「到达时间 + 地点与手机包里某条完全相同、但 UUID 不同」的到访副本（站点侧生成的
UUID）。差异页/合并按 UUID 认人，于是它们被当成「备份新增」，导出到 rond 后就是成对的两条重复记录
（2026-09-29 站长实测：导入后 app 里出现成对的重复条目）。

工具以手机导出的包为参照（数据集的基线）：
  * 站点到访的 UUID 在参照里能找到 → 保留（手机自己也有成对条目，那是合法的，不能动）
  * UUID 找不到、且 (到达时间, 地点) 与参照里某条一致 → 判为副本
副本的附属记录（位移/天气/留档）一并删除；若有别的到访的留档指向副本（ZMERGEDTO / ZPARENT），
改指到保留的那条，避免导出时留下悬空引用。**默认只预演，--apply 才动手。**

踩坑记录（都在此提交里修掉）：
  * `raw->>` 取出的是 text，与数字比较会报「text = integer 操作符不存在」，导致工具在动手前整个退出；
  * 同一个 UPDATE 里不能给 raw 赋两次值（「对同一列 raw 进行了多次分配」），jsonb_set 要嵌套。

演练验证（本地真实数据：导入含 72 条副本的包 → 执行 → 核对）：
  到访 1026 → 954、位移 833 → 809、天气 621 → 589（与手机包一致）；
  「同时间同地点」重复组 101 → **31**（= 手机包自身）、悬空引用 0/0。
 2026-09-29 17:38:50 +08:00
tamakyi d5a011259d 导出：按身份把编号对齐到基线（app 只能靠编号解引用地点/活动，编号漂移就「看不到数据」） 
背景：Core Data 里**地点与活动没有 UUID**，app 只能靠 Z_PK 解引用（ZVISIT.ZLOCATION /
ZVISIT.ZACTIVITY_）。站点这边的 src_pk 是从「导入→导出」循环里滚出来的，与手机 store 的 Z_PK
不是一套。2026-09-29 实测（真机 09-28 包 vs 站点导出，按到访 UUID 对齐）：地点引用 920/920 不同、
活动引用 903/920 不同，而引用到的地点按「名称+坐标」完全一致——语义相同、编号不同。结果就是
「导入成功但看不到数据」（每条到访都指到手机那边的别的地点/活动或不存在的行）。

做法（新增 internal/rond/export_align.go）：导出的每张托管表**先按身份建映射**，再按映射后的编号写：
  地点：坐标键优先（多值索引），退到「同名且相距 ≤1km」
  活动/到访：UUID（读留档 entity_raw 里的 ZUID_ / ZIDENTIFIER_）
  标签/交通方式：名称；位移/天气：所属到访（已对齐）
基线里没有身份对应的行 → 取基线最大编号之上的新号；而**身份匹配不上、原编号又没被别的身份占用的行
保持原编号**（这样「基线就是源包」的往返导出一行都不动；被占用时才另取号，避免覆盖基线的别的记录）。

配套改动：引用全部改挂（含自引用 ZMERGEDTO / ZPARENT，它们原本从留档原样带出、对齐后会指错或悬空，
已加入托管列并按映射写回）；Z_PRIMARYKEY.Z_MAX 改用实际写入的编号；基线身份查询都 ORDER BY Z_PK 保证
确定性；siteUUIDMap 改成读 base64 后在 Go 里解码（与 web 侧 loadStoredVisits 同一手法）。

验证：
- 真实数据（本地数据集 + 真机 09-28 当基线）：按 UUID 对齐的 953 条共同到访里地点引用一致 933、
  活动一致 951（改前 0 / 7），悬空引用 0；余下 20 条是基线自己重名重复行的归属歧义。
- 用例 TestExportAlignsPKsToBaseline：把库内编号整体平移 500000 再导出，断言按 UUID 对齐后**地点/
  活动的编号**与基线一致率 ≥95% + 7 类引用无悬空 ⇒ 822/822。⚠️ 第一版只比「名称+坐标」，变异验证
  不会变红（编号不一致时引用依然自洽），必须比编号本身。
- 往返不变量 TestExportRoundtrip 通过（「匹配不上则保持原编号」这条规则就是为它加的：之前唯一的
  未匹配行是那条没有 UUID 的「全空到访」，被改号成 825 才暴露出来）。
- 全量验收 297 PASS / 0 FAIL / 0 SKIP。

注意：对齐的目标是**这份数据集的基线**。要让导出与手机编号一致，数据集的基线就得是手机包
（把手机导出作为新数据集上传、再把旧站点导出包合并进去，然后从它导出）。
 2026-09-29 16:57:29 +08:00
tamakyi d5e96edbea 导出：撤销「给 ZISOCOUNTRYCODE 补空串」——实测空串会让真机拒绝整包 
真机对照实验（同一份内容、同一台设备，唯一差异是这一列）：

  国家码 = ''   → 备份恢复失败
  国家码 = NULL → **能导入**

也就是说我 2026-09-29 早些时候那个「按真机形状补空串」的改动是有害的回归：真机包里的确有 19 行是 ''，
但**导入侧不接受**它（真机自己写出来的形状不代表它能吃回去）。恢复成按站点当前值原样写（新建地点没有
这一项 → NULL），与「被真机接受过的 A 包」一致。

教训记进注释：这一列不要做任何「形状美化」，保持 NULL。
 2026-09-29 15:18:28 +08:00
tamakyi f98d3864b8 导出：zip 用 CreateRaw 写长度/CRC，别再带 data descriptor（真机判整包损坏） 
真正的病根（09-16 起每一份站点导出都被拒都是它）：Go 的 zip.Writer 默认走流式写入——本地头里
的长度与 CRC 留 0、真值挪到条目尾部的数据描述符里，并在 flag 里置 bit3。**真机的读取器只认
「本地头里就写着长度」的条目**，遇到这种包直接判成损坏，报「备份恢复失败，你的当前数据未被更改」。

铁证（直接读文件头）：
  站点 Go 写的每一份导出        本地头 flags=0x0008  csize/usize=0/0   → 全部被拒
  20260920-fixed-A-数据修复    本地头 flags=0x0000  有长度             → 真机接受（Python 重打包）
  真机自己的包                 本地头 flags=0x0800  有长度             → 正常（只有 UTF-8 位）

这也解释了之前为什么全都修错了方向：09-20 那次「修悬空引用后就能导入」其实是 Python 重打包顺手把
zip 写法修对了；而 09-29 一整天修的内容问题（活动颜色为 NULL、交通方式重名）都不是拦路虎。

修复：zipBackup 改用 zw.CreateRaw，先把三个文件读进内存算出 CRC32 与长度写进本地头，
不再用会置 bit3 的 zw.CreateHeader。

用例：TestZipBackupWritesNoDataDescriptor —— 直接读第 0 个条目的**本地头**，断言 bit3 为 0、
压缩/原始长度非 0、CRC 正确（变异验证：改回 CreateHeader → 立刻变红，且精确复现 0x0008 + 长度 0）。
真实数据验证：修复后新导出的本地头 flags=0x0000、长度正确。

全量验收 296 PASS / 0 FAIL / 0 SKIP。
 2026-09-29 15:04:07 +08:00
tamakyi 9c1413bb39 导出/合并：交通方式编号空间串了，导出会吐出两条同名方式（真机整包拒收） 
继上一轮修「活动颜色为 NULL」之后，生产重新导出 `data/20260929.rondbackup` 依旧导不回 rond。
这次拿**最后一次被真机接受的包**（20260920-fixed-A-数据修复）当参照逐项比对：SQLite 头、31 表 /
47 索引 / 建表语句 / 列定义、`Z_METADATA.Z_PLIST` 与 `Z_MODELCACHE`（逐字节）、值类型分布、文本合法
字节、BLOB 长度、UUID 唯一性、关系完整性、`Z_OPT`、行级时间不变量——全部一致；唯一差异是
**`ZTRANSPORT` 里出现了两条同名「公交」（Z_PK 2 与 4），而真机与可导入的 A 包都只有一条**。

根因：`mergeVisits` 把实机的 `ZTRANSPORT` 编号原样写进 `movements.transport_src`。站点没有交通方式表，
方式只活在位移的 transport_* 四列里，两套编号空间同一个数字含义不同（实测 src=4：站点=电🐔、实机=公交，
src 3/5/6 同样撞车）。于是同一个 src 带上两种含义：导出按 src 聚合只能取一个名字 → 另一种含义的位移挂错
方式；更糟的是吐出两条同名方式，真机那边是模型唯一约束级别的违规 → 整包拒收。

修复两处：
1. 合并侧 `mergeVisits`：按名称把实机方式归一到站点编号（新增 `(*Server).transportsByName`：同名沿用
   站点已有的编号，没有才 `nextSrcPK(transportSeq)` 新发一个）。
2. 导出侧 `queryTransports`：改为按**名称**归组（名称就是身份），用量最多的名称优先认领编号，其余编号的
   位移改挂到它上面；并清掉「基线里同名但编号已被归并掉」的旧行——`keepMissing` 会把它原样带回，于是又是
   两条同名。这段清理必须排在所有托管表写完之后，否则兜底判据看到的还是基线里未重写的 ZMOVEMENT。

真实数据效果（本地库，与生产同一形状）：方式恢复成站点原本那套 1火车/2公交/3高铁/4电🐔/5地铁/6步行、
无重名；位移各挂回自己的方式（电🐔 336、地铁 25、高铁 23、公交 19、火车 9、步行 3——修复前只有 6 条能对上）。

用例：`TestExportMergesDuplicateTransportNames`（同名归并 + 位移挂回自己那条 + 无悬空引用）、
`TestMergeKeepsTransportNumberingConsistent`（合并后同一 transport_src 不许有两种名称，附「位移确实被补
回来了」的哨兵断言避免写成空用例）。三处都做了变异验证：去掉改挂 / 去掉旧行清理 / 合并照抄实机编号 →
对应用例分别变红。

全量验收 295 PASS / 0 FAIL / 0 SKIP。
 2026-09-29 13:25:50 +08:00
tamakyi f26537b1e9 导出：新建活动没选颜色时补占位色，别再写 ZCOLOR_=NULL（真机拒收整包） 
症状：生产导出的包导不回 rond，提示「错误，备份恢复失败，你的当前数据未被更改」。

根因链：站内「地点补全」新建活动时写的是 color=''、icon=''（fillup.go 的 INSERT），而导出侧
ns() 把空串也当空（返回 nil）——图标那侧早就有 📍 兜底（注释还写着「站点自己渲染时缺省用 📍」），
颜色这侧漏了，于是写出 ZACTIVITY.ZCOLOR_ = NULL。真机这一列在任何包里都是 0 NULL/0 空串
（扫了 data/ 与 storage/ 下全部 15 个包，只有出事的那份有 1 个空），Core Data 拿到非可选属性上的
NULL 会判成损坏数据 → 整包拒收。

修复：加 activityPlaceholderColor = "gray"（与 transportPlaceholderColor 同一套写法），
活动颜色为空时兜底。

用例：TestExportNeverNullsColumnsTheDeviceAlwaysFills 补上「没选颜色的活动」场景——它守的通用
不变量是「基线里 0 个 NULL 的列，导出新行也不许 NULL」，但此前只造过交通方式，没覆盖活动。
变异验证：去掉兜底 → 两条断言都红（提示语正好复刻生产现象）。

另新增 tools/audit_export_nulls.py：拿参照包做逐列空值画像 + 全部关系列悬空 + Z_MAX 检查，
是排查「导出被拒收」最快的一步（这次就是它一击命中的）。注意判据必须是「参照里 0 个 NULL」——
ZLOCATION.ZISOCOUNTRYCODE 真机自己就漏过 1 个 NULL，说明它容忍 NULL，不要当违规去修。

全量验收 293 PASS / 0 FAIL / 0 SKIP。
 2026-09-29 11:50:06 +08:00
tamakyi 8763b850be 合并：地点配对只留一份实现（rond.MatchPlaces），合并侧不再自己配一遍 
- 抽出 rond.MatchPlaces(stored, backup) PlaceMatch：坐标优先、退到「同名且相距 ≤1km」、
  多值索引 + 认领即标记已用；DiffPlaces 与 web.mergePlaces 共用它。
- mergePlaces 原来是单槽位 byCoord/byName 自己再配一遍：同坐标/同名的多条备份地点全并到同一行
  站内地点，到访被挂到错的分店（实测「茶颜悦色」两家分店相隔 8.3km，到访却指着同一条）。
  现在直接用配对结果，再叠加 plan.AddPlaces 的新插入。
- loadStoredPlaces 与 mergePlaces 的地点查询都加 ORDER BY id：候选多于一个时靠顺序定谁配谁，
  两侧必须一致，否则配对会飘。
- 删掉只写不读的 PlacePatch.CoordKey、ActivityPatch.Key（容易被误当成查找键）。
- 用例：TestMatchPlacesKeepsDuplicateNameGroupsDistinct（同一坐标/邻近同名都要一条配一条）、
  TestMergePlacesMapsSameNameLocationsOneToOne（真库 + 真事务，两条同名备份地点必须映射到两条不同
  地点）；两处都做了变异验证（认领不标记已用 / 恢复单槽位映射 → 对应用例变红）。
- 探针库复测（从 dump 恢复、不动本地真库，49 组冲突全「用实机」）：到访挂错地点（>1km）0/953 条、
  地点被搬动 >1km 0 个；合并后再比对三类全 0（到访 0/47/0、地点 0/4/0、活动 0/0/0），
  再点合并「按当前的选择没有要写入的改动」。全量验收 293 PASS / 0 FAIL / 0 SKIP。

已知取舍：勾「用实机」但没勾「并进来」时，若该到访在实机上的地点站内没有、且按 1km 规则也配不上，
place_id 会被置空（旧行为是挂到一条远方的同名地点上——那正是这次要去掉的错配）。
 2026-09-29 10:46:54 +08:00
tamakyi 370c4285f8 合并：按名称兜底配对加 1km 上限，冲突行在名称相同时把坐标印出来 
- DiffPlaces 的 takeByName 只在两点相距 ≤1km 时才认领：名称不是唯一键，连锁店同名是常态
  （真机里「中国体育彩票」3 条、「长沙南站」2 条、「茶颜悦色」2 条）。没有上限时，坐标配不上
  的两条同名地点会被强行配成一对——实测把佛山的「中国体育彩票」配给了贺州那条（直线 236.8km），
  站长勾「用实机」就把站内那条地点的坐标搬到另一座城市（实测 src_pk=71 从贺州搬到佛山）。
  注意 geo.Haversine 返回的是公里，常量按公里写。
- visitFieldChanges 的「地点」在两边名称相同时用 coordSuffix 把坐标印出来：这一项比的是坐标，
  只印名称会渲染成「X → X」，站长看不出差在哪（连锁店重名、同一地点两边坐标略有出入都会走到这里）。
- 新增用例 3 条（相隔 236.8km 不该配对、665m 仍要配对、名称相同时必须带坐标）+ 变异验证。
- 复测（回滚后按浏览器默认全选「用实机」重跑）：被搬动超过 1km 的地点从 1 个变 0 个；
  合并后再比对 到访 0/47/1、地点 0/4/1、活动 0/0/0；953 条 UUID 到访全命中、到达时间 0 偏差。
 2026-09-29 10:18:22 +08:00
tamakyi 10d23e03cf 合并：重复地点不再反复判「备份新增」，到访的活动改按身份比 
- DiffPlaces 的 byCoord/byName 改为多值索引 + take() 逐条认领未用项：真机一个坐标下会有
  多条同名同坐标的地点（实测「柳州站」3 条），单槽位时同一坐标最多只配上 2 条，第 3 条
  永远判「备份新增」⇒ 每次合并都再插一条重复地点、差异永远归不了零（实测 368→438→439）。
  修完：地点新增 70→67、合并后再比对归零、再点合并直接「没有要写入的改动」。
- 到访的「活动」由按名称比改为按身份（ZUID_）比，两边都缺 UUID 才退回名称：16 个活动改名
  曾把 355 条到访全变成同因冲突，且逐条选「用实机」只写回 activity_id（映射回同一个活动）
  改不掉名字。loadStoredVisits 为此多 JOIN 一次 entity_raw 取 ZACTIVITY.ZUID_。
- 回归用例 4 条（重复地点一一配上、活动改名不算冲突、换活动仍要报、缺 UUID 退回名称）+
  「合并后地点差异归零」断言 3 处；两处改动都做过变异验证。
- 实测（09-28 备份并进 09-14 数据集）：到访冲突 253→6，合并两次地点数 438→439 变为 435→435。
 2026-09-28 19:31:21 +08:00