docs(cqrs): 更新生成式 invoker 恢复点

- 更新 CQRS 重写跟踪到 RP-070,补充 hidden-implementation generated invoker runtime 回归说明

- 补充本轮定向验证结果与当前相对 origin/main 的 branch diff 指标
This commit is contained in:
gewuyou 2026-04-30 14:37:12 +08:00
parent 5a77e2fb33
commit 6b5c5d9e2d
2 changed files with 38 additions and 3 deletions

View File

@ -7,7 +7,7 @@ CQRS 迁移与收敛。
## 当前恢复点 ## 当前恢复点
- 恢复点编号:`CQRS-REWRITE-RP-069` - 恢复点编号:`CQRS-REWRITE-RP-070`
- 当前阶段:`Phase 8` - 当前阶段:`Phase 8`
- 当前焦点: - 当前焦点:
- 已完成一轮 `CQRS vs Mediator` 只读评估归档,结论已沉淀到 `archive/todos/cqrs-vs-mediator-assessment-rp063.md` - 已完成一轮 `CQRS vs Mediator` 只读评估归档,结论已沉淀到 `archive/todos/cqrs-vs-mediator-assessment-rp063.md`
@ -64,6 +64,11 @@ CQRS 迁移与收敛。
- `CqrsHandlerRegistryGenerator` 现会把 generated request / stream invoker 的发射范围,从“仅 direct registration”扩大到“实现类型隐藏、但 handler interface 仍可直接表达”的 reflected-implementation registration - `CqrsHandlerRegistryGenerator` 现会把 generated request / stream invoker 的发射范围,从“仅 direct registration”扩大到“实现类型隐藏、但 handler interface 仍可直接表达”的 reflected-implementation registration
- 当前扩展仍刻意避开 `PreciseReflectedRegistrationSpec`,不把隐藏 request/response 类型误拉进 provider 发射,继续保持生成源码可编译边界 - 当前扩展仍刻意避开 `PreciseReflectedRegistrationSpec`,不把隐藏 request/response 类型误拉进 provider 发射,继续保持生成源码可编译边界
- `GFramework.SourceGenerators.Tests` 已新增两条 hidden-implementation 回归,锁定 request / stream provider 在该场景下都会继续发射 descriptor 与静态 invoker 方法 - `GFramework.SourceGenerators.Tests` 已新增两条 hidden-implementation 回归,锁定 request / stream provider 在该场景下都会继续发射 descriptor 与静态 invoker 方法
- 已完成一轮 hidden-implementation generated invoker runtime 回归补强:
- `GFramework.Cqrs.Tests/Cqrs/CqrsGeneratedRequestInvokerProviderTests.cs` 现覆盖“实现类型隐藏、但 handler interface 可见”场景下的 generated request / stream invoker 消费路径
- `HiddenImplementationGeneratedRequestInvokerProviderRegistry``HiddenImplementationGeneratedStreamInvokerProviderRegistry` 与对应 container / handler fixture 现锁定 registrar 接线后dispatcher 会优先命中 generated descriptor而不是退回反射 invoker
- 当前 runtime 回归继续保持 `PreciseReflectedRegistrationSpec` 排除边界不变,只验证已允许发射 provider 元数据的 visible-interface hidden-implementation 场景
- 当前相对 `origin/main` 的累计 branch diff 为 `24 files / 1754 changed lines`,仍低于本轮 `$gframework-batch-boot 50` 的主要 stop condition可继续推进下一批低风险切片
- 已将 mixed fallback 场景进一步收敛:当 runtime 允许同一程序集声明多个 `CqrsReflectionFallbackAttribute` 实例时generator 现会把可直接引用的 fallback handlers 与仅能按名称恢复的 fallback handlers 拆分发射 - 已将 mixed fallback 场景进一步收敛:当 runtime 允许同一程序集声明多个 `CqrsReflectionFallbackAttribute` 实例时generator 现会把可直接引用的 fallback handlers 与仅能按名称恢复的 fallback handlers 拆分发射
- `CqrsReflectionFallbackAttribute` 现允许多实例,以承载 `Type[]` 与字符串 fallback 元数据的组合输出 - `CqrsReflectionFallbackAttribute` 现允许多实例,以承载 `Type[]` 与字符串 fallback 元数据的组合输出
- 已将 generator 的程序集级 fallback 元数据进一步收敛:当全部 fallback handlers 都可直接引用且 runtime 暴露 `params Type[]` 合同时,生成器现优先发射 `typeof(...)` 形式的 fallback 元数据 - 已将 generator 的程序集级 fallback 元数据进一步收敛:当全部 fallback handlers 都可直接引用且 runtime 暴露 `params Type[]` 合同时,生成器现优先发射 `typeof(...)` 形式的 fallback 元数据
@ -268,6 +273,9 @@ CQRS 迁移与收敛。
- `dotnet test GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Emits_Request_Invoker_Provider_Metadata_For_Hidden_Implementation_With_Visible_Interface|FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Emits_Stream_Invoker_Provider_Metadata_For_Hidden_Implementation_With_Visible_Interface|FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Emits_Request_Invoker_Provider_Metadata_When_Runtime_Contract_Is_Available|FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Emits_Stream_Invoker_Provider_Metadata_When_Runtime_Contract_Is_Available"` - `dotnet test GFramework.SourceGenerators.Tests/GFramework.SourceGenerators.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Emits_Request_Invoker_Provider_Metadata_For_Hidden_Implementation_With_Visible_Interface|FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Emits_Stream_Invoker_Provider_Metadata_For_Hidden_Implementation_With_Visible_Interface|FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Emits_Request_Invoker_Provider_Metadata_When_Runtime_Contract_Is_Available|FullyQualifiedName~CqrsHandlerRegistryGeneratorTests.Emits_Stream_Invoker_Provider_Metadata_When_Runtime_Contract_Is_Available"`
- 结果:通过 - 结果:通过
- 备注:`4/4` passed确认 hidden implementation + visible interface 场景也会继续发射 request / stream invoker provider 元数据 - 备注:`4/4` passed确认 hidden implementation + visible interface 场景也会继续发射 request / stream invoker provider 元数据
- `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsGeneratedRequestInvokerProviderTests"`
- 结果:通过
- 备注:`8/8` passed补齐 hidden implementation + visible interface 场景后,确认 generated request / stream invoker 在 runtime 侧也会优先命中 provider descriptor
- `dotnet build GFramework.Core/GFramework.Core.csproj -c Release` - `dotnet build GFramework.Core/GFramework.Core.csproj -c Release`
- 结果:通过 - 结果:通过
- 备注:`0 warning / 0 error`;确认 `CqrsRuntimeModule` 接线变更未引入 `GFramework.Core` 模块构建问题 - 备注:`0 warning / 0 error`;确认 `CqrsRuntimeModule` 接线变更未引入 `GFramework.Core` 模块构建问题
@ -301,6 +309,6 @@ CQRS 迁移与收敛。
## 下一步 ## 下一步
1. 基于已落地的 notification publisher seam评估是否需要第二阶段公开配置面、并行 publisher 或 telemetry decorator 1. 在保持 branch diff 明显低于 `50 files` 的前提下,继续挑选下一批低风险 `dispatch/invoker` 收敛切片,并优先考虑 request / stream provider 的诊断、入口或测试补强
2. 基于已落地的 request invoker provider评估是否继续把 notification / stream 的 invoker 也前移,或先补 provider 发现/诊断与文档入口 2. 基于已落地的 notification publisher seam评估是否需要第二阶段公开配置面、并行 publisher 或 telemetry decorator
3. 单独规划旧 `Command` / `Query` API 的收口顺序;`LegacyICqrsRuntime` compatibility slice 已收口到显式 helper 与专门测试,可暂时移出最高优先级 3. 单独规划旧 `Command` / `Query` API 的收口顺序;`LegacyICqrsRuntime` compatibility slice 已收口到显式 helper 与专门测试,可暂时移出最高优先级

