mirror of https://github.com/GeWuYou/GFramework.git synced 2026-05-14 06:34:30 +08:00

gewuyou c82e981b7e perf(cqrs): 收口请求管线基准宿主

- 新增 request pipeline benchmark 的 handwritten generated request registry，并通过真实程序集注册路径接上 generated invoker provider

- 更新 RequestPipelineBenchmarks 宿主接线与 benchmark README，统一默认 request 与 pipeline 场景的 generated-provider 口径

- 更新 CQRS 迁移 tracking 与 trace，记录 RP-106 的基线、验证结果与下一恢复点

2026-05-08 12:38:18 +08:00

39 KiB

Raw Blame History

CQRS 重写迁移跟踪

目标

围绕 GFramework 当前的双轨 CQRS 现状，继续完成以“去外部依赖、降低反射、收口公开入口”为目标的 CQRS 迁移与收敛。

当前恢复点

恢复点编号：CQRS-REWRITE-RP-106
当前阶段：Phase 8
当前 PR 锚点：PR #340
当前结论：
- GFramework.Cqrs 已完成对外部 Mediator 的生产级替代，当前主线已从“是否可替代”转向“仓库内部收口与能力深化顺序”
- dispatch/invoker 生成前移已扩展到 request / stream 路径，RP-077 已补齐 request invoker provider gate 与 stream gate 对称的 descriptor / descriptor entry runtime 合同回归
- RP-078 已补齐 mixed fallback metadata 在 runtime 不允许多个 fallback attribute 实例时的单字符串 attribute 回退回归
- RP-079 已补齐 runtime 缺少 generated handler registry interface 时的 generator 静默跳过回归
- RP-080 已将基础 generation gate 回归扩展到 notification handler interface、stream handler interface 与 registry attribute 缺失分支
- RP-081 已继续补齐基础 generation gate 的 logging 与 DI runtime contract 缺失分支
- 当前 RP-082 已补齐基础 generation gate 的 request handler runtime contract 缺失分支
- RP-083 已补齐 mixed direct / reflected-implementation request 与 stream invoker provider 发射顺序回归
- RP-084 已引入独立 GFramework.Cqrs.Benchmarks 项目，作为持续吸收 Mediator benchmark 组织方式的第一落点
- RP-085 已补齐 stream request benchmark，对齐 Mediator messaging benchmark 的第二个核心场景
- RP-086 已补齐 request pipeline 0 / 1 / 4 数量矩阵，开始把 benchmark 关注点从单纯 messaging steady-state 扩展到行为编排开销
- RP-087 已补齐 request startup benchmark，把 initialization 与 cold-start 维度正式纳入 GFramework.Cqrs.Benchmarks
- 当前 RP-088 已补齐 request invoker reflection / generated-provider 对照，开始直接量化 dispatcher 预热 generated descriptor 的收益
- 当前 RP-089 已补齐 stream invoker reflection / generated-provider 对照，使 generated descriptor 预热收益从 request 扩展到 stream 路径
- 当前 RP-090 已收敛 PR #326 benchmark review：统一 benchmark 最小宿主构建、冻结 GFramework 容器、限制 MediatR 扫描范围，并恢复 request startup cold-start 对照
- 当前 RP-091 已把 benchmark 项目发布面隔离与包清单校验前移到 PR：GFramework.Cqrs.Benchmarks 明确保持不可打包，publish.yml 与 ci.yml 复用同一份 packed-modules 校验脚本
- RP-092 已补齐 request handler Singleton / Transient 生命周期矩阵 benchmark，并明确把 Scoped 对照留到具备真实显式作用域边界的宿主模型后再评估
- RP-093 已把 GFramework.Core 的 legacy SendCommand / SendQuery 兼容入口收敛到底层统一 GFramework.Cqrs runtime，同时补充 Mediator 未吸收能力差距复核
- RP-094 已按 PR #334 latest-head review 收口 legacy bridge 的测试注册方式、模块运行时依赖契约、异步取消语义、XML 文档缺口与兼容文档回退边界
- RP-095 已继续收口 PR #334 剩余 review：把 legacy 同步 bridge 的阻塞等待统一切到线程池隔离 helper、补齐 ArchitectureContext / executor 共享 dispatch helper、修正 bridge fixture 的并行与容器释放约束，并为 runtime bridge 与 async void command cancellation 增补回归测试
- RP-096 已再次使用 $gframework-pr-review 复核 PR #334 latest-head review，确认仍显示为 open 的 AI threads 在本地代码中已无新增仍成立的运行时 / 测试 / 文档缺陷，剩余差异主要是 GitHub thread 未 resolve 的状态滞后
- RP-097 已继续收口 PR #334 latest-head nitpick：为 AsyncQueryExecutorTests / CommandExecutorTests 补齐可观察的上下文保留断言，并让 RecordingCqrsRuntime 在测试替身返回错误响应类型时抛出带请求/类型信息的诊断异常
- 当前 RP-098 已再次使用 $gframework-pr-review 复核 PR #334 latest-head review，并收口 LegacyCqrsDispatchHelper.TryResolveDispatchContext(...) 过宽吞掉 InvalidOperationException 的真实运行时诊断退化问题；现在仅把“上下文尚未就绪”视为允许 fallback 的信号，并为 fallback / 异常冒泡分别补齐回归测试
- RP-099 已补齐 GFramework.Cqrs 的最小 stream pipeline seam：新增 IStreamPipelineBehavior<,> / StreamMessageHandlerDelegate<,>、RegisterCqrsStreamPipelineBehavior<TBehavior>()、dispatcher 侧 stream pipeline executor 缓存与 generated stream invoker 兼容回归，以及 Architecture 公开注册入口与对应文档说明
- 当前 RP-100 已使用 $gframework-pr-review 复核 PR #339 latest-head review：收口 RegisterCqrsStreamPipelineBehavior<TBehavior>() 的异常契约文档、为 StreamPipelineInvocation.GetContinuation(...) 补齐并发 continuation 缓存说明、抽取 MicrosoftDiContainer 的 CQRS 行为注册公共逻辑，并顺手修复当前 branch diff 内 ICqrsRequestInvokerProvider.cs 的 XML 缩进格式问题
- 当前 RP-101 已按用户新增 benchmark 诉求收口 request 热路径：为 IIocContainer 新增不激活实例的 HasRegistration(Type)、让 dispatcher 在 0 pipeline 场景下跳过空行为解析，并为 MicrosoftDiContainer 的热路径查询补齐 debug-level 守卫，避免无效日志字符串分配
- 当前 RP-102 已把 GFramework.Cqrs.Benchmarks 的 Mediator 对照组收口为官方 NuGet 引用（Mediator.Abstractions / Mediator.SourceGenerator 3.0.2），不再使用本地 ai-libs/Mediator project reference；RequestBenchmarks 现已新增 source-generated concrete Mediator 对照方法，并通过 RequestLifetimeBenchmarks 复核 hot path 收口后的新基线
- 当前 RP-102 已将 BenchmarkDotNet.Artifacts/ 收口为默认忽略路径，并把 request steady-state / lifetime benchmark 复跑升级为 CQRS 性能相关改动的默认回归门槛；当前阶段目标明确为“持续逼近 source-generated Mediator，并至少稳定超过反射版 MediatR”
- 当前 RP-103 已使用 $gframework-pr-review 复核 PR #340 latest-head review：修复 CreateStream_Should_Throw_When_Stream_Pipeline_Behavior_Context_Does_Not_Implement_IArchitectureContext 因 strict mock 未配置 HasRegistration(Type) 产生的 CI 失败，收紧 MicrosoftDiContainer.HasRegistration(Type) 到与 GetAll(Type) 一致的服务键可见性语义，补齐 IIocContainer.HasRegistration(Type) 的异常/XML 契约与 docs/zh-CN/core/ioc.md 的用户接入说明，并同步 benchmark 注释与 active tracking/trace 到当前 PR 锚点
- 当前 RP-104 已继续沿用 $gframework-batch-boot 50 压 request 热路径：先把 CqrsDispatcher.SendAsync(...) 改成 direct-return ValueTask，移除 dispatcher 自身的 async/await 状态机；再让 MicrosoftDiContainer.HasRegistration(Type) 在冻结后复用预构建的服务键索引，避免每次命中零 pipeline request 都线性扫描全部描述符；本轮 benchmark 表明第一刀显著压低 steady-state / lifetime request，第二刀在当前短跑下主要确认“无回退、收益不明显”
- 当前 RP-105 已继续沿用 $gframework-batch-boot 50 压默认 request steady-state：为 benchmark 最小宿主补齐 CQRS runtime / registrar / registration service 基础设施，让 RequestBenchmarks 不再只测反射路径，而是通过 handwritten generated registry + RegisterCqrsHandlersFromAssembly(...) 真实接上 generated request invoker provider；本轮 benchmark 表明默认 request 路径进一步从约 70.298 ns / 32 B 压到约 65.296 ns / 32 B，Singleton / Transient lifetime 也同步收敛到约 68.772 ns / 32 B 与 73.157 ns / 56 B
- 当前 RP-106 已把同一套 generated-provider 宿主收口扩展到 RequestPipelineBenchmarks：新增 handwritten GeneratedRequestPipelineBenchmarkRegistry，并让 RequestPipelineBenchmarks 改走 RegisterCqrsHandlersFromAssembly(...) + benchmark CQRS 基础设施预接线；本轮 benchmark 表明 0 pipeline steady-state 进一步收敛到约 64.755 ns / 32 B，1 pipeline 约 353.141 ns / 536 B，4 pipeline 在短跑噪音下维持约 555.083 ns / 896 B
ai-plan active 入口现以 RP-106 为最新恢复锚点；PR #340、PR #339、PR #334、PR #331、PR #326、PR #323、PR #307 与其他更早阶段细节均以下方归档或说明为准

