admin/charging-cabinet
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
77 Commits 1 Branch 0 Tags
Commit Graph

27 Commits

Author SHA1 Message Date
12451
401f84bda6 chore: 清掉误入库的 agent 工具记忆目录与 Vite 模板 README（内容先按主题归位） 
## 起因

用户问"现在确定所有文档都是按分类存放没重复和过期内容了吧" ——
**不能凭感觉答"是"**，于是做了一次针对**已跟踪文件**的体检（重复/断链/过期陈述三维度）。
第一轮体检结果：重复 0 组、断链 0 处，但**又扫出 3 处该处理的东西**。

## 一、`.workbuddy/memory/` —— 另一个 agent 工具的记忆目录被误入库

3 个文件（`MEMORY.md` / `2026-07-02.md` / `2026-07-07.md`），**全仓零引用**，
最后一次"提交"是搭车进 `feat(protocol): TCP v1.1 协议对齐` 这类无关提交 ——
与之前那几张误提交的图片同一模式。

- ⚠️ `2026-07-02.md` 里含一处**生图 API Key 片段**（`sk-ib7i...M2z`）；
- `.gitignore` 里 `.codebuddy/` 早有，但 `.workbuddy/` **漏了** ⇒ 才被顺手提交进来。

### 处理：内容先归位，再删目录（不是一删了之）

按 `docs/README.md` 已确立的原则"**过时就删；仍有价值的归到正确的类**"，
把 `MEMORY.md` 里仍有价值的三类内容分别落位：

| 内容 | 归到哪 | 为什么 |
|---|---|---|
| UI 颜色系统 / 背景容器 / 36 仓通道卡布局 | **`docs/tech/小程序用户端.md`** 新增「附：UI 设计规范（视觉口径，改动界面前必读）」 | 这是页面视觉口径，属小程序文档 |
| Ardot `batch_edit` 的 `fills`/`strokes`/`cornerRadius` 写法坑 + 设计稿 7 屏 ID | **`docs/compound-notes/2026-07-ardot-batch-edit-属性写法.md`** | 工具特有的单点教训，正是 compound-notes 的定义 |
| "开发前必须确认需求"、"生产环境须授权"、落地页明亮风格偏好 | **`AGENTS.md` 新增「操作规则」小节** | 项目级规则，须常驻加载 |

然后把 `.workbuddy/` 从版本控制移除并**加入 `.gitignore`**（连同 `.opencode/`、`.codegraph/`），
堵住同一个坑再犯。

## 二、`software/web/README.md` —— 建站模板残留

23 行里 9 行是 Vite/plugin-react/Oxlint 的模板话术（英文、与项目无关）。
`api-server` / `device-server` / `h5-uniapp` 三个工程**都没有** README —— 构建方式统一在
`AGENTS.md` 与 `docs/tech/部署手册.md` 里。⇒ **删除**。

## 三、一个我自己的误判（已纠正，记录以免后人重复）

我一度怀疑 `docs/tech/API.md` 接口表"少 12 行"（我数出 68 行，而 `mod.rs` 有 80 个 `.route(`）。
复核发现 **`API.md` 自己写明了计数约定**："一行 = 一次 `.route(...)` 注册，共 80 行；
展开后 93 对" —— 而我的正则 `^\|\s*(GET|POST)\s*\|` **漏掉了 `| GET / POST |` 这种链式写法**。
用能匹配链式的正则重数 = **正好 80** ⇒ **`API.md` 是准确的，我的怀疑是错的**。

## 校验（只扫 git 已跟踪文件）

- 已跟踪文件 **217**（原 221 → 删 3 个工具记忆 + 1 个模板 README）；
- 文档内容重复：**0 组**；
- 已跟踪 md 的本地链接：**0 断链**；
- `.workbuddy` 已跟踪文件数 = 0、工作区已不存在。

## 仍**刻意保留**的（不是遗漏）

- `生产环境.txt`：**唯一凭据清单**且被 `docs/tech/小程序用户端.md` 引用为密钥记录处 ——
  上一提交已把"不入代码仓库"这句与事实矛盾的表述改准；是否改走 `.gitignore`+密码管理器由你定。
- `docs/README.md` 的「旧名→现名映射」表 / 处置记录 / 自证方法：**必须**出现旧名，属预期。
- `docs/compound-notes/TEMPLATE.md`（94 B）：新建笔记的模板，给该目录提供格式约束。
- `tasks/002-未结待办-*.md`：两项未结（`energy` 等硬件答复、长函数重构），
  `tasks/` 本身已 gitignore、不入库。
 2026-09-20 05:04:53 +08:00
12451
a03c163c1d chore: 清理过时与误提交产物；取消 archive/（过时就删，历史交给 git） 
## 起因

用户问"历史留痕？看看有没有过时的和无用的东西可以删除" ——
**不该把"归档"当免检区**。逐项查证后：确认了 3 类该删的、1 类归错类的、1 个不能删的。

## 一、删除：被"顺手 git add"误带进无关提交的产物

