待验证清单.md 16 KB

待验证清单 · operate/control 双进程拆分

续接载体之一。真机/运行期门控项,每验一条回写状态 + 进度状态.yaml + 交接卡 + 进度数据.js。 状态:☐ 未验 / ☑ 已验通过 / ✗ 验证失败。新任务(2026-06-22)重列。 红线:真机已连,所有测试/调试/验证由 Claude 自主跑完(UAC 静默提权,无需用户在场/中途配合)。下位机均有可读默认值(项目内有读默认值的方法);唯一需守安全区间的是「水平电机(皿孔旋转)」与「垂直 Z 电机(对焦)」的运动范围,参考 临时文件/相关参数.html(用户自测值,仅供参考,实际安全范围比文档更宽):水平钳位 0,220000、垂直 Z 钳位 0,125000。除这两轴运动范围外,其余下位机控制无任何风险。


阶段1 · control 独立进程骨架

编号 验证项 门控 状态
D1-01 operate 启动后能拉起独立 ivf_tl_ControlHost.exe(管理员静默,不弹 UAC) 运行 ☑ 真外壳实跑
D1-02 http://127.0.0.1:38080/ping/status 返回 JSON 运行
D1-03 control 独立进程真机硬件获取(6相机SN读到/7 COM口 True) 真机
D1-04 operate 关闭后 control 进程仍在驱动(核心目标) 运行 ☑ 真外壳实跑
D1-05 重开 operate 复用已在跑的 control(不重复拉起) 运行 ☑ 真实代码实跑
D1-06 单实例:手动起第二个 control 发现 Mutex 已占自退(进程数仍为1) 运行
D1-07 control 完整采集闭环 + 数据入库(started:true / 真机自控环 / 落库) 真机 ☑(修死锁后·DB实证)
D1-08 serialBin/HAL 借用ComBin重开不复活发送线程致串口握手死锁 修复 真机 ☑ 已修复并真机验证
D1-09 control 本地 SQLite 建表/schema 缺口(AUTOINCREMENT + 多表缺列) 运行 ☑ 已修复并真机验证
D1-10 control 硬件操作不进 operation_log(oplog 埋点在 operate 的另一套栈) 运行 ✗ 归阶段3(两栈去重)

2026-06-22 真机验证实测说明(D1-xx 详情见交接卡同日段):

  • D1-01/D1-05 真实代码实跑(非机制层):编译运行 operate 端真实 ControlProcessLauncher.EnsureRunning(集成测试 harness 临时文件/LauncherTest,<Compile Include> 链入真文件):① control 未运行时 IsControlAlive=False → 已拉起 control.exe → 轮询就绪 → True(拉起路径);② control 已运行时 IsControlAlive=True → "已在运行,直接连接" → True、PID 不变、进程数恒 1(复用路径)。harness(operate 代理)退出后 control 仍在 = 续命亦由真实拉起路径实证。唯一未跑 = operate WPF 外壳(登录窗→MainWindow),因僵尸 20268 占 operate 单实例 Mutex,但其调用的拉起逻辑已实跑验证。
  • D1-07 数据入库闭环 DB 实证:control 运行期(20:19 起)直查 108 aivfo_tl_setting 库:house_collect 20:18 后新增 22 行、alarm_data 新增 270 行;抽样实读:house_collect = tl_sn=NEO-1-20230411, house_sn=2..9, temperature=37.16/37.46℃(真实箱体温), 多点温度, house_door=0, create_by=admin_admin, create_time=20:29;alarm_data = house_sn=11 PRESS alarm(control 自主检测缓冲瓶低压上报)。闭环:control 读真机传感器 → MQTT/服务器 → 108 库入库,实锤。
  • ☑ 项均 108 集群在线 + 真机连接、Claude UAC 静默提权自主完成,全程无需用户配合点击/起停进程。死锁修复同样惠及 operate(同 ScanDevices→serialBin 路径)。
  • D1-09 ☑ 已修复(2026-06-22):控制端本地 SQLite 两类缺口已修——① HouseAutofocusCalibrationDB.id long→int(SQLite AUTOINCREMENT 只允许 INTEGER PRIMARY KEY,long→BIGINT 报错致 InitTables 建表失败);② DBService.StartDbService 对 control 本地写的 9 个实体逐个 CodeFirst.InitTables 自愈 schema(打包 aivfoTL.db 落后于实体,缺 localAutofocusEnabled 等列致 no such column)。真机验证:修复后 control 启动 DbException 条数=0(此前每启动报 AUTOINCREMENT + 多表 no such column),started:true 正常驱动,6 单测过。
  • D1-10 oplog 缺口(归阶段3,非闭环阻塞):核查发现全 OperationLogger 埋点都在 operate 侧(ivf_tl_Operate + operate 的 ivf_tl_Services/HttpHelper + operate 的 ivf_tl_Entity 的 Camera/ComBin),control 子树零埋点。control 硬件操作的 oplog 收口本就挂在 operate 的另一套 ComBin/Camera 栈(=阶段3 "ComBin 两套栈去重 G1-2")——故给 ControlHost 单加 InitOperationLog 也不会产 oplog(control 自己串口栈无埋点)。归阶段3 两栈去重一并处理。control 诊断走 RunRecord/HouseComRecord 文件日志(本次定位全程靠它),业务数据入库走 MQTT,闭环不受影响
  • 旁注:ServiceDishAndBalanceData 接口返回失败=无皿时服务器无培养记录、回退本地,正常非缺陷。