当前活跃事实

当前分支为 feat/cqrs-optimization
本轮 $gframework-batch-boot 50 以 origin/main (4d6dbba6, 2026-05-08 11:13:33 +0800) 为基线；本地 main 仍落后，不作为 branch diff 基线
当前已提交分支相对 origin/main 的累计 branch diff 为 8 files / 358 lines
本批待提交工作树集中在 GFramework.Cqrs.Benchmarks/Messaging/RequestPipelineBenchmarks.cs、GFramework.Cqrs.Benchmarks/Messaging/GeneratedRequestPipelineBenchmarkRegistry.cs 与 GFramework.Cqrs.Benchmarks/README.md，新增 generated-provider pipeline 宿主接线后仍明显低于 $gframework-batch-boot 50 的文件阈值
GFramework.Cqrs.Benchmarks 作为 benchmark 基础设施项目，必须持续排除在 NuGet / GitHub Packages 发布集合之外
GFramework.Cqrs.Benchmarks 现已覆盖 request steady-state、pipeline 数量矩阵、startup、request/stream generated invoker，以及 request handler Singleton / Transient 生命周期矩阵
GFramework.Cqrs.Benchmarks 当前以 NuGet 方式引用 Mediator.Abstractions / Mediator.SourceGenerator 3.0.2；ai-libs/Mediator 只保留为本地源码/README 对照资料，不再参与 benchmark 项目编译
当前 request steady-state benchmark 已形成 baseline / Mediator / MediatR / GFramework.Cqrs 四方对照：最新约 5.680 ns / 32 B、6.565 ns / 32 B、54.737 ns / 232 B、63.644 ns / 32 B
当前 request lifetime benchmark 已继续收敛：Singleton 下 GFramework.Cqrs 最新约 69.896 ns / 32 B，Transient 下约 72.880 ns / 56 B；相较 RP-104 前的 73.005 ns / 32 B 与 74.757 ns / 56 B 已继续下降
当前 request pipeline benchmark 已改为与默认 request steady-state 相同的 generated-provider 宿主接线路径：0 pipeline 约 64.755 ns / 32 B，1 pipeline 约 353.141 ns / 536 B，4 pipeline 约 555.083 ns / 896 B
本轮已验证旧 benchmark 劣化的两个主热点：0 pipeline 场景下仍解析空行为列表，以及容器查询热路径在 debug 禁用时仍构造日志字符串；两者收口后，GFramework.Cqrs request 路径不再出现额外数百字节分配
HasRegistration(Type) 现在只把“同一服务键已注册”或“开放泛型服务键可闭合到目标类型”视为命中，不再把“仅以具体实现类型自注册”的行为误判为接口服务已注册；该语义与 Get(Type) / GetAll(Type) 已重新对齐
GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherContextValidationTests.cs 已同步适配 HasRegistration(Type) fast-path，避免 strict mock 因缺少新调用配置而在上下文失败语义断言前提前抛出 Moq.MockException
docs/zh-CN/core/ioc.md 已新增 HasRegistration(Type) 的使用语义、热路径用途与“按服务键而非可赋值关系判断”的示例说明
当前 request steady-state 仍落后于 source-generated Mediator 与 MediatR，但差距已从“额外数百字节分配 + 近 300ns”收敛到“零 pipeline fast-path 仍慢约 31ns / 3.6x 于 Mediator”；下一批若继续压 request dispatch，应优先评估默认路径吸收 generated invoker/provider 的空间
本轮 SendAsync(...) 的 direct-return ValueTask 改动已证明确实是有效热点：同样的短跑配置下，GFramework.Cqrs steady-state request 从约 83.823 ns 下探到 69-70 ns 区间
冻结后 HasRegistration(Type) 服务键索引化在当前短跑下没有带来同等量级的可见收益，但也没有引入功能回退或额外分配；后续若继续压零 pipeline request，应优先重新评估“默认 request 路径进一步吸收 generated invoker/provider”而不是继续堆叠同层级微优化
默认 RequestBenchmarks 与 RequestPipelineBenchmarks 现在都已通过 handwritten generated registry + 真实 RegisterCqrsHandlersFromAssembly(...) 宿主接线命中 generated request invoker provider，不再只代表纯反射 request binding 路径
当前性能回归门槛已收紧为：只要改动触达 GFramework.Cqrs request dispatch、DI 热路径、invoker/provider、pipeline 或 benchmark 宿主，就必须至少复跑 RequestBenchmarks.SendRequest_* 与 RequestLifetimeBenchmarks.SendRequest_*
当前阶段的性能验收目标已明确为：默认 request steady-state 路径不要求超过 source-generated Mediator，但必须持续逼近它，并至少稳定快于基于反射 / 扫描的 MediatR
GFramework.Core 当前已通过内部 bridge request / handler 把 legacy ICommand、IAsyncCommand、IQuery、IAsyncQuery 接到统一 ICqrsRuntime
标准 Architecture 初始化路径会自动扫描 GFramework.Core 程序集中的 legacy bridge handler，因此旧 SendCommand(...) / SendQuery(...) 无需改变用法即可进入统一 pipeline
CommandExecutor、QueryExecutor、AsyncQueryExecutor 仍保留“无 runtime 时直接执行”的回退路径，用于不依赖容器的隔离单元测试
LegacyCqrsDispatchHelper 现统一负责 runtime dispatch context 解析，以及 legacy 同步 bridge 对 ICqrsRuntime.SendAsync(...) 的线程池隔离等待
ArchitectureContext、CommandExecutor、QueryExecutor 的同步 CQRS/legacy bridge 入口不再直接在调用线程上阻塞 SendAsync(...).GetAwaiter().GetResult()
GFramework.Core.Tests 现通过 InternalsVisibleTo("GFramework.Core.Tests") 直接实例化内部 bridge handler，不再依赖字符串反射装配测试桥接注册
使用 LegacyBridgePipelineTracker 的 ArchitectureContextTests 与 ArchitectureModulesBehaviorTests 现都显式标记为 NonParallelizable
ArchitectureContextTests.CreateFrozenBridgeContext(...) 现把冻结容器所有权显式交回调用方，并在每个 bridge 用例的 finally 中释放
CommandExecutorModule、QueryExecutorModule、AsyncQueryExecutorModule 现改为 GetRequired<ICqrsRuntime>() 并在 XML 文档里显式声明注册顺序契约，避免 runtime 缺失时静默回退
LegacyAsyncQueryDispatchRequestHandler、LegacyAsyncCommandResultDispatchRequestHandler、LegacyAsyncCommandDispatchRequestHandler 现都通过 ThrowIfCancellationRequested() + WaitAsync(cancellationToken) 显式保留调用方取消可见性
相对 ai-libs/Mediator，当前仍未完全吸收的能力集中在五类：facade 公开入口、telemetry、notification publisher 策略、生成器配置与诊断、生命周期/缓存公开配置面
发布工作流已有 packed modules 校验，但 PR 工作流此前没有等价的 solution pack 产物名单校验
本地 dotnet pack GFramework.sln -c Release --no-restore -o <temp-dir> 当前只产出 14 个预期包，未复现 benchmark .nupkg
PR #334 在 2026-05-07 的 latest-head review 当前显示 CodeRabbit 10 / Greptile 5 个 open thread；本轮再次复核后确认其中大部分仍是已实质修复但未 resolve 的 stale thread，仅 LegacyCqrsDispatchHelper.TryResolveDispatchContext(...) 的异常边界仍需要继续收口
benchmark 场景现统一通过 BenchmarkHostFactory 构建最小宿主：GFramework 侧在 runtime 分发前显式 Freeze() 容器，MediatR 侧只扫描当前场景需要的 handler / behavior 类型
RequestStartupBenchmarks 已恢复 ColdStart_GFrameworkCqrs 结果产出，不再命中 No CQRS request handler registered
BenchmarkDotNet 在当前 agent 沙箱里会因自动生成的 bootstrap 脚本异常失败；同一 dotnet run --no-build 命令在沙箱外执行通过，因此本轮以沙箱外结果作为 benchmark 权威验证
已新增手动触发的 benchmark workflow；默认只验证 benchmark 项目 Release build，只有显式提供过滤器时才执行 BenchmarkDotNet 运行；过滤器输入现通过环境变量传入 shell，避免 workflow_dispatch 输入直接插值到命令行
远端 CTRF 最新汇总为 2311/2311 passed（run #1079, 2026-05-07）
MegaLinter 当前只暴露 dotnet-format 的 Restore operation failed 环境噪音，尚未提供本地仍成立的文件级格式诊断
LegacyCqrsDispatchHelper.TryResolveDispatchContext(...) 现在只会把“Context 尚未设置”或“当前没有活动上下文”识别为可安全 fallback 的缺上下文信号；其他 InvalidOperationException 将继续向上传播，避免把真实运行时故障误判成 legacy 直执行场景
CommandExecutorTests 已新增“缺上下文继续 fallback”和“意外 InvalidOperationException 必须冒泡”的回归，防止后续再次放宽该异常过滤面
PR #334 当前 latest-head open AI feedback 经过本轮本地复核与修复后，应主要剩余待 GitHub 重新索引的状态差异或已实质关闭但未 resolve 的 thread
GFramework.Core.Tests 中 legacy bridge 的“保留上下文”回归现在同时断言 bridge request 类型与目标对象执行期观察到的 IArchitectureContext
RecordingCqrsRuntime 对非 Unit 响应已显式校验返回值类型；若测试工厂返回了 null 或错误装箱类型，异常会直接指出 request 类型与期望/实际响应类型
PR #339 当前 latest-head review 仍显示 2 个 CodeRabbit open thread 与 2 个 nitpick；本轮本地复核后确认：
- GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherCacheTests.cs 的 Per_Behavior_Count 拼写已在当前 head 修正，属于 stale thread
- GFramework.Core.Abstractions/Ioc/IIocContainer.cs 的流式行为注册入口此前确实缺少 <exception> / <remarks> 契约说明，现已补齐并同步到 IArchitecture / Architecture / ArchitectureModules
- GFramework.Cqrs/Internal/CqrsDispatcher.cs 的 StreamPipelineInvocation.GetContinuation(...) 线程模型说明此前少于 request 对称路径，现已补齐并发 next() 时 continuation 缓存的语义边界
- GFramework.Core/Ioc/MicrosoftDiContainer.cs 的 request / stream 行为注册逻辑此前存在重复实现，现已抽取共享私有 helper 以避免后续生命周期或校验逻辑漂移
本地 dotnet format GFramework.Cqrs/GFramework.Cqrs.csproj --verify-no-changes 显示当前 diff 内仍有 GFramework.Cqrs/ICqrsRequestInvokerProvider.cs 的空白格式问题，本轮已修复；同一次命令报出的多条 CHARSET 提示集中在未触达的历史文件，不视为 PR #339 本轮新增 triage 结论

