背景：
目前渠道有三个左右
一、为通过官方渠道充值，chatgpt puls 110元、chatgpt prox20 1250元
二、通过二手渠道，稳定plus 115元（60~150），prox20 10000以上，拼车400元。
三、中转站 质量未知，价格未知。估计不如自己买。
四、成为codex自己人，开源获取活动资格，绑国外卡，伪装为国外人。 0元

分析：
中短期来看，渠道二是很不错的选择，也有售后，但从长期来看，一四很香也更方便。
所以首选是尝试第四个方法

查询了很久，需要搞到海外的银行卡，就得肉身出海，或者找到海外的朋友搞，再然后搞开源项目，再然后才能够获得资格。
这比较难，几乎都需要面签，填写住址，收入流水，这类的。方法四放弃。

尝试成功，已经成功购买，花费17元（为原先花费的1/6），也成功登录了codex，若是一直想的话，恐怕是一直都不会有结果的。

me：
我想知道目前该方案和世界上主流的方案相比是否有相似之处，是否可以基于现成的项目代码来进行开发，而不是重新造轮子浪费力气（可以单开一个文件分析，然后建议我分析，选择，判断，讨论完再调整方案也可以。若是没什么区别也可以直接调整方案）。  
D:\hua_project\LineChangeover-Control-System\该路径的项目的plc的连接有mc和modbus tcp的，感觉比之前的好一点。  
根据上面调整一下方案。我阅读后觉得没问题，我说执行再执行。

me：
新方案规划用合适的技能制作html文件来进行展示（不单单是给我看的，也是给只有一点点基础的，不了解背景的领导，同事看的，），目前上面这些内容（模块、业务驱动、架构、生命周期等等的）对于我、及同事来说还是很超纲，不够通俗易懂。

codex：

me:
修复1,3,4的问题
**结论**

当前最需要优化的不是页面性能，而是 PLC 通信一致性、切换流程并发控制、权限校验和日志可靠性。这几项会直接影响现场操作安全。

**主要问题**

1. **[P0] 等待切换轮询可能重复执行**

[client/index.ts (line 3118)](D:/hua_project/LineChangeover-Control-System/src/main/modules/client/index.ts:3118) 使用 `setInterval` 每 15 秒启动一次异步轮询，但没有判断上一轮是否完成。一轮切换包含连接、写入、等待 1.5 秒、整组参数读取和重试，很容易超过 15 秒。

下一轮可能与上一轮同时操作同一 PLC，造成重复写入机种号、重复告警、重复复位确认点。

建议改成“上一轮完成后再延迟 15 秒”的递归 `setTimeout`，并增加设备级操作锁和切换批次 ID。

2. **[P0] 参数覆盖权限实际上可以绕过**

授权密码 `233` 和身份关键词判断都在渲染进程中：[ClientLogDialog.vue (line 203)](D:/hua_project/LineChangeover-Control-System/src/renderer/src/views/workspace/components/ClientLogDialog.vue:203)、[ClientLogDialog.vue (line 254)](D:/hua_project/LineChangeover-Control-System/src/renderer/src/views/workspace/components/ClientLogDialog.vue:254)。

主进程直接信任渲染进程传入的 `overwriteAuth`：[client/index.ts (line 3683)](D:/hua_project/LineChangeover-Control-System/src/main/modules/client/index.ts:3683)。生产环境还可以通过 `Shift+I` 打开开发者工具：[main/index.ts (line 171)](D:/hua_project/LineChangeover-Control-System/src/main/index.ts:171)。

因此任何能操作客户端的人都可以绕过界面直接调用 IPC。最终权限必须由后端根据工号、登录凭证和岗位校验；客户端密码只能作为交互提示，不能作为安全凭证。

3. **[P1] 正式业务和测试页使用两套 PLC 编解码**

正式业务自己实现了一套 Modbus 解析：[client/index.ts (line 1022)](D:/hua_project/LineChangeover-Control-System/src/main/modules/client/index.ts:1022)。

测试模块又实现了一套：[point.ts (line 44)](D:/hua_project/LineChangeover-Control-System/src/main/modules/plc-comm/utils/point.ts:44)，渲染测试页还存在第三处地址转换：[plc_comm_test.vue (line 163)](D:/hua_project/LineChangeover-Control-System/src/renderer/src/views/temp/plc_comm_test.vue:163)。

这正是“测试页正常、正式切换异常”的主要来源。最近 FX5U 字序修复也需要修改多处。

建议正式业务统一调用 `plc-comm` 的 Adapter、地址解析和编解码，不再维护独立版本。

4. **[P1] 数据类型归一化存在数值错误风险**

[client/index.ts (line 169)](D:/hua_project/LineChangeover-Control-System/src/main/modules/client/index.ts:169) 只要接口返回 `readBitWidth=32`，就强制转成 `int32`。这样：