用 `git log --diff-filter=A` 追来历，发现它们**根本不是有意提交的**：

| 文件 | 来历 | 判据 |
|---|---|---|
| `换电柜用锂电池充电器1TN标准通信协议 - RS485 V1.0(1).pdf` | `652bde4`（nginx 路由修复） | 与 `docs/hardware/1TN协议标准_苏州翌工电源_V1.0.pdf` **MD5 完全相同**（`B723A1FC…`）—— 纯重复 |
| `package.json` + `package-lock.json` | `652bde4`（同上） | 唯一依赖 `html-docx-js`，**全仓无任何脚本引用**（当次把合同 md 转 docx 的一次性工具残留） |
| `9b0d3b8a…jpg` / `d6e6add1…png` / `ea4410ba…jpg` | `8bc7812`（"23 个函数拆分"）/ `999885c`（协议对齐） | **零引用**，且混在与图片毫无关系的重构提交里 —— 误提交的截图 |

## 二、归错类（**不是过时，所以不删**）：`开发文档.md` → `hardware/硬件与系统设计文档.md`

原本被塞进 `archive/`，但通读目录后确认它含**硬件设计内容**，这些在 `AGENTS.md`/`docs/tech/` 里**没有**：
硬件架构、仓控/柜控主板设计、指示灯状态机、充电控制逻辑（握手/双模式/动态调整/无协议模式）、
BMS 协议适配、安全防护联动、性能指标、第三方服务配置。

⇒ 它是**归错类而非过时**：**硬件部分仍是权威参考**，只有第 7 章（软件平台）被现行文档取代。
已在 `docs/README.md` 写明"两者冲突时软件口径以 `AGENTS.md` 为准"。

## 三、删除：两份 2026-07-06 报告（**问题已全部解决**）

逐条核对了它们"发现的问题"，**无一条仍然成立**：

| 报告 | 当时的问题 | 现状 |
|---|---|---|
| 深度分析报告 | 敏感信息泄露（AGENTS.md 明文密码） | 已成 `AGENTS.md` 的**明示豁免**条目 |
| | 目录名不一致（可能用 taro，需确认） | 已确认 `h5-uniapp`，无 taro |
| | `test/` 目录缺失 | `test/` 已存在且有 7 项验收脚本 |
| | 温度单位不一致（K×100 vs 0.1°C） | 已统一为 K×100 |
| 数据单位审查报告 | SOC/SOH 单位标注错误 | `API.md` 早已重写；该报告基准 `tcp-protocol.md` 已不存在 |

## 四、**不删**：`生产环境.txt`（并修掉自相矛盾的表述）

它是**唯一凭据清单**（阿里云账号/小程序 AppSecret/腾讯地图 key/SSL AccessKey 都在其中），
且被 `docs/tech/小程序用户端.md` 明确引用为"密钥记录处"。

但原文写着"仅记录在内网 Git 仓库 `生产环境.txt`，**不入代码仓库**"—— **与事实矛盾**
（`git ls-files` 实测它**已入库**）。已改为准确表述：只记录在该文件、**绝不写进任何源码/.env**、
**不要删除**（新凭据追加到那里，不要散落别处）。

> 🔐 **留给你的决定**：该文件含大量明文凭据。现策略与 `AGENTS.md`「明文密码」豁免一致（内网仓库），
> 若要收紧，建议把它加入 `.gitignore` 并另存到密码管理器 —— 但这会改变 agent 的直连方式，故未擅自改。

## 五、取消 `archive/` 目录本身

**不再设归档**。理由：被删内容在 **git 历史里完整可查**（`git log -- <原路径>`），
归档的"留痕"价值因此为零，却持续制造"这文件还算不算依据"的歧义。
已把该结论写进 `docs/README.md` 的维护约定：**过时就删；仍有价值的归到正确的类。**

## 六、其他归位

- `营业执照.jpg`（主体资质，小程序/备案用）→ `docs/contract/`
- 根目录现在只剩 5 个必要文件：`.gitignore` / `AGENTS.md` / `README.md` / `opencode.json` / `生产环境.txt`

## 校验

- docs 相对链接 **0 断链**（搬迁引入的 2 处已在上一提交修好，本次复检通过）；
- 已删除文件的残留引用：**仅剩 `docs/README.md` 的处置记录/映射表**（旧名必须出现，属预期）；
- `cargo check --all-targets` 两服务零 error/warning（本次只动文档与仓库清理，未碰源码逻辑）。
 2026-09-20 05:00:29 +08:00
12451
7d2b57d021 docs: 澄清"唯一 TCP 协议文档"并隔离硬件总线协议；删除已完成任务、摘出未结待办 
## 起因

用户提问：**"我们不是有一个 tcp 协议权威文档了吗？为啥还有其他 tcp 协议文档"** ——
查证后确认：**权威文档只有一份**，但目录布局让人容易误判，且**我上一轮的搬迁引入了一处断链**。

## 一、查证结果：全仓只有一份 TCP 协议文档

按"是否同时出现 `auth_str`/`status_post`/`bat_in` 等 act 名"全仓扫描，含协议内容的只有：

