gewuyou/GFramework
1
0
Fork 0
mirror of https://github.com/GeWuYou/GFramework.git synced 2026-05-13 14:14:29 +08:00
Code Issues Packages Projects Releases Wiki Activity
GFramework/ai-plan/public/analyzer-warning-reduction/traces/analyzer-warning-reduction-trace.md
gewuyou 091b872c86 docs(ai-plan): 更新告警基线追踪 
- 更新 analyzer warning reduction 的 active tracking 到 RP-046 并记录 solution 级 891 条 warning 基线
- 补充前台构建与日志采集形态不一致的环境风险和后续恢复建议
2026-04-24 11:57:49 +08:00

6.4 KiB
Raw Blame History

Analyzer Warning Reduction 追踪

2026-04-24 — RP-046

阶段：solution warning baseline 采样与 active plan 回写

  • 触发背景：
    • 用户纠正本轮目标为“执行 dotnet build 收集当前项目 warning，并更新当前工作树激活计划”
    • active topic 仍为 analyzer-warning-reduction，因此本轮需要先确认 solution 级 warning baseline 是否可直接从当前工作树获取
  • 主线程实施：
    • 直接执行前台 dotnet build GFramework.sln -c Release
    • 构建成功，得到 891 Warning(s) / 0 Error(s) / Time Elapsed 00:00:18.57
    • 从实时输出中确认 warning 热点主要集中在 GFramework.Godot.SourceGenerators、GFramework.Godot.SourceGenerators.Tests、GFramework.Core、GFramework.Game、GFramework.Cqrs、GFramework.Godot
    • 从实时输出中确认规则热点以 MA0051、MA0158、MA0004 为主，并伴随 MA0006、MA0002、MA0009
    • 追加尝试把同一命令改为“重定向到日志文件”“附加 file logger”“script 分配 TTY”几种采集方式；这些路径都未稳定复现前台结果，而是出现 Build FAILED / 0 Warning(s) / 0 Error(s) 或 Restore failed
    • 基于上述差异，本轮把“前台普通构建”视为 warning baseline 真值来源，并把采集形态漂移记录为环境风险
  • 本轮验证结果：
    • dotnet build GFramework.sln -c Release
      • 结果：成功；891 Warning(s)、0 Error(s)
    • dotnet build GFramework.sln -c Release > /tmp/gframework-build-warnings.log 2>&1
      • 结果：失败；约 0.78s 结束，摘要仅显示 Build FAILED / 0 Warning(s) / 0 Error(s)
    • dotnet build GFramework.sln -c Release '/flp:logfile=/tmp/gframework-build-warnings.log;verbosity=normal'
      • 结果：成功；但日志文件只保留了构建摘要，没有留下 warning 行
    • dotnet build GFramework.sln -c Release '/flp1:logfile=/tmp/gframework-build-warnings-only.log;warningsonly'
      • 结果：成功；但 warning-only 日志文件为空
    • script -q -c "dotnet build GFramework.sln -c Release" /tmp/gframework-build-full-typescript.log
      • 结果：失败；TTY 形态下 restore 于约 0.8s 退出
  • 当前结论：
    • 当前工作树的 solution 级 warning baseline 可以通过普通前台 dotnet build 获取，且样本值是 891 条 warning、0 条 error
    • 当前环境对 stdout/TTY/logger 形态敏感，不能把“把输出落到文件”的结果直接当作同等可信的构建事实
    • 下一轮 warning reduction 应以本轮前台 baseline 为准，而不是继续围绕空日志或快速失败结果做误判

2026-04-24 — RP-045

阶段：solution no-restore 阻塞面采样与 active plan 回写

  • 触发背景：
    • 用户要求显式执行 dotnet build GFramework.sln -c Release --no-restore，收集当前项目报错并同步更新当前工作树激活计划
    • active topic 仍为 analyzer-warning-reduction，因此本轮的核心工作是把 solution 级失败面与先前的 restore / warning 线索重新归并到同一个恢复点
  • 主线程实施：
    • 先执行 dotnet build GFramework.sln -c Release --no-restore，发现命令约 1 秒即失败，标准摘要只有 Build FAILED / 0 Warning(s) / 0 Error(s)
    • 补跑 dotnet build GFramework.sln -c Release --no-restore -v:diag，确认 solution 在根 GFramework.csproj 的 inner-build dispatch 阶段退出，没有进入各子项目编译
    • 继续把根项目拆成 net8.0、net9.0、net10.0 三个 --no-restore 构建，全部稳定复现同一条 MSB4018
    • 读取根项目 obj/project.assets.json，确认当前资产文件记录了 Windows restore 元数据与不存在的 fallback package folder
    • 按用户追加要求执行默认 dotnet build 与 dotnet build -v:diag，确认它不是落在相同失败层，而是更早停在 solution restore 图生成阶段
  • 本轮验证结果：
    • dotnet build GFramework.sln -c Release --no-restore
      • 结果：失败；仅有失败摘要，没有暴露真实阻塞点
    • dotnet build GFramework.sln -c Release --no-restore -v:diag
      • 结果：失败；失败位置收敛到根 GFramework.csproj
    • dotnet build
      • 结果：失败；同样约 1 秒退出，摘要仍只有 0 Warning(s) / 0 Error(s)
    • dotnet build -v:diag
      • 结果：失败；停在 GFramework.sln 的 Restore 路径 _FilterRestoreGraphProjectInputItems
      • 补充：具体落点是根 GFramework.csproj 的 _IsProjectRestoreSupported，日志记录 MSB4276，默认 SDK resolver 找不到 Microsoft.NET.SDK.WorkloadAutoImportPropsLocator
    • dotnet build GFramework.csproj -c Release -f net8.0 --no-restore
      • 结果：失败；MSB4018，ResolvePackageAssets 因缺失 D:\Tool\Development Tools\Microsoft Visual Studio\Shared\NuGetPackages 退出
    • dotnet build GFramework.csproj -c Release -f net9.0 --no-restore
      • 结果：失败；与 net8.0 相同
    • dotnet build GFramework.csproj -c Release -f net10.0 --no-restore
      • 结果：失败；与 net8.0 相同
  • 当前结论：
    • 默认 dotnet build 与 dotnet build GFramework.sln -c Release --no-restore 失败，但二者不是同一层错误；前者先死在 restore 图阶段，后者死在资产解析阶段
    • 当前 solution 级 --no-restore 阻塞不是代码编译错误，而是根项目资产文件引用了当前 WSL 不存在的 Windows fallback package folder
    • 当前 restore 路径还额外暴露出 SDK / workload resolver 环境问题，因此仅仅重建资产文件还不足以恢复默认 dotnet build
    • 这一层阻塞比先前记录的 NU1301 更靠前，因为它会让 --no-restore 构建在读取资产阶段直接退出
    • Meziantou.Polyfill 1.0.116 缺失 / NU1301 仍然是 restore 路径的独立风险；修复资产文件后仍需继续处理
    • active tracking 已升级到 RP-045，下一轮恢复应先重建与当前环境一致的根项目资产文件，再回测 solution --no-restore

Archive Context