GFramework/ai-plan/public/godot-logging-compliance-polish/todos/godot-logging-compliance-polish-tracking.md
gewuyou a52f3c6fec feat(godot): 补齐 GodotLogger 接入文件
- 新增 GodotLogger 的配置加载、延迟入口和宿主输出适配实现。
- 复制 ai-libs/GodotLogger 的 MIT 许可证到 third-party-licenses/GodotLogger/LICENSE。
- 补充 active tracking 与 trace,保留下一阶段对齐点。
2026-05-02 21:39:26 +08:00

4.6 KiB
Raw Blame History

Godot Logging Compliance Polish 跟踪

目标

继续把 GFramework.Godot.Logging 从“基础可用的 Godot 输出适配”收敛成“对齐 GodotLogger 优点、但保持 GFramework 自身日志抽象不分叉”的稳定宿主层,并为后续 Godot / Core 日志统一留下清晰恢复点。

当前恢复点

  • 恢复点编号:GODOT-LOGGING-COMPLIANCE-POLISH-RP-001
  • 当前阶段:Phase 1
  • 当前焦点:
    • 已补齐 GodotLog 静态入口、延迟 logger 解析、配置自动发现与热重载
    • 已让 GodotLoggerFactoryProvider 对已缓存 logger 生效动态配置,而不是只在新建 logger 时读快照
    • 已让 GodotLogger 支持 {properties} 占位符,并把 IStructuredLogger / LogContext 属性落到 Godot 输出
    • 已兼容 GodotLogger 风格配置值,如 Information / Critical
    • 下一轮优先评估是否把 Godot 输出进一步并入 Core 的 appender / formatter / filter 组合管线

当前状态摘要

  • GFramework.Core 仍是主日志框架;GFramework.Godot 没有引入第二套业务日志 API
  • GFramework.Godot.Logging 现在已经补上原 GodotLogger 项目最有价值的宿主便利层:
    • GodotLog
    • DeferredLogger
    • 配置文件自动发现
    • 文件热重载
    • 结构化属性渲染
  • 本轮没有把 Microsoft.Extensions.LoggingILoggingBuilder / ILoggerProvider 生态原样搬入 GFramework
  • AbstractLogger 已支持动态最小级别提供器,为 Godot 配置热更新生效打通基础能力

当前活跃事实

  • 当前主题由分支 feat/godot-logging-compliance-polish 驱动,并已在 ai-plan/public/README.md 建立映射
  • ai-libs/GodotLogger 的 MIT 许可证已复制到 third-party-licenses/GodotLogger/LICENSE
  • GodotLog 当前的配置发现顺序为:
    • GODOT_LOGGER_CONFIG
    • 可执行目录 appsettings.json
    • res://appsettings.json
  • GodotLog.Configure(...) 仍要求在首次 materialize provider 前调用;延迟 logger 会避免 static readonly 字段过早锁死配置
  • GodotLoggerFactoryProvider 当前按 logger 名称缓存实例,但每次判定级别和写日志都会读取最新 GodotLoggerSettings
  • Godot 模板默认已扩展为包含 {properties},因此结构化属性和 LogContext 会进入渲染结果
  • 配置加载兼容两套级别命名:
    • GFramework 风格:Info / Fatal
    • GodotLogger 风格:Information / Critical
  • 现有设计仍保留 UTC 时间戳语义,没有为了对齐原项目而默认切回本地时间

当前风险

  • 双入口生命周期风险:如果同一宿主同时混用 LoggerFactoryResolver.ProviderGodotLog,需要明确谁是最终默认 provider
    • 缓解措施:当前文档与实现都保留 GodotLog.UseAsDefaultProvider(),并继续把 ArchitectureConfiguration 方式写成默认推荐路径
  • Core / Godot 管线分离风险Godot 侧虽然已有热重载与配置发现,但还没有变成 Core 可组合 appender
    • 缓解措施下一轮只评估“Godot sink / appender 化”,不再继续扩张独立的 Godot logging 面
  • 配置热重载的宿主差异风险Godot 编辑器、导出包和测试宿主的文件系统语义不完全一致
    • 缓解措施active 入口先锁定 discovery / reload 语义,后续若遇到平台差异,再用定向回归和文档补充收口

活跃文档

验证说明

  • dotnet test GFramework.Godot.Tests/GFramework.Godot.Tests.csproj -c Release --filter FullyQualifiedName~GodotLog -nologo
    • 结果:通过
    • 备注:定向新增 Godot logging 配置 / 模板回归共 11 项通过
  • dotnet test GFramework.Godot.Tests/GFramework.Godot.Tests.csproj -c Release -nologo
    • 结果:通过
    • 备注Godot 测试项目共 69 项通过
  • dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter FullyQualifiedName~Logging -nologo
    • 结果:通过
    • 备注Core logging 相关测试共 214 项通过,覆盖 AbstractLogger 动态最小级别改造回归

下一步

  1. 评估是否需要把 Godot 控制台输出收敛成 Core 可组合 sink / appender而不是继续扩张独立 provider 逻辑
  2. 若继续做 Godot logger 能力,优先补真实宿主下的配置 reload / 输出行为回归,而不是再添加新的公开入口
  3. 若本轮改动进入 PR后续 review / follow-up 继续写回本 topic而不是另开第二份 Godot logging 追踪