当前风险

顶层 GFramework.sln / GFramework.csproj 在 WSL 下仍可能受 Windows NuGet fallback 配置影响，完整 solution 级验证成本高于模块级验证
若后续新增 benchmark / example / tooling 项目但未同步校验发布面，solution 级 dotnet pack 仍可能在 tag 发布前才暴露异常包
RequestStartupBenchmarks 为了量化真正的单次 cold-start，引入了 InvocationCount=1 / UnrollFactor=1 的专用 job；该配置会触发 BenchmarkDotNet 的 MinIterationTime 提示，后续若要做稳定基线比较，还需要决定是否引入批量外层循环或自定义 cold-start harness
当前 benchmark 宿主仍刻意保持“单根容器最小宿主”模型；若要公平比较 Scoped handler 生命周期，需要先引入显式 scope 创建与 scope 内首次解析的对照基线
当前 Mediator 对照组仅先接入 steady-state request；若要把 Transient / Scoped 生命周期矩阵也纳入同一组对照，需要按 Mediator 官方 benchmark 的做法拆分 compile-time lifetime build config，而不是在同一编译产物里混用多个 lifetime
BenchmarkDotNet.Artifacts/ 现已加入仓库忽略规则；若后续确实需要提交新的基准报告，应显式挑选结果文件或改走文档归档，而不是直接纳入整个生成目录
当前 GFramework.Cqrs request steady-state 仍慢于 MediatR；在“至少超过反射版 MediatR”这个阶段目标达成前，任何相关改动都不能只看功能 build/test 结果，必须附带 benchmark 回归数据
仓库内部仍保留旧 Command / Query API、LegacyICqrsRuntime alias 与部分历史命名语义，后续若不继续分批收口，容易混淆“对外替代已完成”与“内部收口未完成”
若继续扩大 generated invoker 覆盖面，需要持续区分“可静态表达的合同”与 PreciseReflectedRegistrationSpec 等仍需保守回退的场景
legacy bridge 当前只为已有 Command / Query 兼容入口接到统一 request pipeline；若后续要继续对齐 Mediator，仍需要单独设计 stream pipeline、telemetry 与 facade 公开面，而不是把这次 bridge 当成“全部收口完成”
LegacyBridgePipelineTracker 仍是进程级静态测试辅助；虽然现在已在相关 fixture 清理阶段重置并补充线程安全说明，但若将来扩大并行 bridge fixture 数量，仍要继续控制共享状态扩散
stream pipeline 当前只在“单次建流”层面包裹 handler 调用；若后续需要 per-item 拦截、元素级重试或流内 metrics 聚合，仍需额外设计更细粒度 contract，而不是把本轮 seam 直接等同于元素级 middleware
PR #339 在 GitHub 上仍有 1 个已本地失效但未 resolve 的 stale test-thread；若后续 head 再次变化，需要重新抓取 latest-head review 确认未解决线程是否收敛
若后续继续依赖 HasRegistration(Type) 做热路径短路，新增测试替身或 strict mock 时必须同步配置该调用，否则容易在真正业务断言之前被 mock 框架短路成环境性失败