阶段2 · 监控补全 + 调试借串口 + 受护栏停止

编号 验证项 门控 状态
D2-01 监控页跨进程显示完整(/status 三块:活动/阀态/借用让路 + 心跳/磁盘/链路) 运行 ☑ 真机验证
D2-02 调试借串口:control 让路(暂停该舱采集)→ 恢复(原 V-012) 真机 ◑ 让路契约已验/调试页完整驱动待设计
D2-03 受护栏停止(二次确认+工程师口令)能安全停 control 运行 ☑ 真机验证

2026-06-22 阶段2 实测说明(详见交接卡同日段):

  • D2-01 ☑:control 端 /status 返回完整 MonitorSnapshot(补 §6 三块:WorkingType/ValveState/CapturePausedByGate);operate 端 ControlClient.GetStatusSnapshot()(harness 实跑真代码)往返反序列化 10 舱、真温 37℃、三块字段正确;ServiceMonitorViewModel.Refresh 已由"同进程 AppData"改为 HTTP /status;监控页 XAML 加三列。
  • D2-03 ☑:/shutdown 错口令→403 拒绝、对口令 tl13579→200 安全停机(HAL.ShutdownAll 关硬件 + 进程退出 + 7 COM 口全释放,非僵尸);operate 端 ShutdownControlCommand(二次确认+Microsoft.VisualBasic.InputBox 口令)+ 监控页受护栏按钮。
  • D2-02 ◑:/serial/pause {houseSn} 实测——舱2 CapturePausedByGate=true 且 COM4 串口停发(control 让路,不驱动电机)→ /serial/resume 恢复;operate ControlClient.SerialPause/Resume 验证生效。但调试页完整借串口驱动在拆分下断链:debug 页原 gate.Acquire同进程 HAL 同一物理句柄(HouseDebugPageViewModel:256),拆分后 operate 进程 HAL 是空单例、拿不到 control 持有的串口——需 control 暴露串口/相机命令代理(当前设计文档未细化的大改面)+ 驱动电机受安全红线门控(设计 §178 需用户在场)。让路契约(/serial/pause|resume)已就位作基础,调试页完整驱动列独立子任务(需设计+受监督真机验)。

阶段3 · 清理老壳 + 装机收尾

编号 验证项 门控 状态
D3-01 退役删 ivf_tl_ControlTest 后 control sln / operate 仍编译正常 编译 ☑ 已删+两编译0错
D3-02 operate 开机自启(注册表 Run),开机自动起 operate→拉起 control 运行 ◑ 注册表方案已验/整机开机自启复测需重启
D3-03 全新部署一次到位(两 exe + control 子目录 + 端口 + DependFile) 部署 ☑ 部署布局已验(operate E2E 即用 control/ 子目录拉起)
D3-04 ComBin 两套栈去重(G1-2,含 D1-10 oplog) 编译+运行 ✗ 延后专项(有风险重构)

2026-06-22 阶段3 实测说明(详见交接卡同日段):

  • D3-01 ☑:ivf_tl_ControlTest(ControlMain 老壳)从 control/ivf_tl_Control.sln 移除并删目录;control sln 重编 0 错误、operate 编译 0 错误(operate 仅 SettingPageView:392 字符串引用旧进程名 ivf_tl_ControlMain=死代码,无类型依赖,随调试页借串口改造一并清)。
  • D3-02 ◑:开机自启注册表 Run 键方案已实测(创建→读回→删除往返成功);整机"重启→自动起 operate→拉起 control"需真重启复测。部署步骤见 开发环境/双进程部署指南.md §三
  • D3-03 ☑:部署布局(operate 目录 + control/ 子目录,control 自带 dll.config + DependFile)已在 operate WPF 真外壳 E2E 实证(operate 即从 control/ivf_tl_ControlHost.exe 拉起 control)。部署指南 开发环境/双进程部署指南.md
  • D3-04 ✗ 延后:operate(ivf_tl_Entity/ComEntitys/ComBin,带 OperationLogger 埋点)与 control(ivf_tl_SerialHelper/ComBin,真驱动硬件)两套串口栈。拆分后 operate 已不驱动串口→operate 那套栈成运行期死代码;control 操作不进 operation_log(oplog 埋点在 operate 栈,=D1-10)。去重=动串口代码的有风险重构,属收尾清理不阻塞功能,列延后专项(需设计 oplog 收口归属 + 受控验证)。