View File

@ -2,6 +2,33 @@
## 2026-04-30 ## 2026-04-30
### 阶段hidden-implementation generated invoker runtime 回归补强CQRS-REWRITE-RP-070
- 在 `5a77e2fb` 提交后补齐 active `ai-plan` 恢复入口,继续按 `gframework-batch-boot 50` 执行,基线仍为当前本地 `origin/main`
- 当前已提交 branch diff 复算为 `24 files / 1754 changed lines`,仍低于主要 stop condition因此本轮只补 runtime 回归与恢复点,不改 generator / runtime 生产实现
- 本轮关键目标是把 `RP-069` 已落地的 hidden-implementation provider 发射范围补强,继续向 runtime 消费侧闭环,避免 active tracking 只记录了 generator 侧验证
- 主线程已完成:
- `GFramework.Cqrs.Tests/Cqrs/CqrsGeneratedRequestInvokerProviderTests.cs` 新增 hidden-implementation + visible-interface 的 request / stream runtime 回归
- `HiddenImplementationGeneratedRequestInvokerProviderRegistry``HiddenImplementationGeneratedStreamInvokerProviderRegistry` 与对应 container fixture 已被纳入同一组 provider 消费测试,锁定 registrar 接线与 dispatcher 优先命中 generated descriptor 的语义
- 当前测试仍保持 `PreciseReflectedRegistrationSpec` 排除边界不变,不把隐藏 request/response 类型场景错误抬升为 runtime 支持承诺
### 验证RP-070
- `dotnet test GFramework.Cqrs.Tests/GFramework.Cqrs.Tests.csproj -c Release --filter "FullyQualifiedName~CqrsGeneratedRequestInvokerProviderTests"`
- 结果:通过,`8/8` passed
- `git diff --name-only origin/main...HEAD | wc -l`
- 结果:通过
- 备注:当前相对 `origin/main` 的已提交 branch diff 为 `24 files`
- `git diff --numstat origin/main...HEAD`
- 结果:通过
- 备注:当前相对 `origin/main` 的已提交 branch diff 为 `1754 changed lines`
### 当前下一步RP-070
1. 先提交本轮 `ai-plan` 恢复点更新,保持 batch 追踪与已提交代码状态一致
2. 在剩余 headroom 内继续选择下一批低风险 `dispatch/invoker` 收敛切片,优先考虑 request / stream provider 的诊断、入口或测试补强
3. 如下一批写集仍可拆分,再用只读 / 写入 subagent 分离非冲突切片,继续降低主线程上下文压力
### 阶段generated stream invoker provider 最小落地CQRS-REWRITE-RP-068 ### 阶段generated stream invoker provider 最小落地CQRS-REWRITE-RP-068
- 继续按 `gframework-batch-boot 50` 执行,基线仍为当前本地 `origin/main` - 继续按 `gframework-batch-boot 50` 执行,基线仍为当前本地 `origin/main`