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 提交,待你过目。