- `32位 + float` 会错误变成 `int32`
- `32位 + uint32` 会错误变成 `int32`
- `16位 + uint16` 会错误变成 `int16`

正式 Modbus 编解码还缺少 `uint32` 分支：[client/index.ts (line 1194)](D:/hua_project/LineChangeover-Control-System/src/main/modules/client/index.ts:1194)，而测试模块支持 `uint32`：[point.ts (line 143)](D:/hua_project/LineChangeover-Control-System/src/main/modules/plc-comm/utils/point.ts:143)。

应保留兼容的数据类型，仅在类型缺失时根据位数推断。

5. **[P1] 系统日志上传目前是假上传**

[log/uploader.ts (line 115)](D:/hua_project/LineChangeover-Control-System/src/main/modules/log/uploader.ts:115) 调用的是 `mockUpload`，随后记录“日志上传成功（模拟）”。生产环境配置的地址还是 `api.example.com`：[main/index.ts (line 49)](D:/hua_project/LineChangeover-Control-System/src/main/index.ts:49)。

手动上传还查找 `quality-client-日期.log`：[log/index.ts (line 86)](D:/hua_project/LineChangeover-Control-System/src/main/modules/log/index.ts:86)，实际日志名称却是 `日期.log`：[helper.ts (line 42)](D:/hua_project/LineChangeover-Control-System/src/main/modules/log/helper.ts:42)。

结果是界面可能显示上传成功，但文件没有真正上传。建议真实接口完成前明确显示“仅本地保存”，不要返回成功。

6. **[P1] 业务日志存在丢失窗口**

[client/index.ts (line 2576)](D:/hua_project/LineChangeover-Control-System/src/main/modules/client/index.ts:2576) 先等待上传，完成后才保存本地日志。上传期间客户端崩溃，日志会完全丢失。

续传结束时又直接用 `failedLogs` 覆盖整个队列：[client/index.ts (line 3787)](D:/hua_project/LineChangeover-Control-System/src/main/modules/client/index.ts:3787)。如果续传过程中产生新日志，新日志可能被从队列中覆盖掉。

建议采用 Outbox 模式：先持久化，再上传；续传按日志 ID 更新状态，不整表覆盖。

7. **[P1] PLC 核心逻辑没有自动化测试**

项目没有测试脚本，也没有发现测试文件。地址映射、字序和切换状态机都只能到现场验证，回归成本很高。

最应该先补表格驱动测试：

- FX5U 的 `D320` 16/32 位读写
- `M0`、`M200`、`M1397` 映射
- `ABCD/CDAB` 编解码
- `int16/uint16/int32/uint32/float`
- 轮询期间禁止重复切换
- 离线日志续传不丢记录

8. **[P2] 单文件职责过重**

[client/index.ts](D:/hua_project/LineChangeover-Control-System/src/main/modules/client/index.ts) 约 3794 行、159 个函数，同时承担 API、PLC 协议、配方、切换、日志、闭环、Mock 和 IPC。

[device.ts](D:/hua_project/LineChangeover-Control-System/src/renderer/src/store/modules/others/device.ts) 约 1410 行，也混合配置、配方、卡片、日志和操作进度。

建议在统一 PLC 通信后逐步拆成 `plc-core`、`recipe-service`、`changeover-service`、`log-outbox` 和 `client-ipc`，不建议一次性重写。

9. **[P2] 更新与环境配置需要收口**

更新源仍使用 HTTP：[electron-builder.yml (line 19)](D:/hua_project/LineChangeover-Control-System/electron-builder.yml:19)，多个后端地址也散落在源码中。建议统一环境配置，并将更新源改为 HTTPS，正式安装包增加代码签名。

另外，当前项目的 `.git` 是空目录，`git status` 无法执行。开始较大重构前应先恢复或重新初始化 Git 仓库，否则无法可靠审查和回退。

**建议顺序**

1. 先解决轮询重入、服务端权限校验和假日志上传。
2. 统一正式业务与测试页的 PLC 通信核心。
3. 补地址映射、字序、数据类型和状态机测试。
4. 改造日志 Outbox，再拆分超大模块。

codex：
已修复 1、3、4 三项问题。

- **切换防重入**：等待轮询改为上一轮完成后再计时；重复点击一键切换会复用当前任务；新切换会等待正在执行的轮询结束。[client/index.ts (line 2455)](D:/hua_project/LineChangeover-Control-System/src/main/modules/client/index.ts:2455)
- **统一 PLC 通信**：正式状态检测、机种号写入、参数读取、确认点复位和测试功能均改用 `plcCommManager`；旧的重复 MC/Modbus 实现已从业务模块删除。[client/index.ts (line 875)](D:/hua_project/LineChangeover-Control-System/src/main/modules/client/index.ts:875)
- **统一点位映射**：FX5/FX3 地址、32 位字序和标准 Modbus 规则集中到共享模块，正式业务和测试页面共同使用。[plc-point.ts (line 88)](D:/hua_project/LineChangeover-Control-System/src/shared/plc-point.ts:88)
- **修复数据类型**：`32位 + float/uint32`、`16位 + uint16` 会保留原数据类型；正式路径已支持 `uint32` 读写，MC 也补充了无符号值转换。[point.ts (line 150)](D:/hua_project/LineChangeover-Control-System/src/main/modules/plc-comm/utils/point.ts:150)

