restrict v7

.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(` → 前者即缺陷。
 
 ## 表单校验