aivfo-tl-3.0/项目文档/进度/交接卡.md

续接交接卡（追加时间线，勿覆盖）

每完成一任务或暂停时追加一段。新会话开场读最新一段接上。

2026-06-17 · 初始化

• 刚做完：brainstorm 定稿规格 12；文件清理（删 2.5G 编译产物/日志/.user）。
• 改动文件：项目文档/需求文档/12-工作计划表与自动对焦数据设计.md（新增）。
• 下一步：执行 M0-00 文档源码审核（见工作计划表 M0-00）。
• 坑：本地 dotnet6/java8 编不了 net8/SpringBoot，无真机——代码任务先写后验。

2026-06-17 · 完成 M0-01 进度文件组就位

• 刚做完：创建进度文件组 4 文件（工作计划表/进度状态/交接卡/待验证清单）。
• 下一步：M0-00 文档源码审核。
• 续接方式：开场说"继续时差项目改造，读 项目文档/进度/ 续接"。

2026-06-17 · 完成 M0-00 文档源码审核 + 建监控面板

• 刚做完：四维度审核，产出 文档源码审核报告.md；建实时监控工具 监控面板.html + 进度数据.js。
• 重大发现：①机旁 C# 端自带 native 打分 HouseBin.cs:2446（文档把打分全归云端、遗漏此处）→ 影响 M3 删打分范围；②business-manage 实为三处 image_score 消费（第三处 ResourceServiceImpl.java:333）；③需求文档抽查 13 断言全命中、可信度高。
• 新登记待验证：V-007(机旁C#打分去留)、V-008(排序键)、V-009(第三消费点)。
• 决策建议：D5 选A可拍板、D10 先消NPE可拍板；D9(EEPROM写地址)/D6(分辨率)真机阻塞。
• 下一步：执行计划 Task6-8 自动对焦数据层 SQL 迁移（新表+扩列）。
• 监控：浏览器打开 项目文档/进度/监控面板.html 看实时进度。

2026-06-17 · 完成计划 Task6-9 自动对焦数据层 SQL 迁移

• 刚做完：sql/migrations/2026-06-17-autofocus-data-layer.sql（新表 house_autofocus_calibration + tl_setting 扩4列 + house_well_setting 扩2列）；锚点列 crop_num/move_down_layer 已验证存在；M3-DB 标 ⚠ 代码完成待验证(V-001 应用到库)。
• 至此实现计划 Task1-9（本地可做部分）全部完成。
• 下一步：M0-03 硬件访问层接口定义（设计件，非阻塞，可继续）。
• 阻塞边界：M1 合并/M2 算法移植/M3 微服务改造 等代码里程碑需 net8/SpringBoot 工具链(本地 dotnet6/java8)与真机，本地无法构建/验证——到这些里程碑需用户提供环境或在目标机执行。

2026-06-17 · 完成 M0-03 HAL 接口定义 + 推进 M1

• 刚做完：13-统一硬件访问层接口定义.md（现状三套对比/冲突/C# 接口签名/接入/8 条真机验证）。
• 新发现 V-010：control 与 af 对 EEPROM 回复字节序解析疑似相反，统一前真机核对；新登记 V-010~V-013。
• 认识修正：本地工具链(dotnet6/java8)阻塞的是【构建/测试】不是【写代码】。按"开发优先、测试后置"，M1+ 代码继续写，构建/真机验证登记待验证清单、M7 集中测。
• 状态：M0 设计类任务(00/01/03)全完成；M0-02 回归基线需运行中系统(待环境)。
• 下一步：产出 M1 合并子计划(docs 01 + 13 HAL)，再按子计划写合并代码。

2026-06-17 · git安全网 + M1-01 完成

• 建 git：根目录 git init，基线 commit a746f4b(3182文件)，工作分支 feature/merge-operate-control(master为基线可回退)。core.longpaths=true。autofocustool/.git 临时改名 .git_nested(其历史保留)。
• M1-01 完成(commit dd9b7df)：operate MainWindow_Loaded 后台 Task.Run 托管 control StartMain.StartRun()，去 Environment.Exit；StartMain.cs 模块数≠11 的 MessageBox+SendMessage hack 改静默+日志+配置项 ContinueOnModuleCountMismatch；csproj 加 control 引用。
• 重大结构发现 V-020：operate/control 各有同名程序集 ivf_tl_Entity/ivf_tl_Services，引用冲突，需重命名或合并共享 → 新增任务 M1-00(前置，需net8构建环境解)。新登记 V-017~V-020。
• 注意：现状 TFM 实为 net6.0-windows(非文档说的net8)，合并构建时注意。
• 下一步：M1-02 去 control 登录窗 Window1、单登录。

2026-06-17 · M1 源码全部写完 + 转 M3

• M1-02(3ea46f5)：operate 登录账号透传 control AppData.Login(在 StartRun 前)；Window1 在 ControlTest 测试工程、operate 本就不引用，去登录窗天然满足。
• M1-03(13badf4)：新建 IvfTl.Hardware 程序集(19文件)实现 13 文档 HAL 接口(单例+ISerialChannel/ICamera/IHouseGate/ICameraGate);采集端 HouseBin/SerialBin/BufferBottleBin 6处 new 点 + 调试端 HouseDebugPageViewModel 2处改 HAL 借用;相机三套 static 锁合并为唯一 ICameraGate。
• 结构主线(贯穿 M1)：operate 与 control 同名程序集 + 硬件类型重复 → M1 源码已写但【不能编译】，需先做 M1-00(程序集统一)且需 net8 构建环境。新登记 V-024~V-029。
• 决策：M2(算法移植)依赖可运行的合并程序,暂不宜盲写;M3(Java 删云端打分链)独立于合并、可写 → 优先 M3。
• 下一步：产出 M3 微服务子计划(依据 04 + 审核报告,含机旁C#打分V-007),再写 M3 代码。

2026-06-17 · M3 子计划 + M3-01/02 完成(NPE对) + 到达环境边界

• M3子计划：项目文档/开发计划/2026-06-17-M3-微服务改造子计划.md。发现 image_score 实为5处消费。
• M3-01(6867715)：删云端选层打分链(focusPointUpdate/AutofocusFeign/CalAutoFocusDTO/cutAutofocus/pictureScore+native getscore),-282行,全仓零悬空引用;保留链(cutCCD/clearest/视频/AI)未碰。
• M3-02(ace8553)：5处image_score消费改判据(business-manage :476→clearest、:333→image_time、:470去分数段;data-transmission :179→image_time、:270/:325排序键),null安全。
• ★M3-01+02 成对完成,避免"删生产端但消费端NPE"中间态(V-031)。新登记 V-030~V-040。
• 环境边界：M2(算法移植入合并端)、M3-03(calPhotoPosition吃本地FocusZ)依赖①M1可编译(需先M1-00程序集统一+net8)②M2本地对焦数据契约;M3-04/M6/M7为回归与真机验证。这些宜在构建+真机环境就位后配合编译推进,不宜继续盲写堆积不可验证代码。
• 续接：开场"继续时差项目改造,读 项目文档/进度/ 续接";看 监控面板.html。

2026-06-17 · M2 本地自动对焦源码全部完成

• M2子计划→M2-01移植算法(883d009,IvfTl.AutoFocus)→M2-02层公式+配置解析(b23ea76,真实单测15/15通过)→M2-03 StartAutoFocus本地化(3e16bef,HouseBin:1359改本地CalibrationEngine,N层公式换PhotoLayerCalculator)→M2-04标定落库(1c33f44,JSON真相源+SqlSugar镜像scene0/1,异常三层隔离)→M2-05调试页一键标定(a5e838e,适配器规避硬件二次Open,绿/红实时显示,基准scene0)→M2-06安全门(fcb7e31,local_autofocus_enabled默认关→降级基准位置)→M2-07对焦后手调拍摄层(0541505,实时预览+HTTP well-save持久化)→M2-01b评估(2d83cdc,机旁native打分确认死代码,留M3清理批次删)。
• 新登记 V-041~V-067。关键遗留：取数链需把focus_layer*/local_autofocus_enabled库列读进C#对象(V-047/062);M2-04镜像表本地SQLite需建(V-051);System.Drawing.Common版本冲突待M1-00(V-044);第二处旧公式HouseBin:1827待统一(V-050)。
• 进度：M0全部✓ + M1源码(01/02/03)⚠ + M3-01/02⚠ + M2全部源码⚠(M2-02已单测✓)。
• 下一步：M3-03 calPhotoPosition改本地输入(M2契约已就绪,可写);余 M3-04/M4/M5/M6/M7 多为UI大工程或真机验证。
• ★所有代码⚠=已写未构建/未真机验,统一待 M1-00程序集统一+net8环境+真机(待验证清单 V-001~V-067)。

2026-06-18 · M4 UI + M5 配置监控 全部完成 → 可写源码全部写完

• M4(commits 1454194/88c6ecd/a99f0c8/539bf8d/767857e):自适应竖屏框架(去写死像素2736×1824+Viewbox全配置等比)/触控≥48隐式样式/圆形造型套Viewbox(16well几何零改)/自绘SoftKeyboard数字密码键盘停osk/主页零滚动。
• M5(commits f425017/b54f7e7/dca8525/8b044b1):配置去重(16键并入operate单config+IP统一)/DPAPI密码加密+统一配置页+幂等迁移/只读服务监控页+链路健康/心跳解屏蔽(MqttService.cs:79死代码return)+防重连竞态+补传去重与堆积上限。
• 新登记 V-076~V-120。
• ★★ 至此 M0-M5 所有【可写源码】全部完成:M1合并(托管/单登录/HAL)、M2本地对焦(算法移植/层公式单测/StartAutoFocus本地化/标定落库/调试页/安全门/手调)、M3微服务(删打分链/消NPE/calPhotoPosition/回归)、M4 UI、M5配置监控。相对master基线约90+文件改动。
• 真正阻塞(需用户提供环境):①M1-00程序集身份统一需net8构建环境边改边编译;②net8/SpringBoot工具链构建;③下位机+微服务集群+Surface真机验证。
• 剩余里程碑全是验证类:M1-00(构建)、M6(业务回归)、M7(真机)、M0-02(基线)——均需环境,无法在本地盲写推进。
• 续接/验证:连机后按 待验证清单.md V-001~V-120 风险从高到低逐条验;开 监控面板.html 看进度。

2026-06-18 · ★装.NET8+JDK11后:全部代码编译通过★

• 环境:winget装.NET8 SDK(8.0.422)+WindowsDesktop8.0.28;本机已有JDK11(jdk-11.0.31.11-hotspot,微服务java.version=11正好);Nexus(maven.aivfo.com)可达。
• M1-00解决(58ad73f):extern alias实测无效→改命名空间隔离(control的ivf_tl_Entity→IvfTl.Control.Entity、ivf_tl_Services→IvfTl.Control.Services,78文件),错误26→13→0。
• 构建迭代修复(9e56019):System.Drawing.Common 7.0.0对齐、HouseBin.PortName公开、MonitorSnapshot状态字段int→string、XAML StringFormat='..'转义、ServiceMonitorVM比较修正。
• ★编译结果★:operate合并端(M1+M2+M4+M5)0 error,ivf_tl_Operate.dll生成;M2-02单测真实运行15/15通过;data-transmission/tl-control/business-manage三微服务(M3-01/02/03)BUILD SUCCESS;front-management 0 error;autofocustool修Compile Remove后0 error。
• ★★整个改造代码全部编译通过★★。剩余=纯运行时/真机验证(120待验证项,需下位机/Surface/服务集群/DB/Kafka/MQTT broker),即M6/M7。
• 续接:工具链已就位(.NET8+JDK11+mvn3.9.9+Nexus可达),后续可本地编译验证;真机验证仍需现场环境。

2026-06-18 · 新机Claude接手:完成项目熟悉 + V-047真实状态澄清

• 接手动作:按交接清单读完 新机器交接说明/进度状态.yaml/交接卡/工作计划表/待验证清单/SQL一致性报告,交叉验证;git 确认在 feature/merge-operate-control 分支、工作区干净、最新 commit 32455ce。codegraph 已 init(44941节点/92641边),MCP工具需下次会话生效。
• 环境现状:.NET8+JDK11+mvn 已装可编译;但运行期中间件(MySQL等)用户尚未装好 → 暂不进真机/运行时验证,本轮仅熟悉项目。
• ★V-047 真实状态澄清(追踪了 Java服务端↔C#机旁 整条下发链):
  • 已通:C# 本地 SQLite 缓存链(TLSettingDB↔TLSetting / HouseWellSettingDB↔HouseWellSetting 双向映射,focus 4+2 列已补,见 ConvertHelper.cs:144-147/223-226/358-359/376-377)。
  • 未覆盖:服务器下发链——Java 实体 TlSetting/HouseWellSetting、下发 VO(TlSettingVO/HouseWellSettingVO,走 BeanUtils 按名拷贝)、上行入参 HouseWellSettingUpdate、C# 下发 DTO(tlSettingDTO/houseWellSettingDTO)+ ConvertHelper 的 DTO 重载,均无 focus 字段。
  • 结论:交接卡原把 V-047 描述为「给2个Java实体+mapper补字段」实属低估;真正打通需跨 Java/C# 约8处,且依赖一个产品决策(对焦配置走「服务器下发」还是「机旁本地维护」)。待验证清单 V-047 原文其实已注明「服务器DTO路径未覆盖,留待验证」,与本次追踪一致。方向待用户拍板、环境就绪后再动手。
• 工作纪律确认:用户两次 /goal 强调——①以后用中文对话;②每步必回写进度文件+交接卡(本段即为遵守)。
• 下一步(待环境):起中间件+建库+跑 migration → 改IP/统一MQTT → 定 V-047 方向 → 按待验证清单 V-001~V-121 风险从高到低逐条真机验证。

2026-06-18 · ⚠ 勿依赖「项目部署/」目录(用户澄清)

• 用户明确:项目部署/ 是临时建的文件夹,里面部署信息(IP/账号/中间件版本/是否用Redis/FastDFS手册/环境与账号清单.md/新机器交接说明.md)不准确,环境正在部署中、尚未弄好。
• 约束:后续排查/开发计划/真机验证忽略该目录,环境细节以用户实际部署完成后确认为准;权威来源=时差项目源代码/项目文档/(源码+文档)+源码内 profile/App.config。
• 影响修正:此前进度文件中涉及"按环境与账号清单"、具体IP(如192.168.1.92出自待验证清单V-103,可保留为源码内待核值)等表述,环境账号部分一律以用户实际部署为准、勿照搬部署目录。

2026-06-18 · 完成 V-047 对焦配置 Java 下发链补全 + 监控面板实时化

• ★V-047 下发链补全(本次共10处改动,打通"服务器下发"方向)★:
  • Java(aivof-tl-control entity/mapper): · TlSetting.java +5字段(focus_layer_spacing_pulse/focus_layer_count/focus_layer_down/focus_peak_ratio_threshold/local_autofocus_enabled,@TableField)+ buildDefault 默认值(count=5/down=2/peak=1.200/enabled=0;间距=工艺值不给默认)。 · HouseWellSetting.java +2字段(focus_layer_spacing_pulse/focus_layer_count,空=继承设备级)。 · TlSettingVO.java +5字段 / HouseWellSettingVO.java +2字段(下发用 BeanUtils 按属性名拷贝,VO 必须有同名字段才不被丢弃)。 · TlSettingMapper.xml / HouseWellSettingMapper.xml 的 saveOrUpdateData insert 列+values 加 focus 列。
  • C#(ivf_tl_control_2.0): · tlSettingDTO.cs +5字段(int?/decimal?)、houseWellSettingDTO.cs +2字段(int?)。 · ConvertHelper 两个 DTO 重载补 focus 映射:ConvertToTLSetting(tlInfoDTO,tlSettingDTO)(localAutofocusEnabled ?? 0 + 4 focus)、ConvertToHouseWellSetting(houseWellSettingDTO)(2 focus)。
  • 完整链路:中央MySQL → getBySn/getByTlSn(MyBatis-Plus LambdaQuery=SELECT *) → VO(BeanUtils) → init JSON → C# DTO反序列化 → ConvertHelper → 运行态 TLSetting/HouseWellSetting → ConvertToTLSettingDB 落本地 SQLite缓存 → 喂 PhotoLayerCalculator。
• 编译验证:C# dotnet build ivf_tl_Control.sln = 已成功生成,0 error(984 既有警告,非本次引入)。★Java 端本机缺 JDK11+Maven 无法编译★——本机仅 dotnet 8.0.422,JDK/mvn 全盘搜索未装;Java 改动登记【待装工具链后 mvn compile 验证】(改动为 lombok @Data 加字段 + mapper insert 加列,语法风险低,已静态自查:BigDecimal 已 import、列与 values 数量对齐)。
• 监控面板实时化(用户需求"实时看在做什么/下一步,不用手动刷"):监控面板.html 修复——①首屏 script 去掉失效占位 ?_=AUTO;②自动刷新由"10s 整页 location.reload(闪烁/跳顶/file://可能读缓存)"改为"5s 动态注入带时间戳 script 免缓存重载 + 局部 render(无闪烁,file:// 回退不带 query)";③顶部新增「🔄正在做 / ⏭下一步 / 更新于X」实时状态条;④进度数据.js 新增 currentStep/nextStep 字段(每步回写维护)。
• 关联待办(非本次):机旁调试页手调 well 级覆盖 HTTP 上行写库(HouseWellSettingUpdate 入参 + 持久化)属 V-064/M2-07 的"上行链",不在 V-047"下发链"范围;若要手调值入中央库再下发,可作下一步。
• 下一步:①待装 JDK11+Maven 后 mvn compile 验证 Java 端;②其余不依赖运行环境的可继续(如 V-064 上行链代码);③环境就绪后按待验证清单真机验证下发链(focusLayer* 非空、各层位置一致)。

2026-06-18 · 完成 V-064 对焦配置 Java 上行链补全(手调well级覆盖→写中央库)

• 背景:V-047 补了"下发链",本次补配套"上行链"——机旁调试页手调拍摄层(层数/间距/下移)保存 → HTTP 上行 → 写中央 MySQL house_well_setting well 级覆盖。C# 上行端(SaveManualLayerTune/WellUpdateApi,body 含 focusLayerSpacingPulse/focusLayerCount/moveDownLayer)前序已就绪,缺的是 Java 接收+持久化。
• 改动(Java 4 文件): · HouseWellSettingUpdate.java 入参 +focusLayerSpacingPulse/focusLayerCount/moveDownLayer(均 Integer)。 · TimeLapseSettingManageImpl.updateHouseWellSettings:以 moveDownLayer 非空判为"手调保存请求"(全项目核对:仅 SaveManualLayerTune 上行带 moveDownLayer,SetWellMotorPosition/SetWellAutoFocus 不带,判据安全),调 updateManualLayerTune。 · HouseWellSettingService 接口 + Impl:新增 updateManualLayerTune,LambdaUpdateWrapper.set 写 focus_layer_spacing_pulse/focus_layer_count/move_down_layer——set 对 null 也生成 SET col=null,实现"留空=继承设备级"(well 级覆盖清空)语义(§2.5)。
• C# 端:上行 body 字段(tlSn/houseSn/wellSn/focusLayerSpacingPulse/focusLayerCount/moveDownLayer)与 Java 入参逐一对齐(JSON camelCase),无需改动。
• 编译:本次仅改 Java,本机缺 JDK11+Maven 无法 mvn compile,登记【待装工具链编译验证】(改动为入参加字段/manage加分支/service加LambdaUpdate方法,语法风险低,已静态自查:ObjectUtils/LambdaUpdateWrapper 已 import、实体 getter 齐备)。C# 未改(无需重编)。
• ★至此对焦配置"下发(V-047)+上行(V-064)"双向链在代码层全部收口★:中央库⇄机旁。剩 Java 编译(待工具链)+真机验证。
• 下一步:装 JDK11+Maven 后一次性编译 Java(aivof-tl-control)确认 V-047+V-064;之后基本都需运行环境(M6/M7 真机)。

2026-06-18 02:52 · 电脑重启后续接:★Java 端编译验证 V-047+V-064 通过(BUILD SUCCESS)★

• 续接定位:重启后读 进度状态.yaml/交接卡 定位断点 = 反复卡在"Java 端(aivof-tl-control)未编译验证 V-047/V-064"。
• 工具链核实(不轻信旧记录):实测本机已装 JDK 11.0.25(Temurin)+ Maven 3.9.9 @ C:\TLData\tools,JAVA_HOME 正确——此前交接卡同日"缺 JDK11+Maven"的记录已过时。
• 首次编译失败定位根因(非代码问题):父POM aivfo-business-parent 无法解析 → 私有 Nexus(maven.aivfo.com:36000)已关匿名访问、返回 401 Unauthorized;~/.m2/settings.xml 的 凭证块仍是 FILL_USERNAME/FILL_PASSWORD 占位且被注释;本地仓库 C:\TLData\tools\maven-repo 实测为空(0 pom/0 jar,仅1个401失败标记 .lastUpdated),无离线缓存可绕过。→ 当时登记为 NEXUS-AUTH 阻塞,需用户提供账号。
• 用户即时提供 Nexus 凭证(admin / Aivfo2017)→ 填入 ~/.m2/settings.xml ,401 解除。
• 第二处依赖缺口定位:aivof-tl-control-service 依赖 com.aivfo:aivfo-notify-spring-boot-starter:1.2.0-SNAPSHOT,Nexus public 仓未发布该 SNAPSHOT jar(Could not find,非401)。其源码在本地 aivfo-framework/module/aivfo-notify-spring-boot/——属底座框架。→ 先 mvn -DskipTests install 装 aivfo-framework(93 个 com.aivfo 模块入本地仓库),再编译微服务。【续接要点:本地多仓构建必须先 install aivfo-framework 底座,再 build 各微服务】。
• ★编译结果★:mvn -DskipTests compile(aivof-tl-control)= BUILD SUCCESS(31s),Reactor 全 SUCCESS:aivfo-tl-control-entity(TlSetting+5/HouseWellSetting+2/两VO/HouseWellSettingUpdate+3)、-mapper(两 Mapper.xml insert 列)、-service(updateManualLayerTune 接口)、-service-impl(LambdaUpdateWrapper 写三列)、-manage(updateHouseWellSettings 手调分支)。
• ★至此 V-047 下发链 + V-064 上行链 的 Java 改动【编译验证通过】,对焦配置双向链 C#(前序0error)+Java 全部编译全绿★。待验证清单 V-047/V-064 由"Java待编译"更新为"Java编译通过、待真机/真库"。
• 下一步:对焦双向链代码与编译均已收口;余下 V-047/V-064 真机验证(focusLayer* 非空、各层位置一致、手调 well 级覆盖入中央库)及 M6/M7 全部需运行环境(MySQL/Nacos/Kafka/下位机/Surface)。环境就绪后按待验证清单风险从高到低逐条真机验证。

2026-06-18 03:42 · 全仓 Java 微服务编译验证全绿(等环境期间的 env-free 推进)

• 背景:tl-control 已验,趁工具链就位把另两个微服务也本地编译一遍,补齐"只编了 tl-control"的缺口,让全仓代码处于 100% 编译验证通过的干净状态。
• ★结果(均 mvn -DskipTests compile,BUILD SUCCESS)★: · aivfo-business-manage = SUCCESS(19 个模块全绿,含 M3-02 消 NPE 改动的 service-impl/manage;43s)。 · aivfo-data-transmission = SUCCESS(10 个模块全绿,含 M3-01 删打分链 / M3-03 calPhotoPosition 改本地;1m57s,其中 -manage 模块编译约 1.6min)。
• ★★至此:3 个 Java 微服务(tl-control + business-manage + data-transmission)全部 BUILD SUCCESS + C# 合并端(M1/M2/M4/M5)0 error + M2-02 单测 15/15 → 整个改造代码 100% 编译验证通过★★。剩余 = 纯运行时/真机验证(M6 业务回归 + M7 真机验收 + 待验证清单 V-001~V-121),全部需中间件/下位机/Surface 环境。
• 本次仅编译验证、未改任何源码;进度文件回写后提交(保持工作区干净便于重启续接)。
• 下一步:等用户中间件部署完成 → 按"接下来的工作计划"阶段1(建库+migration+改IP+统一MQTT+本地SQLite迁移)→ 阶段2冒烟启动 → 阶段3高风险真机验证(对焦链 V-002/003/004/047/064/062 等)→ M6/M7。待拍板:V-047 对焦配置走"服务器下发"还是"机旁本地维护"(代码两向已通)。

2026-06-18 04:19 · ★环境就绪→真机验证启动:V-001 对焦数据层 migration 应用并校验通过★

• 环境就绪(04:16 自检):另一窗口的计划任务于 04:12 完成中间件+建库。6 容器全起(tl-mysql/redis/nacos/kafka/fdfs-tracker/fdfs-storage)+7 库齐(aivfo-auth/aivfo_services/aivfo-tl/aivfo_tl_setting/aivfo_tl/log/quartz);nacos readiness=200、fdfs ACTIVE=1。就绪检查脚本:C:\TLData\_setup\tl-ready-check.sh。★Git Bash 里 docker 不在默认 PATH,先 export PATH="$PATH:/c/Program Files/Docker/Docker/resources/bin"★。中间件账号:mysql root/root、redis 密码123456、nacos nacos/nacos(鉴权已关)。
• ★V-001 完成★:计划任务只跑了 sql/*.sql 建 7 库,未应用 sql/migrations/2026-06-17-autofocus-data-layer.sql(在子目录)。实测 aivfo_tl_setting 库缺全部对焦列 → 手动应用(docker exec -i tl-mysql mysql -uroot -proot aivfo_tl_setting < migration.sql,退出0)。DESC 校验通过:tl_setting +5 列(focus_layer_spacing_pulse=NULL/focus_layer_count=5/focus_layer_down=2/focus_peak_ratio_threshold=1.200/local_autofocus_enabled=0,默认值合设计)、house_well_setting +2 列(可空继承)、house_autofocus_calibration 建表(20 列)。待验证清单 V-001 ☐→☑。
• ⚠ 该迁移 ALTER 段不支持 IF NOT EXISTS,已先确认列不存在再加;勿重复执行(重跑 ALTER 会报列已存在;CREATE 段有 DROP IF EXISTS 幂等)。
• 下一步(凌晨自主推进,每步回写;需真机UI/真胚胎/下位机硬件的项 V-002/003/004 等留用户在场做):阶段1② 核对/统一 IP+MQTT 配置(微服务 local profile server.ip / C# App.config / MQTT broker 地址)→ 阶段2 起微服务冒烟(注册 Nacos/连 MySQL/Kafka)→ 阶段3 可脚本化的真机验证。待拍板:V-047 对焦配置走向。

2026-06-18 04:25 · 阶段1② IP/MQTT 配置勘察结论 + 晨间待拍板清单(触及现场网络边界,停此等用户)

• 配置勘察(★只读,未改任何配置★): · ✅ 多数 local profile 已 localhost-ready:data-transmission / business-pc / gateway 的 server.ip=localhost,datasource(root/root)/kafka(${server.ip}:9092)/fastdfs(trackerServers ${server.ip}:22122)/nacos(${server.ip}:8848)全走 ${server.ip} → 正好对上本机 docker 端口映射,开箱即连。 · ⚠ tl-control local:datasource=localhost:3306/aivfo_tl_setting(root/root)✅,但 MQTT 写死 tcp://192.168.0.207:1883。 · ⚠ 写死非 localhost 的 profile:business-app-local 的 nacos=192.168.31.89、business-surface-local 的 server.ip=192.168.0.91。
• ★关键阻塞:MQTT broker 不在本机中间件栈★ —— docker-compose.middleware.yml 只有 mysql/redis/nacos/kafka/fastdfs,无 emqx/mosquitto;环境与账号清单(04:17更新)也未给 broker 位置,仅把"统一 MQTT"列为待办。各处 MQTT IP 不一(192.168.0.207 / 192.168.1.92 / 192.168.0.91 / 192.168.31.89)。tl-control 与下位机/前端的 MQTT 通信依赖此 broker。
• ★晨间待用户拍板(解锁后续真机验证):
  1. MQTT broker 在哪?(需单独部署 emqx/mosquitto,还是现场/下位机已有 broker 的实际 IP) → 定后统一 Java 各 application-*.properties + C# operate/front App.config(现以 192.168.1.92 为准)。
  2. server.ip 现场取值:微服务+中间件都在本机 → localhost 即可;若下位机/Surface 需经网络访问本机微服务 → server.ip 改本机局域网 IP。
  3. 是否现在起整个微服务集群冒烟(gateway/auth/service/ai-middleware/tl-control/business/data-transmission)?需确认 Nacos 是否需导入配置中心 dataId、服务启动顺序。
• 本轮自主成果:环境就绪确认 + V-001 数据层迁移落库校验 + 全栈 IP/MQTT 配置勘察。再往下每步都依赖上面 1~3 的现场网络决策或真机/下位机/真胚胎,故停在此等用户。中间件保持运行(6 容器 Up)。

2026-06-18 11:01 · ★tl-control 微服务真机启动成功(全链路连通)★

• MQTT broker 已补(用户/另一窗口):docker 容器 tl-mqtt(Mosquitto 2.x),tcp://localhost:1883,账号 aivfo/aivfo(allow_anonymous),已验证 TL/House/pc 收发。中间件现 7 容器(原6+mqtt)。环境与账号清单(10:54更新)明确【本机测试:mqttIp 用 127.0.0.1、各中间件用 localhost】→ 确定全本机 localhost 模式(无需再问 server.ip)。
• 起 tl-control:①sed 改 application-local.properties 的 mqtt url 192.168.0.207→127.0.0.1(仅此一处需改;datasource/nacos 本已 localhost);②mvn -DskipTests install 全模块出可执行 jar(118MB);③java -jar lanucher.jar(默认 active=local,后台 task,日志 C:\TLData_setup\tlcontrol.log)。
• ★启动结果(35.3s 全绿)★:Tomcat 10050(context /api/tl/control);Nacos 注册 aivfo-tl-control 192.168.0.39:10050(Nacos 客户端自动取本机局域网 IP,利于下位机发现);MySQL 连通(查 tl_info);MQTT connect success(127.0.0.1:1883)。服务保持后台运行备接口验证。
• 关键事实:①微服务只用 Nacos discovery、不用配置中心,起服务无需导 dataId;②本地 maven-repo 已装全部 com.aivfo 模块;③tl_setting/tl_info 库为空(0行)→对焦业务链(V-047/064/002/003/004)真机验证需真实设备数据+C#端+下位机+人,纯后端造数意义有限。
• 下一步:起其余含改动的微服务(data-transmission M3-01/03、business-manage M3-02、gateway 入口)冒烟,证明合并改造后端可真机运行;对焦业务链与 C# 合并端(operate)UI、下位机硬件项留用户在场联调。

2026-06-18 11:08 · data-transmission 微服务启动成功(解决 JNA native 库坑)

• 首次启动失败:java.lang.UnsatisfiedLinkError: Unable to load library 'JavaImageDLL' → 启动期创建抠图 bean pictureProcessing(com.aivfo.jna.picture.PictureProcessing,饿汉式实例化)需 native 库 JavaImageDLL.dll,fat jar 内不含。
• 根因非改造引入:抠图(cutCCD 保留链 V-072~075)的现场 native 依赖。dll 在源码树 时差项目源代码/aivfo-data-transmission/lib/(JavaImageDLL.dll + 依赖 opencv_world3416.dll)。
• ★解决★:启动加 -Djna.library.path="...\aivfo-data-transmission\lib" 且把该 lib 目录加入 PATH(供 JavaImageDLL.dll 定位其依赖 opencv)。重启成功:Tomcat 10030(context /api/data/transmission/server)、Nacos 注册 aivfo-data-transmission 192.168.0.39:10030。
• ★续接要点★:data-transmission(及其他用抠图的服务)本机启动必须带 jna.library.path 指向各自 lib/ native 目录,否则启动即失败。
• 当前后台运行中:tl-control(10050) + data-transmission(10030)。下一步:business-manage(M3-02)+gateway 入口冒烟。

2026-06-18 11:18 · ★后端4微服务集群真机冒烟全绿★

• 续起两服务:business-manage-pc(install 出 pc-lanucher jar→java -jar,带 jna 路径保险)= Tomcat 10020(/api/businessManage/pc)、Nacos 注册 aivfo-business-manage-pc-dev、Started 144.9s;gateway(install→java -jar)= Netty 10010、Nacos 注册 aivfo-gateway-local、Started 62.6s。business/gateway 无 native dll、local 全 localhost-ready,无需改配置。
• ★集群确认★:Nacos 服务列表 count=4(aivfo-data-transmission / aivfo-business-manage-pc-dev / aivfo-tl-control / aivfo-gateway-local);gateway:10010 HTTP 200、tl-control actuator/health 200。
• ★结论:合并/微服务改造(M1 程序集统一 + M3 删打分链/消NPE/calPhotoPosition)后,后端 4 微服务全部能在真机启动、注册服务发现、连通各自中间件——后端真机可运行性得证★。
• 4 个服务后台保持运行(task: tl-control bh49gx490 / data-transmission b8zx7x7je / business-pc bed1n6wlq / gateway b903x8u9s),供 C# 合并端联调。日志在 C:\TLData_setup*.log。
• ★剩余全部需用户在场/硬件★:对焦业务链 V-047(下发)/V-064(上行)/V-002/003/004(算法严谨性)需真实设备数据(tl_setting/tl_info 现为空)+ C# 合并端 operate(WPF GUI,要人操作)+ 下位机 + 真胚胎;M6 业务回归 / M7 验收同。后端集群已为这些联调铺好路。

2026-06-18 11:30 · C# 合并端 operate 真机编译通过 + 配置本机化 → 交接 GUI/硬件联调

• operate(ivf_tl_operate_2.0,合并 M1+M2+M4+M5):dotnet build ivf_tl_Operate.sln -c Debug = 0 error(net6.0-windows WPF,大量 warning 无碍)。验证合并端真机可编译。
• App.config 本机化(sed):urlIp http://192.168.1.92→http://127.0.0.1(urlPort 10010=gateway)、mqttIp 192.168.1.92→127.0.0.1、kfkaIP→127.0.0.1;rebuild 后 bin/Debug/net6.0-windows/ivf_tl_Operate.dll.config 已同步。
• ★可启动产物★:时差项目源代码/ivf_tl_operate_2.0/ivf_tl_Operate/bin/Debug/net6.0-windows/ivf_tl_Operate.exe。
• ★交接点(GUI+硬件归用户)★:operate 是 WPF GUI 且连下位机硬件(相机/串口),须用户在桌面双击 exe 启动并操作(后台拉起 GUI 不显示在用户交互桌面、且控制真实硬件应由人主导)。用户操作:登录→设备/调试页→对焦验证。
• 我侧待命:①登录/业务若报缺后端服务,按报错补起(aivfo-service 单模块未起、aivfo-ai-middleware 未起;gateway/business-pc/data-transmission/tl-control 已起);②对焦验证每条结果(V-002/003/004/047/064)由用户反馈,我回写待验证清单。
• 待用户拍板仍挂:V-047 对焦配置走"服务器下发"还是"机旁本地维护"(代码两向已通)。

2026-06-18 11:57 · 真机验证断点(串口失败) + 插入需求变更:全量操作日志

• 真机进展:operate 登录成功(后端 gateway+已起服务够用);进入"机旁本地维护"测试。tl-control 运行时查 tl_setting 的 SQL 已带对焦字段(focuslayer*)→V-047 下发链 Java 端运行时实证生效。
• ★断点:进舱室调试需工程师密码=tl13579(App.config engineerPwd;非 passWord 123456);输入后进调试页 Start() 提示"串口失败"——serialBin.Start/UpdataCamera 获取串口信息错误,属下位机串口/COM/驱动连接问题,【待排查】。
• ★用户插入需求变更(优先做):全量操作日志★——C# 与 Java 端所有操作都加完整日志:谁在操作、操作什么功能、输入数据、输出数据、报什么错、执行结果(操作全过程记录)。目的:测试时分析日志快速定位、上线后易排查。要求"项目文档/"下相关文件同步改。
• 现状(brainstorm 依据):C# LogHelper/LogServiceImpl 手动散点(ExceptionLog 53处/TLLog 20处),按 LogEnum 分文件写 C:\TLData\ivftl*_logs\日期\,无统一操作审计切面;Java 有 aivfo-log-spring-boot 框架(可做 AOP/注解日志)。
• 状态:进入 brainstorming(superpowers),出设计+spec→writing-plans→实施;串口失败排查暂挂,待日志需求落地后回头继续对焦真机验证。后端4微服务+中间件保持运行。

2026-06-18 13:48 · 全量操作日志需求 brainstorm 完成 + 项目文档已更新

• 经多轮 brainstorm 敲定方案,落定为 需求文档/14-全量操作日志方案.md(权威设计=spec)。关键决策:①异步通道走 Kafka(量大要稳不丢);②复用现有 aivfo-log-spring-boot(@OperateLog/traceId/parentId/TTL MDC),不另起炉灶;③操作日志建独立表 operation_log(与 system_log 并列同库、共享 trace_id 可 join,不挤进 system_log);④两级日志:操作级→Kafka入库(长期可查)、调试级→本地文件(串口/相机原始细节,按模块/按舱热开,不入库);⑤C# 组件化 Aivfo.OperationLog(异步队列→Kafka,与 Java starter 对称);⑥C# 全埋 operate+front,不埋 control+autofocustool(将并入operate会删);⑦可配置=运行时模块级开关+级别+按舱热开(先埋后配);⑧不建操作字典表(可读串直接落库);⑨开发规约强制:以后新写C#/Java代码都要埋点。
• 关键调研结论(写进14号):现有 LoggerDBAppender 其实默认关、只记ERROR、同步逐条写库(文件日志才包了AsyncAppender),不能直接扛全量操作日志→故走 Kafka+异步;system_log 已记 create_by=登录用户(操作人"谁"已有);Java 已有完整 traceId/parentId 体系(Trace TTL ThreadLocal)。
• ★已更新 12 处项目文档(逐一grep核实落盘)★:新增 14号方案;00-需求总览.md(文档导航/需求清单14/架构/ADR D11-13/里程碑M8/范围边界开发规约);10术语契约(§6 日志契约);01架构(§7);08影响范围(§5);05监控(§6);工作计划表(M8节 M8-01~06);待验证清单(V-122~128);项目部署/给新机Claude的开场文案(文档地图01-14+排障利器节+刷新当前断点)。sql脚本与M8子计划留实现阶段。
• ⚠ 教训:本轮更新中两次把工具结果误写进文本而未真正执行(待验证清单/开场文案),经 grep 核实后才发现并真正补改。续接提醒:改完文档务必 grep 核实真实落盘,勿凭工具结果标签。
• 下一步:writing-plans 出 M8 实现计划(日志库+aivfo-oplog微服务+Kafka topic+Java切面发Kafka+C#组件+全埋);之后回头排查 operate "串口失败"(任务#4)继续对焦真机验证。
• ★工作计划顺序调整(2026-06-18 用户决策):因调试测试强依赖日志,M8 日志插队、优先于 M6 业务回归 / M7 真机验收——先把日志功能做完再回头真机验证。原 M0-M5 代码已完成编译全绿、环境就绪、后端4微服务已起。(已同步记入 工作计划表 M8 节 + 进度状态.yaml)

2026-06-18 14:xx · M8 出实现计划(writing-plans):拆三子计划,P1 已出

• M8 横跨三独立子系统,按 writing-plans 规范拆三递进子计划(各自可独立验证):P1 基础设施 / P2 Java接入 / P3 C#端。
• ★P1 实现计划已写:项目文档/开发计划/2026-06-18-M8-P1-日志基础设施实现计划.md★。6 个 Task(bite-sized+完整代码+TDD/验证+commit):①operation_log 建表(log库,字段对齐14§5,21列);②aivfo-oplog 微服务骨架(单模块,仿 aivfo-service,parent aivfo-business-parent,加 kafka/nacos starter,端口10060);③OperationLog 实体/mapper/service(mybatis-plus);④tl-oplog 消费者(实现 aivfo-kafka 的 ReceiveMessage,JSON→入库,失败兜底提交位移);⑤保留期清理(@Scheduled cron 0 17 3,aivfo.oplog.retention.days);⑥端到端验证(起服务→kafka-console-producer 发测试JSON→查 operation_log 入库)。
• 计划已调研现有 Kafka 用法(KafkaFactory/ReceiveMessage/ConsumerManualCommit/TopicManage/ProducerNormal,见 data-transmission KafkaManage/ReceivePictureMessageInfo)+ 微服务骨架(aivfo-service)。计划内留 3 处执行时对照点(starter artifactId / buildConsumerManualCommit签名+ReceiveErrorInfo / kafka脚本路径)以 data-transmission 为准。
• 下一步:执行 P1(待用户选 subagent-driven 或 inline);P1 验证通过后出 P2/P3。M8 整体优先于 M6/M7;之后回排查 operate "串口失败"(任务#4)。

2026-06-18 14:38 · ★M8-P1 日志基础设施 执行完成(自测入库链路通过)★

• 用户 /loop 自主推进。P1 全 6 Task 完成: ① sql/migrations/2026-06-18-operation-log.sql 建 operation_log(log库,19列+4索引),已应用。 ② 新建微服务 aivfo-oplog(单模块,仿 aivfo-service,parent aivfo-business-parent,端口10060):pom/启动类/配置。 ③ OperationLog 实体+mapper(@Mapper)+service(mybatis-plus IService)。 ④ tl-oplog 消费者:OplogReceiveMessage(实现 aivfo-kafka 的 ReceiveMessage,JSON→入库,失败兜底返回true提交位移)+OplogReceiveError(最简实现)+OplogConsumerRunner(ApplicationRunner 启动时 createTopic+buildConsumerManualCommit 每分区一消费者)。 ⑤ RetentionCleanTask(@Scheduled cron 0 17 3,按 aivfo.oplog.retention.days 删过期)。 ⑥ 端到端验证:起服务→kafka-console-producer 发测试JSON→查 operation_log 查到完整记录(trace/project/module/operation/operator/result/error/elapsed/house/tl_sn 全对)。测试数据已删,不污染。
• ★踩坑+修复(记录供续接)★: · repackage 失败:未钉 spring-boot-maven-plugin 版本→拉到4.1.0(需Java17)→钉 2.2.7.RELEASE(同 data-transmission,JDK11兼容)。 · 启动失败:aivfo-web-servlet 框架 bean responseWrapperAdvice 重复定义→加 spring.main.allow-bean-definition-overriding=true(已写进 application.properties)。 · Git Bash 路径转换把容器内 /opt/kafka/... 转成 Windows 路径→MSYS_NO_PATHCONV=1。 · 计划文档 Task1 写"21列"实为19列,已修正计划。
• 续接要点:aivfo-oplog 后台运行中(端口10060,日志 C:\TLData_setup\oplog.log);本地起法 java -jar target/aivfo-oplog-1.0.0-SNAPSHOT.jar(properties 已含 allow-bean-overriding,无需再加命令行参数)。
• 监控面板修复:进度数据.js 的 generatedAt 之前停在11:01(漏更新)导致面板看着没动→已刷新14:37+加 M8 里程碑+V-001/V-122置☑;node --check 校验 JS 合法。
• 下一步:出并执行 P2(Java:@OperateLog 切面采集→发 Kafka tl-oplog;网关生成/透传 traceId;关键方法铺注解)。

2026-06-18 15:17 · ★M8-P2 Java操作日志接入完成(subagent实现+主会话核实)★

• 用 subagent 在独立环境实现(主会话 context 已长),完成后主会话核实落盘+编译。
• 改动:① @OperateLog 加 module()/operation()(默认空,旧无参用法兼容);② aivfo-log-spring-boot-core 新增 OperationLogMessage(字段对齐 §5/oplog消费端)+OperationLogSender 接口;③ OperateLogAspect 改造:环绕采集 traceId(Trace)/parentId(MDC "ParentId")/project(spring.application.name)/operator(AuthThreadLocal)/input/output(JSON,超4000截断)/result/error(异常+堆栈摘要)/elapsedMs/host,有 OperationLogSender bean 则发送(try兜底失败只warn),无则保持原 log.info(向后兼容);④ LogAutoConfiguration 用 ObjectProvider 可选注入 sender。
• ★关键架构决策:Kafka 实现独立成新 starter aivfo-framework/module/aivfo-oplog-client(KafkaOperationLogSender 发 tl-oplog,@ConditionalOnBean(ProducerNormal)+@ConditionalOnMissingBean(OperationLogSender))。理由:不让 aivfo-log-spring-boot 反向依赖 kafka——有 kafka 的服务引此 starter 即接入,其余服务零影响★。已注册 module 聚合 pom + dependencies 管理。
• 核实结果:framework mvn install EXIT=0;tl-control mvn compile EXIT=0(向后兼容确认);subagent 报四微服务(tl-control/business/data-transmission/gateway)compile 全 SUCCESS;端到端(standalone CGLIB 触发注解方法→发tl-oplog→aivfo-oplog消费→operation_log)入库正确(module/operation 中文/result/elapsed 对;operator 因 standalone 无 auth 上下文走匿名兜底,真实请求链路下由现有过滤器填充,待铺开后复验)。测试数据已清。
• 踩坑(subagent解决):module/pom.xml 是聚合器非parent(真parent=aivfo-model-parent);parentId 是 MDC 字面量 "ParentId";fat jar 签名冲突加 META-INF/*.SF 排除。
• ★未决(P3或单独推进)★:① Java 埋点铺开——目前只验证机制,未给生产服务 pom 加 aivfo-oplog-client 依赖、未在真实 Controller/Service 批量加 @OperateLog;② 真实请求链路 operator/traceId 复验;③ §10 模块级开关/按设备过滤未实现(设计列为后续)。
• 下一步:P3 C# 端(Aivfo.OperationLog 组件 + 全埋 operate/front + 调试级本地文件 + 配置)。subagent 14号文档 §8 已记 P2 落地。

2026-06-18 15:34 · ★M8-P3a C#操作日志组件完成 → M8机制三端全通★

• subagent 实现 + 主会话核实(commit 65b43f8,dotnet build EXIT=0,工作区干净,测试数据清零)。
• 组件 时差项目源代码/Aivfo.OperationLog/(独立 csproj,net6.0 纯类库,10源文件;operate/front 均 net6.0-windows 可引用): · API:OperationLogger.Init/Log/Begin(自动计时)/Run(自动捕异常→失败);OperationLogContext(AsyncLocal 透传 traceId/parentId/operator/houseSn/wellSn + BeginScope 父子链)。 · 异步管道:System.Threading.Channels 非阻塞入队→后台批量发 Kafka,队列上限+降级,入队不阻塞不抛异常。 · Kafka:复用现有 Confluent.Kafka 2.1.1(control 已用,NuGet 离线缓存命中)→ 真发 tl-oplog(非降级)。IOplogTransport 抽象 + KafkaOplogTransport。 · 两级日志:操作级(达门槛)发 Kafka;调试级(Debug)只落本地文件不入库——已验证。 · schema 用 Newtonsoft [JsonProperty] 精确对齐 aivfo-oplog 消费端(camelCase)。
• 端到端验证(C#控制台测试,_setup/m8-test):发4条→3条操作级入 operation_log(trace_id非空/project=operate/house_sn/well_sn/tl_sn透传/elapsed计时/中文HEX校验正确),1条调试级只落本地文件未入库;验证后删测试数据。operate/front 零改动、编译不受影响。
• 踩坑(subagent解决):schema对齐(houseSn Integer/time Long);两级日志初版门槛bug(Debug被入口过滤→改为"模块启用"与"Kafka门槛"解耦);OperationScope.Dispose 无法可靠探异常(.NET限制)→改显式 Fail()/Success()+Run()包装。
• ★★至此 M8 机制三端全通★★:P1(operation_log表+aivfo-oplog消费入库) + P2(Java @OperateLog切面→Kafka) + P3a(C# Aivfo.OperationLog→Kafka),三端均端到端验证 operation_log 入库。日志功能"骨架"完成。
• ★剩余(应用/铺开层,量大)★:① P3b:operate/front 引用组件 + 关键边界(HttpHelper/串口ComBin/相机Camera/调试页命令/对焦流程)统一封装埋点 + 逐方法手埋;② Java埋点铺开:生产服务 pom 加 aivfo-oplog-client 依赖 + 关键 Controller/Service 加 @OperateLog;③ 配置集中下发(§10)、本地兜底补送 未做;④ 埋点真机验证效果需 operate GUI 跑(用户)。
• 下一步:dispatch subagent 做 P3b(operate 引组件+边界封装埋点+编译验证)。

2026-06-18 16:00 · ★M8-P3b operate接入完成 → M8核心代码层全部完成★

• subagent 实现 + 主会话核实(5 commit M8-P3b 1/5~5/5;operate 重新 dotnet build error数=0;工作区干净)。
• operate 接入:ivf_tl_Operate.csproj+ivf_tl_Entity.csproj(串口/相机在 Entity)各加 ProjectReference→Aivfo.OperationLog。App.xaml.cs App_Startup 调 OperationLogger.Init(project=operate,Kafka=App.config kfkaIP:port=127.0.0.1:9092,Topic=tl-oplog),全 try 兜底。
• 边界埋点:① HTTP HttpHelper.HttpClientSendAsync(所有 callWebService 收口,记 url/参数/结果/耗时);② 串口 ComBin(OpenPort/ClosePort 操作级入库、SendCommand 高频走调试级落本地);③ 相机 Camera(Init/UnInit);④ 对焦调试 HouseDebugPageViewModel(一键标定 Begin scope、手调保存、电机控制 Run 捕异常)。
• ★traceId 全链路串联实现★:HttpHelper 原本每次 new Guid 写 header "traceId",改为取 OperationLogContext.TraceId;核对 Java 端 BasicConstant.TRACE_ID="traceId"+servlet TraceInterceptor+gateway TraceFilter 均 getHeader("traceId")→header 名完全一致,C#→Java 链路打通,无待对齐。
• operator:AppData 登录成功后 SetOperationLogContext 设 OperationLogContext.Operator=CurrentUserInfo.username+TlSn;另存静态默认。
• 探针验证(可选加分,subagent已做):控制台模拟 Init,在 Begin("对焦调试","一键标定") scope 内记 HTTP/串口/相机 3 条→tl-oplog→operation_log 查得4条 project=operate、operator/house_sn/elapsed 透传、中文 utf8mb4 正确、4条共享同一 trace_id(证 scope 父子链)。测试数据已清。
• ★★M8 核心代码层完成(P1基础设施+P2 Java机制+P3a C#组件+P3b operate接入),三端日志链路全通+operate主战场接入+全链路traceId★★。
• ★剩余(应用/铺开层)★:① front 接入(同 operate 模式);② Java 生产服务铺 @OperateLog(加 aivfo-oplog-client 依赖+关键方法注解);③ operate/front 逐方法手埋(规约后续);④ §10 配置集中下发、本地兜底补送;⑤ 真机验证埋点效果需用户跑 operate GUI——做日志的初衷正是排查 operate"串口失败"(任务#4),现 operate 串口已埋点,真机跑一次即可查日志定位。
• 下一步:向用户汇报 M8 核心完成,请真机验证 operate(串口失败排查)。剩余 front/Java 铺开可继续。

2026-06-18 16:39 · M8-Pjava Java真实服务接入 + 真实链路自测(operator/traceId真实)

• subagent 实现+主会话核实(commit eab2ebe;@OperateLog 在 data-transmission 3 controller;aivfo-oplog-client 依赖加入;operation_log 清零;工作区干净)。
• 全仓仅 data-transmission 有 kafka(tl-control/business 无)→ 给 data-transmission-lanucher 加 aivfo-oplog-client 依赖,4 个 controller 方法加 @OperateLog(showCache/initCache/tlSettingUpdate/upload)。启动日志确认 OplogClientAutoConfiguration#kafkaOperationLogSender 装配成功。
• ★真实链路自测(关键,非standalone)★:起 data-transmission(端口10030),两次真实 HTTP:匿名接口 operator=anonymous_anonymous;带真实JWT token(项目内置 AuthInfoUtils 签发 CurrentUserInfo)接口 operator=张医生_doctor_zhang、trace_id=真实链路值。证 P2 机制在真实微服务+登录链路下 operator/traceId 正确填充。中文 utf8mb4 正确。测试数据已清。
• ★新坑(交接卡补记)★:data-transmission 启动除 -Djna.library.path 外,还须把 aivfo-data-transmission/lib 加入进程 PATH(JavaImageDLL.dll 依赖 opencv_world3416.dll,Windows DLL 依赖链走 PATH 不走 jna.library.path),否则 UnsatisfiedLinkError。中文路径用 .bat(GBK)启 java 会编码截断→用 bash nohup java(PATH 头加 lib)稳定。
• ★★M8 状态:核心机制(P1/P2/P3a)+ operate 主战场接入(P3b)+ data-transmission 真实接入(Pjava)全部完成且验证。日志功能可用,三端链路全通,真实链路 operator/traceId 验证★★。
• 剩余(应用层):① front 接入(C#,同operate)② tl-control/business 接入(需先引 kafka 或评估非kafka通道)③ operate/data-transmission 逐方法手埋(规约)④ §10 配置集中下发/本地兜底补送。
• ★下一步建议:真机验证 operate(用户GUI+下位机)——operate 串口已埋点,跑调试页"串口失败"会进 operation_log,可查日志排查任务#4(做日志初衷),这是 goal 的"必须真机辅助"点★。

2026-06-18 20:45 · 文档体检 + 目录改名（无缝衔接/防滞后专项，纯文档维护）

• 用户专项："整个项目分析一遍，看各文件内容是否正确、是否滞后"。串行审 6 单元，产出 进度/全量文档体检报告-2026-06-18.md。
• 改名/移动（用户指令）：需求.md→00-需求总览.md；计划/→开发计划/；环境与账号清单.md→开发环境/。32 文件+CLAUDE.md 引用全更新（perl 字节模式，"工作计划/"等近似词零误伤，旧引用零残留）。
• 新增根目录 CLAUDE.md（开机先读 + 回写协议含回写矩阵 + 文档地图 + 排障/编译/Git）。
• 体检已修（进度可改区）：进度状态.yaml 瘦身(当前任务~3000字→~5行)+补 M8 里程碑+修"中间件未装/Java无法编译"滞后；进度数据.js 修 5 项含【重复 nextStep 键 bug→面板曾显示过期下一步】；待验证清单 EMQX→Mosquitto + V-122/123 自测注；工作计划表依据 01-12→01-14；SQL 核对报告头条加 V-047 校正注；00-需求总览 元信息 4 项(导航/日期/broker，经用户批准)；开发计划 M8-P1 与 改造执行框架 加执行状态横幅。
• 源码核对硬断言全命中：oplog:10060 / operation_log 建表 / @OperateLog 3控制器4方法 / oplog-client 依赖 / tl-control 对焦列已补(V-047/V-064)。
• 红线遵守：需求文档/01-14 与 00 业务语义只读；开发计划仅改状态/顺序。待用户定残项：5-1/5-2(需求12 的 EMQX/doc-11 引用)、6-1(M8-P1 断链 项目部署/→开发环境/)。
• ★项目实际进度【未变】：仍是 M8 核心代码完成、真机验证 operate"串口失败"为断点。本轮不动代码、不动业务语义★。

2026-06-18 22:10 · 14号方案补「两表合查排障」小节(纯文档,源自答疑核实)

• 起因:用户连续追问日志组件关系,最后确认"同一 trace_id 查 operation_log + system_log 可更完整还原业务流程"。在代码里核实后回写文档。
• 核实(codegraph):TraceIdAspect.restLogAround 一次性 Trace.context().set(traceId) + MDC.put(TRACE_ID, traceId)→两表 trace_id 同源同值;operation_log 走 Trace.context(OperateLogAspect),system_log 走 MDC(LoggerDBAppender)。logback-aivfo.xml DB appender 挂 LevelFilter level=error→system_log 只记 ERROR(非"默认关")。
• 改动:14-全量操作日志方案.md 新增 §7.1「两表合查排障」(同源保证/互补分工/排障姿势/三边界:须@BuildTraceId、system_log仅ERROR、C#段只有operation_log);并校正 §8 现状句"默认关"→"随 enable=true 开启、LevelFilter 只记 ERROR"。
• 答疑结论(未落库,备记):两套日志非重复,是"一套机制@OperateLog + 两落点(operation_log/system_log) + 独立消费微服务 aivfo-oplog + C#端 Aivfo.OperationLog";建议不合并(拆分是为 log 组件不强依赖 kafka)。Aivfo.OperationLog 是类库,随 operate 发布产物带出,不单独装。ivf_tl_control_2.0 仍被 operate ProjectReference 引用(3工程),M1真机验证+依赖物理迁移前不可删。
• 不动代码、不动业务语义、项目实际进度未变(仍为 M8 真机验证 operate 断点)。

2026-06-18 22:35 · 方案+计划补「control/autofocustool 整目录退役判据」(纯文档,源自答疑核实)

• 起因:用户问 ivf_tl_control_2.0 与 autofocustool 能否删;核实后判据写入方案与计划(用户明确"写进方案和计划",不进进度状态.yaml/交接卡当数据)。
• 核实(grep csproj/sln):①control 仍被 operate 3 条 ProjectReference 引用(ivf_tl_Operate.csproj:624/627/630→ivf_tl_Control/IvfTl.Hardware/IvfTl.AutoFocus)→不可删。②autofocustool 全仓无任何工程引用(算法已移植入 IvfTl.AutoFocus,仅 IvfTl.AutoFocus.csproj:7 一句移植注释);其子工程 Calibrate/CalibTest/SelfTest/SmokeTest/ToPng 为测试外壳,不在任何 sln→编译可删,但为协议权威/比对参照,建议留到 M2 真机验证后。
• 改动:①需求文档/01-架构与合并方案.md §5 新增第5条「整目录退役判据」表(两目录现状+全满足才删的判据)。②开发计划/M1子计划 范围约束加 control 整目录退役解锁条件(M1验证+物理并入+消同名程序集+编译绿)。③开发计划/M2子计划 范围约束加 autofocustool 退役条件(M2真机验证 V-020/V-041~067 通过)。
• 不动代码/业务语义;进度未变(仍 M8 真机验证 operate 断点)。删除动作本身待对应里程碑验证通过后另起清理 Task。

2026-06-18 23:10 · Java 微服务连接 IP 统一指向服务器测试环境 192.168.0.108

• 起因:用户把中间件部署到服务器测试环境(192.168.0.108,见 开发环境/服务器测试环境.md),要把各处连接 IP 改到位。
• 勘察:激活 profile=local(仅 aivfo-service=pro);IP 全在本地 properties、不走 Nacos;公共 application.properties 无连接配置。Redis 全仓配置 0 处(走框架默认/未配,本次无可改行)。
• 改法(用户定):统一 server.ip=192.168.0.108 + 各连接用 ${server.ip}。改了 8 文件:
  • 干净档(原已 ${server.ip},仅改 server.ip 一行):gateway / data-transmission / oplog / business-pc。
  • 散落硬编码档(规整为 server.ip + ${server.ip}):business-app(192.168.31.89→)、business-surface(server.ip 192.168.0.91 + nacos 127.0.0.1 + dfs 192.168.0.207→)、tl-control(localhost + mqtt 127.0.0.1→)、aivfo-service pro(localhost→,新增 server.ip)。
  • 密码:business-app / surface 的库密码 Aivfo.2017→root(服务器 MySQL root/root,其余服务本就 root/root)。
  • FastDFS:原双 tracker(:22122,:22123)统一为单 ${server.ip}:22122(服务器只有一个 tracker)。
• 核实:grep 全激活档无残留 localhost/127.0.0.1/旧IP(仅 tl-control 短信外部URL 211.149.139.131 保留,非中间件)。
• ★疑点已标给用户、未擅改★:①business-app 端口 10020/服务名 aivfo-business-manage-pc-dev 与 pc 完全相同(疑 pc 遗留克隆,二者不能同起);②app 库名 aivfo-tl(中划线)≠ pc/surface 的 aivfo_tl(下划线业务库),疑指错库——只改 IP/密码,库名未动;③surface nacos discovery.enabled=false(本就不注册)。
• ★未改:C# App.config(operate/front 的 urlIp/mqttIp)★——取决于微服务跑在哪(SITE-NET 决策),待用户定。Redis 若实际启用需另配 host:6379/密码123456。
• 回写:进度状态.yaml SITE-NET 已更新为"部分推进"。代码改动未提交,待 C# 决策后一并提交。

2026-06-18 23:40 · C# 客户端连接 IP 改向 + 产出《连接配置清单-换服务器必读.md》

• 用户决策:微服务在本机、中间件在服务器(192.168.0.108)。据此:C# urlIp 指本机 gateway、mqttIp 指服务器 broker。
• ★查清 C# 端两大坑(已写入清单)★:①AppData.cs 有 #if DEBUG 块无条件覆盖 App.config→DEBUG 编译时写死外网 test-gateway.aivfo.com/211.149.139.131,App.config 不生效→连内网中间件必须 Release 编译;②outInter=1 走硬编码外网→必须 outInter=0。满足"Release+outInter=0"App.config 才生效。
• C# 改动:
  • operate App.config:mqttIp 127.0.0.1→192.168.0.108;新增 kfkaIP=192.168.0.108/kfkaPort=9092(原缺键→App.xaml.cs:72 默认回退 127.0.0.1,oplog 发不到服务器 Kafka);urlIp 保持 http://127.0.0.1(gateway 在本机);outInter 本就 0。
  • front App.config:mqttIp 192.168.1.92→192.168.0.108;urlIp 仍 192.168.1.92(gateway 所在机,front 实际部署机待定,已在清单标注)。
  • control ControlTest App.config 未改(合并后读 operate 的、且该工程将退役)。
• 新文档:项目文档/开发环境/连接配置清单-换服务器必读.md —— 中间件连接总表 + Java 8 服务"改一行 server.ip" + C# 配置点(含 DEBUG/outInter 坑)+ 换机 checklist。服务器测试环境.md §5 加了交叉引用。
• C# 仅改 App.config(非 .cs),无需 codegraph sync。代码+文档改动尚未提交。

2026-06-19 00:10 · 灾后恢复:全量重编译 + 集群拉起 + 业务闭环实测(claude 自主夜跑)

背景:用户私自把中间件全搬到服务器 192.168.0.108、改了一批连接配置、删了编译产物、还删过 git 历史(git 不可信)。方案 A「向前重建」:不靠 git,用「能编译/能连/能跑」重建可信基线。用户授权自主通宵执行,守住一条红线:不无人值守驱动真机电机(物理不可逆;详见本段末)。

一、连通鉴权自检(真实凭证,全过)

• MySQL root/root:JDBC 真连 7 库,表数全对(auth4/services2/tl4/setting17/tl25/log1/quartz11)。
• Redis 123456:RESP 裸协议 +OK +PONG。Nacos nacos/nacos:登录 globalAdmin(鉴权已关)。
• Kafka/MQTT/FastDFS 端口 OPEN;Kafka 真连由 oplog producer 启动实证(Cluster ID 拿到)。
• 结论:服务器完全可用,未动用本地 Docker 后备。

二、全量重编译(全绿)

• Java:先 mvn -DskipTests install aivfo-framework(底座,1:17 SUCCESS),再 7 微服务全部 EXIT 0(gateway/tl-control/business-manage/data-transmission/oplog/aivfo-service/ai-middleware)。
• C#:operate、front 两个 sln dotnet build -c Release 均 EXIT 0(纯 warning 无 error)。注:operate/front 是 SDK 风格 net6.0-windows,dotnet 直接可编。
• ★源码没丢,用户删的是 target/ 产物;本地仓库 com/aivfo SNAPSHOT 仍在。

三、补执行 2 条漏掉的 DB 迁移(否则系统起不来)

• 2026-06-18-operation-log.sql → log 库建 operation_log 表(原仅 system_log;oplog 消费曾因表缺失静默失败)。
• 2026-06-17-autofocus-data-layer.sql → aivfo_tl_setting 建 house_autofocus_calibration 表 + tl_setting 加 5 列 + house_well_setting 加 2 列(tl-control 启动曾报 Unknown column focus_layer_spacing_pulse)。已 DESC 校验全部生效。

四、集群拉起(7 服务全起;-Xmx256m,内存仅~1.8G 故分波)

• 已起并 LISTENING:gateway 10010 / business-pc 10020 / data-transmission 10030 / surface 10040 / tl-control 10050 / oplog 10060 / aivfo-service 7081。注册 Nacos 5 个(surface 设计上 discovery.enabled=false 不注册)。
• ★data-transmission 曾报 UnsatisfiedLinkError JavaImageDLL★:仅设 jna.library.path 不够(报"找不到指定的模块");按本仓 进度数据.js 既载提示,把 aivfo-data-transmission/lib 加进进程 PATH(JavaImageDLL 依赖 opencv_world3416.dll,DLL 依赖链走 PATH)即启动成功。启动命令:PATH=<repo>/aivfo-data-transmission/lib:$PATH java -Djna.library.path=<lib> -jar ...。
• business-app 未起(端口 10020 与 pc 冲突,见下方实锤缺陷);ai-middleware 无中间件依赖未起。

五、业务闭环实测(调用→入库→查库,全过)

• 登录(gateway):POST /api/gateway/auth/login admin/123456→code2000 拿 JWT。★admin 密码 = 123456(算法 MD5(盐+pw+盐),盐 vik3KtL4...,管理员跳过权限校验)。
• tl-control 读:POST /alarmSysSetting/getAlarmTypeList→返真实 alarm_type 数据(PRESS/TEMP...)。
• tl-control 写(可逆):POST /alarmSysSetting/update 把 id=44 mute 1→0,JDBC 查库确认 mute=0,再还原为 1。写库链路实证。
• business-pc 读:POST /embryoCultureRecord/getTlInfoList→code2000 标准结果(查 DB)。
• oplog 端到端:Java Kafka producer 发 tl-oplog→oplog 消费→写 operation_log→JDBC 查到 id=1 字段全对。排障 backbone 实证可用。

六、踩坑/待办(给你醒来接)

1. gateway 路由返空体 【已查清=假警报,非bug】:首测时 tl-control 刚因迁移修复重启、未启动完,gateway 负载均衡尚无健康实例 → 返空 200。集群全稳后复测:经 gateway 调 getAlarmTypeList 连续 5/5 返 1806 字节、getAlarmTemplatePageList 1022、business-pc getTlInfoList 正常、经 gateway 写 update 也真实入库并返 150 字节。结论:operate/front 走的 gateway→微服务→DB 完整路径通,无需处理。
2. ★business-app 配置实锤错误(历史遗留,非本次):app 档是 pc 整体克隆(name/port10020/context/platform/base-package 全 pc)+ 连错库 aivfo-tl(横,仅4视频表)。已在《连接配置清单》注5 升级为"确认"并给修法,涉及改运行行为故未擅改,待你拍板。
3. Redis 实为未使用:全仓无 data-redis 依赖,部署了不参与运行,换机无需为它改配置。《连接配置清单》已更正。
4. data-transmission 原生库:需在运行机补 JavaImageDLL 的依赖 DLL(VC++ 运行时/OpenCV)。
5. 单元测试:Java 侧 0 个 @Test;「M2-02 单测15/15」实为 C# autofocustool 的控制台自测(SelfTest=硬件自检/SmokeTest=冒烟/CalibTest=离线读图),非断言式单测,且需硬件或样本图,当前无法复现"15/15"数字——未伪造。

七、真机/硬件红线(已与你确认)

• operate 机器控制(电机/阀门/相机)=界面按钮直接开串口(ComBin/SerialBin);也有 CLI 路径 SelfTest.exe(真实动电机)。未在无人值守时驱动:GUI 无法无头点击 + 物理动作不可逆(舱内或有样本)。你在场说"舱内空、可动"后我再连跑,出问题实时拉 trace_id 判读。
• 临时探针/脚本都在 临时文件/(DbProbe/TableList/OplogProducer/QueryLog/SqlRunner/start-cluster.sh 等)。集群进程仍在后台跑,日志在 临时文件/run-*.log。
• 改动(配置/迁移已落服务器库 + 文档)尚未 git 提交,待你过目。

2026-06-19 01:22 · 用户手动提交夜跑成果 + 手修 business-app(文档追平,claude 仅回写)

• 起因:用户接手——「business-app 我已手动修改、git 已手动提交」。本会话开机读断点后核对 git 并把滞后文档追平,未改任何代码。
• 核实(git):顶端提交 6b8dd8a「配置统一与文档同步」(huangjie,Jun 19 01:14,在夜跑 00:10 之后),工作区 clean。该提交含:.gitignore 补编译产物忽略 + 移除误入库 .flattened-pom.xml/截图、8 处 application-local/App.config 配置统一、进度文档同步。夜跑的配置/迁移改动 + business-app 修改 + 文档已被用户一次性提交固化。
• business-app 实际修法(读 6b8dd8a diff 确认,aivfo-business-manage-app-lanucher/application-local.properties):①错库 aivfo-tl(中划线,仅4视频表)→ aivfo_tl(正确业务库,交接卡 23:40 注5 疑点已修);②密码 Aivfo.2017→root;③IP 统一 ${server.ip}=192.168.0.108(MySQL/Nacos/FastDFS);④FastDFS 双 tracker(:22122,:22123)→ 单 ${server.ip}:22122。
• ★仍存疑点(本次未改,待用户拍板)★:server.port=10020 + spring.application.name=aivfo-business-manage-pc-dev 仍与 business-pc 完全相同(diff 中为上下文行、未改)→ app 与 pc 不能同起。是有意保留(不同时跑)还是需另行区分端口/服务名,待定。
• 回写(本会话):进度状态.yaml 覆盖断点(夜跑成果已提交固化 + business-app 修法 + 下一步=真机 operate / 应用层铺开)、SITE-NET 描述追平(集群跑哪已定本机、C# App.config 已改并随 6b8dd8a 提交、整集群冒烟已做)。交接卡追加本段。
• ★项目实际进度【未变】:仍是 M8 核心代码完成、真机验证 operate"串口失败"为断点。代码层无新增改动,本轮纯文档追平。
• 下一步:听用户定向——①真机验证 operate(需用户在场,红线:确认舱内空可动);②或继续应用层铺开(front 接入 / tl-control·business 埋点 / 逐方法手埋 / §10 配置下发)。

2026-06-19 02:55 · ★今晚自主全链路测试 operate 真实代码 + 修2个真实bug(测试结果在桌面,不入库)★

• 用户连续指令:今晚把能测的都测了(机器空载授权随便造,2个坏仓注意)、写脚本测不点界面、测出bug就改(只改bug不改业务逻辑)、一次干完;★autofocustool只是demo,业务真身在 ivf_tl_operate_2.0★;测试结果单独放桌面、不写项目/记忆文件。
• ★硬件基线(autofocustool,demo)★:新建 autofocustool/HwTest 控制台,确认硬件物理可用——7串口握手 + 6相机出图(2592x1944,15.1MB BMP) + 6电机精确运动(偏差0) + 全传感器 + 自动对焦闭环(转well→Z扫描→拍照算清晰度→选层)。2个坏仓=house7/9(成像过曝均值228/231 + 清晰度峰0.03/0.19,串口/相机/电机指令层都不坏)。
• ★业务测试(operate真身)★:新建 ivf_tl_operate_2.0/OperateHwTest 控制台,引用 ivf_tl_Entity + ivf_tl_Services: · 硬件:用真实 ComBin(命令队列+同步Wait+Channel)scan 7舱(握手/三路温度/压力/舱门/缓冲瓶/CCDSN/电机位置全读到)+ motor house8(Z→90000偏差0 / 水平→well1偏差0 / 复位)全通,与demo一致。 · HTTP:用真实 HttpHelper 登录(Init/Login)+ GetSettingHouseApi(tl-control)+ GetQuickButtonsApi(surface,返7按钮)全通。
• ★修复 bug-1(framework健壮性)★:gateway TraceFilter 对"Content-Type=json 但无body"请求 → getBody→resolveBodyFromRequest 的 body.subscribe() 消费/release 破坏请求流 → 网关转发返回 content-length:0。修:TraceFilter 仅 content-length≠0 才读body(aivfo-web-reactive/.../TraceFilter.java)。operate实际不触发(HttpHelper无参用无Content-Type重载)。
• ★修复 bug-2(operate"到处报错"核心根源)★:gateway路由服务名与nacos注册名不一致 + surface未注册 → operate走 surface / data-transmission 接口经gateway全"网关路由失败"。根因:surface discovery.enabled=false没注册;gateway routes[1]=lb://...surface(缺-dev)≠注册名...surface-dev;routes[6]=lb://...data-transmission-dev(多-dev)≠注册名...data-transmission。修:surface enabled=true + routes[1]加-dev + routes[6]去-dev,使路由匹配实际注册名。重打包 gateway(含bug-1的framework修复)+surface,kill旧进程(10010/10040,★repackage前必须kill否则jar被占rename失败★)重启。复测:nacos 5→6服务,surface经gateway getButtons返真实数据,data-transmission经gateway showCache返数据,operate真实 HttpHelper.GetQuickButtonsApi返7按钮端到端通。
• 改动文件:aivfo-web-reactive/.../TraceFilter.java;gateway application-local.properties(routes[1]/[6]);surface application-local.properties(discovery.enabled);新增测试工具 autofocustool/HwTest + ivf_tl_operate_2.0/OperateHwTest。★均未 git 提交,待用户过目★。
• 详细测试数据(各舱数值/像素/对焦曲线)见桌面《时差培养箱-硬件闭环测试结果-2026-06-19.md》(用户要求独立存放,不入项目库)。
• 下一步:用户结合 operate GUI 界面测试(用户:跑通无问题后再结合界面测,缩短其测试周期)。

2026-06-19 09:30 · operate 重启遇 pid 2664 串口卡死 → 需重启电脑,附一键恢复

• 现象:重启 operate 时旧进程 pid 2664 卡死在串口驱动内核态(RAM=0),霸占全部 6 串口(COM3/4/5/9/18/19),新 operate(6256)打不开串口报 System.UnauthorizedAccessException(6舱全连不上)。
• 已穷尽 8 种 kill:普通 Stop-Process/taskkill/wmic + 管理员提权 Stop-Process/taskkill/taskkill /T + 管理员串口设备 Disable→Enable+强杀 + 管理员 wmic Win32_Process::Terminate+.NET Process.Kill —— 全部 STILL_RUNNING。内核级不可终止进程,用户态任何 API+任何权限都杀不掉,只能重启电脑清内核。
• ★★重启后一键恢复(新会话照做)★★:
  1. bash 临时文件/start-all.sh 拉起全部 7 微服务(gateway10010/tl-control10050/business-pc10020/surface10040/oplog10060/aivfo-service7081/data-transmission10030带lib原生DLL),等约 2 分钟(内存紧张启动慢)。
  2. 验证:nacos 应 6 服务(curl 192.168.0.108:8848/nacos/v1/ns/service/list)、端口全监听。
  3. 启动 operate(Release,管理员会弹 UAC):ivf_tl_operate_2.0/ivf_tl_Operate/bin/Release/net6.0-windows/ivf_tl_Operate.exe。★只启一个实例,确认旧进程已无再启,避免再次串口占用★。
  4. operate tlInfo/time 持续报错 = 空库无 tlNum=20230411 设备数据(非bug,需先建设备基础数据)。
• 今晚测试成果(operate 真实代码全链路通 + 修 gateway TraceFilter & 路由2个bug)见上一段 02:55 + 桌面《时差培养箱-硬件闭环测试结果-2026-06-19.md》。★代码/配置改动均未 git 提交,待用户过目★。

2026-06-19 21:48 · 重启后集群一键恢复 + bug-2 路由修复真机复验通过（claude 回写）

• 续接：用户「继续工作」。开机读断点定位 = 09:30 串口内核卡死需重启电脑。核实：pid2664 已消失（电脑已重启）、java/operate 均无进程、集群未起。
• ★拉起集群★：前置校验（java 在 / gateway jar 02:46 含修复 / nacos 192.168.0.108 返 200）→ bash 临时文件/start-all.sh 起 7 微服务。验证：端口 10010/20/30/40/50/60 + 7081 全 LISTENING；日志确认 gateway「管理员admin登陆成功」+ tl-control 定时任务运行中（完全启动）。
• ★端到端冒烟全绿（bug-2 真机复验）★：登录 admin/123456=2000 拿 JWT；surface getButtons 经 gateway=2000 返 buttons；data-transmission showCache 经 gateway=2000。→ 今晚 bug-2 修复（surface discovery.enabled=true + gateway routes[1] 加 -dev / routes[6] 去 -dev，使路由匹配 nacos 注册名）经 gateway 端到端真机复验通过。
• ★踩坑（环境）★：①Git Bash profile 噪音致多命令脚本输出错乱（echo: command not found）→ 冒烟改「写文件再读」规避。②nacos /ns/service/list 返 0 是 API 调用方式问题，实际服务正常（gateway 登录成功为证）。③★进度状态.yaml 被某进程改成损坏 UTF-16（UTF-8 字节被逐字节提升再存 UTF-16LE，混合码点）→ Read/Edit 读为空/Unknown。已用 Write 重建为干净 UTF-8（无 BOM），损坏原件备份在 临时文件/yaml_corrupt_backup.bin。交接卡/进度数据.js 仍是正常 UTF-8 未受影响★。
• 改动：仅回写进度文档（进度状态.yaml 重建+断点更新、本段、进度数据.js）。今晚代码/配置改动（TraceFilter + gateway/surface 配置 + HwTest/OperateHwTest）仍未提交，待用户过目。
• 下一步：用户启动 operate（Release/UAC）结合 GUI 测试；空库无 tlNum=20230411 设备数据时 tlInfo/time 报错属正常（需先建设备基础数据，非 bug）。

2026-06-20 · Phase0 T0.1 完成(删 kfka 重复键)

• 改:operate App.config 删第 68-71 行(kfkaIP=127.0.0.1/kfkaPort 重复块+注释),只留第 26-27 行服务器值 192.168.0.108。git diff = 4 deletions。备份 临时文件/App.config.bak。
• 效果:App.xaml.cs:72 oplog Kafka 生产者不再被 localhost 覆盖,M8 日志可发服务器(A2 修复)。
• ⚠ bin/Debug/*.config 是构建产物,重新 build 会从源 App.config 同步,无需手改。
• 下一步:T0.2 修对焦默认不拍照(scene=0 基准链),倾向降级路径回退既有 clearestPosition/EEPROM(纯 C# 逻辑,最安全)。

2026-06-20 · Phase0 T0.2 完成(修对焦默认不拍照,降级回退)

• 改:HouseBin.cs StartAutoFocus 降级路径(安全门 local_autofocus_enabled=0 默认态)。原 else 分支"取不到 scene=0 基准就跳过该 well"→ 改为回退该 well 既有清晰拍摄 Z _wellSettings[*].eepromClearPosition(与 operate verNewValue 默认同源,>0 才用,否则才跳过)。git diff +12/-1。备份 临时文件/HouseBin.cs.bak。
• 效果:出厂默认安全门关闭态下,绝大多数 well(eepromClearPosition 已配)能回退到既有清晰位置拍照,filled>0→return true,消除"默认不拍照"断点(A1)。scene=0 基准库后续可另行补落库,但降级不再依赖它。
• 子代理调研确认:HouseWellPhoto 下游只读 wellSn+verticalMotorPosition;_wellSettings 构造即就绪、每 well 一条;HouseWellSetting.wellSn(:30)/eepromClearPosition(:65)字段确认;现有 :1674/:1854/:2095 同样 _wellSettings.FirstOrDefault(x=>x.wellSn==..)。
• 待:dotnet 编译验证(下条);真机验证降级拍照(V-060~063)。

2026-06-20 · T0.2 编译验证通过

• dotnet build ivf_tl_Operate.csproj(经 ProjectReference 传递编译 control HouseBin)= 0 个错误(仅预存 nullable 警告)。T0.2 对焦降级回退修复编译有效。
• Phase0 进度:T0.1 ✅(删 kfka 重复键)+ T0.2 ✅编译验证(对焦默认不拍照→降级回退 eepromClearPosition)。下一步 T0.3:front AutoFocusWindow 对焦预览改判据(去 imageScore 文件名段、高亮改 clearest),与后端 M3-02 对齐。
• ★未提交改动累计:App.config(T0.1)、HouseBin.cs(T0.2)+ 昨晚夜跑的 framework/gateway/surface/测试工具。待用户过目后一并提交。

2026-06-20 · ★Phase0 止血完成(3 个功能 bug 全修)★

• T0.1 ✅ 删 App.config kfka 重复键(M8 日志不再发 localhost)。
• T0.2 ✅ HouseBin.StartAutoFocus 降级回退 eepromClearPosition(修"默认不拍照"),dotnet build operate=0 错误编译验证通过。
• T0.3 ✅ front AutoFocusWindow.xaml.cs:149 文件名串去掉恒 0 的 imageScore 段(与后端 M3-02 对齐;高亮 :152 无需改,后端已用 clearest 填 highestScore)。删字段引用不可能破坏编译。
• 累计未提交改动:App.config / HouseBin.cs / front AutoFocusWindow.xaml.cs(本会话 Phase0)+ 昨晚夜跑的 framework TraceFilter / gateway·surface 配置 / 测试工具。备份在 临时文件/*.bak。待用户过目后一并 git 提交。
• ★下一步 = Phase1 串口占用 + HAL 真接管(较复杂,建议新鲜上下文做)★:T1.1 补全 SerialChannelImpl 7 方法(从 operate 栈搬)→ T1.2 调试页改用 lease.Serial/Camera 删 new ComBin → T1.3 接通借用闸门暂停(OnPauseCapture 订阅 HouseBin)→ T1.4 真机验证(用户在场,舱内空)。详见《2026-06-20-当前开发计划.md》G1（串口收尾）。
• 续接读:本卡 + 《工作计划表》 + 《2026-06-20-当前开发计划.md》 + 进度状态.yaml。

2026-06-20 · Phase1 T1.1 完成(补全 SerialChannelImpl 方法,子代理实现+编译验证)

• 改 4 个 control 文件:① ComBin.cs 加水平/垂直相对正反向×4 + AutoWait(照 operate 同名方法忠实搬运,control 风格);② Commander.cs 加 CreateAutoCommand(逐字节搬 operate);③ Enums.cs 加 AutoAirSwap;④ SerialChannelImpl.cs 5 方法(VerticalForward/Backward/HorizontalForward/Backward/AutoAirSwap)从 return false 改为加 _ioLock 调 ComBin。
• ★安全红线遵守★:WriteWellHorizontalPosWait(写 EEPROM)保留 TODO return false——子代理核实 control CreateWriteEEPROMhoriMtWellHoriPos 与 operate 字节级完全相同(同 0x12/同 well 地址表/同小端 pulse),但写 EEPROM 破坏性且 V-010 字节序未真机统一,故待真机核对后补(补法平凡:ComBin 加 WriteEEPROMhoriMtWellHorHorWait 包装+改 SerialChannelImpl 调用)。SendWait 裸帧 control 栈无入口、非调试必需,保留 null。
• 编译:operate + control HAL 工程均 0 错误(子代理已 dotnet build 验证)。
• 下一步 T1.3 接通借用闸门暂停(OnPauseCapture 订阅 HouseBin,纯代码非破坏)→ T1.2 调试页改 lease(较复杂,部分写EEPROM动作受 V-010 真机门控)→ T1.4 真机验证。

2026-06-20 · Phase1 T1.3 完成(接通借用闸门暂停,子代理实现+编译验证)

• 改 HouseBin.cs:①新增 volatile CapturePausedByGate 标志(与 MQTT IsDebug 独立)+ _gateSubscribed 幂等;②新增 SubscribeGateCapturePause/OnGatePause/OnGateResume,在 StartTask 起始订阅 GetHouseGate(houseSn) 的 OnPauseCapture/OnResumeCapture;③MainThread 让路判断 if(IsDebug)→if(IsDebug||CapturePausedByGate),让路时不发任何串口/电机命令(让出 ComBin)。
• 死锁分析(子代理):对焦支线同舱同线程,标志仅循环顶部生效、不打断在途对焦,using 本迭代内 Dispose 清位,下一节拍标志已清→无自暂停无死锁;_foregroundHolders 计数保证无环路。取不到 gate try/catch 不崩。
• 编译 0 错误。
• ★Phase1 串口占用进度:B5 部分(T1.1 补 6/7 方法,写EEPROM真机门控)+ B1(T1.3 暂停接通)已修。剩 B2=T1.2 调试页改用 lease.Serial/Camera 删 new ComBin(★大重构 1489 行 VM,部分写EEPROM动作受 V-010 真机门控,宜新鲜上下文做★)+ T1.4 真机验证(需用户在场,红线:不无人值守驱动电机)。
• 累计未提交:Phase0(App.config/HouseBin/front)+Phase1(control 的 ComBin/Commander/Enums/SerialChannelImpl/HouseBin)+昨晚夜跑。

2026-06-20 · ★Phase1 串口占用代码层修复完成(T1.2,子代理+独立编译验证)★

• T1.2:HouseDebugPageViewModel + BufferDebugViewModel 删 new ComBin/new Camera(grep 零残留),改用 _halLease.Serial/_halLease.Camera(与采集端同一 HAL 句柄)。ComHouseInit 不再开第二口、ComHouseUnit 不再 ClosePort(物理口归采集端)。补 ICamera/CameraImpl(GrabRaw/RawToRgb/SavePic)+ ISerialChannel/SerialChannelImpl(多个写E方)+ control ComBin 4 个写E方包装(调既有 builder)。写排气阀/灯光等 control 缺 builder 的动作保守保留(UI 提示待真机)、不臆造字节。
• ★独立编译验证:dotnet build operate = 0 错误,3 警告。grep 确认调试页无 new ComBin★。
• ★★串口占用根因代码层全修复★★:T1.1(HAL 方法)+T1.2(调试复用句柄不开二口)+T1.3(借用闸门暂停采集让出)。剩 T1.4 真机验证(需用户在场,红线)。
• 真机待验(子代理提醒):①写E方 0x12 回包长度 control=6/operate=12,需真机确认写成功语义;②待补 3 个写E方 builder(排气阀写/读、灯光写);③借用时序 V-012/V-024 不死锁不占用;④SavePic 走 control SaveBmpPic 图像方向/质量比对。
• 下一步:Phase2 物理合并(建合并 .sln,hook 要求),退役删除 control/autofocustool 受真机判据门控。

2026-06-20 · T4.5 部分:M2-02 单测重建 + 对焦层公式逻辑验证(回答用户#1疑虑)

• 新建 IvfTl.AutoFocus.Tests(xunit,net8 测试引用 net6 类库),PhotoLayerCalculatorTests.cs 23 个真实断言用例(层公式/双空异常/就近优先/down覆盖/pulseMax钳位/边界),dotnet test 全通过 23/0,只测不改生产代码。
• ★独立评估结论:对焦层公式逻辑正确无 bug★。公式起点=FocusZ−down×spacing/逐层+spacing 多组验证吻合;计划期望值[88178..88690]与代码现算一致(未过时);就近优先正确处理 down=0 当有效覆盖;异常分级/钳位合理。
• 唯一隐患(非bug,未改):ComputeLayerPositions 不校验 down<count,仅 ViewModel 手调路径兜;自动对焦链路传脏配置会静默产出"清晰层不在拍摄范围"。建议把校验下沉(登记,待定)。
• 计划 M2-02 数字与代码吻合,M2 对焦核心逻辑可信度由此提升。

2026-06-20 · ★autofocustool 退役删除完成(子代理核实+编译验证)★

• 先解决矛盾:定论 HouseBin 用 IvfTl.AutoFocus 移植副本(using IvfTl.AutoFocus.Calib,ivf_tl_Com.csproj:15 引 IvfTl.AutoFocus),非 autofocustool(AutoFocusTool.* 命名空间)。codegraph 当初把同名类解析串了。审计"autofocustool 无引用"正确。
• autofocustool 全仓零生产引用:无 csproj ProjectReference、无 using AutoFocusTool、不在任何 sln。
• ★已 git rm -r autofocustool/(46 跟踪文件;git 历史保留可恢复作真机比对兜底;未跟踪的 HwTest 夜跑产物已备份 临时文件/autofocustool-HwTest-backup-20260620)★。未 git commit(主会话统一处理)。
• 编译验证:operate sln / front sln / control sln(含 -t:Rebuild 全量)全部 0 错误,无回滚。
• ★退役进度:autofocustool ✅删除;control ✗仍被 operate 3 ProjectReference 引用(ivf_tl_Control/IvfTl.Hardware/IvfTl.AutoFocus),需大迁移(采集核心物理并入 operate)+ 真机判据才能删★。
• 待回写:M2 子计划 autofocustool 退役条件标完成;待验证清单。

2026-06-20 · ★★三项目合并物理收尾达成:control 并入 operate★★(子代理+三关编译验证)

• git mv ivf_tl_control_2.0 → ivf_tl_operate_2.0/control(172 文件 rename 保留历史);operate.csproj 3 条 ProjectReference 改 ....\ivf_tl_control_2.0\X → ..\control\X。control 内部相对引用不变;operate.sln 走 csproj 引用无需改;control.sln 随树移动仍有效。
• ★顶层 ivf_tl_control_2.0 消失,operate 自包含★。三项目合并物理收尾:autofocustool 已删 + control 并入 + operate 单一项目。front 是独立中央管理端,不在合并范围,未动。
• 编译验证三关全 0 错误:operate 主程序(传递编译搬入的全部 control 工程)/ front sln / control/IvfTl.AutoFocus.Tests(23 通过)/ 额外 control/ivf_tl_Control.sln。HEAD 6b8dd8a 不变,改动在工作区未 commit。
• 提醒:①搬移后 IvfTl.AutoFocus.Tests 在新位置仍未跟踪,提交前 git add;②control 树含 ivf_tl_ControlTest(壳/Window1,operate 不引用)+ doc,随树搬入不影响编译;③路径大变动需 codegraph sync;④提交按 3.4 同步 08影响范围/开发计划旧路径/本卡/进度状态。
• ★剩余(非"合并"本身):真正去重(operate 与 control 两套 ComBin 合一省 token,语义重构)+ T1.4/运行期真机验证(新路径加载 HAL/对焦引擎、串口占用解除)需用户在场★。

2026-06-20 · Phase4 批次1(B6/C3/down<count,子代理+编译验证)

• B6 M5容错读取接启动崩点:operate AppData.cs:79-82 裸 int.Parse/.ToString → AppConfigHelper.GetString/GetInt(mqttPort 默认1883);control AppData.cs:49-52 不能反引operate工程,用 BCL TryParse 兜底。R8 防护真生效。
• C3 M5 HTTP失联标记 M5-04-4:MainPageViewModel.cs:762 HTTP轮询成功(a!=null)后写 ivf_tl_Control.AppData.Instance.LastHttpOkAt=DateTime.Now(全限定+try),失败分支已 continue 天然"失联不更新"。监控页读取逻辑未碰。
• down=count 抛 FocusConfigMissingException(文案对齐 ViewModel),自动对焦链路兜底。23 单测全过(探针测 ComputeLayerPositions 绕 Resolve 不受影响,仅更新注释)。
• 编译 0 错误。未提交。
• 提醒:control AppData 其它键(gbTime 等)仍有裸读缺键风险,不在本批3项内未碰。
• 剩余 Phase4:M8埋点铺开(operate逐方法/front接入/Java注解,大)+ M8配置下发/补送(C4)+ 两套ComBin去重(省token语义重构,风险);真机验证需用户在场。

2026-06-20 · ComBin 去重(部分:删死代码;全删受枚举迁移+真机门控)

• 子代理删 DebugCalibrationAdapter.cs 里死代码 DebugSerialAdapter/DebugCameraAdapter(B栈ComBin的唯一类型引用点,但从不被new,标定早走HAL lease)+清无用using。编译0错误。保留活跃的 WellCalibState/WellCalibUiItem/LayerPreviewItem。
• ★B栈(ivf_tl_Entity/ComEntitys ComBin/Channel/SerialBin)未物理删★:仍有生产用点——HouseDebugPageViewModel.Start():171 + BufferDebugViewModel:79 的 new SerialBin()(B栈)做开机枚举舱室/相机/EEPROM握手;T1.2只迁了写EEPROM未迁枚举。+ OperateHwTest(测试工具)用B栈。
• ★全去重剩余(需专门一轮+真机)★:①迁 Start()/BufferDebug 枚举阶段 B-SerialBin→A栈(HAL),难点:A栈 SerialBin 返回 control-Entity 命名空间DTO,operate-VM 期望 operate-Entity 类型,需跨命名空间映射,且枚举握手运行期必须真机验证;②OperateHwTest 排除/重写/删;③之后才能 git rm B栈文件。
• 安全:子代理只删确证死代码(compile绿,无runtime风险,不需真机);活跃枚举点保守保留不臆造迁移。

2026-06-20 · Phase4 front 接入日志组件完成(C5,子代理+编译验证)

• front(aivfo-front-manament-2.0)ivf_tl_Manage/ivf_tl_Service 加 ProjectReference→Aivfo.OperationLog;App.xaml.cs App_Startup 加 InitOperationLog(project=front,kafka从App.config kfkaIP:port,topic=tl-oplog,全try兜底);App.config 补 kfkaIP=192.168.0.108/kfkaPort=9092。
• HTTP 收口 HttpServiceCall.HttpClientSendAsync 埋点(成功/失败/耗时)+ traceId 改取 OperationLogContext.TraceId(header"traceId"与后端一致,跨端串联)。编译 front sln 0 错误。
• 真机验证待:front 操作真入 operation_log 需起 kafka+oplog 验。
• ★用户消息:真机已连接,授权测试(不怕搞坏),临时文件/相关参数.html 有安全运动参数(注意:是demo流程非实际业务流程)。转入真机测试。★

2026-06-20 · ★真机测试(用户连真机授权)+ data-transmission 修复 → 全栈闭环★

• 用户提醒:中间件用服务器 192.168.0.108(本机 docker 冗余)。核实:微服务 application-local.properties server.ip=192.168.0.108,确实连 108。
• ★真机测试(子代理,按 临时文件/相关参数.html 安全钳位:水平[0,220000]/Z[0,125000])★: · 硬件层全通过:7舱(2/4/6/7/8/9/11)握手+三路温度~36/39/40℃+压力+舱门(关闭)+电机位置+CCDSN 全读到;电机舱8/舱2 运动 Z→90000/水平→well EEPROM 读回偏差0+复位0/0;相机 Init→拍帧(2592×1944×3 有效JPG)→存图,3相机SN与CCDSN吻合(相机↔舱映射正确)。结果在 临时文件/真机测试结果-20260620.md。 · 业务API全通过:登录2000+tl-control(getAlarm/setting/focus)+business(getHouseCultureList)+surface(getButtons返7按钮 operate→gateway→surface→DB)+对焦下发/上行链(V-047/V-064)全2000。 · ★合并未破坏运行期★:operate硬件栈(ComBin串口+Camera/MVCAPI)、相机SDK、微服务、gateway路由 运行期全正常,零合并相关异常。
• ★data-transmission 启动失败修复(非代码bug,是108漏建库)★:子代理误诊为库名配置bug;实查服务器测试环境.md:aivfo-tl(中划线,4视频表)=data-transmission专用库,与aivfo_tl(下划线,business)是两个库。data-transmission 配 aivfo-tl 正确,但 108 实际只有6库漏了aivfo-tl(SHOW DATABASES确认)。修:docker exec mysql -h108 建 aivfo-tl 库 + 导入 sql/aivfo-tl.sql(4表video/video_pictures/video_splice/video_update)。重启 dt:Started 92s,端口10030,nacos 6服务注册。★全栈闭环★。
• 待用户定:子代理给 OperateHwTest 测试工具加了 camera 子命令+拷相机SDK资源(测试用,非产品代码),是否保留。
• 必须GUI才能测(留用户):operate界面/首页舱室弹框位置大小/对焦窗实拍跑层/串口占用T1.4/M4视觉项。

2026-06-20 · 文档重组完成

• 改动:三层归位——需求文档=合并后现实(01架构合并/13硬件访问层已更新到"已合并"现实);开发计划=《2026-06-20-当前开发计划.md》(5组15任务,统摄剩余工作),7个历史子计划已移入 开发计划/已完成归档/;进度=工作计划表已重写为真实状态、待验证清单已更、进度数据.js已更。
• 删除:实现符合性审计报告、会话完整续接文档、合并收尾与质量修复总计划、临时/1735方案。
• 归档:7个历史子计划→开发计划/已完成归档/;3份历史报告(SQL与代码一致性核对/全量文档体检-0618/文档源码审核)→进度/历史报告/。
• 下一步:按《2026-06-20-当前开发计划.md》推剩余工作(G1串口收尾/G2 UI/G3日志/G4对焦数据/G5业务回归)+真机GUI验证;续接锚=《工作计划表》+《当前开发计划》+《进度状态.yaml》三件。

2026-06-20 · G4-2 建库脚本与 migration 合并 + 幂等 runner(C2)完成

• 改动:①两 migration 内容并入 base CREATE TABLE(非追加 ALTER,更干净且天然幂等)——aivfo_tl_setting.sql:tl_setting +5 对焦列(focus_layer_spacing_pulse/count/down/peak_ratio_threshold/local_autofocus_enabled)、house_well_setting +2 覆盖列、新增 house_autofocus_calibration 表;log.sql:system_log 后追加 operation_log 表。②两 migration 文件头加注"全新部署 base 已含,仅供旧库增量升级"(autofocus 迁移强调 MySQL8 ADD COLUMN 无 IF NOT EXISTS,旧库重跑前 DESC 判列)。③新增幂等 runner sql/init-database.sh(建 7 库 CREATE DATABASE IF NOT EXISTS + 导 base,可重跑)。④清单.md:aivfo_tl_setting 表数 17→18、log 行补 operation_log、新增"〇一键部署"与"四 migrations 分工"段。
• ★核实(真实闭环,非纸面):起一次性 MySQL8 容器 tl-sql-verify(独立名,不碰 tl-mysql/108)→ docker cp sql 进去 → 跑 init-database.sh:7 库零报错。information_schema 抽查:house_autofocus_calibration 存在、tl_setting 5 列全在、house_well_setting 2 列全在、log 库={operation_log,system_log}、aivfo_tl_setting 18 表(对齐清单)。★二次执行 runner 零报错=幂等验证通过★。验毕 docker rm -f 销毁容器,生产容器 tl-mysql/tl-nacos 健在。
• 踩坑:git-bash 把 docker exec 的容器内路径 /sql/... 转成 Windows 路径(C:/Program Files/Git/sql/...),需 export MSYS_NO_PATHCONV=1 禁用转换。
• 下一步:G4-2 是纯代码闭环已交付。剩余纯代码 P1 候选:G3 日志铺开(operate 逐方法/Java @OperateLog)、G2 UI(弹框/13 子页自适应,最终视觉真机为准)。真机门控 G1-1/G4-3/G5 待用户在场。

2026-06-20 · G3-2 Java 操作日志埋点完成(tl-control + business,两 subagent + 编译验证)

• 背景:调研发现 tl-control/business 原本无 log starter 也无 Kafka 生产者,真入 operation_log 需补 M8 三件套(用户已拍板"引三件套真入库")。配方来自 data-transmission 模板。
• 改动(每服务):①service 模块 pom 引 aivfo-log-spring-boot-starter(切面+@OperateLog 注解);②manage 模块引 aivfo-kafka-spring-boot-starter(ProducerNormal);③lanucher 引 aivfo-oplog-client(KafkaOperationLogSender,@ConditionalOnBean ProducerNormal 自动装配);④application-local 配 kafka(aivfo.kafka.properties.ips=${server.ip}:9092 / producer.enable=true / consumer.group)。topic 固定 tl-oplog。
• 埋点:operation=方法 @ApiOperation 中文值逐字照抄(过长留核心动作)、module=类 @Api tags(去版本号/状态尾巴噪声)。覆盖写操作+查询,不改方法体/签名,保留已有 @PreAuthorize/@SkipLogRequest 等。 · tl-control:15 Controller / 90 方法。 · business:24 Controller / 121 方法(三端 pc/surface/app:oplog-client 加在父聚合 lanucher 公共 dependencies 一处即覆盖三端;三个 application-local 各配 kafka 且 consumer.group 三端各异 business-{pc/surface/app}-oplog 避免抢分区)。
• ★编译核实:tl-control 全模块 BUILD SUCCESS;business Reactor 19 模块全 SUCCESS 0 error(01:28)。三件套 artifact 已在本地仓库,未动 framework install。clean 阶段偶报 jar 文件锁(进程占用旧 jar),改不带 clean 的 compile 即过,非代码问题。★ codegraph sync already up to date。
• 主线核实:git status 改动文件齐;三件套依赖/ kafka 配置/ @OperateLog 计数(tl-control 90+15import、business 121+24import)全对上;抽查 DataController 注解 module/operation 取值正确。
• 真机/运行待验:★真入 operation_log 表需起 Kafka+oplog 微服务端到端抽查(运行期,非真机硬件门控)——GUI/接口触发任一操作后查 log 库 operation_log 有记录即闭环★。
• 下一步:G3 余下 G3-1(operate 逐方法埋点,C# 大量 ViewModel)/G3-3(配置下发 C4);或 G2 UI / G4 纯代码。
• 提醒:本批改动含 .flattened-pom.xml(flatten 插件产物)与 target/classes 副本随编译变化,提交时留意是否纳入。

2026-06-20 · G3-1 operate 逐方法埋点完成(C# 端 M8 操作日志铺开,10 subagent + 编译验证)

• 背景:G3-2 Java 埋点后接续同域 G3-1。C# 机制(Aivfo.OperationLog 组件:Run/Begin/Log + OperationLogContext + 本地兜底)P3a/P3b 已就绪,P3b 已封装关键边界(HTTP 单点收口 HttpHelper、串口 OpenPort/ClosePort、相机 Init/UnInit、HouseDebugPageVM 几个命令)。G3-1 = 在其余 VM/命令逐方法手动埋点达成"操作全埋"。
• 重大结构发现:operate MVVM 不规范,很多真实用户操作写在 View 的 *.xaml.cs code-behind 的 _Click 事件里,不在 ViewModel(VM 多为纯数据/展示)。故 G3-1 分两层铺:VM 层 + View code-behind 层。
• 埋点方式(两类):①VM 内同步动作用 OperationLogger.Run(模块,操作,()=>核心调用,input:...)(自动计时+异常重抛,保持原异常流);多步流程用 Begin scope 串 traceId。②View code-behind 事件多自带 try/catch 吞异常不重抛,用 using var _op = OperationLogger.Begin(模块,操作) + try 末尾 _op.Success()/catch 开头 _op.Fail(...)。铁律:OperationScope.Dispose 无法探测异常默认记"成功",所有失败路径(校验早return/接口false/catch)必须显式 Fail(),否则失败误记成功。守卫子句留 scope 外,input 排除密码等敏感字段,全限定名不加 using,每处加 // M8-G3-1： 注释。
• 已埋(10 个 subagent 分文件并行,互不触碰同一文件): · VM 层:HouseDebugPageViewModel ~23 法(LED/进排气阀/补排气/写EEPROM×3/水平电机正反向/到well/垂直电机正反向/绝对/一键电机准备Begin/设曝光/抓拍/水平抓图Begin/清晰图层抓图Begin/保存手调拍摄层Begin)、BufferDebugViewModel 3(补气/写进气阀时间Begin/写灯光亮度Begin)、MainPageViewModel 2(EndDish 结束培养 Run、SetAlarmMute 报警静音改 Log 保留吞异常)、UnifiedConfigViewModel 1(SaveAll 保存统一配置,input 排除 PassWord/EngineerPwd)。 · View code-behind 层:AddDishWindowView(EditDishSave 保存皿/StartDish 启动培养皿/StartBalance 启停平衡皿)、DetailPageView(EmbryoMove/Free/Del/Inv/Over 5 个胚胎操作)、HouseSettingPageView(SaveHouse 保存舱室/SaveSetting 保存系统设置含8校验)、AutoFocusSettingView(SaveHouse 保存对焦设置/SettCheck 批量校验)。 · 正确跳过(说明在位):展示类/纯数据 VM(PhotoPageVM/DetailPageVM/DishRecordVM/AlarmPageVM/ChartPageVM/ServiceMonitorVM 纯展示无操作)、HouseDebugPageView 等 code-behind 仅转调已埋 VM 方法(不重复埋)、HTTP-only 方法(P3b 单点收口已覆盖)、导航/构造/UI 刷新/私有辅助。
• ★编译核实:dotnet build ivf_tl_Operate/ivf_tl_Operate.csproj -c Debug 0 错误,已成功生成(两轮:VM 层后一次、code-behind 层后一次)。BufferDebug 几条 MVVMTK0034(直接引用 currentHouse 字段)系原有代码非本次引入。codegraph sync up to date。
• 抽查:AutoFocusSettingView.SaveHouse(守卫外置/Success 成功分支/4处 Fail 覆盖校验+接口false+catch+throw)、DetailPageView.EmbryoOver(守卫保留原try内/内层try Success+Fail+throw到外层原ExLog吞异常)——Success/Fail 放置正确、控制流逐字保留。
• 真机/运行待验:★同 G3-2,真入 operation_log 待起 Kafka+oplog 端到端抽查(运行期,非真机硬件门控)——GUI 触发任一操作后查 log 库有记录即闭环★。
• 下一步:G3 仅剩 G3-3(M8 §10 配置集中下发+本地兜底补送 C4);或 G2 UI(首页弹框/13子页自适应/TabTip/well三态)、G4-1(C6 对焦清理任务)纯代码任务。真机门控 G1-1/G4-3/G5 待用户在场。

2026-06-20 · ★G3-3 配置集中下发 + 本地兜底补送完成(M8 G3 收官,续写半截任务)★

• 背景:上一会话窗口关闭时 G3-3 写到一半。续接核实:已改 4 文件(KafkaOplogTransport/LocalFileWriter/OperationLogOptions/OperationLogPipeline)+新增 OperationLogConfigWatcher.cs,但门面 OperationLogger.cs 尚未接线——卡点正在此。
• 收尾改动(本次):① OperationLogger.InitCore 构造 KafkaOplogTransport 传 onDeliveryFailed: local.WriteFallback(投递失败/队列满整条 JSON 落兜底,由 Pipeline 补送定时器恢复后补回);② InitCore 在 ConfigFilePath 非空时起 OperationLogConfigWatcher(存静态字段);③ Shutdown 释放 watcher。
• 修 WIP 遗留编译错:OperationLogOptions.ApplyConfigJson 两处 JToken.Value<bool>() 无参非法 → 改 (bool)en/(bool)me(前已判 .Type==Boolean,强转安全)。
• §10 配置热生效:ConfigFilePath/ConfigReloadSeconds + ApplyConfigJson(容错解析 enabled/globalLevel/模块级开关,任意字段缺失/格式错忽略不抛)+ OperationLogConfigWatcher(轮询文件大小/写时间变才重读重应用,SafeRead FileShare.ReadWrite 容并发写)。运维/日志微服务把统一配置下发覆盖到该路径即热生效,不重编。
• §11 兜底补送:LocalFileWriter 加 ListFallbackFiles/ClaimFallback(原子重命名 .resending 避 append 竞争与并发重复)/ReadLines/DeleteQuietly;Pipeline.TryResend 定时器(认领→逐行 Send→Flush 2s→删,重入保护 Interlocked + 每轮限流 ResendFilesPerCycle,全 try)。与 RunLoop 既有 catch 不双写(Send 现内部 catch ProduceException 不外抛)。
• ★编译核实:dotnet build Aivfo.OperationLog/Aivfo.OperationLog.csproj -c Debug = 0 错误 0 警告。codegraph sync up to date。
• 兼容性:消费端 operate/front 只用 OperationLogger.Init/Log/Begin/Run 门面,签名全未变(新增的是 KafkaOplogTransport 可选参 + Options 新字段),零改动不破坏(codegraph 确认仅 OperationLogger.cs 构造这些内部类),故未再全量 build operate/front。
• 真机/运行待验:★真入库 + Kafka 宕→恢复补送 + 配置文件改→热生效,三条均待起 Kafka+oplog 端到端抽查(运行期,非真机门控)★。
• 本次未 git commit(按惯例主会话统一,与累计未提交改动一并)。累计未提交:本次 Aivfo.OperationLog 5 文件 + 此前各会话累计(见前卡)。
• 下一步:M8 可写代码全清。挑剩余纯代码——G2 UI(首页舱室弹框/13子页自适应/TabTip/well三态,视觉真机为准)或 G4-1(C6 对焦标定清理任务)。真机门控 G1-1(T1.4)/G4-3/G5 待用户在场。

2026-06-20 · ★G4-1 对焦标定清理任务(C6)完成★

• 用户拍板:保留天数配置走 tl_setting.clean_autofocus_data 中央下发列(而非本地 App.config)。
• ★关键发现省一半工作★:clean_autofocus_data 是 tl_setting 原始遗留列(与 clean_source/control/pc/surface/video_data 同族"清理时间"列),base sql(aivfo_tl_setting.sql:688 默认30)已含、老库本就有→中央 MySQL 无需改;Java 下发链原已就绪(TlSetting.java:235 cleanAutofocusData 默认30、TlSettingVO:224、TlSystemSettingVO/UpdateDTO)。审计 C6 原话"clean_autofocus_data 仅配置列无消费者"——G4-1 = 补 C# 消费者。
• 改动(C# 端,全镜像 focusLayerCount): · 下发链 4 文件:tlSettingDTO / TLSettingDB([SugarColumn(IsNullable=true)] int?) / TLSetting / ConvertHelper 3 路径(DTO→TLSetting、TLSettingDB→TLSetting、TLSetting→TLSettingDB)各加 cleanAutofocusData。 · DBService.CleanAutofocusData(int keepDays):Db.Deleteable().Where(scene==1 && calibTime<now-keepDays) 物理删除;scene=0 永不动(12 §2.7 约束①);keepDays<=0 安全阀返回0不删;全 try 兜底记 DbException 返回删除条数。物删非置 deleted——retention 需真正缩表(12 §2.7 数据量评估按清理维持万级)。 · AppData.CleanAutofocusCalibration():读 TLSetting.cleanAutofocusData(缺省/非正→30)调 DBService.CleanAutofocusData,记 RunRecord 日志;挂到 StartPushMessageThread 每日维护窗口(autoFocusTime 时刻、isSetZiDong 守卫,与既有 DeleteLog 同源同守卫,日清一次)。
• 读路径不碰 SQLite:keepDays 取自内存 TLSetting(server init 下发值,AppData.cs:197/1321),零 V-046 读风险。TLSettingDB 加列是为离线缓存一致,与既有 focus 列同受 V-046/G4-3 预置库重建门控。
• ★编译核实:dotnet build operate = 0 error(仅预存警告,含已知 BufferDebug MVVMTK0034)。codegraph sync done。
• 真机/运行待验:清理真执行删库 = 起运行后到 autoFocusTime 触发查 house_autofocus_calibration scene=1 过期行被删、scene=0 在(运行期非真机门控);本地旧 SQLite 加 cleanAutofocusData 列 = G4-3/V-046 真机门控。
• 本次未 git commit(待与文档一并)。下一步:G2 UI 或 G1-2(ComBin 去重,需专门一轮+真机)。

2026-06-20 · ★G2-2 子页自适应(根层)完成 + 5 个已完成任务 push 远程★

• 先 push:会话开场核实 working tree clean,G3 全部/G4-1/G4-2 共 5 提交本地已规范提交(均带同步文档,符合 3.4),但领先 origin/main 未推。已 git push:617cc53..968f9ae,现 main...origin/main 同步。
• G2-2 调研关键发现:operate 所有页(含主页)整屏 LoadPage 进 MainWindow _container(ContentControl),外层只有 一个 Viewbox{Uniform}(MainWindow.xaml.cs M4-01-1 无条件包裹 MainGrid)。Viewbox 以无约束测量子页自然尺寸再等比缩放——故含 * 星号行的页靠根 Height=2736 撑开;直接删根尺寸,星号行塌缩成内容高、Viewbox 拿到扁画布→视觉崩。样板 MainPageView(Auto/Auto/*/Auto)根已删尺寸但宿主未给基准,自身也是此隐患(M4 视觉本未验)。
• 方案=设计基准下沉一处(用户拍板"宿主基准+全11页"): · 改动1 MainWindow.xaml:<Grid x:Name="MainGrid"> 加 Width="1824" Height="2736"(唯一固定设计基准;_container/_mask 同在其下基准统一;D6 真机校准只调这一处;一并修好样板页)。不动 .xaml.cs。 · 改动2 11 全屏子页根 Height="2736" Width="1824" → d:DesignHeight="2736" d:DesignWidth="1824"(11 页均已有 xmlns:d+mc:Ignorable,d: 运行时忽略仅设计期):About/Alarm/AutoFocus/Buffer/Chart/Detail/DishRecord/HouseSetting/Photo/Setting/HouseDebug。
• 本轮范围边界:只动根尺寸。内层 Canvas 绝对定位/内层写死 Width=1824(SettingPageView 14 个 Grid、PhotoPageView WrapPanel、Detail/Alarm/DishRecord 分页控件等)= 深层 R6「去 Canvas 绝对坐标」高视觉风险层,留后续真机轮,本轮不碰。CCDSettingView 根已 d:DesignHeight=450/Width=800 达标不改;AddDishWindowView 是 <Window> 弹窗(非 _container 全屏页)归 G2-1 弹框族单独处理。
• 核实:① grep 11 页前12行根运行时 Height="2736"/裸 Width="1824" 清零(残留 Width=1824 全是内层 WrapPanel/Grid,非根);② 各页 d:DesignHeight="2736" 计数=1 就位;③ dotnet build ivf_tl_Operate.csproj -c Debug = 0 错误(2056 警告全预存 nullable/MVVMTK0034,本轮只改 XAML 不引入);④ codegraph sync up to date(XAML 非索引符号)。
• TDD 记账:声明式 XAML 布局无可单测纯逻辑 + operate 无测试工程(IvfTl.AutoFocus.Tests 仅 control 侧),属 TDD 例外;CLAUDE.md「开发优先·真机视觉验收」按 superpowers 指令优先级高于 TDD skill。验证=grep+编译(已闭环),视觉走 G2 真机门控。
• 真机/视觉待验(G2 门控,留用户):7 个星号页(About/Alarm/Chart/DishRecord/Photo/Setting/HouseDebug)+主页进 GUI 看满屏不溢出/不塌缩/不变形、一屏排布。这是 G2-2 最终验收。
• 本次未 git commit(按惯例主会话统一,与文档一并)。下一步纯代码:G2-1 首页弹框 / G2-3 TabTip 程序级屏蔽 / G2-4 well 三态(需求未定哪三态,先定义再做);或 G1-2 ComBin 去重(需专门一轮+真机)。

2026-06-20 · ★G2 软键盘 Viewbox 适配回归修复（顶层 Popup 托管，代码完成待实机验）★

• 背景：续接发现工作区有一个未提交改动 SoftKeyboardHost.cs(+37/-14)，交接卡无记录＝上次电脑重启时正在调"设备舱室调试输入密码的小键盘问题"中断。本会话续接核实+收尾。
• 根因（G2-2 引入的回归）：G2-2 给 MainWindow.xaml 的 MainGrid 加固定 Width=1824 Height=2736 并套进唯一的 Viewbox{Uniform} 后，KeyboardOverlay 原方案"把键盘浮层动态 Add 到窗口 root Panel"失效——固定尺寸的 MainGrid 在 Viewbox 内，运行期新增的子树不会被父级重新测量/布局，键盘渲染成 0×0 不可见（代码注释记"实测复现"）。这正是用户说的小键盘问题。
• 修复（仅 SoftKeyboardHost.cs 一处，KeyboardOverlay）： · 加字段 _popup；Show() 重写：键盘 + 全窗透明背景捕获层(bgCatcher，点空白=取消) 装进 _layer(Grid winW×winH)，再放进顶层 Popup(PlacementMode.Relative / PlacementTarget=_window / HorizontalOffset=VerticalOffset=0 / 全窗尺寸 / AllowsTransparency=true / StaysOpen=true) → IsOpen=true。Popup 是独立顶层 HWND/布局根，脱离 Viewbox 与固定 MainGrid，必被测量渲染，绕开 0×0 坑。 · 键盘尺寸从写死 px(1000/700 + MaxWidth) 改为按窗口 ActualWidth/ActualHeight 动态算(Password=min(960,W.62)×min(560,H.52)；Number=min(640,W.42)×min(470,H.46)，fallback 1920×1080)——Popup 走屏幕像素、不随 Viewbox 缩放。 · Dispose()：_popup.IsOpen=false; Child=null; _popup=null。遮罩逻辑不变(有 _mask 复用、否则 _rootPanel 注入半透明层；MainWindow 走 _mask 复用)。
• ★实机前风险已逐一核查并排除（systematic-debugging）★： · 编译：dotnet build ivf_tl_Operate.csproj -c Debug = 0 error(2060 警告全预存 nullable/MVVMTK0034)。 · 不变形：SoftKeyboard.xaml 内部全 Grid/UniformGrid * 星号比例，给定固定 W/H 自适应填满，宽高比合理。 · 不崩：按键样式依赖 {StaticResource TouchMinSize}，定义在 Resources/AdaptiveStyles.xaml，已在 App.xaml:30 合并进 Application.Resources(App 级)；WPF 资源查找 fallback 到 Application.Resources，故 Popup 内逻辑树孤立也能找到，不抛 StaticResource 异常。 · 0×0 根因：Popup 独立布局根，方向对症。
• 任务归属说明：代码注释借用了"G2-3"标签，但实质是 G2-2 自适应改造的回归修复(软键盘对 Viewbox 适配)，不是 真正的 G2-3(TabTip 系统触摸键盘程序级屏蔽，仍未做)。
• 实机门控待验(留用户,GUI)：①舱室调试页点密码框→键盘弹出、底部居中、按键不变形；②遮罩压暗铺满+键盘浮最上不错位(_mask 在 Viewbox 内、键盘在 Popup 屏幕坐标，重点看对齐)；③输入实时写回 PasswordBox(tl13579 校验照常触发)+数字键盘(参数输入)同路径顺带验。
• 本次未 git commit(按惯例与文档一并，待实机验后提交)。累计未提交含此前各会话改动(见前卡)。
• 下一步：实机验本修复；纯代码可挑 G2-1 首页弹框 / G2-3 TabTip 屏蔽 / G2-4 well 三态(需求先定义)。

2026-06-20 · ★G2 软键盘修复·实机验证通过（用户在场，三轮调试）★

• 接上条。用户在机器旁实机测试，启动 Debug 版 operate(bin/Debug/net6.0-windows/ivf_tl_Operate.exe，cmd start 拉起；git-bash ./exe 直跑被沙箱拒=exit126，改 cmd //c start)。
• 三轮现象→修复： · 轮1：键盘能弹出来了（0×0 根因=Popup 托管已修复，确认有效）。但"高度不够，内容没显示完"。 · 轮2：把高度上限调大(Password 560→860/比例0.52→0.62、Number 470→680/0.46→0.55)。结果"还是没显示完，输入后没有确定按钮"——判明根因不是框矮，是键盘贴底(VerticalAlignment=Bottom+Margin底40)被屏幕底部裁掉最底行(清除/空格/确定)。 · 轮3：键盘改 VerticalAlignment=Center 屏幕居中 + Margin=0(去掉贴底)。结果"可以了"——居中后最底行"确定"完整露出，验证通过。
• 最终修复(SoftKeyboardHost.cs，KeyboardOverlay.Show)：键盘 VerticalAlignment=Center/Margin=0/Width=kbW/Height=kbH；kbW=Password min(960,W.62)/Number min(640,W.42)；kbH=Password min(860,H.62)/Number min(680,H.55)。键盘+bgCatcher 装 _layer 放顶层 Popup(脱离 Viewbox)。
• 验证闭环：①0×0 解决 ②高度够 ③居中、底行完整、输入写回正常。dotnet build operate 0 error(每轮改后重编译+重启验)。
• 经验：Viewbox 内固定尺寸容器中动态浮层→必用顶层 Popup；全屏覆盖型 Popup 里的内容居中比贴边稳，贴底/贴边易被屏幕物理边界裁切(尤其 DPI/窗口尺寸与屏幕不完全一致时)。
• 下一步：git 提交本修复(SoftKeyboardHost.cs + 本轮文档 + 此前累计未提交改动)；然后按工作计划继续。