diff --git a/ai-plan/public/analyzer-warning-reduction/todos/analyzer-warning-reduction-tracking.md b/ai-plan/public/analyzer-warning-reduction/todos/analyzer-warning-reduction-tracking.md index 0cba238d..707b2f78 100644 --- a/ai-plan/public/analyzer-warning-reduction/todos/analyzer-warning-reduction-tracking.md +++ b/ai-plan/public/analyzer-warning-reduction/todos/analyzer-warning-reduction-tracking.md @@ -6,36 +6,59 @@ ## 当前恢复点 -- 恢复点编号：`ANALYZER-WARNING-REDUCTION-RP-042` -- 当前阶段：`Phase 42` +- 恢复点编号：`ANALYZER-WARNING-REDUCTION-RP-046` +- 当前阶段：`Phase 46` - 当前焦点： - - 已于 `2026-04-24` 使用 `gframework-pr-review` 复核当前分支 PR #280，latest-head review 仍有 `3` 条 open threads - - 本地确认这 `3` 条 open threads 均指向 `ai-plan` 文档：错误归档链接、`rp002-rp041` trace 混入 `RP-001` 段落，以及 active trace 的恢复信息失真 - - 本轮按最小写集直接修正文档恢复入口，不再扩大 `GFramework.SourceGenerators.Tests` 的代码写集 - - `RP-041` 验证完成时，分支相对 `origin/main` 的唯一变更文件数为 `4`；这说明继续只处理同一热点文件时，该指标增长会很慢 - - `GFramework.SourceGenerators.Tests` 在 `RP-042` 的 `net10.0` Release build 中仍为 `10` 条 `MA0051` warning、`0` error；剩余热点继续集中在 `CqrsHandlerRegistryGeneratorTests.cs` + - 已按用户更正后的要求执行前台 `dotnet build GFramework.sln -c Release`，收集当前工作树的 solution 级 warning 基线，并将结果回写 active plan + - 当前前台 solution Release build 已能稳定完成，结果为 `891 Warning(s)` / `0 Error(s)` / `Time Elapsed 00:00:18.57` + - 当前 baseline 仍为 `origin/main` (`e692ed3`, `2026-04-24 09:36:17 +0800`)；分支仍映射到 `fix/analyzer-warning-reduction-batch` / `GFramework-analyzer` + - 当前直接观察到的热点 warning 规则集中在 `MA0051`、`MA0158`、`MA0004`，并伴随一部分 `MA0006`、`MA0002`、`MA0009` + - 当前直接观察到的热点模块集中在 `GFramework.Godot.SourceGenerators`、`GFramework.Godot.SourceGenerators.Tests`、`GFramework.Core`、`GFramework.Game`、`GFramework.Cqrs`、`GFramework.Godot` + - 非前台形态的同命令当前不稳定：重定向到文件、`script` 分配 TTY、以及若干 logger 组合都曾快速返回 `Build FAILED / 0 Warning(s) / 0 Error(s)` 或 `Restore failed` ## 当前状态摘要 -- 已修正 `archive/todos/analyzer-warning-reduction-history-rp002-rp041.md` 中指向 `RP-001` 归档的相对链接，恢复历史入口可点击性 -- 已从 `archive/traces/analyzer-warning-reduction-history-rp002-rp041.md` 中移除误混入的 `RP-001` 段落，确保文件名与内容范围一致 -- 已刷新 active tracking / trace 的恢复点描述，使其反映当前仍待远端收敛的是文档类 review threads，而不是已处理过的代码项 -- PR #280 的 MegaLinter 仍显示 `dotnet-format` warning，但测试报告为 `2156 passed / 0 failed`；该 warning 目前更像 CI 环境 restore / SDK 噪音，而不是本地代码行为回归 +- 已通过 explorer `Rawls` 盘点出本轮最适合并行推进的低风险切片： + - `GFramework.Game/Data/UnifiedSettingsFile.cs` 的 `MA0016` + - `GFramework.Godot/Setting/Data/LocalizationMap.cs` 的 `MA0016` + - `GFramework.SourceGenerators.Tests/Cqrs/CqrsHandlerRegistryGeneratorTests.cs` 的 `MA0051` +- 已通过 explorer `Arendt` 收敛过旧构建根因：当前离线缓存只有 `Meziantou.Polyfill 1.0.110`，缺少项目请求的 `1.0.116`，导致 restore 失败并使 source-generator 相关 `netstandard2.0` 项目缺失有效引用图 +- worker `Aquinas` 已独立完成 `LocalizationMap` 收口并生成提交 `a0ce04b`（`fix(godot): 收紧本地化映射集合暴露`） +- worker `Boyle` 已完成 `UnifiedSettingsFile` / `UnifiedSettingsDataRepository` 的最小 API 形状修正，并同步更新 active todo / trace 草稿 +- 主线程本轮重新执行前台 `dotnet build GFramework.sln -c Release`，构建成功并暴露出完整 warning 面，说明当前工作树至少在交互式前台构建路径上已经恢复到可收集 analyzer baseline 的状态 +- 从实时输出可直接确认的热点包括： + - `GFramework.Godot.SourceGenerators/GodotProjectMetadataGenerator.cs`、`BindNodeSignalGenerator.cs`、`GetNodeGenerator.cs`、`Registration/AutoRegisterExportedCollectionsGenerator.cs` + - `GFramework.Godot.SourceGenerators.Tests/**` 多个 generator 测试文件 + - `GFramework.Cqrs/Internal/WeakKeyCache.cs` + - `GFramework.Core/**` 多个锁相关组件，如 `SamplingFilter.cs`、`BindableProperty.cs`、`FileAppender.cs`、`ResourceHandle.cs` + - `GFramework.Game/Config/YamlConfigSchemaValidator*.cs`、`GFramework.Game/UI/UiRouterBase.cs`、`GFramework.Game/Storage/FileStorage.cs` +- 同一轮中，多次尝试把相同命令切换到“重定向日志”“TTY 包裹”或“附加 logger 输出到文件”的形态时，构建又会退化成 `Build FAILED / 0 Warning(s) / 0 Error(s)` 或 `Restore failed` +- 这说明当前环境不只是“能否构建”的问题，还存在“前台构建”和“非前台采集”结果不一致的执行形态漂移 ## 当前活跃事实 -- 当前主题仍保持 active，因为 `GFramework.SourceGenerators.Tests` 尚有剩余 `MA0051` warning 需要决定是否继续推进 -- 继续按“单文件单方法”节奏处理 `CqrsHandlerRegistryGeneratorTests.cs` 可以稳定消除 warning，但不利于快速提高唯一变更文件数 -- 当前 PR review 已没有新的 failed-test 信号；当前优先级是提交这轮 `ai-plan` 修正并等待远端 PR threads 收敛 +- 当前主题仍保持 active，因为 analyzer warning reduction 主任务尚未结束，而且本轮新增了可直接消费的 solution warning baseline +- `CqrsHandlerRegistryGeneratorTests.cs` 当前已不再保留方法内 `const string source = """..."""` 型大型 fixture；后续只需回到真实 warning 热点继续收敛 +- `UnifiedSettingsFile.Sections` 改为 `IDictionary` 后，`CloneFile` 仍会在底层是 `Dictionary` 时保留 comparer，从而避免改变现有 key 比较行为 +- `LocalizationMap` 现在通过私有只读字典与 `IReadOnlyDictionary` 暴露映射，消费者 `GodotLocalizationSettings` 仍只按只读方式使用这些映射 +- 当前 worktree 的推荐构建入口仍是 `bash scripts/dotnet-wsl.sh ...` +- 当前前台 `dotnet build GFramework.sln -c Release` 的结果是 `891` 条 warning、`0` 条 error，且已确认不是“0 warning 的假成功” +- 当前 warning 规则的已观察集合包括 `MA0051`、`MA0158`、`MA0004`、`MA0006`、`MA0002`、`MA0009` +- 当前“非前台采集”路径仍不可信：把输出重定向到文件、追加 file logger 或经 `script` 分配 TTY 时，都未稳定复现前台结果 +- 先前已识别的 `--no-restore` 资产文件漂移、`Meziantou.Polyfill 1.0.116` 缺失、以及 `NU1301` 风险仍保留，但本轮用户要求的 warning 基线以成功的前台 `dotnet build` 结果为准 ## 当前风险 -- warning 治理策略风险：如果用户仍以“唯一变更文件数接近 `75`”作为目标，继续深挖同一测试文件会让目标推进缓慢 - - 缓解措施：下一轮先确认是继续压低 `MA0051` 基线，还是切换到新的文件写集 -- WSL 构建环境风险：当前 worktree 的 .NET 定向验证仍需显式附带 `-p:RestoreFallbackFolders=`，并在沙箱外运行以规避命名管道 / socket 限制 - - 缓解措施：后续所有 affected-project Release build 继续复用该参数组合 -- source generator test warning 范围风险：一旦继续触达 `GFramework.SourceGenerators.Tests`，剩余 warning 会继续成为本轮完成条件的一部分 - - 缓解措施：继续用最小写集和 warnings-only build 锁定范围 +- warning 采集形态漂移风险：同一个 `dotnet build GFramework.sln -c Release` 在前台可成功输出 `891` warnings，但一旦切到日志重定向、TTY 包裹或特定 logger 组合，就可能在约 `1` 秒内快速失败 + - 缓解措施：短期内把“前台普通构建”作为 warning 基线真值来源；若需要自动化统计，再单独排查 stdout/TTY/logger 相关环境差异 +- SDK / workload resolver 环境漂移风险：历史诊断样本里 Linux .NET SDK `10.0.106` 在 solution restore 图阶段报告过 `Microsoft.NET.SDK.WorkloadAutoImportPropsLocator` 缺失 + - 缓解措施：后续若要恢复脚本化或 `--no-restore` 验证，再重新检查当前 WSL `dotnet --info`、workload 解析器状态与仓库推荐构建入口是否一致 +- 资产文件环境漂移风险：历史样本中的根项目 `project.assets.json` 明显来自 Windows restore，上游记录的 fallback package folder 在当前 WSL 会话不存在 + - 缓解措施：需要重新启用 `--no-restore` 验证时，先用与 WSL 兼容的 NuGet / restore 配置重建根项目资产文件 +- 构建环境可达性风险：`Meziantou.Polyfill 1.0.116` 缺失与 `NU1301` 在旧样本中仍是有效线索 + - 缓解措施：后续若再次命中 restore 阻塞，优先核查本地缓存版本与 NuGet 可达性 +- reviewability 风险：当前分支只提交了 `LocalizationMap` 一个 warning 切片，而工作树仍保留 `ai-plan` 等未提交变更 + - 缓解措施：后续 warning reduction 继续按模块或规则切片提交，不把多个热点混成单个大提交 ## 活跃文档 @@ -48,13 +71,22 @@ ## 验证说明 -- `DOTNET_CLI_HOME=/tmp/dotnet-home dotnet restore GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -p:RestoreFallbackFolders=""` - - 结果：通过；重写了受 Windows fallback package folder 影响的测试项目资产文件 -- `DOTNET_CLI_HOME=/tmp/dotnet-home dotnet build GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -c Release -t:Rebuild --no-restore --disable-build-servers -m:1 -p:UseSharedCompilation=false -p:RestoreFallbackFolders="" -nologo -clp:"Summary;WarningsOnly"` - - 结果：`10 Warning(s)`，`0 Error(s)`；warning 仍全部来自 `CqrsHandlerRegistryGeneratorTests.cs` 的既有 `MA0051` 基线 +- `dotnet build GFramework.sln -c Release` + - 结果：成功；`891 Warning(s)`、`0 Error(s)`、`Time Elapsed 00:00:18.57` + - 补充：当前 warning 流可直接从前台交互式构建观察到；热点规则以 `MA0051`、`MA0158`、`MA0004` 为主 +- `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` 退出 +- `git --git-dir=/mnt/f/gewuyou/System/Documents/WorkSpace/GameDev/GFramework/.git/worktrees/GFramework-analyzer --work-tree=/mnt/f/gewuyou/System/Documents/WorkSpace/GameDev/GFramework-WorkTree/GFramework-analyzer branch --show-current` + - 结果：成功；当前分支为 `fix/analyzer-warning-reduction-batch` ## 下一步建议 -1. 提交 `RP-042` 后重新抓取 PR #280 review，确认这 `3` 条 latest-head open threads 是否随新提交收敛 -2. 若 PR threads 收敛，再决定下一轮是继续清理 `CqrsHandlerRegistryGeneratorTests.cs` 的剩余 `MA0051`，还是切换到新的文件写集 -3. 如果仍要继续沿用“唯一变更文件数接近 `75`”的目标，应优先切到新的 warning 写集，而不是继续深挖同一测试文件 +1. 先以本轮前台 `dotnet build GFramework.sln -c Release` 的 `891` warning baseline 为起点，优先从 `MA0051` / `MA0158` 最密集的模块切分下一批低风险整改 +2. 并行保留环境核查：检查为什么相同命令在重定向日志、TTY 包裹或 logger 组合下会快速失败，避免后续 warning 统计自动化再次失真 +3. 在需要重新启用 `--no-restore` 或脚本化验证时，再回到根 `GFramework.csproj` 资产文件漂移、SDK workload resolver、以及 `Meziantou.Polyfill 1.0.116` / `NU1301` 这几条环境线索 diff --git a/ai-plan/public/analyzer-warning-reduction/traces/analyzer-warning-reduction-trace.md b/ai-plan/public/analyzer-warning-reduction/traces/analyzer-warning-reduction-trace.md index 76acd1af..eb3a3153 100644 --- a/ai-plan/public/analyzer-warning-reduction/traces/analyzer-warning-reduction-trace.md +++ b/ai-plan/public/analyzer-warning-reduction/traces/analyzer-warning-reduction-trace.md @@ -1,28 +1,71 @@ # Analyzer Warning Reduction 追踪 -## 2026-04-24 — RP-042 +## 2026-04-24 — RP-046 -### 阶段：PR #280 review follow-up 与 ai-plan 恢复入口修正 +### 阶段：solution warning baseline 采样与 active plan 回写 -- 启动复核： - - 使用 `gframework-pr-review` 抓取当前分支 PR #280 的 latest-head review threads、MegaLinter 摘要与测试报告 - - 本地核对后确认 `3` 条 open threads 均仍成立，但全部集中在 `ai-plan` 文档恢复入口，而不是新的代码行为问题 -- 决策： - - 不再继续扩大 `GFramework.SourceGenerators.Tests` 的写集，先把远端 latest-head review 中仍成立的文档问题全部收口 - - 保持 `RP-042` 作为 active recovery point，仅刷新其事实描述、归档链接和 trace 范围边界 -- 实施调整： - - 修正 `archive/todos/analyzer-warning-reduction-history-rp002-rp041.md` 中两条指向 `RP-001` 归档的相对链接 - - 从 `archive/traces/analyzer-warning-reduction-history-rp002-rp041.md` 中移除误混入的 `RP-001` 段落，使文件只保留 `RP-002` 到 `RP-041` - - 刷新 active tracking / trace 的恢复点描述，明确当前 open threads 已收敛为文档问题，并记录本轮 follow-up 的事实与下一步 -- 验证结果： - - `DOTNET_CLI_HOME=/tmp/dotnet-home dotnet build GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -c Release -t:Rebuild --no-restore --disable-build-servers -m:1 -p:UseSharedCompilation=false -p:RestoreFallbackFolders="" -nologo -clp:"Summary;WarningsOnly"` - - 结果：`10 Warning(s)`，`0 Error(s)`；warning 仍全部来自 `CqrsHandlerRegistryGeneratorTests.cs` 的既有 `MA0051` 基线 +- 触发背景： + - 用户纠正本轮目标为“执行 `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` 退出 - 当前结论： - - PR #280 当前没有 failed-test 回归信号；latest-head review 剩余项可以全部在 `ai-plan` 范围内处理 - - active 恢复入口与历史归档范围已重新对齐，后续 `boot` 不会再从 `rp002-rp041` 误读 `RP-001` -- 下一步建议： - - 提交后重新抓取 PR #280 review，确认 open threads 是否收敛 - - 若 threads 收敛，则回到 `CqrsHandlerRegistryGeneratorTests.cs` 剩余 `MA0051`，或根据目标改切新的 warning 写集 + - 当前工作树的 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