 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 |
|