合并遗留 · operate 侧降级 / 待验证(与双进程拆分并行存在)

来源:2026-06-22 复核评审逐条源码坐实;详见 需求文档/操作端逻辑与配置全景.md §八。 这些是"三项目合并"阶段做了一半、未真机验收的功能缺口——合并代码完成 ≠ 业务闭环。 状态:☐ 未验 / ☑ 已验通过 / ✗ 验证失败 / ▼ 已知降级未接通。 根因统一:ivf_tl_operate_2.0/control/IvfTl.Hardware/Impl/SerialChannelImpl.cs(control 端 Commander 缺 builder)。

编号 验证项 现状(file:line) 门控 状态
M-01 舱室排气阀时间 EEPROM 真下发下位机 SerialChannelImpl.cs:130 已去桩→调 _com.WriteEEPROOpenVentTimeWait(control 补 builder,地址 00 03 08,与 operate 逐字节一致) 真机 ☑ 已验通过
M-02 舱室排气阀时间 真读下位机 SerialChannelImpl.cs:137 已去桩→调 _com.ReadEEPROMVentWait(control 补 builder/Wait,地址 00 03 08) 真机 ☑ 已验通过
M-03 缓冲瓶灯光亮度 EEPROM 真下发 SerialChannelImpl.cs:143 已去桩→调 _com.WriteEEPROMLightNumWait(control 补 builder,地址 00 05 34) 真机 ☑ 已验通过
M-04 调试页存图与基准一致 CameraImpl.cs:148 SavePic(name,w,h) 忽略 w/h 转发 _camera.SaveBmpPic(name)(底层从相机自身 SourceBuffer 取帧、自带尺寸→丢弃入参 w/h 无害);落盘格式/旋转/位深 vs operate 基准 MVCAPI.SavePic 等价性需一次受控抓帧核对(当前相机正被 control 用于活体成像,不宜无监督抓帧干扰) 真机 ◑ 代码核查无害/落盘格式待受控抓帧
M-05 写 EEPROM 类"成功=true"可靠性 帧错位根因=合并回归已修复:control CustomProtocolLength 对 0x12 写E方回包帧长误设 6(基线 operate=12),真机实证回包确为 12(舱8/舱9 一致,回包[3]=0x0C 自证)→ 改 control 帧长表 0x12→12(Commander.cs:76)。残留:Write*Wait 仍"收回复即 return"不把状态字传回调用方(非回归,基线同) 真机 ☑ 帧错位已修复并真机验证(残留"成功语义传播"非回归)
M-06 ReadWellFocusZero 按 well 区分 非合并回归,但真机诊断确认是真实缺陷:control ReadWellFocusZeroWait(well) 忽略 well 恒读 well-1 零点;真机只读诊断(无电机)证 EEPROM per-well 焦点零点真实分槽且不同(舱9 79300~80200/3个值、舱8 74000~74600/5个值,均在安全Z区[0,125000]),autofocustool 权威表(well1=0x08 步进4)也按 well 读 → autofocus 对非 well-1 用了偏 600~900 脉冲的错误 Z 起点。修=采纳 per-well 读(同 autofocustool),但改 Z 对焦定位(垂直电机轴),按红线需受控对焦真机验证 真机 ☐ 确认真实缺陷·硬数据已备·改动涉垂直电机待受控验证/用户决策
M-07 Release 连内网网关(非测试外网) 已验证:Release 排除 #if DEBUG(其 :108 行覆写到 test-gateway 外网);部署 App.config outInter=0(不触发 :87 外网覆写)+ urlIp=http://127.0.0.1+urlPort=10010→ BaseUrl=内网网关。已由阶段1 operate WPF 真外壳 Release E2E 真服务器登录成功 + control 10010 ESTABLISHED 坐实。现场换站点改 urlIp 即可 部署 ☑ 已验通过