| 文件 | act 命中 | 性质 |
|---|---:|---|
| `docs/protocol/柜控板固件对接文档.md` | 171 | ⭐ **唯一权威 TCP 协议规格** |
| `docs/tech/API.md` | 14 | HTTP 接口文档，TCP 章节**只有一句指回权威文档的链接** |
| `AGENTS.md` / `数据模型.md` / `小程序用户端.md` | 13 / 8 / 3 | 规则与存储说明，非协议规格 |
| `docs/archive/项目深度分析报告-2026-07-06.md` | 1 | 历史归档 |

⇒ **没有任何第二份 TCP 协议文档。** 用户看到的"另一份"应是下面二者之一（都已处理）：

### 1. `docs/protocol/1TN协议标准_*` —— **不是 TCP 协议**

它是**仓控板 ↔ 翌工电源的 RS485 总线协议**（另一条物理链路）。与 TCP 权威文档同放
`protocol/`，名字又像"协议标准"，极易被当成第二份平台协议。
**已移到新目录 `docs/hardware/`**（硬件侧总线协议），并在两处都写明"**不是**平台 TCP 协议"。

**结果：`docs/protocol/` 下有且仅有一个文件** —— 一眼就能确认"只有一份"。

### 2. `tasks/001-TCP协议对齐与安全修复.md`（66 KB）—— 是任务记录，不是协议文档

文件名含"TCP协议"，且 66 KB。它已被完整处理（见下节）。

## 二、删除已完成的任务文件，并摘出真正的未结待办

`tasks/` **已 gitignore（`.gitignore:27`），是本地草稿区、从不入库**。

`tasks/001` 的 A~AH **全部 ✅ 已完成**，但其**状态头写着"待排期（未开始编码）"** —— 是错的。
按「已完成的任务文件及时清理」，**已删除**；删前把**唯一两项未结**摘成
`tasks/002-未结待办-协议待确认项与长函数重构.md`：

1. **`energy` 数据源待硬件答复**（协议待确认第 13 项，阻塞中）+ 关联的第 16 项；
2. **长函数重构**（已授权未开工）。

> ⚠️ **顺带纠正 001 的两处数字**（实测后才发现，**不能沿用**）：
> - 001 记"23 个函数超 80 行"—— **当前实测只有 8 个**（本会话多轮重构已拆掉大部分）；
> - 001 记 `migrate.rs::run` 已从 280 拆到 **46 行** —— **拆分本身没被回退**
>   （`SCHEMA_SQL` 确在 L20、`run` 内 0 个 `CREATE TABLE`），但后续每轮迁移改动都往 `run` 里追加
>   （`LEGACY_COLUMN_TARGETS` 对齐、`ensure_active_order_unique`、列注释对齐……），
>   **它又长回 174 行，重新成为全仓最长函数** —— 这是一次**重构回归**，已列为第一优先。
> - 实测脚本随 002 一起留在 `tasks/`（该目录不入库，避免下次重新发明）。

## 三、修复我上一轮搬迁引入的断链（1 处真缺陷 + 1 处机械替换误伤）

搬迁脚本只覆盖了 `docs/<name>` 与 `../<name>` 两种形态，**没覆盖三种情况**，已全部修好并加了体检：

| 位置 | 问题 | 修复 |
|---|---|---|
| `docs/tech/API.md` | 同级相对链接 `](柜控板固件对接文档.md)` 因文件被移走而断链 | → `](../protocol/柜控板固件对接文档.md)` |
| `docs/tech/数据模型.md` | 我的替换把 **markdown 链接目标** `](docs/API.md)` 也换成了 `docs/tech/API.md` ⇒ 解析成 `docs/tech/docs/tech/API.md` | 显示文字保留可读路径，**链接目标改回 `API.md`** |
| `docs/archive/审查报告…md` | 指向当时已删除的 `./tcp-protocol.md`（历史事实） | 归档**保留原文**，顶部加**归档横幅 + 旧名→现名映射表** |

**新增体检方法并实测能发现问题**：遍历 `docs/**/*.md` 的所有相对链接、逐个还原路径判存在性。
修完后复跑 → 只剩归档那一处（按设计保留），已用横幅给出映射。

> 📌 教训（已写进 `docs/README.md` 维护约定）：**移动文档后必须做链接体检**，
> 不能只做字符串替换 —— 同级相对链接、以及"写在链接目标里的仓库相对路径"都会被漏掉。

## 四、文档地图同步更新

`docs/README.md` 新增：
- 顶部**「关于到底有几份 TCP 协议文档」**专节：直接回答，并列出"三份内部件何时被删"的历史；
- `hardware/` 目录说明；
- `protocol/` 明确标注 **⛔ 不要在这里放第二份协议文档**（要补充就改那一份并升版本号）。

`AGENTS.md` 项目结构同步加 `hardware/` 一行。
 2026-09-20 04:55:28 +08:00
12451
619c96c85f docs: 文档分类整理 —— AGENTS.md 只留判据与链接，详细篇按用途归入 docs/ 子目录 
## 为什么要做

