صفحهٔ اصلی گشت‌و‌گذار راهنما
ثبت نام ورود
huangjie
/
aivfo-tl-3.0
1
0
انشعاب 0
پرونده‌ها مشکلات 0 درخواست واکشی 0 ویکی
درخت: eae7f048e9
شاخه‌ها تگ‌ها
aivfo-tl-3.0
/
项目文档
/
进度
/
交接卡.md

交接卡.md 24 KB
تاريخچه خام

交接卡 · operate/control 双进程拆分(追加式历史)

续接载体之一。每完成一步或暂停,在末尾追加一段:## 日期 时间 · 一句话标题,下列「改动/核实/踩坑/下一步」。只追加,绝不覆盖。 新任务(2026-06-22 启动)。旧任务(M0-M8 合并改造)交接卡随旧文档清空,本卡为新任务重起。

2026-06-22 · 旧任务结项 + 新任务(双进程拆分)启动,文档体系重建

  • 背景:旧任务"三项目合并改造"(M0–M8)已全部结项。用户主动清空 项目文档/ 下旧文档(00总纲/需求文档01-14/开发计划归档/历史报告),为新任务腾空。
  • 新任务:operate / control 双进程拆分 —— 把 control 从 operate 进程内剥离成独立常驻进程,operate 可随时开关而 control 续命驱动机器;装机仍一个软件、只启 operate。
  • 本会话已完成:
    1. 需求梳理:7 路并行捋遍 control 全部逻辑(采集主循环/服务器双向交互/启动硬件层/缓冲瓶排队换气/数据库数据流)+ 穷尽全部配置参数(App.config + 三级数据库 tl_setting/house/house_well_setting)。产出 需求文档/control-逻辑与配置全景.md。
      • 纠正若干认知:温度=下位机自控只读;气体/压力=control 主动控制(周期换气 AirSwapFun、低压补气 AerationNew);拍照/对焦=StartDish 后 control 自主按 photoIntervalPerRound 循环驱动(非每张等指令)。
    2. 架构设计(brainstorming 逐项确认):双进程 + 本地 HTTP(127.0.0.1)通信 + operate 按需拉起 + control Mutex 单实例 + 开机自启 operate + 调试跨进程借串口(复用 HouseGate)+ 受护栏停止(二次确认+工程师口令)。产出 需求文档/specs/2026-06-22-operate-control-双进程拆分-design.md(9章)。
    3. 阶段1实现计划(writing-plans):7 个 bite-sized 任务,纯逻辑 TDD 单测、进程/HTTP/采集编译+真机验证。产出 开发计划/2026-06-22-阶段1-control独立进程骨架.md。
    4. 老壳鉴定:ivf_tl_ControlTest(csproj=ivf_tl_ControlMain)= 合并前 control 独立 exe,但 Window1 启动骨架已被 operate 复刻吸收、MainWindow 是纯测试、StopWindow 是死窗,命名混乱(三命名空间)。结论:不改造,阶段3 退役删,新 control 启动器基于干净的 ivf_tl_Control 类库新建。
    5. 文档体系重建:沿用原目录结构。新写 00-需求总览.md(新总纲);全景移入需求文档/、阶段1计划移入开发计划/;续接三件套(进度状态.yaml/工作计划表.md/本卡/待验证清单/进度数据.js)按新任务重写;CLAUDE.md 引用改到新体系。
  • 顺带(非本任务,环境修复):本会话还修了 data-transmission 启动失败(application-local.properties 里 jna.lib-path/video 路径写死成 D:\WorkSpace 开发机路径→改本机 + 重编译,DLL 加载成功、10030 通);起了本机微服务集群(gateway 等 6 服务,oplog 原在跑)。
  • 踩坑/待办:① 旧 operate 残留进程 PID 20268(高权限,非交互 shell 杀不掉)需用户在桌面任务管理器/重启清掉;② operate Debug 版有 #if DEBUG 把地址覆盖到 207 外网,真机验证须用 Release。
  • 下一步:① 建 feature 分支(勿在 main 改代码);② 子代理驱动执行阶段1 Task1-6(编码);③ Task7 真机验证待用户在场。