2026-06-23 M-01/M-02/M-03 ☑ 已修复并真机验证(TDD):

  • 根因:合并阶段 control 端 Commander 缺 3 个 E方 builder(CreateWriteEEPROOpenVentTimeCommand/CreateReadEEPROMVentNum/CreateWriteEEPROMLightNum),SerialChannelImpl 对应方法返回桩值(false/-1),写排气阀时间/读排气阀时间/写灯光亮度未真正下发下位机。
  • TDD red→green:新建 ivf_tl_SerialHelper.Tests(net6.0 xUnit,已入 control sln),对 3 个 builder 断言精确字节(期望=合并前 operate 同名方法黄金真值,末位 CreateORC 校验);先 RED(方法不存在 CS1061),补 builder 后 4 单测全绿(含"写排气阀 vs 写进气阀仅地址低字节 0x08/0x0c 不同"交叉校验)。
  • 接线:control Enums 补 3 枚举;ComBinWriteEEPROOpenVentTimeWait/ReadEEPROMVentWait/WriteEEPROMLightNumWait(镜像既有 intake/light 模式);SerialChannelImpl 三方法去桩调真实方法;operate 消费方(HouseDebugPageViewModel.WriteOpenVentTime/RedVentTimeBufferDebugViewModel.writeL)注释/提示同步更新。control sln + operate Release 双编译 0 错。
  • 真机验证(非破坏性回环,经真实 SerialChannelImpl 端到端,EEPROM 读写无电机风险):读 V→写 V+1→读确认=V+1→写回 V→读确认=V。舱9 排气阀 200→201→200 ✓、舱8 排气阀 90→91→90 ✓(M-01 写/M-02 读)、舱8 灯光 500→501→500 ✓(M-03 写)。写入值真机读回随之变化且已恢复原值→写命令字节正确、真下发下位机。
  • 旁注:无排空时"写后紧接读"偶现垃圾值/null=0x12 写回包长度与 0x11 读不同致帧错位(=既有 M-05 可靠性问题,非本次新命令字节错误——字节错则干净回环不可能出现写入值);加读前丢弃一帧+间隔后 100% 干净。M-05 帧错位/写成功判定列后续专项。

2026-06-23 M-05 ☑ 帧错位根因(合并回归)已修复并真机实证(TDD):

  • 订正定性:上轮把 M-05 整体记为"非回归"。逐字节复核发现其中"帧错位"那半是真实合并回归:control ivf_tl_SerialHelper/Util/Commander.cs CustomProtocolLength0x12 写E方回包帧长设成 6,而合并前 operate 基线(ivf_tl_Entity/ComEntitys/Commander.cs,真机写过 EEPROM)=12;autofocustool Protocol.ReplyLength 也写 6 但它根本没有 0x12 写命令(抄来的未验证默认值)。三方分歧 → 真机实测定论。
  • 真机 raw 抓包实证(裸 SerialPort 9600 8N1,DataReceived 事件收包,整窗累加计数):0x12 写排气阀回包 舱9=12 字节 5E 92 09 0C C8 00 00 00 00 CA 00 97舱8=12 字节 5E 92 08 0C 5A 00 00 00 00 5B 00 B9(回包自带长度字段 [3]=0x0C=12 自证;状态字 [10]=0x00、ORC [11])。校准:0x11 读回 10、握手回 6、0x10 读门回 7(舱8/舱9 一致,[3]=0x07 自证;control 默认 6——但磁盘上 control 帧长表已含 0x08=9/0x10=7,实测确认其正确,唯 0x12 错)。
  • 根因机理:control 只读前 6 字节 → 把数据字节 [4]=0xC8 误当状态字(非0→误判"下位机操作失败")、ORC 校验错位,且残留 6 字节 00 00 00 CA 00 97 污染紧接的下一次读(=M-01/02/03 验证时"写后读垃圾值/null"现象的真正根因,此前用"丢弃一帧+700ms间隔"掩盖)。
  • TDD red→green:新增 ivf_tl_SerialHelper.Tests/CustomProtocolLengthTests.cs(18 测试:0x12=12/0x10=7/0x08=9 三焦点 + 整表 14 项逐项对齐 operate 基线 Theory + 未知码回退6)。先 RED(0x12 实得 6,2 处失败:[Fact] + Theory 行),改 Commander.cs:76 0x12→12 后 22 单测全绿(含既有 4 个 M-01/02/03)。
  • 真机修复验证(紧凑写→立即读,无丢帧 workaround):经真实 SerialChannelImpl,连续多轮"写原值→立即读"——舱9(V0=200)12 轮、舱8(V0=90)12 轮,24/24 全干净(读回精确=写入值,无 -1/垃圾);旧码此处必污染。回归 M-01/02/03 三条仍 PASS。control sln + operate Release 双编译 0 错。
  • 残留(非回归,未做):Write*Wait 仍"收回复即 return",未把已落到正确位置 [10] 的状态字作为 bool 成功传回调用方——属"成功语义传播",基线 operate 同样无条件 true,非合并回归,列后续按需。