`AGENTS.md` 曾达 **90,370 B**，而工作区指令预算是 **65,536 B** —— 系统按**保留头部**截断，
于是**尾部约 25 KB 永远不会被加载**：组织架构、数据模型、TCP 协议、数据单位规范、
微信小程序用户端**全部处于"写了但读不到"的状态**。手册实际上部分失效。

## 一、AGENTS.md 瘦身：90,370 → 60,227 B（余量 5,309 B，尾部不再被截断）

三个**纯参考型大段**整段搬迁到 `docs/tech/`（**内容逐字保留，未删改**），
原位置换成「判据 + 链接」：

| 原 AGENTS.md 章节 | 大小 | 现位置 |
|---|---|---|
| `## 部署与维护` | 17,611 B | `docs/tech/部署手册.md` |
| `## 数据模型` | 12,100 B | `docs/tech/数据模型.md` |
| `## 微信小程序用户端` | 10,262 B | `docs/tech/小程序用户端.md` |

替换后的章节**只留改动前必须先知道的硬约束**（例如：产物名与测试环境落地名不一致、
ETXTBSY 的 `.new`→`stop`→`mv`→`start` 流程、`stream{}` 不可重加、发布顺序 device 先 api 后、
建表顺序即依赖顺序且写错报 MySQL 1824、时间列必须 DATETIME、`cabinets.status` 是配置态不表示在线……），
其余指向详细篇。**判据留在常驻加载的 AGENTS.md，逐项参考移出**。

## 二、docs/ 分类（原 21 个文件平铺 → 五个用途目录）

```
docs/
├── README.md          新增：文档地图（分类/权威性/旧名→现名映射/维护约定）
├── protocol/          设备协议（冻结，对硬件交付）★唯一权威
│   ├── 柜控板固件对接文档.md
│   └── 1TN协议标准_*.md / *.pdf
├── tech/              平台技术文档（开发/运维必读）
│   ├── API.md · 数据模型.md · 部署手册.md · 小程序用户端.md
├── contract/          合同·规格·验收标准（商务依据，不描述实现）
├── compound-notes/    单点经验笔记（原有）
└── archive/           ⛔ 历史留痕（只读，不代表现状，不可作依据）
    ├── 开发文档.md（早于现行实现）
    └── 审查报告/深度分析报告-2026-07-06
```

- 19 个文件用 `git mv` 迁移（保留历史），3 个未跟踪文件用普通移动；
- **内容零改动**（唯一例外是引用替换），已核验 `docs/tech/API.md` 的 `git diff` 为空。

## 三、全仓引用同步：40 处 / 10 个文件

路径不只出现在文档里，还散落在**源码注释**（`db/migrate.rs`、`routes/cabinets.rs`、
`workers/report_worker.rs`、`tcp/connection.rs`、`h5-uniapp/utils/format.ts`）、
`test/tcp_e2e_smoke.py`、`tasks/001-*.md`、`README.md`、`AGENTS.md` 中，全部同步。

**并已实测校验命令能失败**：往 `docs/tech/API.md` 植入 `<!-- probe: docs/API.md -->`
→ 命中；删除 → 无输出。
> ⚠️ 过程中踩了一个坑并已修：这些 `.md` 多为 **CRLF**，我第一次用 `\n` 正则删除时
> **没匹配上 `\r\n`**，以为删干净了其实残留了一行 —— 靠 `git diff` 非空才发现。
> 已把「CRLF 必须按 `\r?\n` 处理」写进 `docs/README.md` 的维护约定。

## 四、顺带查实的失效引用（归档保留原文，不改写历史）

- `docs/tcp-protocol.md`：仅出现在 2026-07-06 的两份历史报告里（当时的事实）；
- `docs/柜控板-平台TCP接口文档.md`：仅出现在协议文档 **v1.1 变更记录**里
  （记录"已删除该内部重复文档"这件事），**不是活链接**，无需修复。

两者已在 `docs/README.md` 的「旧名 → 现名映射」表中给出对应关系。
 2026-09-20 04:42:51 +08:00
12451
471b61d277 fix(test)+fix(deploy)+docs: 探针状态语义反转修复、退出码补齐、文档校订 
1) probe_export.py：任务状态语义**搞反了**（导出成功也会被判失败）
   - download_tasks.status 的权威语义是 0 排队 / 1 处理中 / **2 完成** / 3 失败
     （db/migrate.rs:225 列注释；写入侧 charge_records.rs::mark_task_completed 写的就是 2）。
   - 该脚本此前**等 status == 1（处理中）当成功、把 status == 2（完成）判成"导出失败"**
     —— 典型假红。已按权威语义订正，并与另外两处**本来就正确**的口径对齐：
     web/src/pages/charge-records/DownloadCenter.tsx::statusText、
     test/schema_alignment_e2e.py（等 status in (2,3) 再断言 == 2）。
   - 同批修正退出码分类：账号缺 charge_record:export（403）由 exit 1 改为
     **exit 2「未验证」** —— 本项要验证的是"降权成 pms 后能否往 exports/ 落盘"，
     没权限根本走不到那一步，报 1 是**把夹具缺陷说成产品缺陷**（误报与假绿同样有害）。
   - 允许用 PMS_PROBE_PHONE / PMS_PROBE_PASSWORD 换成有权限的账号。
   - **C 项结论（由落盘物证直接判定，不依赖该脚本）**：测试环境
     exports/充电记录__-.xlsx 5559 B、生产同类产物 5457 B，属主均为 pms:pms；
     两环境 exports/uploads 目录均 pms:pms，两 api-server 单元均 User=pms/Group=pms
     ⇒ 降权进程确实能落盘。已在 README 写明并给出取证依据。

