mirror of
https://github.com/GeWuYou/GFramework.git
synced 2026-05-07 00:39:00 +08:00
docs(ai-plan): 更新告警基线追踪
- 更新 analyzer warning reduction 的 active tracking 到 RP-046 并记录 solution 级 891 条 warning 基线 - 补充前台构建与日志采集形态不一致的环境风险和后续恢复建议
This commit is contained in:
gewuyou
parent
a0ce04b185
commit
091b872c86
@ -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<string, string>` 后，`CloneFile` 仍会在底层是 `Dictionary` 时保留 comparer，从而避免改变现有 key 比较行为
|
||||
- `LocalizationMap` 现在通过私有只读字典与 `IReadOnlyDictionary<string, string>` 暴露映射，消费者 `GodotLocalizationSettings` 仍只按只读方式使用这些映射
|
||||
- 当前 worktree 的推荐构建入口仍是 `bash scripts/dotnet-wsl.sh <dotnet-command> ...`
|
||||
- 当前前台 `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` 这几条环境线索
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user