From dcc9ce34e16ab0516cea1e0002915227f2a2cae5 Mon Sep 17 00:00:00 2001
From: QiuSW <105186638@qq.com>
Date: Wed, 29 Jul 2026 11:36:39 +0800
Subject: [PATCH] docs(t235): plan ERP session validation fix

---
 docs/current-state.md |  8 +++---
 docs/tasks/T-235.md   | 59 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 63 insertions(+), 4 deletions(-)
 create mode 100644 docs/tasks/T-235.md

diff --git a/docs/current-state.md b/docs/current-state.md
index 0d84832..0915995 100644
--- a/docs/current-state.md
+++ b/docs/current-state.md
@@ -5,7 +5,7 @@
 ## 当前快照
 
 - 日期：2026-07-29
-- 阶段：T-234 已在受控诊断模式输出 OCR 验证码文本
+- 阶段：T-235 计划修复顺运宝登录后用户会话校验协议
 - Git：当前分支为 `main`；T-001 至 T-004、T-101 至 T-104、T-201 至 T-219
   均按文档提交、实现提交的顺序纳入历史
 - 生产代码：`android-buyer/` 已接入 Roubao Android 源码
@@ -207,9 +207,9 @@
 - 已完成：另含 T-220 至 T-234 ERP 契约、货运存储、采购需求生成、日期增量同步、Go
  直连协议、OCR 会话预检、稳定预检错误、安全诊断日志、直连 `FreightSource`、旧 Connector
  清理和受控本地凭证加载。
-- 进行中：无。
-- 下一步：使用 `start-backend.bat --erp-debug` 重启 API 后以受控单号导入一次，读取 OCR 文本、
-  ERP 请求/响应摘要和货运预检 code；再确认 OCR 规则或服务准确率。
+- 进行中：T-235 将保存登录响应的受控用户身份，使用 `GET /am/user/get?id=<user.id>` 校验
+  同一会话，并收紧 ERP session error 分类。
+- 下一步：实现并验证 T-235 后，使用 `start-backend.bat --erp-debug` 重新执行受控单号 smoke。
 
 ## 当前可运行内容
 
diff --git a/docs/tasks/T-235.md b/docs/tasks/T-235.md
new file mode 100644
index 0000000..5ac5b13
--- /dev/null
+++ b/docs/tasks/T-235.md
@@ -0,0 +1,59 @@
+---
+id: T-235
+title: 修复顺运宝登录后用户会话校验协议
+phase: 2
+deps:
+  - T-234
+status: PLANNED
+created: 2026-07-29
+context_ref: 4cf2151
+work_branch: null
+write_paths:
+  - docs/tasks/T-235.md
+  - docs/api.md
+  - docs/current-state.md
+  - docs/integrations/shunyunbao-contract.md
+  - backend-api/internal/platform/shunyunbao/**
+---
+
+## 问题 / 背景
+
+真实诊断日志证明验证码 OCR `F4B8` 被 ERP 接受，`POST /am/auth/login` 返回
+`status=true`、user 和 token；随后 Go 请求不带 query 的 `GET /am/user/get`，ERP 返回
+`status=false`、`msg=没有任何操作`。原 Python 合约明确要求
+`GET /am/user/get?id=<登录响应中的 user.id>`。当前 Go 只用 `hasUser` 判断 user 存在，既未
+保存/传递 `user.id`，又把用户接口任意 `status=false` 都归类为会话失效，最终在 Web 层表现为
+泛化 `503`。
+
+## 方案
+
+1. 登录成功后从 `data.user` 严格解析正整数 ID 和非空 username，仅保存在受锁内存会话中；
+   不保存或返回登录 token。
+2. 使用 `url.Values` 构造 `GET /am/user/get?id=<id>`，保持同一 Cookie jar；响应必须包含相同
+   ID 和 username，否则清除内存认证身份并返回 `ERP_RESPONSE_INVALID`。
+3. 后续 Validate/货运查询复用已确认身份。HTTP 401/403 或 ERP code `-2` 才归类为
+   `ERP_SESSION_REQUIRED`；其他业务 `status=false` 归类为 `ERP_RESPONSE_INVALID`，不再误报
+   会话失效/泛化 503。
+4. 以脱敏 fixture 覆盖 user id query、身份一致性、非 `-2` 错误分类、`-2`/401 会话失效、
+   Cookie 复用和查询流程；日志不得输出 user id、username、token 或 query。
+
+## 验收要点
+
+- [ ] 登录成功后的用户校验请求包含登录响应中的唯一 `id`，且复用登录 Cookie。
+- [ ] 用户响应 ID/username 必须与登录身份一致；缺失、冲突或普通 `status=false` 返回
+  `ERP_RESPONSE_INVALID`。
+- [ ] 仅 HTTP 401/403 或 ERP code `-2` 清除认证并返回 `ERP_SESSION_REQUIRED`。
+- [ ] Admin 不再因缺失 user id 得到 `freight_import_failed status=503`；该协议失败若重现应显示
+  `ERP_RESPONSE_INVALID`。
+- [ ] 标准 Go 测试、race、vet 和三个入口构建通过。
+
+## 边界
+
+- 不修改 OCR、验证码重试、ERP 账号密码、登录 token 持久化、货运字段、数据库或采购流程。
+- 不在自动测试中访问真实 ERP；真实单号 smoke 由部署者重启后执行。
+
+## 执行记录
+
+- 2026-07-29：创建任务。真实日志已排除 OCR、网络和账号密码；对照
+  `D:/chengma/shunyunbaoerp/shunyunbaoerp_single.py` 确认 Go 遗漏用户接口的 `id` query，
+  并发现非 `-2` 响应被过度归类为会话失效。