下一推荐步骤

若继续沿用 $gframework-batch-boot 50 且优先处理性能，下一批先查看 RequestLifetimeBenchmarks 与 stream/notification 对照里是否还有未吸收 generated-provider 宿主收益的低风险切片
若要把“至少超过反射版 MediatR”变成可执行目标，下一批应继续围绕 request dispatch / pipeline 路径的剩余常量开销下钻，并在每次改动后立即复跑 RequestBenchmarks、RequestLifetimeBenchmarks 与 RequestPipelineBenchmarks
若 benchmark 对照需要继续贴近 Mediator 官方设计，再扩 Mediator 的 compile-time lifetime 或 stream 对照矩阵，而不是回头重试已被 benchmark 否决的 GetAll(Type) 零行为探测方案

活跃文档

历史跟踪归档：cqrs-rewrite-history-through-rp043.md
验证历史归档：cqrs-rewrite-validation-history-through-rp062.md
RP-063 至 RP-074 验证归档：cqrs-rewrite-validation-history-rp063-through-rp074.md
RP-062 至 RP-076 trace 归档：cqrs-rewrite-history-rp062-through-rp076.md
CQRS 与 Mediator 评估归档：cqrs-vs-mediator-assessment-rp063.md
历史 trace 归档：cqrs-rewrite-history-through-rp043.md
RP-046 至 RP-061 trace 归档：cqrs-rewrite-history-rp046-through-rp061.md

说明

PR #261、PR #302、PR #305、PR #307 及更早阶段的详细过程已不再作为 active 恢复入口；如需追溯，以对应归档文件或历史 trace 段落为准
active tracking 仅保留当前恢复点、当前风险、最近权威验证与下一推荐步骤，避免 boot 落到历史阶段细节

39 KiB Raw Blame History Unescape Escape

CQRS 重写迁移跟踪

目标

当前恢复点

当前活跃事实

当前风险

最近权威验证

下一推荐步骤

活跃文档

说明

39 KiB

Raw Blame History