diff --git a/GFramework.Cqrs.Benchmarks/Messaging/BenchmarkHostFactory.cs b/GFramework.Cqrs.Benchmarks/Messaging/BenchmarkHostFactory.cs index 61f3a13d..34397dc1 100644 --- a/GFramework.Cqrs.Benchmarks/Messaging/BenchmarkHostFactory.cs +++ b/GFramework.Cqrs.Benchmarks/Messaging/BenchmarkHostFactory.cs @@ -165,33 +165,30 @@ internal static class BenchmarkHostFactory /// 在真实的 request 级作用域内执行一次 GFramework.CQRS request 分发。 /// /// 请求响应类型。 - /// 冻结后的 benchmark 根容器,用于创建 request 作用域并提供注册元数据。 - /// 当前 request 级 runtime 复用的日志器。 + /// 复用的 scoped benchmark runtime。 + /// 负责为每次 request 激活独立作用域的只读容器适配层。 /// 当前 CQRS 分发上下文。 /// 要发送的 request。 /// 取消令牌。 /// 当前 request 的响应结果。 /// - /// 该入口只服务 request lifetime benchmark:每次调用都会显式创建并释放一个新的 DI 作用域, - /// 让 `Scoped` handler 在真实 request 边界内解析,而不是退化为根容器解析。 + /// 该入口只服务 request lifetime benchmark:它会复用同一个 dispatcher/runtime 实例, + /// 但在每次调用前后显式创建并释放新的 DI 作用域, + /// 让 `Scoped` handler 在真实 request 边界内解析,而不是退化为根容器解析或额外计入 runtime 构造成本。 /// internal static async ValueTask SendScopedGFrameworkRequestAsync( - MicrosoftDiContainer rootContainer, - ILogger runtimeLogger, + ICqrsRuntime runtime, + ScopedBenchmarkContainer scopedContainer, ICqrsContext context, GFramework.Cqrs.Abstractions.Cqrs.IRequest request, CancellationToken cancellationToken = default) { - ArgumentNullException.ThrowIfNull(rootContainer); - ArgumentNullException.ThrowIfNull(runtimeLogger); + ArgumentNullException.ThrowIfNull(runtime); + ArgumentNullException.ThrowIfNull(scopedContainer); ArgumentNullException.ThrowIfNull(context); ArgumentNullException.ThrowIfNull(request); - using var scope = rootContainer.CreateScope(); - var scopedContainer = new ScopedBenchmarkContainer(rootContainer, scope); - var runtime = GFramework.Cqrs.CqrsRuntimeFactory.CreateRuntime( - scopedContainer, - runtimeLogger); + using var scopeLease = scopedContainer.EnterScope(); return await runtime.SendAsync(context, request, cancellationToken).ConfigureAwait(false); } @@ -223,8 +220,8 @@ internal static class BenchmarkHostFactory /// 在真实的 request 级作用域内创建一次 GFramework.CQRS stream,并让该作用域覆盖整个异步枚举周期。 /// /// stream 响应元素类型。 - /// 冻结后的 benchmark 根容器,用于创建 request 作用域并提供注册元数据。 - /// 当前 request 级 runtime 复用的日志器。 + /// 复用的 scoped benchmark runtime。 + /// 负责为每次 stream 激活独立作用域的只读容器适配层。 /// 当前 CQRS 分发上下文。 /// 要创建 stream 的 request。 /// 取消令牌。 @@ -235,18 +232,18 @@ internal static class BenchmarkHostFactory /// 避免 `Scoped` handler 退化成“建流后立刻释放 scope,再在根容器语义下继续枚举”的错误模型。 /// internal static IAsyncEnumerable CreateScopedGFrameworkStream( - MicrosoftDiContainer rootContainer, - ILogger runtimeLogger, + ICqrsRuntime runtime, + ScopedBenchmarkContainer scopedContainer, ICqrsContext context, GFramework.Cqrs.Abstractions.Cqrs.IStreamRequest request, CancellationToken cancellationToken = default) { - ArgumentNullException.ThrowIfNull(rootContainer); - ArgumentNullException.ThrowIfNull(runtimeLogger); + ArgumentNullException.ThrowIfNull(runtime); + ArgumentNullException.ThrowIfNull(scopedContainer); ArgumentNullException.ThrowIfNull(context); ArgumentNullException.ThrowIfNull(request); - return EnumerateScopedGFrameworkStreamAsync(rootContainer, runtimeLogger, context, request, cancellationToken); + return EnumerateScopedGFrameworkStreamAsync(runtime, scopedContainer, context, request, cancellationToken); } /// @@ -279,7 +276,7 @@ internal static class BenchmarkHostFactory /// 可直接解析 generated `Mediator.Mediator` 的 DI 宿主。 /// /// 当前 benchmark 只把 `Mediator` 作为单例 steady-state 对照组接入, - /// 因为它的 lifetime 由 source generator 在编译期塑形;若后续需要 `Transient` / `Scoped` 矩阵, + /// 因为它的 lifetime 由 source generator 在编译期塑形;若后续需要 `Transient` / `Scoped` 矩阵, /// 应按 `Mediator` 官方 benchmark 的做法拆成独立 build config,而不是在同一编译产物里混用多个 lifetime。 /// internal static ServiceProvider CreateMediatorServiceProvider(Action? configure) @@ -310,17 +307,13 @@ internal static class BenchmarkHostFactory /// 在单个显式作用域内创建并枚举 GFramework.CQRS stream。 /// private static async IAsyncEnumerable EnumerateScopedGFrameworkStreamAsync( - MicrosoftDiContainer rootContainer, - ILogger runtimeLogger, + ICqrsRuntime runtime, + ScopedBenchmarkContainer scopedContainer, ICqrsContext context, GFramework.Cqrs.Abstractions.Cqrs.IStreamRequest request, [System.Runtime.CompilerServices.EnumeratorCancellation] CancellationToken cancellationToken) { - using var scope = rootContainer.CreateScope(); - var scopedContainer = new ScopedBenchmarkContainer(rootContainer, scope); - var runtime = GFramework.Cqrs.CqrsRuntimeFactory.CreateRuntime( - scopedContainer, - runtimeLogger); + using var scopeLease = scopedContainer.EnterScope(); var stream = runtime.CreateStream(context, request, cancellationToken); await foreach (var response in stream.ConfigureAwait(false)) diff --git a/GFramework.Cqrs.Benchmarks/Messaging/RequestLifetimeBenchmarks.cs b/GFramework.Cqrs.Benchmarks/Messaging/RequestLifetimeBenchmarks.cs index 8a9458b0..4c0e5306 100644 --- a/GFramework.Cqrs.Benchmarks/Messaging/RequestLifetimeBenchmarks.cs +++ b/GFramework.Cqrs.Benchmarks/Messaging/RequestLifetimeBenchmarks.cs @@ -32,6 +32,8 @@ public class RequestLifetimeBenchmarks { private MicrosoftDiContainer _container = null!; private ICqrsRuntime? _runtime; + private ScopedBenchmarkContainer? _scopedContainer; + private ICqrsRuntime? _scopedRuntime; private ServiceProvider _serviceProvider = null!; private IMediator? _mediatr; private BenchmarkRequestHandler _baselineHandler = null!; @@ -111,6 +113,13 @@ public class RequestLifetimeBenchmarks _container, _runtimeLogger); } + else + { + _scopedContainer = new ScopedBenchmarkContainer(_container); + _scopedRuntime = GFramework.Cqrs.CqrsRuntimeFactory.CreateRuntime( + _scopedContainer, + _runtimeLogger); + } _serviceProvider = BenchmarkHostFactory.CreateMediatRServiceProvider( configure: null, @@ -157,8 +166,8 @@ public class RequestLifetimeBenchmarks if (Lifetime == HandlerLifetime.Scoped) { return BenchmarkHostFactory.SendScopedGFrameworkRequestAsync( - _container, - _runtimeLogger, + _scopedRuntime!, + _scopedContainer!, BenchmarkContext.Instance, _request, CancellationToken.None); diff --git a/GFramework.Cqrs.Benchmarks/Messaging/ScopedBenchmarkContainer.cs b/GFramework.Cqrs.Benchmarks/Messaging/ScopedBenchmarkContainer.cs index 29c51d71..536c7009 100644 --- a/GFramework.Cqrs.Benchmarks/Messaging/ScopedBenchmarkContainer.cs +++ b/GFramework.Cqrs.Benchmarks/Messaging/ScopedBenchmarkContainer.cs @@ -14,34 +14,53 @@ using Microsoft.Extensions.DependencyInjection; namespace GFramework.Cqrs.Benchmarks.Messaging; /// -/// 把冻结后的 benchmark 根容器与单个 组合成 request 级解析视图。 +/// 把冻结后的 benchmark 根容器适配成可重复进入的 request 级解析视图。 /// /// /// `CqrsDispatcher` 会直接依赖 做 handler / pipeline 解析, -/// 因此 request lifetime benchmark 需要一个既保留根容器注册元数据,又把实例解析切换到显式作用域 provider -/// 的最小适配层。该类型只覆盖 benchmark 当前 request 路径会使用到的解析相关入口; +/// 因此 request lifetime benchmark 需要一个既保留根容器注册元数据,又能在每次 benchmark 调用时把实例解析切换到 +/// 显式作用域 provider 的最小适配层。该类型只覆盖 benchmark 当前 request 路径会使用到的解析相关入口; /// 任何注册、清空或冻结修改操作都应继续发生在根容器构建阶段,因此这里统一拒绝可变更 API。 /// internal sealed class ScopedBenchmarkContainer : IIocContainer { private readonly MicrosoftDiContainer _rootContainer; - private readonly IServiceProvider _scopedProvider; + private IServiceScope? _activeScope; + private IServiceProvider? _scopedProvider; /// /// 初始化一个绑定到单个 request 作用域的 benchmark 容器适配器。 /// /// 已冻结的 benchmark 根容器。 - /// 当前 request 独占的作用域实例。 - internal ScopedBenchmarkContainer(MicrosoftDiContainer rootContainer, IServiceScope scope) + internal ScopedBenchmarkContainer(MicrosoftDiContainer rootContainer) { _rootContainer = rootContainer ?? throw new ArgumentNullException(nameof(rootContainer)); - ArgumentNullException.ThrowIfNull(scope); - _scopedProvider = scope.ServiceProvider; + } + + /// + /// 为当前 benchmark 调用创建并持有一个新的 request 级作用域。 + /// + /// 离开作用域时负责释放本次 request 级作用域的租约。 + /// 当前适配器仍持有上一次尚未释放的作用域。 + internal ScopeLease EnterScope() + { + if (_activeScope is not null) + { + throw new InvalidOperationException( + "Scoped benchmark containers do not support overlapping active scopes."); + } + + _activeScope = _rootContainer.CreateScope(); + _scopedProvider = _activeScope.ServiceProvider; + return new ScopeLease(this); } /// /// 当前适配器不支持在 request 作用域内追加注册。 /// + /// 实例类型。 + /// 原本要注册到根容器中的单例实例。 + /// 当前适配器始终为只读视图。 public void RegisterSingleton(T instance) { throw CreateMutationNotSupportedException(); @@ -50,6 +69,9 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer /// /// 当前适配器不支持在 request 作用域内追加注册。 /// + /// 服务契约类型。 + /// 服务实现类型。 + /// 当前适配器始终为只读视图。 public void RegisterSingleton() where TImpl : class, TService where TService : class @@ -60,6 +82,9 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer /// /// 当前适配器不支持在 request 作用域内追加注册。 /// + /// 服务契约类型。 + /// 服务实现类型。 + /// 当前适配器始终为只读视图。 public void RegisterTransient() where TImpl : class, TService where TService : class @@ -70,6 +95,9 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer /// /// 当前适配器不支持在 request 作用域内追加注册。 /// + /// 服务契约类型。 + /// 服务实现类型。 + /// 当前适配器始终为只读视图。 public void RegisterScoped() where TImpl : class, TService where TService : class @@ -80,6 +108,8 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer /// /// 当前适配器不支持在 request 作用域内追加注册。 /// + /// 原本要附加到复数注册集合中的实例。 + /// 当前适配器始终为只读视图。 public void RegisterPlurality(object instance) { throw CreateMutationNotSupportedException(); @@ -88,6 +118,8 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer /// /// 当前适配器不支持在 request 作用域内追加注册。 /// + /// 复数注册项类型。 + /// 当前适配器始终为只读视图。 public void RegisterPlurality() where T : class { throw CreateMutationNotSupportedException(); @@ -96,6 +128,8 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer /// /// 当前适配器不支持在 request 作用域内追加注册。 /// + /// 原本要注册到容器中的系统实例。 + /// 当前适配器始终为只读视图。 public void RegisterSystem(ISystem system) { throw CreateMutationNotSupportedException(); @@ -104,6 +138,9 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer /// /// 当前适配器不支持在 request 作用域内追加注册。 /// + /// 实例类型。 + /// 原本要注册到容器中的实例。 + /// 当前适配器始终为只读视图。 public void Register(T instance) { throw CreateMutationNotSupportedException(); @@ -112,6 +149,9 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer /// /// 当前适配器不支持在 request 作用域内追加注册。 /// + /// 原本要绑定的服务类型。 + /// 原本要绑定到该类型的实例。 + /// 当前适配器始终为只读视图。 public void Register(Type type, object instance) { throw CreateMutationNotSupportedException(); @@ -120,6 +160,9 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer /// /// 当前适配器不支持在 request 作用域内追加注册。 /// + /// 工厂要创建的服务类型。 + /// 原本要注册的工厂委托。 + /// 当前适配器始终为只读视图。 public void RegisterFactory(Func factory) where TService : class { throw CreateMutationNotSupportedException(); @@ -128,6 +171,8 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer /// /// 当前适配器不支持在 request 作用域内追加注册。 /// + /// 原本要注册的 request pipeline 行为类型。 + /// 当前适配器始终为只读视图。 public void RegisterCqrsPipelineBehavior() where TBehavior : class { throw CreateMutationNotSupportedException(); @@ -136,6 +181,8 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer /// /// 当前适配器不支持在 request 作用域内追加注册。 /// + /// 原本要注册的 stream pipeline 行为类型。 + /// 当前适配器始终为只读视图。 public void RegisterCqrsStreamPipelineBehavior() where TBehavior : class { throw CreateMutationNotSupportedException(); @@ -144,6 +191,8 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer /// /// 当前适配器不支持在 request 作用域内追加注册。 /// + /// 原本要扫描 CQRS handler 的程序集。 + /// 当前适配器始终为只读视图。 public void RegisterCqrsHandlersFromAssembly(System.Reflection.Assembly assembly) { throw CreateMutationNotSupportedException(); @@ -152,6 +201,8 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer /// /// 当前适配器不支持在 request 作用域内追加注册。 /// + /// 原本要扫描 CQRS handler 的程序集集合。 + /// 当前适配器始终为只读视图。 public void RegisterCqrsHandlersFromAssemblies(IEnumerable assemblies) { throw CreateMutationNotSupportedException(); @@ -160,6 +211,8 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer /// /// 当前适配器不支持执行额外的服务配置钩子。 /// + /// 原本要执行的服务配置委托。 + /// 当前适配器始终为只读视图。 public void ExecuteServicesHook(Action? configurator = null) { throw CreateMutationNotSupportedException(); @@ -168,57 +221,87 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer /// /// 从当前 request 作用域解析单个服务实例。 /// + /// 目标服务类型。 + /// 解析到的服务实例;若当前作用域未注册则返回 + /// 调用方尚未通过 激活作用域。 public T? Get() where T : class { - return _scopedProvider.GetService(); + return GetScopedProvider().GetService(); } /// /// 从当前 request 作用域解析单个服务实例。 /// + /// 目标服务类型。 + /// 解析到的服务实例;若当前作用域未注册则返回 + /// + /// 调用方尚未通过 激活作用域。 public object? Get(Type type) { ArgumentNullException.ThrowIfNull(type); - return _scopedProvider.GetService(type); + return GetScopedProvider().GetService(type); } /// /// 从当前 request 作用域解析必需的单个服务实例。 /// + /// 目标服务类型。 + /// 解析到的服务实例。 + /// + /// 调用方尚未通过 激活作用域,或当前作用域缺少必需服务。 + /// public T GetRequired() where T : class { - return _scopedProvider.GetRequiredService(); + return GetScopedProvider().GetRequiredService(); } /// /// 从当前 request 作用域解析必需的单个服务实例。 /// + /// 目标服务类型。 + /// 解析到的服务实例。 + /// + /// + /// 调用方尚未通过 激活作用域,或当前作用域缺少必需服务。 + /// public object GetRequired(Type type) { ArgumentNullException.ThrowIfNull(type); - return _scopedProvider.GetRequiredService(type); + return GetScopedProvider().GetRequiredService(type); } /// /// 从当前 request 作用域解析全部服务实例。 /// + /// 目标服务类型。 + /// 当前作用域中该服务类型的全部实例。 + /// 调用方尚未通过 激活作用域。 public IReadOnlyList GetAll() where T : class { - return _scopedProvider.GetServices().ToList(); + return GetScopedProvider().GetServices().ToList(); } /// /// 从当前 request 作用域解析全部服务实例。 /// + /// 目标服务类型。 + /// 当前作用域中该服务类型的全部实例。 + /// + /// 调用方尚未通过 激活作用域。 public IReadOnlyList GetAll(Type type) { ArgumentNullException.ThrowIfNull(type); - return _scopedProvider.GetServices(type).Where(static service => service is not null).Cast().ToList(); + return GetScopedProvider().GetServices(type).Where(static service => service is not null).Cast().ToList(); } /// /// 从当前 request 作用域解析全部服务实例,并按调用方比较器排序。 /// + /// 目标服务类型。 + /// 用于排序的比较器。 + /// 按比较器排序后的服务列表。 + /// + /// 调用方尚未通过 激活作用域。 public IReadOnlyList GetAllSorted(Comparison comparison) where T : class { ArgumentNullException.ThrowIfNull(comparison); @@ -231,6 +314,9 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer /// /// 从当前 request 作用域解析全部服务实例,并按优先级排序。 /// + /// 目标服务类型。 + /// 按优先级稳定排序后的服务列表。 + /// 调用方尚未通过 激活作用域。 public IReadOnlyList GetAllByPriority() where T : class { return SortByPriority(GetAll()); @@ -239,6 +325,10 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer /// /// 从当前 request 作用域解析全部服务实例,并按优先级排序。 /// + /// 目标服务类型。 + /// 按优先级稳定排序后的服务列表。 + /// + /// 调用方尚未通过 激活作用域。 public IReadOnlyList GetAllByPriority(Type type) { ArgumentNullException.ThrowIfNull(type); @@ -248,10 +338,13 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer /// /// 判断根容器是否声明了目标服务键。 /// + /// 目标服务类型。 + /// 根容器中声明了该服务键时返回 /// /// `CqrsDispatcher` 在热路径上先做注册存在性判断,再决定是否枚举 pipeline;这里沿用根容器冻结后的注册视图, /// 避免把“当前 scope 还未物化实例”误判成“没有注册该行为”。 /// + /// public bool HasRegistration(Type type) { ArgumentNullException.ThrowIfNull(type); @@ -261,6 +354,8 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer /// /// 判断根容器是否声明了目标服务键。 /// + /// 目标服务类型。 + /// 根容器中声明了该服务键时返回 public bool Contains() where T : class { return _rootContainer.Contains(); @@ -269,6 +364,8 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer /// /// 当前 request 作用域适配器不追踪实例归属。 /// + /// 待检查的实例。 + /// 若根容器已追踪该实例,则返回根容器的检查结果。 public bool ContainsInstance(object instance) { return _rootContainer.ContainsInstance(instance); @@ -277,6 +374,7 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer /// /// 当前适配器不支持清空注册。 /// + /// 当前适配器始终为只读视图。 public void Clear() { throw CreateMutationNotSupportedException(); @@ -285,6 +383,7 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer /// /// 当前适配器不支持重新冻结。 /// + /// 当前适配器始终为只读视图。 public void Freeze() { throw CreateMutationNotSupportedException(); @@ -293,19 +392,23 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer /// /// 继续暴露根容器底层服务集合,仅用于接口兼容。 /// + /// 根容器当前持有的底层服务集合。 public IServiceCollection GetServicesUnsafe => _rootContainer.GetServicesUnsafe; /// /// 基于当前 request 作用域继续创建嵌套作用域。 /// + /// 从当前激活作用域继续派生出的子作用域。 + /// 调用方尚未通过 激活作用域。 public IServiceScope CreateScope() { - return _scopedProvider.CreateScope(); + return GetScopedProvider().CreateScope(); } /// /// 将上下文转发给根容器,保持与 request 生命周期无关的上下文缓存行为一致。 /// + /// 要绑定到根容器的架构上下文。 public void SetContext(GFramework.Core.Abstractions.Architectures.IArchitectureContext context) { ((IContextAware)_rootContainer).SetContext(context); @@ -314,21 +417,47 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer /// /// 读取根容器当前持有的架构上下文。 /// + /// 根容器当前保存的架构上下文。 public GFramework.Core.Abstractions.Architectures.IArchitectureContext GetContext() { return ((IContextAware)_rootContainer).GetContext(); } /// - /// 释放当前 request 适配器时不拥有作用域;外层 benchmark 调度入口负责统一释放。 + /// 释放当前 request 适配器时,同时兜底释放任何尚未归还的激活作用域。 /// public void Dispose() { + ReleaseActiveScope(); + } + + /// + /// 读取当前激活的 request 级作用域服务提供器。 + /// + /// 当前作用域对应的服务提供器。 + /// 调用方尚未通过 激活作用域。 + private IServiceProvider GetScopedProvider() + { + return _scopedProvider ?? throw new InvalidOperationException( + "Scoped benchmark containers require an active scope. Call EnterScope() before resolving scoped services."); + } + + /// + /// 释放当前激活的 request 级作用域,并清空解析视图。 + /// + private void ReleaseActiveScope() + { + _scopedProvider = null; + + var activeScope = _activeScope; + _activeScope = null; + activeScope?.Dispose(); } /// /// 生成统一的只读适配器异常,避免 benchmark 误把 request 级容器当成可变组合根。 /// + /// 描述当前适配器只读语义的统一异常。 private static InvalidOperationException CreateMutationNotSupportedException() { return new InvalidOperationException( @@ -358,4 +487,29 @@ internal sealed class ScopedBenchmarkContainer : IIocContainer .Select(static x => x.Service) .ToList(); } + + /// + /// 表示一次激活中的 request 级作用域租约。 + /// + internal readonly struct ScopeLease : IDisposable + { + private readonly ScopedBenchmarkContainer _owner; + + /// + /// 初始化一个绑定到目标适配器的作用域租约。 + /// + /// 拥有当前作用域的 benchmark 容器适配器。 + internal ScopeLease(ScopedBenchmarkContainer owner) + { + _owner = owner ?? throw new ArgumentNullException(nameof(owner)); + } + + /// + /// 释放当前 request 级作用域。 + /// + public void Dispose() + { + _owner.ReleaseActiveScope(); + } + } } diff --git a/GFramework.Cqrs.Benchmarks/Messaging/StreamLifetimeBenchmarks.cs b/GFramework.Cqrs.Benchmarks/Messaging/StreamLifetimeBenchmarks.cs index 3f1c1738..7dbb5d78 100644 --- a/GFramework.Cqrs.Benchmarks/Messaging/StreamLifetimeBenchmarks.cs +++ b/GFramework.Cqrs.Benchmarks/Messaging/StreamLifetimeBenchmarks.cs @@ -37,8 +37,12 @@ public class StreamLifetimeBenchmarks { private MicrosoftDiContainer _reflectionContainer = null!; private ICqrsRuntime _reflectionRuntime = null!; + private ScopedBenchmarkContainer? _scopedReflectionContainer; + private ICqrsRuntime? _scopedReflectionRuntime; private MicrosoftDiContainer _generatedContainer = null!; private ICqrsRuntime _generatedRuntime = null!; + private ScopedBenchmarkContainer? _scopedGeneratedContainer; + private ICqrsRuntime? _scopedGeneratedRuntime; private ServiceProvider _serviceProvider = null!; private IMediator _mediatr = null!; private ReflectionBenchmarkStreamHandler _baselineHandler = null!; @@ -118,56 +122,11 @@ public class StreamLifetimeBenchmarks [GlobalSetup] public void Setup() { - LoggerFactoryResolver.Provider = new ConsoleLoggerFactoryProvider - { - MinLevel = LogLevel.Fatal - }; - Fixture.Setup($"StreamLifetime/{Lifetime}", handlerCount: 1, pipelineCount: 0); - BenchmarkDispatcherCacheHelper.ClearDispatcherCaches(); - - _baselineHandler = new ReflectionBenchmarkStreamHandler(); - _reflectionRequest = new ReflectionBenchmarkStreamRequest(Guid.NewGuid(), 3); - _generatedRequest = new GeneratedBenchmarkStreamRequest(Guid.NewGuid(), 3); - _mediatrRequest = new MediatRBenchmarkStreamRequest(Guid.NewGuid(), 3); - _reflectionRuntimeLogger = - LoggerFactoryResolver.Provider.CreateLogger(nameof(StreamLifetimeBenchmarks) + ".Reflection." + Lifetime); - _generatedRuntimeLogger = - LoggerFactoryResolver.Provider.CreateLogger(nameof(StreamLifetimeBenchmarks) + ".Generated." + Lifetime); - - _reflectionContainer = BenchmarkHostFactory.CreateFrozenGFrameworkContainer(container => - { - RegisterReflectionHandler(container, Lifetime); - }); - if (Lifetime != HandlerLifetime.Scoped) - { - _reflectionRuntime = GFramework.Cqrs.CqrsRuntimeFactory.CreateRuntime( - _reflectionContainer, - _reflectionRuntimeLogger); - } - - _generatedContainer = BenchmarkHostFactory.CreateFrozenGFrameworkContainer(container => - { - BenchmarkHostFactory.RegisterGeneratedBenchmarkRegistry(container); - RegisterGeneratedHandler(container, Lifetime); - }); - // 容器内已提前保留默认 runtime 以支撑 generated registry 接线; - // 这里额外创建带生命周期后缀的 runtime,只是为了区分不同 benchmark 矩阵的 dispatcher 日志。 - if (Lifetime != HandlerLifetime.Scoped) - { - _generatedRuntime = GFramework.Cqrs.CqrsRuntimeFactory.CreateRuntime( - _generatedContainer, - _generatedRuntimeLogger); - } - - _serviceProvider = BenchmarkHostFactory.CreateMediatRServiceProvider( - configure: null, - typeof(StreamLifetimeBenchmarks), - static candidateType => candidateType == typeof(MediatRBenchmarkStreamHandler), - ResolveMediatRLifetime(Lifetime)); - if (Lifetime != HandlerLifetime.Scoped) - { - _mediatr = _serviceProvider.GetRequiredService(); - } + ConfigureBenchmarkInfrastructure(); + InitializeRequestsAndLoggers(); + InitializeReflectionRuntime(); + InitializeGeneratedRuntime(); + InitializeMediatRRuntime(); } /// @@ -205,8 +164,8 @@ public class StreamLifetimeBenchmarks { return ObserveAsync( BenchmarkHostFactory.CreateScopedGFrameworkStream( - _reflectionContainer, - _reflectionRuntimeLogger, + _scopedReflectionRuntime!, + _scopedReflectionContainer!, BenchmarkContext.Instance, _reflectionRequest, CancellationToken.None), @@ -231,8 +190,8 @@ public class StreamLifetimeBenchmarks { return ObserveAsync( BenchmarkHostFactory.CreateScopedGFrameworkStream( - _generatedContainer, - _generatedRuntimeLogger, + _scopedGeneratedRuntime!, + _scopedGeneratedContainer!, BenchmarkContext.Instance, _generatedRequest, CancellationToken.None), @@ -354,6 +313,102 @@ public class StreamLifetimeBenchmarks }; } + /// + /// 初始化当前 benchmark 所需的全局日志与夹具基础设施。 + /// + private void ConfigureBenchmarkInfrastructure() + { + LoggerFactoryResolver.Provider = new ConsoleLoggerFactoryProvider + { + MinLevel = LogLevel.Fatal + }; + Fixture.Setup($"StreamLifetime/{Lifetime}", handlerCount: 1, pipelineCount: 0); + BenchmarkDispatcherCacheHelper.ClearDispatcherCaches(); + } + + /// + /// 初始化当前 benchmark 会复用的请求对象、baseline handler 与日志器。 + /// + private void InitializeRequestsAndLoggers() + { + _baselineHandler = new ReflectionBenchmarkStreamHandler(); + _reflectionRequest = new ReflectionBenchmarkStreamRequest(Guid.NewGuid(), 3); + _generatedRequest = new GeneratedBenchmarkStreamRequest(Guid.NewGuid(), 3); + _mediatrRequest = new MediatRBenchmarkStreamRequest(Guid.NewGuid(), 3); + _reflectionRuntimeLogger = + LoggerFactoryResolver.Provider.CreateLogger(nameof(StreamLifetimeBenchmarks) + ".Reflection." + Lifetime); + _generatedRuntimeLogger = + LoggerFactoryResolver.Provider.CreateLogger(nameof(StreamLifetimeBenchmarks) + ".Generated." + Lifetime); + } + + /// + /// 初始化 reflection 路径的 GFramework runtime。 + /// + private void InitializeReflectionRuntime() + { + _reflectionContainer = BenchmarkHostFactory.CreateFrozenGFrameworkContainer(container => + { + RegisterReflectionHandler(container, Lifetime); + }); + + if (Lifetime != HandlerLifetime.Scoped) + { + _reflectionRuntime = GFramework.Cqrs.CqrsRuntimeFactory.CreateRuntime( + _reflectionContainer, + _reflectionRuntimeLogger); + return; + } + + _scopedReflectionContainer = new ScopedBenchmarkContainer(_reflectionContainer); + _scopedReflectionRuntime = GFramework.Cqrs.CqrsRuntimeFactory.CreateRuntime( + _scopedReflectionContainer, + _reflectionRuntimeLogger); + } + + /// + /// 初始化 generated registry 路径的 GFramework runtime。 + /// + private void InitializeGeneratedRuntime() + { + _generatedContainer = BenchmarkHostFactory.CreateFrozenGFrameworkContainer(container => + { + BenchmarkHostFactory.RegisterGeneratedBenchmarkRegistry(container); + RegisterGeneratedHandler(container, Lifetime); + }); + + // 容器内已提前保留默认 runtime 以支撑 generated registry 接线; + // 这里额外创建带生命周期后缀的 runtime,只是为了区分不同 benchmark 矩阵的 dispatcher 日志。 + if (Lifetime != HandlerLifetime.Scoped) + { + _generatedRuntime = GFramework.Cqrs.CqrsRuntimeFactory.CreateRuntime( + _generatedContainer, + _generatedRuntimeLogger); + return; + } + + _scopedGeneratedContainer = new ScopedBenchmarkContainer(_generatedContainer); + _scopedGeneratedRuntime = GFramework.Cqrs.CqrsRuntimeFactory.CreateRuntime( + _scopedGeneratedContainer, + _generatedRuntimeLogger); + } + + /// + /// 初始化 MediatR 对照宿主。 + /// + private void InitializeMediatRRuntime() + { + _serviceProvider = BenchmarkHostFactory.CreateMediatRServiceProvider( + configure: null, + typeof(StreamLifetimeBenchmarks), + static candidateType => candidateType == typeof(MediatRBenchmarkStreamHandler), + ResolveMediatRLifetime(Lifetime)); + + if (Lifetime != HandlerLifetime.Scoped) + { + _mediatr = _serviceProvider.GetRequiredService(); + } + } + /// /// 按观测模式消费 stream,便于把“建流/首个元素”和“完整枚举”分开观察。 /// diff --git a/GFramework.Cqrs.Benchmarks/Program.cs b/GFramework.Cqrs.Benchmarks/Program.cs index 7677b68d..a6f26a0a 100644 --- a/GFramework.Cqrs.Benchmarks/Program.cs +++ b/GFramework.Cqrs.Benchmarks/Program.cs @@ -33,7 +33,7 @@ internal static class Program ConsoleLogger.Default.WriteLine("Running GFramework.Cqrs benchmarks"); - if (invocation.ArtifactsSuffix is not null && + if (invocation.RequiresHostIsolation && !string.Equals( Environment.GetEnvironmentVariable(IsolatedHostEnvironmentVariable), "1", @@ -95,7 +95,11 @@ internal static class Program } var artifactsPath = ResolveArtifactsPath(commandLineSuffix); - return new BenchmarkInvocation(benchmarkDotNetArguments.ToArray(), commandLineSuffix, artifactsPath); + return new BenchmarkInvocation( + benchmarkDotNetArguments.ToArray(), + commandLineSuffix, + artifactsPath, + artifactsPath is not null); } /// @@ -219,10 +223,63 @@ internal static class Program /// 当前 suffix 对应的独立宿主目录。 private static void PrepareIsolatedHostDirectory(string sourceHostDirectory, string isolatedHostDirectory) { + ValidateIsolatedHostDirectory(sourceHostDirectory, isolatedHostDirectory); Directory.CreateDirectory(isolatedHostDirectory); CopyDirectoryRecursively(sourceHostDirectory, isolatedHostDirectory); } + /// + /// 拒绝把隔离宿主目录放到当前宿主输出目录内部,避免递归复制把 `host/host/...` 无限扩张。 + /// + /// 当前 benchmark 宿主输出目录。 + /// 目标隔离宿主目录。 + /// + /// 等于或位于 之内。 + /// + private static void ValidateIsolatedHostDirectory(string sourceHostDirectory, string isolatedHostDirectory) + { + var normalizedSourceDirectory = Path.TrimEndingDirectorySeparator(Path.GetFullPath(sourceHostDirectory)); + var normalizedIsolatedHostDirectory = Path.TrimEndingDirectorySeparator(Path.GetFullPath(isolatedHostDirectory)); + + if (string.Equals( + normalizedSourceDirectory, + normalizedIsolatedHostDirectory, + StringComparison.OrdinalIgnoreCase)) + { + throw new InvalidOperationException( + "The isolated benchmark host directory must differ from the current host output directory."); + } + + var relativePath = Path.GetRelativePath(normalizedSourceDirectory, normalizedIsolatedHostDirectory); + if (IsCurrentDirectoryOrChild(relativePath)) + { + throw new InvalidOperationException( + $"The isolated benchmark host directory '{normalizedIsolatedHostDirectory}' must not be nested inside the current host output directory '{normalizedSourceDirectory}'."); + } + } + + /// + /// 判断一个相对路径是否仍指向当前目录或其子目录。 + /// + /// 相对路径。 + /// 目标位于当前目录或其子目录时返回 + private static bool IsCurrentDirectoryOrChild(string relativePath) + { + if (string.IsNullOrEmpty(relativePath) || string.Equals(relativePath, ".", StringComparison.Ordinal)) + { + return true; + } + + if (Path.IsPathRooted(relativePath)) + { + return false; + } + + return !string.Equals(relativePath, "..", StringComparison.Ordinal) && + !relativePath.StartsWith(".." + Path.DirectorySeparatorChar, StringComparison.Ordinal) && + !relativePath.StartsWith(".." + Path.AltDirectorySeparatorChar, StringComparison.Ordinal); + } + /// /// 递归复制 benchmark 宿主输出目录,覆盖同名文件以支持同一 suffix 的重复运行。 /// @@ -251,8 +308,10 @@ internal static class Program /// 实际传递给 BenchmarkDotNet 的命令行参数。 /// 当前运行声明的隔离后缀;若未声明则为 。 /// 本次运行的 artifacts 目录;若未隔离则为 。 + /// 本次运行是否需要重启到隔离宿主目录。 private readonly record struct BenchmarkInvocation( string[] BenchmarkDotNetArguments, string? ArtifactsSuffix, - string? ArtifactsPath); + string? ArtifactsPath, + bool RequiresHostIsolation); } diff --git a/GFramework.Cqrs.Benchmarks/README.md b/GFramework.Cqrs.Benchmarks/README.md index 2d4a5b96..ee518bc9 100644 --- a/GFramework.Cqrs.Benchmarks/README.md +++ b/GFramework.Cqrs.Benchmarks/README.md @@ -68,7 +68,7 @@ dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.cspro - `BenchmarkDotNet.Artifacts/` 属于本地生成输出,默认加入仓库忽略,不作为常规提交内容 - 当两个带 `--filter` 的 benchmark 进程需要并发运行时,必须为它们分别传入不同的 `--artifacts-suffix `,避免多个 `BenchmarkDotNet` 进程写入同一份 auto-generated build / artifacts 目录;这个约束只服务于本地输出隔离,不代表 benchmark 场景之间存在额外业务依赖 - `RequestLifetimeBenchmarks` 现在复用与默认 generated-provider 路径一致的 benchmark 宿主接线;它比较的是生命周期切换后的 handler 解析与 dispatch 成本,不单独引入另一套 runtime 发现口径 -- `RequestLifetimeBenchmarks` 的 `Scoped` 场景会在每次 request 分发时显式创建并释放真实 DI 作用域,用来观察 scoped handler 绑定到 request 边界后的解析与 dispatch 成本 +- `RequestLifetimeBenchmarks` 的 `Scoped` 场景会复用单个 scoped runtime,但在每次 request 分发时仍显式创建并释放真实 DI 作用域,用来观察 scoped handler 绑定到 request 边界后的解析与 dispatch 成本,而不是把 runtime 构造常量成本混进生命周期对照 - `StreamLifetimeBenchmarks` 现在按 direct handler、`GFramework.Cqrs` reflection、`GFramework.Cqrs` generated、`MediatR` 四层口径组织,并额外区分 `FirstItem` 与 `DrainAll` 两种观测方式,用于把 stream 建流/首个元素成本与完整枚举成本拆开观察 - `StreamingBenchmarks` 与 `StreamInvokerBenchmarks` 都同时暴露 `FirstItem` 与 `DrainAll`;阅读结果时应把它们分别理解为“建流到首个元素”的固定成本观测与“完整枚举整个 stream”的总成本观测 - `StreamInvokerBenchmarks` 当前的 `DrainAll` short-job 输出只适合做 smoke 复核,确认矩阵和路径可以正常跑通;它不应直接写成 reflection、generated 或 `MediatR` 之间的稳定性能结论,若要做排序判断,应复跑默认作业或更完整的 benchmark 批次 diff --git a/ai-plan/public/cqrs-rewrite/archive/todos/cqrs-rewrite-migration-tracking-history-through-rp131.md b/ai-plan/public/cqrs-rewrite/archive/todos/cqrs-rewrite-migration-tracking-history-through-rp131.md new file mode 100644 index 00000000..b5f5960e --- /dev/null +++ b/ai-plan/public/cqrs-rewrite/archive/todos/cqrs-rewrite-migration-tracking-history-through-rp131.md @@ -0,0 +1,492 @@ +# CQRS 重写迁移跟踪 + +## 目标 + +围绕 `GFramework` 当前的双轨 CQRS 现状,继续完成以“去外部依赖、降低反射、收口公开入口”为目标的 +CQRS 迁移与收敛。 + +## 当前恢复点 + +- 恢复点编号:`CQRS-REWRITE-RP-131` +- 当前阶段:`Phase 8` +- 当前 PR 锚点:`待重新抓取` +- 当前结论: +- 当前 `RP-131` 继续沿用 `$gframework-batch-boot 50`,并把上一波定位到的 BenchmarkDotNet 并行运行冲突真正收口到 benchmark 入口层:`Program.cs` 现在支持 `--artifacts-suffix `,并在声明 suffix 时自动把当前 benchmark 运行重启到独立的 host 工作目录 +- 本轮继续沿用已复核的基线:`origin/main` 与本地 `main` 当前都在 `699d0b48`(`2026-05-09 18:39:38 +0800`);当前分支相对 `origin/main` 的累计 branch diff 仍约为 `9 files changed, 953 insertions(+), 83 deletions(-)`,离 `$gframework-batch-boot 50` 还有明显余量 +- 本轮写面收敛在 benchmark 入口与文档两处:`GFramework.Cqrs.Benchmarks/Program.cs` 与 `GFramework.Cqrs.Benchmarks/README.md`;没有扩散到 benchmark 业务逻辑文件、`GFramework.Cqrs` runtime 或测试项目 +- `Program.cs` 当前约定为: + - 解析并剥离仓库自定义参数 `--artifacts-suffix `,避免把它误传给 BenchmarkDotNet CLI + - 支持通过环境变量回退复用同一套 suffix / artifacts path 约定 + - 当 suffix 存在时,先把当前 benchmark 宿主输出复制到 `BenchmarkDotNet.Artifacts//host/`,再从该隔离宿主目录重启运行,使 BenchmarkDotNet 自动生成的 `GFramework.Cqrs.Benchmarks-Job-*` 项目、`OutDir` 与最终 results 都落到 suffix 私有目录下 +- 并发 smoke 已直接证明这套隔离生效:`RequestLifetimeBenchmarks.SendRequest_*` 与 `StreamInvokerBenchmarks.Stream_*` 在两个终端并发 short-job 时,分别落到 `BenchmarkDotNet.Artifacts/req-lifetime-a/host/...` 与 `BenchmarkDotNet.Artifacts/stream-invoker-b/host/...`,不再共享同一 `.../bin/Release/net10.0/GFramework.Cqrs.Benchmarks-Job-JWUHXL-1/` 生成目录,也没有再出现 `.dll.config being used by another process` +- `README` 已同步新的运行约定:当两个带 `--filter` 的 benchmark 需要并发执行时,必须为每个进程传入不同的 `--artifacts-suffix`;该约束只服务于本地输出隔离,不代表 benchmark 业务语义本身需要额外依赖 +- 下一推荐步骤: +- 若继续 benchmark 线,可重新利用新的并发运行隔离约定,单开一波更稳定的 `StreamInvokerBenchmarks` `DrainAll` 排序复核,或并行推进其他不冲突的 benchmark smoke +- 若上下文预算仍允许,下一批更适合继续保持在 `GFramework.Cqrs.Benchmarks` 单模块,避免过早把 review 面重新扩到 runtime 或测试层 +- 更早的 `RP-123` 及之前阶段细节以下方 trace 与归档为准,active 入口不再重复展开旧阶段流水。 + - 当前分支相对 `origin/main` 的累计 branch diff 启动时为 `9 files`,仍明显低于 `$gframework-batch-boot 50` 的停止阈值;这一批继续保持单模块、低风险、可直接评审的 benchmark 边界 + - 当前 `RP-113` 已继续沿用 `$gframework-batch-boot 50`,并把 notification 线从 benchmark 对照推进到实际 runtime 能力:新增公开内置 `TaskWhenAllNotificationPublisher`,让 `GFramework.Cqrs` 在保留默认顺序发布器的同时,提供与 `Mediator` `TaskWhenAllPublisher` 对齐的并行 notification publish 策略 + - `TaskWhenAllNotificationPublisher` 当前语义明确为:零处理器静默完成,单处理器直接透传,多处理器并行启动并等待全部结束;它不保留默认顺序发布器的“首个异常立即停止”语义,而是把全部处理器的失败/取消结果收敛到同一个返回任务 + - 本轮同时补齐 `CqrsNotificationPublisherTests` 对新内置策略的回归,并更新 `GFramework.Cqrs/README.md` 与 `docs/zh-CN/core/cqrs.md`,把切换方式和语义边界写回用户可见文档;当前已提交 branch diff 仍明显低于 `$gframework-batch-boot 50` 的停止阈值 + - 这一批选择真正落一个内置 publisher strategy,而不是继续加 notification benchmark 维度;原因是 `RP-111` / `RP-112` 已经把 notification gap 量化清楚,下一步更高价值的是开始收口“能力差距”而不是继续重复建立对照数据 + - 当前 `RP-112` 已继续沿用 `$gframework-batch-boot 50`,并在 `RP-111` 的单处理器 notification 对照基础上补齐固定 `4 handler` 的 fan-out publish benchmark:新增 `NotificationFanOutBenchmarks`,对比 baseline、`GFramework.Cqrs`、NuGet `Mediator` concrete runtime 与 `MediatR` + - `NotificationFanOutBenchmarks` 当前 short-job 基线约为 baseline `8.302 ns / 0 B`、`Mediator` `4.314 ns / 0 B`、`MediatR` `230.304 ns / 1256 B`、`GFramework.Cqrs` `434.413 ns / 408 B`;这说明 notification fan-out 的差距已经不只体现在单处理器 publish,而是在固定 4 处理器场景下依然保持相近量级 + - 本轮仍然只扩 benchmark 对照口径,没有直接修改 notification runtime 或 publisher 策略语义;原因是当前更高价值的事实是先量化“单处理器”和“固定 fan-out”两条 notification 路径的外部差距,再决定下一批是否值得切进 publisher strategy 或 runtime 热点 + - 当前 `RP-111` 已继续沿用 `$gframework-batch-boot 50`,并按 skill 规则重新以 `origin/main` 作为基线复核:`origin/main` = `7ca21af9`(`2026-05-08 16:12:20 +0800`),本地 `main` = `c2d22285` 已落后,当前分支 `feat/cqrs-optimization` 与 `origin/main` 的累计 branch diff 为 `0 files / 0 lines`;基于“上下文预算优先、单批可评审边界次之”的停止规则,本轮选择 `NotificationBenchmarks` 这一条仍缺 `Mediator` concrete runtime 对照的单模块 benchmark 切片,而不是为了对称性继续扩展 notification runtime seam + - `NotificationBenchmarks` 现已从双方对照扩成三方对照:新增 NuGet `Mediator` source-generated concrete runtime 宿主与 `PublishNotification_Mediator()`,`BenchmarkNotification` / `BenchmarkNotificationHandler` 也同步接上 `Mediator` 的 notification 合同;当前 short-job 基线约为 `Mediator` `1.108 ns / 0 B`、`MediatR` `97.173 ns / 416 B`、`GFramework.Cqrs` `291.582 ns / 392 B` + - 本轮只把“notification publish 的高性能外部对照”补齐到 benchmark 层,而没有直接新增 generated notification invoker/provider 或 runtime 语义调整;原因是 notification dispatch 现有反射委托本就只在首次命中时缓存,继续加一层 provider 对 steady-state publish 的收益信号不如先把 `Mediator` concrete runtime 对照补齐来得清晰 + - 当前 `RP-110` 已再次使用 `$gframework-pr-review` 复核 `PR #341` latest-head review:`BenchmarkHostFactory` 的 legacy runtime alias 防守式类型检查、benchmark 宿主定向 generated registry 激活、以及 `CqrsDispatcher.SendAsync(...)` 的 faulted `ValueTask` 失败语义在当前 head 均已实质收口;本轮仅继续接受仍然成立的 CodeRabbit nitpick,为 `SendAsync_Should_Return_Faulted_ValueTask_When_Handler_Is_Missing()` 补齐 `HasRegistration(...)` / `GetAll(...)` 防御性 mock,并删除 trace 中重复 `本轮权威验证` 的 `本轮下一步` 段落 + - 当前 `RP-109` 已使用 `$gframework-pr-review` 复核 `PR #341` latest-head review:benchmark 宿主改为定向激活当前场景的 generated registry,避免同一 benchmark 程序集里的其他 registry 扩大冻结服务索引与 `HasRegistration` 基线;`BenchmarkHostFactory` 为 legacy runtime alias 注册补齐防守式类型检查与 stream lifetime 运行时注释;`CqrsDispatcher.SendAsync(...)` 在保留 direct-return 热路径的同时恢复 faulted `ValueTask` 失败语义,并补齐 generated registry 定向接线与 request fault 语义回归测试;`.agents/skills/gframework-batch-boot/SKILL.md` 的 MD005 缩进也已顺手修正 + - `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()`、dispatcher 侧 stream pipeline executor 缓存与 generated stream invoker 兼容回归,以及 `Architecture` 公开注册入口与对应文档说明 + - 当前 `RP-100` 已使用 `$gframework-pr-review` 复核 `PR #339` latest-head review:收口 `RegisterCqrsStreamPipelineBehavior()` 的异常契约文档、为 `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` + - 当前 `RP-107` 已把默认 stream steady-state 宿主也切到 generated-provider 路径:新增 handwritten `GeneratedDefaultStreamingBenchmarkRegistry`,让 `StreamingBenchmarks` 改走 `RegisterCqrsHandlersFromAssembly(...)` 并在 setup/cleanup 清理 dispatcher cache;同时将 `gframework-boot` / `gframework-batch-boot` 的默认停止规则改为“AI 上下文预算优先,建议在预计接近约 80% 安全上下文占用前收口”,不再把 changed files 误当作唯一阈值 + - 当前 `RP-108` 已补齐 stream handler `Singleton / Transient` 生命周期矩阵 benchmark:新增 `StreamLifetimeBenchmarks` 与 `GeneratedStreamLifetimeBenchmarkRegistry`,让 stream 生命周期对照沿用 generated-provider 宿主接线而不是退回纯反射路径;本轮 benchmark 表明 `Singleton` 下 baseline / `GFramework.Cqrs` / `MediatR` 约 `80.144 ns / 137.515 ns / 229.242 ns`,`Transient` 下约 `77.198 ns / 144.998 ns / 228.185 ns` +- `ai-plan` active 入口现以 `RP-122` 为最新恢复锚点;`PR #340`、`PR #339`、`PR #334`、`PR #331`、`PR #326`、`PR #323`、`PR #307` 与其他更早阶段细节均以下方归档或说明为准 + +## 当前活跃事实 + +- 当前分支为 `feat/cqrs-optimization` +- 本轮 `$gframework-batch-boot 50` 以 `origin/main` (`d85828c5`, `2026-05-09 12:25:41 +0800`) 为基线;本地 `main` (`c2d22285`, `2026-05-06 21:34:59 +0800`) 已落后,不作为 branch diff 基线 +- 当前已提交分支相对 `origin/main` 的累计 branch diff 为 `21 files`(`1344 insertions / 194 deletions`),仍明显低于 `$gframework-batch-boot 50` 的 `50 files` 停止阈值 +- 当前用于收口 `PR #345` review 的写面额外覆盖 `AGENTS.md`、`GFramework.Cqrs.Benchmarks/README.md` 与 `ai-plan/public/cqrs-rewrite/**`;本轮代码层面的唯一触点保持在 `StreamLifetimeBenchmarks.cs` +- 当前 `PR #345` latest-head review body 已本地复核完毕;仍成立并已吸收的反馈集中在 `AGENTS.md` 术语说明、`StreamLifetimeBenchmarks` 的取消/注释细节,以及 benchmark README / `ai-plan` 恢复入口漂移 +- 当前批次后的默认停止依据已改为 AI 上下文预算:若下一轮预计会让活动对话、已加载 recovery 文档、验证输出与当前 diff 接近约 `80%` 安全上下文占用,应在当前自然批次边界停止,即使 branch diff 仍有余量 +- `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.608 ns / 32 B`、`5.445 ns / 32 B`、`57.071 ns / 232 B`、`64.825 ns / 32 B` +- 当前 request lifetime benchmark 已对齐 generated-provider 宿主路径:`Singleton` 下 baseline / `GFramework.Cqrs` / `MediatR` 约为 `5.012 ns / 32 B`、`49.612 ns / 32 B`、`51.796 ns / 232 B`;`Transient` 下约为 `3.962 ns / 32 B`、`50.480 ns / 56 B`、`50.284 ns / 232 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` +- 当前 stream steady-state benchmark 也已切到 generated-provider 宿主接线路径:baseline 约 `5.535 ns / 32 B`、`MediatR` 约 `59.499 ns / 232 B`、`GFramework.Cqrs` 约 `66.778 ns / 32 B` +- 当前 stream lifetime benchmark 已更新为 `Observation=FirstItem / DrainAll` 双口径:`Singleton + FirstItem` 下 baseline / generated / reflection / `MediatR` 约为 `48.704 ns / 216 B`、`94.629 ns / 216 B`、`95.417 ns / 216 B`、`152.886 ns / 608 B`;`Singleton + DrainAll` 下约为 `73.335 ns / 280 B`、`118.860 ns / 280 B`、`119.632 ns / 280 B`、`205.629 ns / 672 B` +- `Transient + FirstItem` 下 baseline / reflection / generated / `MediatR` 约为 `48.293 ns / 216 B`、`97.628 ns / 240 B`、`100.011 ns / 240 B`、`154.149 ns / 608 B`;`Transient + DrainAll` 下约为 `78.466 ns / 280 B`、`124.174 ns / 304 B`、`116.780 ns / 304 B`、`220.040 ns / 672 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` +- `GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherContextValidationTests.cs` 现连“handler 缺失但仍返回 faulted `ValueTask`”这条 request 失败语义回归也显式为 `HasRegistration(Type)` / `GetAll(Type)` 预留了防御性 mock,不再依赖 dispatcher 先判空 handler、后探测 pipeline 的内部顺序 +- `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` 与 `StreamingBenchmarks` 现在都已通过 handwritten generated registry + 真实 `RegisterCqrsHandlersFromAssembly(...)` 宿主接线命中 generated invoker provider,不再只代表纯反射 binding 路径 +- `gframework-boot` 与 `gframework-batch-boot` 现明确把“上下文预算接近约 80%”视为默认优先停止信号,branch diff files / lines 仅保留为次级仓库范围指标 +- 当前性能回归门槛已收紧为:只要改动触达 `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()` 并在 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 ` 当前只产出 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` 的流式行为注册入口此前确实缺少 `` / `` 契约说明,现已补齐并同步到 `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 结论 + +## 当前风险 + +- 当前 `_requestBehaviorPresenceCache` 依赖“同一 dispatcher 生命周期内,request pipeline 行为注册在容器冻结后保持稳定”这一约束;若未来引入运行时动态增删 request behavior 的模型,需要重新评估这类实例级 presence cache 的失效策略 +- 当前 `_streamBehaviorPresenceCache` 也依赖“同一 dispatcher 生命周期内,stream pipeline 行为注册在容器冻结后保持稳定”这一约束;若后续引入运行期动态增删 stream behavior 或按 scope 改写可见性的模型,需要同步设计失效策略,而不能继续假设实例级缓存永久有效 +- 标准架构启动路径现在已经有“自定义 notification publisher 不被默认顺序策略短路”的集成回归;但若后续再引入第三种仓库内置策略或新的启动快捷入口,仍需要同步补这条生产路径验证,不能只看 `CqrsTestRuntime` 测试宿主 +- 顶层 `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` concrete runtime 对照已覆盖 steady-state request、单处理器 notification publish 与固定 `4 handler` notification fan-out;若要把 `Transient` / `Scoped` 生命周期矩阵、stream 生命周期矩阵或更大 fan-out 矩阵也纳入同一组对照,需要按 `Mediator` 官方 benchmark 的做法拆分 compile-time lifetime / 场景配置,而不是在同一编译产物里混用多个 runtime 变量 +- 当前 stream 生命周期矩阵尚未接入 `Mediator` concrete runtime;若要继续对齐 `Mediator` 官方 benchmark 的 compile-time lifetime 设计,需要为 stream 场景补专门的 build-time 配置,而不是在当前统一宿主里临时拼接 +- `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 框架短路成环境性失败 +- `PR #345` 当前 latest-head review 仍以 CodeRabbit review body 的 `4` 条 actionable comments 为主;最新本地复核后,仍成立的问题集中在 `AGENTS.md` 术语说明、`StreamLifetimeBenchmarks` 的取消/文档细节,以及 benchmark README / `ai-plan` 恢复入口漂移 + +## 最近权威验证 + +- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - 备注:覆盖 benchmark 入口 `--artifacts-suffix` 隔离实现、`README` 命令示例与 `ai-plan` 更新后的最小 Release build +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --artifacts-suffix req-lifetime-a --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:本次 auto-generated benchmark 项目已在 `BenchmarkDotNet.Artifacts/req-lifetime-a/host/...` 下执行;`Singleton` 约为 baseline `5.189 ns`、`MediatR` `52.765 ns`、`GFramework.Cqrs` `60.938 ns` +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --artifacts-suffix stream-invoker-b --filter "*StreamInvokerBenchmarks.Stream_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:本次 auto-generated benchmark 项目已在 `BenchmarkDotNet.Artifacts/stream-invoker-b/host/...` 下执行;`DrainAll` 约为 baseline `77.82 ns`、generated `130.37 ns`、reflection `139.08 ns`、`MediatR` `245.23 ns` +- `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Program.cs GFramework.Cqrs.Benchmarks/README.md ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` + - 结果:通过 +- `git --git-dir=/.git/worktrees/GFramework-cqrs --work-tree=. diff --check` + - 结果:通过 + +- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - 备注:覆盖 `BenchmarkHostFactory` scoped stream helper、`StreamLifetimeBenchmarks` scoped 生命周期矩阵与 `README` 同步后的最小 Release build +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*StreamLifetimeBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:`StreamLifetimeBenchmarks` 已稳定跑出 `24` 个 case;`Scoped + DrainAll` 当前约为 baseline `81.20 ns / 280 B`、`MediatR` `428.66 ns / 1224 B`、generated `692.05 ns / 3888 B`、reflection `716.61 ns / 3888 B` +- `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/BenchmarkHostFactory.cs GFramework.Cqrs.Benchmarks/Messaging/StreamLifetimeBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` + - 结果:通过 +- `git --git-dir=/.git/worktrees/GFramework-cqrs --work-tree=. diff --check` + - 结果:通过 + +- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - 备注:覆盖 `StreamLifetimeBenchmarks` 的代码收口与 benchmark `README` 同步后的最小 Release build +- `python3 scripts/license-header.py --check --paths AGENTS.md GFramework.Cqrs.Benchmarks/Messaging/StreamLifetimeBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` + - 结果:通过 +- `git --git-dir=/.git/worktrees/GFramework-cqrs --work-tree=. diff --shortstat d85828c5...HEAD` + - 结果:通过 + - 备注:当前分支相对 `origin/main` 的累计 diff 为 `21 files changed, 1344 insertions(+), 194 deletions(-)` + +- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:宿主已对齐 generated-provider 路径;`Singleton` 下 baseline / `GFramework.Cqrs` / `MediatR` 约为 `5.012 ns / 32 B`、`49.612 ns / 32 B`、`51.796 ns / 232 B`;`Transient` 下约为 `3.962 ns / 32 B`、`50.480 ns / 56 B`、`50.284 ns / 232 B` +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*StreamLifetimeBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:已产出 `baseline / GFramework reflection / GFramework generated / MediatR` 四方矩阵;`Singleton` 下约为 `79.602 / 120.553 / 111.547 / 208.381 ns`,`Transient` 下约为 `76.351 / 119.632 / 129.166 / 213.420 ns` +- `python3 scripts/license-header.py --check --paths ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` + - 结果:通过 + +- `python3 scripts/license-header.py --check --paths GFramework.Cqrs/Internal/CqrsDispatcher.cs GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherContextValidationTests.cs GFramework.Cqrs.Tests/Cqrs/CqrsNotificationPublisherTests.cs GFramework.Cqrs.Tests/Cqrs/NotificationPublisherRegistrationExtensionsTests.cs GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherCacheTests.cs ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` + - 结果:通过 +- `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - 备注:首轮与 `GFramework.Cqrs.Tests` 并行构建时曾出现 `MSB3026` 单次复制重试;串行重跑同一命令后稳定通过 +- `dotnet build GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~CqrsDispatcherContextValidationTests|FullyQualifiedName~CqrsNotificationPublisherTests|FullyQualifiedName~NotificationPublisherRegistrationExtensionsTests|FullyQualifiedName~CqrsDispatcherCacheTests"` + - 结果:通过,`30/30` passed +- `git diff --check` + - 结果:通过 + +- `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsDispatcherCacheTests"` + - 结果:通过,`11/11` passed +- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:默认 request steady-state 当前约为 baseline `5.876 ns / 32 B`、`Mediator` `5.275 ns / 32 B`、`GFramework.Cqrs` `51.717 ns / 32 B`、`MediatR` `56.108 ns / 232 B` +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:`Singleton` 下 baseline / `GFramework.Cqrs` / `MediatR` 约 `5.720 ns / 52.490 ns / 56.890 ns`,`Transient` 下约 `5.814 ns / 57.746 ns / 55.545 ns` +- `python3 scripts/license-header.py --check --paths GFramework.Cqrs/Internal/CqrsDispatcher.cs GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherCacheTests.cs` + - 结果:通过 +- `dotnet build GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~ArchitectureModulesBehaviorTests"` + - 结果:通过,`5/5` passed +- `python3 scripts/license-header.py --check --paths GFramework.Core.Tests/Architectures/ArchitectureModulesBehaviorTests.cs` + - 结果:通过 +- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*NotificationFanOutBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:本轮对称化 MediatR handler 后,fixed `4 handler` fan-out 对照约为 `Mediator` `3.598 ns / 0 B`、baseline `7.033 ns / 0 B`、`MediatR` `257.533 ns / 1256 B`、`GFramework.Cqrs` 顺序 `409.557 ns / 408 B`、`TaskWhenAll` `484.531 ns / 496 B` +- `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/NotificationFanOutBenchmarks.cs GFramework.Cqrs/README.md docs/zh-CN/core/cqrs.md ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` + - 结果:通过 +- `git diff --check` + - 结果:通过 + - 备注:仅剩 `GFramework.sln` 的历史 CRLF 提示,无本轮新增 diff 格式问题 +- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*NotificationFanOutBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:历史基线(`RP-112`)固定 `4 handler` notification fan-out 对照约为 baseline `8.302 ns / 0 B`、`Mediator` `4.314 ns / 0 B`、`MediatR` `230.304 ns / 1256 B`、`GFramework.Cqrs` `434.413 ns / 408 B` +- `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/NotificationFanOutBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md` + - 结果:通过 +- `git diff --check` + - 结果:通过 + - 备注:仅剩 `GFramework.sln` 的历史 CRLF 提示,无本轮新增 diff 格式问题 +- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*NotificationBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:notification publish 三方对照当前约为 `Mediator` `1.108 ns / 0 B`、`MediatR` `97.173 ns / 416 B`、`GFramework.Cqrs` `291.582 ns / 392 B` +- `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/NotificationBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md` + - 结果:通过 +- `git diff --check` + - 结果:通过 + - 备注:仅剩 `GFramework.sln` 的历史 CRLF 提示,无本轮新增 diff 格式问题 +- `dotnet build GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - 备注:并行验证首轮曾因 `build` 与 `test` 同时写入同一输出 DLL 触发 `MSB3026` 单次复制重试;改为串行重跑同一命令后稳定通过 +- `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsDispatcherContextValidationTests"` + - 结果:通过,`6/6` passed +- `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherContextValidationTests.cs` + - 结果:通过 +- `git diff --check` + - 结果:通过 + - 备注:仅剩 `GFramework.sln` 的历史 CRLF 提示,无本轮新增 diff 格式问题 +- `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --format json --json-output /tmp/current-pr-review.json` + - 结果:通过 + - 备注:确认当前分支对应 `PR #342`;latest-head 当前显示 `CodeRabbit 4` / `Greptile 3` open thread,其中真正仍成立的是 benchmark handler 对称性、README / 中文文档示例与恢复文档锚点漂移,其余历史 thread 需要按当前 head 继续甄别 +- `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --json-output /tmp/current-pr-review.json` + - 结果:通过 + - 备注:确认当前分支对应 `PR #340`;latest-head 当前显示 `CodeRabbit 2` / `Greptile 2` open thread,且 `CTRF` 报告中唯一失败测试为 `CreateStream_Should_Throw_When_Stream_Pipeline_Behavior_Context_Does_Not_Implement_IArchitectureContext` +- `dotnet build GFramework.Core.Abstractions/GFramework.Core.Abstractions.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet build GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~MicrosoftDiContainerTests"` + - 结果:通过,`52/52` passed +- `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~CqrsDispatcherContextValidationTests"` + - 结果:通过,`4/4` passed +- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:按新性能回归门槛复跑后,steady-state request 对照约为 baseline `5.300 ns / 32 B`、`Mediator` `4.964 ns / 32 B`、`MediatR` `57.993 ns / 232 B`、`GFramework.Cqrs` `83.823 ns / 32 B` +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:按新性能回归门槛复跑后,`Singleton` 下 `GFramework.Cqrs` / `MediatR` 约 `83.183 ns / 32 B` vs `60.915 ns / 232 B`;`Transient` 下约 `86.243 ns / 56 B` vs `59.644 ns / 232 B` +- `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` + - 结果:通过 +- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/GeneratedStreamLifetimeBenchmarkRegistry.cs GFramework.Cqrs.Benchmarks/Messaging/StreamLifetimeBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md` + - 结果:通过 +- `git diff --check` + - 结果:通过 +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:steady-state request 对照约为 baseline `5.336 ns / 32 B`、`Mediator` `5.564 ns / 32 B`、`MediatR` `53.307 ns / 232 B`、`GFramework.Cqrs` `64.745 ns / 32 B` +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:`Singleton` 下 baseline / `MediatR` / `GFramework.Cqrs` 约 `4.309 ns / 51.923 ns / 67.981 ns`;`Transient` 下约 `5.029 ns / 54.435 ns / 76.437 ns` +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*StreamLifetimeBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:`Singleton` 下 baseline / `GFramework.Cqrs` / `MediatR` 约 `80.144 ns / 137.515 ns / 229.242 ns`,`Transient` 下约 `77.198 ns / 144.998 ns / 228.185 ns` +- `git diff --check` + - 结果:通过 + - 备注:当前仅保留 `GFramework.sln` 的历史 CRLF 警告,无本轮新增 diff 格式错误 +- `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~MicrosoftDiContainerTests"` + - 结果:通过,`52/52` passed +- `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~CqrsDispatcherCacheTests|FullyQualifiedName~CqrsDispatcherContextValidationTests"` + - 结果:通过,`14/14` passed +- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:本轮两批热路径收口后的最新 steady-state request 对照约为 baseline `6.141 ns / 32 B`、`Mediator` `6.674 ns / 32 B`、`MediatR` `61.803 ns / 232 B`、`GFramework.Cqrs` `70.298 ns / 32 B` +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:最新 lifetime request 对照约为 `Singleton` 下 baseline / `MediatR` / `GFramework.Cqrs` = `4.706 ns / 52.197 ns / 73.005 ns`,`Transient` 下 = `4.571 ns / 50.175 ns / 74.757 ns` +- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/GeneratedDefaultRequestBenchmarkRegistry.cs GFramework.Cqrs.Benchmarks/Messaging/BenchmarkHostFactory.cs GFramework.Cqrs.Benchmarks/Messaging/RequestBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md` + - 结果:通过 +- `git diff --check` + - 结果:通过 +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:默认 steady-state request 对照现约为 baseline `5.013 ns / 32 B`、`Mediator` `5.747 ns / 32 B`、`MediatR` `51.588 ns / 232 B`、`GFramework.Cqrs` `65.296 ns / 32 B` +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:最新 lifetime request 对照约为 `Singleton` 下 baseline / `MediatR` / `GFramework.Cqrs` = `4.817 ns / 48.177 ns / 68.772 ns`,`Transient` 下 = `4.841 ns / 51.753 ns / 73.157 ns` +- `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` + - 结果:通过 +- `git diff --check` + - 结果:通过 + - 备注:仍仅保留 `GFramework.sln` 的历史 CRLF 警告,无本轮新增 diff 格式问题 +- `dotnet pack GFramework.sln -c Release --no-restore -o /tmp/gframework-pack-validation -p:IncludeSymbols=false` + - 结果:通过 + - 备注:当前本地产物仅包含 14 个预期发布包,未生成 `GFramework.Cqrs.Benchmarks.*.nupkg` +- `bash scripts/validate-packed-modules.sh /tmp/gframework-pack-validation` + - 结果:通过 + - 备注:共享脚本确认 actual package set 与预期 14 个发布包完全一致 +- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~MicrosoftDiContainerTests"` + - 结果:通过,`51/51` passed +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:最新 steady-state request 对照约为 baseline `5.969 ns / 32 B`、`Mediator` `6.242 ns / 32 B`、`MediatR` `53.818 ns / 232 B`、`GFramework.Cqrs` `85.504 ns / 32 B` +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:`Singleton` 下 `GFramework.Cqrs` / `MediatR` 约 `84.066 ns / 32 B` vs `56.096 ns / 232 B`;`Transient` 下约 `90.652 ns / 56 B` vs `57.207 ns / 232 B` +- `python3 scripts/license-header.py --check` + - 结果:通过 +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestStartupBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:`ColdStart_GFrameworkCqrs` 已恢复出数,最新本地输出约 `220-292 us`,MediatR 对照约 `575-616 us`;当前仅剩 BenchmarkDotNet 对单次 cold-start 场景的 `MinIterationTime` 提示 +- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - 备注:用于验证本轮 request invoker / pipeline / stream invoker 调整与 benchmark workflow 改动后的 Release 编译结果 +- `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --format json --json-output /tmp/current-pr-review.json` + - 结果:通过 + - 备注:确认当前分支对应 `PR #334`;`CodeRabbit` latest review 已 `APPROVED`,但 latest-head 仍显示 `10` 个 open thread、`Greptile` 仍显示 `3` 个 open thread;本地逐项复核后未发现新的仍成立缺陷,最新 CI 测试汇总为 `2311/2311` passed,`MegaLinter` 仅剩 `dotnet-format` restore 环境噪音 +- `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --json-output /tmp/current-pr-review.json` + - 结果:通过 + - 备注:确认当前分支对应 `PR #339`;latest-head 显示 `2` 个 CodeRabbit open thread 与 `2` 个 nitpick;本轮本地接受并修复的问题集中在流式行为注册入口 XML 契约、stream continuation 线程说明与 `MicrosoftDiContainer` 的重复注册逻辑,测试方法拼写线程已在当前 head 失效 +- `dotnet format GFramework.Cqrs/GFramework.Cqrs.csproj --verify-no-changes` + - 结果:发现当前 diff 内 `GFramework.Cqrs/ICqrsRequestInvokerProvider.cs` 的空白格式问题;其余 `CHARSET` 提示集中在未触达的历史文件 +- `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet build GFramework.Core.Abstractions/GFramework.Core.Abstractions.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~CqrsDispatcherCacheTests"` + - 结果:通过,`10/10` passed +- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~ArchitectureModulesBehaviorTests"` + - 结果:通过,`4/4` passed +- `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` + - 结果:通过 +- `git diff --check` + - 结果:通过 +- `dotnet build GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~CommandExecutorTests|FullyQualifiedName~AsyncQueryExecutorTests"` + - 结果:通过,`19/19` passed +- `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --json-output /tmp/current-pr-review.json` + - 结果:通过 + - 备注:确认当前分支对应 `PR #334`;最新 review 仍为 `CodeRabbit APPROVED (2026-05-07T12:20:24Z)`,latest-head 显示 `CodeRabbit 10` / `Greptile 5` open thread;本轮接受并修复的仍成立问题收敛到 `LegacyCqrsDispatchHelper.TryResolveDispatchContext(...)` 的过宽异常吞掉逻辑 +- `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet build GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~CommandExecutorTests|FullyQualifiedName~QueryExecutorTests"` + - 结果:通过,`25/25` passed +- `python3 scripts/license-header.py --check` + - 结果:通过 +- `git diff --check` + - 结果:通过 +- `python3 scripts/license-header.py --check` + - 结果:通过 +- `git diff --check` + - 结果:通过 +- `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --format json --json-output ` + - 结果:通过 + - 备注:确认当前分支对应 `PR #331`,本轮 latest-head open AI feedback 已收敛到 `dotnet pack --no-build`、共享包校验脚本跨平台兼容性与 active 文档 PR 锚点同步 +- `python3 scripts/license-header.py --check` + - 结果:通过 + - 备注:当前 WSL worktree 需要显式绑定 `GIT_DIR` / `GIT_WORK_TREE` 后运行 +- `git diff --check` + - 结果:通过 +- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestLifetimeBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过(以沙箱外 `--no-build` 权威结果为准) + - 备注:`Singleton` 下 baseline / MediatR / GFramework 均值约 `5.633 ns / 58.687 ns / 301.731 ns`;`Transient` 下约 `5.044 ns / 52.274 ns / 287.863 ns` +- `python3 scripts/license-header.py --check` + - 结果:通过 + - 备注:当前 WSL worktree 需要显式绑定 `GIT_DIR` / `GIT_WORK_TREE` +- `git diff --check` + - 结果:通过 +- `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~ArchitectureContextTests|FullyQualifiedName~CommandExecutorTests|FullyQualifiedName~QueryExecutorTests|FullyQualifiedName~AsyncQueryExecutorTests"` + - 结果:通过,`45/45` passed +- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release` + - 结果:通过,`1644/1644` passed +- `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` + - 结果:通过 +- `git diff --check` + - 结果:通过 +- `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --json-output /tmp/current-pr-review.json` + - 结果:通过 + - 备注:确认当前分支对应 `PR #334`;仍有效的 latest-head review 已收敛到 legacy bridge 测试装配、运行时依赖契约、异步取消、XML 文档与兼容文档边界 +- `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - 备注:修复新增 XML 文档 warning 后复跑,当前 `GFramework.Core` 三个 target framework 均已干净通过 +- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~ArchitectureContextTests|FullyQualifiedName~ArchitectureModulesBehaviorTests|FullyQualifiedName~CommandExecutorTests|FullyQualifiedName~QueryExecutorTests|FullyQualifiedName~AsyncQueryExecutorTests"` + - 结果:通过,`48/48` passed + - 备注:覆盖 legacy bridge 兼容入口、测试装配、执行器 runtime fallback 与相关模块行为 +- `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` + - 结果:通过 +- `git diff --check` + - 结果:通过 +- `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~ArchitectureContextTests|FullyQualifiedName~ArchitectureModulesBehaviorTests|FullyQualifiedName~CommandExecutorTests|FullyQualifiedName~QueryExecutorTests|FullyQualifiedName~AsyncQueryExecutorTests|FullyQualifiedName~LegacyAsyncCommandDispatchRequestHandlerTests"` + - 结果:通过,`54/54` passed + - 备注:覆盖 legacy 同步 bridge 的同步上下文隔离、bridge fixture 容器释放,以及 async void command cancellation 可见性 +- `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` + - 结果:通过 + +## 下一推荐步骤 + +1. 若下一轮继续压 request steady-state,优先挑选仍能减少常量热路径查询/分支的切片;继续避开“类型级 `IContextAware` 判定缓存”这条已验证无收益的热点假设 +2. 若下一轮转向 benchmark 对齐,优先评估 `request scoped host + compile-time lifetime` 对照,而不是继续并行跑多个 BenchmarkDotNet 任务去争用同一自动生成目录 +3. 若下一轮回到 notification 线,应把问题重新收敛到“是否值得公开第三种仓库内置 publisher strategy”或“是否需要 `IServiceCollection` 版本的公开入口”,而不是继续重复扩同层级回归 + +## 活跃文档 + +- 历史跟踪归档:[cqrs-rewrite-history-through-rp043.md](../archive/todos/cqrs-rewrite-history-through-rp043.md) +- 验证历史归档:[cqrs-rewrite-validation-history-through-rp062.md](../archive/todos/cqrs-rewrite-validation-history-through-rp062.md) +- `RP-063` 至 `RP-074` 验证归档:[cqrs-rewrite-validation-history-rp063-through-rp074.md](../archive/todos/cqrs-rewrite-validation-history-rp063-through-rp074.md) +- `RP-062` 至 `RP-076` trace 归档:[cqrs-rewrite-history-rp062-through-rp076.md](../archive/traces/cqrs-rewrite-history-rp062-through-rp076.md) +- CQRS 与 Mediator 评估归档:[cqrs-vs-mediator-assessment-rp063.md](../archive/todos/cqrs-vs-mediator-assessment-rp063.md) +- 历史 trace 归档:[cqrs-rewrite-history-through-rp043.md](../archive/traces/cqrs-rewrite-history-through-rp043.md) +- `RP-046` 至 `RP-061` trace 归档:[cqrs-rewrite-history-rp046-through-rp061.md](../archive/traces/cqrs-rewrite-history-rp046-through-rp061.md) + +## 说明 + +- `PR #261`、`PR #302`、`PR #305`、`PR #307` 及更早阶段的详细过程已不再作为 active 恢复入口;如需追溯,以对应归档文件或历史 trace 段落为准 +- active tracking 仅保留当前恢复点、当前风险、最近权威验证与下一推荐步骤,避免 `boot` 落到历史阶段细节 diff --git a/ai-plan/public/cqrs-rewrite/archive/traces/cqrs-rewrite-migration-trace-history-through-rp131.md b/ai-plan/public/cqrs-rewrite/archive/traces/cqrs-rewrite-migration-trace-history-through-rp131.md new file mode 100644 index 00000000..b7d9eec2 --- /dev/null +++ b/ai-plan/public/cqrs-rewrite/archive/traces/cqrs-rewrite-migration-trace-history-through-rp131.md @@ -0,0 +1,1727 @@ +# CQRS 重写迁移追踪 + +## 2026-05-11 + +### 阶段:benchmark 并发运行隔离入口(CQRS-REWRITE-RP-131) + +- 延续 `$gframework-batch-boot 50`,在 `RP-130` 已确认冲突来自 BenchmarkDotNet 工件/生成目录层后,本轮继续保持写面只在 `GFramework.Cqrs.Benchmarks` 单模块,优先收口 benchmark 入口而不是回头改 benchmark 业务逻辑 +- 本轮主线程与 worker 边界: + - `README.md` 由 worker 独占,补 `--artifacts-suffix ` 的使用约定与两条并发 smoke 命令示例 + - `Program.cs` 起初交给独立 worker,但其回传超时;主线程随后接管该单文件实现,并主动关闭未返回的 worker,避免继续消耗上下文预算 +- 本轮主线程关键修正: + - 首版只设置 `IConfig.ArtifactsPath`,虽然把结果导出目录隔离到了 `BenchmarkDotNet.Artifacts/`,但并行 smoke 立刻暴露出 auto-generated benchmark 项目仍写回共享 `bin/Release/net10.0/GFramework.Cqrs.Benchmarks-Job-JWUHXL-1/` 目录,`RequestLifetimeBenchmarks` 再次命中 `.dll.config being used by another process` + - 因此本轮把实现升级为“独立宿主目录重启”模型:当存在 `--artifacts-suffix` 时,`Program.cs` 会先把当前 benchmark 宿主输出复制到 `BenchmarkDotNet.Artifacts//host/`,再从该目录重新启动同一个程序集,并通过环境变量把隔离后的 artifacts path 传递给子进程 + - 最终子进程里的 BenchmarkDotNet restore/build/output 路径均落到 `BenchmarkDotNet.Artifacts//host/GFramework.Cqrs.Benchmarks-Job-...`,从根上切断同名 job 目录在并发进程之间的共享 +- 本轮验证: + - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - 备注:中途曾引入 `MA0015`,已在同一轮把 `ThrowIfNull` 改成显式局部变量判空后清零 + - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Program.cs GFramework.Cqrs.Benchmarks/README.md` + - 结果:通过 + - `git diff --check` + - 结果:通过 + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --artifacts-suffix req-lifetime-a --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:实际执行路径已切到 `BenchmarkDotNet.Artifacts/req-lifetime-a/host/...` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --artifacts-suffix stream-invoker-b --filter "*StreamInvokerBenchmarks.Stream_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:实际执行路径已切到 `BenchmarkDotNet.Artifacts/stream-invoker-b/host/...` + - 两条命令并发运行时未再出现 `.dll.config being used by another process`,说明冲突已经从入口层实质收口 +- 本轮结论: + - `--artifacts-suffix` 现在不只是“结果目录标签”,而是完整的并发运行隔离开关:它会同时隔离 BenchmarkDotNet 最终导出目录与 auto-generated benchmark 项目工作目录 + - 这条修复只触及 benchmark 入口与文档,不影响 `Fixture`、generated registry、runtime 宿主或 benchmark 业务语义,因此评审面仍保持单模块、低风险边界 +- 下一恢复点: + - 若继续 benchmark 线,可直接复用新的并发隔离能力,同时跑互不冲突的 filtered short-job,而不必再人为串行化所有 BenchmarkDotNet smoke + - 优先候选仍是 `StreamInvokerBenchmarks` `DrainAll` 更稳定作业复核,或其他仅触达 `GFramework.Cqrs.Benchmarks` 的对照矩阵扩展 + +### 阶段:stream lifetime scoped 矩阵与 README 同步(CQRS-REWRITE-RP-130) + +- 延续 `$gframework-batch-boot 50`,在上一波把 `StreamingBenchmarks`、`StreamInvokerBenchmarks` 与 `RequestLifetimeBenchmarks` 扩成双观测 / scoped-request 基线后,本轮先不回到 runtime,而是只补齐 `StreamLifetimeBenchmarks` 的真实 `Scoped` stream 生命周期矩阵,并同步 benchmark `README` +- 本轮主线程验收与修正: + - 接受 worker 留在 `BenchmarkHostFactory.cs` 的 scoped stream helper 方向,但把实现收口为“创建 scope -> 在 scope 内创建 runtime / mediator -> 让 scope 覆盖完整 async stream 枚举周期”的包装迭代器,而不是只在建流阶段短暂持有作用域 + - `StreamLifetimeBenchmarks.cs` 现仅在 `Lifetime == Scoped` 时改走新的 scoped stream helper;`Singleton / Transient` 仍保持原有最小 steady-state 宿主,不把 scoped 宿主额外成本误混进其他矩阵 + - `GFramework.Cqrs.Benchmarks/README.md` 已同步 `RequestLifetimeBenchmarks` 与 `StreamLifetimeBenchmarks` 的 `Scoped` 现状,并把 `StreamInvokerBenchmarks` `DrainAll` 标成 smoke-only 结论 +- 本轮验证: + - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/BenchmarkHostFactory.cs GFramework.Cqrs.Benchmarks/Messaging/StreamLifetimeBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` + - 结果:通过 + - `git diff --check` + - 结果:通过 + - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*StreamLifetimeBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:`24` 个 case 全部跑通;`Scoped + FirstItem` 约为 baseline `56.24 ns`、`MediatR` `338.82 ns`、reflection `612.49 ns`、generated `628.65 ns`;`Scoped + DrainAll` 约为 baseline `81.20 ns`、`MediatR` `428.66 ns`、generated `692.05 ns`、reflection `716.61 ns` +- 本轮结论: + - `StreamLifetimeBenchmarks` 现在已经具备与 `RequestLifetimeBenchmarks` 对称的真实 scoped-host 作用域边界,后续不必再先修 benchmark 宿主才能观察 stream scoped lifetime + - `Scoped` 成本当前明显高于 `Singleton / Transient`,说明这条矩阵已经把“真实 scope 生命周期”本身的常量开销带入观测;这正是本轮想要确认的边界,而不是回归或异常 + - 本轮并没有改变 `GFramework.Cqrs` runtime 或业务逻辑,只是把 benchmark 宿主语义与文档描述对齐到当前事实 +- 下一恢复点: + - 优先切到 benchmark 运行隔离层,只动 `GFramework.Cqrs.Benchmarks/Program.cs` 与必要的 `README` 说明,解决两个过滤 benchmark 并行运行时共享 auto-generated build/artifacts 目录的问题 + - 新开的 explorer 已确认根因集中在 `Program.cs` 直接把 `args` 原样交给 `BenchmarkSwitcher.Run(args)`,当前没有为每次运行注入唯一 `ArtifactsPath`;不建议下一批回头改 `Fixture.cs` 或 benchmark 业务逻辑 + +### 阶段:benchmark 多 worker 波次与 scoped-host 基线(CQRS-REWRITE-RP-129) + +- 本轮从 `$gframework-batch-boot 50` 启动,但按 `gframework-multi-agent-batch` 规则把非阻塞工作拆成三条互不冲突的 benchmark 切片: + - `StreamingBenchmarks.cs`:默认 steady-state stream 宿主补 `FirstItem / DrainAll` + - `StreamInvokerBenchmarks.cs`:generated/reflection/MediatR invoker 对照补 `FirstItem / DrainAll` + - `RequestLifetimeBenchmarks.cs` + `BenchmarkHostFactory.cs` + `ScopedBenchmarkContainer.cs`:为 request lifetime 引入真实 scoped-host 作用域边界 +- 启动前已重新复核基线:`origin/main` 与本地 `main` 当前同为 `699d0b48`,启动时 `origin/main...HEAD` 为 `0 files / 0 lines`;因此先前 active 入口里的 `21 files` 已视为历史恢复信息,不再作为本轮 stop-condition 计数基线 +- worker 输出验收: + - `StreamingBenchmarks` worker 仅触达 `StreamingBenchmarks.cs`,并完成 `dotnet build ... -c Release` 与 `dotnet run ... --filter "*StreamingBenchmarks*"`;本轮保留其实现与 smoke 结果 + - `StreamInvokerBenchmarks` worker 只触达 `StreamInvokerBenchmarks.cs`,主线程保留其观测模式拆分;后续 smoke 验证改由主线程串行执行 + - `RequestLifetimeBenchmarks` worker 在 `BenchmarkHostFactory.cs` 与新建 `ScopedBenchmarkContainer.cs` 留下未编译完的 scoped-helper 草稿;主线程接手补齐 `using`、`IContextAware` 转发与 `IPrioritized` 命名空间,然后完成 `RequestLifetimeBenchmarks.cs` 的 scoped 接线 +- 本轮主线程关键修正: + - `ScopedBenchmarkContainer` 采用“根容器注册可见性 + 作用域 provider 实例解析”的只读适配层,避免在 request benchmark 里把 scoped handler 错误解析到根容器 + - `BenchmarkHostFactory.SendScopedGFrameworkRequestAsync(...)` 与 `SendScopedMediatRRequestAsync(...)` 统一封装每次 request 的显式 scope 创建/释放逻辑 + - 首次把 `StreamInvokerBenchmarks` 与 `RequestLifetimeBenchmarks` 并行跑 smoke 时触发 BenchmarkDotNet 自动生成目录争用;主线程按仓库规则改为串行重跑相同命令,并以串行结果为权威 +- 本轮验证: + - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/BenchmarkHostFactory.cs GFramework.Cqrs.Benchmarks/Messaging/RequestLifetimeBenchmarks.cs GFramework.Cqrs.Benchmarks/Messaging/ScopedBenchmarkContainer.cs GFramework.Cqrs.Benchmarks/Messaging/StreamInvokerBenchmarks.cs GFramework.Cqrs.Benchmarks/Messaging/StreamingBenchmarks.cs` + - 结果:通过 + - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*StreamInvokerBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过(串行权威结果) + - 备注:`FirstItem` 下 baseline / reflection / generated 约为 `5.84 ns / 52.90 ns / 59.44 ns`;`DrainAll` 报告当前呈现异常排序,应只把本次结果视作 smoke 运行通过信号,不直接当成稳定性能结论 + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过(串行权威结果) + - 备注:`Singleton` 下 baseline / `GFramework.Cqrs` / `MediatR` 约为 `5.23 ns / 53.43 ns / 56.35 ns`;`Scoped` 下约为 `5.60 ns / 575.92 ns / 170.94 ns`;`Transient` 下约为 `6.00 ns / 58.70 ns / 60.91 ns` +- 下一恢复点: + - 先把 `GFramework.Cqrs.Benchmarks/README.md` 与本 active tracking / trace 从旧 `PR #345 / 21 files` 状态刷新到当前 `699d0b48` 基线和本轮新矩阵 + - 然后判断 `StreamInvokerBenchmarks` 的 `DrainAll` smoke 输出是否需要单开一批稳定性复核;若只是 short-job 配置噪音,再考虑继续把 scoped host 扩到 stream lifetime,而不是现在就解读该组数字 + +## 2026-05-09 + +### 阶段:PR #345 latest-head review 收口(CQRS-REWRITE-RP-128) + +- 使用 `$gframework-pr-review` 抓取当前分支对应的 `PR #345`,确认 latest-head 没有新的 unresolved review thread,但 CodeRabbit 最新 review body 仍保留 `4` 条 actionable comments +- 本轮本地复核后接受并修复的反馈收敛到四类: + - `AGENTS.md` 的 multi-agent budget 术语缺少明确释义,影响新贡献者理解 stop condition + - `StreamLifetimeBenchmarks` 的 `ConsumeFirstItemAsync(...)` 未显式向枚举器传播 `CancellationToken`,且 `[EnumeratorCancellation]` 仍使用全限定名 + - `StreamLifetimeBenchmarks` 类级 `` 尚未解释 `FirstItem / DrainAll` 观测维度的取舍 + - `GFramework.Cqrs.Benchmarks/README.md` 与 `ai-plan/public/cqrs-rewrite/todos/**` 仍保留治理型 `RP-127` 表述、过期 `PR #344` 锚点与旧 branch diff 数字 +- 本轮验证计划保持最小化: + - 代码路径用 `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` 证明 benchmark 工程仍可编译 + - 文档与 tracking 更新后补跑 `python3 scripts/license-header.py --check --paths AGENTS.md GFramework.Cqrs.Benchmarks/Messaging/StreamLifetimeBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` +- 本轮验证结果: + - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `python3 scripts/license-header.py --check --paths AGENTS.md GFramework.Cqrs.Benchmarks/Messaging/StreamLifetimeBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` + - 结果:通过 +- 当前分支相对 `origin/main` (`d85828c5`) 的累计 branch diff 已复核为 `21 files / 1344 insertions / 194 deletions`,后续 active tracking 与 trace 均以这组数字为准 +- 下一恢复点: + - 推送本轮 commit 后,再次运行 `$gframework-pr-review` 复核 `PR #345` latest-head review body 是否已收敛 + - 若 stream lifetime 后续仍要继续压热路径,优先恢复 `Transient + FirstItem` 的小幅差值复核,而不是重新展开已收口的 `README` / `ai-plan` 漂移问题 + +### 阶段:stream lifetime 观测维度补齐与 generated binding 强类型缓存(CQRS-REWRITE-RP-127) + +- 延续 `$gframework-batch-boot 50`,在 `RP-126` 已建立四方 stream lifetime 口径后,本轮改用多 worker wave 同时推进三个互不冲突切片: + - `benchmark-only`:为 `StreamLifetimeBenchmarks` 增加 `FirstItem / DrainAll` 观测维度,并收口 `MA0004` + - `runtime-only`:把 `CqrsDispatcher.CreateStream(...)` 的 stream dispatch binding 改成按 `TResponse` 强类型缓存,避免 generated lane 在热路径上继续通过 `object -> IAsyncEnumerable` 桥接 + - `docs / ai-plan`:把 `RP-126` 的旧恢复结论更新为本轮实测结果,并给出下一恢复入口 +- 本轮主线程验收与修正: + - 首次并行验证时,`dotnet test` 与 `dotnet build` 同跑触发 `MSB3030` 输出争用;已按仓库规则改为串行重跑同一命令,并以串行结果为权威 + - runtime worker 初版在 `CqrsDispatcher.cs` 留下一个 `StreamInvoker` 方法组绑定编译错误;主线程已局部修正为显式 lambda 适配,未改变预期语义 + - 经修正后,generated lane 不再出现 “incompatible invoker signature” 运行时异常,`StreamLifetimeBenchmarks` 16 个 case 全部通过 +- 本轮验证: + - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsDispatcherCacheTests|FullyQualifiedName~CqrsGeneratedRequestInvokerProviderTests"` + - 结果:通过,`31/31` passed + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*StreamLifetimeBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:`Transient + FirstItem` 下 generated 约 `100.011 ns / 240 B`、reflection 约 `97.628 ns / 240 B`;`Transient + DrainAll` 下 generated 约 `116.780 ns / 304 B`、reflection 约 `124.174 ns / 304 B` +- 本轮结论: + - `FirstItem / DrainAll` 双观测维度把“建流到首个元素的瞬时成本”和“完整枚举总成本”拆开后,`Transient` 场景下的 generated lane 已不再呈现统一的反向退化 + - 当前仍保留的差值集中在 `Transient + FirstItem`,规模约 `2.4 ns`,明显小于 `RP-126` 的旧结论;而 `Transient + DrainAll` 已转为 generated 领先 reflection + - 当前分支相对 `origin/main` 的累计 branch diff 已到 `21 files`(`1231 insertions / 181 deletions`),仍低于 `$gframework-batch-boot 50` 阈值;但主线程已接近当前回合的安全上下文预算,因此在本轮自然边界停止,不继续开下一波 worker +- 下一恢复点: + - 若继续 benchmark 线,先从 `Transient + FirstItem` 的小幅差值恢复,并用 `StreamInvokerBenchmarks` 复核 generated lane 的常量成本收益是否仍成立;若差值不稳定,再考虑把下一批切到 `Mediator` concrete runtime 的 stream lifetime 对照 + - 若切回 runtime 线,则以 `b7fa3eee` 与本轮 `StreamLifetimeBenchmarks` 双口径结果作为后续回归基线 + +### 阶段:stream lifetime 对照口径补齐(CQRS-REWRITE-RP-126) + +- 延续 `$gframework-batch-boot 50`,在 `RP-125` 先把 request lifetime benchmark 宿主对齐到 generated-provider 路径后,本轮继续补齐 stream 生命周期矩阵的当前对照口径,不回到 runtime 或测试代码 +- 本轮主线程决策: + - 只修改 `GFramework.Cqrs.Benchmarks/Messaging/GeneratedStreamLifetimeBenchmarkRegistry.cs` 与 `StreamLifetimeBenchmarks.cs`,不扩散到 `GFramework.Cqrs` runtime、README 或 docs + - 将 stream lifetime 的 GFramework reflection、GFramework generated 与 `MediatR` 请求/响应/handler 类型拆开,避免不同宿主继续共用同一 stream 合同而污染对照语义 + - 将 generated registry 收口为只绑定 `GeneratedBenchmarkStreamRequest/Response` 这一条 generated lane,避免静态 dispatcher cache 把 reflection 与 generated 结果混在一起 +- 本轮验证: + - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*StreamLifetimeBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:`Singleton` 下 baseline / generated / reflection / `MediatR` 约为 `79.602 ns / 280 B`、`111.547 ns / 280 B`、`120.553 ns / 280 B`、`208.381 ns / 672 B`;`Transient` 下 baseline / reflection / generated / `MediatR` 约为 `76.351 ns / 280 B`、`119.632 ns / 304 B`、`129.166 ns / 304 B`、`213.420 ns / 672 B` +- 本轮结论: + - 当前 stream 生命周期矩阵已经具备可直接比较 `baseline / reflection / generated / MediatR` 的四方口径,后续恢复时无需再回头拼接不同批次的 stream 生命周期数据 + - 当前短跑下,generated lane 在 `Singleton` 档优于 reflection,但在 `Transient` 档仍慢于 reflection,差值约为 `9.5 ns` 与 `24 B`;这里先只把它记录为 benchmark 观察,不把它放大成更宽泛的 runtime 优劣结论 + - 当前已提交分支相对 `origin/main`(`d85828c5`, `2026-05-09 12:25:41 +0800`)的累计 branch diff 已到 `10 files`(`556 insertions / 75 deletions`),仍远低于 `$gframework-batch-boot 50` 的 `50 files` stop condition +- 下一恢复点: + - 若继续 benchmark 线,优先从 `Stream_GFrameworkGenerated` 与 `Stream_GFrameworkReflection` 的 `Transient` 差值恢复,先确认该差值是否稳定,再决定继续压 generated 宿主的瞬时解析成本,或单开 `Mediator` concrete runtime 的 stream lifetime 对照批次;若切回 runtime 线,则以 `RP-126` 的四方矩阵作为后续性能回归基线 + +### 阶段:request lifetime generated-provider 宿主对齐(CQRS-REWRITE-RP-125) + +- 延续 `$gframework-batch-boot 50`,在 `RP-124` 收口 stream behavior presence cache 后,本轮先不继续改 dispatcher,而是回头补齐 request lifetime benchmark 宿主路径,让生命周期矩阵与当前默认 request steady-state 的 generated-provider 口径重新对齐 +- 本轮主线程决策: + - 只修改 `GFramework.Cqrs.Benchmarks/Messaging/GeneratedRequestLifetimeBenchmarkRegistry.cs` 与 `RequestLifetimeBenchmarks.cs` + - 为 request lifetime 补入 handwritten generated registry,只暴露最小 generated request descriptor,再由 benchmark 主体显式控制 `Singleton / Transient` handler 生命周期 + - 在 setup / cleanup 统一清理 dispatcher cache,避免不同生命周期矩阵之间共享静态缓存而污染结果 +- 本轮验证: + - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:`Singleton` 下 baseline / `GFramework.Cqrs` / `MediatR` 约为 `5.012 ns / 32 B`、`49.612 ns / 32 B`、`51.796 ns / 232 B`;`Transient` 下约为 `3.962 ns / 32 B`、`50.480 ns / 56 B`、`50.284 ns / 232 B` +- 本轮结论: + - request lifetime 宿主现已与当前 generated-provider request 宿主保持一致,后续不再需要把旧生命周期矩阵结果与 generated steady-state 数据做“跨宿主”比较 + - 当前短跑下,`Singleton` 仍稳定快于 `MediatR`,`Transient` 已缩到基本持平但仍略慢;这给下一步 stream 线 benchmark 同步提供了更干净的 request 基线 +- 下一恢复点: + - 继续补齐 `StreamLifetimeBenchmarks` 的当前对照口径,把 `baseline / reflection / generated / MediatR` 四方生命周期矩阵补完整 + +### 阶段:stream behavior presence cache(CQRS-REWRITE-RP-124) + +- 延续 `$gframework-batch-boot 50`,在 `RP-123` 收口 notification publisher review 线程后,继续把 `CqrsDispatcher` 的 stream 热路径与 `RP-122` 的 request hot path 对齐,选择“缓存 `CreateStream(...)` 的 behavior presence 判定”这一条最小且可验证的 runtime 切片 +- 本轮主线程决策: + - 仅修改 `GFramework.Cqrs/Internal/CqrsDispatcher.cs`、`GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherCacheTests.cs`,并新增 `DispatcherZeroPipelineStreamRequest/Handler` 测试桩,不扩散到新的公开 API、中文文档或额外 benchmark 宿主实现 + - 为 `CqrsDispatcher` 新增实例级 `_streamBehaviorPresenceCache`,按闭合 `IStreamPipelineBehavior<,>` 服务类型缓存当前 dispatcher 容器中的服务可见性,让 `CreateStream(...)` 在 steady-state 下不再重复调用 `HasRegistration(Type)` + - 在 `CqrsDispatcherCacheTests` 新增 `Dispatcher_Should_Cache_Stream_Behavior_Presence_Per_Dispatcher_Instance()`,显式锁住“同容器共享同一 dispatcher/cache、独立容器不共享”的实例级边界,并把缓存值与容器实际 `HasRegistration(...)` 语义对齐,避免测试再依赖夹具对某个具体 stream 类型的错误可见性假设 +- 本轮验证: + - `python3 scripts/license-header.py --check --paths GFramework.Cqrs/Internal/CqrsDispatcher.cs GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherCacheTests.cs GFramework.Cqrs.Tests/Cqrs/DispatcherZeroPipelineStreamRequest.cs GFramework.Cqrs.Tests/Cqrs/DispatcherZeroPipelineStreamHandler.cs` + - 结果:通过 + - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet build GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~CqrsDispatcherCacheTests"` + - 结果:通过,`12/12` passed + - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*StreamLifetimeBenchmarks.Stream_GFrameworkCqrs*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:`Singleton` 约 `107.241 ns / 240 B`,`Transient` 约 `119.434 ns / 264 B` + - `git diff --check` + - 结果:通过 + - 备注:仅剩 `GFramework.sln` 的历史 CRLF 提示,无本轮新增 diff 格式问题 +- 下一恢复点: + - 推送本轮 commit 后,再次运行 `$gframework-pr-review` 复核 `PR #344` latest-head thread 是否已收敛;若 review 已清空,则下一批优先补完整 `StreamLifetimeBenchmarks` 三方对照,再决定继续压 stream 零管道常量路径还是切回 request `Transient` 热点 + +### 阶段:PR #344 latest-head review 收尾(CQRS-REWRITE-RP-123) + +- 使用 `$gframework-pr-review` 重新抓取当前分支 PR,确认当前 worktree 对应 `PR #344`,latest-head 仍有 `CodeRabbit 2` / `Greptile 1` open thread +- 主线程逐条复核后确认仍成立的问题: + - `CodeRabbit` 对 `NotificationPublisherRegistrationExtensionsTests` 的“唯一注册”断言建议仍有效 + - `CodeRabbit` 对 strict `IIocContainer` mock 缺少 `GetAll(typeof(INotificationPublisher))` 默认装配的 CI 失败结论仍有效,且更适合在两个测试 helper 层统一兜底 + - `CodeRabbit` 对 `CqrsDispatcherCacheTests` 的共享装配 helper 建议仍有效,属于真实维护性风险而非纯样式问题 + - `Greptile` 指出的 `ResolveNotificationPublisher()` 热路径重复 `GetAll(...)` 与默认 publisher 重复分配也成立;由于容器在 publish 前已冻结,dispatcher 生命周期内可以安全缓存最终解析结果 +- 本轮决策: + - 为 `CqrsDispatcher` 增加 dispatcher 实例级 `_resolvedNotificationPublisher` 缓存,并使用线程安全比较交换固定首次解析出的最终策略实例 + - 在 `CqrsDispatcherContextValidationTests` 与 `CqrsNotificationPublisherTests` 的 strict mock runtime helper 中统一预设 `GetAll(typeof(INotificationPublisher))` 返回空集合 + - 在 `NotificationPublisherRegistrationExtensionsTests` 为泛型组合根重载补上 `INotificationPublisher` 唯一注册断言 + - 在 `CqrsDispatcherCacheTests` 提取共享的 `ConfigureDispatcherCacheFixture(...)`,消除 `SetUp()` 与 `CreateFrozenContainer()` 的注册漂移风险 +- 本轮验证: + - `python3 scripts/license-header.py --check --paths GFramework.Cqrs/Internal/CqrsDispatcher.cs GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherContextValidationTests.cs GFramework.Cqrs.Tests/Cqrs/CqrsNotificationPublisherTests.cs GFramework.Cqrs.Tests/Cqrs/NotificationPublisherRegistrationExtensionsTests.cs GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherCacheTests.cs ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` + - 结果:通过 + - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - 备注:首轮与 `GFramework.Cqrs.Tests` 并行构建时出现 `MSB3026` 单次复制重试;串行重跑后稳定通过,判定为输出目录竞争噪音 + - `dotnet build GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~CqrsDispatcherContextValidationTests|FullyQualifiedName~CqrsNotificationPublisherTests|FullyQualifiedName~NotificationPublisherRegistrationExtensionsTests|FullyQualifiedName~CqrsDispatcherCacheTests"` + - 结果:通过,`30/30` passed + - `git diff --check` + - 结果:通过 +- 下一恢复点: + - 推送本轮 commit 后,再次运行 `$gframework-pr-review` 复核 `PR #344` latest-head open thread 是否已随新 head 收敛;若仍残留 open thread,再区分 stale 状态与新增 review + +### 阶段:request 零管道 behavior presence cache(CQRS-REWRITE-RP-122) + +- 延续 `$gframework-batch-boot 50`,本轮在 `RP-121` 把 notification 线阶段性收口后,重新回到 request steady-state 常量开销,并接受并行 explorer 的共同结论:下一刀应继续减少每次 `SendAsync(...)` 必经的通用查询,而不是回头优化 `HasRegistration(Type)` 内部实现或重试已证伪的 `IContextAware` 类型缓存 +- 本轮主线程决策: + - 只改 `GFramework.Cqrs/Internal/CqrsDispatcher.cs` 与 `GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherCacheTests.cs`,不同时打开 scoped benchmark 宿主或 notification 新公开 API 两条线 + - 为 `CqrsDispatcher` 新增 `_requestBehaviorPresenceCache`,按闭合 `IPipelineBehavior<,>` 服务类型缓存“当前 dispatcher 的容器里是否存在该 request behavior 注册” + - 保持优化面只覆盖 request `0 pipeline` 热路径;stream 对称缓存与 scoped host benchmark 继续留到后续独立批次 + - 在 `CqrsDispatcherCacheTests` 新增实例级回归,明确“同容器多个 `ArchitectureContext` 解析到同一个 runtime/dispatcher,会共享该缓存;另一独立容器创建的 dispatcher 不共享该缓存” +- 本轮权威验证: + - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsDispatcherCacheTests"` + - 结果:通过,`11/11` passed + - 备注:新增回归首轮曾因错误假设“不同 `ArchitectureContext` 必定对应不同 dispatcher”而失败;修正为“同容器共享 runtime、独立容器不共享缓存”后稳定通过 + - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:默认 request steady-state 当前约为 baseline `5.876 ns / 32 B`、`Mediator` `5.275 ns / 32 B`、`GFramework.Cqrs` `51.717 ns / 32 B`、`MediatR` `56.108 ns / 232 B` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:首次与 `RequestBenchmarks` 并行触发时,BenchmarkDotNet 自动生成项目目录发生 `.nuget.g.props already exists` 冲突;改为串行重跑同一命令后,`Singleton` 下 baseline / `GFramework.Cqrs` / `MediatR` 约 `5.720 ns / 52.490 ns / 56.890 ns`,`Transient` 下约 `5.814 ns / 57.746 ns / 55.545 ns` + - `python3 scripts/license-header.py --check --paths GFramework.Cqrs/Internal/CqrsDispatcher.cs GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherCacheTests.cs` + - 结果:通过 +- 本轮结论: + - request `0 pipeline` 常量路径再次被压短,默认 steady-state request 与 `Singleton` lifetime 均继续快于当前 `MediatR` short-job 基线 + - `Transient` 仍略慢于 `MediatR`,但相较更早轮次已明显收敛;下一轮若继续 request 热点,更值得继续减少 steady-state 必经路径,或切到 explorer 建议的 `request scoped host + compile-time lifetime` 对齐线,而不是继续打磨已收益有限的 `HasRegistration(Type)` 内部细节 + +### 阶段:标准架构启动路径 notification publisher 回归(CQRS-REWRITE-RP-121) + +- 延续 `$gframework-batch-boot 50`,本轮没有继续扩 notification runtime 语义,而是先给 `RP-120` 刚修复的默认接线补一条更贴近生产的架构启动回归 +- 本轮主线程决策: + - 保持写面只落在 `GFramework.Core.Tests/Architectures/ArchitectureModulesBehaviorTests.cs`,不再改动 `GFramework.Cqrs` / `GFramework.Core` 运行时代码 + - 通过 `Architecture.Configurator` 注册依赖容器 probe 的自定义 `INotificationPublisher`,并在 `OnInitialize()` 显式接入额外程序集 notification handler,验证默认 `Architecture.InitializeAsync()` 路径最终 publish 时不会退回默认顺序策略 + - 用现有 `AdditionalAssemblyNotificationHandlerRegistry` 测试桩承载 handler 执行观察,把本轮信号收敛到“标准架构启动路径是否真正复用自定义 publisher” +- 本轮权威验证: + - `dotnet build GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~ArchitectureModulesBehaviorTests"` + - 结果:通过,`5/5` passed + - `python3 scripts/license-header.py --check --paths GFramework.Core.Tests/Architectures/ArchitectureModulesBehaviorTests.cs` + - 结果:通过 +- 本轮结论: + - 标准 `Architecture.InitializeAsync()` 启动路径现在也被回归锁住:通过 `Configurator` 声明的自定义 `INotificationPublisher` 会在真实 publish 路径里被复用,不会再被 `CqrsRuntimeModule` 创建 runtime 时静默短路成默认顺序发布器 + - notification 线当前已形成“组合根入口 -> 默认接线修复 -> 标准架构启动回归”的闭环;下一轮若继续留在该方向,更合理的是重新评估产品面是否真的需要第三种仓库内置策略,而不是继续堆同层级回归 + +### 阶段:notification publisher 默认接线修复(CQRS-REWRITE-RP-120) + +- 延续 `$gframework-batch-boot 50`,本轮沿着 `RP-119` 的 notification publisher 组合根回归继续向下追,发现这不是单纯的文档或测试补洞,而是默认 runtime 接线存在真实时序缺陷 +- 本轮主线程决策: + - 保持修复面收敛在 notification publisher 单线,不把问题扩散到 request dispatch 热路径或无关模块 + - 让 `CqrsRuntimeFactory.CreateRuntime(...)` 不再在工厂层把 `null` publisher 立即替换成 `SequentialNotificationPublisher`,改由 `CqrsDispatcher` 在真正 publish 时优先复用显式实例或容器内唯一注册策略,最后才回退到默认顺序发布器 + - 同步移除 `CqrsRuntimeModule` 与 `GFramework.Tests.Common/CqrsTestRuntime` 里对 `container.Get()` 的预解析,避免冻结前可见性再次把策略短路掉 + - 在 `NotificationPublisherRegistrationExtensionsTests` 新增“publisher 依赖容器内探针服务”的真实采用回归,并重新验证 `UseTaskWhenAllNotificationPublisher()` 在默认基础设施路径里会继续调度所有处理器 +- 本轮权威验证: + - `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~NotificationPublisherRegistrationExtensionsTests"` + - 结果:通过,`7/7` passed + - `python3 scripts/license-header.py --check --paths GFramework.Cqrs/Internal/CqrsDispatcher.cs GFramework.Cqrs/CqrsRuntimeFactory.cs GFramework.Core/Services/Modules/CqrsRuntimeModule.cs GFramework.Tests.Common/CqrsTestRuntime.cs GFramework.Cqrs.Tests/Cqrs/NotificationPublisherRegistrationExtensionsTests.cs` + - 结果:通过 + - `git diff --check` + - 结果:通过 +- 本轮结论: + - `UseTaskWhenAllNotificationPublisher()` 与 `UseNotificationPublisher()` 现在不再只是“能注册进容器”,而是能真正穿过默认 runtime 基础设施参与 publish 路径 + - 本轮属于完整的语义修复批次,应在提交后再决定是否继续 notification 线或切回 request steady-state 热点 + +### 阶段:notification publisher 泛型组合根入口收口(CQRS-REWRITE-RP-119) + +- 延续 `$gframework-batch-boot 50`,本轮在 `feat/cqrs-optimization` 已与 `origin/main` 对齐后,没有直接重开 request dispatch 热路径实验,而是先选择 notification publisher 线上一个更小、可直接评审的采用面切片 +- 本轮主线程决策: + - 保持 `GFramework.Cqrs` runtime 代码不变,只补 `UseNotificationPublisher()` 的组合根回归与用户文档说明 + - 在 `NotificationPublisherRegistrationExtensionsTests` 新增两条 targeted 回归,确认泛型重载会注册唯一单例策略,且在容器已存在 `INotificationPublisher` 时同样会拒绝重复声明 + - 在 `GFramework.Cqrs/README.md` 与 `docs/zh-CN/core/cqrs.md` 把自定义入口统一写成 `UseNotificationPublisher(...)` / `UseNotificationPublisher()`,并明确实例重载与泛型重载的生命周期边界 +- 本轮权威验证: + - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~NotificationPublisherRegistrationExtensionsTests"` + - 结果:通过,`6/6` passed + - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Tests/Cqrs/NotificationPublisherRegistrationExtensionsTests.cs GFramework.Cqrs/README.md docs/zh-CN/core/cqrs.md ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` + - 结果:通过 + - `git diff --check` + - 结果:通过 +- 本轮结论: + - notification publisher 的组合根采用面现在不再默认读者只能“手里先有一个实例”;文档与回归都已明确容器托管型自定义 publisher 的标准入口 + - 这批仍然保持在低风险、单模块、易评审边界内,适合在完成验证后直接收口为新的恢复点 + +## 2026-05-08 + +### 阶段:PR #342 latest-head review 收口(CQRS-REWRITE-RP-118) + +- 使用 `$gframework-pr-review` 抓取 `feat/cqrs-optimization` 当前公开 PR,并确认当前锚点已从 `PR #341` 更新为 `PR #342` +- 本轮 latest-head review 结论: + - `CodeRabbit` 当前仍成立的是 `NotificationFanOutBenchmarks.cs` 中 MediatR 显式 `Handle(...)` 直接返回 `Task.CompletedTask`,导致该对照组绕过共享 `HandleCore(...)` 的空值 / 取消校验 + - `CodeRabbit` 对 `ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md` 的两条评论也成立:当前恢复点锚点仍写 `PR #341`,且“最近权威验证”里的 fan-out 数值属于更早轮次,需要显式标注历史来源 + - `Greptile` 额外指出 `GFramework.Cqrs/README.md` 与 `docs/zh-CN/core/cqrs.md` 里 `UseTaskWhenAllNotificationPublisher()` 示例包含多余 `using GFramework.Cqrs.Notification;`;这条在当前 head 仍成立 + - MegaLinter 仍报告 `dotnet-format` restore 失败,但这属于 CI 环境 restore 噪声,不是当前 diff 的格式违规;README 的 MD058 空行问题仍需在本地直接修复 +- 本轮主线程决策: + - 让 `NotificationFanOutBenchmarks` 的四个 MediatR handler 显式转发到 `HandleCore(notification, cancellationToken).AsTask()`,保持与 baseline、`GFramework.Cqrs` 和 NuGet `Mediator` 分支一致的前置检查 + - 在 `GFramework.Cqrs/README.md` 修复表格前后空行,并删除 README / 中文文档中 `UseTaskWhenAllNotificationPublisher()` 示例的多余 `using` + - 把 `cqrs-rewrite` tracking 当前恢复点推进到 `RP-118`,同步 `PR #342` 锚点,并把早期 fan-out 数值显式标成 `历史基线(RP-112)` +- 本轮权威验证: + - `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --format json --json-output /tmp/current-pr-review.json` + - 结果:通过 + - 备注:确认当前分支对应 `PR #342`;CodeRabbit 当前 `4` 条 actionable comments 与 Greptile `3` 条 open thread 已作为本轮本地复核输入 + - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*NotificationFanOutBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:本轮对称化 MediatR handler 后,fixed `4 handler` fan-out 对照约为 `Mediator` `3.598 ns / 0 B`、baseline `7.033 ns / 0 B`、`MediatR` `257.533 ns / 1256 B`、`GFramework.Cqrs` 顺序 `409.557 ns / 408 B`、`TaskWhenAll` `484.531 ns / 496 B` + - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/NotificationFanOutBenchmarks.cs GFramework.Cqrs/README.md docs/zh-CN/core/cqrs.md ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` + - 结果:通过 + - `git diff --check` + - 结果:通过 + - 备注:仅剩 `GFramework.sln` 的历史 CRLF 提示,无本轮新增 diff 格式问题 + +### 阶段:notification publisher 采用矩阵文档收口(CQRS-REWRITE-RP-117) + +- 延续 `$gframework-batch-boot 50`,本轮没有继续把自动批处理推到新的 runtime seam,而是先按 tracking 建议复核“notification 线是否还缺采用边界文档”: + - 当前分支相对 `origin/main`(`7ca21af9`, `2026-05-08 16:12:20 +0800`)的累计 branch diff 约为 `12 files`,仍明显低于 `50` 文件阈值 + - 主线程先短试了一刀 request dispatch 热路径微优化:把 dispatcher 中“运行时类型是否实现 `IContextAware`”改成弱键缓存,并按性能治理规则复跑 `RequestBenchmarks` 与 `RequestLifetimeBenchmarks` + - 复跑结果表明这条假设没有正收益:默认 steady-state request 回到约 `71.824 ns / 32 B`,`Singleton / Transient` lifetime 约为 `73.191 ns / 32 B` 与 `80.468 ns / 56 B`,因此本轮在同一提交前已完全撤回该运行时代码实验,不把负收益热点带进后续恢复点 +- 本轮主线程决策: + - 保持 `GFramework.Cqrs` runtime 与测试代码不变,只更新 `GFramework.Cqrs/README.md` 与 `docs/zh-CN/core/cqrs.md` + - 把 `SequentialNotificationPublisher`、`TaskWhenAllNotificationPublisher` 与 `UseNotificationPublisher(...)` 自定义实例三条路径收口到同一张策略矩阵 + - 在用户文档里明确 `TaskWhenAllNotificationPublisher` 是“并行完成 + 聚合失败”语义策略,而不是 fixed fan-out publish 的性能开关 +- 本轮权威验证: + - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsDispatcherCacheTests|FullyQualifiedName~CqrsDispatcherContextValidationTests"` + - 结果:通过,`17/17` passed + - 备注:首轮与 build 并行触发时出现 `MSB3026` 单次复制重试告警,但同一命令最终稳定通过,未形成代码失败 + - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:用于否决本轮已撤回的热点假设;默认 steady-state request 对照约为 baseline `5.853 ns / 32 B`、`Mediator` `6.256 ns / 32 B`、`MediatR` `53.401 ns / 232 B`、`GFramework.Cqrs` `71.824 ns / 32 B` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:用于否决本轮已撤回的热点假设;`Singleton` 下 baseline / `MediatR` / `GFramework.Cqrs` 约 `5.259 ns / 58.415 ns / 73.191 ns`,`Transient` 下约 `4.914 ns / 57.150 ns / 80.468 ns` +- 本轮结论: + - notification publisher 公开入口现在不仅有显式顺序 / 并行 API,也有更直接的策略选择矩阵;读者不再需要从分散段落里拼装“什么时候该选哪条策略” + - request dispatch 热路径的下一轮探索应显式绕开“类型级 `IContextAware` 判定缓存”这一条已验证无收益的方向,把 context budget 留给更可能影响 steady-state 的热点 + - 当前仍可继续自动推进,但若再开一批 runtime 性能实验,应放在新的自然批次里,避免把已否决假设和新热点混在同一评审单元中 + +### 阶段:公开顺序 notification publisher 策略(CQRS-REWRITE-RP-116) + +- 延续 `$gframework-batch-boot 50`,本轮继续留在 notification publisher 配置面,但不再新增第三方 benchmark 或 runtime seam: + - 当前分支相对 `origin/main`(`7ca21af9`, `2026-05-08 16:12:20 +0800`)的累计 branch diff 在 `RP-115` 提交后约为 `11 files`,明显低于 `50` 文件阈值 + - `RP-115` 已把采用路径收口到显式组合根扩展,但当前仍只有 `TaskWhenAllNotificationPublisher` 是公开内置策略;默认顺序语义仍主要靠“未注册时的隐式回退”表达 +- 本轮主线程决策: + - 新增公开 `GFramework.Cqrs/Notification/SequentialNotificationPublisher.cs`,并让 `CqrsRuntimeFactory` 默认回退直接使用这条公开顺序策略 + - 删除 `GFramework.Cqrs/Internal/SequentialNotificationPublisher.cs` 的内部副本,避免默认顺序语义同时存在“内部实现”和“公开实现”两套类型来源 + - 为 `NotificationPublisherRegistrationExtensions` 增加 `UseSequentialNotificationPublisher()`,并在回归与用户文档中把“显式顺序策略”与“显式并行策略”作为对称选择面呈现 +- 本轮权威验证: + - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~NotificationPublisherRegistrationExtensionsTests|FullyQualifiedName~CqrsNotificationPublisherTests"` + - 结果:通过,`10/10` passed + - `python3 scripts/license-header.py --check --paths GFramework.Cqrs/Notification/SequentialNotificationPublisher.cs GFramework.Cqrs/CqrsRuntimeFactory.cs GFramework.Cqrs/Extensions/NotificationPublisherRegistrationExtensions.cs GFramework.Cqrs.Tests/Cqrs/NotificationPublisherRegistrationExtensionsTests.cs GFramework.Cqrs/README.md docs/zh-CN/core/cqrs.md ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` + - 结果:通过 + - `git diff --check` + - 结果:通过 +- 本轮结论: + - notification publisher 的公开配置面现已从“一个显式策略 + 一个隐式默认回退”收口成两条对称的内置策略选择:`UseSequentialNotificationPublisher()` 与 `UseTaskWhenAllNotificationPublisher()` + - 若后续继续 notification 线,更合理的下一刀会是补更细的采用文档或新的策略语义,而不是继续让顺序 / 并行这两条基础选择停留在隐式约定上 + +### 阶段:notification publisher 组合根配置面(CQRS-REWRITE-RP-115) + +- 延续 `$gframework-batch-boot 50`,本轮不再回到 benchmark 宿主,而是沿着 `RP-114` 已明确的性能/语义事实继续收口用户接入缺口: + - 当前分支相对 `origin/main`(`7ca21af9`, `2026-05-08 16:12:20 +0800`)的累计 branch diff 在启动时仍为 `9 files`,明显低于 `50` 文件阈值 + - `RP-113` / `RP-114` 已证明内置 `TaskWhenAllNotificationPublisher` 的价值主要是语义补齐,但当前用户若要采用它,仍需知道 `INotificationPublisher` 的底层注册细节 +- 本轮主线程决策: + - 新增 `GFramework.Cqrs/Extensions/NotificationPublisherRegistrationExtensions.cs`,提供 `UseNotificationPublisher(...)`、`UseNotificationPublisher()` 与 `UseTaskWhenAllNotificationPublisher()` 三个显式组合根入口 + - 在 `GFramework.Cqrs.Tests/Cqrs/NotificationPublisherRegistrationExtensionsTests.cs` 补齐回归,确认默认 runtime 基础设施会复用 `UseTaskWhenAllNotificationPublisher()`,且重复策略注册会在组合根阶段被显式阻止 + - 更新 `GFramework.Cqrs/README.md` 与 `docs/zh-CN/core/cqrs.md`,把推荐用法改成组合根扩展,并把 `RP-114` 的 benchmark 结论翻译成用户可用的采用边界 +- 本轮权威验证: + - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~NotificationPublisherRegistrationExtensionsTests|FullyQualifiedName~CqrsNotificationPublisherTests"` + - 结果:通过,`9/9` passed + - `python3 scripts/license-header.py --check --paths GFramework.Cqrs/Extensions/NotificationPublisherRegistrationExtensions.cs GFramework.Cqrs.Tests/Cqrs/NotificationPublisherRegistrationExtensionsTests.cs GFramework.Cqrs/README.md docs/zh-CN/core/cqrs.md ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` + - 结果:通过 + - `git diff --check` + - 结果:通过 +- 本轮结论: + - 这一批已把 notification publisher 的采用路径从“理解内部 seam”收口成“在组合根里显式选择策略”,并让重复策略注册在配置阶段就得到清晰失败信号 + - 若后续仍继续 notification 线,更合理的下一刀会是补第二个内置策略或更细的采用文档,而不是继续要求用户手写容器底层注册 + +### 阶段:`TaskWhenAll` notification publisher fan-out benchmark(CQRS-REWRITE-RP-114) + +- 延续 `$gframework-batch-boot 50`,本轮不再扩新的 notification runtime 能力,而是沿着 `RP-113` 刚落地的内置并行 publisher 继续补验证口径: + - 当前分支相对 `origin/main`(`7ca21af9`, `2026-05-08 16:12:20 +0800`)的累计 branch diff 启动时为 `9 files`,明显低于 `50` 文件阈值 + - `RP-112` 只量化了默认顺序发布器的 fixed `4 handler` fan-out 成本;`RP-113` 已把 `TaskWhenAllNotificationPublisher` 引入 production runtime,但还没有 benchmark 说明“能力差距收口后,代价是多少” +- 本轮主线程决策: + - 在 `GFramework.Cqrs.Benchmarks/Messaging/NotificationFanOutBenchmarks.cs` 同时保留 `baseline`、默认顺序 `GFramework.Cqrs`、内置 `TaskWhenAllNotificationPublisher`、NuGet `Mediator` concrete runtime 与 `MediatR` 五组对照 + - 复用同一个冻结 `MicrosoftDiContainer` 创建两个 `ICqrsRuntime`,确保变量集中在 notification publisher 策略,而不是 handler 注册或容器形状差异 + - 更新 `GFramework.Cqrs.Benchmarks/README.md` 与 active tracking,使默认恢复入口直接记录新的 benchmark 口径 +- 本轮权威验证: + - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*NotificationFanOutBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:fixed `4 handler` fan-out 对照当前约为 baseline `7.424 ns / 0 B`、`Mediator` `3.854 ns / 0 B`、`MediatR` `225.940 ns / 1256 B`、`GFramework.Cqrs` 默认顺序发布器 `427.453 ns / 408 B`、内置 `TaskWhenAllNotificationPublisher` `472.574 ns / 496 B` + - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/NotificationFanOutBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` + - 结果:通过 + - `git diff --check` + - 结果:通过 +- 本轮结论: + - 当前 benchmark 说明 `TaskWhenAllNotificationPublisher` 的主要价值是补齐“等待全部处理器并聚合异常”的 notification 语义,而不是在 fixed `4 handler` fan-out steady-state 下带来吞吐收益;它比默认顺序发布器额外增加了约 `45 ns` 与 `88 B` + - 这组结果足以支持后续把 notification 线的重心转回 API 配置面、使用边界与文档语义,而不是继续机械堆新的 runtime seam 或期待 `TaskWhenAll` 自带性能红利 + - 当前 turn 仍可继续自动推进,但默认停止规则仍以“上下文预算优先、单批可评审边界次之”为准 + +### 阶段:内置 `TaskWhenAll` notification publisher(CQRS-REWRITE-RP-113) + +- 延续 `$gframework-batch-boot 50`,本轮不再继续堆 notification benchmark 维度,而是直接把上一批已经量化清楚的 capability gap 收口到 runtime: + - `RP-111` / `RP-112` 已证明当前 notification publish 无论单处理器还是固定 fan-out,都和 `Mediator` 的 publish strategy 能力差距相关,而不只是“缺 benchmark” + - 当前分支相对 `origin/main` 的累计 branch diff 仍明显低于 `50` 文件阈值,因此适合用一个单模块、可回归、可文档化的能力切片继续自动推进 +- 本轮主线程决策: + - 新增 `GFramework.Cqrs/Notification/TaskWhenAllNotificationPublisher.cs`,提供公开内置并行 notification publisher,并把“同步抛出的处理器异常也收敛到返回任务中”作为实现约束 + - 在 `GFramework.Cqrs.Tests/Cqrs/CqrsNotificationPublisherTests.cs` 补齐针对新策略的回归,确认它不会像默认顺序发布器那样在首个失败处停止其余处理器 + - 更新 `GFramework.Cqrs/README.md` 与 `docs/zh-CN/core/cqrs.md`,写明切换方式,以及“不保证顺序 / 等待全部处理器完成 / 统一暴露异常或取消结果”的采用边界 +- 本轮权威验证: + - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsNotificationPublisherTests"` + - 结果:通过 + - `python3 scripts/license-header.py --check --paths GFramework.Cqrs/Notification/TaskWhenAllNotificationPublisher.cs GFramework.Cqrs.Tests/Cqrs/CqrsNotificationPublisherTests.cs GFramework.Cqrs/README.md docs/zh-CN/core/cqrs.md` + - 结果:通过 + - `git diff --check` + - 结果:通过 +- 本轮结论: + - `GFramework.Cqrs` 现在不再只有“自定义 seam”这一种 notification publisher 扩展方式,而是先提供了一个仓库维护的内置并行策略,开始实质缩小和 `Mediator` 在 publisher strategy 上的能力差距 + - 这批改动保持默认顺序语义不变,因此风险主要落在“新策略的异常聚合和用户理解边界”,已通过测试和文档同步收口 + - 当前可以继续自动推进,但更合理的下一批应优先补新策略的 benchmark 或继续评估 notification publisher 配置面,而不是回头重复扩更多 fan-out benchmark + +### 阶段:notification fan-out publish benchmark(CQRS-REWRITE-RP-112) + +- 延续 `$gframework-batch-boot 50`,本轮没有直接切入 notification runtime 或 publisher strategy,而是先补齐固定 `4 handler` 的 fan-out publish 对照: + - `RP-111` 已量化单处理器 notification publish,但还缺“同一路径在固定多处理器 fan-out 时是否保持同级差距”的事实 + - 继续机械扩充 `HandlerCount` 参数矩阵会把 `Mediator` compile-time 处理器集合、MediatR 扫描过滤与 benchmark 注册变量混在一起;固定 `4 handler` 场景更容易保持三方对照口径稳定 +- 本轮主线程决策: + - 新增 `GFramework.Cqrs.Benchmarks/Messaging/NotificationFanOutBenchmarks.cs`,固定 4 个 handler,比对 baseline、`GFramework.Cqrs`、NuGet `Mediator` concrete runtime 与 `MediatR` 的 publish 开销 + - 让 baseline 直接顺序调用 4 个 handler,避免把 fan-out 的额外调用成本误归因为框架 dispatch 自身 + - 更新 `GFramework.Cqrs.Benchmarks/README.md`,明确 notification benchmark 现在同时覆盖单处理器与固定 4 处理器 fan-out 场景 +- 本轮权威验证: + - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*NotificationFanOutBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:历史基线(`RP-112`)固定 `4 handler` notification fan-out 对照约为 baseline `8.302 ns / 0 B`、`Mediator` `4.314 ns / 0 B`、`MediatR` `230.304 ns / 1256 B`、`GFramework.Cqrs` `434.413 ns / 408 B` + - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/NotificationFanOutBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md` + - 结果:通过 + - `git diff --check` + - 结果:通过 + - 备注:仅剩 `GFramework.sln` 的历史 CRLF 提示,无本轮新增 diff 格式问题 +- 本轮结论: + - notification 路径现在已同时具备“单处理器 publish”与“固定 4 处理器 fan-out publish”两条三方对照基线,足以支撑后续是否值得切进 publisher strategy 或 runtime 热点 + - 当前更有价值的下一步不是继续横向堆更多 fan-out 场景,而是转向 publisher strategy / 异常语义,或回到 request dispatch 常量开销这类更可能产生真实运行时收益的切片 + - 在 branch diff 仍明显低于阈值时可以继续自动推进,但应把“上下文预算接近约 80%”继续视为优先停止信号 + +### 阶段:notification publish 补齐 `Mediator` concrete runtime 对照(CQRS-REWRITE-RP-111) + +- 延续 `$gframework-batch-boot 50`,本轮重新按 skill 规则复核 branch diff 基线与容量: + - `origin/main` = `7ca21af9`,提交时间 `2026-05-08 16:12:20 +0800` + - 本地 `main` = `c2d22285`,已落后于 remote-tracking ref,因此不作为本轮 baseline + - 当前分支 `feat/cqrs-optimization` 与 `origin/main` 的累计 branch diff 为 `0 files / 0 lines` + - 当前工作树干净,且上一个自然批次 `RP-110` 已并入 `origin/main`;因此本轮不是“续做未提交热路径”,而是基于 active topic 重新选择下一块低风险 CQRS benchmark 切片 +- 本轮接受的只读探索结论: + - `NotificationBenchmarks` 仍停留在 `GFramework.Cqrs` vs `MediatR` 的双方对照,缺少 request steady-state 已具备的 `Mediator` concrete runtime 高性能参照物 + - 对 notification 路径直接补 generated invoker/provider 的性价比不高:dispatcher 当前对 notification 反射委托已按消息类型弱缓存,steady-state publish 的主要差距不在“每次都反射” + - 因此本轮更高信号、边界更清晰的切片是先补 benchmark 对照口径,而不是为了对称性新增一层 runtime seam +- 本轮主线程决策: + - 在 `GFramework.Cqrs.Benchmarks/Messaging/NotificationBenchmarks.cs` 新增 `Mediator` concrete runtime 宿主、`PublishNotification_Mediator()` benchmark 方法,以及对应的 `Mediator.INotification` / `Mediator.INotificationHandler` 合同实现 + - 保持现有 `GFramework.Cqrs` 与 `MediatR` notification publish 路径不变,只扩充对照组,确保这批仍然是单模块、低风险、可直接评审的 benchmark 收口 + - 更新 `GFramework.Cqrs.Benchmarks/README.md` 与 active tracking,使 notification 场景的公开说明和恢复入口都反映新的三方对照事实 +- 本轮权威验证: + - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*NotificationBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:notification publish 三方对照当前约为 `Mediator` `1.108 ns / 0 B`、`MediatR` `97.173 ns / 416 B`、`GFramework.Cqrs` `291.582 ns / 392 B` + - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/NotificationBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md` + - 结果:通过 + - `git diff --check` + - 结果:通过 + - 备注:仅剩 `GFramework.sln` 的历史 CRLF 提示,无本轮新增 diff 格式问题 +- 本轮结论: + - notification 场景现在也拥有了与 request steady-state 对称的 `Mediator` concrete runtime 参照物,后续再讨论 `notification publisher` 策略或 runtime 热点时,不再只能拿 `MediatR` 做外部对照 + - 当前最值得保留的结论不是“立刻给 notification 也上 generated invoker/provider”,而是 `GFramework.Cqrs` 单处理器 publish 相对 `Mediator` 与 `MediatR` 的量级差距已经被量化出来,可为后续是否继续压 notification 路径提供依据 + - 本轮到这里属于新的自然批次边界;下一轮若继续沿用 `$gframework-batch-boot 50`,更适合从多处理器 publish / publisher strategy 或更高价值的 request 常量开销热点里再选一块,而不是在同一 turn 里继续堆 notification 基准扩展 + +### 阶段:PR #341 latest-head review 尾声收口(CQRS-REWRITE-RP-110) + +- 再次使用 `$gframework-pr-review` 抓取 `PR #341` latest-head review,确认当前 open thread 已收敛到: + - `BenchmarkHostFactory.cs` 的 legacy runtime alias 防守式类型检查 thread,但当前 head 已存在 `RegisterLegacyRuntimeAlias(...)` 的显式类型校验与实际类型信息异常,属于 GitHub 未 resolve 的 stale thread + - `RequestBenchmarks.cs` / `CqrsDispatcher.cs` 的 Greptile thread,对应“程序集级 registry 扩散”与“faulted ValueTask 失败语义”均已在当前 head 修复,属于 stale thread + - 仍然成立且值得当前收口的只剩 `CqrsDispatcherContextValidationTests.cs` 的 strict mock 脆弱性,以及本 trace 中 `本轮下一步` 与 `本轮权威验证` 重复的问题 +- 本轮主线程决策: + - 为 `SendAsync_Should_Return_Faulted_ValueTask_When_Handler_Is_Missing()` 补齐 `HasRegistration(...)` 与 `GetAll(...)` 的防御性 mock,降低该测试对 dispatcher 内部检查顺序的隐式耦合 + - 删除 `RP-109` 记录中重复 `本轮权威验证` 的 `本轮下一步` 段落,保持默认恢复入口只保留仍有价值的恢复信息 +- 本轮权威验证: + - `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --format json --json-output /tmp/current-pr-review.json` + - 结果:通过 + - 备注:确认当前分支对应 `PR #341`;latest-head 当前仍显示 `CodeRabbit 2` / `Greptile 2` open thread,但其中运行时/benchmark 两条已在本地失效 + - `dotnet build GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - 备注:并行验证首轮曾因 `build` 与 `test` 同时写入同一输出 DLL 触发 `MSB3026` 单次复制重试;改为串行重跑同一命令后稳定通过 + - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsDispatcherContextValidationTests"` + - 结果:通过,`6/6` passed + - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherContextValidationTests.cs` + - 结果:通过 + - `git diff --check` + - 结果:通过 + - 备注:仅剩 `GFramework.sln` 的历史 CRLF 提示,无本轮新增 diff 格式问题 + +### 阶段:PR #341 latest-head review 收口(CQRS-REWRITE-RP-109) + +- 使用 `$gframework-pr-review` 抓取 `feat/cqrs-optimization` 当前公开 PR,并确认当前锚点已从 `PR #340` 更新为 `PR #341` +- 本轮 latest-head review 结论: + - `CodeRabbit` 仍有 `BenchmarkHostFactory.cs` 的 legacy runtime 硬转型、`StreamLifetimeBenchmarks.cs` 的注释缺口,以及 `.agents/skills/gframework-batch-boot/SKILL.md` 的 `MD005` 缩进问题 + - `Greptile` 指出的两条仍然成立:benchmark 项目里通过 `RegisterCqrsHandlersFromAssembly(typeof(...).Assembly)` 会把同程序集的其他 generated registry 一并激活,扩大 benchmark 宿主的服务索引基线;`CqrsDispatcher.SendAsync(...)` 直接去掉 `async/await` 后也把原本的 faulted-`ValueTask` 失败语义改成了同步抛出 +- 本轮主线程决策: + - 在 `GFramework.Cqrs.Internal.CqrsHandlerRegistrar` 新增 direct generated-registry 激活入口,并通过 `InternalsVisibleTo` 暴露给 `GFramework.Cqrs.Benchmarks`,让 benchmark 宿主只激活当前场景的 generated registry + - 把 `RequestBenchmarks`、`RequestPipelineBenchmarks`、`StreamingBenchmarks`、`StreamLifetimeBenchmarks` 以及 request/stream invoker benchmark 的 generated 宿主全部切到定向 registry 接线,避免同程序集其他 registry 扩大冻结索引和 descriptor 预热基线 + - 在 `BenchmarkHostFactory` 里用防守式类型检查注册 legacy runtime alias,并补充 stream lifetime runtime 二次创建的注释 + - 让 `CqrsDispatcher.SendAsync(...)` 通过 `ValueTask.FromException(...)` 恢复旧的 faulted-`ValueTask` 失败语义,同时保留成功路径的 direct-return 热路径 + - 补齐 `CqrsGeneratedRequestInvokerProviderTests` 与 `CqrsDispatcherContextValidationTests` 的 targeted 回归,并顺手修正 batch boot skill 的 markdown 缩进 +- 本轮权威验证: + - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` + - 结果:通过,`1 warning / 0 error` + - 备注:仅出现 `MSB3026` 单次复制重试告警,随后成功产出 `net10.0` 目标;未出现编译失败或新增代码警告 + - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsDispatcherContextValidationTests|FullyQualifiedName~CqrsGeneratedRequestInvokerProviderTests"` + - 结果:通过,`24/24` passed + - 备注:首轮并行验证时因与 build 同时运行触发 MSBuild 输出文件锁竞争;改为串行重跑同一命令后稳定通过 + - `python3 scripts/license-header.py --check --paths GFramework.Cqrs/Properties/AssemblyInfo.cs GFramework.Cqrs/Internal/CqrsHandlerRegistrar.cs GFramework.Cqrs/Internal/CqrsDispatcher.cs GFramework.Cqrs.Benchmarks/Messaging/BenchmarkHostFactory.cs GFramework.Cqrs.Benchmarks/Messaging/RequestBenchmarks.cs GFramework.Cqrs.Benchmarks/Messaging/RequestPipelineBenchmarks.cs GFramework.Cqrs.Benchmarks/Messaging/StreamingBenchmarks.cs GFramework.Cqrs.Benchmarks/Messaging/StreamLifetimeBenchmarks.cs GFramework.Cqrs.Benchmarks/Messaging/RequestInvokerBenchmarks.cs GFramework.Cqrs.Benchmarks/Messaging/StreamInvokerBenchmarks.cs GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherContextValidationTests.cs GFramework.Cqrs.Tests/Cqrs/CqrsGeneratedRequestInvokerProviderTests.cs` + - 结果:通过 + - 备注:仓库脚本默认内部调用未绑定 worktree 的 `git ls-files`,因此本轮按修改文件列表显式 `--paths` 校验 + - `git diff --check` + - 结果:通过 + +### 阶段:stream handler 生命周期矩阵 benchmark(CQRS-REWRITE-RP-108) + +- 延续 `$gframework-batch-boot 50`,本轮继续使用 `origin/main` 作为 branch diff 基线,并先复核: + - `origin/main` = `4d6dbba6`,提交时间 `2026-05-08 11:13:33 +0800` + - 当前分支 `feat/cqrs-optimization` 相对 `origin/main` 的累计 branch diff 为 `14 files / 507 lines` + - 当前 turn 虽然仍低于 `50 files` 阈值,但已加载多轮 recovery / benchmark 输出;因此只允许再推进一个单模块、低风险 benchmark 切片 +- 本轮接受的只读探索结论: + - `RequestLifetimeBenchmarks` 已覆盖 request 的 `Singleton / Transient` 生命周期矩阵,但 stream 侧仍缺少对称的 handler 生命周期对照 + - `StreamingBenchmarks` 已在 `RP-107` 切到 generated-provider 宿主,适合作为 stream 生命周期矩阵的宿主基础;继续退回纯反射路径会让“生命周期变量”和“descriptor 路径变量”混在一起 + - 如果让 generated registry 顺手注册默认单例 handler,会破坏生命周期矩阵的变量控制,因此 registry 只能暴露 descriptor,不能抢先锁死 handler 生命周期 +- 本轮主线程决策: + - 新增 `StreamLifetimeBenchmarks`,对齐 request 生命周期矩阵,只比较 `Singleton / Transient` 两档,继续明确把 `Scoped` 留给未来显式 scoped host + - 新增 `GeneratedStreamLifetimeBenchmarkRegistry`,只提供 handwritten generated stream invoker descriptor,不直接注册 handler + - 让 `StreamLifetimeBenchmarks` 使用 `RegisterCqrsHandlersFromAssembly(typeof(StreamLifetimeBenchmarks).Assembly)` 建立 generated-provider 宿主,再显式按 benchmark 参数注册 `Singleton / Transient` handler 生命周期 + - 更新 `GFramework.Cqrs.Benchmarks/README.md`,把 stream 生命周期矩阵列为已覆盖场景,并从“后续扩展方向”里移除这项待办 +- 本轮验证过程的重要补充: + - 首次并行触发 `RequestBenchmarks` / `RequestLifetimeBenchmarks` / `StreamLifetimeBenchmarks` 时,在同一 autogenerated BenchmarkDotNet 目录下复现了文件已存在冲突与 bootstrap 异常;这是 benchmark 基础设施层面的并行目录竞争,不是代码缺陷 + - 改为串行重跑后三组 benchmark 全部稳定通过,因此本轮将“BenchmarkDotNet 在当前仓库里不应并行运行多条 `dotnet run --project ... --filter ...` 会话”视为有效执行约束 +- 本轮权威验证: + - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/GeneratedStreamLifetimeBenchmarkRegistry.cs GFramework.Cqrs.Benchmarks/Messaging/StreamLifetimeBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md` + - 结果:通过 + - `git diff --check` + - 结果:通过 + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:steady-state request 对照约为 baseline `5.336 ns / 32 B`、`Mediator` `5.564 ns / 32 B`、`MediatR` `53.307 ns / 232 B`、`GFramework.Cqrs` `64.745 ns / 32 B` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:`Singleton` 下 baseline / `MediatR` / `GFramework.Cqrs` 约 `4.309 ns / 51.923 ns / 67.981 ns`;`Transient` 下约 `5.029 ns / 54.435 ns / 76.437 ns` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*StreamLifetimeBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:`Singleton` 下 baseline / `GFramework.Cqrs` / `MediatR` 约 `80.144 ns / 137.515 ns / 229.242 ns`,`Transient` 下约 `77.198 ns / 144.998 ns / 228.185 ns` +- 本轮结论: + - stream 生命周期矩阵现在已与 request 生命周期矩阵对称,且继续沿用 generated-provider 宿主路径,没有把变量退化回纯反射 binding + - `GFramework.Cqrs` 在 stream `Singleton / Transient` 两档下都明显快于 `MediatR`,同时保持接近 baseline 的分配规模;`Transient` 仅从 `240 B` 小幅增至 `264 B` + - 真正的停止依据仍是上下文预算安全。虽然 branch diff 只有 `14 files`,但当前 turn 已包含多轮 benchmark 输出和恢复文档,因此本批提交后应主动停止 + - 下一轮若继续性能线,更值得优先看 notification publish 或更高价值的 request 常量开销热点,而不是继续做同层级 benchmark 宿主补齐 + +### 阶段:默认 stream benchmark 吸收 generated provider 宿主(CQRS-REWRITE-RP-107) + +- 延续 `$gframework-batch-boot 50`,但本轮按用户新增要求把默认停止依据改为“AI 上下文预算优先,建议在预计接近约 80% 安全上下文占用前收口”;在真正落代码前先复核: + - `origin/main` = `4d6dbba6`,提交时间 `2026-05-08 11:13:33 +0800` + - 当前分支 `feat/cqrs-optimization` 相对 `origin/main` 的累计 branch diff 为 `10 files / 507 lines` + - 当前 turn 已加载 `AGENTS.md`、`gframework-batch-boot` / `gframework-boot`、active tracking/trace、上一轮 benchmark 结果与多次 validation 输出,因此继续一个自然批次可以接受,但不应在本次提交后继续无界循环 +- 本轮接受的只读探索结论: + - 默认 request / request pipeline 宿主都已吸收 generated provider,但 `StreamingBenchmarks` 仍停在“直接注册单个 stream handler”的旧宿主路径,口径与 `StreamInvokerBenchmarks` / 默认 request 组不对称 + - 默认 stream steady-state 场景已经足够独立,适合用一份新的 handwritten generated stream registry 最小化收口,而不用再修改 runtime 语义 + - 用户要求把停止条件从 changed files 改成 AI 上下文预算,因此 skill 文档本身也属于这一批必须一起落下的恢复边界更新 +- 本轮主线程决策: + - 新增 `GeneratedDefaultStreamingBenchmarkRegistry`,用 handwritten generated registry + `ICqrsStreamInvokerProvider` + `IEnumeratesCqrsStreamInvokerDescriptors` 为 `StreamingBenchmarks.BenchmarkStreamRequest` 提供真实的 generated stream invoker descriptor + - 让 `StreamingBenchmarks` 改用 `RegisterCqrsHandlersFromAssembly(typeof(StreamingBenchmarks).Assembly)` 建容器,并在 `Setup/Cleanup` 前后显式清理 dispatcher 静态缓存 + - 更新 `GFramework.Cqrs.Benchmarks/README.md`,明确默认 stream steady-state benchmark 也已接上 handwritten generated stream invoker provider + - 更新 `.agents/skills/gframework-batch-boot/SKILL.md` 与 `.agents/skills/gframework-boot/SKILL.md`,明确“上下文预算接近约 80% 时优先停止,branch diff 文件/行数只作次级仓库范围信号” +- 本轮权威验证: + - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/GeneratedDefaultStreamingBenchmarkRegistry.cs GFramework.Cqrs.Benchmarks/Messaging/StreamingBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md` + - 结果:通过 + - `git diff --check` + - 结果:通过 + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:steady-state request 对照约为 baseline `5.608 ns / 32 B`、`Mediator` `5.445 ns / 32 B`、`MediatR` `57.071 ns / 232 B`、`GFramework.Cqrs` `64.825 ns / 32 B` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:`Singleton` 下 baseline / `MediatR` / `GFramework.Cqrs` 约 `4.446 ns / 51.331 ns / 69.275 ns`;`Transient` 下约 `4.918 ns / 56.382 ns / 74.301 ns` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*StreamingBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:默认 stream steady-state 对照约为 baseline `5.535 ns / 32 B`、`MediatR` `59.499 ns / 232 B`、`GFramework.Cqrs` `66.778 ns / 32 B` +- 本轮结论: + - 默认 stream steady-state benchmark 现在也已切到 generated-provider 宿主路径,request / pipeline / stream 三个默认宿主场景的 benchmark 口径终于对齐 + - `StreamingBenchmarks` 的 `GFramework.Cqrs` 结果约 `66.778 ns / 32 B`,仍慢于 `MediatR`,但没有新增分配或明显回退,说明这次宿主收口是低风险可接受的 + - 更重要的是,默认停止依据已从“branch diff 文件数是否触顶”改成“AI 上下文预算是否接近约 80%”;结合当前 turn 已加载的大量 recovery/validation/benchmark 输出,本次提交后应主动停止,而不是继续机械扩批 + - 下一轮若继续性能线,应从 `RP-107` 恢复点重新进入,并优先挑选新的高价值热点族,而不是沿着当前 turn 再追加更多同类宿主收口 + +### 阶段:request pipeline benchmark 吸收 generated provider 宿主(CQRS-REWRITE-RP-106) + +- 延续 `$gframework-batch-boot 50`,本轮基于 `RP-105` 已验证的默认 request 宿主接线继续推进,并先复核 branch diff 基线: + - `origin/main` = `4d6dbba6`,提交时间 `2026-05-08 11:13:33 +0800` + - 当前分支 `feat/cqrs-optimization` 相对 `origin/main` 的累计 branch diff 为 `8 files / 358 lines` + - 当前工作树待提交改动只集中在 `RequestPipelineBenchmarks`、对应 handwritten generated registry 与 benchmark `README`,因此继续自动推进下一批 pipeline 宿主收口 +- 本轮接受的只读探索结论: + - `RP-105` 已证明“让默认 request 宿主真实接上 generated request invoker provider”能稳定压低 steady-state request,因此 pipeline benchmark 仍保留旧的“直接注册单个 handler”路径会让口径不对齐 + - 之前已被 benchmark 否决的“总是 `GetAll(Type)` 做零 pipeline 探测”不应回头重试;下一刀更合理的是把 pipeline benchmark 也切到真实程序集注册入口 + - `RequestPipelineBenchmarks` 只需要补一份与 `RequestBenchmarks` 对称的 handwritten generated registry,就能最小化改动并保持 runtime 语义不变 +- 本轮主线程决策: + - 新增 `GeneratedRequestPipelineBenchmarkRegistry`,用 handwritten generated registry + `ICqrsRequestInvokerProvider` + `IEnumeratesCqrsRequestInvokerDescriptors` 为 `RequestPipelineBenchmarks.BenchmarkRequest` 提供真实的 generated request invoker descriptor + - 让 `RequestPipelineBenchmarks` 改用 `RegisterCqrsHandlersFromAssembly(typeof(RequestPipelineBenchmarks).Assembly)` 建容器,只把 pipeline 行为数量矩阵保留在 benchmark 自己的显式注册里 + - 更新 `GFramework.Cqrs.Benchmarks/README.md`,明确 request pipeline benchmark 也已接上 handwritten generated request invoker provider +- 本轮权威验证: + - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/GeneratedRequestPipelineBenchmarkRegistry.cs GFramework.Cqrs.Benchmarks/Messaging/RequestPipelineBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md` + - 结果:通过 + - `git diff --check` + - 结果:通过 + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:steady-state request 对照约为 baseline `5.680 ns / 32 B`、`Mediator` `6.565 ns / 32 B`、`MediatR` `54.737 ns / 232 B`、`GFramework.Cqrs` `63.644 ns / 32 B` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:`Singleton` 下 `GFramework.Cqrs` / `MediatR` 约 `69.896 ns / 32 B` vs `57.469 ns / 232 B`;`Transient` 下约 `72.880 ns / 56 B` vs `55.106 ns / 232 B` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestPipelineBenchmarks.SendRequest_GFrameworkCqrs*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:第一次短跑为 `PipelineCount=0` `64.928 ns / 32 B`、`PipelineCount=1` `366.468 ns / 536 B`、`PipelineCount=4` `547.800 ns / 896 B` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestPipelineBenchmarks.SendRequest_GFrameworkCqrs*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:复跑确认后为 `PipelineCount=0` `64.755 ns / 32 B`、`PipelineCount=1` `353.141 ns / 536 B`、`PipelineCount=4` `555.083 ns / 896 B` +- 本轮结论: + - request pipeline benchmark 现在已与默认 request steady-state 使用同一条 generated-provider 宿主接线路径,后续再看 `0 / 1 / 4` 行为矩阵时不再混入“默认 request 已吸收 generated invoker,而 pipeline 还停在纯反射宿主”的口径偏差 + - `0 pipeline` steady-state 继续下探到约 `64.755 ns / 32 B`,与 `RP-105` 的默认 request benchmark 收敛方向一致,说明这条宿主接线收益能稳定复用到 pipeline benchmark + - `1 pipeline` 与 `4 pipeline` 结果在当前 short job 配置下存在噪音,但没有出现清晰的新增分配或显著退化;因此本轮适合作为低风险宿主收口批次接受 + - 下一批若继续沿用 `$gframework-batch-boot 50`,应优先查看 request lifetime、stream 或 notification benchmark 中是否还存在未吸收 generated-provider 宿主收益的对称切片,而不是回头重试已被 benchmark 否决的 runtime 微优化 + +### 阶段:默认 request benchmark 吸收 generated provider 宿主(CQRS-REWRITE-RP-105) + +- 延续 `$gframework-batch-boot 50`,本轮先确认失败试验已手工回退回 `RP-104` 的已验证状态,再重新评估“默认 request 路径继续逼近 source-generated `Mediator`”的下一刀 +- 本轮接受的只读探索结论: + - 继续在 `CqrsDispatcher` 或 `MicrosoftDiContainer` 上堆叠同层级微优化的性价比已经下降,而且上一轮“总是 `GetAll(Type)`”的试验已被 benchmark 明确否决 + - 默认 `RequestBenchmarks` 虽然已包含 `Mediator` 对照,但当前 GFramework 组仍只注册了单个 handler 实例,没有走 `RegisterCqrsHandlersFromAssembly(...)` + generated registry/provider 的真实宿主接线路径 + - `RequestInvokerBenchmarks` 已证明 generated request invoker provider 路径比纯反射 binding 更接近目标,因此下一批最小切片应先把这条收益吸收到默认 steady-state request benchmark +- 本轮主线程决策: + - 在 `BenchmarkHostFactory` 内补齐 benchmark 最小宿主的 CQRS 基础设施预接线:runtime、legacy alias、registrar、registration service + - 新增 `GeneratedDefaultRequestBenchmarkRegistry`,用 handwritten generated registry + `ICqrsRequestInvokerProvider` + `IEnumeratesCqrsRequestInvokerDescriptors` 为 `RequestBenchmarks.BenchmarkRequest` 提供真实的 generated request invoker descriptor + - 让 `RequestBenchmarks` 改用 `RegisterCqrsHandlersFromAssembly(typeof(RequestBenchmarks).Assembly)` 建容器,并在 `Setup/Cleanup` 前后显式清理 dispatcher 静态缓存,避免前一组 benchmark 污染默认 request steady-state 结果 +- 本轮权威验证: + - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/GeneratedDefaultRequestBenchmarkRegistry.cs GFramework.Cqrs.Benchmarks/Messaging/BenchmarkHostFactory.cs GFramework.Cqrs.Benchmarks/Messaging/RequestBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md` + - 结果:通过 + - `git diff --check` + - 结果:通过 + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:steady-state request 对照约为 baseline `5.013 ns / 32 B`、`Mediator` `5.747 ns / 32 B`、`MediatR` `51.588 ns / 232 B`、`GFramework.Cqrs` `65.296 ns / 32 B` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:`Singleton` 下 `GFramework.Cqrs` / `MediatR` 约 `68.772 ns / 32 B` vs `48.177 ns / 232 B`;`Transient` 下约 `73.157 ns / 56 B` vs `51.753 ns / 232 B` +- 本轮结论: + - 默认 request benchmark 现在终于测到了“默认宿主已吸收 generated request invoker provider”后的真实 steady-state,而不再只是纯反射 request binding + - 这条宿主层收口在不改 runtime 语义的前提下,把 `GFramework.Cqrs` steady-state request 从约 `70.298 ns` 再压到约 `65.296 ns` + - lifetime 矩阵也同步改善到 `68.772 ns / 73.157 ns`,说明默认 request 宿主吸收 generated provider 不只是 benchmark 口径变化,而是对常见 handler 生命周期也有稳定收益 + - 下一批若继续沿用 `$gframework-batch-boot 50`,应优先转向 pipeline 路径或 handler 解析热路径中仍未吸收 generated/provider 收益的常量开销,而不是回头重试已被否决的 `GetAll(Type)` 零行为探测方案 + +### 阶段:request 热路径继续收口(CQRS-REWRITE-RP-104) + +- 延续 `$gframework-batch-boot 50`,本轮先重新按 `origin/main` 复核 branch diff 基线: + - `origin/main` = `4d6dbba6`,提交时间 `2026-05-08 11:13:33 +0800` + - 当前分支 `feat/cqrs-optimization` 相对 `origin/main` 的累计 branch diff 仍为 `0 files / 0 lines` + - 当前工作树在真正落代码前只有活跃文档更新,仍明显低于 `$gframework-batch-boot 50` 的文件阈值,因此继续自动推进下一批 request 热路径收口 +- 本轮接受的只读探索结论: + - `RequestBenchmarks` / `RequestInvokerBenchmarks` 的下一个低风险热点仍在“每次发送都必经的容器查询与短生命周期对象创建”,不是重新回到更高风险的语义层重构 + - 候选优先级排序为:`SendAsync` 自身状态机开销、`HasRegistration + GetAll` / 服务键扫描,以及 pipeline continuation 的临时对象 +- 本轮主线程决策: + - 先以最小行为改动切第一刀:把 `CqrsDispatcher.SendAsync(...)` 从 `async/await` 改为 direct-return `ValueTask`,让零 pipeline request 常见路径不再为 dispatcher 自身生成额外状态机 + - 在第一刀验证通过且 benchmark 明显改善后,再切第二刀:让 `MicrosoftDiContainer.HasRegistration(Type)` 在冻结后复用预构建的服务键索引,而不是每次线性扫描全部 `ServiceDescriptor` + - 第二刀完成后停止继续叠第三刀,因为当前批次已经能清晰区分“有效收益”和“无回退但收益不明显”的因果,不再为了追逐更小常量开销降低评审清晰度 +- 本轮权威验证: + - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~MicrosoftDiContainerTests"` + - 结果:通过,`52/52` passed + - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~CqrsDispatcherCacheTests|FullyQualifiedName~CqrsDispatcherContextValidationTests"` + - 结果:通过,`14/14` passed + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:最新 steady-state request 对照约为 baseline `6.141 ns / 32 B`、`Mediator` `6.674 ns / 32 B`、`MediatR` `61.803 ns / 232 B`、`GFramework.Cqrs` `70.298 ns / 32 B` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:最新 lifetime request 对照约为 `Singleton` 下 baseline / `MediatR` / `GFramework.Cqrs` = `4.706 ns / 52.197 ns / 73.005 ns`,`Transient` 下 = `4.571 ns / 50.175 ns / 74.757 ns` + - `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` + - 结果:通过 + - `git diff --check` + - 结果:通过 + - 备注:仍仅有 `GFramework.sln` 的历史 CRLF 警告,无本轮新增格式问题 +- 本轮结论: + - 第一刀有效:`CqrsDispatcher.SendAsync(...)` 的 direct-return `ValueTask` 把 `GFramework.Cqrs` steady-state request 从 `RP-103` 记录的约 `83.823 ns` 压到约 `70.298 ns` + - 第二刀保守有效:冻结后 `HasRegistration(Type)` 索引化没有带来同量级的可见收益,但也没有造成功能回退、额外分配或测试破坏 + - 下一批若继续压 request hot path,应优先评估默认 request 路径吸收 generated invoker/provider,而不是继续围绕同层级容器存在性判断做微调 + +### 阶段:PR #340 latest-head review 收口(CQRS-REWRITE-RP-103) + +- 使用 `$gframework-pr-review` 抓取 `feat/cqrs-optimization` 当前公开 PR,并确认当前锚点已从 `PR #339` 更新为 `PR #340` +- 本轮 latest-head review 结论: + - `CodeRabbit` 当前显示 `2` 个 nitpick / open thread,`Greptile` 显示 `2` 个 open thread;`MegaLinter` 仍只有 `dotnet-format restore` 环境噪音 + - `CTRF` 当前显示 `2321` 项测试中 `1` 项失败,失败用例为 `CreateStream_Should_Throw_When_Stream_Pipeline_Behavior_Context_Does_Not_Implement_IArchitectureContext` + - 失败原因不是业务断言退化,而是 `CqrsDispatcher` 新增 `HasRegistration(Type)` fast-path 后,严格 mock 的上下文校验测试没有同步配置该调用,导致在命中上下文注入失败断言前先抛出 `Moq.MockException` + - `MicrosoftDiContainer.HasRegistration(Type)` 当前实现用 `requestedType.IsAssignableFrom(registeredServiceType)` 判断命中,会把“仅以实现类型自身注册”的服务误判成接口服务键也已注册,这与 `Get(Type)` / `GetAll(Type)` 的服务键语义不一致,属于仍成立的运行时缺陷 + - `IIocContainer.HasRegistration(Type)` XML 文档缺少异常契约;`docs/zh-CN/core/ioc.md` 也还未解释该新公开入口的用途与语义边界;`BenchmarkHostFactory` / `RequestBenchmarks` 中仍残留旧 `ai-libs/Mediator` 注释或隐式共享 handler 合同,属于仍成立的文档/维护性问题 +- 本轮主线程决策: + - 在 `CqrsDispatcherContextValidationTests` 为受影响的 request / stream pipeline mock 显式补 `HasRegistration(Type)` 配置,确保上下文失败语义测试不会被 strict mock 噪音短路 + - 把 `MicrosoftDiContainer.CanSatisfyServiceType(...)` 收窄为“服务键完全命中”或“开放泛型服务键可闭合到目标类型”,并新增回归覆盖“仅按具体实现类型自注册时,接口服务键应返回 false” + - 为 `IIocContainer.HasRegistration(Type)` 补 `` / ``,并在 `docs/zh-CN/core/ioc.md` 新增用户接入说明,明确该入口按服务键而不是按可赋值关系判断可见性 + - 更新 benchmark 相关注释到 NuGet `Mediator` 语义,并为 `BenchmarkRequestHandler` 增补显式 `Mediator.IRequestHandler<,>` 实现,降低未来升级时的契约漂移诊断成本 +- 本轮权威验证: + - `dotnet build GFramework.Core.Abstractions/GFramework.Core.Abstractions.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet build GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~MicrosoftDiContainerTests"` + - 结果:通过,`52/52` passed + - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~CqrsDispatcherContextValidationTests"` + - 结果:通过,`4/4` passed + - `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` + - 结果:通过 + - `git diff --check` + - 结果:通过 + - 备注:仅剩 `GFramework.sln` 的历史 CRLF 警告,无本轮新增格式问题 +- 下一步: + - 关注 `PR #340` 重新索引后的 latest-head open thread 是否随本轮提交自然收敛,尤其是 `HasRegistration(Type)` 相关 runtime / docs 线程 + - 若后续继续压 request hot path,可从 `CqrsDispatcher` 默认 request 路径与 generated invoker/provider 的进一步吸收空间继续下钻 + +### 阶段:性能回归门槛收紧与 benchmark 产物忽略收口(CQRS-REWRITE-RP-102) + +- 延续 `RP-101` 后的 benchmark 基线,本轮没有继续改 runtime 热路径,而是先把性能治理规则补齐,避免后续优化波次出现“功能通过但 steady-state request 变慢”的回退 +- 本轮主线程决策: + - 将 `BenchmarkDotNet.Artifacts/` 加入仓库 `.gitignore`,避免本地 benchmark 生成目录反复污染工作树 + - 在 `GFramework.Cqrs.Benchmarks/README.md` 明确写下新的默认回归门槛:只要改动触达 request dispatch、DI 热路径、invoker/provider、pipeline 或 benchmark 宿主,就必须至少复跑 `RequestBenchmarks.SendRequest_*` 与 `RequestLifetimeBenchmarks.SendRequest_*` + - 在 `cqrs-rewrite` active tracking 中把当前阶段目标升级为“持续逼近 source-generated `Mediator`,并至少稳定超过反射版 `MediatR`”,不再只把 benchmark 当成观察工具,而是作为性能收口阶段的验收门槛 +- 本轮权威验证: + - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:按新门槛复跑后,steady-state request 对照约为 baseline `5.300 ns / 32 B`、`Mediator` `4.964 ns / 32 B`、`MediatR` `57.993 ns / 232 B`、`GFramework.Cqrs` `83.823 ns / 32 B` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:按新门槛复跑后,`Singleton` 下 `GFramework.Cqrs` / `MediatR` 约 `83.183 ns / 32 B` vs `60.915 ns / 232 B`;`Transient` 下约 `86.243 ns / 56 B` vs `59.644 ns / 232 B` + - `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` + - 结果:通过 + - `git diff --check` + - 结果:通过 +- 本轮结论: + - `BenchmarkDotNet.Artifacts/` 现在不再是工作树噪音源 + - request benchmark 已从“偶尔人工观察”升级为 CQRS 性能波次的默认回归门槛 + - 当前离“至少超过反射版 `MediatR`”还有明确差距,所以下一批优化必须围绕 request steady-state 常量开销继续下钻,而不是只增加更多 benchmark 维度 + +### 阶段:request 热路径 benchmark 收口与 NuGet `Mediator` 对照补齐(CQRS-REWRITE-RP-101) + +- 延续 `$gframework-batch-boot 50`,本轮先按 `origin/main` 复核 branch diff 基线: + - `origin/main` = `5dc2dd25`,提交时间 `2026-05-08 09:08:37 +0800` + - 当前分支 `feat/cqrs-optimization` 相对 `origin/main` 的累计 branch diff 仍为 `0 files / 0 lines` + - 当前工作树仅新增 9 个跟踪文件修改,另有 `BenchmarkDotNet.Artifacts/` 本地生成输出未纳入提交范围,仍明显低于 `$gframework-batch-boot 50` 的文件阈值 +- 用户新增的 benchmark 诉求有两部分: + - 解释 `BenchmarkDotNet.Artifacts/results` 里为什么 `GFramework.Cqrs` request 路径表现显著差于对照组 + - 把 `martinothamar/Mediator` 加入 benchmark 对照,但必须使用官方 NuGet 包,不允许接本地 `ai-libs/Mediator` project reference +- 本轮主线程先回到 runtime hot path 与 benchmark 宿主做最小成本排查,确认旧坏值的两个主要根因: + - `CqrsDispatcher.SendAsync(...)` / `CreateStream(...)` 在 `0 pipeline` 场景下仍无条件执行 `container.GetAll(dispatchBinding.BehaviorType)`,即使根本没有行为注册,也会多走一次容器解析与空集合分配 + - `MicrosoftDiContainer.Get(Type)` / `GetAll()` / `GetAll(Type)` 在 debug logging 关闭时仍会先构造日志字符串,导致 benchmark 默认 `Fatal` 级别下仍持续产生无效分配 +- 本轮主线程决策: + - 为 `IIocContainer` 新增不激活实例的 `HasRegistration(Type)`,并由 `MicrosoftDiContainer` 提供支持开放泛型匹配的非激活查询实现 + - 让 `CqrsDispatcher` 在 request / stream 的 `0 pipeline` 场景先走 `HasRegistration(...)` fast-path;没有行为注册时直接调用已准备好的 request / stream invoker,不再解析空行为列表 + - 为 `MicrosoftDiContainer` 的热路径查询补 `IsDebugEnabled()` 守卫,避免 benchmark 常态配置下的无效日志字符串构造 + - 在 benchmark 项目中通过 NuGet 接入 `Mediator.Abstractions` 与 `Mediator.SourceGenerator` `3.0.2`,并让 `RequestBenchmarks` 使用 source-generated concrete `Mediator.Mediator` 作为新对照组 + - 保持 `ai-libs/Mediator` 只作为本地源码 / README 参考资料,不参与编译或项目引用 +- 本轮新增 / 更新的验证与回归覆盖: + - `GFramework.Core.Tests/Ioc/MicrosoftDiContainerTests.cs` 新增 `HasRegistration(...)` 回归,覆盖“无匹配注册返回 false”与“开放泛型注册可满足封闭请求行为类型”两个分支 + - `GFramework.Cqrs.Benchmarks/Messaging/RequestBenchmarks.cs` 现在同时对照 baseline / `Mediator` / `MediatR` / `GFramework.Cqrs` + - `GFramework.Cqrs.Benchmarks/Messaging/BenchmarkHostFactory.cs` 新增 `CreateMediatorServiceProvider(...)`,统一最小宿主构建方式 +- 本轮权威验证: + - `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~MicrosoftDiContainerTests"` + - 结果:通过,`51/51` passed + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:steady-state request 对照约为 baseline `5.969 ns / 32 B`、`Mediator` `6.242 ns / 32 B`、`MediatR` `53.818 ns / 232 B`、`GFramework.Cqrs` `85.504 ns / 32 B` + - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:`Singleton` 下 `GFramework.Cqrs` 从旧值 `301.731 ns / 440 B` 收敛到 `84.066 ns / 32 B`;`Transient` 下从旧值 `287.863 ns / 464 B` 收敛到 `90.652 ns / 56 B` +- 本轮结论: + - `GFramework.Cqrs` 之前“垫底很多”的主要原因不是抽象层级本身,而是 request 热路径残留了两个可避免的分配热点:空 pipeline 解析与禁用日志下的字符串构造 + - 收口后,`GFramework.Cqrs` 仍慢于 `MediatR` 与 source-generated `Mediator`,但已经去掉了旧 benchmark 中最明显的异常分配和 300ns 级退化 + - 下一批若继续沿用 `$gframework-batch-boot 50` 压 request steady-state,最值得优先评估的是让默认 request 路径进一步吸收 generated invoker/provider 的收益,而不是继续扩大更多横向对照项 + +## 2026-05-07 + +### 阶段:PR #339 stream pipeline seam review 收口(CQRS-REWRITE-RP-100) + +- 使用 `$gframework-pr-review` 抓取 `feat/cqrs-optimization` 当前公开 PR,并确认已从历史 `PR #334` 进入新的 `PR #339` +- 本轮 latest-head review 结论: + - `CodeRabbit` 当前显示 `2` 个 open thread 与 `2` 个 nitpick,失败检查为 `0`,GitHub Test Reporter 汇总仍为全绿 + - `GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherCacheTests.cs` 的 test-name 拼写 thread 已在当前 head 失效,本地代码已经是 `Per_Behavior_Count` + - `GFramework.Core.Abstractions/Ioc/IIocContainer.cs` 的 `RegisterCqrsStreamPipelineBehavior()` 仍缺 `` / `` 契约说明,属于仍成立的文档缺口 + - `GFramework.Cqrs/Internal/CqrsDispatcher.cs` 的 `StreamPipelineInvocation.GetContinuation(...)` 缺少 request 对称路径已有的线程模型说明,属于仍成立的并发语义文档缺口 + - `GFramework.Core/Ioc/MicrosoftDiContainer.cs` 的 request / stream CQRS 行为注册逻辑完全重复,属于仍成立的维护性问题 +- 本轮主线程决策: + - 在 `IIocContainer` 补齐流式行为注册入口的 `` / ``,并把相同契约补到 `IArchitecture`、`Architecture` 与 `ArchitectureModules`,避免公开入口文档漂移 + - 为 `StreamPipelineInvocation.GetContinuation(...)` 补齐“仅假定单次建流链顺序推进;并发 `next()` 时可能重复创建等价 continuation,但不会跨建流共享实例”的说明 + - 在 `MicrosoftDiContainer` 抽取 `RegisterCqrsPipelineBehaviorCore(...)`,统一 request / stream 行为注册的开放泛型、封闭接口枚举、错误消息与日志路径 + - 顺手修复 `dotnet format` 在当前 branch diff 内实际命中的 `GFramework.Cqrs/ICqrsRequestInvokerProvider.cs` XML 缩进问题;不处理未触达历史文件上的 `CHARSET` 提示 +- 本轮权威验证: + - `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --json-output /tmp/current-pr-review.json` + - 结果:通过 + - `dotnet format GFramework.Cqrs/GFramework.Cqrs.csproj --verify-no-changes` + - 结果:发现当前 diff 内 `GFramework.Cqrs/ICqrsRequestInvokerProvider.cs` 的空白格式问题;其余 `CHARSET` 提示集中在未触达的历史文件 + - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet build GFramework.Core.Abstractions/GFramework.Core.Abstractions.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~CqrsDispatcherCacheTests"` + - 结果:通过,`10/10` passed + - `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~ArchitectureModulesBehaviorTests"` + - 结果:通过,`4/4` passed + - `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` + - 结果:通过 + - `git diff --check` + - 结果:通过 + +### 阶段:stream pipeline seam 收口(CQRS-REWRITE-RP-099) + +- 延续 `$gframework-batch-boot 50`,主线程先按 `origin/main` 评估 branch diff 容量,并在 `stream pipeline` 与 `notification publisher` 两个独立切片中选择更贴近 active gap 的下一批目标 +- 只读 subagent 结论已被接受: + - `notification publisher` 已有稳定 seam、默认顺序实现与专门回归,缺口主要在“更多内置策略” + - `stream pipeline` 仍缺独立 contract、注册入口与 runtime executor,对应缺口在 public docs 与 active tracking 中都已显式列出 +- 本轮主线程决策: + - 为 `GFramework.Cqrs.Abstractions` 新增 `IStreamPipelineBehavior<,>` 与 `StreamMessageHandlerDelegate<,>` + - 为 `IIocContainer`、`IArchitecture`、`Architecture`、`ArchitectureModules` 与 `MicrosoftDiContainer` 新增 `RegisterCqrsStreamPipelineBehavior()` + - 为 `CqrsDispatcher` 的 `CreateStream(...)` 路径补齐 stream behavior 解析、上下文注入,以及按 behaviorCount 缓存的 stream pipeline executor 形状 + - 保持语义边界清晰:本轮 stream pipeline 只包裹单次 `CreateStream(...)` 建流,不扩展到每个元素的逐项 middleware 语义 + - 让 generated stream invoker provider 与 stream pipeline seam 共存,并补齐“generated invoker 仍命中、行为链仍生效”的回归 +- 本轮新增 / 更新的测试方向: + - `CqrsDispatcherCacheTests`:stream pipeline executor 缓存、顺序稳定性、上下文重新注入 + - `CqrsDispatcherContextValidationTests`:stream behavior 需要 `IArchitectureContext` 时的显式失败语义 + - `CqrsGeneratedRequestInvokerProviderTests`:generated stream invoker 与 stream behavior 并存时仍优先消费 generated descriptor + - `ArchitectureModulesBehaviorTests`:公开 `RegisterCqrsStreamPipelineBehavior()` 冒烟回归 +- 文档收口: + - `GFramework.Cqrs/README.md` 现在显式说明 stream behavior 的建流级作用域 + - `docs/zh-CN/core/cqrs.md` 现在区分 request pipeline 与 stream pipeline 两个注册入口,并从“仍缺 stream pipeline seam”的能力差距列表中移除该项 +- 当前立即下一步: + - 运行 `GFramework.Cqrs` / `GFramework.Cqrs.Tests` / `GFramework.Core.Tests` 的 Release build 与 targeted tests + - 刷新 `origin/main...HEAD` 的 branch diff files / lines 指标 + - 若验证通过,再补 license / diff check 与自动提交 +- 本轮权威验证: + - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet build GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet build GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~CqrsDispatcherCacheTests|FullyQualifiedName~CqrsGeneratedRequestInvokerProviderTests|FullyQualifiedName~CqrsDispatcherContextValidationTests"` + - 结果:通过,`31/31` passed + - `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~ArchitectureModulesBehaviorTests"` + - 结果:通过,`4/4` passed + - `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` + - 结果:通过 + - `git diff --check` + - 结果:通过 + - `origin/main...HEAD` + - 结果:`0 files / 0 lines` + +### 阶段:PR #334 latest-head helper 异常边界收口(CQRS-REWRITE-RP-098) + +- 再次使用 `$gframework-pr-review` 抓取 `feat/cqrs-optimization` 对应的 `PR #334` latest-head review,并重新核对 `/tmp/current-pr-review.json` 中最新 open thread: + - 当前公开 PR 仍为 `PR #334` + - `CodeRabbit` 最新 review 在 `2026-05-07T12:20:24Z` 为 `APPROVED` + - latest-head 当前显示 `CodeRabbit 10` / `Greptile 5` 个 open thread +- 本轮逐条回到本地代码后,确认大多数 open thread 仍是 stale 状态;唯一继续成立的问题集中在 `LegacyCqrsDispatchHelper.TryResolveDispatchContext(...)`: + - 该 helper 之前会把 `IContextAware.GetContext()` 抛出的任意 `InvalidOperationException` 都吞掉并回退到 legacy 直执行 + - 这会把真实运行时故障误判为“上下文未就绪”,导致 bridge 路径悄悄绕过统一 runtime,退化为难以诊断的行为差异 +- 本轮主线程决策: + - 将异常过滤收窄为只接受两类缺上下文信号:`Architecture context has not been set...` 与 `No active architecture context is currently bound.` + - 其他 `InvalidOperationException` 一律继续向上传播,避免掩盖容器、生命周期或自定义 `GetContext()` 内的真实错误 + - 在 `CommandExecutorTests` 中新增两条回归:一条验证缺上下文时仍会 fallback 到 legacy 直执行;一条验证意外 `InvalidOperationException` 不会被 bridge 逻辑静默吞掉 + - 同步刷新 `cqrs-rewrite` active tracking,把本轮修复记录为新的恢复锚点 `RP-098` +- 本轮权威验证: + - `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --json-output /tmp/current-pr-review.json` + - 结果:通过 + - `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet build GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~CommandExecutorTests|FullyQualifiedName~QueryExecutorTests"` + - 结果:通过,`25/25` passed + - `python3 scripts/license-header.py --check` + - 结果:通过 + - `git diff --check` + - 结果:通过 + +### 阶段:PR #334 nitpick 测试收尾(CQRS-REWRITE-RP-097) + +- 继续处理 `PR #334` latest-head review 中仍值得本地吸收的轻量 nitpick,范围限定在 legacy bridge 测试可观察性与测试替身诊断质量: + - `AsyncQueryExecutorTests.SendAsync_Should_Bridge_Through_Runtime_And_Preserve_Context` 标题声明“保留上下文”,但此前只断言了返回值与 bridge request 类型 + - `CommandExecutorTests.Send_WithResult_Should_Bridge_Through_Runtime_And_Preserve_Context` 同样缺少可观察的上下文注入断言 + - `RecordingCqrsRuntime` 直接强转响应对象,若测试工厂回错类型,失败信息不够聚焦 +- 本轮主线程决策: + - 为两个 “Preserve_Context” 用例补齐 `ObservedContext` 与 `expectedContext` 的同一实例断言,使测试标题、注释与断言对象保持一致 + - 让 `RecordingCqrsRuntime` 通过私有 helper 显式执行响应类型还原;当工厂返回 `null` 或错误装箱类型时,抛出包含 request 类型与期望/实际响应类型的 `InvalidOperationException` + - 同步刷新 `cqrs-rewrite` active tracking,把本轮 nitpick 收敛与验证结果记录为新的恢复锚点 `RP-097` +- 本轮权威验证: + - `dotnet build GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~CommandExecutorTests|FullyQualifiedName~AsyncQueryExecutorTests"` + - 结果:通过,`19/19` passed + - `python3 scripts/license-header.py --check` + - 结果:通过 + - `git diff --check` + - 结果:通过 + +### 阶段:PR #334 latest-head review 复核(CQRS-REWRITE-RP-096) + +- 再次使用 `$gframework-pr-review` 抓取 `feat/cqrs-optimization` 对应的 `PR #334` latest-head review,并读取 `/tmp/current-pr-review.json` 中的 `review_agents`、`latest_commit_review`、`megalinter_report` 与 `test_reports` +- 本轮复核结论: + - 当前公开 PR 为 `PR #334`,head commit 为 `dc3bd3744e2ceaa557ef03bc991fc88daedb460b` + - `CodeRabbit` latest review 在 `2026-05-07T11:46:42Z` 已是 `APPROVED`,但 latest-head 仍显示 `10` 个 open thread;`Greptile` 仍显示 `3` 个 open thread + - 逐条回到本地代码后,相关修复已在当前分支落地:`ArchitectureBootstrapper` 已自动扫描 `typeof(ArchitectureContext).Assembly`;`ArchitectureContextTests` / `ArchitectureModulesBehaviorTests` 已标注 `NonParallelizable` 并保证资源释放;`LegacyAsync*DispatchRequestHandler` 已统一补 `ThrowIfCancellationRequested()` + `WaitAsync(cancellationToken)`;`QueryExecutor` / legacy bridge request XML 文档与 `docs/zh-CN/core/command.md` fallback 说明也已齐备 + - 远端 CTRF 最新测试汇总为 `2311/2311 passed`(run `#1079`),`MegaLinter` 仅剩 `dotnet-format` restore failed 的环境噪音,没有新的文件级诊断 +- 主线程决策: + - 不再为这些 stale open thread 追加新的本地代码改动,避免重复修补已吸收的问题 + - 仅更新 `cqrs-rewrite` active tracking/trace,把“当前剩余差异主要是 GitHub thread 状态滞后”记录为最新权威事实 +- 本轮权威验证: + - `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --format json --json-output /tmp/current-pr-review.json` + - 结果:通过 + - `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + +### 阶段:PR #334 legacy bridge sync follow-up(CQRS-REWRITE-RP-095) + +- 再次使用 `$gframework-pr-review` 抓取 `feat/cqrs-optimization` 对应的 `PR #334` latest-head review,并只保留本地复核后仍成立的问题: + - `QueryExecutor` / `CommandExecutor` 新增的同步 bridge 仍直接阻塞 `ICqrsRuntime.SendAsync(...)`,在调用方存在 `SynchronizationContext` 时容易放大 sync-over-async 死锁面 + - `QueryExecutor` / `CommandExecutor` / `AsyncQueryExecutor` 各自保留一份相同的 dispatch-context 解析逻辑,仍有漂移风险 + - `ArchitectureContextTests` 的 bridge fixture 依然共享静态 tracker 且未显式声明非并行;冻结容器所有权也未交还给调用方释放 + - `LegacyAsyncCommandDispatchRequestHandler` 仍未沿用另两个 async bridge handler 的取消可见性模式 +- 本轮主线程决策: + - 新增 `GFramework.Core/Cqrs/LegacyCqrsDispatchHelper.cs`,统一收口 legacy bridge 的 dispatch-context 解析,以及同步 bridge 对 `ICqrsRuntime.SendAsync(...)` 的线程池隔离等待 + - 将 `QueryExecutor`、`CommandExecutor`、`AsyncQueryExecutor` 的重复 helper 改为复用共享 helper,并把 `ArchitectureContext` 的同步 CQRS 包装入口一并切换到同一阻塞策略,避免留下半修状态 + - 为 `ICqrsRuntime.SendAsync(...)` 补充 ``,显式说明 legacy 同步入口会在后台线程上等待该异步契约,处理链路不应依赖调用方 `SynchronizationContext` + - 把 `ArchitectureContextTests`、`ArchitectureModulesBehaviorTests` 标记为 `NonParallelizable`,并让 `CreateFrozenBridgeContext(...)` 把冻结容器通过 `out` 参数返还给每个测试在 `finally` 中释放 + - 为 `LegacyAsyncCommandDispatchRequestHandler` 增补 `ThrowIfCancellationRequested()` + `WaitAsync(cancellationToken)`,与另外两个 async bridge handler 保持一致 + - 新增回归测试覆盖同步 bridge 的 `SynchronizationContext` 隔离、legacy async command handler 的取消语义,以及 async/sync bridge request 的 request-type 命中 +- 本轮权威验证: + - `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` + - 结果:通过 + - `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~ArchitectureContextTests|FullyQualifiedName~ArchitectureModulesBehaviorTests|FullyQualifiedName~CommandExecutorTests|FullyQualifiedName~QueryExecutorTests|FullyQualifiedName~AsyncQueryExecutorTests|FullyQualifiedName~LegacyAsyncCommandDispatchRequestHandlerTests"` + - 结果:通过,`54/54` passed + +### 阶段:PR #334 legacy bridge / 文档 review 收尾(CQRS-REWRITE-RP-094) + +- 使用 `$gframework-pr-review` 抓取当前分支公开 PR,确认 `feat/cqrs-optimization` 当前对应 `PR #334` +- latest-head open AI review 复核后,主线程接受并执行的修复集中在六类: + - `GFramework.Core.Tests/Architectures/ArchitectureContextTests.cs` 通过字符串字面量反射实例化内部 bridge handler,维护成本高且不利于 rename-safe 重构 + - `ArchitectureModulesBehaviorTests` 在断言失败路径下未保证 `DestroyAsync()` 执行,且 `TearDown` 未重置 `LegacyBridgePipelineTracker` + - `LegacyBridgePipelineTracker` 以静态共享计数器记录 bridge pipeline 命中,但未文档化线程安全语义,且用字符串匹配类型名识别 bridge request + - `LegacyAsyncQueryDispatchRequestHandler` / `LegacyAsyncCommandResultDispatchRequestHandler` 丢弃了 runtime 传入的 `CancellationToken` + - `CommandExecutorModule` / `QueryExecutorModule` / `AsyncQueryExecutorModule` 依赖 `container.Get()` 的隐式注册顺序,但此前既未显式失败,也未写进 API 契约 + - 多个 legacy bridge request / docs 页面仍缺 XML 文档或回退边界说明 +- 本轮主线程决策: + - 为 `GFramework.Core` 新增 `Properties/AssemblyInfo.cs`,用 `InternalsVisibleTo("GFramework.Core.Tests")` 让测试直接实例化内部 handler + - 把 `ArchitectureContextTests.RegisterLegacyBridgeHandlers` 改成显式构造 6 个 handler,移除字符串反射装配 + - 为 bridge 相关测试补 `TearDown` 清理和 `try/finally` 销毁,减少失败路径资源泄露 + - 为 `LegacyBridgePipelineTracker` 增补 ``,并改用 `typeof(LegacyCqrsDispatchRequestBase).IsAssignableFrom(requestType)` 识别 bridge request + - 为 `LegacyAsyncQueryDispatchRequestHandler` / `LegacyAsyncCommandResultDispatchRequestHandler` 加入预取消检查与 `WaitAsync(cancellationToken)` + - 将三个 executor module 改为 `GetRequired()`,同时在 XML 文档中显式声明 `CqrsRuntimeModule` 的前置注册约束 + - 为 `CommandExecutor` / `QueryExecutor` / `AsyncQueryExecutor` 的 dispatch-context helper 增加 `[MemberNotNullWhen]`,收敛重复 `_runtime is not null` 判空与 null-forgiving + - 补齐 legacy bridge request / handler 的 XML 文档,以及 `docs/zh-CN/core/command.md`、`context.md` 的 fallback 边界说明 +- 本轮没有跟进的 thread: + - `GFramework.Cqrs.Benchmarks/Messaging/RequestLifetimeBenchmarks.cs` 的 `sealed` 建议属于低价值性能/风格提示,不影响 `PR #334` 的行为正确性 + - 若 review 在 GitHub 重新索引前仍显示旧 thread,下一轮以最新 head commit 再次抓取为准,不在本地重复造改动 +- 本轮权威验证: + - `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + - `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~ArchitectureContextTests|FullyQualifiedName~ArchitectureModulesBehaviorTests|FullyQualifiedName~CommandExecutorTests|FullyQualifiedName~QueryExecutorTests|FullyQualifiedName~AsyncQueryExecutorTests"` + - 结果:通过,`48/48` passed + - `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` + - 结果:通过 + - `git diff --check` + - 结果:通过 + +### 阶段:legacy Core CQRS -> GFramework.Cqrs bridge(CQRS-REWRITE-RP-093) + +- 延续 `$gframework-batch-boot 50`,本轮明确不只盯 benchmark,而是同时处理两个目标: + - 复核 `ai-libs/Mediator` 还有哪些能力尚未被 `GFramework.Cqrs` 吸收 + - 验证 `GFramework.Core` 的简单 `Command` / `Query` 兼容入口能否在不改外部用法的前提下,底层统一改走 `GFramework.Cqrs` +- 主线程先完成 `GFramework.Core` bridge 实现收尾与测试修正: + - `ArchitectureContext` 的 legacy `SendCommand(...)` / `SendQuery(...)` / `SendQueryAsync(...)` 现在会创建内部 bridge request,并直接通过统一 `ICqrsRuntime` 分发 + - `CommandExecutor`、`QueryExecutor`、`AsyncQueryExecutor` 在解析到 runtime 且目标对象可提供架构上下文时,也会复用同一条 bridge/runtime 路径 + - 为避免破坏不依赖容器的旧测试,执行器仍保留“未接入 runtime 时直接执行”的回退语义 +- 新增 `GFramework.Core/Cqrs/Legacy*DispatchRequest*.cs` 与对应 handler,把 legacy 命令/查询包装成内部 request: + - bridge handler 在执行前会显式把当前 `IArchitectureContext` 注入给 `IContextAware` 目标 + - 这让旧调用链在不改 public API 的情况下,也能复用统一 pipeline 与 handler dispatch 语义 +- 生产接线结论已经本地复核: + - `CqrsRuntimeModule` 只注册 runtime / registrar / registration service,本身不直接手工注册 bridge handler + - 默认生产路径依赖 `ArchitectureBootstrapper.ConfigureServices(...)` 自动调用 `RegisterCqrsHandlersFromAssemblies([architectureType.Assembly, typeof(ArchitectureContext).Assembly])` + - 因此 `GFramework.Core` 程序集中的 internal bridge handler 会在标准架构初始化阶段自动被扫描和注册,不需要业务侧手工补注册 +- 为防止以后有人改坏默认扫描范围,本轮额外补了一条更接近真实启动路径的回归: + - `ArchitectureModulesBehaviorTests.InitializeAsync_Should_AutoRegister_LegacyBridgeHandlers_For_Default_Core_Assemblies` + - 该用例通过 `Architecture.Configurator` 注册 open-generic pipeline behavior,然后直接走 `Architecture.InitializeAsync()`,验证旧 `SendCommand` / `SendQuery` 兼容入口能命中统一 pipeline +- 只读 subagent 同步完成 `Mediator` 差距复核,接受的结论是六类未完全吸收能力: + - `IMediator` / `ISender` / `IPublisher` 风格 facade + - telemetry / tracing / metrics + - stream pipeline + - notification publisher 策略 + - 生成器配置与诊断公开面 + - 生命周期 / 缓存公开配置面 +- 文档与恢复入口同步更新: + - `docs/zh-CN/core/context.md`、`command.md`、`query.md`、`cqrs.md` + - `GFramework.Core/README.md` + - active tracking / trace 升级到 `RP-093` + +### 验证(RP-093) + +- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~ArchitectureContextTests|FullyQualifiedName~CommandExecutorTests|FullyQualifiedName~QueryExecutorTests|FullyQualifiedName~AsyncQueryExecutorTests"` + - 结果:通过,`45/45` passed +- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release` + - 结果:通过,`1644/1644` passed +- `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` + - 结果:通过 +- `git diff --check` + - 结果:通过 + +### 当前下一步(RP-093) + +1. 若继续沿用 `$gframework-batch-boot 50`,优先从 `stream pipeline` 或 `notification publisher` 策略中切一块对齐 `Mediator` +2. 若要继续收敛 public seam,下一批优先设计 facade,而不是继续扩大 `ArchitectureContext` 的兼容职责 + +### 阶段:request handler 生命周期矩阵 benchmark(CQRS-REWRITE-RP-092) + +- 使用 `$gframework-batch-boot 50` 启动本轮批次,并按技能要求先复核 `origin/main` 基线与 branch diff: + - `origin/main` = `2c58d8b6`,提交时间 `2026-05-07 13:24:46 +0800` + - 本地 `main` = `c2d22285`,已落后于 remote-tracking ref,因此不作为本轮 batch baseline + - 当前 `feat/cqrs-optimization` 相对 `origin/main` 的累计 branch diff 在开工前为 `0 files / 0 lines` +- 本轮批次目标:继续推进 `GFramework.Cqrs.Benchmarks`,补一个独立、低风险、可单项目 Release 验证的 request 生命周期对照切片 +- 主线程先复核现有 benchmark 宿主与 runtime 解析路径后确认: + - `RequestBenchmarks` 与 `StreamingBenchmarks` 当前都固定使用单根容器宿主 + - `MicrosoftDiContainer` 虽支持 `RegisterScoped` / `CreateScope()`,但当前 `CqrsDispatcher` 的 steady-state benchmark 路径直接从根容器解析 handler + - 因此若直接把 `Scoped` 注册加入现有 benchmark,会把“根作用域下的 scoped 解析”误当成公平对照,语义不成立 +- 本轮决策: + - 新增 `Messaging/RequestLifetimeBenchmarks.cs` + - 生命周期矩阵只覆盖 `Singleton / Transient` + - 在 XML 文档与 README 中显式注明:`Scoped` 需要等未来具备真实显式作用域边界的 benchmark host 后再比较 +- 已修改: + - `GFramework.Cqrs.Benchmarks/Messaging/RequestLifetimeBenchmarks.cs` + - `GFramework.Cqrs.Benchmarks/README.md` + - `ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md` + - `ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` +- 预期结果: + - `GFramework.Cqrs.Benchmarks` 不再只覆盖“有无 generated provider / startup / pipeline”的维度,也开始覆盖 request steady-state 下的 handler 生命周期成本差异 + - benchmark 设计继续保持“只加入语义公平的矩阵”,避免把作用域模型不对称的结论写进基线 + +### 验证(RP-092) + +- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestLifetimeBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过(沙箱外权威结果) + - 备注:当前 agent 沙箱内执行同一 benchmark 会在 BenchmarkDotNet 自动生成 bootstrap 阶段失败;切换到沙箱外后,`restore/build` 自举与 6 个 benchmark case 全部通过 + - 备注:`Singleton` 下 baseline / MediatR / GFramework 分别约 `5.633 ns / 58.687 ns / 301.731 ns` + - 备注:`Transient` 下 baseline / MediatR / GFramework 分别约 `5.044 ns / 52.274 ns / 287.863 ns` +- `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` + - 结果:通过 +- `git diff --check` + - 结果:通过 + +### 当前下一步(RP-092) + +1. 若 branch diff 仍明显低于 `$gframework-batch-boot 50` 阈值,下一批优先补 `stream handler` 生命周期矩阵,保持 request / stream benchmark 维度对称 +2. 若准备扩到 `Scoped` 生命周期,先为 benchmark host 设计真实显式作用域基线,再进入运行时对照 + +## 2026-05-06 + +### 阶段:PR #331 review 收尾补丁(CQRS-REWRITE-RP-091) + +- 使用 `$gframework-pr-review` 拉取当前分支 `fix/package-validation-guard` 对应的 `PR #331` latest-head review 后,主线程只保留本地复核仍成立的问题: + - `.github/workflows/ci.yml` 的 `dotnet pack` 步骤缺少 `--no-build`,会在已完成 solution `Build` 后重复编译整仓库 + - `scripts/validate-packed-modules.sh` 使用 GNU `find -printf`,在 macOS / BSD `find` 下无法运行 + - `ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md` 的 active PR 锚点仍写成 `待创建`,与当前公开 PR 状态不一致 +- 本轮决策: + - `ci.yml` 的 pack 步骤显式补上 `--no-build`,使其与前置 `Build` 步骤形成单次编译链路 + - 共享包校验脚本改为使用 `find ... -exec basename {} \;`,避免依赖 GNU-only 选项 + - active tracking 同步到 `PR #331`,并把这轮 PR review 的剩余问题描述更新为当前已核验的真实范围 +- 预期结果: + - PR workflow 的 pack 阶段不再对同一 solution 重复编译 + - `validate-packed-modules.sh` 可在 GNU / BSD `find` 环境下保持相同行为 + - `cqrs-rewrite` active 恢复入口继续与当前公开 PR 保持一致 + +### 阶段:benchmark 发布面隔离与包清单校验前移(CQRS-REWRITE-RP-091) + +- 针对 tag 发布中出现的 `GFramework.Cqrs.Benchmarks` 异常包名单,本轮先复核 benchmark 项目与 solution pack 的本地事实: + - `GFramework.Cqrs.Benchmarks.csproj` 已包含 `IsPackable=false` 与 `GeneratePackageOnBuild=false` + - 本地执行 `dotnet pack GFramework.sln -c Release --no-restore -o /tmp/gframework-sln-pack-probe -p:IncludeSymbols=false` 时,产物仅包含 14 个预期发布包 + - 因此本轮不把 benchmark 包加入发布白名单,而是把“benchmark 永不发布”与“PR 前置完整包名单校验”同时固化 +- 本轮决策: + - 为 `GFramework.Cqrs.Benchmarks` 补充注释,明确其 benchmark-only 的发布边界 + - 新增 `scripts/validate-packed-modules.sh`,集中维护预期包集合与实际 `.nupkg` diff 逻辑 + - `publish.yml` 改为调用共享脚本,避免发布工作流与 PR 工作流各自维护一份包名单 + - `ci.yml` 新增 solution `dotnet pack` 与 packed modules 校验,把异常发布包从 tag 发布前移到普通 PR 阶段 +- 预期结果: + - benchmark / example / tooling 一类新项目若意外进入发布面,会先在 PR 失败,而不是等到 tag 发布 + - 发布与 PR 使用同一份包名单规则,减少后续名单漂移 + - `GFramework.Cqrs.Benchmarks` 继续只服务于 benchmark workflow,不进入 NuGet / GitHub Packages + +### 阶段:benchmark 对照宿主收敛与 startup cold-start 恢复(CQRS-REWRITE-RP-090) + +- 使用 `$gframework-pr-review` 拉取 `PR #326` latest-head review 后,主线程确认仍有效的 benchmark 反馈集中在三类问题: + - `RequestBenchmarks` 的 GFramework / MediatR handler 生命周期不对齐 + - `RequestStartupBenchmarks` 把容器构建、程序集扫描范围和缓存清理阶段混在一起,导致 cold-start 对照不公平 + - benchmark 工程里的 `MicrosoftDiContainer` 多处以 `ImplementationType` 方式注册 handler,但未在 runtime 分发前 `Freeze()`,首次真实解析路径存在隐藏失败风险 +- 本轮本地复核的关键根因: + - `MicrosoftDiContainer.Get(Type)` 在未冻结时只读取 `ImplementationInstance`,不会实例化 `ImplementationType` + - `ColdStart_GFrameworkCqrs` 清空 dispatcher 静态缓存后,首次发送必须走真实 handler 解析,因此会稳定触发 `No CQRS request handler registered` + - 多个 benchmark 同时采用“手工 MediatR 注册 + `RegisterServicesFromAssembly(...)` 全程序集扫描”,容易把无关 handler / behavior 一并纳入对照,且存在重复注册漂移 +- 本轮决策: + - 新增 `Messaging/BenchmarkHostFactory.cs`,统一 benchmark 最小宿主构建规则 + - GFramework benchmark 宿主统一先注册再 `Freeze()`,保证 steady-state 与 cold-start 都走真实可解析容器 + - MediatR benchmark 宿主统一通过 `TypeEvaluator` 限制到当前场景所需 handler / behavior 类型,保留正常 `AddMediatR` 组装路径,同时移除全程序集扫描噪音 + - `RequestStartupBenchmarks` 采用专用 `ColdStart` job,设置 `InvocationCount=1` 与 `WithUnrollFactor(1)`,并把 dispatcher cache reset 放到 `IterationSetup` +- 已修改的 benchmark 范围: + - `RequestBenchmarks` + - `RequestPipelineBenchmarks` + - `RequestStartupBenchmarks` + - `StreamingBenchmarks` + - `NotificationBenchmarks` + - `RequestInvokerBenchmarks` + - `StreamInvokerBenchmarks` +- 结果: + - `ColdStart_GFrameworkCqrs` 已恢复出有效结果,不再出现 `No CQRS request handler registered` + - `RequestBenchmarks`、`RequestStartupBenchmarks` 在本地均可实际运行 + - `RequestStartupBenchmarks` 目前仍会收到 BenchmarkDotNet 对单次 cold-start 场景的 `MinIterationTime` 提示;这是测量形状带来的工具提示,不再是运行级失败 + +### 验证(RP-090) + +- `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --json-output /tmp/gframework-current-pr-review.json` + - 结果:通过 + - 备注:确认当前分支对应 `PR #326`,仍有效的 open AI feedback 集中在 benchmark 对照语义与 active 文档收敛 +- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestStartupBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:`ColdStart_GFrameworkCqrs` 已恢复,最新本地输出约 `220-292 us`,`ColdStart_MediatR` 约 `575-616 us` +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:通过 + - 备注:steady-state request 对照可正常运行,未再触发 MediatR 重复注册或 GFramework 首次解析失败 + +### 阶段:PR #326 review 收尾补丁(CQRS-REWRITE-RP-090) + +- 再次使用 `$gframework-pr-review` 复核 `PR #326` latest-head open threads 后,主线程确认本轮仍成立且适合在当前 PR 内收敛的问题集中在四类: + - `.github/workflows/benchmark.yml` 的 `benchmark_filter` 直接插值到 shell,存在 workflow_dispatch 输入注入风险 + - `RequestInvokerBenchmarks` 与 `StreamInvokerBenchmarks` 的 MediatR handler 生命周期仍为 `Singleton`,与 GFramework 反射 / generated 路径的 transient 语义不一致 + - `RequestPipelineBenchmarks` 未在场景切换前后清理 dispatcher 缓存,且四个空 pipeline behavior 类型仍使用非法的分号类声明 + - `ai-plan/public/cqrs-rewrite` active 文档仍保留旧失败结论与重复日期标题,和“active 入口只保留最新权威恢复点”的约束不一致 +- 本轮刻意未扩展处理的 review: + - `MicrosoftDiContainer` 的释放契约建议会扩大到核心 Ioc 接口与全仓库生命周期语义,不适合作为 benchmark review 顺手改动 + - `RequestStartupBenchmarks` 的“手工单点注册 vs 受限程序集扫描”差异目前属于有意保留的最小宿主模型,代码注释已明确该设计边界 +- 已修改: + - `.github/workflows/benchmark.yml` + - `GFramework.Cqrs.Benchmarks/Messaging/RequestInvokerBenchmarks.cs` + - `GFramework.Cqrs.Benchmarks/Messaging/RequestPipelineBenchmarks.cs` + - `GFramework.Cqrs.Benchmarks/Messaging/StreamInvokerBenchmarks.cs` + - `ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md` + - `ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` +- 预期结果: + - 手动 benchmark workflow 的过滤器输入不再直接参与 shell 解析 + - request / stream invoker 三路对照的 handler 生命周期重新回到同一基线 + - request pipeline benchmark 在 `0 / 1 / 4` 场景切换时不再复用旧 dispatcher cache + - active tracking / trace 更符合 boot 恢复入口所要求的“只保留最新权威结论”形状 + +## 2026-04-30 + +### 阶段:历史 PR #307 active 入口收敛(CQRS-REWRITE-RP-076) + +- 继续沿用 `$gframework-pr-review` 对 `PR #307` 做 latest-head triage,本轮只处理仍成立的 `ai-plan` 恢复入口问题 +- 主线程确认当前远端权威信号: + - 当时分支对应 `PR #307`,状态为 `OPEN` + - 远端 `CTRF` 最新汇总为 `2247/2247` passed + - `MegaLinter` 仅剩 `dotnet-format` 的 `Restore operation failed` 环境噪音 + - 仍未闭环的 review 重点集中在 `cqrs-rewrite` active tracking / trace 仍保留过多历史锚点,而非新的运行时代码缺陷 +- 本轮决策: + - 将 active tracking 收敛为单一恢复入口,只保留 `RP-076`、`PR #307`、活跃风险、最近权威验证与下一推荐步骤 + - 将 active trace 收敛为当前阶段的关键事实与决策,不再在默认恢复入口中保留 `RP-062` 之后的长阶段流水账 + - 新增 `archive/traces/cqrs-rewrite-history-rp062-through-rp076.md` 承接 `RP-062` 至 `RP-076` 的详细 trace 历史,保持旧阶段仍可追溯 + +### 验证(RP-076) + +- `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --format json --json-output ` + - 结果:通过 + - 备注:确认 `PR #307` 的当前 review 重点已收敛到 `ai-plan` 文档收尾 +- `dotnet build GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `dotnet test GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Does_Not_Emit_Stream_Invoker_Provider_Metadata_When_Runtime_Lacks_Stream_Provider_Interface|FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Does_Not_Emit_Stream_Invoker_Provider_Metadata_When_Runtime_Lacks_Stream_Descriptor_Enumerator|FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Does_Not_Emit_Stream_Invoker_Provider_Metadata_When_Runtime_Lacks_Stream_Descriptor_Type|FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Does_Not_Emit_Stream_Invoker_Provider_Metadata_When_Runtime_Lacks_Stream_Descriptor_Entry_Type|FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Emits_Stream_Invoker_Provider_Metadata_When_Runtime_Contract_Is_Available"` + - 结果:通过,`5/5` passed + +### 当前下一步(RP-076) + +1. 当时继续按 `PR #307` 的 latest-head review 收尾,优先保持 active tracking 与 active trace 的单一锚点一致 +2. 若继续推进代码切片,先复核 request 侧是否仍存在与 stream invoker gate 对称的生成合同遗漏 +3. 进入下一批前继续使用最小 Release build 或 targeted test 作为权威验证,避免把环境噪音误判为代码问题 + +## 2026-05-04 + +### 阶段:request invoker provider gate 对称回归(CQRS-REWRITE-RP-077) + +- 使用 `$gframework-batch-boot 25` 继续 `feat/cqrs-optimization` 的 CQRS 收口批次 +- 批次目标:在 branch diff 相对 `origin/main` 接近 `25` 个文件前,补齐低风险的 generator 合同回归切片 +- 本轮先确认当前 worktree 已无 `local-plan` 遗留恢复入口,随后转入 `cqrs-rewrite` 的 request / stream invoker provider gate 对称性复核 +- 结论: + - 生产代码已经同时检查 request provider、enumerator、descriptor 与 descriptor entry 四项 runtime 合同 + - request 侧测试只覆盖缺少 provider / enumerator,缺少 descriptor / descriptor entry 的回归覆盖落后于 stream 侧 +- 已补齐: + - `Does_Not_Emit_Request_Invoker_Provider_Metadata_When_Runtime_Lacks_Request_Descriptor_Type` + - `Does_Not_Emit_Request_Invoker_Provider_Metadata_When_Runtime_Lacks_Request_Descriptor_Entry_Type` + - source emission XML 文档同步说明 provider gate 依赖完整 descriptor / descriptor entry 合同 + +### 验证(RP-077) + +- `dotnet test GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Does_Not_Emit_Request_Invoker_Provider_Metadata_When_Runtime_Lacks_Request_Descriptor_Type|FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Does_Not_Emit_Request_Invoker_Provider_Metadata_When_Runtime_Lacks_Request_Descriptor_Entry_Type|FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Does_Not_Emit_Request_Invoker_Provider_Metadata_When_Runtime_Lacks_Request_Provider_Interface|FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Does_Not_Emit_Request_Invoker_Provider_Metadata_When_Runtime_Lacks_Request_Descriptor_Enumerator"` + - 结果:通过,`4/4` passed +- `dotnet build GFramework.Cqrs.SourceGenerators/GFramework.Cqrs.SourceGenerators.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `python3 scripts/license-header.py --check` + - 结果:通过 + - 备注:当前 WSL worktree 需要显式绑定 `GIT_DIR` / `GIT_WORK_TREE` 后运行,避免脚本内部 plain `git ls-files` 误判仓库上下文 +- `git diff --check` + - 结果:通过 + +### 当前下一步(RP-077) + +1. 继续使用 `origin/main` 作为 `$gframework-batch-boot 25` 的基线,复算 branch diff 后决定是否还能接下一批 +2. 若继续推进代码切片,优先查找 request / stream invoker provider runtime 合同之外的同类对称测试缺口 + +### 阶段:mixed fallback attribute usage 回归(CQRS-REWRITE-RP-078) + +- 继续沿用 `$gframework-batch-boot 25`,当前 branch diff 仍低于阈值 +- 复核 fallback metadata runtime contract 后确认: + - mixed fallback 在 runtime 允许多个 fallback attribute 实例时已有直接 `Type` + 字符串拆分回归 + - runtime 同时支持 `params Type[]` / `params string[]` 但不允许多个 fallback attribute 实例时,缺少锁定“整体回退到单个字符串 attribute”的回归 +- 已补齐: + - `Emits_String_Fallback_Metadata_For_Mixed_Fallback_When_Runtime_Disallows_Multiple_Fallback_Attributes` + - `ReplaceAttributeUsageForType` 测试辅助方法,用于构造 runtime attribute usage 变体而不复制大型 source fixture + +### 验证(RP-078) + +- `dotnet test GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Emits_String_Fallback_Metadata_For_Mixed_Fallback_When_Runtime_Disallows_Multiple_Fallback_Attributes"` + - 结果:通过,`1/1` passed +- `python3 scripts/license-header.py --check` + - 结果:通过 + - 备注:当前 WSL worktree 需要显式绑定 `GIT_DIR` / `GIT_WORK_TREE` 后运行 +- `git diff --check` + - 结果:通过 + +### 当前下一步(RP-078) + +1. 继续复算 branch diff vs `origin/main`,若仍低于 `25` 个文件可继续下一批 +2. 下一批优先查看 fallback metadata 与 generated invoker provider 之外是否还有同类 runtime contract gate 回归缺口 + +### 阶段:基础 generated registry contract gate 回归(CQRS-REWRITE-RP-079) + +- 继续沿用 `$gframework-batch-boot 25`,当前 branch diff 仍低于阈值 +- 复核 generator 基础启用条件后确认:缺少 `ICqrsHandlerRegistry` 时,runtime 不具备承载 generated registry 的基础接口合同,应整体跳过发射 +- 已补齐: + - `Does_Not_Generate_Registry_When_Runtime_Lacks_Handler_Registry_Interface` + +### 验证(RP-079) + +- `dotnet test GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Does_Not_Generate_Registry_When_Runtime_Lacks_Handler_Registry_Interface"` + - 结果:通过,`1/1` passed +- `python3 scripts/license-header.py --check` + - 结果:通过 + - 备注:当前 WSL worktree 需要显式绑定 `GIT_DIR` / `GIT_WORK_TREE` 后运行 +- `git diff --check` + - 结果:通过 + +### 当前下一步(RP-079) + +1. 继续复算 branch diff vs `origin/main`,若仍低于 `25` 个文件可继续下一批 +2. 下一批优先复核基础 generation gate 中其他必需 runtime contracts 是否也需要同类回归覆盖 + +### 阶段:基础 generated registry contract gate 扩展回归(CQRS-REWRITE-RP-080) + +- 将 `RP-079` 的单一 handler registry interface 缺失回归扩展为基础 generation gate 参数化测试 +- 已补齐缺失分支: + - `ICqrsHandlerRegistry` + - `INotificationHandler` + - `IStreamRequestHandler` + - `CqrsHandlerRegistryAttribute` +- stream handler interface 变体采用类型重命名构造 runtime metadata miss,避免删除命名空间尾部单行接口时引入输入编译错误 + +### 验证(RP-080) + +- `dotnet test GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Does_Not_Generate_Registry_When_Runtime_Lacks_Required_Generation_Contract"` + - 结果:通过,`4/4` passed +- `python3 scripts/license-header.py --check` + - 结果:通过 + - 备注:当前 WSL worktree 需要显式绑定 `GIT_DIR` / `GIT_WORK_TREE` 后运行 +- `git diff --check` + - 结果:通过 + +### 当前下一步(RP-080) + +1. 继续复算 branch diff vs `origin/main`,若仍低于 `25` 个文件可继续下一批 +2. 下一批优先复核基础 generation gate 中 logging / DI 依赖是否已有合适的输入编译安全回归覆盖方式 + +### 阶段:基础 generated registry external contract gate 回归(CQRS-REWRITE-RP-081) + +- 延续 `RP-080` 的参数化基础 generation gate 测试,将外部 logging / DI 依赖也纳入同一组静默跳过回归 +- 已补齐缺失分支: + - `GFramework.Core.Abstractions.Logging.ILogger` + - `Microsoft.Extensions.DependencyInjection.IServiceCollection` +- 两个变体均通过类型重命名构造 runtime metadata miss,保持输入源码可编译,避免把依赖缺失测试误写成编译失败测试 + +### 验证(RP-081) + +- `dotnet test GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Does_Not_Generate_Registry_When_Runtime_Lacks_Required_Generation_Contract"` + - 结果:通过,`6/6` passed +- `python3 scripts/license-header.py --check` + - 结果:通过 + - 备注:当前 WSL worktree 需要显式绑定 `GIT_DIR` / `GIT_WORK_TREE` 后运行 +- `git diff --check` + - 结果:通过 + +### 当前下一步(RP-081) + +1. 继续复算 branch diff vs `origin/main`,若仍低于 `25` 个文件可继续下一批 +2. 下一批优先复核基础 generation gate 中 request handler contract 与 handler registry attribute 以外是否还有可安全构造的缺失分支 + +### 阶段:基础 generated registry request handler gate 回归(CQRS-REWRITE-RP-082) + +- 延续 `RP-081` 的基础 generation gate 参数化测试,补齐 `IRequestHandler` 缺失分支 +- 该变体同样通过类型重命名构造 runtime metadata miss,保持输入源码可编译 +- 至此基础 generation gate 中可安全构造的缺失分支已覆盖: + - request handler interface + - notification handler interface + - stream handler interface + - handler registry interface + - handler registry attribute + - logging interface + - DI service collection interface + +### 验证(RP-082) + +- `dotnet test GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Does_Not_Generate_Registry_When_Runtime_Lacks_Required_Generation_Contract"` + - 结果:通过,`7/7` passed +- `python3 scripts/license-header.py --check` + - 结果:通过 + - 备注:当前 WSL worktree 需要显式绑定 `GIT_DIR` / `GIT_WORK_TREE` 后运行 +- `git diff --check` + - 结果:通过 + +### 当前下一步(RP-082) + +1. 继续复算 branch diff vs `origin/main`,若仍低于 `25` 个文件可继续下一批 +2. 下一批优先复核基础 generation gate 之外的 runtime contract 或 fallback selection 分支;基础 gate 的可安全构造缺失分支已覆盖 + +### 阶段:PR #323 review 锚点收敛(CQRS-REWRITE-RP-082) + +- 使用 `$gframework-pr-review` 重新拉取当前分支 PR review payload,确认当前分支对应 `PR #323`,状态为 `OPEN` +- 本轮 latest-head open AI thread 仅指出 active tracking 中仍保留 `PR #307` 作为当前 PR 锚点;本地复核后确认该反馈仍成立 +- 已将 active tracking 的当前 PR 锚点、活跃事实、最近 PR review 备注和下一推荐步骤统一到 `PR #323` +- `PR #307` 仅保留为历史 PR 说明和较早 trace 段落,不再作为 active 恢复入口 + +### 验证(PR #323 review) + +- `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --format json --json-output ` + - 结果:通过 + - 备注:确认 `PR #323` 只有 1 个 CodeRabbit open thread,指向 active tracking 的 PR 锚点漂移 +- 远端 `CTRF` 最新汇总为 `2274/2274` passed +- `MegaLinter` 当前仅报告 `dotnet-format` 的 `Restore operation failed` 环境噪音,未提供本地仍成立的文件级格式诊断 +- `git diff --check` + - 结果:通过 +- `python3 scripts/license-header.py --check` + - 结果:通过 + - 备注:当前 WSL worktree 需要显式绑定 `GIT_DIR` / `GIT_WORK_TREE` 后运行 +- `dotnet build GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + +### 当前下一步(PR #323 review) + +1. 若 review 重新触发后仍有 latest-head open thread,继续以 `PR #323` 为当前唯一 PR 恢复锚点复核 +2. 后续若继续推进代码切片,优先复核基础 generation gate 之外的 runtime contract 或 fallback selection 分支 + +## 2026-05-06(RP-083 ~ RP-089) + +### 阶段:mixed invoker provider 排序回归(CQRS-REWRITE-RP-083) + +- 使用 `$gframework-batch-boot 50` 继续 `feat/cqrs-optimization` 的 CQRS 收口批次 +- 批次目标:在 branch diff 相对 `origin/main` 接近 `50` 个文件前,继续补齐低风险的 generator runtime contract / emission 回归 +- 本轮基线选择: + - `origin/main a8c6c11e`,committer date `2026-05-05 13:14:24 +0800` + - `main a8c6c11e`,committer date `2026-05-05 13:14:24 +0800` + - 当前分支 `feat/cqrs-optimization a8c6c11e`,committer date `2026-05-05 13:14:24 +0800` +- 启动时 branch diff vs `origin/main` 为 `0` files / `0` lines,因此继续选择低风险测试回归切片 +- 本轮复核 `CreateGeneratedRegistrySourceShape` 与 invoker emission 路径后确认: + - 现有测试已覆盖 request / stream provider 的单一 direct 场景、单一 reflected-implementation 场景、precise reflected 跳过边界,以及各项 runtime contract 缺失分支 + - 尚未锁定“同一 registry 同时包含 direct registration 与 reflected-implementation registration”时的 descriptor 顺序与 `Invoke*HandlerN` 编号稳定性 +- 已补齐: + - `Emits_Request_Invoker_Provider_Metadata_In_Stable_Order_For_Mixed_Direct_And_Reflected_Implementations` + - `Emits_Stream_Invoker_Provider_Metadata_In_Stable_Order_For_Mixed_Direct_And_Reflected_Implementations` + - 两组 source fixture:`MixedRequestInvokerProviderSource`、`MixedStreamInvokerProviderSource` +- 通过新增回归,显式锁定以下约束: + - provider descriptor 条目按稳定实现排序输出 + - `InvokeRequestHandler0/1` 与 `InvokeStreamHandler0/1` 的方法编号随 emission 顺序连续增长 + - 隐藏实现类型不会破坏 direct registration 与 reflected-implementation registration 的混合发射 + +### 验证(RP-083) + +- `dotnet test GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Emits_Request_Invoker_Provider_Metadata_In_Stable_Order_For_Mixed_Direct_And_Reflected_Implementations|FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Emits_Stream_Invoker_Provider_Metadata_In_Stable_Order_For_Mixed_Direct_And_Reflected_Implementations"` + - 结果:通过,`2/2` passed + +### 当前 stop-condition 度量(RP-083) + +- primary metric:branch diff files vs `origin/main` +- 当前说明:active batch 尚未提交时,基于 `HEAD` 的 branch diff 仍显示 `0` files / `0` lines;提交本批后再以新 `HEAD` 复算累计 branch diff + +### 当前下一步(RP-083) + +1. 提交本轮 mixed invoker provider 排序回归后,复算 branch diff vs `origin/main`,确认 `50` 文件阈值仍有充足余量 +2. 若继续推进代码切片,优先复核 invoker provider 之外的 runtime contract 或 fallback selection 分支 + +### 阶段:benchmark 基础设施引入(CQRS-REWRITE-RP-084) + +- 用户明确将当前长期分支目标上提为:系统性吸收 `ai-libs/Mediator` 的实现思路与设计哲学,并将可取部分纳入 `GFramework.Cqrs` +- 本轮据此调整批次目标,不再把关注点收缩到单个 generator 回归,而是建立能持续比较和吸收设计差异的 benchmark 基础设施 +- 参考 `ai-libs/Mediator` 的 benchmark 设计后,本轮采纳的核心结构包括: + - 独立 benchmark 项目壳,而非扩展现有 NUnit 测试项目 + - 共享 `Fixture` 输出并校验场景配置 + - `Request` / `Notification` 两个 messaging 场景作为首批最小落点 + - 自定义列 `CustomColumn`,为后续矩阵扩展保留可读结果标签 +- 本轮新增: + - `GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj` + - `GFramework.Cqrs.Benchmarks/Program.cs` + - `GFramework.Cqrs.Benchmarks/CustomColumn.cs` + - `GFramework.Cqrs.Benchmarks/Messaging/Fixture.cs` + - `GFramework.Cqrs.Benchmarks/Messaging/BenchmarkContext.cs` + - `GFramework.Cqrs.Benchmarks/Messaging/RequestBenchmarks.cs` + - `GFramework.Cqrs.Benchmarks/Messaging/NotificationBenchmarks.cs` + - `GFramework.Cqrs.Benchmarks/README.md` +- 设计取舍: + - 使用最小 `ICqrsContext` marker,避免把完整 `ArchitectureContext` 初始化成本混入 steady-state dispatch + - 直接复用 `GFramework.Cqrs.CqrsRuntimeFactory` 与 `MicrosoftDiContainer`,让基准聚焦于 runtime dispatch / publish + - 外部对照组先接入 `MediatR`,保持与 `Mediator` benchmark 的对照哲学一致;但本轮仍只做最小 request / notification 场景 + - 暂不把 source generator benchmark、cold-start 独立工程或完整 pipeline / stream 矩阵一起引入,避免首批 scope 失控 +- 兼容性修正: + - 在根 `GFramework.csproj` 中显式排除 `GFramework.Cqrs.Benchmarks/**`,避免 meta-package 意外编译 benchmark 源码 + - 将 benchmark 项目加入 `GFramework.sln`,保持仓库级工作流完整 + +### 验证(RP-084) + +- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `GIT_DIR= GIT_WORK_TREE= python3 scripts/license-header.py --check` + - 结果:通过 +- `git diff --check` + - 结果:通过 + +### 当前 stop-condition 度量(RP-084) + +- primary metric:branch diff files vs `origin/main` +- 当前说明:本轮仍在 `50` 文件阈值以内,可继续按 benchmark 场景或 CQRS runtime 对照能力分批推进 + +### 当前下一步(RP-084) + +1. 继续扩展 `GFramework.Cqrs.Benchmarks`,优先补齐 pipeline、stream、cold-start 与 generated invoker provider 对照场景 +2. 当后续有具体 runtime 优化切片时,用该 benchmark 项目验证是否真正吸收到了 `Mediator` 的低开销 dispatch 设计收益 + +### 阶段:stream request benchmark 对照(CQRS-REWRITE-RP-085) + +- 继续沿用 `$gframework-batch-boot 50`,当前 branch diff 相对 `origin/main` 仍明显低于阈值 +- 在 `RP-084` 已建立独立 benchmark 项目后,本轮优先补齐 `ai-libs/Mediator/benchmarks/Mediator.Benchmarks/Messaging/StreamingBenchmarks.cs` 对应的最小 stream 场景 +- 选择 stream 作为第二批 benchmark 的原因: + - 已有独立的 `CreateStream` runtime 路径和单独的 stream invoker provider 元数据契约 + - 与 `Mediator` 的 messaging benchmark 分层直接对应 + - 不需要像 pipeline / cold-start 那样先进一步澄清运行时或宿主边界 +- 本轮新增: + - `GFramework.Cqrs.Benchmarks/Messaging/StreamingBenchmarks.cs` + - `GFramework.Cqrs.Benchmarks/README.md` 中的 stream 场景说明 +- 设计约束: + - 保持与前一批一致的三路对照:`Baseline`、`GFramework.Cqrs`、`MediatR` + - 基准测量“完整枚举 3 个元素”的全量消费成本,而不是只测创建异步枚举器 + - 使用最小 `ICqrsContext` marker,继续避免把完整 `ArchitectureContext` 初始化成本混入 steady-state stream dispatch +- 结论: + - 当前 benchmark 项目已经覆盖 `Request`、`Notification`、`StreamRequest` 三个核心 messaging steady-state 场景 + - 下一批更适合转向 request pipeline 数量矩阵或 cold-start / initialization,而不是继续扩同层次的 messaging 基线 + +### 验证(RP-085) + +- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `GIT_DIR= GIT_WORK_TREE= python3 scripts/license-header.py --check` + - 结果:通过 +- `git diff --check` + - 结果:通过 + +### 当前 stop-condition 度量(RP-085) + +- primary metric:branch diff files vs `origin/main` +- 当前说明:新增 stream benchmark 后仍处于 `50` 文件阈值以内,适合继续下一批 request pipeline 或 cold-start 场景 + +### 当前下一步(RP-085) + +1. 继续扩展 `GFramework.Cqrs.Benchmarks`,优先补齐 request pipeline 数量矩阵,随后再评估 cold-start / initialization +2. 当需要验证 generated invoker provider 的实际收益时,把 request benchmark 扩展为 reflection / generated provider 对照,而不是只停留在框架间对比 + +### 阶段:request pipeline 数量矩阵(CQRS-REWRITE-RP-086) + +- 继续沿用 `$gframework-batch-boot 50`,当前 branch diff 相对 `origin/main` 仍明显低于阈值 +- 本轮把 benchmark 关注点从单纯 messaging steady-state 扩展到 request pipeline 编排行为,原因是: + - `ai-libs/Mediator` 的对照价值已经不只在 request / notification / stream 三个入口本身,还在 pipeline 包装策略与生命周期取舍 + - `GFramework.Cqrs.Internal.CqrsDispatcher` 已按 `behaviorCount` 缓存 `RequestPipelineExecutor` 形状,因此单独量化 `0 / 1 / 4` 个行为的 steady-state 开销有直接信息密度 +- 本轮新增: + - `GFramework.Cqrs.Benchmarks/Messaging/RequestPipelineBenchmarks.cs` + - `GFramework.Cqrs.Benchmarks/README.md` 中的 request pipeline 场景说明 +- 设计取舍: + - 采用 `0 / 1 / 4` 个 pipeline 行为,而不是立即扩到更大的参数空间,先锁定最有代表性的无行为 / 少量行为 / 常见多行为矩阵 + - 使用最小 no-op 行为族,不引入日志、计时或上下文刷新逻辑,避免把测量结果污染成业务行为成本 + - `GFramework.Cqrs` 与 `MediatR` 侧都只注册当前 benchmark 请求对应的闭合行为类型,确保矩阵反映编排成本而非程序集扫描差异 +- 接受的只读 subagent 结论: + - 下一批 benchmark 继续优先考虑 `cold-start / initialization` 与 `generated provider` 对照,而不是立即照搬 `Mediator` 的 large-project 维度 + - 当前 `GFramework.Cqrs.Benchmarks` 仍未接入 `Mediator` 包和 `GFramework.Cqrs.SourceGenerators`,因此本轮不扩成 `Mediator_IMediator` / generated-provider 对照,避免 scope 失控 +- 结论: + - 当前 benchmark 项目已经覆盖 `Request`、`Notification`、`StreamRequest` 与 `RequestPipeline` + - 后续若要继续贴近 `Mediator` 的 comparison benchmark,最值得优先补的是 initialization / first-hit 与 generated invoker provider,而不是继续横向堆更多 steady-state messaging 入口 + +### 验证(RP-086) + +- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + +### 当前 stop-condition 度量(RP-086) + +- primary metric:branch diff files vs `origin/main` +- 当前说明:提交前基于 `HEAD` 的 branch diff 仍为 `14` files,距离 `50` 文件阈值仍有明显余量 + +### 当前下一步(RP-086) + +1. 提交本轮 request pipeline benchmark 后,继续扩展 `GFramework.Cqrs.Benchmarks`,优先补齐 initialization / cold-start 场景 +2. 当需要验证 dispatcher 预热与 source generator 收益时,引入 generated invoker provider 对照,并评估是否同时接入 `Mediator` concrete runtime 作为更贴近设计哲学的外部参照 + +### 阶段:request startup 基线(CQRS-REWRITE-RP-087) + +- 继续沿用 `$gframework-batch-boot 50`,当前 branch diff 相对 `origin/main` 仍明显低于阈值 +- 本轮目标:把 benchmark 从 steady-state dispatch 再向前推进一层,补齐与 `ai-libs/Mediator/benchmarks/Mediator.Benchmarks/Messaging/Comparison/*` 更接近的 startup 维度 +- 本轮新增: + - `GFramework.Cqrs.Benchmarks/Messaging/RequestStartupBenchmarks.cs` + - `GFramework.Cqrs.Benchmarks/README.md` 中的 startup 场景说明 +- 设计取舍: + - `Initialization` 只测“从已配置宿主解析/创建 runtime 句柄”的成本,不把完整架构初始化混入 benchmark + - `ColdStart` 只测新宿主上的首次 request send;`GFramework.Cqrs` 侧在每次 benchmark 前通过反射清空 dispatcher 静态缓存,避免把热缓存误当 first-hit + - `ColdStart_MediatR` 改为真正 `await` 完任务后再释放 `ServiceProvider`,以满足 `Meziantou.Analyzer` 对资源生命周期的要求,并避免 benchmark 本身含有错误宿主释放语义 +- 结论: + - 当前 benchmark 项目已经覆盖 `Request`、`Notification`、`StreamRequest`、`RequestPipeline`、`RequestStartup` + - 后续若继续贴近 `Mediator` comparison benchmark,下一批最有价值的是 generated invoker provider、registration / service lifetime 与 concrete runtime 外部对照,而不是继续只加同层 steady-state case + +### 验证(RP-087) + +- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + +### 当前 stop-condition 度量(RP-087) + +- primary metric:branch diff files vs `origin/main` +- 当前说明:提交前 branch diff 仍远低于 `50` 文件阈值,可继续下一批 benchmark 或低风险 runtime 对照切片 + +### 当前下一步(RP-087) + +1. 提交本轮 request startup benchmark 后,继续扩展 `GFramework.Cqrs.Benchmarks`,优先评估 generated invoker provider 与 registration / service lifetime 矩阵 +2. 若要更贴近 `Mediator` 的 comparison benchmark 设计哲学,评估是否在 benchmark 项目中同时接入 `Mediator` concrete runtime 对照,而不只保留 `MediatR` + +### 阶段:request invoker reflection / generated 对照(CQRS-REWRITE-RP-088) + +- 继续沿用 `$gframework-batch-boot 50`,当前 branch diff 相对 `origin/main` 仍明显低于阈值 +- 本轮目标:不再只比较 `GFramework.Cqrs` 与 `MediatR` 的外层框架差异,而是开始直接量化 `GFramework.Cqrs` 内部 reflection request binding 与 generated invoker provider 路径的 steady-state 差异 +- 本轮新增: + - `GFramework.Cqrs.Benchmarks/Messaging/RequestInvokerBenchmarks.cs` + - `GFramework.Cqrs.Benchmarks/Messaging/GeneratedRequestInvokerBenchmarkRegistry.cs` + - `GFramework.Cqrs.Benchmarks/README.md` 中的 generated invoker 场景说明 +- 设计取舍: + - 采用 benchmark 内手写的 generated registry/provider“等价物”,而不是当轮就把真实 `GFramework.Cqrs.SourceGenerators` 接到 benchmark 项目中,目的是先走通真实的 registrar -> descriptor 预热 -> dispatcher generated path,同时把写入面控制在低风险范围 + - generated 对照使用程序集级 `CqrsHandlerRegistryAttribute` + `ICqrsRequestInvokerProvider` + `IEnumeratesCqrsRequestInvokerDescriptors`,确保运行时语义与生产路径一致 + - 在 benchmark 生命周期前后清理 dispatcher 静态缓存,避免 generated descriptor 预热状态跨场景泄漏,污染 reflection 对照 +- 结论: + - 当前 benchmark 项目已经能区分 `GFramework.Cqrs` 的 reflection request 路径、generated request 路径与 `MediatR` 外部对照 + - 后续若继续贴近 `Mediator` comparison benchmark,下一批更适合扩到 registration / service lifetime、stream generated provider,或再决定是否接入 `Mediator` concrete runtime + +### 验证(RP-088) + +- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` + +### 当前 stop-condition 度量(RP-088) + +- primary metric:branch diff files vs `origin/main` +- 当前说明:提交前 branch diff 仍远低于 `50` 文件阈值,可继续推进下一批 benchmark 对照切片 + +### 当前下一步(RP-088) + +1. 提交本轮 request invoker benchmark 后,继续扩展 `GFramework.Cqrs.Benchmarks`,优先评估 registration / service lifetime 或 stream generated provider + +### 阶段:stream invoker reflection / generated 对照(CQRS-REWRITE-RP-089) + +- 使用 `$gframework-batch-boot 30` 继续 `feat/cqrs-optimization` 的 CQRS 收口批次 +- 本轮基线选择: + - `origin/main c01abac0`,committer date `2026-05-06 09:40:08 +0800` + - `main a8c6c11e`,committer date `2026-05-05 13:14:24 +0800` +- 启动时 branch diff vs `origin/main` 为 `18` files / `2100` lines,低于 `30` 文件阈值,因此继续选择单模块、低风险 benchmark 切片 +- 复核 `GFramework.Cqrs.Benchmarks` 与 `ai-libs/Mediator/benchmarks` 后确认: + - `RP-088` 已把 generated descriptor 预热收益量化到 request dispatch 路径 + - stream benchmark 仍停留在 direct handler / reflection runtime / `MediatR` 三路对照,尚未量化 generated stream invoker provider 的收益 + - 虽然 `Mediator` 参考基准大量使用 service lifetime 矩阵,但当前 `GFramework.Cqrs.Benchmarks` 尚未建立对称的 scoped host 模式;直接扩 lifetime 会引入超出本批风险预算的宿主语义变化 +- 本轮因此优先选择 request 对称切片,而不是 service lifetime 扩展: + - 新增 `Messaging/StreamInvokerBenchmarks.cs` + - 新增 `Messaging/GeneratedStreamInvokerBenchmarkRegistry.cs` + - 更新 `GFramework.Cqrs.Benchmarks/README.md` +- 设计约束: + - 继续沿用 handwritten generated registry/provider 模式,避免把 benchmark 基础设施与真实 source-generator 输出耦合 + - 复用与 `RP-088` 相同的 dispatcher 缓存清理策略,确保 reflection / generated 路径对照不受静态缓存残留污染 + - 使用统一的异步枚举体工厂,让三组 stream handler 共享同一枚举成本基线,把变量收敛到 invoker/provider 接线路径 + +### 当前下一步(RP-089) + +1. 完成本轮 benchmark 项目 Release build、license header 检查与 diff 校验后,更新 active tracking 的权威验证列表 +2. 若 branch diff 仍明显低于 `30` 文件阈值,可继续评估 notification publish strategy 或更贴近 `Mediator` concrete runtime 的单批对照 +3. 若要继续贴近 `Mediator` 的 comparison benchmark 设计哲学,评估是否把 `Mediator` concrete runtime 本身接入 benchmark 项目,而不是长期只保留 `MediatR` + +### 验证(RP-089) + +- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` + - 结果:通过,`0 warning / 0 error` +- `GIT_DIR= GIT_WORK_TREE= python3 scripts/license-header.py --check` + - 结果:通过 +- `git diff --check` + - 结果:通过 +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestStartupBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` + - 结果:部分通过;`MediatR` startup benchmark 已恢复真实测量,`ColdStart_GFrameworkCqrs` 仍因 `No CQRS request handler registered` 失败 + +### 阶段:手动 benchmark workflow(CQRS-REWRITE-RP-089) + +- 新增 `.github/workflows/benchmark.yml`,提供仅 `workflow_dispatch` 触发的 benchmark 入口 +- workflow 默认只执行 `GFramework.Cqrs.Benchmarks` 的 Release build,避免在当前已知 `RequestStartupBenchmarks` 残留未清时默认运行失败 +- 只有在手动输入 `benchmark_filter` 时才执行 BenchmarkDotNet,并上传 `BenchmarkDotNet.Artifacts` 供后续比较 diff --git a/ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md b/ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md index b5f5960e..951e3c88 100644 --- a/ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md +++ b/ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md @@ -1,3 +1,8 @@ + + # CQRS 重写迁移跟踪 ## 目标 @@ -7,486 +12,79 @@ CQRS 迁移与收敛。 ## 当前恢复点 -- 恢复点编号:`CQRS-REWRITE-RP-131` +- 恢复点编号:`CQRS-REWRITE-RP-132` - 当前阶段:`Phase 8` -- 当前 PR 锚点:`待重新抓取` +- 当前 PR 锚点:`PR #347` - 当前结论: -- 当前 `RP-131` 继续沿用 `$gframework-batch-boot 50`,并把上一波定位到的 BenchmarkDotNet 并行运行冲突真正收口到 benchmark 入口层:`Program.cs` 现在支持 `--artifacts-suffix `,并在声明 suffix 时自动把当前 benchmark 运行重启到独立的 host 工作目录 -- 本轮继续沿用已复核的基线:`origin/main` 与本地 `main` 当前都在 `699d0b48`(`2026-05-09 18:39:38 +0800`);当前分支相对 `origin/main` 的累计 branch diff 仍约为 `9 files changed, 953 insertions(+), 83 deletions(-)`,离 `$gframework-batch-boot 50` 还有明显余量 -- 本轮写面收敛在 benchmark 入口与文档两处:`GFramework.Cqrs.Benchmarks/Program.cs` 与 `GFramework.Cqrs.Benchmarks/README.md`;没有扩散到 benchmark 业务逻辑文件、`GFramework.Cqrs` runtime 或测试项目 -- `Program.cs` 当前约定为: - - 解析并剥离仓库自定义参数 `--artifacts-suffix `,避免把它误传给 BenchmarkDotNet CLI - - 支持通过环境变量回退复用同一套 suffix / artifacts path 约定 - - 当 suffix 存在时,先把当前 benchmark 宿主输出复制到 `BenchmarkDotNet.Artifacts//host/`,再从该隔离宿主目录重启运行,使 BenchmarkDotNet 自动生成的 `GFramework.Cqrs.Benchmarks-Job-*` 项目、`OutDir` 与最终 results 都落到 suffix 私有目录下 -- 并发 smoke 已直接证明这套隔离生效:`RequestLifetimeBenchmarks.SendRequest_*` 与 `StreamInvokerBenchmarks.Stream_*` 在两个终端并发 short-job 时,分别落到 `BenchmarkDotNet.Artifacts/req-lifetime-a/host/...` 与 `BenchmarkDotNet.Artifacts/stream-invoker-b/host/...`,不再共享同一 `.../bin/Release/net10.0/GFramework.Cqrs.Benchmarks-Job-JWUHXL-1/` 生成目录,也没有再出现 `.dll.config being used by another process` -- `README` 已同步新的运行约定:当两个带 `--filter` 的 benchmark 需要并发执行时,必须为每个进程传入不同的 `--artifacts-suffix`;该约束只服务于本地输出隔离,不代表 benchmark 业务语义本身需要额外依赖 -- 下一推荐步骤: -- 若继续 benchmark 线,可重新利用新的并发运行隔离约定,单开一波更稳定的 `StreamInvokerBenchmarks` `DrainAll` 排序复核,或并行推进其他不冲突的 benchmark smoke -- 若上下文预算仍允许,下一批更适合继续保持在 `GFramework.Cqrs.Benchmarks` 单模块,避免过早把 review 面重新扩到 runtime 或测试层 -- 更早的 `RP-123` 及之前阶段细节以下方 trace 与归档为准,active 入口不再重复展开旧阶段流水。 - - 当前分支相对 `origin/main` 的累计 branch diff 启动时为 `9 files`,仍明显低于 `$gframework-batch-boot 50` 的停止阈值;这一批继续保持单模块、低风险、可直接评审的 benchmark 边界 - - 当前 `RP-113` 已继续沿用 `$gframework-batch-boot 50`,并把 notification 线从 benchmark 对照推进到实际 runtime 能力:新增公开内置 `TaskWhenAllNotificationPublisher`,让 `GFramework.Cqrs` 在保留默认顺序发布器的同时,提供与 `Mediator` `TaskWhenAllPublisher` 对齐的并行 notification publish 策略 - - `TaskWhenAllNotificationPublisher` 当前语义明确为:零处理器静默完成,单处理器直接透传,多处理器并行启动并等待全部结束;它不保留默认顺序发布器的“首个异常立即停止”语义,而是把全部处理器的失败/取消结果收敛到同一个返回任务 - - 本轮同时补齐 `CqrsNotificationPublisherTests` 对新内置策略的回归,并更新 `GFramework.Cqrs/README.md` 与 `docs/zh-CN/core/cqrs.md`,把切换方式和语义边界写回用户可见文档;当前已提交 branch diff 仍明显低于 `$gframework-batch-boot 50` 的停止阈值 - - 这一批选择真正落一个内置 publisher strategy,而不是继续加 notification benchmark 维度;原因是 `RP-111` / `RP-112` 已经把 notification gap 量化清楚,下一步更高价值的是开始收口“能力差距”而不是继续重复建立对照数据 - - 当前 `RP-112` 已继续沿用 `$gframework-batch-boot 50`,并在 `RP-111` 的单处理器 notification 对照基础上补齐固定 `4 handler` 的 fan-out publish benchmark:新增 `NotificationFanOutBenchmarks`,对比 baseline、`GFramework.Cqrs`、NuGet `Mediator` concrete runtime 与 `MediatR` - - `NotificationFanOutBenchmarks` 当前 short-job 基线约为 baseline `8.302 ns / 0 B`、`Mediator` `4.314 ns / 0 B`、`MediatR` `230.304 ns / 1256 B`、`GFramework.Cqrs` `434.413 ns / 408 B`;这说明 notification fan-out 的差距已经不只体现在单处理器 publish,而是在固定 4 处理器场景下依然保持相近量级 - - 本轮仍然只扩 benchmark 对照口径,没有直接修改 notification runtime 或 publisher 策略语义;原因是当前更高价值的事实是先量化“单处理器”和“固定 fan-out”两条 notification 路径的外部差距,再决定下一批是否值得切进 publisher strategy 或 runtime 热点 - - 当前 `RP-111` 已继续沿用 `$gframework-batch-boot 50`,并按 skill 规则重新以 `origin/main` 作为基线复核:`origin/main` = `7ca21af9`(`2026-05-08 16:12:20 +0800`),本地 `main` = `c2d22285` 已落后,当前分支 `feat/cqrs-optimization` 与 `origin/main` 的累计 branch diff 为 `0 files / 0 lines`;基于“上下文预算优先、单批可评审边界次之”的停止规则,本轮选择 `NotificationBenchmarks` 这一条仍缺 `Mediator` concrete runtime 对照的单模块 benchmark 切片,而不是为了对称性继续扩展 notification runtime seam - - `NotificationBenchmarks` 现已从双方对照扩成三方对照:新增 NuGet `Mediator` source-generated concrete runtime 宿主与 `PublishNotification_Mediator()`,`BenchmarkNotification` / `BenchmarkNotificationHandler` 也同步接上 `Mediator` 的 notification 合同;当前 short-job 基线约为 `Mediator` `1.108 ns / 0 B`、`MediatR` `97.173 ns / 416 B`、`GFramework.Cqrs` `291.582 ns / 392 B` - - 本轮只把“notification publish 的高性能外部对照”补齐到 benchmark 层,而没有直接新增 generated notification invoker/provider 或 runtime 语义调整;原因是 notification dispatch 现有反射委托本就只在首次命中时缓存,继续加一层 provider 对 steady-state publish 的收益信号不如先把 `Mediator` concrete runtime 对照补齐来得清晰 - - 当前 `RP-110` 已再次使用 `$gframework-pr-review` 复核 `PR #341` latest-head review:`BenchmarkHostFactory` 的 legacy runtime alias 防守式类型检查、benchmark 宿主定向 generated registry 激活、以及 `CqrsDispatcher.SendAsync(...)` 的 faulted `ValueTask` 失败语义在当前 head 均已实质收口;本轮仅继续接受仍然成立的 CodeRabbit nitpick,为 `SendAsync_Should_Return_Faulted_ValueTask_When_Handler_Is_Missing()` 补齐 `HasRegistration(...)` / `GetAll(...)` 防御性 mock,并删除 trace 中重复 `本轮权威验证` 的 `本轮下一步` 段落 - - 当前 `RP-109` 已使用 `$gframework-pr-review` 复核 `PR #341` latest-head review:benchmark 宿主改为定向激活当前场景的 generated registry,避免同一 benchmark 程序集里的其他 registry 扩大冻结服务索引与 `HasRegistration` 基线;`BenchmarkHostFactory` 为 legacy runtime alias 注册补齐防守式类型检查与 stream lifetime 运行时注释;`CqrsDispatcher.SendAsync(...)` 在保留 direct-return 热路径的同时恢复 faulted `ValueTask` 失败语义,并补齐 generated registry 定向接线与 request fault 语义回归测试;`.agents/skills/gframework-batch-boot/SKILL.md` 的 MD005 缩进也已顺手修正 - - `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()`、dispatcher 侧 stream pipeline executor 缓存与 generated stream invoker 兼容回归,以及 `Architecture` 公开注册入口与对应文档说明 - - 当前 `RP-100` 已使用 `$gframework-pr-review` 复核 `PR #339` latest-head review:收口 `RegisterCqrsStreamPipelineBehavior()` 的异常契约文档、为 `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` - - 当前 `RP-107` 已把默认 stream steady-state 宿主也切到 generated-provider 路径:新增 handwritten `GeneratedDefaultStreamingBenchmarkRegistry`,让 `StreamingBenchmarks` 改走 `RegisterCqrsHandlersFromAssembly(...)` 并在 setup/cleanup 清理 dispatcher cache;同时将 `gframework-boot` / `gframework-batch-boot` 的默认停止规则改为“AI 上下文预算优先,建议在预计接近约 80% 安全上下文占用前收口”,不再把 changed files 误当作唯一阈值 - - 当前 `RP-108` 已补齐 stream handler `Singleton / Transient` 生命周期矩阵 benchmark:新增 `StreamLifetimeBenchmarks` 与 `GeneratedStreamLifetimeBenchmarkRegistry`,让 stream 生命周期对照沿用 generated-provider 宿主接线而不是退回纯反射路径;本轮 benchmark 表明 `Singleton` 下 baseline / `GFramework.Cqrs` / `MediatR` 约 `80.144 ns / 137.515 ns / 229.242 ns`,`Transient` 下约 `77.198 ns / 144.998 ns / 228.185 ns` -- `ai-plan` active 入口现以 `RP-122` 为最新恢复锚点;`PR #340`、`PR #339`、`PR #334`、`PR #331`、`PR #326`、`PR #323`、`PR #307` 与其他更早阶段细节均以下方归档或说明为准 + - 已用 `$gframework-pr-review` 重新抓取并复核 `PR #347` 的 latest-head review,当前仍成立的代码问题已收口到 + `GFramework.Cqrs.Benchmarks` 单模块与 `ai-plan/public/cqrs-rewrite/**` 恢复入口。 + - `Program.cs` 现在按“任意已生效的 artifacts 隔离配置”而不是“仅命令行 `--artifacts-suffix`”决定是否重启隔离宿主; + 同时新增“目标宿主目录不得等于或嵌套在当前宿主输出目录内”的防守式校验,避免 `host/host/...` 递归膨胀。 + - `RequestLifetimeBenchmarks` 与 `StreamLifetimeBenchmarks` 的 `Scoped` 路径改为复用单个 scoped runtime / + dispatcher,只在每次 benchmark 调用时显式创建并释放真实 DI scope,避免把 runtime 构造常量成本混进生命周期矩阵。 + - `ScopedBenchmarkContainer` 已补齐只读适配语义与作用域租约的 XML 合同说明,避免 PR review 再次停留在“公开成员文档不完整”。 + - active tracking / trace 已完成瘦身:历史长流水迁移到 `archive/` 新文件,当前 active 入口只保留恢复点、风险、 + 权威验证与下一步。 ## 当前活跃事实 -- 当前分支为 `feat/cqrs-optimization` -- 本轮 `$gframework-batch-boot 50` 以 `origin/main` (`d85828c5`, `2026-05-09 12:25:41 +0800`) 为基线;本地 `main` (`c2d22285`, `2026-05-06 21:34:59 +0800`) 已落后,不作为 branch diff 基线 -- 当前已提交分支相对 `origin/main` 的累计 branch diff 为 `21 files`(`1344 insertions / 194 deletions`),仍明显低于 `$gframework-batch-boot 50` 的 `50 files` 停止阈值 -- 当前用于收口 `PR #345` review 的写面额外覆盖 `AGENTS.md`、`GFramework.Cqrs.Benchmarks/README.md` 与 `ai-plan/public/cqrs-rewrite/**`;本轮代码层面的唯一触点保持在 `StreamLifetimeBenchmarks.cs` -- 当前 `PR #345` latest-head review body 已本地复核完毕;仍成立并已吸收的反馈集中在 `AGENTS.md` 术语说明、`StreamLifetimeBenchmarks` 的取消/注释细节,以及 benchmark README / `ai-plan` 恢复入口漂移 -- 当前批次后的默认停止依据已改为 AI 上下文预算:若下一轮预计会让活动对话、已加载 recovery 文档、验证输出与当前 diff 接近约 `80%` 安全上下文占用,应在当前自然批次边界停止,即使 branch diff 仍有余量 -- `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.608 ns / 32 B`、`5.445 ns / 32 B`、`57.071 ns / 232 B`、`64.825 ns / 32 B` -- 当前 request lifetime benchmark 已对齐 generated-provider 宿主路径:`Singleton` 下 baseline / `GFramework.Cqrs` / `MediatR` 约为 `5.012 ns / 32 B`、`49.612 ns / 32 B`、`51.796 ns / 232 B`;`Transient` 下约为 `3.962 ns / 32 B`、`50.480 ns / 56 B`、`50.284 ns / 232 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` -- 当前 stream steady-state benchmark 也已切到 generated-provider 宿主接线路径:baseline 约 `5.535 ns / 32 B`、`MediatR` 约 `59.499 ns / 232 B`、`GFramework.Cqrs` 约 `66.778 ns / 32 B` -- 当前 stream lifetime benchmark 已更新为 `Observation=FirstItem / DrainAll` 双口径:`Singleton + FirstItem` 下 baseline / generated / reflection / `MediatR` 约为 `48.704 ns / 216 B`、`94.629 ns / 216 B`、`95.417 ns / 216 B`、`152.886 ns / 608 B`;`Singleton + DrainAll` 下约为 `73.335 ns / 280 B`、`118.860 ns / 280 B`、`119.632 ns / 280 B`、`205.629 ns / 672 B` -- `Transient + FirstItem` 下 baseline / reflection / generated / `MediatR` 约为 `48.293 ns / 216 B`、`97.628 ns / 240 B`、`100.011 ns / 240 B`、`154.149 ns / 608 B`;`Transient + DrainAll` 下约为 `78.466 ns / 280 B`、`124.174 ns / 304 B`、`116.780 ns / 304 B`、`220.040 ns / 672 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` -- `GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherContextValidationTests.cs` 现连“handler 缺失但仍返回 faulted `ValueTask`”这条 request 失败语义回归也显式为 `HasRegistration(Type)` / `GetAll(Type)` 预留了防御性 mock,不再依赖 dispatcher 先判空 handler、后探测 pipeline 的内部顺序 -- `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` 与 `StreamingBenchmarks` 现在都已通过 handwritten generated registry + 真实 `RegisterCqrsHandlersFromAssembly(...)` 宿主接线命中 generated invoker provider,不再只代表纯反射 binding 路径 -- `gframework-boot` 与 `gframework-batch-boot` 现明确把“上下文预算接近约 80%”视为默认优先停止信号,branch diff files / lines 仅保留为次级仓库范围指标 -- 当前性能回归门槛已收紧为:只要改动触达 `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()` 并在 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 ` 当前只产出 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` 的流式行为注册入口此前确实缺少 `` / `` 契约说明,现已补齐并同步到 `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 结论 +- 当前分支:`feat/cqrs-optimization` +- 当前 PR:`PR #347` +- 当前写面: + - `GFramework.Cqrs.Benchmarks/Program.cs` + - `GFramework.Cqrs.Benchmarks/README.md` + - `GFramework.Cqrs.Benchmarks/Messaging/BenchmarkHostFactory.cs` + - `GFramework.Cqrs.Benchmarks/Messaging/RequestLifetimeBenchmarks.cs` + - `GFramework.Cqrs.Benchmarks/Messaging/ScopedBenchmarkContainer.cs` + - `GFramework.Cqrs.Benchmarks/Messaging/StreamLifetimeBenchmarks.cs` + - `ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md` + - `ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` + - `ai-plan/public/cqrs-rewrite/archive/todos/cqrs-rewrite-migration-tracking-history-through-rp131.md` + - `ai-plan/public/cqrs-rewrite/archive/traces/cqrs-rewrite-migration-trace-history-through-rp131.md` +- 当前基线: + - `RequestLifetimeBenchmarks.SendRequest_GFrameworkCqrs` short-job 当前约为 + `Singleton 52.69 ns / 32 B`、`Transient 57.88 ns / 56 B`、`Scoped 144.72 ns / 368 B` + - `StreamLifetimeBenchmarks.Stream_GFramework*` short-job 当前约为 + `Scoped + FirstItem 266.7~267.0 ns / 792 B`、 + `Scoped + DrainAll 331.6~332.2 ns / 856 B` + - 两条并发 smoke 均已落到独立的 + `BenchmarkDotNet.Artifacts/pr347-req-scoped/host/...` 与 + `BenchmarkDotNet.Artifacts/pr347-stream-scoped/host/...` ## 当前风险 -- 当前 `_requestBehaviorPresenceCache` 依赖“同一 dispatcher 生命周期内,request pipeline 行为注册在容器冻结后保持稳定”这一约束;若未来引入运行时动态增删 request behavior 的模型,需要重新评估这类实例级 presence cache 的失效策略 -- 当前 `_streamBehaviorPresenceCache` 也依赖“同一 dispatcher 生命周期内,stream pipeline 行为注册在容器冻结后保持稳定”这一约束;若后续引入运行期动态增删 stream behavior 或按 scope 改写可见性的模型,需要同步设计失效策略,而不能继续假设实例级缓存永久有效 -- 标准架构启动路径现在已经有“自定义 notification publisher 不被默认顺序策略短路”的集成回归;但若后续再引入第三种仓库内置策略或新的启动快捷入口,仍需要同步补这条生产路径验证,不能只看 `CqrsTestRuntime` 测试宿主 -- 顶层 `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` concrete runtime 对照已覆盖 steady-state request、单处理器 notification publish 与固定 `4 handler` notification fan-out;若要把 `Transient` / `Scoped` 生命周期矩阵、stream 生命周期矩阵或更大 fan-out 矩阵也纳入同一组对照,需要按 `Mediator` 官方 benchmark 的做法拆分 compile-time lifetime / 场景配置,而不是在同一编译产物里混用多个 runtime 变量 -- 当前 stream 生命周期矩阵尚未接入 `Mediator` concrete runtime;若要继续对齐 `Mediator` 官方 benchmark 的 compile-time lifetime 设计,需要为 stream 场景补专门的 build-time 配置,而不是在当前统一宿主里临时拼接 -- `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 框架短路成环境性失败 -- `PR #345` 当前 latest-head review 仍以 CodeRabbit review body 的 `4` 条 actionable comments 为主;最新本地复核后,仍成立的问题集中在 `AGENTS.md` 术语说明、`StreamLifetimeBenchmarks` 的取消/文档细节,以及 benchmark README / `ai-plan` 恢复入口漂移 +- `Program.cs` 的“嵌套目标目录保护”只覆盖当前宿主目录与隔离宿主目录关系;若后续再扩展更多自定义 artifacts 入口, + 仍需保持同一层防守式校验,避免配置分叉。 +- `ScopedBenchmarkContainer` 现在明确禁止重叠 active scope;若后续 benchmark 引入同一 runtime 的并行枚举或嵌套调用, + 需要新的宿主模型,不能直接突破当前只读适配器的约束。 +- 本轮 benchmark 结果仍是 `job short + 1 iteration` smoke,用于证明路径正确与相对量级,不应用作稳定性能结论。 ## 最近权威验证 - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - 结果:通过,`0 warning / 0 error` - - 备注:覆盖 benchmark 入口 `--artifacts-suffix` 隔离实现、`README` 命令示例与 `ai-plan` 更新后的最小 Release build -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --artifacts-suffix req-lifetime-a --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --artifacts-suffix pr347-req-scoped --filter "*RequestLifetimeBenchmarks.SendRequest_GFrameworkCqrs*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - 结果:通过 - - 备注:本次 auto-generated benchmark 项目已在 `BenchmarkDotNet.Artifacts/req-lifetime-a/host/...` 下执行;`Singleton` 约为 baseline `5.189 ns`、`MediatR` `52.765 ns`、`GFramework.Cqrs` `60.938 ns` -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --artifacts-suffix stream-invoker-b --filter "*StreamInvokerBenchmarks.Stream_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:本次 auto-generated benchmark 项目已在 `BenchmarkDotNet.Artifacts/stream-invoker-b/host/...` 下执行;`DrainAll` 约为 baseline `77.82 ns`、generated `130.37 ns`、reflection `139.08 ns`、`MediatR` `245.23 ns` -- `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Program.cs GFramework.Cqrs.Benchmarks/README.md ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` - - 结果:通过 -- `git --git-dir=/.git/worktrees/GFramework-cqrs --work-tree=. diff --check` - - 结果:通过 - -- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - 备注:覆盖 `BenchmarkHostFactory` scoped stream helper、`StreamLifetimeBenchmarks` scoped 生命周期矩阵与 `README` 同步后的最小 Release build -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*StreamLifetimeBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:`StreamLifetimeBenchmarks` 已稳定跑出 `24` 个 case;`Scoped + DrainAll` 当前约为 baseline `81.20 ns / 280 B`、`MediatR` `428.66 ns / 1224 B`、generated `692.05 ns / 3888 B`、reflection `716.61 ns / 3888 B` -- `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/BenchmarkHostFactory.cs GFramework.Cqrs.Benchmarks/Messaging/StreamLifetimeBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` - - 结果:通过 -- `git --git-dir=/.git/worktrees/GFramework-cqrs --work-tree=. diff --check` - - 结果:通过 - -- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - 备注:覆盖 `StreamLifetimeBenchmarks` 的代码收口与 benchmark `README` 同步后的最小 Release build -- `python3 scripts/license-header.py --check --paths AGENTS.md GFramework.Cqrs.Benchmarks/Messaging/StreamLifetimeBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` - - 结果:通过 -- `git --git-dir=/.git/worktrees/GFramework-cqrs --work-tree=. diff --shortstat d85828c5...HEAD` - - 结果:通过 - - 备注:当前分支相对 `origin/main` 的累计 diff 为 `21 files changed, 1344 insertions(+), 194 deletions(-)` - -- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:宿主已对齐 generated-provider 路径;`Singleton` 下 baseline / `GFramework.Cqrs` / `MediatR` 约为 `5.012 ns / 32 B`、`49.612 ns / 32 B`、`51.796 ns / 232 B`;`Transient` 下约为 `3.962 ns / 32 B`、`50.480 ns / 56 B`、`50.284 ns / 232 B` -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*StreamLifetimeBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:已产出 `baseline / GFramework reflection / GFramework generated / MediatR` 四方矩阵;`Singleton` 下约为 `79.602 / 120.553 / 111.547 / 208.381 ns`,`Transient` 下约为 `76.351 / 119.632 / 129.166 / 213.420 ns` -- `python3 scripts/license-header.py --check --paths ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` - - 结果:通过 - -- `python3 scripts/license-header.py --check --paths GFramework.Cqrs/Internal/CqrsDispatcher.cs GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherContextValidationTests.cs GFramework.Cqrs.Tests/Cqrs/CqrsNotificationPublisherTests.cs GFramework.Cqrs.Tests/Cqrs/NotificationPublisherRegistrationExtensionsTests.cs GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherCacheTests.cs ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` - - 结果:通过 -- `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - 备注:首轮与 `GFramework.Cqrs.Tests` 并行构建时曾出现 `MSB3026` 单次复制重试;串行重跑同一命令后稳定通过 -- `dotnet build GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~CqrsDispatcherContextValidationTests|FullyQualifiedName~CqrsNotificationPublisherTests|FullyQualifiedName~NotificationPublisherRegistrationExtensionsTests|FullyQualifiedName~CqrsDispatcherCacheTests"` - - 结果:通过,`30/30` passed -- `git diff --check` - - 结果:通过 - -- `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsDispatcherCacheTests"` - - 结果:通过,`11/11` passed -- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:默认 request steady-state 当前约为 baseline `5.876 ns / 32 B`、`Mediator` `5.275 ns / 32 B`、`GFramework.Cqrs` `51.717 ns / 32 B`、`MediatR` `56.108 ns / 232 B` -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:`Singleton` 下 baseline / `GFramework.Cqrs` / `MediatR` 约 `5.720 ns / 52.490 ns / 56.890 ns`,`Transient` 下约 `5.814 ns / 57.746 ns / 55.545 ns` -- `python3 scripts/license-header.py --check --paths GFramework.Cqrs/Internal/CqrsDispatcher.cs GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherCacheTests.cs` - - 结果:通过 -- `dotnet build GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~ArchitectureModulesBehaviorTests"` - - 结果:通过,`5/5` passed -- `python3 scripts/license-header.py --check --paths GFramework.Core.Tests/Architectures/ArchitectureModulesBehaviorTests.cs` - - 结果:通过 -- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*NotificationFanOutBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:本轮对称化 MediatR handler 后,fixed `4 handler` fan-out 对照约为 `Mediator` `3.598 ns / 0 B`、baseline `7.033 ns / 0 B`、`MediatR` `257.533 ns / 1256 B`、`GFramework.Cqrs` 顺序 `409.557 ns / 408 B`、`TaskWhenAll` `484.531 ns / 496 B` -- `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/NotificationFanOutBenchmarks.cs GFramework.Cqrs/README.md docs/zh-CN/core/cqrs.md ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` - - 结果:通过 -- `git diff --check` - - 结果:通过 - - 备注:仅剩 `GFramework.sln` 的历史 CRLF 提示,无本轮新增 diff 格式问题 -- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*NotificationFanOutBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:历史基线(`RP-112`)固定 `4 handler` notification fan-out 对照约为 baseline `8.302 ns / 0 B`、`Mediator` `4.314 ns / 0 B`、`MediatR` `230.304 ns / 1256 B`、`GFramework.Cqrs` `434.413 ns / 408 B` -- `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/NotificationFanOutBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md` - - 结果:通过 -- `git diff --check` - - 结果:通过 - - 备注:仅剩 `GFramework.sln` 的历史 CRLF 提示,无本轮新增 diff 格式问题 -- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*NotificationBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:notification publish 三方对照当前约为 `Mediator` `1.108 ns / 0 B`、`MediatR` `97.173 ns / 416 B`、`GFramework.Cqrs` `291.582 ns / 392 B` -- `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/NotificationBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md` - - 结果:通过 -- `git diff --check` - - 结果:通过 - - 备注:仅剩 `GFramework.sln` 的历史 CRLF 提示,无本轮新增 diff 格式问题 -- `dotnet build GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - 备注:并行验证首轮曾因 `build` 与 `test` 同时写入同一输出 DLL 触发 `MSB3026` 单次复制重试;改为串行重跑同一命令后稳定通过 -- `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsDispatcherContextValidationTests"` - - 结果:通过,`6/6` passed -- `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherContextValidationTests.cs` - - 结果:通过 -- `git diff --check` - - 结果:通过 - - 备注:仅剩 `GFramework.sln` 的历史 CRLF 提示,无本轮新增 diff 格式问题 -- `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --format json --json-output /tmp/current-pr-review.json` - - 结果:通过 - - 备注:确认当前分支对应 `PR #342`;latest-head 当前显示 `CodeRabbit 4` / `Greptile 3` open thread,其中真正仍成立的是 benchmark handler 对称性、README / 中文文档示例与恢复文档锚点漂移,其余历史 thread 需要按当前 head 继续甄别 -- `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --json-output /tmp/current-pr-review.json` - - 结果:通过 - - 备注:确认当前分支对应 `PR #340`;latest-head 当前显示 `CodeRabbit 2` / `Greptile 2` open thread,且 `CTRF` 报告中唯一失败测试为 `CreateStream_Should_Throw_When_Stream_Pipeline_Behavior_Context_Does_Not_Implement_IArchitectureContext` -- `dotnet build GFramework.Core.Abstractions/GFramework.Core.Abstractions.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet build GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~MicrosoftDiContainerTests"` - - 结果:通过,`52/52` passed -- `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~CqrsDispatcherContextValidationTests"` - - 结果:通过,`4/4` passed -- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:按新性能回归门槛复跑后,steady-state request 对照约为 baseline `5.300 ns / 32 B`、`Mediator` `4.964 ns / 32 B`、`MediatR` `57.993 ns / 232 B`、`GFramework.Cqrs` `83.823 ns / 32 B` -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:按新性能回归门槛复跑后,`Singleton` 下 `GFramework.Cqrs` / `MediatR` 约 `83.183 ns / 32 B` vs `60.915 ns / 232 B`;`Transient` 下约 `86.243 ns / 56 B` vs `59.644 ns / 232 B` -- `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` - - 结果:通过 -- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/GeneratedStreamLifetimeBenchmarkRegistry.cs GFramework.Cqrs.Benchmarks/Messaging/StreamLifetimeBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md` - - 结果:通过 -- `git diff --check` - - 结果:通过 -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:steady-state request 对照约为 baseline `5.336 ns / 32 B`、`Mediator` `5.564 ns / 32 B`、`MediatR` `53.307 ns / 232 B`、`GFramework.Cqrs` `64.745 ns / 32 B` -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:`Singleton` 下 baseline / `MediatR` / `GFramework.Cqrs` 约 `4.309 ns / 51.923 ns / 67.981 ns`;`Transient` 下约 `5.029 ns / 54.435 ns / 76.437 ns` -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*StreamLifetimeBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:`Singleton` 下 baseline / `GFramework.Cqrs` / `MediatR` 约 `80.144 ns / 137.515 ns / 229.242 ns`,`Transient` 下约 `77.198 ns / 144.998 ns / 228.185 ns` -- `git diff --check` - - 结果:通过 - - 备注:当前仅保留 `GFramework.sln` 的历史 CRLF 警告,无本轮新增 diff 格式错误 -- `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~MicrosoftDiContainerTests"` - - 结果:通过,`52/52` passed -- `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~CqrsDispatcherCacheTests|FullyQualifiedName~CqrsDispatcherContextValidationTests"` - - 结果:通过,`14/14` passed -- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:本轮两批热路径收口后的最新 steady-state request 对照约为 baseline `6.141 ns / 32 B`、`Mediator` `6.674 ns / 32 B`、`MediatR` `61.803 ns / 232 B`、`GFramework.Cqrs` `70.298 ns / 32 B` -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:最新 lifetime request 对照约为 `Singleton` 下 baseline / `MediatR` / `GFramework.Cqrs` = `4.706 ns / 52.197 ns / 73.005 ns`,`Transient` 下 = `4.571 ns / 50.175 ns / 74.757 ns` -- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/GeneratedDefaultRequestBenchmarkRegistry.cs GFramework.Cqrs.Benchmarks/Messaging/BenchmarkHostFactory.cs GFramework.Cqrs.Benchmarks/Messaging/RequestBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md` - - 结果:通过 -- `git diff --check` - - 结果:通过 -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:默认 steady-state request 对照现约为 baseline `5.013 ns / 32 B`、`Mediator` `5.747 ns / 32 B`、`MediatR` `51.588 ns / 232 B`、`GFramework.Cqrs` `65.296 ns / 32 B` -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:最新 lifetime request 对照约为 `Singleton` 下 baseline / `MediatR` / `GFramework.Cqrs` = `4.817 ns / 48.177 ns / 68.772 ns`,`Transient` 下 = `4.841 ns / 51.753 ns / 73.157 ns` -- `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` - - 结果:通过 -- `git diff --check` - - 结果:通过 - - 备注:仍仅保留 `GFramework.sln` 的历史 CRLF 警告,无本轮新增 diff 格式问题 -- `dotnet pack GFramework.sln -c Release --no-restore -o /tmp/gframework-pack-validation -p:IncludeSymbols=false` - - 结果:通过 - - 备注:当前本地产物仅包含 14 个预期发布包,未生成 `GFramework.Cqrs.Benchmarks.*.nupkg` -- `bash scripts/validate-packed-modules.sh /tmp/gframework-pack-validation` - - 结果:通过 - - 备注:共享脚本确认 actual package set 与预期 14 个发布包完全一致 -- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~MicrosoftDiContainerTests"` - - 结果:通过,`51/51` passed -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:最新 steady-state request 对照约为 baseline `5.969 ns / 32 B`、`Mediator` `6.242 ns / 32 B`、`MediatR` `53.818 ns / 232 B`、`GFramework.Cqrs` `85.504 ns / 32 B` -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:`Singleton` 下 `GFramework.Cqrs` / `MediatR` 约 `84.066 ns / 32 B` vs `56.096 ns / 232 B`;`Transient` 下约 `90.652 ns / 56 B` vs `57.207 ns / 232 B` -- `python3 scripts/license-header.py --check` - - 结果:通过 -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestStartupBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:`ColdStart_GFrameworkCqrs` 已恢复出数,最新本地输出约 `220-292 us`,MediatR 对照约 `575-616 us`;当前仅剩 BenchmarkDotNet 对单次 cold-start 场景的 `MinIterationTime` 提示 -- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - 备注:用于验证本轮 request invoker / pipeline / stream invoker 调整与 benchmark workflow 改动后的 Release 编译结果 -- `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --format json --json-output /tmp/current-pr-review.json` - - 结果:通过 - - 备注:确认当前分支对应 `PR #334`;`CodeRabbit` latest review 已 `APPROVED`,但 latest-head 仍显示 `10` 个 open thread、`Greptile` 仍显示 `3` 个 open thread;本地逐项复核后未发现新的仍成立缺陷,最新 CI 测试汇总为 `2311/2311` passed,`MegaLinter` 仅剩 `dotnet-format` restore 环境噪音 -- `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --json-output /tmp/current-pr-review.json` - - 结果:通过 - - 备注:确认当前分支对应 `PR #339`;latest-head 显示 `2` 个 CodeRabbit open thread 与 `2` 个 nitpick;本轮本地接受并修复的问题集中在流式行为注册入口 XML 契约、stream continuation 线程说明与 `MicrosoftDiContainer` 的重复注册逻辑,测试方法拼写线程已在当前 head 失效 -- `dotnet format GFramework.Cqrs/GFramework.Cqrs.csproj --verify-no-changes` - - 结果:发现当前 diff 内 `GFramework.Cqrs/ICqrsRequestInvokerProvider.cs` 的空白格式问题;其余 `CHARSET` 提示集中在未触达的历史文件 -- `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet build GFramework.Core.Abstractions/GFramework.Core.Abstractions.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~CqrsDispatcherCacheTests"` - - 结果:通过,`10/10` passed -- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~ArchitectureModulesBehaviorTests"` - - 结果:通过,`4/4` passed -- `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` - - 结果:通过 -- `git diff --check` - - 结果:通过 -- `dotnet build GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~CommandExecutorTests|FullyQualifiedName~AsyncQueryExecutorTests"` - - 结果:通过,`19/19` passed -- `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --json-output /tmp/current-pr-review.json` - - 结果:通过 - - 备注:确认当前分支对应 `PR #334`;最新 review 仍为 `CodeRabbit APPROVED (2026-05-07T12:20:24Z)`,latest-head 显示 `CodeRabbit 10` / `Greptile 5` open thread;本轮接受并修复的仍成立问题收敛到 `LegacyCqrsDispatchHelper.TryResolveDispatchContext(...)` 的过宽异常吞掉逻辑 -- `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet build GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~CommandExecutorTests|FullyQualifiedName~QueryExecutorTests"` - - 结果:通过,`25/25` passed -- `python3 scripts/license-header.py --check` - - 结果:通过 -- `git diff --check` - - 结果:通过 -- `python3 scripts/license-header.py --check` - - 结果:通过 -- `git diff --check` - - 结果:通过 -- `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --format json --json-output ` - - 结果:通过 - - 备注:确认当前分支对应 `PR #331`,本轮 latest-head open AI feedback 已收敛到 `dotnet pack --no-build`、共享包校验脚本跨平台兼容性与 active 文档 PR 锚点同步 -- `python3 scripts/license-header.py --check` - - 结果:通过 - - 备注:当前 WSL worktree 需要显式绑定 `GIT_DIR` / `GIT_WORK_TREE` 后运行 -- `git diff --check` - - 结果:通过 -- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestLifetimeBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过(以沙箱外 `--no-build` 权威结果为准) - - 备注:`Singleton` 下 baseline / MediatR / GFramework 均值约 `5.633 ns / 58.687 ns / 301.731 ns`;`Transient` 下约 `5.044 ns / 52.274 ns / 287.863 ns` -- `python3 scripts/license-header.py --check` - - 结果:通过 - - 备注:当前 WSL worktree 需要显式绑定 `GIT_DIR` / `GIT_WORK_TREE` -- `git diff --check` - - 结果:通过 -- `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~ArchitectureContextTests|FullyQualifiedName~CommandExecutorTests|FullyQualifiedName~QueryExecutorTests|FullyQualifiedName~AsyncQueryExecutorTests"` - - 结果:通过,`45/45` passed -- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release` - - 结果:通过,`1644/1644` passed -- `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` - - 结果:通过 -- `git diff --check` - - 结果:通过 -- `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --json-output /tmp/current-pr-review.json` - - 结果:通过 - - 备注:确认当前分支对应 `PR #334`;仍有效的 latest-head review 已收敛到 legacy bridge 测试装配、运行时依赖契约、异步取消、XML 文档与兼容文档边界 -- `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - 备注:修复新增 XML 文档 warning 后复跑,当前 `GFramework.Core` 三个 target framework 均已干净通过 -- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~ArchitectureContextTests|FullyQualifiedName~ArchitectureModulesBehaviorTests|FullyQualifiedName~CommandExecutorTests|FullyQualifiedName~QueryExecutorTests|FullyQualifiedName~AsyncQueryExecutorTests"` - - 结果:通过,`48/48` passed - - 备注:覆盖 legacy bridge 兼容入口、测试装配、执行器 runtime fallback 与相关模块行为 -- `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` - - 结果:通过 -- `git diff --check` - - 结果:通过 -- `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~ArchitectureContextTests|FullyQualifiedName~ArchitectureModulesBehaviorTests|FullyQualifiedName~CommandExecutorTests|FullyQualifiedName~QueryExecutorTests|FullyQualifiedName~AsyncQueryExecutorTests|FullyQualifiedName~LegacyAsyncCommandDispatchRequestHandlerTests"` - - 结果:通过,`54/54` passed - - 备注:覆盖 legacy 同步 bridge 的同步上下文隔离、bridge fixture 容器释放,以及 async void command cancellation 可见性 -- `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` + - 备注:`Singleton 52.69 ns / 32 B`、`Transient 57.88 ns / 56 B`、`Scoped 144.72 ns / 368 B` +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --artifacts-suffix pr347-stream-scoped --filter "*StreamLifetimeBenchmarks.Stream_GFramework*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - 结果:通过 + - 备注:`Scoped + FirstItem` 约为 `266.7~267.0 ns / 792 B`,`Scoped + DrainAll` 约为 `331.6~332.2 ns / 856 B` ## 下一推荐步骤 -1. 若下一轮继续压 request steady-state,优先挑选仍能减少常量热路径查询/分支的切片;继续避开“类型级 `IContextAware` 判定缓存”这条已验证无收益的热点假设 -2. 若下一轮转向 benchmark 对齐,优先评估 `request scoped host + compile-time lifetime` 对照,而不是继续并行跑多个 BenchmarkDotNet 任务去争用同一自动生成目录 -3. 若下一轮回到 notification 线,应把问题重新收敛到“是否值得公开第三种仓库内置 publisher strategy”或“是否需要 `IServiceCollection` 版本的公开入口”,而不是继续重复扩同层级回归 +1. 再次运行 `$gframework-pr-review` 复核 `PR #347` latest-head open thread 是否已随本轮 head 收敛。 +2. 若 review 已清空,继续留在 `GFramework.Cqrs.Benchmarks` 单模块推进下一批 benchmark 对照,而不是立即扩散到 runtime。 +3. 若 review 仍保留 benchmark 相关线程,优先区分 stale 与新增结论,再决定是否需要新的 scoped-host 或 artifacts 入口修补。 ## 活跃文档 -- 历史跟踪归档:[cqrs-rewrite-history-through-rp043.md](../archive/todos/cqrs-rewrite-history-through-rp043.md) -- 验证历史归档:[cqrs-rewrite-validation-history-through-rp062.md](../archive/todos/cqrs-rewrite-validation-history-through-rp062.md) -- `RP-063` 至 `RP-074` 验证归档:[cqrs-rewrite-validation-history-rp063-through-rp074.md](../archive/todos/cqrs-rewrite-validation-history-rp063-through-rp074.md) -- `RP-062` 至 `RP-076` trace 归档:[cqrs-rewrite-history-rp062-through-rp076.md](../archive/traces/cqrs-rewrite-history-rp062-through-rp076.md) -- CQRS 与 Mediator 评估归档:[cqrs-vs-mediator-assessment-rp063.md](../archive/todos/cqrs-vs-mediator-assessment-rp063.md) -- 历史 trace 归档:[cqrs-rewrite-history-through-rp043.md](../archive/traces/cqrs-rewrite-history-through-rp043.md) -- `RP-046` 至 `RP-061` trace 归档:[cqrs-rewrite-history-rp046-through-rp061.md](../archive/traces/cqrs-rewrite-history-rp046-through-rp061.md) +- 当前 active tracking:`ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md` +- 当前 active trace:`ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` +- 当前历史归档: + - `ai-plan/public/cqrs-rewrite/archive/todos/cqrs-rewrite-migration-tracking-history-through-rp131.md` + - `ai-plan/public/cqrs-rewrite/archive/traces/cqrs-rewrite-migration-trace-history-through-rp131.md` ## 说明 -- `PR #261`、`PR #302`、`PR #305`、`PR #307` 及更早阶段的详细过程已不再作为 active 恢复入口;如需追溯,以对应归档文件或历史 trace 段落为准 -- active tracking 仅保留当前恢复点、当前风险、最近权威验证与下一推荐步骤,避免 `boot` 落到历史阶段细节 +- `RP-131` 及之前的长历史验证、阶段流水与旧恢复点说明已迁移到新的 `archive/` 文件,不再继续堆叠在 active 入口。 +- active tracking 现在只保留当前恢复点所需的最小事实、风险、权威验证与下一步,供 `boot` 与后续 PR review 快速恢复。 diff --git a/ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md b/ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md index b7d9eec2..d399a86c 100644 --- a/ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md +++ b/ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md @@ -1,1727 +1,66 @@ + + # CQRS 重写迁移追踪 ## 2026-05-11 -### 阶段:benchmark 并发运行隔离入口(CQRS-REWRITE-RP-131) - -- 延续 `$gframework-batch-boot 50`,在 `RP-130` 已确认冲突来自 BenchmarkDotNet 工件/生成目录层后,本轮继续保持写面只在 `GFramework.Cqrs.Benchmarks` 单模块,优先收口 benchmark 入口而不是回头改 benchmark 业务逻辑 -- 本轮主线程与 worker 边界: - - `README.md` 由 worker 独占,补 `--artifacts-suffix ` 的使用约定与两条并发 smoke 命令示例 - - `Program.cs` 起初交给独立 worker,但其回传超时;主线程随后接管该单文件实现,并主动关闭未返回的 worker,避免继续消耗上下文预算 -- 本轮主线程关键修正: - - 首版只设置 `IConfig.ArtifactsPath`,虽然把结果导出目录隔离到了 `BenchmarkDotNet.Artifacts/`,但并行 smoke 立刻暴露出 auto-generated benchmark 项目仍写回共享 `bin/Release/net10.0/GFramework.Cqrs.Benchmarks-Job-JWUHXL-1/` 目录,`RequestLifetimeBenchmarks` 再次命中 `.dll.config being used by another process` - - 因此本轮把实现升级为“独立宿主目录重启”模型:当存在 `--artifacts-suffix` 时,`Program.cs` 会先把当前 benchmark 宿主输出复制到 `BenchmarkDotNet.Artifacts//host/`,再从该目录重新启动同一个程序集,并通过环境变量把隔离后的 artifacts path 传递给子进程 - - 最终子进程里的 BenchmarkDotNet restore/build/output 路径均落到 `BenchmarkDotNet.Artifacts//host/GFramework.Cqrs.Benchmarks-Job-...`,从根上切断同名 job 目录在并发进程之间的共享 -- 本轮验证: - - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - 备注:中途曾引入 `MA0015`,已在同一轮把 `ThrowIfNull` 改成显式局部变量判空后清零 - - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Program.cs GFramework.Cqrs.Benchmarks/README.md` - - 结果:通过 - - `git diff --check` - - 结果:通过 - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --artifacts-suffix req-lifetime-a --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:实际执行路径已切到 `BenchmarkDotNet.Artifacts/req-lifetime-a/host/...` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --artifacts-suffix stream-invoker-b --filter "*StreamInvokerBenchmarks.Stream_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:实际执行路径已切到 `BenchmarkDotNet.Artifacts/stream-invoker-b/host/...` - - 两条命令并发运行时未再出现 `.dll.config being used by another process`,说明冲突已经从入口层实质收口 -- 本轮结论: - - `--artifacts-suffix` 现在不只是“结果目录标签”,而是完整的并发运行隔离开关:它会同时隔离 BenchmarkDotNet 最终导出目录与 auto-generated benchmark 项目工作目录 - - 这条修复只触及 benchmark 入口与文档,不影响 `Fixture`、generated registry、runtime 宿主或 benchmark 业务语义,因此评审面仍保持单模块、低风险边界 -- 下一恢复点: - - 若继续 benchmark 线,可直接复用新的并发隔离能力,同时跑互不冲突的 filtered short-job,而不必再人为串行化所有 BenchmarkDotNet smoke - - 优先候选仍是 `StreamInvokerBenchmarks` `DrainAll` 更稳定作业复核,或其他仅触达 `GFramework.Cqrs.Benchmarks` 的对照矩阵扩展 - -### 阶段:stream lifetime scoped 矩阵与 README 同步(CQRS-REWRITE-RP-130) - -- 延续 `$gframework-batch-boot 50`,在上一波把 `StreamingBenchmarks`、`StreamInvokerBenchmarks` 与 `RequestLifetimeBenchmarks` 扩成双观测 / scoped-request 基线后,本轮先不回到 runtime,而是只补齐 `StreamLifetimeBenchmarks` 的真实 `Scoped` stream 生命周期矩阵,并同步 benchmark `README` -- 本轮主线程验收与修正: - - 接受 worker 留在 `BenchmarkHostFactory.cs` 的 scoped stream helper 方向,但把实现收口为“创建 scope -> 在 scope 内创建 runtime / mediator -> 让 scope 覆盖完整 async stream 枚举周期”的包装迭代器,而不是只在建流阶段短暂持有作用域 - - `StreamLifetimeBenchmarks.cs` 现仅在 `Lifetime == Scoped` 时改走新的 scoped stream helper;`Singleton / Transient` 仍保持原有最小 steady-state 宿主,不把 scoped 宿主额外成本误混进其他矩阵 - - `GFramework.Cqrs.Benchmarks/README.md` 已同步 `RequestLifetimeBenchmarks` 与 `StreamLifetimeBenchmarks` 的 `Scoped` 现状,并把 `StreamInvokerBenchmarks` `DrainAll` 标成 smoke-only 结论 -- 本轮验证: - - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/BenchmarkHostFactory.cs GFramework.Cqrs.Benchmarks/Messaging/StreamLifetimeBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` - - 结果:通过 - - `git diff --check` - - 结果:通过 - - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*StreamLifetimeBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:`24` 个 case 全部跑通;`Scoped + FirstItem` 约为 baseline `56.24 ns`、`MediatR` `338.82 ns`、reflection `612.49 ns`、generated `628.65 ns`;`Scoped + DrainAll` 约为 baseline `81.20 ns`、`MediatR` `428.66 ns`、generated `692.05 ns`、reflection `716.61 ns` -- 本轮结论: - - `StreamLifetimeBenchmarks` 现在已经具备与 `RequestLifetimeBenchmarks` 对称的真实 scoped-host 作用域边界,后续不必再先修 benchmark 宿主才能观察 stream scoped lifetime - - `Scoped` 成本当前明显高于 `Singleton / Transient`,说明这条矩阵已经把“真实 scope 生命周期”本身的常量开销带入观测;这正是本轮想要确认的边界,而不是回归或异常 - - 本轮并没有改变 `GFramework.Cqrs` runtime 或业务逻辑,只是把 benchmark 宿主语义与文档描述对齐到当前事实 -- 下一恢复点: - - 优先切到 benchmark 运行隔离层,只动 `GFramework.Cqrs.Benchmarks/Program.cs` 与必要的 `README` 说明,解决两个过滤 benchmark 并行运行时共享 auto-generated build/artifacts 目录的问题 - - 新开的 explorer 已确认根因集中在 `Program.cs` 直接把 `args` 原样交给 `BenchmarkSwitcher.Run(args)`,当前没有为每次运行注入唯一 `ArtifactsPath`;不建议下一批回头改 `Fixture.cs` 或 benchmark 业务逻辑 - -### 阶段:benchmark 多 worker 波次与 scoped-host 基线(CQRS-REWRITE-RP-129) - -- 本轮从 `$gframework-batch-boot 50` 启动,但按 `gframework-multi-agent-batch` 规则把非阻塞工作拆成三条互不冲突的 benchmark 切片: - - `StreamingBenchmarks.cs`:默认 steady-state stream 宿主补 `FirstItem / DrainAll` - - `StreamInvokerBenchmarks.cs`:generated/reflection/MediatR invoker 对照补 `FirstItem / DrainAll` - - `RequestLifetimeBenchmarks.cs` + `BenchmarkHostFactory.cs` + `ScopedBenchmarkContainer.cs`:为 request lifetime 引入真实 scoped-host 作用域边界 -- 启动前已重新复核基线:`origin/main` 与本地 `main` 当前同为 `699d0b48`,启动时 `origin/main...HEAD` 为 `0 files / 0 lines`;因此先前 active 入口里的 `21 files` 已视为历史恢复信息,不再作为本轮 stop-condition 计数基线 -- worker 输出验收: - - `StreamingBenchmarks` worker 仅触达 `StreamingBenchmarks.cs`,并完成 `dotnet build ... -c Release` 与 `dotnet run ... --filter "*StreamingBenchmarks*"`;本轮保留其实现与 smoke 结果 - - `StreamInvokerBenchmarks` worker 只触达 `StreamInvokerBenchmarks.cs`,主线程保留其观测模式拆分;后续 smoke 验证改由主线程串行执行 - - `RequestLifetimeBenchmarks` worker 在 `BenchmarkHostFactory.cs` 与新建 `ScopedBenchmarkContainer.cs` 留下未编译完的 scoped-helper 草稿;主线程接手补齐 `using`、`IContextAware` 转发与 `IPrioritized` 命名空间,然后完成 `RequestLifetimeBenchmarks.cs` 的 scoped 接线 -- 本轮主线程关键修正: - - `ScopedBenchmarkContainer` 采用“根容器注册可见性 + 作用域 provider 实例解析”的只读适配层,避免在 request benchmark 里把 scoped handler 错误解析到根容器 - - `BenchmarkHostFactory.SendScopedGFrameworkRequestAsync(...)` 与 `SendScopedMediatRRequestAsync(...)` 统一封装每次 request 的显式 scope 创建/释放逻辑 - - 首次把 `StreamInvokerBenchmarks` 与 `RequestLifetimeBenchmarks` 并行跑 smoke 时触发 BenchmarkDotNet 自动生成目录争用;主线程按仓库规则改为串行重跑相同命令,并以串行结果为权威 -- 本轮验证: - - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/BenchmarkHostFactory.cs GFramework.Cqrs.Benchmarks/Messaging/RequestLifetimeBenchmarks.cs GFramework.Cqrs.Benchmarks/Messaging/ScopedBenchmarkContainer.cs GFramework.Cqrs.Benchmarks/Messaging/StreamInvokerBenchmarks.cs GFramework.Cqrs.Benchmarks/Messaging/StreamingBenchmarks.cs` - - 结果:通过 - - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*StreamInvokerBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过(串行权威结果) - - 备注:`FirstItem` 下 baseline / reflection / generated 约为 `5.84 ns / 52.90 ns / 59.44 ns`;`DrainAll` 报告当前呈现异常排序,应只把本次结果视作 smoke 运行通过信号,不直接当成稳定性能结论 - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过(串行权威结果) - - 备注:`Singleton` 下 baseline / `GFramework.Cqrs` / `MediatR` 约为 `5.23 ns / 53.43 ns / 56.35 ns`;`Scoped` 下约为 `5.60 ns / 575.92 ns / 170.94 ns`;`Transient` 下约为 `6.00 ns / 58.70 ns / 60.91 ns` -- 下一恢复点: - - 先把 `GFramework.Cqrs.Benchmarks/README.md` 与本 active tracking / trace 从旧 `PR #345 / 21 files` 状态刷新到当前 `699d0b48` 基线和本轮新矩阵 - - 然后判断 `StreamInvokerBenchmarks` 的 `DrainAll` smoke 输出是否需要单开一批稳定性复核;若只是 short-job 配置噪音,再考虑继续把 scoped host 扩到 stream lifetime,而不是现在就解读该组数字 - -## 2026-05-09 - -### 阶段:PR #345 latest-head review 收口(CQRS-REWRITE-RP-128) - -- 使用 `$gframework-pr-review` 抓取当前分支对应的 `PR #345`,确认 latest-head 没有新的 unresolved review thread,但 CodeRabbit 最新 review body 仍保留 `4` 条 actionable comments -- 本轮本地复核后接受并修复的反馈收敛到四类: - - `AGENTS.md` 的 multi-agent budget 术语缺少明确释义,影响新贡献者理解 stop condition - - `StreamLifetimeBenchmarks` 的 `ConsumeFirstItemAsync(...)` 未显式向枚举器传播 `CancellationToken`,且 `[EnumeratorCancellation]` 仍使用全限定名 - - `StreamLifetimeBenchmarks` 类级 `` 尚未解释 `FirstItem / DrainAll` 观测维度的取舍 - - `GFramework.Cqrs.Benchmarks/README.md` 与 `ai-plan/public/cqrs-rewrite/todos/**` 仍保留治理型 `RP-127` 表述、过期 `PR #344` 锚点与旧 branch diff 数字 -- 本轮验证计划保持最小化: - - 代码路径用 `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` 证明 benchmark 工程仍可编译 - - 文档与 tracking 更新后补跑 `python3 scripts/license-header.py --check --paths AGENTS.md GFramework.Cqrs.Benchmarks/Messaging/StreamLifetimeBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` -- 本轮验证结果: - - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `python3 scripts/license-header.py --check --paths AGENTS.md GFramework.Cqrs.Benchmarks/Messaging/StreamLifetimeBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` - - 结果:通过 -- 当前分支相对 `origin/main` (`d85828c5`) 的累计 branch diff 已复核为 `21 files / 1344 insertions / 194 deletions`,后续 active tracking 与 trace 均以这组数字为准 -- 下一恢复点: - - 推送本轮 commit 后,再次运行 `$gframework-pr-review` 复核 `PR #345` latest-head review body 是否已收敛 - - 若 stream lifetime 后续仍要继续压热路径,优先恢复 `Transient + FirstItem` 的小幅差值复核,而不是重新展开已收口的 `README` / `ai-plan` 漂移问题 - -### 阶段:stream lifetime 观测维度补齐与 generated binding 强类型缓存(CQRS-REWRITE-RP-127) - -- 延续 `$gframework-batch-boot 50`,在 `RP-126` 已建立四方 stream lifetime 口径后,本轮改用多 worker wave 同时推进三个互不冲突切片: - - `benchmark-only`:为 `StreamLifetimeBenchmarks` 增加 `FirstItem / DrainAll` 观测维度,并收口 `MA0004` - - `runtime-only`:把 `CqrsDispatcher.CreateStream(...)` 的 stream dispatch binding 改成按 `TResponse` 强类型缓存,避免 generated lane 在热路径上继续通过 `object -> IAsyncEnumerable` 桥接 - - `docs / ai-plan`:把 `RP-126` 的旧恢复结论更新为本轮实测结果,并给出下一恢复入口 -- 本轮主线程验收与修正: - - 首次并行验证时,`dotnet test` 与 `dotnet build` 同跑触发 `MSB3030` 输出争用;已按仓库规则改为串行重跑同一命令,并以串行结果为权威 - - runtime worker 初版在 `CqrsDispatcher.cs` 留下一个 `StreamInvoker` 方法组绑定编译错误;主线程已局部修正为显式 lambda 适配,未改变预期语义 - - 经修正后,generated lane 不再出现 “incompatible invoker signature” 运行时异常,`StreamLifetimeBenchmarks` 16 个 case 全部通过 -- 本轮验证: - - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsDispatcherCacheTests|FullyQualifiedName~CqrsGeneratedRequestInvokerProviderTests"` - - 结果:通过,`31/31` passed - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*StreamLifetimeBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:`Transient + FirstItem` 下 generated 约 `100.011 ns / 240 B`、reflection 约 `97.628 ns / 240 B`;`Transient + DrainAll` 下 generated 约 `116.780 ns / 304 B`、reflection 约 `124.174 ns / 304 B` -- 本轮结论: - - `FirstItem / DrainAll` 双观测维度把“建流到首个元素的瞬时成本”和“完整枚举总成本”拆开后,`Transient` 场景下的 generated lane 已不再呈现统一的反向退化 - - 当前仍保留的差值集中在 `Transient + FirstItem`,规模约 `2.4 ns`,明显小于 `RP-126` 的旧结论;而 `Transient + DrainAll` 已转为 generated 领先 reflection - - 当前分支相对 `origin/main` 的累计 branch diff 已到 `21 files`(`1231 insertions / 181 deletions`),仍低于 `$gframework-batch-boot 50` 阈值;但主线程已接近当前回合的安全上下文预算,因此在本轮自然边界停止,不继续开下一波 worker -- 下一恢复点: - - 若继续 benchmark 线,先从 `Transient + FirstItem` 的小幅差值恢复,并用 `StreamInvokerBenchmarks` 复核 generated lane 的常量成本收益是否仍成立;若差值不稳定,再考虑把下一批切到 `Mediator` concrete runtime 的 stream lifetime 对照 - - 若切回 runtime 线,则以 `b7fa3eee` 与本轮 `StreamLifetimeBenchmarks` 双口径结果作为后续回归基线 - -### 阶段:stream lifetime 对照口径补齐(CQRS-REWRITE-RP-126) - -- 延续 `$gframework-batch-boot 50`,在 `RP-125` 先把 request lifetime benchmark 宿主对齐到 generated-provider 路径后,本轮继续补齐 stream 生命周期矩阵的当前对照口径,不回到 runtime 或测试代码 -- 本轮主线程决策: - - 只修改 `GFramework.Cqrs.Benchmarks/Messaging/GeneratedStreamLifetimeBenchmarkRegistry.cs` 与 `StreamLifetimeBenchmarks.cs`,不扩散到 `GFramework.Cqrs` runtime、README 或 docs - - 将 stream lifetime 的 GFramework reflection、GFramework generated 与 `MediatR` 请求/响应/handler 类型拆开,避免不同宿主继续共用同一 stream 合同而污染对照语义 - - 将 generated registry 收口为只绑定 `GeneratedBenchmarkStreamRequest/Response` 这一条 generated lane,避免静态 dispatcher cache 把 reflection 与 generated 结果混在一起 -- 本轮验证: - - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*StreamLifetimeBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:`Singleton` 下 baseline / generated / reflection / `MediatR` 约为 `79.602 ns / 280 B`、`111.547 ns / 280 B`、`120.553 ns / 280 B`、`208.381 ns / 672 B`;`Transient` 下 baseline / reflection / generated / `MediatR` 约为 `76.351 ns / 280 B`、`119.632 ns / 304 B`、`129.166 ns / 304 B`、`213.420 ns / 672 B` -- 本轮结论: - - 当前 stream 生命周期矩阵已经具备可直接比较 `baseline / reflection / generated / MediatR` 的四方口径,后续恢复时无需再回头拼接不同批次的 stream 生命周期数据 - - 当前短跑下,generated lane 在 `Singleton` 档优于 reflection,但在 `Transient` 档仍慢于 reflection,差值约为 `9.5 ns` 与 `24 B`;这里先只把它记录为 benchmark 观察,不把它放大成更宽泛的 runtime 优劣结论 - - 当前已提交分支相对 `origin/main`(`d85828c5`, `2026-05-09 12:25:41 +0800`)的累计 branch diff 已到 `10 files`(`556 insertions / 75 deletions`),仍远低于 `$gframework-batch-boot 50` 的 `50 files` stop condition -- 下一恢复点: - - 若继续 benchmark 线,优先从 `Stream_GFrameworkGenerated` 与 `Stream_GFrameworkReflection` 的 `Transient` 差值恢复,先确认该差值是否稳定,再决定继续压 generated 宿主的瞬时解析成本,或单开 `Mediator` concrete runtime 的 stream lifetime 对照批次;若切回 runtime 线,则以 `RP-126` 的四方矩阵作为后续性能回归基线 - -### 阶段:request lifetime generated-provider 宿主对齐(CQRS-REWRITE-RP-125) - -- 延续 `$gframework-batch-boot 50`,在 `RP-124` 收口 stream behavior presence cache 后,本轮先不继续改 dispatcher,而是回头补齐 request lifetime benchmark 宿主路径,让生命周期矩阵与当前默认 request steady-state 的 generated-provider 口径重新对齐 -- 本轮主线程决策: - - 只修改 `GFramework.Cqrs.Benchmarks/Messaging/GeneratedRequestLifetimeBenchmarkRegistry.cs` 与 `RequestLifetimeBenchmarks.cs` - - 为 request lifetime 补入 handwritten generated registry,只暴露最小 generated request descriptor,再由 benchmark 主体显式控制 `Singleton / Transient` handler 生命周期 - - 在 setup / cleanup 统一清理 dispatcher cache,避免不同生命周期矩阵之间共享静态缓存而污染结果 -- 本轮验证: - - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:`Singleton` 下 baseline / `GFramework.Cqrs` / `MediatR` 约为 `5.012 ns / 32 B`、`49.612 ns / 32 B`、`51.796 ns / 232 B`;`Transient` 下约为 `3.962 ns / 32 B`、`50.480 ns / 56 B`、`50.284 ns / 232 B` -- 本轮结论: - - request lifetime 宿主现已与当前 generated-provider request 宿主保持一致,后续不再需要把旧生命周期矩阵结果与 generated steady-state 数据做“跨宿主”比较 - - 当前短跑下,`Singleton` 仍稳定快于 `MediatR`,`Transient` 已缩到基本持平但仍略慢;这给下一步 stream 线 benchmark 同步提供了更干净的 request 基线 -- 下一恢复点: - - 继续补齐 `StreamLifetimeBenchmarks` 的当前对照口径,把 `baseline / reflection / generated / MediatR` 四方生命周期矩阵补完整 - -### 阶段:stream behavior presence cache(CQRS-REWRITE-RP-124) - -- 延续 `$gframework-batch-boot 50`,在 `RP-123` 收口 notification publisher review 线程后,继续把 `CqrsDispatcher` 的 stream 热路径与 `RP-122` 的 request hot path 对齐,选择“缓存 `CreateStream(...)` 的 behavior presence 判定”这一条最小且可验证的 runtime 切片 -- 本轮主线程决策: - - 仅修改 `GFramework.Cqrs/Internal/CqrsDispatcher.cs`、`GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherCacheTests.cs`,并新增 `DispatcherZeroPipelineStreamRequest/Handler` 测试桩,不扩散到新的公开 API、中文文档或额外 benchmark 宿主实现 - - 为 `CqrsDispatcher` 新增实例级 `_streamBehaviorPresenceCache`,按闭合 `IStreamPipelineBehavior<,>` 服务类型缓存当前 dispatcher 容器中的服务可见性,让 `CreateStream(...)` 在 steady-state 下不再重复调用 `HasRegistration(Type)` - - 在 `CqrsDispatcherCacheTests` 新增 `Dispatcher_Should_Cache_Stream_Behavior_Presence_Per_Dispatcher_Instance()`,显式锁住“同容器共享同一 dispatcher/cache、独立容器不共享”的实例级边界,并把缓存值与容器实际 `HasRegistration(...)` 语义对齐,避免测试再依赖夹具对某个具体 stream 类型的错误可见性假设 -- 本轮验证: - - `python3 scripts/license-header.py --check --paths GFramework.Cqrs/Internal/CqrsDispatcher.cs GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherCacheTests.cs GFramework.Cqrs.Tests/Cqrs/DispatcherZeroPipelineStreamRequest.cs GFramework.Cqrs.Tests/Cqrs/DispatcherZeroPipelineStreamHandler.cs` - - 结果:通过 - - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet build GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~CqrsDispatcherCacheTests"` - - 结果:通过,`12/12` passed - - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*StreamLifetimeBenchmarks.Stream_GFrameworkCqrs*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:`Singleton` 约 `107.241 ns / 240 B`,`Transient` 约 `119.434 ns / 264 B` - - `git diff --check` - - 结果:通过 - - 备注:仅剩 `GFramework.sln` 的历史 CRLF 提示,无本轮新增 diff 格式问题 -- 下一恢复点: - - 推送本轮 commit 后,再次运行 `$gframework-pr-review` 复核 `PR #344` latest-head thread 是否已收敛;若 review 已清空,则下一批优先补完整 `StreamLifetimeBenchmarks` 三方对照,再决定继续压 stream 零管道常量路径还是切回 request `Transient` 热点 - -### 阶段:PR #344 latest-head review 收尾(CQRS-REWRITE-RP-123) - -- 使用 `$gframework-pr-review` 重新抓取当前分支 PR,确认当前 worktree 对应 `PR #344`,latest-head 仍有 `CodeRabbit 2` / `Greptile 1` open thread -- 主线程逐条复核后确认仍成立的问题: - - `CodeRabbit` 对 `NotificationPublisherRegistrationExtensionsTests` 的“唯一注册”断言建议仍有效 - - `CodeRabbit` 对 strict `IIocContainer` mock 缺少 `GetAll(typeof(INotificationPublisher))` 默认装配的 CI 失败结论仍有效,且更适合在两个测试 helper 层统一兜底 - - `CodeRabbit` 对 `CqrsDispatcherCacheTests` 的共享装配 helper 建议仍有效,属于真实维护性风险而非纯样式问题 - - `Greptile` 指出的 `ResolveNotificationPublisher()` 热路径重复 `GetAll(...)` 与默认 publisher 重复分配也成立;由于容器在 publish 前已冻结,dispatcher 生命周期内可以安全缓存最终解析结果 -- 本轮决策: - - 为 `CqrsDispatcher` 增加 dispatcher 实例级 `_resolvedNotificationPublisher` 缓存,并使用线程安全比较交换固定首次解析出的最终策略实例 - - 在 `CqrsDispatcherContextValidationTests` 与 `CqrsNotificationPublisherTests` 的 strict mock runtime helper 中统一预设 `GetAll(typeof(INotificationPublisher))` 返回空集合 - - 在 `NotificationPublisherRegistrationExtensionsTests` 为泛型组合根重载补上 `INotificationPublisher` 唯一注册断言 - - 在 `CqrsDispatcherCacheTests` 提取共享的 `ConfigureDispatcherCacheFixture(...)`,消除 `SetUp()` 与 `CreateFrozenContainer()` 的注册漂移风险 -- 本轮验证: - - `python3 scripts/license-header.py --check --paths GFramework.Cqrs/Internal/CqrsDispatcher.cs GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherContextValidationTests.cs GFramework.Cqrs.Tests/Cqrs/CqrsNotificationPublisherTests.cs GFramework.Cqrs.Tests/Cqrs/NotificationPublisherRegistrationExtensionsTests.cs GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherCacheTests.cs ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` - - 结果:通过 - - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - 备注:首轮与 `GFramework.Cqrs.Tests` 并行构建时出现 `MSB3026` 单次复制重试;串行重跑后稳定通过,判定为输出目录竞争噪音 - - `dotnet build GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~CqrsDispatcherContextValidationTests|FullyQualifiedName~CqrsNotificationPublisherTests|FullyQualifiedName~NotificationPublisherRegistrationExtensionsTests|FullyQualifiedName~CqrsDispatcherCacheTests"` - - 结果:通过,`30/30` passed - - `git diff --check` - - 结果:通过 -- 下一恢复点: - - 推送本轮 commit 后,再次运行 `$gframework-pr-review` 复核 `PR #344` latest-head open thread 是否已随新 head 收敛;若仍残留 open thread,再区分 stale 状态与新增 review - -### 阶段:request 零管道 behavior presence cache(CQRS-REWRITE-RP-122) - -- 延续 `$gframework-batch-boot 50`,本轮在 `RP-121` 把 notification 线阶段性收口后,重新回到 request steady-state 常量开销,并接受并行 explorer 的共同结论:下一刀应继续减少每次 `SendAsync(...)` 必经的通用查询,而不是回头优化 `HasRegistration(Type)` 内部实现或重试已证伪的 `IContextAware` 类型缓存 -- 本轮主线程决策: - - 只改 `GFramework.Cqrs/Internal/CqrsDispatcher.cs` 与 `GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherCacheTests.cs`,不同时打开 scoped benchmark 宿主或 notification 新公开 API 两条线 - - 为 `CqrsDispatcher` 新增 `_requestBehaviorPresenceCache`,按闭合 `IPipelineBehavior<,>` 服务类型缓存“当前 dispatcher 的容器里是否存在该 request behavior 注册” - - 保持优化面只覆盖 request `0 pipeline` 热路径;stream 对称缓存与 scoped host benchmark 继续留到后续独立批次 - - 在 `CqrsDispatcherCacheTests` 新增实例级回归,明确“同容器多个 `ArchitectureContext` 解析到同一个 runtime/dispatcher,会共享该缓存;另一独立容器创建的 dispatcher 不共享该缓存” -- 本轮权威验证: - - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsDispatcherCacheTests"` - - 结果:通过,`11/11` passed - - 备注:新增回归首轮曾因错误假设“不同 `ArchitectureContext` 必定对应不同 dispatcher”而失败;修正为“同容器共享 runtime、独立容器不共享缓存”后稳定通过 - - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:默认 request steady-state 当前约为 baseline `5.876 ns / 32 B`、`Mediator` `5.275 ns / 32 B`、`GFramework.Cqrs` `51.717 ns / 32 B`、`MediatR` `56.108 ns / 232 B` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:首次与 `RequestBenchmarks` 并行触发时,BenchmarkDotNet 自动生成项目目录发生 `.nuget.g.props already exists` 冲突;改为串行重跑同一命令后,`Singleton` 下 baseline / `GFramework.Cqrs` / `MediatR` 约 `5.720 ns / 52.490 ns / 56.890 ns`,`Transient` 下约 `5.814 ns / 57.746 ns / 55.545 ns` - - `python3 scripts/license-header.py --check --paths GFramework.Cqrs/Internal/CqrsDispatcher.cs GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherCacheTests.cs` - - 结果:通过 -- 本轮结论: - - request `0 pipeline` 常量路径再次被压短,默认 steady-state request 与 `Singleton` lifetime 均继续快于当前 `MediatR` short-job 基线 - - `Transient` 仍略慢于 `MediatR`,但相较更早轮次已明显收敛;下一轮若继续 request 热点,更值得继续减少 steady-state 必经路径,或切到 explorer 建议的 `request scoped host + compile-time lifetime` 对齐线,而不是继续打磨已收益有限的 `HasRegistration(Type)` 内部细节 - -### 阶段:标准架构启动路径 notification publisher 回归(CQRS-REWRITE-RP-121) - -- 延续 `$gframework-batch-boot 50`,本轮没有继续扩 notification runtime 语义,而是先给 `RP-120` 刚修复的默认接线补一条更贴近生产的架构启动回归 -- 本轮主线程决策: - - 保持写面只落在 `GFramework.Core.Tests/Architectures/ArchitectureModulesBehaviorTests.cs`,不再改动 `GFramework.Cqrs` / `GFramework.Core` 运行时代码 - - 通过 `Architecture.Configurator` 注册依赖容器 probe 的自定义 `INotificationPublisher`,并在 `OnInitialize()` 显式接入额外程序集 notification handler,验证默认 `Architecture.InitializeAsync()` 路径最终 publish 时不会退回默认顺序策略 - - 用现有 `AdditionalAssemblyNotificationHandlerRegistry` 测试桩承载 handler 执行观察,把本轮信号收敛到“标准架构启动路径是否真正复用自定义 publisher” -- 本轮权威验证: - - `dotnet build GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~ArchitectureModulesBehaviorTests"` - - 结果:通过,`5/5` passed - - `python3 scripts/license-header.py --check --paths GFramework.Core.Tests/Architectures/ArchitectureModulesBehaviorTests.cs` - - 结果:通过 -- 本轮结论: - - 标准 `Architecture.InitializeAsync()` 启动路径现在也被回归锁住:通过 `Configurator` 声明的自定义 `INotificationPublisher` 会在真实 publish 路径里被复用,不会再被 `CqrsRuntimeModule` 创建 runtime 时静默短路成默认顺序发布器 - - notification 线当前已形成“组合根入口 -> 默认接线修复 -> 标准架构启动回归”的闭环;下一轮若继续留在该方向,更合理的是重新评估产品面是否真的需要第三种仓库内置策略,而不是继续堆同层级回归 - -### 阶段:notification publisher 默认接线修复(CQRS-REWRITE-RP-120) - -- 延续 `$gframework-batch-boot 50`,本轮沿着 `RP-119` 的 notification publisher 组合根回归继续向下追,发现这不是单纯的文档或测试补洞,而是默认 runtime 接线存在真实时序缺陷 -- 本轮主线程决策: - - 保持修复面收敛在 notification publisher 单线,不把问题扩散到 request dispatch 热路径或无关模块 - - 让 `CqrsRuntimeFactory.CreateRuntime(...)` 不再在工厂层把 `null` publisher 立即替换成 `SequentialNotificationPublisher`,改由 `CqrsDispatcher` 在真正 publish 时优先复用显式实例或容器内唯一注册策略,最后才回退到默认顺序发布器 - - 同步移除 `CqrsRuntimeModule` 与 `GFramework.Tests.Common/CqrsTestRuntime` 里对 `container.Get()` 的预解析,避免冻结前可见性再次把策略短路掉 - - 在 `NotificationPublisherRegistrationExtensionsTests` 新增“publisher 依赖容器内探针服务”的真实采用回归,并重新验证 `UseTaskWhenAllNotificationPublisher()` 在默认基础设施路径里会继续调度所有处理器 -- 本轮权威验证: - - `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~NotificationPublisherRegistrationExtensionsTests"` - - 结果:通过,`7/7` passed - - `python3 scripts/license-header.py --check --paths GFramework.Cqrs/Internal/CqrsDispatcher.cs GFramework.Cqrs/CqrsRuntimeFactory.cs GFramework.Core/Services/Modules/CqrsRuntimeModule.cs GFramework.Tests.Common/CqrsTestRuntime.cs GFramework.Cqrs.Tests/Cqrs/NotificationPublisherRegistrationExtensionsTests.cs` - - 结果:通过 - - `git diff --check` - - 结果:通过 -- 本轮结论: - - `UseTaskWhenAllNotificationPublisher()` 与 `UseNotificationPublisher()` 现在不再只是“能注册进容器”,而是能真正穿过默认 runtime 基础设施参与 publish 路径 - - 本轮属于完整的语义修复批次,应在提交后再决定是否继续 notification 线或切回 request steady-state 热点 - -### 阶段:notification publisher 泛型组合根入口收口(CQRS-REWRITE-RP-119) - -- 延续 `$gframework-batch-boot 50`,本轮在 `feat/cqrs-optimization` 已与 `origin/main` 对齐后,没有直接重开 request dispatch 热路径实验,而是先选择 notification publisher 线上一个更小、可直接评审的采用面切片 -- 本轮主线程决策: - - 保持 `GFramework.Cqrs` runtime 代码不变,只补 `UseNotificationPublisher()` 的组合根回归与用户文档说明 - - 在 `NotificationPublisherRegistrationExtensionsTests` 新增两条 targeted 回归,确认泛型重载会注册唯一单例策略,且在容器已存在 `INotificationPublisher` 时同样会拒绝重复声明 - - 在 `GFramework.Cqrs/README.md` 与 `docs/zh-CN/core/cqrs.md` 把自定义入口统一写成 `UseNotificationPublisher(...)` / `UseNotificationPublisher()`,并明确实例重载与泛型重载的生命周期边界 -- 本轮权威验证: - - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~NotificationPublisherRegistrationExtensionsTests"` - - 结果:通过,`6/6` passed - - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Tests/Cqrs/NotificationPublisherRegistrationExtensionsTests.cs GFramework.Cqrs/README.md docs/zh-CN/core/cqrs.md ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` - - 结果:通过 - - `git diff --check` - - 结果:通过 -- 本轮结论: - - notification publisher 的组合根采用面现在不再默认读者只能“手里先有一个实例”;文档与回归都已明确容器托管型自定义 publisher 的标准入口 - - 这批仍然保持在低风险、单模块、易评审边界内,适合在完成验证后直接收口为新的恢复点 - -## 2026-05-08 - -### 阶段:PR #342 latest-head review 收口(CQRS-REWRITE-RP-118) - -- 使用 `$gframework-pr-review` 抓取 `feat/cqrs-optimization` 当前公开 PR,并确认当前锚点已从 `PR #341` 更新为 `PR #342` -- 本轮 latest-head review 结论: - - `CodeRabbit` 当前仍成立的是 `NotificationFanOutBenchmarks.cs` 中 MediatR 显式 `Handle(...)` 直接返回 `Task.CompletedTask`,导致该对照组绕过共享 `HandleCore(...)` 的空值 / 取消校验 - - `CodeRabbit` 对 `ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md` 的两条评论也成立:当前恢复点锚点仍写 `PR #341`,且“最近权威验证”里的 fan-out 数值属于更早轮次,需要显式标注历史来源 - - `Greptile` 额外指出 `GFramework.Cqrs/README.md` 与 `docs/zh-CN/core/cqrs.md` 里 `UseTaskWhenAllNotificationPublisher()` 示例包含多余 `using GFramework.Cqrs.Notification;`;这条在当前 head 仍成立 - - MegaLinter 仍报告 `dotnet-format` restore 失败,但这属于 CI 环境 restore 噪声,不是当前 diff 的格式违规;README 的 MD058 空行问题仍需在本地直接修复 -- 本轮主线程决策: - - 让 `NotificationFanOutBenchmarks` 的四个 MediatR handler 显式转发到 `HandleCore(notification, cancellationToken).AsTask()`,保持与 baseline、`GFramework.Cqrs` 和 NuGet `Mediator` 分支一致的前置检查 - - 在 `GFramework.Cqrs/README.md` 修复表格前后空行,并删除 README / 中文文档中 `UseTaskWhenAllNotificationPublisher()` 示例的多余 `using` - - 把 `cqrs-rewrite` tracking 当前恢复点推进到 `RP-118`,同步 `PR #342` 锚点,并把早期 fan-out 数值显式标成 `历史基线(RP-112)` -- 本轮权威验证: - - `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --format json --json-output /tmp/current-pr-review.json` - - 结果:通过 - - 备注:确认当前分支对应 `PR #342`;CodeRabbit 当前 `4` 条 actionable comments 与 Greptile `3` 条 open thread 已作为本轮本地复核输入 - - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*NotificationFanOutBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:本轮对称化 MediatR handler 后,fixed `4 handler` fan-out 对照约为 `Mediator` `3.598 ns / 0 B`、baseline `7.033 ns / 0 B`、`MediatR` `257.533 ns / 1256 B`、`GFramework.Cqrs` 顺序 `409.557 ns / 408 B`、`TaskWhenAll` `484.531 ns / 496 B` - - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/NotificationFanOutBenchmarks.cs GFramework.Cqrs/README.md docs/zh-CN/core/cqrs.md ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` - - 结果:通过 - - `git diff --check` - - 结果:通过 - - 备注:仅剩 `GFramework.sln` 的历史 CRLF 提示,无本轮新增 diff 格式问题 - -### 阶段:notification publisher 采用矩阵文档收口(CQRS-REWRITE-RP-117) - -- 延续 `$gframework-batch-boot 50`,本轮没有继续把自动批处理推到新的 runtime seam,而是先按 tracking 建议复核“notification 线是否还缺采用边界文档”: - - 当前分支相对 `origin/main`(`7ca21af9`, `2026-05-08 16:12:20 +0800`)的累计 branch diff 约为 `12 files`,仍明显低于 `50` 文件阈值 - - 主线程先短试了一刀 request dispatch 热路径微优化:把 dispatcher 中“运行时类型是否实现 `IContextAware`”改成弱键缓存,并按性能治理规则复跑 `RequestBenchmarks` 与 `RequestLifetimeBenchmarks` - - 复跑结果表明这条假设没有正收益:默认 steady-state request 回到约 `71.824 ns / 32 B`,`Singleton / Transient` lifetime 约为 `73.191 ns / 32 B` 与 `80.468 ns / 56 B`,因此本轮在同一提交前已完全撤回该运行时代码实验,不把负收益热点带进后续恢复点 -- 本轮主线程决策: - - 保持 `GFramework.Cqrs` runtime 与测试代码不变,只更新 `GFramework.Cqrs/README.md` 与 `docs/zh-CN/core/cqrs.md` - - 把 `SequentialNotificationPublisher`、`TaskWhenAllNotificationPublisher` 与 `UseNotificationPublisher(...)` 自定义实例三条路径收口到同一张策略矩阵 - - 在用户文档里明确 `TaskWhenAllNotificationPublisher` 是“并行完成 + 聚合失败”语义策略,而不是 fixed fan-out publish 的性能开关 -- 本轮权威验证: - - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsDispatcherCacheTests|FullyQualifiedName~CqrsDispatcherContextValidationTests"` - - 结果:通过,`17/17` passed - - 备注:首轮与 build 并行触发时出现 `MSB3026` 单次复制重试告警,但同一命令最终稳定通过,未形成代码失败 - - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:用于否决本轮已撤回的热点假设;默认 steady-state request 对照约为 baseline `5.853 ns / 32 B`、`Mediator` `6.256 ns / 32 B`、`MediatR` `53.401 ns / 232 B`、`GFramework.Cqrs` `71.824 ns / 32 B` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:用于否决本轮已撤回的热点假设;`Singleton` 下 baseline / `MediatR` / `GFramework.Cqrs` 约 `5.259 ns / 58.415 ns / 73.191 ns`,`Transient` 下约 `4.914 ns / 57.150 ns / 80.468 ns` -- 本轮结论: - - notification publisher 公开入口现在不仅有显式顺序 / 并行 API,也有更直接的策略选择矩阵;读者不再需要从分散段落里拼装“什么时候该选哪条策略” - - request dispatch 热路径的下一轮探索应显式绕开“类型级 `IContextAware` 判定缓存”这一条已验证无收益的方向,把 context budget 留给更可能影响 steady-state 的热点 - - 当前仍可继续自动推进,但若再开一批 runtime 性能实验,应放在新的自然批次里,避免把已否决假设和新热点混在同一评审单元中 - -### 阶段:公开顺序 notification publisher 策略(CQRS-REWRITE-RP-116) - -- 延续 `$gframework-batch-boot 50`,本轮继续留在 notification publisher 配置面,但不再新增第三方 benchmark 或 runtime seam: - - 当前分支相对 `origin/main`(`7ca21af9`, `2026-05-08 16:12:20 +0800`)的累计 branch diff 在 `RP-115` 提交后约为 `11 files`,明显低于 `50` 文件阈值 - - `RP-115` 已把采用路径收口到显式组合根扩展,但当前仍只有 `TaskWhenAllNotificationPublisher` 是公开内置策略;默认顺序语义仍主要靠“未注册时的隐式回退”表达 -- 本轮主线程决策: - - 新增公开 `GFramework.Cqrs/Notification/SequentialNotificationPublisher.cs`,并让 `CqrsRuntimeFactory` 默认回退直接使用这条公开顺序策略 - - 删除 `GFramework.Cqrs/Internal/SequentialNotificationPublisher.cs` 的内部副本,避免默认顺序语义同时存在“内部实现”和“公开实现”两套类型来源 - - 为 `NotificationPublisherRegistrationExtensions` 增加 `UseSequentialNotificationPublisher()`,并在回归与用户文档中把“显式顺序策略”与“显式并行策略”作为对称选择面呈现 -- 本轮权威验证: - - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~NotificationPublisherRegistrationExtensionsTests|FullyQualifiedName~CqrsNotificationPublisherTests"` - - 结果:通过,`10/10` passed - - `python3 scripts/license-header.py --check --paths GFramework.Cqrs/Notification/SequentialNotificationPublisher.cs GFramework.Cqrs/CqrsRuntimeFactory.cs GFramework.Cqrs/Extensions/NotificationPublisherRegistrationExtensions.cs GFramework.Cqrs.Tests/Cqrs/NotificationPublisherRegistrationExtensionsTests.cs GFramework.Cqrs/README.md docs/zh-CN/core/cqrs.md ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` - - 结果:通过 - - `git diff --check` - - 结果:通过 -- 本轮结论: - - notification publisher 的公开配置面现已从“一个显式策略 + 一个隐式默认回退”收口成两条对称的内置策略选择:`UseSequentialNotificationPublisher()` 与 `UseTaskWhenAllNotificationPublisher()` - - 若后续继续 notification 线,更合理的下一刀会是补更细的采用文档或新的策略语义,而不是继续让顺序 / 并行这两条基础选择停留在隐式约定上 - -### 阶段:notification publisher 组合根配置面(CQRS-REWRITE-RP-115) - -- 延续 `$gframework-batch-boot 50`,本轮不再回到 benchmark 宿主,而是沿着 `RP-114` 已明确的性能/语义事实继续收口用户接入缺口: - - 当前分支相对 `origin/main`(`7ca21af9`, `2026-05-08 16:12:20 +0800`)的累计 branch diff 在启动时仍为 `9 files`,明显低于 `50` 文件阈值 - - `RP-113` / `RP-114` 已证明内置 `TaskWhenAllNotificationPublisher` 的价值主要是语义补齐,但当前用户若要采用它,仍需知道 `INotificationPublisher` 的底层注册细节 -- 本轮主线程决策: - - 新增 `GFramework.Cqrs/Extensions/NotificationPublisherRegistrationExtensions.cs`,提供 `UseNotificationPublisher(...)`、`UseNotificationPublisher()` 与 `UseTaskWhenAllNotificationPublisher()` 三个显式组合根入口 - - 在 `GFramework.Cqrs.Tests/Cqrs/NotificationPublisherRegistrationExtensionsTests.cs` 补齐回归,确认默认 runtime 基础设施会复用 `UseTaskWhenAllNotificationPublisher()`,且重复策略注册会在组合根阶段被显式阻止 - - 更新 `GFramework.Cqrs/README.md` 与 `docs/zh-CN/core/cqrs.md`,把推荐用法改成组合根扩展,并把 `RP-114` 的 benchmark 结论翻译成用户可用的采用边界 -- 本轮权威验证: - - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~NotificationPublisherRegistrationExtensionsTests|FullyQualifiedName~CqrsNotificationPublisherTests"` - - 结果:通过,`9/9` passed - - `python3 scripts/license-header.py --check --paths GFramework.Cqrs/Extensions/NotificationPublisherRegistrationExtensions.cs GFramework.Cqrs.Tests/Cqrs/NotificationPublisherRegistrationExtensionsTests.cs GFramework.Cqrs/README.md docs/zh-CN/core/cqrs.md ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` - - 结果:通过 - - `git diff --check` - - 结果:通过 -- 本轮结论: - - 这一批已把 notification publisher 的采用路径从“理解内部 seam”收口成“在组合根里显式选择策略”,并让重复策略注册在配置阶段就得到清晰失败信号 - - 若后续仍继续 notification 线,更合理的下一刀会是补第二个内置策略或更细的采用文档,而不是继续要求用户手写容器底层注册 - -### 阶段:`TaskWhenAll` notification publisher fan-out benchmark(CQRS-REWRITE-RP-114) - -- 延续 `$gframework-batch-boot 50`,本轮不再扩新的 notification runtime 能力,而是沿着 `RP-113` 刚落地的内置并行 publisher 继续补验证口径: - - 当前分支相对 `origin/main`(`7ca21af9`, `2026-05-08 16:12:20 +0800`)的累计 branch diff 启动时为 `9 files`,明显低于 `50` 文件阈值 - - `RP-112` 只量化了默认顺序发布器的 fixed `4 handler` fan-out 成本;`RP-113` 已把 `TaskWhenAllNotificationPublisher` 引入 production runtime,但还没有 benchmark 说明“能力差距收口后,代价是多少” -- 本轮主线程决策: - - 在 `GFramework.Cqrs.Benchmarks/Messaging/NotificationFanOutBenchmarks.cs` 同时保留 `baseline`、默认顺序 `GFramework.Cqrs`、内置 `TaskWhenAllNotificationPublisher`、NuGet `Mediator` concrete runtime 与 `MediatR` 五组对照 - - 复用同一个冻结 `MicrosoftDiContainer` 创建两个 `ICqrsRuntime`,确保变量集中在 notification publisher 策略,而不是 handler 注册或容器形状差异 - - 更新 `GFramework.Cqrs.Benchmarks/README.md` 与 active tracking,使默认恢复入口直接记录新的 benchmark 口径 -- 本轮权威验证: - - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*NotificationFanOutBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:fixed `4 handler` fan-out 对照当前约为 baseline `7.424 ns / 0 B`、`Mediator` `3.854 ns / 0 B`、`MediatR` `225.940 ns / 1256 B`、`GFramework.Cqrs` 默认顺序发布器 `427.453 ns / 408 B`、内置 `TaskWhenAllNotificationPublisher` `472.574 ns / 496 B` - - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/NotificationFanOutBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` - - 结果:通过 - - `git diff --check` - - 结果:通过 -- 本轮结论: - - 当前 benchmark 说明 `TaskWhenAllNotificationPublisher` 的主要价值是补齐“等待全部处理器并聚合异常”的 notification 语义,而不是在 fixed `4 handler` fan-out steady-state 下带来吞吐收益;它比默认顺序发布器额外增加了约 `45 ns` 与 `88 B` - - 这组结果足以支持后续把 notification 线的重心转回 API 配置面、使用边界与文档语义,而不是继续机械堆新的 runtime seam 或期待 `TaskWhenAll` 自带性能红利 - - 当前 turn 仍可继续自动推进,但默认停止规则仍以“上下文预算优先、单批可评审边界次之”为准 - -### 阶段:内置 `TaskWhenAll` notification publisher(CQRS-REWRITE-RP-113) - -- 延续 `$gframework-batch-boot 50`,本轮不再继续堆 notification benchmark 维度,而是直接把上一批已经量化清楚的 capability gap 收口到 runtime: - - `RP-111` / `RP-112` 已证明当前 notification publish 无论单处理器还是固定 fan-out,都和 `Mediator` 的 publish strategy 能力差距相关,而不只是“缺 benchmark” - - 当前分支相对 `origin/main` 的累计 branch diff 仍明显低于 `50` 文件阈值,因此适合用一个单模块、可回归、可文档化的能力切片继续自动推进 -- 本轮主线程决策: - - 新增 `GFramework.Cqrs/Notification/TaskWhenAllNotificationPublisher.cs`,提供公开内置并行 notification publisher,并把“同步抛出的处理器异常也收敛到返回任务中”作为实现约束 - - 在 `GFramework.Cqrs.Tests/Cqrs/CqrsNotificationPublisherTests.cs` 补齐针对新策略的回归,确认它不会像默认顺序发布器那样在首个失败处停止其余处理器 - - 更新 `GFramework.Cqrs/README.md` 与 `docs/zh-CN/core/cqrs.md`,写明切换方式,以及“不保证顺序 / 等待全部处理器完成 / 统一暴露异常或取消结果”的采用边界 -- 本轮权威验证: - - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsNotificationPublisherTests"` - - 结果:通过 - - `python3 scripts/license-header.py --check --paths GFramework.Cqrs/Notification/TaskWhenAllNotificationPublisher.cs GFramework.Cqrs.Tests/Cqrs/CqrsNotificationPublisherTests.cs GFramework.Cqrs/README.md docs/zh-CN/core/cqrs.md` - - 结果:通过 - - `git diff --check` - - 结果:通过 -- 本轮结论: - - `GFramework.Cqrs` 现在不再只有“自定义 seam”这一种 notification publisher 扩展方式,而是先提供了一个仓库维护的内置并行策略,开始实质缩小和 `Mediator` 在 publisher strategy 上的能力差距 - - 这批改动保持默认顺序语义不变,因此风险主要落在“新策略的异常聚合和用户理解边界”,已通过测试和文档同步收口 - - 当前可以继续自动推进,但更合理的下一批应优先补新策略的 benchmark 或继续评估 notification publisher 配置面,而不是回头重复扩更多 fan-out benchmark - -### 阶段:notification fan-out publish benchmark(CQRS-REWRITE-RP-112) - -- 延续 `$gframework-batch-boot 50`,本轮没有直接切入 notification runtime 或 publisher strategy,而是先补齐固定 `4 handler` 的 fan-out publish 对照: - - `RP-111` 已量化单处理器 notification publish,但还缺“同一路径在固定多处理器 fan-out 时是否保持同级差距”的事实 - - 继续机械扩充 `HandlerCount` 参数矩阵会把 `Mediator` compile-time 处理器集合、MediatR 扫描过滤与 benchmark 注册变量混在一起;固定 `4 handler` 场景更容易保持三方对照口径稳定 -- 本轮主线程决策: - - 新增 `GFramework.Cqrs.Benchmarks/Messaging/NotificationFanOutBenchmarks.cs`,固定 4 个 handler,比对 baseline、`GFramework.Cqrs`、NuGet `Mediator` concrete runtime 与 `MediatR` 的 publish 开销 - - 让 baseline 直接顺序调用 4 个 handler,避免把 fan-out 的额外调用成本误归因为框架 dispatch 自身 - - 更新 `GFramework.Cqrs.Benchmarks/README.md`,明确 notification benchmark 现在同时覆盖单处理器与固定 4 处理器 fan-out 场景 -- 本轮权威验证: - - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*NotificationFanOutBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:历史基线(`RP-112`)固定 `4 handler` notification fan-out 对照约为 baseline `8.302 ns / 0 B`、`Mediator` `4.314 ns / 0 B`、`MediatR` `230.304 ns / 1256 B`、`GFramework.Cqrs` `434.413 ns / 408 B` - - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/NotificationFanOutBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md` - - 结果:通过 - - `git diff --check` - - 结果:通过 - - 备注:仅剩 `GFramework.sln` 的历史 CRLF 提示,无本轮新增 diff 格式问题 -- 本轮结论: - - notification 路径现在已同时具备“单处理器 publish”与“固定 4 处理器 fan-out publish”两条三方对照基线,足以支撑后续是否值得切进 publisher strategy 或 runtime 热点 - - 当前更有价值的下一步不是继续横向堆更多 fan-out 场景,而是转向 publisher strategy / 异常语义,或回到 request dispatch 常量开销这类更可能产生真实运行时收益的切片 - - 在 branch diff 仍明显低于阈值时可以继续自动推进,但应把“上下文预算接近约 80%”继续视为优先停止信号 - -### 阶段:notification publish 补齐 `Mediator` concrete runtime 对照(CQRS-REWRITE-RP-111) - -- 延续 `$gframework-batch-boot 50`,本轮重新按 skill 规则复核 branch diff 基线与容量: - - `origin/main` = `7ca21af9`,提交时间 `2026-05-08 16:12:20 +0800` - - 本地 `main` = `c2d22285`,已落后于 remote-tracking ref,因此不作为本轮 baseline - - 当前分支 `feat/cqrs-optimization` 与 `origin/main` 的累计 branch diff 为 `0 files / 0 lines` - - 当前工作树干净,且上一个自然批次 `RP-110` 已并入 `origin/main`;因此本轮不是“续做未提交热路径”,而是基于 active topic 重新选择下一块低风险 CQRS benchmark 切片 -- 本轮接受的只读探索结论: - - `NotificationBenchmarks` 仍停留在 `GFramework.Cqrs` vs `MediatR` 的双方对照,缺少 request steady-state 已具备的 `Mediator` concrete runtime 高性能参照物 - - 对 notification 路径直接补 generated invoker/provider 的性价比不高:dispatcher 当前对 notification 反射委托已按消息类型弱缓存,steady-state publish 的主要差距不在“每次都反射” - - 因此本轮更高信号、边界更清晰的切片是先补 benchmark 对照口径,而不是为了对称性新增一层 runtime seam -- 本轮主线程决策: - - 在 `GFramework.Cqrs.Benchmarks/Messaging/NotificationBenchmarks.cs` 新增 `Mediator` concrete runtime 宿主、`PublishNotification_Mediator()` benchmark 方法,以及对应的 `Mediator.INotification` / `Mediator.INotificationHandler` 合同实现 - - 保持现有 `GFramework.Cqrs` 与 `MediatR` notification publish 路径不变,只扩充对照组,确保这批仍然是单模块、低风险、可直接评审的 benchmark 收口 - - 更新 `GFramework.Cqrs.Benchmarks/README.md` 与 active tracking,使 notification 场景的公开说明和恢复入口都反映新的三方对照事实 -- 本轮权威验证: - - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*NotificationBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:notification publish 三方对照当前约为 `Mediator` `1.108 ns / 0 B`、`MediatR` `97.173 ns / 416 B`、`GFramework.Cqrs` `291.582 ns / 392 B` - - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/NotificationBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md` - - 结果:通过 - - `git diff --check` - - 结果:通过 - - 备注:仅剩 `GFramework.sln` 的历史 CRLF 提示,无本轮新增 diff 格式问题 -- 本轮结论: - - notification 场景现在也拥有了与 request steady-state 对称的 `Mediator` concrete runtime 参照物,后续再讨论 `notification publisher` 策略或 runtime 热点时,不再只能拿 `MediatR` 做外部对照 - - 当前最值得保留的结论不是“立刻给 notification 也上 generated invoker/provider”,而是 `GFramework.Cqrs` 单处理器 publish 相对 `Mediator` 与 `MediatR` 的量级差距已经被量化出来,可为后续是否继续压 notification 路径提供依据 - - 本轮到这里属于新的自然批次边界;下一轮若继续沿用 `$gframework-batch-boot 50`,更适合从多处理器 publish / publisher strategy 或更高价值的 request 常量开销热点里再选一块,而不是在同一 turn 里继续堆 notification 基准扩展 - -### 阶段:PR #341 latest-head review 尾声收口(CQRS-REWRITE-RP-110) - -- 再次使用 `$gframework-pr-review` 抓取 `PR #341` latest-head review,确认当前 open thread 已收敛到: - - `BenchmarkHostFactory.cs` 的 legacy runtime alias 防守式类型检查 thread,但当前 head 已存在 `RegisterLegacyRuntimeAlias(...)` 的显式类型校验与实际类型信息异常,属于 GitHub 未 resolve 的 stale thread - - `RequestBenchmarks.cs` / `CqrsDispatcher.cs` 的 Greptile thread,对应“程序集级 registry 扩散”与“faulted ValueTask 失败语义”均已在当前 head 修复,属于 stale thread - - 仍然成立且值得当前收口的只剩 `CqrsDispatcherContextValidationTests.cs` 的 strict mock 脆弱性,以及本 trace 中 `本轮下一步` 与 `本轮权威验证` 重复的问题 -- 本轮主线程决策: - - 为 `SendAsync_Should_Return_Faulted_ValueTask_When_Handler_Is_Missing()` 补齐 `HasRegistration(...)` 与 `GetAll(...)` 的防御性 mock,降低该测试对 dispatcher 内部检查顺序的隐式耦合 - - 删除 `RP-109` 记录中重复 `本轮权威验证` 的 `本轮下一步` 段落,保持默认恢复入口只保留仍有价值的恢复信息 -- 本轮权威验证: - - `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --format json --json-output /tmp/current-pr-review.json` - - 结果:通过 - - 备注:确认当前分支对应 `PR #341`;latest-head 当前仍显示 `CodeRabbit 2` / `Greptile 2` open thread,但其中运行时/benchmark 两条已在本地失效 - - `dotnet build GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - 备注:并行验证首轮曾因 `build` 与 `test` 同时写入同一输出 DLL 触发 `MSB3026` 单次复制重试;改为串行重跑同一命令后稳定通过 - - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsDispatcherContextValidationTests"` - - 结果:通过,`6/6` passed - - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherContextValidationTests.cs` - - 结果:通过 - - `git diff --check` - - 结果:通过 - - 备注:仅剩 `GFramework.sln` 的历史 CRLF 提示,无本轮新增 diff 格式问题 - -### 阶段:PR #341 latest-head review 收口(CQRS-REWRITE-RP-109) - -- 使用 `$gframework-pr-review` 抓取 `feat/cqrs-optimization` 当前公开 PR,并确认当前锚点已从 `PR #340` 更新为 `PR #341` -- 本轮 latest-head review 结论: - - `CodeRabbit` 仍有 `BenchmarkHostFactory.cs` 的 legacy runtime 硬转型、`StreamLifetimeBenchmarks.cs` 的注释缺口,以及 `.agents/skills/gframework-batch-boot/SKILL.md` 的 `MD005` 缩进问题 - - `Greptile` 指出的两条仍然成立:benchmark 项目里通过 `RegisterCqrsHandlersFromAssembly(typeof(...).Assembly)` 会把同程序集的其他 generated registry 一并激活,扩大 benchmark 宿主的服务索引基线;`CqrsDispatcher.SendAsync(...)` 直接去掉 `async/await` 后也把原本的 faulted-`ValueTask` 失败语义改成了同步抛出 -- 本轮主线程决策: - - 在 `GFramework.Cqrs.Internal.CqrsHandlerRegistrar` 新增 direct generated-registry 激活入口,并通过 `InternalsVisibleTo` 暴露给 `GFramework.Cqrs.Benchmarks`,让 benchmark 宿主只激活当前场景的 generated registry - - 把 `RequestBenchmarks`、`RequestPipelineBenchmarks`、`StreamingBenchmarks`、`StreamLifetimeBenchmarks` 以及 request/stream invoker benchmark 的 generated 宿主全部切到定向 registry 接线,避免同程序集其他 registry 扩大冻结索引和 descriptor 预热基线 - - 在 `BenchmarkHostFactory` 里用防守式类型检查注册 legacy runtime alias,并补充 stream lifetime runtime 二次创建的注释 - - 让 `CqrsDispatcher.SendAsync(...)` 通过 `ValueTask.FromException(...)` 恢复旧的 faulted-`ValueTask` 失败语义,同时保留成功路径的 direct-return 热路径 - - 补齐 `CqrsGeneratedRequestInvokerProviderTests` 与 `CqrsDispatcherContextValidationTests` 的 targeted 回归,并顺手修正 batch boot skill 的 markdown 缩进 -- 本轮权威验证: - - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` - - 结果:通过,`1 warning / 0 error` - - 备注:仅出现 `MSB3026` 单次复制重试告警,随后成功产出 `net10.0` 目标;未出现编译失败或新增代码警告 - - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsDispatcherContextValidationTests|FullyQualifiedName~CqrsGeneratedRequestInvokerProviderTests"` - - 结果:通过,`24/24` passed - - 备注:首轮并行验证时因与 build 同时运行触发 MSBuild 输出文件锁竞争;改为串行重跑同一命令后稳定通过 - - `python3 scripts/license-header.py --check --paths GFramework.Cqrs/Properties/AssemblyInfo.cs GFramework.Cqrs/Internal/CqrsHandlerRegistrar.cs GFramework.Cqrs/Internal/CqrsDispatcher.cs GFramework.Cqrs.Benchmarks/Messaging/BenchmarkHostFactory.cs GFramework.Cqrs.Benchmarks/Messaging/RequestBenchmarks.cs GFramework.Cqrs.Benchmarks/Messaging/RequestPipelineBenchmarks.cs GFramework.Cqrs.Benchmarks/Messaging/StreamingBenchmarks.cs GFramework.Cqrs.Benchmarks/Messaging/StreamLifetimeBenchmarks.cs GFramework.Cqrs.Benchmarks/Messaging/RequestInvokerBenchmarks.cs GFramework.Cqrs.Benchmarks/Messaging/StreamInvokerBenchmarks.cs GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherContextValidationTests.cs GFramework.Cqrs.Tests/Cqrs/CqrsGeneratedRequestInvokerProviderTests.cs` - - 结果:通过 - - 备注:仓库脚本默认内部调用未绑定 worktree 的 `git ls-files`,因此本轮按修改文件列表显式 `--paths` 校验 - - `git diff --check` - - 结果:通过 - -### 阶段:stream handler 生命周期矩阵 benchmark(CQRS-REWRITE-RP-108) - -- 延续 `$gframework-batch-boot 50`,本轮继续使用 `origin/main` 作为 branch diff 基线,并先复核: - - `origin/main` = `4d6dbba6`,提交时间 `2026-05-08 11:13:33 +0800` - - 当前分支 `feat/cqrs-optimization` 相对 `origin/main` 的累计 branch diff 为 `14 files / 507 lines` - - 当前 turn 虽然仍低于 `50 files` 阈值,但已加载多轮 recovery / benchmark 输出;因此只允许再推进一个单模块、低风险 benchmark 切片 -- 本轮接受的只读探索结论: - - `RequestLifetimeBenchmarks` 已覆盖 request 的 `Singleton / Transient` 生命周期矩阵,但 stream 侧仍缺少对称的 handler 生命周期对照 - - `StreamingBenchmarks` 已在 `RP-107` 切到 generated-provider 宿主,适合作为 stream 生命周期矩阵的宿主基础;继续退回纯反射路径会让“生命周期变量”和“descriptor 路径变量”混在一起 - - 如果让 generated registry 顺手注册默认单例 handler,会破坏生命周期矩阵的变量控制,因此 registry 只能暴露 descriptor,不能抢先锁死 handler 生命周期 -- 本轮主线程决策: - - 新增 `StreamLifetimeBenchmarks`,对齐 request 生命周期矩阵,只比较 `Singleton / Transient` 两档,继续明确把 `Scoped` 留给未来显式 scoped host - - 新增 `GeneratedStreamLifetimeBenchmarkRegistry`,只提供 handwritten generated stream invoker descriptor,不直接注册 handler - - 让 `StreamLifetimeBenchmarks` 使用 `RegisterCqrsHandlersFromAssembly(typeof(StreamLifetimeBenchmarks).Assembly)` 建立 generated-provider 宿主,再显式按 benchmark 参数注册 `Singleton / Transient` handler 生命周期 - - 更新 `GFramework.Cqrs.Benchmarks/README.md`,把 stream 生命周期矩阵列为已覆盖场景,并从“后续扩展方向”里移除这项待办 -- 本轮验证过程的重要补充: - - 首次并行触发 `RequestBenchmarks` / `RequestLifetimeBenchmarks` / `StreamLifetimeBenchmarks` 时,在同一 autogenerated BenchmarkDotNet 目录下复现了文件已存在冲突与 bootstrap 异常;这是 benchmark 基础设施层面的并行目录竞争,不是代码缺陷 - - 改为串行重跑后三组 benchmark 全部稳定通过,因此本轮将“BenchmarkDotNet 在当前仓库里不应并行运行多条 `dotnet run --project ... --filter ...` 会话”视为有效执行约束 -- 本轮权威验证: - - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/GeneratedStreamLifetimeBenchmarkRegistry.cs GFramework.Cqrs.Benchmarks/Messaging/StreamLifetimeBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md` - - 结果:通过 - - `git diff --check` - - 结果:通过 - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:steady-state request 对照约为 baseline `5.336 ns / 32 B`、`Mediator` `5.564 ns / 32 B`、`MediatR` `53.307 ns / 232 B`、`GFramework.Cqrs` `64.745 ns / 32 B` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:`Singleton` 下 baseline / `MediatR` / `GFramework.Cqrs` 约 `4.309 ns / 51.923 ns / 67.981 ns`;`Transient` 下约 `5.029 ns / 54.435 ns / 76.437 ns` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*StreamLifetimeBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:`Singleton` 下 baseline / `GFramework.Cqrs` / `MediatR` 约 `80.144 ns / 137.515 ns / 229.242 ns`,`Transient` 下约 `77.198 ns / 144.998 ns / 228.185 ns` -- 本轮结论: - - stream 生命周期矩阵现在已与 request 生命周期矩阵对称,且继续沿用 generated-provider 宿主路径,没有把变量退化回纯反射 binding - - `GFramework.Cqrs` 在 stream `Singleton / Transient` 两档下都明显快于 `MediatR`,同时保持接近 baseline 的分配规模;`Transient` 仅从 `240 B` 小幅增至 `264 B` - - 真正的停止依据仍是上下文预算安全。虽然 branch diff 只有 `14 files`,但当前 turn 已包含多轮 benchmark 输出和恢复文档,因此本批提交后应主动停止 - - 下一轮若继续性能线,更值得优先看 notification publish 或更高价值的 request 常量开销热点,而不是继续做同层级 benchmark 宿主补齐 - -### 阶段:默认 stream benchmark 吸收 generated provider 宿主(CQRS-REWRITE-RP-107) - -- 延续 `$gframework-batch-boot 50`,但本轮按用户新增要求把默认停止依据改为“AI 上下文预算优先,建议在预计接近约 80% 安全上下文占用前收口”;在真正落代码前先复核: - - `origin/main` = `4d6dbba6`,提交时间 `2026-05-08 11:13:33 +0800` - - 当前分支 `feat/cqrs-optimization` 相对 `origin/main` 的累计 branch diff 为 `10 files / 507 lines` - - 当前 turn 已加载 `AGENTS.md`、`gframework-batch-boot` / `gframework-boot`、active tracking/trace、上一轮 benchmark 结果与多次 validation 输出,因此继续一个自然批次可以接受,但不应在本次提交后继续无界循环 -- 本轮接受的只读探索结论: - - 默认 request / request pipeline 宿主都已吸收 generated provider,但 `StreamingBenchmarks` 仍停在“直接注册单个 stream handler”的旧宿主路径,口径与 `StreamInvokerBenchmarks` / 默认 request 组不对称 - - 默认 stream steady-state 场景已经足够独立,适合用一份新的 handwritten generated stream registry 最小化收口,而不用再修改 runtime 语义 - - 用户要求把停止条件从 changed files 改成 AI 上下文预算,因此 skill 文档本身也属于这一批必须一起落下的恢复边界更新 -- 本轮主线程决策: - - 新增 `GeneratedDefaultStreamingBenchmarkRegistry`,用 handwritten generated registry + `ICqrsStreamInvokerProvider` + `IEnumeratesCqrsStreamInvokerDescriptors` 为 `StreamingBenchmarks.BenchmarkStreamRequest` 提供真实的 generated stream invoker descriptor - - 让 `StreamingBenchmarks` 改用 `RegisterCqrsHandlersFromAssembly(typeof(StreamingBenchmarks).Assembly)` 建容器,并在 `Setup/Cleanup` 前后显式清理 dispatcher 静态缓存 - - 更新 `GFramework.Cqrs.Benchmarks/README.md`,明确默认 stream steady-state benchmark 也已接上 handwritten generated stream invoker provider - - 更新 `.agents/skills/gframework-batch-boot/SKILL.md` 与 `.agents/skills/gframework-boot/SKILL.md`,明确“上下文预算接近约 80% 时优先停止,branch diff 文件/行数只作次级仓库范围信号” -- 本轮权威验证: - - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/GeneratedDefaultStreamingBenchmarkRegistry.cs GFramework.Cqrs.Benchmarks/Messaging/StreamingBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md` - - 结果:通过 - - `git diff --check` - - 结果:通过 - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:steady-state request 对照约为 baseline `5.608 ns / 32 B`、`Mediator` `5.445 ns / 32 B`、`MediatR` `57.071 ns / 232 B`、`GFramework.Cqrs` `64.825 ns / 32 B` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:`Singleton` 下 baseline / `MediatR` / `GFramework.Cqrs` 约 `4.446 ns / 51.331 ns / 69.275 ns`;`Transient` 下约 `4.918 ns / 56.382 ns / 74.301 ns` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*StreamingBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:默认 stream steady-state 对照约为 baseline `5.535 ns / 32 B`、`MediatR` `59.499 ns / 232 B`、`GFramework.Cqrs` `66.778 ns / 32 B` -- 本轮结论: - - 默认 stream steady-state benchmark 现在也已切到 generated-provider 宿主路径,request / pipeline / stream 三个默认宿主场景的 benchmark 口径终于对齐 - - `StreamingBenchmarks` 的 `GFramework.Cqrs` 结果约 `66.778 ns / 32 B`,仍慢于 `MediatR`,但没有新增分配或明显回退,说明这次宿主收口是低风险可接受的 - - 更重要的是,默认停止依据已从“branch diff 文件数是否触顶”改成“AI 上下文预算是否接近约 80%”;结合当前 turn 已加载的大量 recovery/validation/benchmark 输出,本次提交后应主动停止,而不是继续机械扩批 - - 下一轮若继续性能线,应从 `RP-107` 恢复点重新进入,并优先挑选新的高价值热点族,而不是沿着当前 turn 再追加更多同类宿主收口 - -### 阶段:request pipeline benchmark 吸收 generated provider 宿主(CQRS-REWRITE-RP-106) - -- 延续 `$gframework-batch-boot 50`,本轮基于 `RP-105` 已验证的默认 request 宿主接线继续推进,并先复核 branch diff 基线: - - `origin/main` = `4d6dbba6`,提交时间 `2026-05-08 11:13:33 +0800` - - 当前分支 `feat/cqrs-optimization` 相对 `origin/main` 的累计 branch diff 为 `8 files / 358 lines` - - 当前工作树待提交改动只集中在 `RequestPipelineBenchmarks`、对应 handwritten generated registry 与 benchmark `README`,因此继续自动推进下一批 pipeline 宿主收口 -- 本轮接受的只读探索结论: - - `RP-105` 已证明“让默认 request 宿主真实接上 generated request invoker provider”能稳定压低 steady-state request,因此 pipeline benchmark 仍保留旧的“直接注册单个 handler”路径会让口径不对齐 - - 之前已被 benchmark 否决的“总是 `GetAll(Type)` 做零 pipeline 探测”不应回头重试;下一刀更合理的是把 pipeline benchmark 也切到真实程序集注册入口 - - `RequestPipelineBenchmarks` 只需要补一份与 `RequestBenchmarks` 对称的 handwritten generated registry,就能最小化改动并保持 runtime 语义不变 -- 本轮主线程决策: - - 新增 `GeneratedRequestPipelineBenchmarkRegistry`,用 handwritten generated registry + `ICqrsRequestInvokerProvider` + `IEnumeratesCqrsRequestInvokerDescriptors` 为 `RequestPipelineBenchmarks.BenchmarkRequest` 提供真实的 generated request invoker descriptor - - 让 `RequestPipelineBenchmarks` 改用 `RegisterCqrsHandlersFromAssembly(typeof(RequestPipelineBenchmarks).Assembly)` 建容器,只把 pipeline 行为数量矩阵保留在 benchmark 自己的显式注册里 - - 更新 `GFramework.Cqrs.Benchmarks/README.md`,明确 request pipeline benchmark 也已接上 handwritten generated request invoker provider -- 本轮权威验证: - - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/GeneratedRequestPipelineBenchmarkRegistry.cs GFramework.Cqrs.Benchmarks/Messaging/RequestPipelineBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md` - - 结果:通过 - - `git diff --check` - - 结果:通过 - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:steady-state request 对照约为 baseline `5.680 ns / 32 B`、`Mediator` `6.565 ns / 32 B`、`MediatR` `54.737 ns / 232 B`、`GFramework.Cqrs` `63.644 ns / 32 B` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:`Singleton` 下 `GFramework.Cqrs` / `MediatR` 约 `69.896 ns / 32 B` vs `57.469 ns / 232 B`;`Transient` 下约 `72.880 ns / 56 B` vs `55.106 ns / 232 B` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestPipelineBenchmarks.SendRequest_GFrameworkCqrs*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:第一次短跑为 `PipelineCount=0` `64.928 ns / 32 B`、`PipelineCount=1` `366.468 ns / 536 B`、`PipelineCount=4` `547.800 ns / 896 B` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestPipelineBenchmarks.SendRequest_GFrameworkCqrs*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:复跑确认后为 `PipelineCount=0` `64.755 ns / 32 B`、`PipelineCount=1` `353.141 ns / 536 B`、`PipelineCount=4` `555.083 ns / 896 B` -- 本轮结论: - - request pipeline benchmark 现在已与默认 request steady-state 使用同一条 generated-provider 宿主接线路径,后续再看 `0 / 1 / 4` 行为矩阵时不再混入“默认 request 已吸收 generated invoker,而 pipeline 还停在纯反射宿主”的口径偏差 - - `0 pipeline` steady-state 继续下探到约 `64.755 ns / 32 B`,与 `RP-105` 的默认 request benchmark 收敛方向一致,说明这条宿主接线收益能稳定复用到 pipeline benchmark - - `1 pipeline` 与 `4 pipeline` 结果在当前 short job 配置下存在噪音,但没有出现清晰的新增分配或显著退化;因此本轮适合作为低风险宿主收口批次接受 - - 下一批若继续沿用 `$gframework-batch-boot 50`,应优先查看 request lifetime、stream 或 notification benchmark 中是否还存在未吸收 generated-provider 宿主收益的对称切片,而不是回头重试已被 benchmark 否决的 runtime 微优化 - -### 阶段:默认 request benchmark 吸收 generated provider 宿主(CQRS-REWRITE-RP-105) - -- 延续 `$gframework-batch-boot 50`,本轮先确认失败试验已手工回退回 `RP-104` 的已验证状态,再重新评估“默认 request 路径继续逼近 source-generated `Mediator`”的下一刀 -- 本轮接受的只读探索结论: - - 继续在 `CqrsDispatcher` 或 `MicrosoftDiContainer` 上堆叠同层级微优化的性价比已经下降,而且上一轮“总是 `GetAll(Type)`”的试验已被 benchmark 明确否决 - - 默认 `RequestBenchmarks` 虽然已包含 `Mediator` 对照,但当前 GFramework 组仍只注册了单个 handler 实例,没有走 `RegisterCqrsHandlersFromAssembly(...)` + generated registry/provider 的真实宿主接线路径 - - `RequestInvokerBenchmarks` 已证明 generated request invoker provider 路径比纯反射 binding 更接近目标,因此下一批最小切片应先把这条收益吸收到默认 steady-state request benchmark -- 本轮主线程决策: - - 在 `BenchmarkHostFactory` 内补齐 benchmark 最小宿主的 CQRS 基础设施预接线:runtime、legacy alias、registrar、registration service - - 新增 `GeneratedDefaultRequestBenchmarkRegistry`,用 handwritten generated registry + `ICqrsRequestInvokerProvider` + `IEnumeratesCqrsRequestInvokerDescriptors` 为 `RequestBenchmarks.BenchmarkRequest` 提供真实的 generated request invoker descriptor - - 让 `RequestBenchmarks` 改用 `RegisterCqrsHandlersFromAssembly(typeof(RequestBenchmarks).Assembly)` 建容器,并在 `Setup/Cleanup` 前后显式清理 dispatcher 静态缓存,避免前一组 benchmark 污染默认 request steady-state 结果 -- 本轮权威验证: - - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/GeneratedDefaultRequestBenchmarkRegistry.cs GFramework.Cqrs.Benchmarks/Messaging/BenchmarkHostFactory.cs GFramework.Cqrs.Benchmarks/Messaging/RequestBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md` - - 结果:通过 - - `git diff --check` - - 结果:通过 - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:steady-state request 对照约为 baseline `5.013 ns / 32 B`、`Mediator` `5.747 ns / 32 B`、`MediatR` `51.588 ns / 232 B`、`GFramework.Cqrs` `65.296 ns / 32 B` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:`Singleton` 下 `GFramework.Cqrs` / `MediatR` 约 `68.772 ns / 32 B` vs `48.177 ns / 232 B`;`Transient` 下约 `73.157 ns / 56 B` vs `51.753 ns / 232 B` -- 本轮结论: - - 默认 request benchmark 现在终于测到了“默认宿主已吸收 generated request invoker provider”后的真实 steady-state,而不再只是纯反射 request binding - - 这条宿主层收口在不改 runtime 语义的前提下,把 `GFramework.Cqrs` steady-state request 从约 `70.298 ns` 再压到约 `65.296 ns` - - lifetime 矩阵也同步改善到 `68.772 ns / 73.157 ns`,说明默认 request 宿主吸收 generated provider 不只是 benchmark 口径变化,而是对常见 handler 生命周期也有稳定收益 - - 下一批若继续沿用 `$gframework-batch-boot 50`,应优先转向 pipeline 路径或 handler 解析热路径中仍未吸收 generated/provider 收益的常量开销,而不是回头重试已被否决的 `GetAll(Type)` 零行为探测方案 - -### 阶段:request 热路径继续收口(CQRS-REWRITE-RP-104) - -- 延续 `$gframework-batch-boot 50`,本轮先重新按 `origin/main` 复核 branch diff 基线: - - `origin/main` = `4d6dbba6`,提交时间 `2026-05-08 11:13:33 +0800` - - 当前分支 `feat/cqrs-optimization` 相对 `origin/main` 的累计 branch diff 仍为 `0 files / 0 lines` - - 当前工作树在真正落代码前只有活跃文档更新,仍明显低于 `$gframework-batch-boot 50` 的文件阈值,因此继续自动推进下一批 request 热路径收口 -- 本轮接受的只读探索结论: - - `RequestBenchmarks` / `RequestInvokerBenchmarks` 的下一个低风险热点仍在“每次发送都必经的容器查询与短生命周期对象创建”,不是重新回到更高风险的语义层重构 - - 候选优先级排序为:`SendAsync` 自身状态机开销、`HasRegistration + GetAll` / 服务键扫描,以及 pipeline continuation 的临时对象 -- 本轮主线程决策: - - 先以最小行为改动切第一刀:把 `CqrsDispatcher.SendAsync(...)` 从 `async/await` 改为 direct-return `ValueTask`,让零 pipeline request 常见路径不再为 dispatcher 自身生成额外状态机 - - 在第一刀验证通过且 benchmark 明显改善后,再切第二刀:让 `MicrosoftDiContainer.HasRegistration(Type)` 在冻结后复用预构建的服务键索引,而不是每次线性扫描全部 `ServiceDescriptor` - - 第二刀完成后停止继续叠第三刀,因为当前批次已经能清晰区分“有效收益”和“无回退但收益不明显”的因果,不再为了追逐更小常量开销降低评审清晰度 -- 本轮权威验证: - - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~MicrosoftDiContainerTests"` - - 结果:通过,`52/52` passed - - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~CqrsDispatcherCacheTests|FullyQualifiedName~CqrsDispatcherContextValidationTests"` - - 结果:通过,`14/14` passed - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:最新 steady-state request 对照约为 baseline `6.141 ns / 32 B`、`Mediator` `6.674 ns / 32 B`、`MediatR` `61.803 ns / 232 B`、`GFramework.Cqrs` `70.298 ns / 32 B` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:最新 lifetime request 对照约为 `Singleton` 下 baseline / `MediatR` / `GFramework.Cqrs` = `4.706 ns / 52.197 ns / 73.005 ns`,`Transient` 下 = `4.571 ns / 50.175 ns / 74.757 ns` - - `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` - - 结果:通过 - - `git diff --check` - - 结果:通过 - - 备注:仍仅有 `GFramework.sln` 的历史 CRLF 警告,无本轮新增格式问题 -- 本轮结论: - - 第一刀有效:`CqrsDispatcher.SendAsync(...)` 的 direct-return `ValueTask` 把 `GFramework.Cqrs` steady-state request 从 `RP-103` 记录的约 `83.823 ns` 压到约 `70.298 ns` - - 第二刀保守有效:冻结后 `HasRegistration(Type)` 索引化没有带来同量级的可见收益,但也没有造成功能回退、额外分配或测试破坏 - - 下一批若继续压 request hot path,应优先评估默认 request 路径吸收 generated invoker/provider,而不是继续围绕同层级容器存在性判断做微调 - -### 阶段:PR #340 latest-head review 收口(CQRS-REWRITE-RP-103) - -- 使用 `$gframework-pr-review` 抓取 `feat/cqrs-optimization` 当前公开 PR,并确认当前锚点已从 `PR #339` 更新为 `PR #340` -- 本轮 latest-head review 结论: - - `CodeRabbit` 当前显示 `2` 个 nitpick / open thread,`Greptile` 显示 `2` 个 open thread;`MegaLinter` 仍只有 `dotnet-format restore` 环境噪音 - - `CTRF` 当前显示 `2321` 项测试中 `1` 项失败,失败用例为 `CreateStream_Should_Throw_When_Stream_Pipeline_Behavior_Context_Does_Not_Implement_IArchitectureContext` - - 失败原因不是业务断言退化,而是 `CqrsDispatcher` 新增 `HasRegistration(Type)` fast-path 后,严格 mock 的上下文校验测试没有同步配置该调用,导致在命中上下文注入失败断言前先抛出 `Moq.MockException` - - `MicrosoftDiContainer.HasRegistration(Type)` 当前实现用 `requestedType.IsAssignableFrom(registeredServiceType)` 判断命中,会把“仅以实现类型自身注册”的服务误判成接口服务键也已注册,这与 `Get(Type)` / `GetAll(Type)` 的服务键语义不一致,属于仍成立的运行时缺陷 - - `IIocContainer.HasRegistration(Type)` XML 文档缺少异常契约;`docs/zh-CN/core/ioc.md` 也还未解释该新公开入口的用途与语义边界;`BenchmarkHostFactory` / `RequestBenchmarks` 中仍残留旧 `ai-libs/Mediator` 注释或隐式共享 handler 合同,属于仍成立的文档/维护性问题 -- 本轮主线程决策: - - 在 `CqrsDispatcherContextValidationTests` 为受影响的 request / stream pipeline mock 显式补 `HasRegistration(Type)` 配置,确保上下文失败语义测试不会被 strict mock 噪音短路 - - 把 `MicrosoftDiContainer.CanSatisfyServiceType(...)` 收窄为“服务键完全命中”或“开放泛型服务键可闭合到目标类型”,并新增回归覆盖“仅按具体实现类型自注册时,接口服务键应返回 false” - - 为 `IIocContainer.HasRegistration(Type)` 补 `` / ``,并在 `docs/zh-CN/core/ioc.md` 新增用户接入说明,明确该入口按服务键而不是按可赋值关系判断可见性 - - 更新 benchmark 相关注释到 NuGet `Mediator` 语义,并为 `BenchmarkRequestHandler` 增补显式 `Mediator.IRequestHandler<,>` 实现,降低未来升级时的契约漂移诊断成本 -- 本轮权威验证: - - `dotnet build GFramework.Core.Abstractions/GFramework.Core.Abstractions.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet build GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~MicrosoftDiContainerTests"` - - 结果:通过,`52/52` passed - - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~CqrsDispatcherContextValidationTests"` - - 结果:通过,`4/4` passed - - `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` - - 结果:通过 - - `git diff --check` - - 结果:通过 - - 备注:仅剩 `GFramework.sln` 的历史 CRLF 警告,无本轮新增格式问题 -- 下一步: - - 关注 `PR #340` 重新索引后的 latest-head open thread 是否随本轮提交自然收敛,尤其是 `HasRegistration(Type)` 相关 runtime / docs 线程 - - 若后续继续压 request hot path,可从 `CqrsDispatcher` 默认 request 路径与 generated invoker/provider 的进一步吸收空间继续下钻 - -### 阶段:性能回归门槛收紧与 benchmark 产物忽略收口(CQRS-REWRITE-RP-102) - -- 延续 `RP-101` 后的 benchmark 基线,本轮没有继续改 runtime 热路径,而是先把性能治理规则补齐,避免后续优化波次出现“功能通过但 steady-state request 变慢”的回退 -- 本轮主线程决策: - - 将 `BenchmarkDotNet.Artifacts/` 加入仓库 `.gitignore`,避免本地 benchmark 生成目录反复污染工作树 - - 在 `GFramework.Cqrs.Benchmarks/README.md` 明确写下新的默认回归门槛:只要改动触达 request dispatch、DI 热路径、invoker/provider、pipeline 或 benchmark 宿主,就必须至少复跑 `RequestBenchmarks.SendRequest_*` 与 `RequestLifetimeBenchmarks.SendRequest_*` - - 在 `cqrs-rewrite` active tracking 中把当前阶段目标升级为“持续逼近 source-generated `Mediator`,并至少稳定超过反射版 `MediatR`”,不再只把 benchmark 当成观察工具,而是作为性能收口阶段的验收门槛 -- 本轮权威验证: - - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:按新门槛复跑后,steady-state request 对照约为 baseline `5.300 ns / 32 B`、`Mediator` `4.964 ns / 32 B`、`MediatR` `57.993 ns / 232 B`、`GFramework.Cqrs` `83.823 ns / 32 B` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:按新门槛复跑后,`Singleton` 下 `GFramework.Cqrs` / `MediatR` 约 `83.183 ns / 32 B` vs `60.915 ns / 232 B`;`Transient` 下约 `86.243 ns / 56 B` vs `59.644 ns / 232 B` - - `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` - - 结果:通过 - - `git diff --check` - - 结果:通过 -- 本轮结论: - - `BenchmarkDotNet.Artifacts/` 现在不再是工作树噪音源 - - request benchmark 已从“偶尔人工观察”升级为 CQRS 性能波次的默认回归门槛 - - 当前离“至少超过反射版 `MediatR`”还有明确差距,所以下一批优化必须围绕 request steady-state 常量开销继续下钻,而不是只增加更多 benchmark 维度 - -### 阶段:request 热路径 benchmark 收口与 NuGet `Mediator` 对照补齐(CQRS-REWRITE-RP-101) - -- 延续 `$gframework-batch-boot 50`,本轮先按 `origin/main` 复核 branch diff 基线: - - `origin/main` = `5dc2dd25`,提交时间 `2026-05-08 09:08:37 +0800` - - 当前分支 `feat/cqrs-optimization` 相对 `origin/main` 的累计 branch diff 仍为 `0 files / 0 lines` - - 当前工作树仅新增 9 个跟踪文件修改,另有 `BenchmarkDotNet.Artifacts/` 本地生成输出未纳入提交范围,仍明显低于 `$gframework-batch-boot 50` 的文件阈值 -- 用户新增的 benchmark 诉求有两部分: - - 解释 `BenchmarkDotNet.Artifacts/results` 里为什么 `GFramework.Cqrs` request 路径表现显著差于对照组 - - 把 `martinothamar/Mediator` 加入 benchmark 对照,但必须使用官方 NuGet 包,不允许接本地 `ai-libs/Mediator` project reference -- 本轮主线程先回到 runtime hot path 与 benchmark 宿主做最小成本排查,确认旧坏值的两个主要根因: - - `CqrsDispatcher.SendAsync(...)` / `CreateStream(...)` 在 `0 pipeline` 场景下仍无条件执行 `container.GetAll(dispatchBinding.BehaviorType)`,即使根本没有行为注册,也会多走一次容器解析与空集合分配 - - `MicrosoftDiContainer.Get(Type)` / `GetAll()` / `GetAll(Type)` 在 debug logging 关闭时仍会先构造日志字符串,导致 benchmark 默认 `Fatal` 级别下仍持续产生无效分配 -- 本轮主线程决策: - - 为 `IIocContainer` 新增不激活实例的 `HasRegistration(Type)`,并由 `MicrosoftDiContainer` 提供支持开放泛型匹配的非激活查询实现 - - 让 `CqrsDispatcher` 在 request / stream 的 `0 pipeline` 场景先走 `HasRegistration(...)` fast-path;没有行为注册时直接调用已准备好的 request / stream invoker,不再解析空行为列表 - - 为 `MicrosoftDiContainer` 的热路径查询补 `IsDebugEnabled()` 守卫,避免 benchmark 常态配置下的无效日志字符串构造 - - 在 benchmark 项目中通过 NuGet 接入 `Mediator.Abstractions` 与 `Mediator.SourceGenerator` `3.0.2`,并让 `RequestBenchmarks` 使用 source-generated concrete `Mediator.Mediator` 作为新对照组 - - 保持 `ai-libs/Mediator` 只作为本地源码 / README 参考资料,不参与编译或项目引用 -- 本轮新增 / 更新的验证与回归覆盖: - - `GFramework.Core.Tests/Ioc/MicrosoftDiContainerTests.cs` 新增 `HasRegistration(...)` 回归,覆盖“无匹配注册返回 false”与“开放泛型注册可满足封闭请求行为类型”两个分支 - - `GFramework.Cqrs.Benchmarks/Messaging/RequestBenchmarks.cs` 现在同时对照 baseline / `Mediator` / `MediatR` / `GFramework.Cqrs` - - `GFramework.Cqrs.Benchmarks/Messaging/BenchmarkHostFactory.cs` 新增 `CreateMediatorServiceProvider(...)`,统一最小宿主构建方式 -- 本轮权威验证: - - `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~MicrosoftDiContainerTests"` - - 结果:通过,`51/51` passed - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:steady-state request 对照约为 baseline `5.969 ns / 32 B`、`Mediator` `6.242 ns / 32 B`、`MediatR` `53.818 ns / 232 B`、`GFramework.Cqrs` `85.504 ns / 32 B` - - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:`Singleton` 下 `GFramework.Cqrs` 从旧值 `301.731 ns / 440 B` 收敛到 `84.066 ns / 32 B`;`Transient` 下从旧值 `287.863 ns / 464 B` 收敛到 `90.652 ns / 56 B` -- 本轮结论: - - `GFramework.Cqrs` 之前“垫底很多”的主要原因不是抽象层级本身,而是 request 热路径残留了两个可避免的分配热点:空 pipeline 解析与禁用日志下的字符串构造 - - 收口后,`GFramework.Cqrs` 仍慢于 `MediatR` 与 source-generated `Mediator`,但已经去掉了旧 benchmark 中最明显的异常分配和 300ns 级退化 - - 下一批若继续沿用 `$gframework-batch-boot 50` 压 request steady-state,最值得优先评估的是让默认 request 路径进一步吸收 generated invoker/provider 的收益,而不是继续扩大更多横向对照项 - -## 2026-05-07 - -### 阶段:PR #339 stream pipeline seam review 收口(CQRS-REWRITE-RP-100) - -- 使用 `$gframework-pr-review` 抓取 `feat/cqrs-optimization` 当前公开 PR,并确认已从历史 `PR #334` 进入新的 `PR #339` -- 本轮 latest-head review 结论: - - `CodeRabbit` 当前显示 `2` 个 open thread 与 `2` 个 nitpick,失败检查为 `0`,GitHub Test Reporter 汇总仍为全绿 - - `GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherCacheTests.cs` 的 test-name 拼写 thread 已在当前 head 失效,本地代码已经是 `Per_Behavior_Count` - - `GFramework.Core.Abstractions/Ioc/IIocContainer.cs` 的 `RegisterCqrsStreamPipelineBehavior()` 仍缺 `` / `` 契约说明,属于仍成立的文档缺口 - - `GFramework.Cqrs/Internal/CqrsDispatcher.cs` 的 `StreamPipelineInvocation.GetContinuation(...)` 缺少 request 对称路径已有的线程模型说明,属于仍成立的并发语义文档缺口 - - `GFramework.Core/Ioc/MicrosoftDiContainer.cs` 的 request / stream CQRS 行为注册逻辑完全重复,属于仍成立的维护性问题 -- 本轮主线程决策: - - 在 `IIocContainer` 补齐流式行为注册入口的 `` / ``,并把相同契约补到 `IArchitecture`、`Architecture` 与 `ArchitectureModules`,避免公开入口文档漂移 - - 为 `StreamPipelineInvocation.GetContinuation(...)` 补齐“仅假定单次建流链顺序推进;并发 `next()` 时可能重复创建等价 continuation,但不会跨建流共享实例”的说明 - - 在 `MicrosoftDiContainer` 抽取 `RegisterCqrsPipelineBehaviorCore(...)`,统一 request / stream 行为注册的开放泛型、封闭接口枚举、错误消息与日志路径 - - 顺手修复 `dotnet format` 在当前 branch diff 内实际命中的 `GFramework.Cqrs/ICqrsRequestInvokerProvider.cs` XML 缩进问题;不处理未触达历史文件上的 `CHARSET` 提示 -- 本轮权威验证: - - `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --json-output /tmp/current-pr-review.json` - - 结果:通过 - - `dotnet format GFramework.Cqrs/GFramework.Cqrs.csproj --verify-no-changes` - - 结果:发现当前 diff 内 `GFramework.Cqrs/ICqrsRequestInvokerProvider.cs` 的空白格式问题;其余 `CHARSET` 提示集中在未触达的历史文件 - - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet build GFramework.Core.Abstractions/GFramework.Core.Abstractions.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~CqrsDispatcherCacheTests"` - - 结果:通过,`10/10` passed - - `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~ArchitectureModulesBehaviorTests"` - - 结果:通过,`4/4` passed - - `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` - - 结果:通过 - - `git diff --check` - - 结果:通过 - -### 阶段:stream pipeline seam 收口(CQRS-REWRITE-RP-099) - -- 延续 `$gframework-batch-boot 50`,主线程先按 `origin/main` 评估 branch diff 容量,并在 `stream pipeline` 与 `notification publisher` 两个独立切片中选择更贴近 active gap 的下一批目标 -- 只读 subagent 结论已被接受: - - `notification publisher` 已有稳定 seam、默认顺序实现与专门回归,缺口主要在“更多内置策略” - - `stream pipeline` 仍缺独立 contract、注册入口与 runtime executor,对应缺口在 public docs 与 active tracking 中都已显式列出 -- 本轮主线程决策: - - 为 `GFramework.Cqrs.Abstractions` 新增 `IStreamPipelineBehavior<,>` 与 `StreamMessageHandlerDelegate<,>` - - 为 `IIocContainer`、`IArchitecture`、`Architecture`、`ArchitectureModules` 与 `MicrosoftDiContainer` 新增 `RegisterCqrsStreamPipelineBehavior()` - - 为 `CqrsDispatcher` 的 `CreateStream(...)` 路径补齐 stream behavior 解析、上下文注入,以及按 behaviorCount 缓存的 stream pipeline executor 形状 - - 保持语义边界清晰:本轮 stream pipeline 只包裹单次 `CreateStream(...)` 建流,不扩展到每个元素的逐项 middleware 语义 - - 让 generated stream invoker provider 与 stream pipeline seam 共存,并补齐“generated invoker 仍命中、行为链仍生效”的回归 -- 本轮新增 / 更新的测试方向: - - `CqrsDispatcherCacheTests`:stream pipeline executor 缓存、顺序稳定性、上下文重新注入 - - `CqrsDispatcherContextValidationTests`:stream behavior 需要 `IArchitectureContext` 时的显式失败语义 - - `CqrsGeneratedRequestInvokerProviderTests`:generated stream invoker 与 stream behavior 并存时仍优先消费 generated descriptor - - `ArchitectureModulesBehaviorTests`:公开 `RegisterCqrsStreamPipelineBehavior()` 冒烟回归 -- 文档收口: - - `GFramework.Cqrs/README.md` 现在显式说明 stream behavior 的建流级作用域 - - `docs/zh-CN/core/cqrs.md` 现在区分 request pipeline 与 stream pipeline 两个注册入口,并从“仍缺 stream pipeline seam”的能力差距列表中移除该项 -- 当前立即下一步: - - 运行 `GFramework.Cqrs` / `GFramework.Cqrs.Tests` / `GFramework.Core.Tests` 的 Release build 与 targeted tests - - 刷新 `origin/main...HEAD` 的 branch diff files / lines 指标 - - 若验证通过,再补 license / diff check 与自动提交 -- 本轮权威验证: - - `dotnet build GFramework.Cqrs/GFramework.Cqrs.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet build GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet build GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~CqrsDispatcherCacheTests|FullyQualifiedName~CqrsGeneratedRequestInvokerProviderTests|FullyQualifiedName~CqrsDispatcherContextValidationTests"` - - 结果:通过,`31/31` passed - - `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~ArchitectureModulesBehaviorTests"` - - 结果:通过,`4/4` passed - - `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` - - 结果:通过 - - `git diff --check` - - 结果:通过 - - `origin/main...HEAD` - - 结果:`0 files / 0 lines` - -### 阶段:PR #334 latest-head helper 异常边界收口(CQRS-REWRITE-RP-098) - -- 再次使用 `$gframework-pr-review` 抓取 `feat/cqrs-optimization` 对应的 `PR #334` latest-head review,并重新核对 `/tmp/current-pr-review.json` 中最新 open thread: - - 当前公开 PR 仍为 `PR #334` - - `CodeRabbit` 最新 review 在 `2026-05-07T12:20:24Z` 为 `APPROVED` - - latest-head 当前显示 `CodeRabbit 10` / `Greptile 5` 个 open thread -- 本轮逐条回到本地代码后,确认大多数 open thread 仍是 stale 状态;唯一继续成立的问题集中在 `LegacyCqrsDispatchHelper.TryResolveDispatchContext(...)`: - - 该 helper 之前会把 `IContextAware.GetContext()` 抛出的任意 `InvalidOperationException` 都吞掉并回退到 legacy 直执行 - - 这会把真实运行时故障误判为“上下文未就绪”,导致 bridge 路径悄悄绕过统一 runtime,退化为难以诊断的行为差异 -- 本轮主线程决策: - - 将异常过滤收窄为只接受两类缺上下文信号:`Architecture context has not been set...` 与 `No active architecture context is currently bound.` - - 其他 `InvalidOperationException` 一律继续向上传播,避免掩盖容器、生命周期或自定义 `GetContext()` 内的真实错误 - - 在 `CommandExecutorTests` 中新增两条回归:一条验证缺上下文时仍会 fallback 到 legacy 直执行;一条验证意外 `InvalidOperationException` 不会被 bridge 逻辑静默吞掉 - - 同步刷新 `cqrs-rewrite` active tracking,把本轮修复记录为新的恢复锚点 `RP-098` -- 本轮权威验证: - - `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --json-output /tmp/current-pr-review.json` - - 结果:通过 - - `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet build GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --no-build --filter "FullyQualifiedName~CommandExecutorTests|FullyQualifiedName~QueryExecutorTests"` - - 结果:通过,`25/25` passed - - `python3 scripts/license-header.py --check` - - 结果:通过 - - `git diff --check` - - 结果:通过 - -### 阶段:PR #334 nitpick 测试收尾(CQRS-REWRITE-RP-097) - -- 继续处理 `PR #334` latest-head review 中仍值得本地吸收的轻量 nitpick,范围限定在 legacy bridge 测试可观察性与测试替身诊断质量: - - `AsyncQueryExecutorTests.SendAsync_Should_Bridge_Through_Runtime_And_Preserve_Context` 标题声明“保留上下文”,但此前只断言了返回值与 bridge request 类型 - - `CommandExecutorTests.Send_WithResult_Should_Bridge_Through_Runtime_And_Preserve_Context` 同样缺少可观察的上下文注入断言 - - `RecordingCqrsRuntime` 直接强转响应对象,若测试工厂回错类型,失败信息不够聚焦 -- 本轮主线程决策: - - 为两个 “Preserve_Context” 用例补齐 `ObservedContext` 与 `expectedContext` 的同一实例断言,使测试标题、注释与断言对象保持一致 - - 让 `RecordingCqrsRuntime` 通过私有 helper 显式执行响应类型还原;当工厂返回 `null` 或错误装箱类型时,抛出包含 request 类型与期望/实际响应类型的 `InvalidOperationException` - - 同步刷新 `cqrs-rewrite` active tracking,把本轮 nitpick 收敛与验证结果记录为新的恢复锚点 `RP-097` -- 本轮权威验证: - - `dotnet build GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~CommandExecutorTests|FullyQualifiedName~AsyncQueryExecutorTests"` - - 结果:通过,`19/19` passed - - `python3 scripts/license-header.py --check` - - 结果:通过 - - `git diff --check` - - 结果:通过 - -### 阶段:PR #334 latest-head review 复核(CQRS-REWRITE-RP-096) - -- 再次使用 `$gframework-pr-review` 抓取 `feat/cqrs-optimization` 对应的 `PR #334` latest-head review,并读取 `/tmp/current-pr-review.json` 中的 `review_agents`、`latest_commit_review`、`megalinter_report` 与 `test_reports` -- 本轮复核结论: - - 当前公开 PR 为 `PR #334`,head commit 为 `dc3bd3744e2ceaa557ef03bc991fc88daedb460b` - - `CodeRabbit` latest review 在 `2026-05-07T11:46:42Z` 已是 `APPROVED`,但 latest-head 仍显示 `10` 个 open thread;`Greptile` 仍显示 `3` 个 open thread - - 逐条回到本地代码后,相关修复已在当前分支落地:`ArchitectureBootstrapper` 已自动扫描 `typeof(ArchitectureContext).Assembly`;`ArchitectureContextTests` / `ArchitectureModulesBehaviorTests` 已标注 `NonParallelizable` 并保证资源释放;`LegacyAsync*DispatchRequestHandler` 已统一补 `ThrowIfCancellationRequested()` + `WaitAsync(cancellationToken)`;`QueryExecutor` / legacy bridge request XML 文档与 `docs/zh-CN/core/command.md` fallback 说明也已齐备 - - 远端 CTRF 最新测试汇总为 `2311/2311 passed`(run `#1079`),`MegaLinter` 仅剩 `dotnet-format` restore failed 的环境噪音,没有新的文件级诊断 -- 主线程决策: - - 不再为这些 stale open thread 追加新的本地代码改动,避免重复修补已吸收的问题 - - 仅更新 `cqrs-rewrite` active tracking/trace,把“当前剩余差异主要是 GitHub thread 状态滞后”记录为最新权威事实 -- 本轮权威验证: - - `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --format json --json-output /tmp/current-pr-review.json` - - 结果:通过 - - `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - -### 阶段:PR #334 legacy bridge sync follow-up(CQRS-REWRITE-RP-095) - -- 再次使用 `$gframework-pr-review` 抓取 `feat/cqrs-optimization` 对应的 `PR #334` latest-head review,并只保留本地复核后仍成立的问题: - - `QueryExecutor` / `CommandExecutor` 新增的同步 bridge 仍直接阻塞 `ICqrsRuntime.SendAsync(...)`,在调用方存在 `SynchronizationContext` 时容易放大 sync-over-async 死锁面 - - `QueryExecutor` / `CommandExecutor` / `AsyncQueryExecutor` 各自保留一份相同的 dispatch-context 解析逻辑,仍有漂移风险 - - `ArchitectureContextTests` 的 bridge fixture 依然共享静态 tracker 且未显式声明非并行;冻结容器所有权也未交还给调用方释放 - - `LegacyAsyncCommandDispatchRequestHandler` 仍未沿用另两个 async bridge handler 的取消可见性模式 -- 本轮主线程决策: - - 新增 `GFramework.Core/Cqrs/LegacyCqrsDispatchHelper.cs`,统一收口 legacy bridge 的 dispatch-context 解析,以及同步 bridge 对 `ICqrsRuntime.SendAsync(...)` 的线程池隔离等待 - - 将 `QueryExecutor`、`CommandExecutor`、`AsyncQueryExecutor` 的重复 helper 改为复用共享 helper,并把 `ArchitectureContext` 的同步 CQRS 包装入口一并切换到同一阻塞策略,避免留下半修状态 - - 为 `ICqrsRuntime.SendAsync(...)` 补充 ``,显式说明 legacy 同步入口会在后台线程上等待该异步契约,处理链路不应依赖调用方 `SynchronizationContext` - - 把 `ArchitectureContextTests`、`ArchitectureModulesBehaviorTests` 标记为 `NonParallelizable`,并让 `CreateFrozenBridgeContext(...)` 把冻结容器通过 `out` 参数返还给每个测试在 `finally` 中释放 - - 为 `LegacyAsyncCommandDispatchRequestHandler` 增补 `ThrowIfCancellationRequested()` + `WaitAsync(cancellationToken)`,与另外两个 async bridge handler 保持一致 - - 新增回归测试覆盖同步 bridge 的 `SynchronizationContext` 隔离、legacy async command handler 的取消语义,以及 async/sync bridge request 的 request-type 命中 -- 本轮权威验证: - - `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` - - 结果:通过 - - `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~ArchitectureContextTests|FullyQualifiedName~ArchitectureModulesBehaviorTests|FullyQualifiedName~CommandExecutorTests|FullyQualifiedName~QueryExecutorTests|FullyQualifiedName~AsyncQueryExecutorTests|FullyQualifiedName~LegacyAsyncCommandDispatchRequestHandlerTests"` - - 结果:通过,`54/54` passed - -### 阶段:PR #334 legacy bridge / 文档 review 收尾(CQRS-REWRITE-RP-094) - -- 使用 `$gframework-pr-review` 抓取当前分支公开 PR,确认 `feat/cqrs-optimization` 当前对应 `PR #334` -- latest-head open AI review 复核后,主线程接受并执行的修复集中在六类: - - `GFramework.Core.Tests/Architectures/ArchitectureContextTests.cs` 通过字符串字面量反射实例化内部 bridge handler,维护成本高且不利于 rename-safe 重构 - - `ArchitectureModulesBehaviorTests` 在断言失败路径下未保证 `DestroyAsync()` 执行,且 `TearDown` 未重置 `LegacyBridgePipelineTracker` - - `LegacyBridgePipelineTracker` 以静态共享计数器记录 bridge pipeline 命中,但未文档化线程安全语义,且用字符串匹配类型名识别 bridge request - - `LegacyAsyncQueryDispatchRequestHandler` / `LegacyAsyncCommandResultDispatchRequestHandler` 丢弃了 runtime 传入的 `CancellationToken` - - `CommandExecutorModule` / `QueryExecutorModule` / `AsyncQueryExecutorModule` 依赖 `container.Get()` 的隐式注册顺序,但此前既未显式失败,也未写进 API 契约 - - 多个 legacy bridge request / docs 页面仍缺 XML 文档或回退边界说明 -- 本轮主线程决策: - - 为 `GFramework.Core` 新增 `Properties/AssemblyInfo.cs`,用 `InternalsVisibleTo("GFramework.Core.Tests")` 让测试直接实例化内部 handler - - 把 `ArchitectureContextTests.RegisterLegacyBridgeHandlers` 改成显式构造 6 个 handler,移除字符串反射装配 - - 为 bridge 相关测试补 `TearDown` 清理和 `try/finally` 销毁,减少失败路径资源泄露 - - 为 `LegacyBridgePipelineTracker` 增补 ``,并改用 `typeof(LegacyCqrsDispatchRequestBase).IsAssignableFrom(requestType)` 识别 bridge request - - 为 `LegacyAsyncQueryDispatchRequestHandler` / `LegacyAsyncCommandResultDispatchRequestHandler` 加入预取消检查与 `WaitAsync(cancellationToken)` - - 将三个 executor module 改为 `GetRequired()`,同时在 XML 文档中显式声明 `CqrsRuntimeModule` 的前置注册约束 - - 为 `CommandExecutor` / `QueryExecutor` / `AsyncQueryExecutor` 的 dispatch-context helper 增加 `[MemberNotNullWhen]`,收敛重复 `_runtime is not null` 判空与 null-forgiving - - 补齐 legacy bridge request / handler 的 XML 文档,以及 `docs/zh-CN/core/command.md`、`context.md` 的 fallback 边界说明 -- 本轮没有跟进的 thread: - - `GFramework.Cqrs.Benchmarks/Messaging/RequestLifetimeBenchmarks.cs` 的 `sealed` 建议属于低价值性能/风格提示,不影响 `PR #334` 的行为正确性 - - 若 review 在 GitHub 重新索引前仍显示旧 thread,下一轮以最新 head commit 再次抓取为准,不在本地重复造改动 -- 本轮权威验证: - - `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - - `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~ArchitectureContextTests|FullyQualifiedName~ArchitectureModulesBehaviorTests|FullyQualifiedName~CommandExecutorTests|FullyQualifiedName~QueryExecutorTests|FullyQualifiedName~AsyncQueryExecutorTests"` - - 结果:通过,`48/48` passed - - `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` - - 结果:通过 - - `git diff --check` - - 结果:通过 - -### 阶段:legacy Core CQRS -> GFramework.Cqrs bridge(CQRS-REWRITE-RP-093) - -- 延续 `$gframework-batch-boot 50`,本轮明确不只盯 benchmark,而是同时处理两个目标: - - 复核 `ai-libs/Mediator` 还有哪些能力尚未被 `GFramework.Cqrs` 吸收 - - 验证 `GFramework.Core` 的简单 `Command` / `Query` 兼容入口能否在不改外部用法的前提下,底层统一改走 `GFramework.Cqrs` -- 主线程先完成 `GFramework.Core` bridge 实现收尾与测试修正: - - `ArchitectureContext` 的 legacy `SendCommand(...)` / `SendQuery(...)` / `SendQueryAsync(...)` 现在会创建内部 bridge request,并直接通过统一 `ICqrsRuntime` 分发 - - `CommandExecutor`、`QueryExecutor`、`AsyncQueryExecutor` 在解析到 runtime 且目标对象可提供架构上下文时,也会复用同一条 bridge/runtime 路径 - - 为避免破坏不依赖容器的旧测试,执行器仍保留“未接入 runtime 时直接执行”的回退语义 -- 新增 `GFramework.Core/Cqrs/Legacy*DispatchRequest*.cs` 与对应 handler,把 legacy 命令/查询包装成内部 request: - - bridge handler 在执行前会显式把当前 `IArchitectureContext` 注入给 `IContextAware` 目标 - - 这让旧调用链在不改 public API 的情况下,也能复用统一 pipeline 与 handler dispatch 语义 -- 生产接线结论已经本地复核: - - `CqrsRuntimeModule` 只注册 runtime / registrar / registration service,本身不直接手工注册 bridge handler - - 默认生产路径依赖 `ArchitectureBootstrapper.ConfigureServices(...)` 自动调用 `RegisterCqrsHandlersFromAssemblies([architectureType.Assembly, typeof(ArchitectureContext).Assembly])` - - 因此 `GFramework.Core` 程序集中的 internal bridge handler 会在标准架构初始化阶段自动被扫描和注册,不需要业务侧手工补注册 -- 为防止以后有人改坏默认扫描范围,本轮额外补了一条更接近真实启动路径的回归: - - `ArchitectureModulesBehaviorTests.InitializeAsync_Should_AutoRegister_LegacyBridgeHandlers_For_Default_Core_Assemblies` - - 该用例通过 `Architecture.Configurator` 注册 open-generic pipeline behavior,然后直接走 `Architecture.InitializeAsync()`,验证旧 `SendCommand` / `SendQuery` 兼容入口能命中统一 pipeline -- 只读 subagent 同步完成 `Mediator` 差距复核,接受的结论是六类未完全吸收能力: - - `IMediator` / `ISender` / `IPublisher` 风格 facade - - telemetry / tracing / metrics - - stream pipeline - - notification publisher 策略 - - 生成器配置与诊断公开面 - - 生命周期 / 缓存公开配置面 -- 文档与恢复入口同步更新: - - `docs/zh-CN/core/context.md`、`command.md`、`query.md`、`cqrs.md` - - `GFramework.Core/README.md` - - active tracking / trace 升级到 `RP-093` - -### 验证(RP-093) - -- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~ArchitectureContextTests|FullyQualifiedName~CommandExecutorTests|FullyQualifiedName~QueryExecutorTests|FullyQualifiedName~AsyncQueryExecutorTests"` - - 结果:通过,`45/45` passed -- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release` - - 结果:通过,`1644/1644` passed -- `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` - - 结果:通过 -- `git diff --check` - - 结果:通过 - -### 当前下一步(RP-093) - -1. 若继续沿用 `$gframework-batch-boot 50`,优先从 `stream pipeline` 或 `notification publisher` 策略中切一块对齐 `Mediator` -2. 若要继续收敛 public seam,下一批优先设计 facade,而不是继续扩大 `ArchitectureContext` 的兼容职责 - -### 阶段:request handler 生命周期矩阵 benchmark(CQRS-REWRITE-RP-092) - -- 使用 `$gframework-batch-boot 50` 启动本轮批次,并按技能要求先复核 `origin/main` 基线与 branch diff: - - `origin/main` = `2c58d8b6`,提交时间 `2026-05-07 13:24:46 +0800` - - 本地 `main` = `c2d22285`,已落后于 remote-tracking ref,因此不作为本轮 batch baseline - - 当前 `feat/cqrs-optimization` 相对 `origin/main` 的累计 branch diff 在开工前为 `0 files / 0 lines` -- 本轮批次目标:继续推进 `GFramework.Cqrs.Benchmarks`,补一个独立、低风险、可单项目 Release 验证的 request 生命周期对照切片 -- 主线程先复核现有 benchmark 宿主与 runtime 解析路径后确认: - - `RequestBenchmarks` 与 `StreamingBenchmarks` 当前都固定使用单根容器宿主 - - `MicrosoftDiContainer` 虽支持 `RegisterScoped` / `CreateScope()`,但当前 `CqrsDispatcher` 的 steady-state benchmark 路径直接从根容器解析 handler - - 因此若直接把 `Scoped` 注册加入现有 benchmark,会把“根作用域下的 scoped 解析”误当成公平对照,语义不成立 -- 本轮决策: - - 新增 `Messaging/RequestLifetimeBenchmarks.cs` - - 生命周期矩阵只覆盖 `Singleton / Transient` - - 在 XML 文档与 README 中显式注明:`Scoped` 需要等未来具备真实显式作用域边界的 benchmark host 后再比较 -- 已修改: - - `GFramework.Cqrs.Benchmarks/Messaging/RequestLifetimeBenchmarks.cs` - - `GFramework.Cqrs.Benchmarks/README.md` - - `ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md` - - `ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` -- 预期结果: - - `GFramework.Cqrs.Benchmarks` 不再只覆盖“有无 generated provider / startup / pipeline”的维度,也开始覆盖 request steady-state 下的 handler 生命周期成本差异 - - benchmark 设计继续保持“只加入语义公平的矩阵”,避免把作用域模型不对称的结论写进基线 - -### 验证(RP-092) +### 阶段:PR #347 latest-head review 收口(CQRS-REWRITE-RP-132) + +- 使用 `$gframework-pr-review` 重新抓取当前分支 `feat/cqrs-optimization` 对应的 `PR #347` +- 抓取结果显示当前 latest-head 仍有 `CodeRabbit 6` 与 `Greptile 2` open thread,但本地复核后只接受以下仍成立的结论: + - `Program.cs` 只在命令行 `--artifacts-suffix` 下重启隔离宿主,未覆盖环境变量触发的隔离路径 + - `Program.cs` 缺少“目标隔离宿主目录位于当前宿主输出目录内”的防守式校验 + - `RequestLifetimeBenchmarks` / `StreamLifetimeBenchmarks` 的 `Scoped` 路径每次 benchmark 调用都会新建 runtime,污染生命周期矩阵公平性 + - `ScopedBenchmarkContainer` 的公共/关键成员 XML 契约说明不完整 + - active tracking / trace 已经偏离“快速恢复入口”,需要归档瘦身 +- 本轮实现选择: + - `Program.cs` + - 把“是否需要重启隔离宿主”统一收敛到 `ArtifactsPath != null` + - 为隔离宿主目录补充“不得等于或嵌套在当前宿主输出目录内”的校验 + - `BenchmarkHostFactory.cs` + - scoped request / stream helper 改为复用单个 runtime,只在调用边界进入和释放 scope + - `ScopedBenchmarkContainer.cs` + - 从“构造时绑定单次 scope”改为“可重复进入的作用域适配器 + `ScopeLease`” + - 补齐只读适配器与作用域租约的 XML 合同说明 + - `RequestLifetimeBenchmarks.cs` + - `Scoped` 路径改为 `GlobalSetup` 时创建单个 scoped runtime + - `StreamLifetimeBenchmarks.cs` + - `Scoped` reflection / generated 路径改为 `GlobalSetup` 时各自创建单个 scoped runtime + - 按语义阶段拆分 `Setup()`,同时清掉 `MA0051` + - `README.md` + - 把 `RequestLifetimeBenchmarks` 的 scoped 语义更新为“复用 runtime,仅每次创建真实 scope” + - `ai-plan/public/cqrs-rewrite/**` + - 将旧 active tracking / trace 复制归档到 + `archive/todos/cqrs-rewrite-migration-tracking-history-through-rp131.md` + 与 + `archive/traces/cqrs-rewrite-migration-trace-history-through-rp131.md` + - 重写 active tracking / trace,只保留当前恢复点、关键结论、风险与验证 + +### 本轮验证 - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - 结果:通过,`0 warning / 0 error` -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --filter "*RequestLifetimeBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过(沙箱外权威结果) - - 备注:当前 agent 沙箱内执行同一 benchmark 会在 BenchmarkDotNet 自动生成 bootstrap 阶段失败;切换到沙箱外后,`restore/build` 自举与 6 个 benchmark case 全部通过 - - 备注:`Singleton` 下 baseline / MediatR / GFramework 分别约 `5.633 ns / 58.687 ns / 301.731 ns` - - 备注:`Transient` 下 baseline / MediatR / GFramework 分别约 `5.044 ns / 52.274 ns / 287.863 ns` -- `env GIT_DIR=... GIT_WORK_TREE=... python3 scripts/license-header.py --check` +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --artifacts-suffix pr347-req-scoped --filter "*RequestLifetimeBenchmarks.SendRequest_GFrameworkCqrs*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - 结果:通过 -- `git diff --check` + - 备注:独立宿主目录位于 `BenchmarkDotNet.Artifacts/pr347-req-scoped/host/...` + - 结果摘要:`Singleton 52.69 ns / 32 B`、`Transient 57.88 ns / 56 B`、`Scoped 144.72 ns / 368 B` +- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release --no-build -- --artifacts-suffix pr347-stream-scoped --filter "*StreamLifetimeBenchmarks.Stream_GFramework*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - 结果:通过 + - 备注:独立宿主目录位于 `BenchmarkDotNet.Artifacts/pr347-stream-scoped/host/...` + - 结果摘要: + - `Singleton + FirstItem`:reflection `108.7 ns / 216 B`,generated `110.1 ns / 216 B` + - `Scoped + FirstItem`:reflection `266.7 ns / 792 B`,generated `267.0 ns / 792 B` + - `Scoped + DrainAll`:reflection `331.6 ns / 856 B`,generated `332.2 ns / 856 B` -### 当前下一步(RP-092) +### 当前结论 -1. 若 branch diff 仍明显低于 `$gframework-batch-boot 50` 阈值,下一批优先补 `stream handler` 生命周期矩阵,保持 request / stream benchmark 维度对称 -2. 若准备扩到 `Scoped` 生命周期,先为 benchmark host 设计真实显式作用域基线,再进入运行时对照 +- `Program.cs` 已不再依赖“命令行后缀”这一单一来源决定宿主隔离,环境变量生效路径也会进入隔离宿主。 +- scoped benchmark 的公平性问题已经实质收口:runtime 构造成本不再按每次调用重复计入生命周期矩阵。 +- active tracking / trace 已恢复到可供 `boot` 和后续 PR review 快速进入的体量;历史细节仍可通过新的 archive 文件追溯。 -## 2026-05-06 +### 当前下一步 -### 阶段:PR #331 review 收尾补丁(CQRS-REWRITE-RP-091) - -- 使用 `$gframework-pr-review` 拉取当前分支 `fix/package-validation-guard` 对应的 `PR #331` latest-head review 后,主线程只保留本地复核仍成立的问题: - - `.github/workflows/ci.yml` 的 `dotnet pack` 步骤缺少 `--no-build`,会在已完成 solution `Build` 后重复编译整仓库 - - `scripts/validate-packed-modules.sh` 使用 GNU `find -printf`,在 macOS / BSD `find` 下无法运行 - - `ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md` 的 active PR 锚点仍写成 `待创建`,与当前公开 PR 状态不一致 -- 本轮决策: - - `ci.yml` 的 pack 步骤显式补上 `--no-build`,使其与前置 `Build` 步骤形成单次编译链路 - - 共享包校验脚本改为使用 `find ... -exec basename {} \;`,避免依赖 GNU-only 选项 - - active tracking 同步到 `PR #331`,并把这轮 PR review 的剩余问题描述更新为当前已核验的真实范围 -- 预期结果: - - PR workflow 的 pack 阶段不再对同一 solution 重复编译 - - `validate-packed-modules.sh` 可在 GNU / BSD `find` 环境下保持相同行为 - - `cqrs-rewrite` active 恢复入口继续与当前公开 PR 保持一致 - -### 阶段:benchmark 发布面隔离与包清单校验前移(CQRS-REWRITE-RP-091) - -- 针对 tag 发布中出现的 `GFramework.Cqrs.Benchmarks` 异常包名单,本轮先复核 benchmark 项目与 solution pack 的本地事实: - - `GFramework.Cqrs.Benchmarks.csproj` 已包含 `IsPackable=false` 与 `GeneratePackageOnBuild=false` - - 本地执行 `dotnet pack GFramework.sln -c Release --no-restore -o /tmp/gframework-sln-pack-probe -p:IncludeSymbols=false` 时,产物仅包含 14 个预期发布包 - - 因此本轮不把 benchmark 包加入发布白名单,而是把“benchmark 永不发布”与“PR 前置完整包名单校验”同时固化 -- 本轮决策: - - 为 `GFramework.Cqrs.Benchmarks` 补充注释,明确其 benchmark-only 的发布边界 - - 新增 `scripts/validate-packed-modules.sh`,集中维护预期包集合与实际 `.nupkg` diff 逻辑 - - `publish.yml` 改为调用共享脚本,避免发布工作流与 PR 工作流各自维护一份包名单 - - `ci.yml` 新增 solution `dotnet pack` 与 packed modules 校验,把异常发布包从 tag 发布前移到普通 PR 阶段 -- 预期结果: - - benchmark / example / tooling 一类新项目若意外进入发布面,会先在 PR 失败,而不是等到 tag 发布 - - 发布与 PR 使用同一份包名单规则,减少后续名单漂移 - - `GFramework.Cqrs.Benchmarks` 继续只服务于 benchmark workflow,不进入 NuGet / GitHub Packages - -### 阶段:benchmark 对照宿主收敛与 startup cold-start 恢复(CQRS-REWRITE-RP-090) - -- 使用 `$gframework-pr-review` 拉取 `PR #326` latest-head review 后,主线程确认仍有效的 benchmark 反馈集中在三类问题: - - `RequestBenchmarks` 的 GFramework / MediatR handler 生命周期不对齐 - - `RequestStartupBenchmarks` 把容器构建、程序集扫描范围和缓存清理阶段混在一起,导致 cold-start 对照不公平 - - benchmark 工程里的 `MicrosoftDiContainer` 多处以 `ImplementationType` 方式注册 handler,但未在 runtime 分发前 `Freeze()`,首次真实解析路径存在隐藏失败风险 -- 本轮本地复核的关键根因: - - `MicrosoftDiContainer.Get(Type)` 在未冻结时只读取 `ImplementationInstance`,不会实例化 `ImplementationType` - - `ColdStart_GFrameworkCqrs` 清空 dispatcher 静态缓存后,首次发送必须走真实 handler 解析,因此会稳定触发 `No CQRS request handler registered` - - 多个 benchmark 同时采用“手工 MediatR 注册 + `RegisterServicesFromAssembly(...)` 全程序集扫描”,容易把无关 handler / behavior 一并纳入对照,且存在重复注册漂移 -- 本轮决策: - - 新增 `Messaging/BenchmarkHostFactory.cs`,统一 benchmark 最小宿主构建规则 - - GFramework benchmark 宿主统一先注册再 `Freeze()`,保证 steady-state 与 cold-start 都走真实可解析容器 - - MediatR benchmark 宿主统一通过 `TypeEvaluator` 限制到当前场景所需 handler / behavior 类型,保留正常 `AddMediatR` 组装路径,同时移除全程序集扫描噪音 - - `RequestStartupBenchmarks` 采用专用 `ColdStart` job,设置 `InvocationCount=1` 与 `WithUnrollFactor(1)`,并把 dispatcher cache reset 放到 `IterationSetup` -- 已修改的 benchmark 范围: - - `RequestBenchmarks` - - `RequestPipelineBenchmarks` - - `RequestStartupBenchmarks` - - `StreamingBenchmarks` - - `NotificationBenchmarks` - - `RequestInvokerBenchmarks` - - `StreamInvokerBenchmarks` -- 结果: - - `ColdStart_GFrameworkCqrs` 已恢复出有效结果,不再出现 `No CQRS request handler registered` - - `RequestBenchmarks`、`RequestStartupBenchmarks` 在本地均可实际运行 - - `RequestStartupBenchmarks` 目前仍会收到 BenchmarkDotNet 对单次 cold-start 场景的 `MinIterationTime` 提示;这是测量形状带来的工具提示,不再是运行级失败 - -### 验证(RP-090) - -- `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --json-output /tmp/gframework-current-pr-review.json` - - 结果:通过 - - 备注:确认当前分支对应 `PR #326`,仍有效的 open AI feedback 集中在 benchmark 对照语义与 active 文档收敛 -- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestStartupBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:`ColdStart_GFrameworkCqrs` 已恢复,最新本地输出约 `220-292 us`,`ColdStart_MediatR` 约 `575-616 us` -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:通过 - - 备注:steady-state request 对照可正常运行,未再触发 MediatR 重复注册或 GFramework 首次解析失败 - -### 阶段:PR #326 review 收尾补丁(CQRS-REWRITE-RP-090) - -- 再次使用 `$gframework-pr-review` 复核 `PR #326` latest-head open threads 后,主线程确认本轮仍成立且适合在当前 PR 内收敛的问题集中在四类: - - `.github/workflows/benchmark.yml` 的 `benchmark_filter` 直接插值到 shell,存在 workflow_dispatch 输入注入风险 - - `RequestInvokerBenchmarks` 与 `StreamInvokerBenchmarks` 的 MediatR handler 生命周期仍为 `Singleton`,与 GFramework 反射 / generated 路径的 transient 语义不一致 - - `RequestPipelineBenchmarks` 未在场景切换前后清理 dispatcher 缓存,且四个空 pipeline behavior 类型仍使用非法的分号类声明 - - `ai-plan/public/cqrs-rewrite` active 文档仍保留旧失败结论与重复日期标题,和“active 入口只保留最新权威恢复点”的约束不一致 -- 本轮刻意未扩展处理的 review: - - `MicrosoftDiContainer` 的释放契约建议会扩大到核心 Ioc 接口与全仓库生命周期语义,不适合作为 benchmark review 顺手改动 - - `RequestStartupBenchmarks` 的“手工单点注册 vs 受限程序集扫描”差异目前属于有意保留的最小宿主模型,代码注释已明确该设计边界 -- 已修改: - - `.github/workflows/benchmark.yml` - - `GFramework.Cqrs.Benchmarks/Messaging/RequestInvokerBenchmarks.cs` - - `GFramework.Cqrs.Benchmarks/Messaging/RequestPipelineBenchmarks.cs` - - `GFramework.Cqrs.Benchmarks/Messaging/StreamInvokerBenchmarks.cs` - - `ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md` - - `ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md` -- 预期结果: - - 手动 benchmark workflow 的过滤器输入不再直接参与 shell 解析 - - request / stream invoker 三路对照的 handler 生命周期重新回到同一基线 - - request pipeline benchmark 在 `0 / 1 / 4` 场景切换时不再复用旧 dispatcher cache - - active tracking / trace 更符合 boot 恢复入口所要求的“只保留最新权威结论”形状 - -## 2026-04-30 - -### 阶段:历史 PR #307 active 入口收敛(CQRS-REWRITE-RP-076) - -- 继续沿用 `$gframework-pr-review` 对 `PR #307` 做 latest-head triage,本轮只处理仍成立的 `ai-plan` 恢复入口问题 -- 主线程确认当前远端权威信号: - - 当时分支对应 `PR #307`,状态为 `OPEN` - - 远端 `CTRF` 最新汇总为 `2247/2247` passed - - `MegaLinter` 仅剩 `dotnet-format` 的 `Restore operation failed` 环境噪音 - - 仍未闭环的 review 重点集中在 `cqrs-rewrite` active tracking / trace 仍保留过多历史锚点,而非新的运行时代码缺陷 -- 本轮决策: - - 将 active tracking 收敛为单一恢复入口,只保留 `RP-076`、`PR #307`、活跃风险、最近权威验证与下一推荐步骤 - - 将 active trace 收敛为当前阶段的关键事实与决策,不再在默认恢复入口中保留 `RP-062` 之后的长阶段流水账 - - 新增 `archive/traces/cqrs-rewrite-history-rp062-through-rp076.md` 承接 `RP-062` 至 `RP-076` 的详细 trace 历史,保持旧阶段仍可追溯 - -### 验证(RP-076) - -- `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --format json --json-output ` - - 结果:通过 - - 备注:确认 `PR #307` 的当前 review 重点已收敛到 `ai-plan` 文档收尾 -- `dotnet build GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `dotnet test GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Does_Not_Emit_Stream_Invoker_Provider_Metadata_When_Runtime_Lacks_Stream_Provider_Interface|FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Does_Not_Emit_Stream_Invoker_Provider_Metadata_When_Runtime_Lacks_Stream_Descriptor_Enumerator|FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Does_Not_Emit_Stream_Invoker_Provider_Metadata_When_Runtime_Lacks_Stream_Descriptor_Type|FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Does_Not_Emit_Stream_Invoker_Provider_Metadata_When_Runtime_Lacks_Stream_Descriptor_Entry_Type|FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Emits_Stream_Invoker_Provider_Metadata_When_Runtime_Contract_Is_Available"` - - 结果:通过,`5/5` passed - -### 当前下一步(RP-076) - -1. 当时继续按 `PR #307` 的 latest-head review 收尾,优先保持 active tracking 与 active trace 的单一锚点一致 -2. 若继续推进代码切片,先复核 request 侧是否仍存在与 stream invoker gate 对称的生成合同遗漏 -3. 进入下一批前继续使用最小 Release build 或 targeted test 作为权威验证,避免把环境噪音误判为代码问题 - -## 2026-05-04 - -### 阶段:request invoker provider gate 对称回归(CQRS-REWRITE-RP-077) - -- 使用 `$gframework-batch-boot 25` 继续 `feat/cqrs-optimization` 的 CQRS 收口批次 -- 批次目标:在 branch diff 相对 `origin/main` 接近 `25` 个文件前,补齐低风险的 generator 合同回归切片 -- 本轮先确认当前 worktree 已无 `local-plan` 遗留恢复入口,随后转入 `cqrs-rewrite` 的 request / stream invoker provider gate 对称性复核 -- 结论: - - 生产代码已经同时检查 request provider、enumerator、descriptor 与 descriptor entry 四项 runtime 合同 - - request 侧测试只覆盖缺少 provider / enumerator,缺少 descriptor / descriptor entry 的回归覆盖落后于 stream 侧 -- 已补齐: - - `Does_Not_Emit_Request_Invoker_Provider_Metadata_When_Runtime_Lacks_Request_Descriptor_Type` - - `Does_Not_Emit_Request_Invoker_Provider_Metadata_When_Runtime_Lacks_Request_Descriptor_Entry_Type` - - source emission XML 文档同步说明 provider gate 依赖完整 descriptor / descriptor entry 合同 - -### 验证(RP-077) - -- `dotnet test GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Does_Not_Emit_Request_Invoker_Provider_Metadata_When_Runtime_Lacks_Request_Descriptor_Type|FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Does_Not_Emit_Request_Invoker_Provider_Metadata_When_Runtime_Lacks_Request_Descriptor_Entry_Type|FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Does_Not_Emit_Request_Invoker_Provider_Metadata_When_Runtime_Lacks_Request_Provider_Interface|FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Does_Not_Emit_Request_Invoker_Provider_Metadata_When_Runtime_Lacks_Request_Descriptor_Enumerator"` - - 结果:通过,`4/4` passed -- `dotnet build GFramework.Cqrs.SourceGenerators/GFramework.Cqrs.SourceGenerators.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `python3 scripts/license-header.py --check` - - 结果:通过 - - 备注:当前 WSL worktree 需要显式绑定 `GIT_DIR` / `GIT_WORK_TREE` 后运行,避免脚本内部 plain `git ls-files` 误判仓库上下文 -- `git diff --check` - - 结果:通过 - -### 当前下一步(RP-077) - -1. 继续使用 `origin/main` 作为 `$gframework-batch-boot 25` 的基线,复算 branch diff 后决定是否还能接下一批 -2. 若继续推进代码切片,优先查找 request / stream invoker provider runtime 合同之外的同类对称测试缺口 - -### 阶段:mixed fallback attribute usage 回归(CQRS-REWRITE-RP-078) - -- 继续沿用 `$gframework-batch-boot 25`,当前 branch diff 仍低于阈值 -- 复核 fallback metadata runtime contract 后确认: - - mixed fallback 在 runtime 允许多个 fallback attribute 实例时已有直接 `Type` + 字符串拆分回归 - - runtime 同时支持 `params Type[]` / `params string[]` 但不允许多个 fallback attribute 实例时,缺少锁定“整体回退到单个字符串 attribute”的回归 -- 已补齐: - - `Emits_String_Fallback_Metadata_For_Mixed_Fallback_When_Runtime_Disallows_Multiple_Fallback_Attributes` - - `ReplaceAttributeUsageForType` 测试辅助方法,用于构造 runtime attribute usage 变体而不复制大型 source fixture - -### 验证(RP-078) - -- `dotnet test GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Emits_String_Fallback_Metadata_For_Mixed_Fallback_When_Runtime_Disallows_Multiple_Fallback_Attributes"` - - 结果:通过,`1/1` passed -- `python3 scripts/license-header.py --check` - - 结果:通过 - - 备注:当前 WSL worktree 需要显式绑定 `GIT_DIR` / `GIT_WORK_TREE` 后运行 -- `git diff --check` - - 结果:通过 - -### 当前下一步(RP-078) - -1. 继续复算 branch diff vs `origin/main`,若仍低于 `25` 个文件可继续下一批 -2. 下一批优先查看 fallback metadata 与 generated invoker provider 之外是否还有同类 runtime contract gate 回归缺口 - -### 阶段:基础 generated registry contract gate 回归(CQRS-REWRITE-RP-079) - -- 继续沿用 `$gframework-batch-boot 25`,当前 branch diff 仍低于阈值 -- 复核 generator 基础启用条件后确认:缺少 `ICqrsHandlerRegistry` 时,runtime 不具备承载 generated registry 的基础接口合同,应整体跳过发射 -- 已补齐: - - `Does_Not_Generate_Registry_When_Runtime_Lacks_Handler_Registry_Interface` - -### 验证(RP-079) - -- `dotnet test GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Does_Not_Generate_Registry_When_Runtime_Lacks_Handler_Registry_Interface"` - - 结果:通过,`1/1` passed -- `python3 scripts/license-header.py --check` - - 结果:通过 - - 备注:当前 WSL worktree 需要显式绑定 `GIT_DIR` / `GIT_WORK_TREE` 后运行 -- `git diff --check` - - 结果:通过 - -### 当前下一步(RP-079) - -1. 继续复算 branch diff vs `origin/main`,若仍低于 `25` 个文件可继续下一批 -2. 下一批优先复核基础 generation gate 中其他必需 runtime contracts 是否也需要同类回归覆盖 - -### 阶段:基础 generated registry contract gate 扩展回归(CQRS-REWRITE-RP-080) - -- 将 `RP-079` 的单一 handler registry interface 缺失回归扩展为基础 generation gate 参数化测试 -- 已补齐缺失分支: - - `ICqrsHandlerRegistry` - - `INotificationHandler` - - `IStreamRequestHandler` - - `CqrsHandlerRegistryAttribute` -- stream handler interface 变体采用类型重命名构造 runtime metadata miss,避免删除命名空间尾部单行接口时引入输入编译错误 - -### 验证(RP-080) - -- `dotnet test GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Does_Not_Generate_Registry_When_Runtime_Lacks_Required_Generation_Contract"` - - 结果:通过,`4/4` passed -- `python3 scripts/license-header.py --check` - - 结果:通过 - - 备注:当前 WSL worktree 需要显式绑定 `GIT_DIR` / `GIT_WORK_TREE` 后运行 -- `git diff --check` - - 结果:通过 - -### 当前下一步(RP-080) - -1. 继续复算 branch diff vs `origin/main`,若仍低于 `25` 个文件可继续下一批 -2. 下一批优先复核基础 generation gate 中 logging / DI 依赖是否已有合适的输入编译安全回归覆盖方式 - -### 阶段:基础 generated registry external contract gate 回归(CQRS-REWRITE-RP-081) - -- 延续 `RP-080` 的参数化基础 generation gate 测试,将外部 logging / DI 依赖也纳入同一组静默跳过回归 -- 已补齐缺失分支: - - `GFramework.Core.Abstractions.Logging.ILogger` - - `Microsoft.Extensions.DependencyInjection.IServiceCollection` -- 两个变体均通过类型重命名构造 runtime metadata miss,保持输入源码可编译,避免把依赖缺失测试误写成编译失败测试 - -### 验证(RP-081) - -- `dotnet test GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Does_Not_Generate_Registry_When_Runtime_Lacks_Required_Generation_Contract"` - - 结果:通过,`6/6` passed -- `python3 scripts/license-header.py --check` - - 结果:通过 - - 备注:当前 WSL worktree 需要显式绑定 `GIT_DIR` / `GIT_WORK_TREE` 后运行 -- `git diff --check` - - 结果:通过 - -### 当前下一步(RP-081) - -1. 继续复算 branch diff vs `origin/main`,若仍低于 `25` 个文件可继续下一批 -2. 下一批优先复核基础 generation gate 中 request handler contract 与 handler registry attribute 以外是否还有可安全构造的缺失分支 - -### 阶段:基础 generated registry request handler gate 回归(CQRS-REWRITE-RP-082) - -- 延续 `RP-081` 的基础 generation gate 参数化测试,补齐 `IRequestHandler` 缺失分支 -- 该变体同样通过类型重命名构造 runtime metadata miss,保持输入源码可编译 -- 至此基础 generation gate 中可安全构造的缺失分支已覆盖: - - request handler interface - - notification handler interface - - stream handler interface - - handler registry interface - - handler registry attribute - - logging interface - - DI service collection interface - -### 验证(RP-082) - -- `dotnet test GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Does_Not_Generate_Registry_When_Runtime_Lacks_Required_Generation_Contract"` - - 结果:通过,`7/7` passed -- `python3 scripts/license-header.py --check` - - 结果:通过 - - 备注:当前 WSL worktree 需要显式绑定 `GIT_DIR` / `GIT_WORK_TREE` 后运行 -- `git diff --check` - - 结果:通过 - -### 当前下一步(RP-082) - -1. 继续复算 branch diff vs `origin/main`,若仍低于 `25` 个文件可继续下一批 -2. 下一批优先复核基础 generation gate 之外的 runtime contract 或 fallback selection 分支;基础 gate 的可安全构造缺失分支已覆盖 - -### 阶段:PR #323 review 锚点收敛(CQRS-REWRITE-RP-082) - -- 使用 `$gframework-pr-review` 重新拉取当前分支 PR review payload,确认当前分支对应 `PR #323`,状态为 `OPEN` -- 本轮 latest-head open AI thread 仅指出 active tracking 中仍保留 `PR #307` 作为当前 PR 锚点;本地复核后确认该反馈仍成立 -- 已将 active tracking 的当前 PR 锚点、活跃事实、最近 PR review 备注和下一推荐步骤统一到 `PR #323` -- `PR #307` 仅保留为历史 PR 说明和较早 trace 段落,不再作为 active 恢复入口 - -### 验证(PR #323 review) - -- `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --format json --json-output ` - - 结果:通过 - - 备注:确认 `PR #323` 只有 1 个 CodeRabbit open thread,指向 active tracking 的 PR 锚点漂移 -- 远端 `CTRF` 最新汇总为 `2274/2274` passed -- `MegaLinter` 当前仅报告 `dotnet-format` 的 `Restore operation failed` 环境噪音,未提供本地仍成立的文件级格式诊断 -- `git diff --check` - - 结果:通过 -- `python3 scripts/license-header.py --check` - - 结果:通过 - - 备注:当前 WSL worktree 需要显式绑定 `GIT_DIR` / `GIT_WORK_TREE` 后运行 -- `dotnet build GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - -### 当前下一步(PR #323 review) - -1. 若 review 重新触发后仍有 latest-head open thread,继续以 `PR #323` 为当前唯一 PR 恢复锚点复核 -2. 后续若继续推进代码切片,优先复核基础 generation gate 之外的 runtime contract 或 fallback selection 分支 - -## 2026-05-06(RP-083 ~ RP-089) - -### 阶段:mixed invoker provider 排序回归(CQRS-REWRITE-RP-083) - -- 使用 `$gframework-batch-boot 50` 继续 `feat/cqrs-optimization` 的 CQRS 收口批次 -- 批次目标:在 branch diff 相对 `origin/main` 接近 `50` 个文件前,继续补齐低风险的 generator runtime contract / emission 回归 -- 本轮基线选择: - - `origin/main a8c6c11e`,committer date `2026-05-05 13:14:24 +0800` - - `main a8c6c11e`,committer date `2026-05-05 13:14:24 +0800` - - 当前分支 `feat/cqrs-optimization a8c6c11e`,committer date `2026-05-05 13:14:24 +0800` -- 启动时 branch diff vs `origin/main` 为 `0` files / `0` lines,因此继续选择低风险测试回归切片 -- 本轮复核 `CreateGeneratedRegistrySourceShape` 与 invoker emission 路径后确认: - - 现有测试已覆盖 request / stream provider 的单一 direct 场景、单一 reflected-implementation 场景、precise reflected 跳过边界,以及各项 runtime contract 缺失分支 - - 尚未锁定“同一 registry 同时包含 direct registration 与 reflected-implementation registration”时的 descriptor 顺序与 `Invoke*HandlerN` 编号稳定性 -- 已补齐: - - `Emits_Request_Invoker_Provider_Metadata_In_Stable_Order_For_Mixed_Direct_And_Reflected_Implementations` - - `Emits_Stream_Invoker_Provider_Metadata_In_Stable_Order_For_Mixed_Direct_And_Reflected_Implementations` - - 两组 source fixture:`MixedRequestInvokerProviderSource`、`MixedStreamInvokerProviderSource` -- 通过新增回归,显式锁定以下约束: - - provider descriptor 条目按稳定实现排序输出 - - `InvokeRequestHandler0/1` 与 `InvokeStreamHandler0/1` 的方法编号随 emission 顺序连续增长 - - 隐藏实现类型不会破坏 direct registration 与 reflected-implementation registration 的混合发射 - -### 验证(RP-083) - -- `dotnet test GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Emits_Request_Invoker_Provider_Metadata_In_Stable_Order_For_Mixed_Direct_And_Reflected_Implementations|FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Emits_Stream_Invoker_Provider_Metadata_In_Stable_Order_For_Mixed_Direct_And_Reflected_Implementations"` - - 结果:通过,`2/2` passed - -### 当前 stop-condition 度量(RP-083) - -- primary metric:branch diff files vs `origin/main` -- 当前说明:active batch 尚未提交时,基于 `HEAD` 的 branch diff 仍显示 `0` files / `0` lines;提交本批后再以新 `HEAD` 复算累计 branch diff - -### 当前下一步(RP-083) - -1. 提交本轮 mixed invoker provider 排序回归后,复算 branch diff vs `origin/main`,确认 `50` 文件阈值仍有充足余量 -2. 若继续推进代码切片,优先复核 invoker provider 之外的 runtime contract 或 fallback selection 分支 - -### 阶段:benchmark 基础设施引入(CQRS-REWRITE-RP-084) - -- 用户明确将当前长期分支目标上提为:系统性吸收 `ai-libs/Mediator` 的实现思路与设计哲学,并将可取部分纳入 `GFramework.Cqrs` -- 本轮据此调整批次目标,不再把关注点收缩到单个 generator 回归,而是建立能持续比较和吸收设计差异的 benchmark 基础设施 -- 参考 `ai-libs/Mediator` 的 benchmark 设计后,本轮采纳的核心结构包括: - - 独立 benchmark 项目壳,而非扩展现有 NUnit 测试项目 - - 共享 `Fixture` 输出并校验场景配置 - - `Request` / `Notification` 两个 messaging 场景作为首批最小落点 - - 自定义列 `CustomColumn`,为后续矩阵扩展保留可读结果标签 -- 本轮新增: - - `GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj` - - `GFramework.Cqrs.Benchmarks/Program.cs` - - `GFramework.Cqrs.Benchmarks/CustomColumn.cs` - - `GFramework.Cqrs.Benchmarks/Messaging/Fixture.cs` - - `GFramework.Cqrs.Benchmarks/Messaging/BenchmarkContext.cs` - - `GFramework.Cqrs.Benchmarks/Messaging/RequestBenchmarks.cs` - - `GFramework.Cqrs.Benchmarks/Messaging/NotificationBenchmarks.cs` - - `GFramework.Cqrs.Benchmarks/README.md` -- 设计取舍: - - 使用最小 `ICqrsContext` marker,避免把完整 `ArchitectureContext` 初始化成本混入 steady-state dispatch - - 直接复用 `GFramework.Cqrs.CqrsRuntimeFactory` 与 `MicrosoftDiContainer`,让基准聚焦于 runtime dispatch / publish - - 外部对照组先接入 `MediatR`,保持与 `Mediator` benchmark 的对照哲学一致;但本轮仍只做最小 request / notification 场景 - - 暂不把 source generator benchmark、cold-start 独立工程或完整 pipeline / stream 矩阵一起引入,避免首批 scope 失控 -- 兼容性修正: - - 在根 `GFramework.csproj` 中显式排除 `GFramework.Cqrs.Benchmarks/**`,避免 meta-package 意外编译 benchmark 源码 - - 将 benchmark 项目加入 `GFramework.sln`,保持仓库级工作流完整 - -### 验证(RP-084) - -- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `GIT_DIR= GIT_WORK_TREE= python3 scripts/license-header.py --check` - - 结果:通过 -- `git diff --check` - - 结果:通过 - -### 当前 stop-condition 度量(RP-084) - -- primary metric:branch diff files vs `origin/main` -- 当前说明:本轮仍在 `50` 文件阈值以内,可继续按 benchmark 场景或 CQRS runtime 对照能力分批推进 - -### 当前下一步(RP-084) - -1. 继续扩展 `GFramework.Cqrs.Benchmarks`,优先补齐 pipeline、stream、cold-start 与 generated invoker provider 对照场景 -2. 当后续有具体 runtime 优化切片时,用该 benchmark 项目验证是否真正吸收到了 `Mediator` 的低开销 dispatch 设计收益 - -### 阶段:stream request benchmark 对照(CQRS-REWRITE-RP-085) - -- 继续沿用 `$gframework-batch-boot 50`,当前 branch diff 相对 `origin/main` 仍明显低于阈值 -- 在 `RP-084` 已建立独立 benchmark 项目后,本轮优先补齐 `ai-libs/Mediator/benchmarks/Mediator.Benchmarks/Messaging/StreamingBenchmarks.cs` 对应的最小 stream 场景 -- 选择 stream 作为第二批 benchmark 的原因: - - 已有独立的 `CreateStream` runtime 路径和单独的 stream invoker provider 元数据契约 - - 与 `Mediator` 的 messaging benchmark 分层直接对应 - - 不需要像 pipeline / cold-start 那样先进一步澄清运行时或宿主边界 -- 本轮新增: - - `GFramework.Cqrs.Benchmarks/Messaging/StreamingBenchmarks.cs` - - `GFramework.Cqrs.Benchmarks/README.md` 中的 stream 场景说明 -- 设计约束: - - 保持与前一批一致的三路对照:`Baseline`、`GFramework.Cqrs`、`MediatR` - - 基准测量“完整枚举 3 个元素”的全量消费成本,而不是只测创建异步枚举器 - - 使用最小 `ICqrsContext` marker,继续避免把完整 `ArchitectureContext` 初始化成本混入 steady-state stream dispatch -- 结论: - - 当前 benchmark 项目已经覆盖 `Request`、`Notification`、`StreamRequest` 三个核心 messaging steady-state 场景 - - 下一批更适合转向 request pipeline 数量矩阵或 cold-start / initialization,而不是继续扩同层次的 messaging 基线 - -### 验证(RP-085) - -- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `GIT_DIR= GIT_WORK_TREE= python3 scripts/license-header.py --check` - - 结果:通过 -- `git diff --check` - - 结果:通过 - -### 当前 stop-condition 度量(RP-085) - -- primary metric:branch diff files vs `origin/main` -- 当前说明:新增 stream benchmark 后仍处于 `50` 文件阈值以内,适合继续下一批 request pipeline 或 cold-start 场景 - -### 当前下一步(RP-085) - -1. 继续扩展 `GFramework.Cqrs.Benchmarks`,优先补齐 request pipeline 数量矩阵,随后再评估 cold-start / initialization -2. 当需要验证 generated invoker provider 的实际收益时,把 request benchmark 扩展为 reflection / generated provider 对照,而不是只停留在框架间对比 - -### 阶段:request pipeline 数量矩阵(CQRS-REWRITE-RP-086) - -- 继续沿用 `$gframework-batch-boot 50`,当前 branch diff 相对 `origin/main` 仍明显低于阈值 -- 本轮把 benchmark 关注点从单纯 messaging steady-state 扩展到 request pipeline 编排行为,原因是: - - `ai-libs/Mediator` 的对照价值已经不只在 request / notification / stream 三个入口本身,还在 pipeline 包装策略与生命周期取舍 - - `GFramework.Cqrs.Internal.CqrsDispatcher` 已按 `behaviorCount` 缓存 `RequestPipelineExecutor` 形状,因此单独量化 `0 / 1 / 4` 个行为的 steady-state 开销有直接信息密度 -- 本轮新增: - - `GFramework.Cqrs.Benchmarks/Messaging/RequestPipelineBenchmarks.cs` - - `GFramework.Cqrs.Benchmarks/README.md` 中的 request pipeline 场景说明 -- 设计取舍: - - 采用 `0 / 1 / 4` 个 pipeline 行为,而不是立即扩到更大的参数空间,先锁定最有代表性的无行为 / 少量行为 / 常见多行为矩阵 - - 使用最小 no-op 行为族,不引入日志、计时或上下文刷新逻辑,避免把测量结果污染成业务行为成本 - - `GFramework.Cqrs` 与 `MediatR` 侧都只注册当前 benchmark 请求对应的闭合行为类型,确保矩阵反映编排成本而非程序集扫描差异 -- 接受的只读 subagent 结论: - - 下一批 benchmark 继续优先考虑 `cold-start / initialization` 与 `generated provider` 对照,而不是立即照搬 `Mediator` 的 large-project 维度 - - 当前 `GFramework.Cqrs.Benchmarks` 仍未接入 `Mediator` 包和 `GFramework.Cqrs.SourceGenerators`,因此本轮不扩成 `Mediator_IMediator` / generated-provider 对照,避免 scope 失控 -- 结论: - - 当前 benchmark 项目已经覆盖 `Request`、`Notification`、`StreamRequest` 与 `RequestPipeline` - - 后续若要继续贴近 `Mediator` 的 comparison benchmark,最值得优先补的是 initialization / first-hit 与 generated invoker provider,而不是继续横向堆更多 steady-state messaging 入口 - -### 验证(RP-086) - -- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - -### 当前 stop-condition 度量(RP-086) - -- primary metric:branch diff files vs `origin/main` -- 当前说明:提交前基于 `HEAD` 的 branch diff 仍为 `14` files,距离 `50` 文件阈值仍有明显余量 - -### 当前下一步(RP-086) - -1. 提交本轮 request pipeline benchmark 后,继续扩展 `GFramework.Cqrs.Benchmarks`,优先补齐 initialization / cold-start 场景 -2. 当需要验证 dispatcher 预热与 source generator 收益时,引入 generated invoker provider 对照,并评估是否同时接入 `Mediator` concrete runtime 作为更贴近设计哲学的外部参照 - -### 阶段:request startup 基线(CQRS-REWRITE-RP-087) - -- 继续沿用 `$gframework-batch-boot 50`,当前 branch diff 相对 `origin/main` 仍明显低于阈值 -- 本轮目标:把 benchmark 从 steady-state dispatch 再向前推进一层,补齐与 `ai-libs/Mediator/benchmarks/Mediator.Benchmarks/Messaging/Comparison/*` 更接近的 startup 维度 -- 本轮新增: - - `GFramework.Cqrs.Benchmarks/Messaging/RequestStartupBenchmarks.cs` - - `GFramework.Cqrs.Benchmarks/README.md` 中的 startup 场景说明 -- 设计取舍: - - `Initialization` 只测“从已配置宿主解析/创建 runtime 句柄”的成本,不把完整架构初始化混入 benchmark - - `ColdStart` 只测新宿主上的首次 request send;`GFramework.Cqrs` 侧在每次 benchmark 前通过反射清空 dispatcher 静态缓存,避免把热缓存误当 first-hit - - `ColdStart_MediatR` 改为真正 `await` 完任务后再释放 `ServiceProvider`,以满足 `Meziantou.Analyzer` 对资源生命周期的要求,并避免 benchmark 本身含有错误宿主释放语义 -- 结论: - - 当前 benchmark 项目已经覆盖 `Request`、`Notification`、`StreamRequest`、`RequestPipeline`、`RequestStartup` - - 后续若继续贴近 `Mediator` comparison benchmark,下一批最有价值的是 generated invoker provider、registration / service lifetime 与 concrete runtime 外部对照,而不是继续只加同层 steady-state case - -### 验证(RP-087) - -- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - -### 当前 stop-condition 度量(RP-087) - -- primary metric:branch diff files vs `origin/main` -- 当前说明:提交前 branch diff 仍远低于 `50` 文件阈值,可继续下一批 benchmark 或低风险 runtime 对照切片 - -### 当前下一步(RP-087) - -1. 提交本轮 request startup benchmark 后,继续扩展 `GFramework.Cqrs.Benchmarks`,优先评估 generated invoker provider 与 registration / service lifetime 矩阵 -2. 若要更贴近 `Mediator` 的 comparison benchmark 设计哲学,评估是否在 benchmark 项目中同时接入 `Mediator` concrete runtime 对照,而不只保留 `MediatR` - -### 阶段:request invoker reflection / generated 对照(CQRS-REWRITE-RP-088) - -- 继续沿用 `$gframework-batch-boot 50`,当前 branch diff 相对 `origin/main` 仍明显低于阈值 -- 本轮目标:不再只比较 `GFramework.Cqrs` 与 `MediatR` 的外层框架差异,而是开始直接量化 `GFramework.Cqrs` 内部 reflection request binding 与 generated invoker provider 路径的 steady-state 差异 -- 本轮新增: - - `GFramework.Cqrs.Benchmarks/Messaging/RequestInvokerBenchmarks.cs` - - `GFramework.Cqrs.Benchmarks/Messaging/GeneratedRequestInvokerBenchmarkRegistry.cs` - - `GFramework.Cqrs.Benchmarks/README.md` 中的 generated invoker 场景说明 -- 设计取舍: - - 采用 benchmark 内手写的 generated registry/provider“等价物”,而不是当轮就把真实 `GFramework.Cqrs.SourceGenerators` 接到 benchmark 项目中,目的是先走通真实的 registrar -> descriptor 预热 -> dispatcher generated path,同时把写入面控制在低风险范围 - - generated 对照使用程序集级 `CqrsHandlerRegistryAttribute` + `ICqrsRequestInvokerProvider` + `IEnumeratesCqrsRequestInvokerDescriptors`,确保运行时语义与生产路径一致 - - 在 benchmark 生命周期前后清理 dispatcher 静态缓存,避免 generated descriptor 预热状态跨场景泄漏,污染 reflection 对照 -- 结论: - - 当前 benchmark 项目已经能区分 `GFramework.Cqrs` 的 reflection request 路径、generated request 路径与 `MediatR` 外部对照 - - 后续若继续贴近 `Mediator` comparison benchmark,下一批更适合扩到 registration / service lifetime、stream generated provider,或再决定是否接入 `Mediator` concrete runtime - -### 验证(RP-088) - -- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` - -### 当前 stop-condition 度量(RP-088) - -- primary metric:branch diff files vs `origin/main` -- 当前说明:提交前 branch diff 仍远低于 `50` 文件阈值,可继续推进下一批 benchmark 对照切片 - -### 当前下一步(RP-088) - -1. 提交本轮 request invoker benchmark 后,继续扩展 `GFramework.Cqrs.Benchmarks`,优先评估 registration / service lifetime 或 stream generated provider - -### 阶段:stream invoker reflection / generated 对照(CQRS-REWRITE-RP-089) - -- 使用 `$gframework-batch-boot 30` 继续 `feat/cqrs-optimization` 的 CQRS 收口批次 -- 本轮基线选择: - - `origin/main c01abac0`,committer date `2026-05-06 09:40:08 +0800` - - `main a8c6c11e`,committer date `2026-05-05 13:14:24 +0800` -- 启动时 branch diff vs `origin/main` 为 `18` files / `2100` lines,低于 `30` 文件阈值,因此继续选择单模块、低风险 benchmark 切片 -- 复核 `GFramework.Cqrs.Benchmarks` 与 `ai-libs/Mediator/benchmarks` 后确认: - - `RP-088` 已把 generated descriptor 预热收益量化到 request dispatch 路径 - - stream benchmark 仍停留在 direct handler / reflection runtime / `MediatR` 三路对照,尚未量化 generated stream invoker provider 的收益 - - 虽然 `Mediator` 参考基准大量使用 service lifetime 矩阵,但当前 `GFramework.Cqrs.Benchmarks` 尚未建立对称的 scoped host 模式;直接扩 lifetime 会引入超出本批风险预算的宿主语义变化 -- 本轮因此优先选择 request 对称切片,而不是 service lifetime 扩展: - - 新增 `Messaging/StreamInvokerBenchmarks.cs` - - 新增 `Messaging/GeneratedStreamInvokerBenchmarkRegistry.cs` - - 更新 `GFramework.Cqrs.Benchmarks/README.md` -- 设计约束: - - 继续沿用 handwritten generated registry/provider 模式,避免把 benchmark 基础设施与真实 source-generator 输出耦合 - - 复用与 `RP-088` 相同的 dispatcher 缓存清理策略,确保 reflection / generated 路径对照不受静态缓存残留污染 - - 使用统一的异步枚举体工厂,让三组 stream handler 共享同一枚举成本基线,把变量收敛到 invoker/provider 接线路径 - -### 当前下一步(RP-089) - -1. 完成本轮 benchmark 项目 Release build、license header 检查与 diff 校验后,更新 active tracking 的权威验证列表 -2. 若 branch diff 仍明显低于 `30` 文件阈值,可继续评估 notification publish strategy 或更贴近 `Mediator` concrete runtime 的单批对照 -3. 若要继续贴近 `Mediator` 的 comparison benchmark 设计哲学,评估是否把 `Mediator` concrete runtime 本身接入 benchmark 项目,而不是长期只保留 `MediatR` - -### 验证(RP-089) - -- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` - - 结果:通过,`0 warning / 0 error` -- `GIT_DIR= GIT_WORK_TREE= python3 scripts/license-header.py --check` - - 结果:通过 -- `git diff --check` - - 结果:通过 -- `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestStartupBenchmarks*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1` - - 结果:部分通过;`MediatR` startup benchmark 已恢复真实测量,`ColdStart_GFrameworkCqrs` 仍因 `No CQRS request handler registered` 失败 - -### 阶段:手动 benchmark workflow(CQRS-REWRITE-RP-089) - -- 新增 `.github/workflows/benchmark.yml`,提供仅 `workflow_dispatch` 触发的 benchmark 入口 -- workflow 默认只执行 `GFramework.Cqrs.Benchmarks` 的 Release build,避免在当前已知 `RequestStartupBenchmarks` 残留未清时默认运行失败 -- 只有在手动输入 `benchmark_filter` 时才执行 BenchmarkDotNet,并上传 `BenchmarkDotNet.Artifacts` 供后续比较 +- 推送本轮变更后,重新运行 `$gframework-pr-review`,确认 `PR #347` 的 latest-head open thread 是否已随着新 head 收敛。