验证通过：`pnpm typecheck`、目标文件 ESLint、`pnpm build`。构建仅有原有 Sass 弃用警告。

me：
继续。
最终结果我希望能够继承4个业务，LineChangeover-Control-System、spc-client、sort-client、DTS-client。并且界面的ui可以像标准化的软件一样，可以配置，多个界面，多个业务（有功能可以配置是否启动某个业务），一个合适的架构。开发可以大胆一些，不必把太多的token都用在复核检查测试上，我希望在基于合适的分支管理的基础上看到较大的改动。单纯的合并，我看不到未来的代码架构的开发方向，没有想mes系统那般，可以控制某些业务的显示与隐藏，是否应该有通知界面什么的，是否需要预留工艺参数规格书，各种各样的，我对软件的未来，最终的形态不太确定。我觉得业界里应该对这个形态有确定的共识，我希望直接照着这个目标走，构建起这个框架。已经有的接口可以直接用，不需要测试，但需要有日志打印，方便一次性开发后调试，能够找到问题点。对于没有的接口，可以先用mock接口代替先。
一句话，以业界共识的软件为目标开发，然后大胆的推测，开发，不需要测试，但要有合适的日志打印，方便运行时问题的排查（ai可以阅读日志排查出问题），我需要快速看到实现的结果，然后再以结果为导向逐步填充，完善。后端的代码在：D:\hua_project\liot-server-v2。可以阅读后端代码方便决策，但不要改动后端代码。最后的文档要解释的充分合适，分类，然后添加新业务的时候，有一条合适的工作流（先做什么，后做什么，用什么工具，分类，ai等等之类的），统一每一个同事的开发风格方式，使最后的软件像是一体的而不是风格各异乱七八糟的。

codex：
已完成本阶段的大幅改造，并合并到阶段集成分支：

`codex/phase-1-line-changeover-pilot`  
合并提交：`08fb04a`

`main` 分支未修改、未推送。

### 现在能看到什么

启动客户端后将进入标准化工业运营工作台，默认 Profile 同时启用：

- 产线换型：现有 Mock PLC 完整操作链路
- SPC 过程质量：检测、CPK、点检、趋势工作台
- 零件分选：订单、等级、容器、报工工作台
- DTS 图像追溯：相机画面、识别、单件追溯工作台
- 通知中心
- 工艺规格
- 系统诊断与结构化日志
- Profile 控制业务显示、隐藏和 Mock/Hybrid/Live 模式

整体方向参考了 [ISA-95 制造运营管理边界](https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard)和 [SAP Fiori Spaces/Pages 应用组织方式](https://help.sap.com/docs/SAP_S4HANA_CLOUD/4fc8d03390c342da8a60f8ee387bca1a/f78a65b96121447e8b276c6dec94d637.html)，定位为“统一工业运营客户端 / 轻量 MOM 工作台”，而不是继续复制客户端。

### 当前真实程度

- 换型：业务链路和 PLC Mock 较完整。
- SPC：当前是 Mock，旧接口待和新后端统一。
- 分选：Hybrid，后端已有部分统计/完成接口，逐件分选和报工仍待迁移。
- DTS：Hybrid，后端已有图像识别与记录接口，相机和 PLC 运行时待接入。
- 所有 Mock/Hybrid 状态都会在界面明确显示。

后端 `D:\hua_project\liot-server-v2` 只做了读取分析，没有修改。

### 重要文档

- [最终产品形态与架构](D:/hua_project/muban-cp/docs/architecture/industrial-operations-client-target.md)
- [四业务迁移地图](D:/hua_project/muban-cp/docs/migration/four-business-unification-map.md)
- [新业务统一开发工作流](D:/hua_project/muban-cp/docs/guides/new-business-standard-workflow.md)
- [默认四业务 Profile](D:/hua_project/muban-cp/profiles/default.json)
- [统一应用壳](D:/hua_project/muban-cp/src/renderer/src/layout/index.vue)
- [平台服务与接口目录](D:/hua_project/muban-cp/src/main/platform/platform-service.ts)
- [结构化日志](D:/hua_project/muban-cp/src/main/platform/structured-log.ts)

### 运行查看

```
cd D:\hua_project\muban-cp
pnpm dev
```

已执行并通过：

- `pnpm typecheck`
- `pnpm build`

构建只有原项目 Sass 旧 API 的弃用提示，没有阻断错误。下一阶段建议先把换型的真实配方、日志和 PLC 串成第一条 Live 闭环，然后依次推进 DTS、分选、SPC。