docs(memory): 记录第二批修复与「Python write_text 会改行尾」这个坑

- 2026-10-29.md：第二批 9 项改动与验证数据（含投票结果 2 万条 0.211s→0.023s），
  以及剩余待办清单（级联删除事务、配额漂移、JSON-LD/RSS、箱主数据面板等）
- MEMORY.md：构建测试段补 write_text 行尾陷阱与排查手法（看 git diff --stat / git show），
  其它约定段补 /healthz 与 /readyz 的语义边界（存活探针不查依赖）
- topics/quality.md：标注第二批已完成的范围

附带说明：本轮我自己也踩了 write_text 的坑，把 14 个 LF 文件写成了 CRLF，
靠 git diff --stat 的「整文件重写」发现、再用 git show HEAD:<file> 的行尾比对恢复。

.workbuddy/memory/MEMORY.md

@@ -24,6 +24,11 @@
   `[recaptcha] captcha_type = math`、Windows 侧 127.0.0.1:5877 被占要用 WSL eth0 IP。
   HTTP 端到端与 P1-3 的双路径 A/B 都能在这里做（回环=可信、跨主机=不可信）。
 - python urllib 不稳定（用 curl）；python 别用 `/tmp`；PIL 在 `~/.workbuddy/binaries/python/envs/default`。
+- **Windows 上 `Path.write_text()` 默认把 `\n` 写成 `\r\n`** —— 改 LF 文件必须传 `newline="\n"`
+  或走 bytes，否则整个文件行尾翻车。症状：`gofmt -l` 突然把整文件标为未格式化。
+  **排查看 `git diff --stat`**：真实改动应是几十行，整文件重写就是行尾变了；
+  恢复用 `git show HEAD:<file>` 取其行尾再统一替换。
+  另：本项目 `core.autocrlf=true`，仓库存 LF、工作区 checkout 成 CRLF —— 判断基准要看 `git show`。
 
 ## 行尾 / 模板 / embed（topics/embed.md）
 
@@ -86,6 +91,8 @@
 
 ## 其它约定（topics/misc.md）
 
+- 健康检查：`/healthz` 永远 200（不碰任何依赖，只看进程活着）+ `/readyz` 查 DB（失败 503）。
+  别把 DB 检查并进 healthz —— 数据库抖动会让进程被反复重启，对恢复毫无帮助。
 - 校验用 `valid:"required;maxlen:N"` 标签。
 - 只有箱主 `/user` 面板，**无管理员角色、无站方后台**（用户要求不要加）：站方动作只走 CLI / 邮件 / 改配置重启。
 - CLI 有两个构建入口必须同步：根 `go build .` 与 Dockerfile 的 `./cmd/`。