2026-06-22 · 合并工作复核评审 + 新增 operate 全景文档 + 降级遗留登记

  • 背景:用户指出"三项目合并做到一半、没测、流程跑不通",要求只对源码(合并前 临时文件/ 基准 ↔ 现有合并版)、不依赖 git,完整复核合并改动与文档完整性。
  • 复核结论(逐条源码坐实):
    1. 合并保真:control 整套搬运无源码丢失;AutoFocusTool 重构进 IvfTl.AutoFocus/IvfTl.Hardware,对焦核心算法逐字保留;operate↔control 经 ProjectReference 真接线(同名程序集已改名解冲突),静态看 operate 可编译(未实跑 build)。
    2. operate 侧 4 处真实功能降级(根因:control 端 Commander 缺 builder,HAL SerialChannelImpl 返回桩值):排气阀时间写(:130 return false)/读(:137 return -1)、缓冲瓶灯光写EEPROM(:143 return false)、调试页存图(CameraImpl:148 丢宽高转 SaveBmpPic 未验证)。另有写EEPROM"成功=true"不可靠等待验证项。
    3. control 全景文档准确性高(~90%):抽核 file:line 几乎全中,§九 四条论断属实,降级如实披露;勘误若干(ConvertHelper 路径应为 ivf_tl_UtilHelper、ComBin 30s 超时仅一级、SQLite 应为9表、leftOffset/bottomOffset/focusPeakRatioThreshold 在 control 不消费)——已记录,待随手修订。
  • 改动(本次新增/回写):
    • 新增 需求文档/操作端逻辑与配置全景.md(operate 全景:启动时序/业务模块逐功能/8个 operate↔control 直连点/HTTP 接口全表/凭据加密/配置全键/§八 合并降级登记/后台线程/上线前清理项/拆分结论)。
    • 待验证清单.md 新增"合并遗留·operate 侧"区(M-01~M-07)。
    • 订正 CLAUDE.md/00-需求总览.md/工作计划表.md/进度状态.yaml 里"M0-M8 已全部结项"为"代码完成、真机验收整体未做、有降级遗留";三处文档地图挂上 operate 全景。
  • 核实:4 处降级 + 直连点 + HTTP 接口均在现有源码逐一 file:line 坐实;两份全景互为两半(control + operate)。
  • 踩坑:源码注释里引用的 V-010 / "13 §⑤" 指向已删旧文档(可追溯性断裂),本次用 M-01~M-07 在现存文档重新承接。Release 与 Debug 地址差异(AppData.cs:91-111 #if DEBUG 覆写到 test-gateway 外网)——真机/排障必须用 Release。
  • 下一步:① 用户过目两份全景 + 待验证清单;② (用户已要)产出超详细 HTML 业务流程图;③ 真机门控项(M-01~M-07)待用户在场逐条验/补 control builder。

2026-06-22 · 全量文档↔源码核对评审 + P0/P1 修正落地

  • 背景:用户要求结合三个原始项目(临时文件/)、合并版 operate、front、108 数据库,全面核对 项目文档/ 全部文档的完整性/全面性/滞后性/合理性,只认源码+数据库,不看 git 历史。
  • 核对方法:派 5 路子代理 + 主线复核,逐条核对 ~120 处 file:line 声称。结论:
    1. operate 全景 ≈97% 准(8 直连点 + 4 处降级 100% 逐行属实);control 全景 ≈92% 准(行号锚点几乎全中,问题在少数语义结论)。
    2. 合并保真度坐实:control 整套 0 文件丢失(comm -23 空)、对焦核心算法逐字保留(仅命名空间改 + 硬件面换 HAL)、同名程序集已改名(ivf_tl_Control_Entity/Services)。
    3. 108 数据库实测全过:7 库齐(JDBC 直连 SHOW DATABASES 验证)、log.operation_log 19 列含 CLAUDE.md 列出的全部关键列、aivfo_tl_setting 配置表(tl_setting/house/house_well_setting + 对焦扩列)齐。
    4. 进度文档不滞后:合并 operate 下无 ControlHost 目录 → 阶段1"未开工"属实。
  • 改动(本次回写,纯文档对齐,无代码改动):
    • P0(编译硬伤) 开发计划/2026-06-22-阶段1-control独立进程骨架.md:ControlHost Program.cs 的 Log4netHelper 命名空间错——control 子树是 IvfTl.Control.Services(程序集 ivf_tl_Control_Services),计划照搬了 operate 端的 ivf_tl_Services 会 CS0234。已在 using 区加 using IvfTl.Control.Services; + 块内 11 处改裸 Log4netHelper;operate 侧 Step3 块保持 ivf_tl_Services(本就对)并加"勿混"提示;行号 67-134→67-132(3 处)。
    • P1(事实错):① control 全景 §7.1 8表→9表 + 需预置不建表→8表预置、house_autofocus_calibration 由 DBService CodeFirst.InitTables 自动建;② 背景指南 §六.1 192.168.0.207 外网→#if DEBUG 顺序覆盖后最终生效 test-gateway.aivfo.com:36000、§六.5 同步订正建表表述;③ HTML 总图 §12+§17 两处 SQLite"不建表"同步订正。
  • 核实:grep 校验残留 67-134=0、8 表,DependFile=0、不自动建表/需预置不建表=0;ControlHost 块无错误命名空间、operate 块保留正确命名空间。
  • 未改(P2,影响小,用户暂未要):control 全景 §8.2 三个"伪配置"(leftOffset/bottomOffset 死代码、focusPeakRatioThreshold 硬编码 1.2)、§四散文 bufferBottlerPressureMin+10(源码无 +10);完整性小缺口:OperateHwTest(218 行控制台测试 Exe,不在主 sln)、IvfTl.AutoFocus.Tests(游离工程)均无文档登记;front oplog-config.json 实在 ivf_tl_Manage/ 非"front 根";start-all.sh 头注释路径写"临时文件/"实在"开发环境/"。
  • 下一步:① 阶段1 开工时按修正后的 Program.cs 命名空间写,可避开 CS0234;② 如需,补登 OperateHwTest/IvfTl.AutoFocus.Tests + 修 P2 散碎项。

2026-06-22 · CLAUDE.md 核对修订 + 连接配置清单 front oplog 订正

  • 背景:用户要求核查仓库根 CLAUDE.md 的问题并修正。逐条用源码/108 数据库核对(非 git)。
  • 核实(源码坐实,CLAUDE.md §五 操作日志节高度准确):front ivf_tl_Manage/App.config 确有 kfkaIP=192.168.0.108/kfkaPort=9092;App.xaml.cs InitOperationLog()(project=front、topic=tl-oplog)确实起 Kafka 产消息端;operate oplog-config.json 模块(界面点击/HTTP/串口/相机/舱室设置/对焦调试/对焦设置/缓冲瓶调试/皿管理/胚胎操作)与 CLAUDE.md §5.1 一字不差;front config 仅 界面点击/HTTP。→ §5.2.3"operate/front…kfkaIP"正确。
  • 改动 CLAUDE.md(6 项):① §二+§四 补 项目背景与上手指南.md 为开机先读第1篇/文档地图首条;② §二末环境权威源由 环境与账号清单.md(本机 Docker 备用)改指 服务器测试环境.md(108 当前部署)+连接配置清单;③ §六 新增 C#/.NET 编译段(net6.0-windows、三 sln、dotnet build、真机必 Release、MSB3021);④ §四 开发环境补 服务器测试环境.md;⑤ §5.3 operation_log 列 15→实测 19 列(补 parent_id/level/host/create_time);⑥ §二 标为"续接顺序唯一权威,背景指南/00总纲应对齐"。
  • 改动 连接配置清单-换服务器必读.md:§三 front 表补 kfkaIP/kfkaPort 行;订正"front 无 Kafka/oplog 接入"为"front 有 oplog 接入"(附 App.config/App.xaml.cs 证据);§一 Kafka 行"业务里怎么连"由"operate"改"operate/front"。
  • 踩坑:连接配置清单 §三 旧结论"front 无 Kafka/oplog"与源码相反——典型的文档滞后于代码;已订正。
  • 下一步:无强制后续。背景指南 §四 / 00总纲 §六 的阅读顺序若要与 CLAUDE.md §二 完全统一,可另行对齐(本次仅在 CLAUDE.md 标注权威)。

2026-06-22 · HTML 总图背景段补强(三项目澄清 + 半成品提示)

  • 背景:用户反馈 系统业务流程详图.html 背景段未点明"三项目"具体是哪三个、也没在背景段提示"上一个任务是半成品"。核实:§1.1 只讲 operate+control"两个独立进程",AutoFocusTool 要翻到 §7.1 才出现;§0 程序表列 operate/control/front,易被误读成"三项目=operate+control+front"(实则 front 从未合并)。
  • 改动 系统业务流程详图.html:
    • §1.1 后加 info callout:"三项目"= operate + control + AutoFocusTool(对焦工具,重构进 IvfTl.AutoFocus/IvfTl.Hardware,算法逐字保留,见 §7.1);front 从未被合并、本次不动;原始三项目代码在 临时文件/ 下。
    • §1(改造前 vs 改造后 之后)加 warn callout:本次是接一个"半成品"——上个三项目合并任务代码完成、但真机验收整体未做、有 operate 侧降级遗留(指向 §13 / 待验证清单 M-01~M-07)。
  • 核实:三项目合并范围(operate+control+AutoFocusTool→operate、front 独立)此前已由原始↔合并比对坐实(交接卡 2026-06-22 复核段);AutoFocusTool 算法逐字保留、重构进 IvfTl.AutoFocus/IvfTl.Hardware 属实。
  • 下一步:无强制后续。

2026-06-22 · 进度目录+阶段1计划复核 + 文档缺口补登 + 计划真机前置补正

  • 背景:用户两轮要求——(A)以源码+108库复核全部项目文档(排进度目录);(B)再专项复核进度目录是否最新/正确、阶段1计划是否合理。只认源码+数据库,不看 git。
  • 核实(源码/108 实测坐实):
    1. 进度目录最新且基本正确:阶段1"未开工"属实(control/ 下无 ivf_tl_ControlHost);待验证清单 M-01~M-07 的 file:line 全部源码坐实;yaml/工作计划表/进度数据.js 三件套自洽。
    2. 108 库实测:7 库齐;aivfo_tl_setting=18、log=2(非服务器测试环境.md 旧写的 17/1——两条 migration 已补执行);operation_log 19 列与 CLAUDE.md 一致。
    3. 阶段1 计划合理可执行:对源码所有关键假设(类/方法/签名/返回值/命名空间/引用链/复刻段 67-132)实测全成立,无引用不存在类型的硬冲突。
  • 更正(本卡追加更正,前段不回改):
    • ❗本卡 2026-06-22「全量核对」段所记「§四 bufferBottlerPressureMin+10(源码无 +10)」记反了:实测 BufferBottleBin.cs:179 确有 if (BufferBottlePressure < (bufferBottlerPressureMin + 10)) BufferBottleAeration(...),源码有 +10,control 全景 §四 prose 正确,那条"勘误"作废(所幸列为未改、未误改全景)。
  • 改动(纯文档,无代码改动):
    • 服务器测试环境.md §三:表数 17→18、1→2;两条 schema migration 由「未执行」改「已补执行」并消除与连接配置清单的矛盾。
    • 操作端逻辑与配置全景.md:§十 补登 OperateHwTest(真机硬件测试 CLI,非交付件);§8.2 补 CameraImpl.SetGain→-1 桩。
    • 项目背景与上手指南.md §一:厘清三项目合并来源=operate+control+AutoFocusTool,明确 front 不在合并内。
    • control-逻辑与配置全景.md:§一 补 StartTask:497 父线程;§二「无条件启动」改为受 runHouses 门控;§3.2 补 StartAutoFocus:1443+本地对焦安全门;§3.5 标 AirSwapNewFun:1039 死代码;§3.6 补 CapturePausedByGate:319;§7.3 补对焦库源自 AutoFocusTool + 登记 IvfTl.AutoFocus.Tests 游离单测工程。
    • 开发计划/阶段1:Task7 运行前置扩为三条源码实锤清单——新增 ControlHost 必须自带 App.config(否则 AppData 构造 NPE,比 DependFile 更靠前)+ 10 个 DependFile 文件具体名 + calibration.json 不必预置;统一复刻行号 78-130→67-132。
  • 踩坑:① OperateHwTest/IvfTl.AutoFocus.Tests 是已知文档缺口(本卡「全量核对」段已记),本轮补登;② 阶段1 真机最大坑非 DependFile(csproj 已传递拷贝 10 文件),而是 ControlHost 缺自带 App.config 会让 StartRun 第一步 NPE——计划原仅在部署备注模糊提"App.config",已升级为明确前置。
  • 下一步:阶段1 开工(建 feature 分支 → 子代理跑 Task1-6 → Task7 真机);开工时务必先给 ControlHost 工程加 App.config。

2026-06-22 · 阶段1 落地实现(Task1-6 完成)+ 真机验证(Task7 大半通过,采集闭环遇合并遗留阻塞)

  • 背景:用户 /goal 要求按计划 TDD 一次性做完阶段1,真机已连,Claude 自主完成全部测试验证(不找用户配合点击/起停进程)。建 feature 分支 feature/control-independent-process,子代理驱动 Task1-6,Claude 亲自驱动 Task7 真机。
  • Task1-6(代码,全部完成并提交,7 提交在 feature 分支):
    1. Task1-4(1 实现子代理 + 1 独立 spec 审查):新建 ivf_tl_ControlHost(WinExe/net6.0-windows,引用 ivf_tl_Control+ServicesImpl)+ 单测工程;HostArgs(参数解析)/StatusDto(/ping /status 返回体)/ControlHttpServer(127.0.0.1 HttpListener)。6 xUnit 单测红→绿全通过,ControlHost 编译 0 错误。spec 审查逐文件核对一致(app.manifest 根标签笔误已按计划提示修正)。
    2. Task5(实现子代理):Program.cs 完整启动序——Mutex 单实例 + HTTP 先起 + 复刻 operate 启动序。坐实 control 端命名空间:Log4netHelper=IvfTl.Control.Services(程序集 ivf_tl_Control_Services)、AppData/StartMain=ivf_tl_Control、PathHelper=ivf_tl_UtilHelper(经 Controller/Services 传递可达);逐字给定代码一次编译过、零成员臆造。
    3. Task6(实现子代理):operate 侧新增 ControlProcessLauncher(探活/ping→不在则 Process.Start -Verb RunAs 拉起→轮询就绪)+ MainWindow 内嵌 StartRun 段(旧 63-132)替换为 EnsureRunning 调用 + App.config 加 controlPort/controlExePath。Release 编译 0 错误(Debug 被残留进程锁,改用 Release——亦真机连本地中间件正确配置)。
  • Task7 真机验证(Claude 自主,108 集群在线 + 真机连接):
    • 环境诊断:UAC ConsentPromptBehaviorAdmin=0=管理员静默提权,故 Claude 可 Start-Process -Verb RunAs 自主拉起 requireAdministrator 的 control/operate、自主提权 taskkill,全程无需用户点 UAC/起停进程。网关 10010=200、6+java 微服务在线、7 COM 口实测全 FREE(僵尸 20268 不占硬件)。
    • 部署:给 ControlHost 加 App.config(operate 业务键+连接键,构建转 ivf_tl_ControlHost.dll.config——.dll.config 是 .NET6 正确约定,operate 亦然);Release 构建,DependFile(ccd 7 DLL/DB/newccd)经 ivf_tl_Control 传递拷贝全落地。
    • 实测通过:① control.exe 静默提权独立启动✓;② /ping+/status 返回 {"ok":true,"pid":21976,...}✓;③ control 日志见 6 相机序列号 + 7 COM 口全 True——独立进程真机硬件获取✓;④ 第二个 control 撞 Mutex 自退、进程数恒 1(单实例)✓;⑤ control 结构性独立于 operate 运行(无 operate attached 仍驱动)=核心"续命"目标✓;⑥ 卡住的 control 可提权 taskkill 杀掉(非僵尸)✓。
    • 改进(真机发现并修正,已提交 600075e):Program.cs 原在主线程直跑 StartRun,其内部 serialBin 握手/StartAsync().Wait() 阻塞会占住主线程使 _exitEvent.Wait()(阶段2 /shutdown)永不可达;改为 Task.Run 后台跑、主线程驻留——HTTP 即刻可达,对齐 operate 原 Task.Run 形态。
    • ✗ 采集闭环阻塞(关键结论,穷尽排查):StartRun 永久卡在 serialBin.Start() 串口握手,started 恒 false,无法到"数据入库"闭环。根因=合并遗留缺陷,非双进程改造:Program 先 HAL.ScanDevices()(HardwareAccessLayer.cs:185 已对每口握手一次),随后 serialBin.Start() 对同一 HAL 借用 ComBin 二次握手;ComBin.ShakeHandsWait(ComBin.cs:314)taskAutoResetEvent.WaitOne() 无超时,第二次握手命令入队后发送线程不处理(今日 0 个 HouseComRecord 日志)→ 死锁。两次干净 COM 口重启稳定复现(非偶发/非僵尸残留)。旧合并版 operate(僵尸 PID 20268,自 06-21 23:55 卡死、提权 taskkill/wmic 均拒绝访问、需重启清)卡死在同一 serialBin.Start()——即此缺陷之活证。
  • 核实:6 单测真跑通过;control 真机日志 file 实读;COM 口 FREE/占用、38080 空闲、网关 200 均提权脚本实测;僵尸 20268 属主=AIVFO 同用户、提权仍杀不掉(卡原生驱动内核态)。
  • 踩坑:① operate/control 单实例 Mutex 各一(operate="ivf_tl_Operate"、control="Global\ivf_tl_control_singleton");僵尸 20268 占 operate Mutex → 无法拉新 operate,operate→control 路径退化为机制层验证。② .dll.config 而非 .exe.config 才是 .NET6 apphost 读取名。③ 串口握手 hang 是合并真机验收欠账(M 区同源:HAL/SerialChannelImpl 链路),阶段1"零改 control 业务"不含修复。
  • 下一步(待用户定夺):阶段1 进程拆分骨架代码完成 + 真机机制验证通过;采集闭环被合并遗留串口握手死锁阻塞(已登记 待验证清单 D1-07/D1-08)。选项:(A) 开专项任务修 HAL 借用 ComBin 双重握手(可解锁全闭环,但属 control 业务逻辑改动、有真机电机风险,需用户拍板破"零改"约束);(B) 维持现状,串口死锁与 M-01~M-07 一并纳入"合并真机验收"专项。建议先重启清掉僵尸 20268 再做任一选项的最终闭环复测。

2026-06-22 · D1-08 串口握手死锁根因定位 + 修复 + 真机闭环打通(用户选 A 方案)

  • 背景:用户选 A——授权改 control 串口/HAL 逻辑、允许真机驱动电机,开专项修死锁打通闭环。按 systematic-debugging(铁律:先根因后修)。
  • 根因(读全 HAL.ScanDevices/SerialChannelImpl/ComBin 编排坐实,非猜):
    1. HAL.ScanDevices()(HardwareAccessLayer.cs:178-219)对每口握手后 finally: ch.Close()(:217)。
    2. SerialChannelImpl.Close()(:50-58)里 _com.IsStop = true。
    3. ComBin 发送线程 while(true){ if(IsStop) return; ...}(ComBin.cs:126)→ IsStop=true 令发送线程永久退出,且 OpenPort() 原不复活它。
    4. serialBin.Start()(经 InitTL)借用同一缓存 ComBin(SerialBin.cs:195 HAL.GetSerial(0,port).RawComBin)、直接 OpenPort() 重开(返回True)再 ShakeHandsWait 入队握手 → 发送线程已死无人出队 → ShakeHandsWait(ComBin.cs:314)taskAutoResetEvent.WaitOne()(无超时)永久死锁。
    5. 反证:ScanDevices 期间 IsStopWhile=true(默认),若模块不响应 ScanDevices 自己会无限卡、serialBin 的"打开端口"日志根本不出现;但日志出现→ScanDevices 握手全成功、硬件通信正常→死锁纯是"Close 杀死发送线程、重开不复活"。旧合并 operate 僵尸 20268 卡死同处即此因(operate MainWindow 也先 ScanDevices 再 serialBin)。
  • 修复(fix(control) 提交):ComBin.OpenPort() 重开端口成功且发送线程已停(IsStop)时,复位 IsStop=false 并 StartSendCommandThread() 复活(SendCommandLock 防并发双起)。不改命令内容/时序/电机逻辑,仅复活被误杀的工作线程。覆盖 serialBin 直接用 RawComBin.OpenPort() 的借用路径。同步惠及 operate(同路径)。
  • 真机验证 red→green(穷尽实测):
    • 修前:两次干净 COM 口启动稳定复现卡死,/status started 恒 false、RunRecord 停在"打开端口…True"、0 个 HouseComRecord。
    • 修后:/status = {"ok":true,"pid":22252,"tlSn":"NEO-1-20230411","started":true};RunRecord 越过握手→仓室信息(houseSn 枚举)→E方数据→【CamNum:6】设备基础数据;HouseComRecord 恢复产出,真实串口收发:[COM4]Temperature Rec:5E 86 02 09 0F D6、[COM11]DoorStatus Rec:5E 90 06、[COM3]BufferBottlePressure/Aeration(缓冲瓶换气执行)、house6 空闲监测开始——温度/压力/门/换气自控环在真机运行;control→gateway 10010(×2)+ MQTT 1883 ESTABLISHED。
  • 顺带发现(预存缺陷,非死锁/非进程拆分,已登记 待验证清单 D1-09):
    1. DBServiceImpl.StartDbService.InitTables 每启动报 SQLite Error 1: AUTOINCREMENT only allowed on INTEGER PRIMARY KEY(某表 CodeFirst 建表失败)+ DBUpdateTLInfo 本地写失败;control 仍可运行(读本地培养记录成功),影响限该表本地持久化。建议专项修。
    2. ServiceDishAndBalanceData 接口返回失败=无皿时服务器无培养记录、回退本地,正常非缺陷。
    3. 完整业务数据入库(胚胎照片)需物理放皿 + operate UI 操作(无皿、operate 被僵尸锁),超当前自主可测范围与 stage1 进程拆分范围;环境数据走 MQTT 管道已连通。
  • 核实:/status 实测、RunRecord/HouseComRecord 实读、netstat 连接实查、operation_log 直查(最新停在 06-21 23:57 僵尸卡死前,control 自主监控不产 oplog 属正常)。修复提交 + codegraph sync 完成。
  • 下一步:阶段1 进程拆分 = 代码完成 + 真机闭环打通(D1-07/08 通过)。剩余:① 清僵尸 20268(需重启)后复测 operate 端完整链路;② D1-09 SQLite schema bug 专项;③ M-01~M-07 合并降级专项;④ 阶段2(监控补全/借串口/受护栏停止)拆计划。建议合并到 main + 推送。