restrict v7

.workbuddy/memory/2026-10-18.md

@@ -274,3 +274,51 @@ admin6 当前处于 L2（到期次日），必要时 `unrestrict` 解除。
 （项目自带模板语法检查工具，改模板后必跑）。
 
 未做：箱主列表的「只看被举报」筛选（目前只有 badge）；举报驳回/成立的处置动作（目前 status 只有 pending）。
+
+### 举报链线上验证：4/4 通过
+
+- 入口：单题页 `/73` 出现「举报这条内容」+ form action `/_/admin6/73/report`；
+- 首次举报：POST 302 → flash「已收到举报，感谢反馈」；
+- 同 IP 重复：同样 302 + 同样文案，无失败提示（幂等）；
+- 箱主 `/user/questions`：出现「被举报 **1** 次」（多次重复提交后计数仍为 1，反证幂等生效）。
+
+**过程教训**：中途 python urllib 报「读超时 25s」，一度怀疑服务端挂起。实测 curl 同一接口
+1.6~1.7s 正常返回 302，`location=/_/admin6/73`，手动 GET 也 200。真因是 python 走本地代理
+（`https_proxy=127.0.0.1:54881`）偶发挂起 + `/tmp` 路径在 Windows python 与 MSYS 之间不互通。
+已写进 MEMORY.md：**验证线上行为优先用 curl**。
+
+### 告警触发验证（进行中）
+
+直接 SQL INSERT 不会触发告警（`notifyAbuseIfNeeded` 只在 HTTP 举报 `created=true` 时调用）。
+正确姿势：SQL 补到 7 条 → 删掉自己那条旧记录 → 再用 HTTP 提交一次，使 count 恰好到 8。
+已按此执行（curl 提交返回 302 + 「已收到举报」），等待确认日志
+`Abuse alert mail sent` / `Failed to send abuse alert mail` / 什么都没有（= `security_alert_email` 为空）。
+
+### 邮件告警验证通过
+
+配置 `security_alert_email` + 重启后，补到 7 条再 HTTP 提交第 8 条，邮件成功收到；测试数据已清理。
+举报链至此全部闭环。
+
+### 静默丢失专项清理（用户要求的那项）
+
+静态扫描 `route/**/*.go`：flash 调用后第一个 `Success(`/`Redirect(` 判定，共 **9 处**缺陷
+（`follow_up.go` 2、`page.go` 1、`question.go` 1、`profile.go` 5），全部改为
+`SetError(err[, f])` / `SetInternalError()`。`Set*Flash + Redirect` 112 处正常，未动；
+`vote.go:702/704` 是扫描误报（其后 switch 之后才是 Redirect）。
+`go build ./...` EXIT=0；`go test ./internal/db/ ./internal/i18n/` 全绿（36s）。
+⚠️ 这 9 处只做了编译与静态验证，未逐条构造触发条件（需传超大图/失效追问 id），
+部署后实际遇到对应错误时观察提示是否可见。
+
+### 举报加验证码 + 箱主列表「只看被举报」筛选
+
+- 举报验证码：`form.ReportQuestion` 加 `Recaptcha`（**刻意不加 valid:required**，空值交给
+  `captcha.Verify` 判定，否则 Bind 失败会被统一提示成「请选择一个举报理由」）；
+  `Report` handler 签名加 `recaptcha recaptcha.RecaptchaV3`，调 `captcha.Verify`（与提问/私聊同源）。
+  模板按 `CaptchaType == "math"` 双分支：math 用隐藏域 + `.math-captcha-trigger`（header 的全局弹窗
+  用 `btn.closest('form')` 定位表单、`form.querySelector('[name="g-recaptcha-response"]')` 回填，
+  **不依赖 id**，所以举报表单可直接复用）；非 math 用 `.g-recaptcha` + 自定义 callback `tbReportCaptchaOk`。
+- 筛选：`/user/questions?reported=reported`，复用已查出的 `reportCounts` 在内存过滤，
+  新增 `SelectedReported` + 模板第 5 个下拉（reportFilter / reportedOnly）+ 4 语言文案。
+
+验证：`go build ./...` EXIT=0；`go run ./dev/checktpl` → all templates syntax OK；
+`go test ./internal/i18n/` 通过。**未部署**，且加了验证码之后原来的 curl 测试方式要改成先算题再提交。

.workbuddy/memory/MEMORY.md

@@ -39,6 +39,10 @@
 - ⚠️ **探测端口 200 可能是别的进程**：8899 被本机无关进程占用，服务 panic 后 curl 仍返回 200，
   差点误判成「改动没生效」。起服务后必须看任务日志确认 `Starting web server` 且无 panic，
   再信任 curl 结果；端口探测本身不能证明是自己的服务。
+- ⚠️ **本机 python urllib 不稳定**：`https_proxy=127.0.0.1:54881` 下偶发「响应读超时」
+  （同一时刻 curl 完全正常）。曾据此误判「举报接口卡死 25 秒」，实际是客户端问题。
+  **验证线上行为优先用 curl**；必须用 python 时加短超时 + 重试，且不要用 `/tmp` 路径
+  （Windows python 把 `/tmp/x` 解析成 `C:\tmp\x`，而 MSYS curl 写的是 MSYS 的 `/tmp`，两者不通）。
 
 ## 图片上传与编码（`internal/storage/s3.go`）
 
@@ -98,8 +102,11 @@
   2026-10-18 实测：L3 拒绝发布时箱主完全看不到提示，改 `SetError` 后正常显示。
 - 项目里仍有若干 `SetErrorFlash + Success("question/item")` 的既有组合（`follow_up.go` 的 errNotFound、
   `question.go` 的上传图片过大等），同属该缺陷，遇到时顺手改成 `SetError`。
-- **TODO（用户 2026-10-18 明确要求后续处理）**：全量排查 `SetErrorFlash + Success(...)` 组合并统一改为
-  `SetError`，做一轮专项清理。
+- ✅ **2026-10-18 已完成全量清理**：扫描 `route/**/*.go` 中 `Set*Flash` / `SetInternalErrorFlash`
+  后 8 行内跟 `ctx.Success(...)`（而非 `Redirect`）的位置，共 **9 处**：`follow_up.go` 2 处、
+  `page.go` 1 处、`question.go` 1 处、`profile.go` 5 处，全部改为 `SetError(err[, f])` / `SetInternalError()`。
+  `Set*Flash + Redirect` 112 处属正常模式，未动。`vote.go:702/704` 是扫描器误报（其后是 Redirect）。
+  扫描脚本思路可复用：逐行找 flash 调用 → 向下找第一个 `Success(`/`Redirect(` → 前者即缺陷。
 
 ## 表单校验