2) deploy-prod.ps1 的退出码（此前失败的探针只打印 ❌ 就继续，脚本仍以 0 退出）
   - 消费链路探测失败（exit 1）现在**记入失败清单**并以 exit 1 收尾；
     "未验证"（隧道没起）默认仍不计失败（环境问题会误报），
     但新增 **-StrictVerify** 开关供 CI/无人值守使用，打开即 exit 1。
   - 好处：把这条从"打印了 ❌ 却 exit 0"（仓库第 8 条假绿）里摘出来。

3) 统一退出码 0/1/2 落地到本批脚本，并对每个失败路径实测取证：
   - test/tcp_e2e_smoke.py：13/13 通过（含未登录业务报文被静默丢弃）；先复位夹具再跑。
   - test/security-hardening/ 新增 verdict.py 判据容器（未跟踪 → 本次入库）；
     4 个探针全部按失败→exit 1 改造，并各实测过失败路径。
   - 实测结果（2026-09-20 发布后回归）：smoke_prod 4/4 exit 0、
     probe_prod 5/5 exit 0、probe_upload 6/6 exit 0。

4) 工具与文档
   - tools/db.py 默认库由**生产 pms 改为测试 pms_dev**（可用 PMS_MYSQL_DB 覆盖，
     切生产时打印醒目警告）—— "以为在测测试库、实际打生产"的隐患。
   - tools/db_schema_diff.py：连不上必须是 exit 2，绝不伪装成"无漂移"的 0。
   - 新增 tools/dev-tunnel.ps1（入库，SSH 隧道；口令走 PMS_SSH_PASSWORD 环境变量），
     配套 tools/dev-tunnel-run.ps1 自愈启动器**保持 gitignore**（内含口令）。
   - deploy/nginx/nginx.conf 镜像随线上同步（移除 stream 转发；与线上逐字节一致）。
   - AGENTS.md / README.md：补「踩过的坑」第 7/8 条（掐断上游管道会杀被测进程、
     打印 ❌ 却 exit 0 是假绿）、退出码约定、本地开发改 SSH 隧道、
     在线判据口径订正、order_timeout 守门补齐、小程序 vue-tsc 门禁与其抓到的两个真 BUG。

发布验收（本次统一发布，按 device→api 顺序）：
- 测试环境与生产环境四服务 active，端口 9000/9001/3000/3001 正确，ERROR 均为 0；
- 生产迁移按判据 grep '更新列注释' 实测对齐 cabinets.status 列注释；
- 结构漂移 python tools/db_schema_diff.py = 0 处漂移 / exit 0（--vs-ddl 两库同样 0）；
- schema_alignment_e2e --env dev 全部通过 exit 0；
- 生产域名 /api/pms/cabinets -> 401、/pms/ -> 200；消费链路探测通过。
 2026-09-20 04:31:42 +08:00
12451
9e8826e6f8 fix(deploy): 生产/测试改直连阿里云（nginx stream 转发只服务本地开发） 
- 起因：生产 .env 走 127.0.0.1:6379/3306，而这两个端口是 nginx 在监听 ⇒ 生产实际经由
  "给开发用的转发层"：reload nginx 会同时切断四个服务连接（实测每次 4 条 broken pipe ERROR），
  且生产的库/缓存通路依赖 stream{} 配置（配错则 nginx 起不来、整平台连不上库）
- 改动：/data/pms 与 /data/pms_dev 的 .env 改为直连 rm-...mysql.rds / r-...redis.rds（改前已备份）
- 实测：裸 TCP 可达、python3 直接说 Redis 协议读写成功、mysql 客户端直连查询成功
  （柜子 68/组织 46/版本 8.0.36）、连接目标均为阿里云 IP、health 200、端点回归通过；
  reload nginx 后生产连接数 5→5 不变、生产与测试 ERROR 均为 0（改造前必产生 4 条）
- AGENTS.md 明确：nginx stream 转发只为本地开发，服务侧一律直连
 2026-09-20 03:40:51 +08:00
12451
a904f5ff11 docs: 修正 AGENTS.md 限流描述的事实错误 + 补全限流 location/zone 清单 
- scan_abstract_zone 只挂在 location /api/pms/cabinets/abstract/（前缀匹配不命中 scan/）；
  /api/cabinets/scan/{id} 需登录、无 token 恒 401、不构成枚举信号，无需限流
  （实测：scan 60 连发 = 401x60/429x0；abstract 同法 = 404x23/429x37）
- Nginx配置节的限流清单补上 abstract location 与第 4 个 zone scan_abstract_zone
- 新增经验：写"某 zone 覆盖某某路径"必须按 location 前缀语义核对并附实测 429 清单，
  不要按 zone 名字推断（scan_abstract_zone 这名字极易误导）
 2026-09-20 03:24:34 +08:00
12451
61adcdeaf9 fix(security)+fix(api)+docs: 越权面修复、登录门控与状态语义对齐、文档全面校对 
- 越权面（全部 before/after 实测可复现，10 条）：cabinets/filter 的 project_id/organization_id
  参数分支越权（客户可拿对方向柜全字段）、organization-tree 返回全量组织树、
  cabin-boards/compartments/cabinets 三个 options 无归属校验、batteries 无归属（改为经
  charge_orders→cabinets→projects 间接归属）、feedback 跨组织读且能改他人状态、
  GET /downloads/{id} 漏 user_id 过滤（跨用户元数据泄露）、
  POST /downloads/cleanup 全局删除所有组织导出（改客户侧只清自己）、
  /api/nodes/* 仅需登录（客户可读内网 IP 并注销节点）→ 收紧 role_level>=2；
  /api/devices/stats 同样收紧；新增共享闸门 auth::require_super_admin
- TCP 登录门控：下行投递改为"登录前白名单"（PRE_LOGIN_ALLOWED_ACTS），与上行同一规则
- 60 秒超时对齐协议：挂起项 TTL 120→60 + 值内嵌 deadline 精确判窗 + 超时 WARN（兼容老格式）
- 下发前在线判据改连接级认证标记 device:authed:{imei}（消除"管理端显示成功、设备收不到"）
  ⚠️ device-server 与 api-server 必须同批发布
- 协议对齐：auth_str 登记校验提到限流之前、build_spec Topology 分支 clamp(15/8)、
  行号引用改小节引用、修 3 处错引小节
- 状态语义：compartments.status 只表占用，充满/故障由通道状态派生；柜级 status1/status2
  与开门按钮（柜级独立动作不联动）；列注释对齐（cabinets.status 补 2=禁用、
  charge_orders.status 标注 2 保留未使用）
- 假绿单测修复：超时 SQL 抽常量 + 纯函数孪生体双向断言（方向写反必红）
- RSSI 两端统一为同源纯函数 5 档（小程序显示随之变化）+ test/rssi_signal.test.mjs
- nginx：扫码入口 abstract 限流（zone=scan_abstract_zone 30r/m burst=20）+ 主配置仓库镜像
- 文档：AGENTS.md 新增「踩过的坑」7 条教训 + 部署注意事项 11 条 + 文档口径优先级；
  docs/API.md 接口总表 80 条与 mod.rs 逐条一致、Redis 契约按代码重写、9 处事实错误修正；
  权威协议文档 v1.1.1（协议行为未变，仅修订文档自身的错误/矛盾/缺失）
 2026-09-20 03:23:00 +08:00
12451
ee92102f3c feat(scope)+fix(db)+feat(security): 数据范围(项目级)生效、库列类型对齐、安全加固、状态位分层展示、能耗实时聚合 
- user_scopes 由"假开关"做成生效：粒度到项目级（组织隔离 ∧ 项目∈范围，取交集）；未配置=不限制（逐字向后兼容）；
  总管理员豁免；脏数据保守忽略不锁死；配置期校验存在性+归属；逐接口叠加（列表/详情/写操作/Excel 导出落 scope_project_ids）；
  前端新增"数据范围"弹窗入口。顺带修 GET /api/charge-orders 此前完全没有组织隔离（跨租户泄露）、
  GET /api/projects/{id}/cabinets 的 500
- 数据库列类型系统性对齐：扫描并修复 pms_dev 32 项 / pms 18 项漂移（时间列统一 DATETIME，sqlx NaiveDateTime 只兼容 DATETIME）；
  DECIMAL→BIGINT 与列注释口径拉平；修复生产 GET /api/charge-orders、GET /api/device-logs 必然 500 的根因；
  恢复 7 张表丢失的 updated_at ON UPDATE（行为变化，已记入 AGENTS.md）；修正 SCHEMA_SQL 前向引用（空库建表必崩）；
  新增 tools/db_schema_diff.py（漂移检查，退出码可接部署前置）与 test/schema_alignment_e2e.py
- 安全加固四项：上传去 .svg + 魔数嗅探（堵存储型 XSS）；登录失败锁定(5次/15分)+challenge 限流+并发闸门+验证码容差收紧；
  服务降权 root→pms；nginx 安全头 + limit_req + CORS 白名单收敛
- TCP 连接登录门控（上行+下行同一规则）：login 前只放行 auth_str/login（PRE_LOGIN_ALLOWED_ACTS）
- 状态位按归属层级展示：柜级 status1/status2 显示在柜子（含柜门 + 开门按钮，独立动作不联动业务）、
  仓体级 batt_status/pow_status 显示在仓体；两端解析函数同源同名
- 能耗报表改实时聚合 charge_records（原 energy_stats 全表只读不写导致报表恒 0）+ 补复合索引
- 组织可见性：新增 GET /api/my-organizations（工厂全量、客户仅本组织）
- 仓体 status 仅表占用，充满/故障由 Redis 通道状态派生
- 订单/占用/队列运维缺口：h5 建单漏单、214 仓体自愈、device:reports 上限、死信 TTL、LimitNOFILE、
  每日 mysqldump + 回滚点保留 5 次
- 文档：AGENTS.md 补层级可见性/数据范围/状态位约定/数据库工具/行为变化；docs/API.md 删除废弃 TCP 章节、接口总表对齐 mod.rs
 2026-09-20 02:44:51 +08:00
12451
8bc7812733 refactor(api-server): 23 个超 80 行函数拆分为 ≤80 行（纯重构，行为不变） 
拆分范围（14 个文件）：migrate / users / operation_logs / energy_stats / charge_records /
batteries / device_logs / auth / captcha / main / routes::mod / h5 / cabinet_tree / report_worker

手法：长 SQL 抽模块级 const、拼装与映射与校验抽私有 fn、路由按业务域拆 Router 再 merge、
Excel 导出按"取数/表头/逐行/收尾"分阶段、连续代码块原样搬移+传参。

行为不变的证据：
- 路由 79 → 79 条逐条比对一致（路径+handler+方法链；中间件/CORS/with_state 作用域保持）
- 字符串字面量多重集比对：11 个文件唯一集合完全一致；report_worker 零差异（435 条字面量全等）
- 关键契约计数不变：CAST 14→14、AS SIGNED 4→4、COALESCE 6→6；SQL 文本与 Redis key 零增删
- 未新增 #[allow] / unwrap / expect / panic；captcha 的 RNG 消耗顺序保持（验证码分布不变）

验收：cargo check 0 error / 0 warning；cargo test --bins 39 passed / 0 failed；全仓已无 >80 行函数。
端到端回归：先部署测试环境跑 TCP 协议联调 13/13，且数据库终态与重构前逐字段一致
（orders.energy=22、start_soc=850、end_soc=1000、records.energy=22.00、max_temp=29800、占用状态正确复位）。
 2026-09-20 00:01:01 +08:00
12451
999885c38f feat(protocol): TCP v1.1 协议对齐 + 平台侧兜底 + 生产部署修复 
协议（唯一权威文档：docs/柜控板固件对接文档.md）
- 应答必带 act（与请求一致）、msg_id 与请求一致；判"应答 vs 指令"只看有没有 suc
- dev_id 只在 auth_str/login 携带；其余报文用内部字段 _dev_id 路由（下发前由 device-server 摘除）
- id 只表示动作目标（柜级省略 / 一段=单板 / 两段=仓体级），不再含 IMEI
- msg_id 每连接从 1 起自增；60 秒交互超时；status_post 每通道 18 字符 hex 全量上报
- 未登录连接 30 秒内未 login 即断开；未登录只放行 auth_str/login

平台侧实现
- 上行解析按新结构重写（cabinet/boards/battery），删除废弃的 status/parsed_status
- 订单：唯一入口 = on；bat_in 只登记电池台账；4 条结束路径统一走 finalize_order（含充电记录落库）
- 新增设备日志保留策略（90 天，分批删除）；未登记 IMEI 静默丢弃；停电标记按 status1 bit0 恢复清除
- 待确认第 13 项兜底：平台侧按 电压 × 电流 × 时间 积分计算订单电量（workers/energy.rs）
- 待确认第 18 项兜底：status_post bit7 连续 2 次无电池 → 判定电池被拔走并提前结单

修复（均为部署后才暴露的问题）
- 队列消费禁用 BRPOP：无限阻塞会因代理掐连接永久卡死（零错误日志）；有限超时也只是
  "超时才醒"，下行指令延迟 15~45 秒 → 改为 RPOP 非阻塞轮询，延迟降到 0.1~0.2 秒
- sync_iccid 把可空列 iccid 按 Option<String> 解码 → 整条 login 失败（ICCID 未上报的新柜子永远登录不上）
- 迁移读 information_schema.COLUMN_COMMENT 需 CAST(... AS CHAR)（MySQL 8 驱动报 VARBINARY，否则迁移 panic）
- 部署注意事项：.env 不支持行内注释；pscp 上传需 chmod +x；运行中二进制需 .new + mv 原子替换

部署
- 生产迁到 API 9000 / TCP 9001（systemd 单元补 EnvironmentFile、nginx 同步指向）
- 新增 deploy/deploy-prod.ps1（本地一键：构建→校验→备份→原子替换→重启→验收→无副作用探测）
- 废弃 deploy-prod.sh / deploy-test.sh（原脚本会在 target/release 找产物、装重复 systemd 单元、
  并用本地 .env 覆盖线上 .env）

质量
- 单测：api-server 39 个 / device-server 13 个（含协议示例逐值断言、跨模块 Redis key 契约）
- 两服务 cargo check 零错误零告警；web tsc --noEmit 通过
- test/tcp_e2e_smoke.py 端到端联调 13/13 通过
 2026-09-19 23:41:09 +08:00
12451
b553c4e519 feat: API 统一 + 设备详情补全 + H5 导航优化 
- API 路由统一: 移除 /api/h5/，统一 /api/pms/ 入口
- 二进制改名: api-server -> pms-api（与服务名一致）
- nginx: 合并 /api/ + /pms/api/ 为 /api/pms/
- 新增 docs/API.md 接口文档
- 后端: CabinetDetail 增加 rssi/pow_fail/address/soc 等字段
- Redis 管道批量读取仓体实时数据（SOC/电压/电流/功率）
- DB: 所有 TIMESTAMP 列改为 DATETIME（修复类型不匹配）
- 用户管理: 新增创建时间/修改时间列，状态改用 Switch
- 角色管理/用户管理: 操作按钮改为图标
- PC 设备详情: 基本信息补全 RSSI/ICCID/电源/地址
- PC 卡片: 通道统计改用 Lucide 图标，颜色统一
- PC 二维码: canvas 渲染，含编号文字，支持右键下载
- H5: 按 uni-app 规范修正导航（navigateTo 替代 reLaunch）
- H5: 详情页加返回导航条
- H5: 扫码支持摄像头（jsQR）+ ?id= 参数
- H5: 底部 tabBar 在所有页面常显
- H5: 首页统计改为 6 项（设备/通道/空闲/充电/充满/故障）
- H5: 下拉刷新 / 上拉加载
- 产品首页: 添加业务联系
- 文档: 清理过时文件，补充缺失规范章节
 2026-07-04 04:03:02 +08:00
12451
2b8fd10619 docs: 更新文档 - H5 技术栈改为 uni-app，添加 tar.gz 部署规则 2026-07-03 04:50:01 +08:00
12451
06765f99db feat: H5 用户端 Taro 重写 + 前后端接口对齐修复 
- 使用 Taro + React 重写 H5 用户端（替换旧的 React+Vite+H5 实现）
- 6 个页面：登录、首页、设备列表、设备详情、仓体详情、个人中心
- Zustand 状态管理 + API 层封装 11 个接口
- 后端 H5 路由：新增仪表盘/项目/设备/充电控制接口，组织数据隔离
- 扫码入口：/h5/{abstract_id} → 免认证查设备 + 登录后跳转
- 管理端：新增绑定码管理、二维码展示下载、设备绑定/替换 IMEI
- 产品落地页更新（hero-bg + logo 替换）
- 接口对齐修复：修正 action 路径/请求体，DashboardData 和 CabinetItem 字段匹配后端
- 布局兼容性：grid → flex，提升移动浏览器兼容性
- 移除旧 H5 项目 software/h5/
 2026-07-03 02:45:00 +08:00
12451
52e392f831 feat: 添加数据库工具tools/db.py，更新AGENTS.md 2026-07-02 19:44:23 +08:00
12451
9b5789fb75 refactor: H5和WEB前端分离，H5独立项目，扫码路径改为/h5/ 2026-07-02 18:23:13 +08:00
12451
9581730d56 docs: 删除重复的格式章节，统一放在指令详情中 2026-07-02 17:24:16 +08:00
12451
34f591a9b8 docs: 移除status_get指令，已不再需要 2026-07-02 17:11:12 +08:00
12451
01aaad23bf docs: AGENTS.md补充所有指令的请求/响应JSON格式 2026-07-02 17:09:54 +08:00
12451
b15e0d2d41 docs: AGENTS.md补充所有TCP指令详细介绍章节 2026-07-02 17:07:01 +08:00
12451
efa7f2c837 docs: pow_fail增加info字段区分交直流停电，pow_on/pow_off独立为平台下发指令 2026-07-02 17:01:45 +08:00
12451
d4f689205a docs: 柜控板增加pow_on/pow_off指令，更新pow_fail说明 2026-07-02 16:55:48 +08:00
12451
d365c40800 docs: 更新AGENTS.md，反映分离后的目录结构 2026-07-02 15:43:59 +08:00
12451
652bde44c4 fix: nginx配置修正Gitea路由 /doc/ 而非 /pms/doc/ 2026-07-02 15:18:45 +08:00
12451
4515021f37 docs: 更新服务管理命令（区分测试/正式环境） 2026-07-02 15:10:27 +08:00
12451
7a04f6da53 chore: 测试/正式环境端口分离，更新部署配置 
- API: 测试:3000, 正式:9000
- TCP: 测试:3001, 正式:9001
- 部署路径: /data/pms (正式), /data/pms_dev (测试)
- URL: /pms/ 前缀
- 添加 systemd 服务单元和部署脚本
- 更新 nginx 配置和 AGENTS.md 文档
 2026-07-02 14:58:47 +08:00
12451
12395ee9e2 init: PMS充电柜管理系统源代码 2026-07-02 05:38:01 +08:00