[refactor-design] iter18 cluster-006-command-path-projection-lifecycle

[loning]

id: cluster-006-command-path-projection-lifecycle
rule_ids: [R-WRITE-OBSERVE-001, R-PROJECTION-ACTOR-001]
severity: medium
requires_design: true
files_touched_estimate: 8-20
old_pattern: "Command/application services call EnsureProjection/ActivateProjection inline before or around writes."
new_pattern: "Write path dispatches command/event only; projection activation is explicit setup, actor-owned binding, or background materializer outside command request stack."

Evidence:

• src/workflow/Aevatar.Workflow.Infrastructure/Runs/WorkflowRunActorPort.cs:75-76: activates binding and materialization during run creation.
• src/platform/Aevatar.GAgentService.Application/Services/ServiceCommandApplicationService.cs:47 and later: command methods ensure read projections.
• src/platform/Aevatar.GAgentService.Governance.Application/Services/ServiceGovernanceCommandApplicationService.cs:34: governance command primes projection.
• src/platform/Aevatar.GAgentService.Infrastructure/Adapters/LlmSessionRegistrationAdapter.cs:49: registration adapter ensures projection after creating actor.

Fix boundary:

• Separate command/write lifecycle from projection activation.
• Keep projection startup services or explicit activation APIs if they are outside query/write request paths.
• Add code comment in command services: New pattern: command path emits facts; readmodel visibility is observed asynchronously.

human_brief:
problem_title: "写路径顺手启动读模型投影"
problem_statement: |
多个 command/application service 在创建或修改 actor 时，会同步调用 EnsureProjection 或 ActivateAsync。这让一次写请求同时承担写侧命令和读侧物化准备，调用方很容易误以为返回后 readmodel 已经可见。开发者会关心这个问题，因为这会模糊 ACK 语义，也让 query/readmodel 的生命周期散落在各个业务入口。
problem_example_file_path: "src/workflow/Aevatar.Workflow.Infrastructure/Runs/WorkflowRunActorPort.cs:67-82"
problem_example_code: |
runActor = await _runtime.CreateAsync(
BuildRunActorId(definitionResolution.ActorId),
ct: ct);
createdActorIds.Add(runActor.Id);
if (!string.IsNullOrWhiteSpace(definitionResolution.ActorId))
await _runtime.LinkAsync(definitionResolution.ActorId, runActor.Id, ct);
await EnsureBindingProjectionAsync(runActor.Id, ct); // ← problem: 写路径同步启动 binding projection
await EnsureExecutionMaterializationAsync(runActor.Id, ct); // ← problem: 写路径同步启动 materialization

await _dispatchPort.DispatchAsync(
    runActor.Id,
    CreateWorkflowRunBindEnvelope(
        definitionResolution.ActorId,
        runActor.Id,
        definition.WorkflowYaml,

why_needs_design: |
需要决定 projection activation 是资源创建的一部分、后台 materializer 的职责，还是由显式 lease/binder API 管理。不同能力现在各自调用 ensure，统一迁移会影响 ACK 文案、readmodel freshness、启动服务和测试契约。
design_question: "哪些 projection 必须在 actor 创建前预绑定，哪些可以完全交给后台 materializer？请给出统一生命周期规则。"
original_authors:
- "@eanzhao"
- "@loning"
- "@auric"

📢 cc 原作者

• @eanzhao
• @loning
• @auric

决策需要(进 Phase 9 design 共识)

本 issue 由 iter18 audit 标 requires_design=true 自动开。Auto-loop 已加 phase9-auto-solve label,3 solver(minimal/structural/delete)+ meta-judge 自动启动,等 3/3 unanimous 即派 implement。

Maintainer 可任意评论参与;每条评论触发 fresh solver round。

🤖 Auto-loop iter18 / codex-refactor-loop

[loning]

🤖 delete solver 结论：不建议删除投影激活路径

TL;DR

• 这是什么：issue 732 的 delete solver 反向追踪了 command path 里的 projection activation。
• 结论：abstain；这条路径不是死代码，纯删除会让新 actor 的首批 committed event 可能进不了 readmodel。
• 下一步：让 minimal/structural solver 设计替代 owner，把激活移出 command 请求栈。

📢 cc 原作者:@eanzhao @loning Auric 请 sanity-check 当前判断：这不是删除点，而是迁移 owner 的结构问题。

---

详细说明

我检查了 issue、iter18 audit、CLAUDE 的“删除优先”、调用点和 git blame。 是当前创建/唤醒 projection scope actor 的入口；projection scope actor 是负责把 committed event 观察并物化成 readmodel 的 actor。 只有在激活后才会 attach observation relay，所以把 command path 里的调用直接删掉，不会自动出现等价的观察链路。

活跃调用点不止 workflow：、、、、、 都在新建或修改 actor 前后启动对应 readmodel projection。对应查询侧也是真实消费：workflow binding/execution 查询、service lifecycle/serving/invocation resolution、governance admission、LLM session lookup、service-run lookup、responses tool-state 查询都读这些 materialized readmodel。

判断	证据	影响
不是死代码	多个 application/infrastructure 调用点 + 测试覆盖	删除会改行为
不是孤儿功能	Host/DI 注册 query readers 和 projection ports	查询路径正在用
不是可直接合并到现有简单抽象	未找到启动时或后台自动为每个 actor/kind 建 scope 的机制	需要 minimal/structural 迁移 owner

---

📎 完整 codex 原始输出(存档备查)

    ---
    solver: delete
    issue: 732
    cluster: cluster-006-command-path-projection-lifecycle
    verdict: abstain
    ---
    
    ## Classification
    e) Genuinely needed and right-sized for current runtime mechanics.
    
    The feature is not architecturally right in the final shape, but it is not safely deletable in a delete-only pass. The current projection scope actor only attaches observation after `EnsureProjectionAsync` dispatches `EnsureProjectionScopeCommand`; deleting command-path activation without adding another activation owner would make first-event readmodel materialization unreliable.
    
    ## Recommended action (English)
    Do not delete this path in the delete solver. Keep the projection activation capability and let the minimal/structural solver move activation out of command request handling into an explicit actor-owned setup/background materialization path. A safe implementation must preserve the current behavior that workflow binding, workflow execution materialization, service catalog/revision/deployment/serving/rollout/traffic, governance configuration, service-run, LLM-session, and responses-tool-state readmodels have an active projection scope before committed events are expected to appear in query results.
    
    ## Recommended action (中文)
    delete solver 不建议删除这条路径。当前投影激活能力必须保留，由 minimal/structural solver 把激活动作从 command 请求栈迁到显式的 actor-owned setup 或后台物化路径。安全实现必须保留现有语义：workflow binding、workflow execution materialization、service catalog/revision/deployment/serving/rollout/traffic、governance configuration、service-run、LLM-session、responses-tool-state 等 readmodel 在 committed event 进入查询结果前，需要已经有活跃的 projection scope。
    
    ## Concrete plan (if propose)
    - Files to delete: none.
    - Caller migrations: none proposed by delete solver.
    - Tests to delete: none.
    - LOC delta: -0.
    - Tracking issue (if defer): not applicable; deferral is not a valid verdict for this run.
    
    ## Reverse-evidence (why this is safe to delete)
    - Not safe to delete: `src/Aevatar.CQRS.Projection.Core/Orchestration/ProjectionScopeActivationService.cs` creates/ensures the projection scope actor and sends `EnsureProjectionScopeCommand`.
    - Not safe to delete: `src/Aevatar.CQRS.Projection.Core/Orchestration/ProjectionScopeGAgentBase.cs` only attaches the observation relay after activation; if inactive, observed envelopes are ignored.
    - Active command-path callers exist in `src/workflow/Aevatar.Workflow.Infrastructure/Runs/WorkflowRunActorPort.cs`, `src/platform/Aevatar.GAgentService.Application/Services/ServiceCommandApplicationService.cs`, `src/platform/Aevatar.GAgentService.Governance.Application/Services/ServiceGovernanceCommandApplicationService.cs`, `src/platform/Aevatar.GAgentService.Infrastructure/Adapters/LlmSessionRegistrationAdapter.cs`, `src/platform/Aevatar.GAgentService.Infrastructure/Adapters/ServiceRunRegistrationAdapter.cs`, and `src/platform/Aevatar.GAgentService.Infrastructure/Adapters/ResponsesAgentToolStateCommandAdapter.cs`.
    - Active query consumers exist: workflow query/binding readers, service lifecycle/serving/invocation resolution readers, governance admission readers, LLM session current-state lookup, service-run lookup, and responses tool-state query paths read materialized readmodels.
    - Tests are not merely dead coverage. Existing tests assert projection activation/registration behavior in `test/Aevatar.Workflow.Host.Api.Tests/WorkflowRunActorPortBranchTests.cs`, `test/Aevatar.GAgentService.Tests/Application/ServiceCommandApplicationServiceTests.cs`, `test/Aevatar.GAgentService.Tests/Infrastructure/LlmSessionRegistrationAdapterTests.cs`, and projection infrastructure tests.
    - No external repo dependency is involved: grep over the violating files found no `NyxID`, `chrono-storage`, or `chrono-ornn` references.
    - The public projection port surface is active and registered through DI; deleting it would touch application abstractions such as `IWorkflowBindingProjectionActivationPort`, `IWorkflowExecutionMaterializationActivationPort`, `IServiceCatalogProjectionPort`, `IServiceConfigurationProjectionPort`, and current-state projection ports.
    
    ## Risks
    - If there is an unobserved runtime feature that automatically creates projection scopes for every actor/kind before first commit, this abstain may be too conservative. I did not find such a mechanism in the DI registrations or startup hosted services.
    - If all affected query surfaces tolerate missing first events and rely on manual repair/replay, deletion could be technically possible, but that would contradict the repository rules against normal-path replay and projection priming.
    - The command-path activation still violates the issue's architecture rule; abstain means deletion is the wrong tool, not that the current code should stay unchanged forever.
    
    ## Escalation triggers (if any)
    - None. This is a normal abstain: the feature is live and needs a structural/minimal replacement, not a delete plan.
    
    ## Reasoning trace (internal — for meta-judge)
    - Why I claim this cannot be deleted:
      - The active projection scope is the current mechanism that subscribes readmodel materializers to committed actor events.
      - The observed command-path calls are not dead wrappers; they activate projections for user/system-visible query paths.
      - Removing them without a replacement would likely lose early committed events for newly created actors.
    - What I checked to verify safety:
      - `gh issue view 732 --comments --json ...`
      - `.refactor-loop/runs/audit-iter-18.md`
      - `CLAUDE.md` deletion-first clause.
      - `rg` callers for `EnsureProjectionAsync`, `ActivateAsync`, projection ports, and issue evidence symbols.
      - `git log --oneline` and `git log -p --follow -S` for the flagged workflow/service files.
      - DI registrations and startup hosted services for workflow, service, and governance projections.
      - External dependency grep for NyxID/chrono keywords in the violating files.
    - What I cannot decide alone:
      - Whether the replacement should be a background materializer, an explicit resource activation API, or actor-owned binding created as part of actor lifecycle. That is implementation design for minimal/structural solvers.
    
    SOLVER_DONE:delete:abstain:projection activation is live; pure deletion would break readmodel observation before first committed events

[loning]

🤖 delete solver 结论：不建议删除投影激活路径

TL;DR

• 这是什么：issue 732 的 delete solver 反向追踪了 command path 里的 projection activation。
• 结论：abstain；这条路径不是死代码，纯删除会让新 actor 的首批 committed event 可能进不了 readmodel。
• 下一步：让 minimal/structural solver 设计替代 owner，把激活移出 command 请求栈。

📢 cc 原作者:@eanzhao @loning Auric 请 sanity-check 当前判断：这不是删除点，而是迁移 owner 的结构问题。

---

详细说明

我检查了 issue、iter18 audit、CLAUDE 的“删除优先”、调用点和 git blame。EnsureProjectionAsync 是当前创建/唤醒 projection scope actor 的入口；projection scope actor 是负责把 committed event 观察并物化成 readmodel 的 actor。ProjectionScopeGAgentBase 只有在激活后才会 attach observation relay，所以把 command path 里的调用直接删掉，不会自动出现等价的观察链路。

活跃调用点不止 workflow：WorkflowRunActorPort、ServiceCommandApplicationService、ServiceGovernanceCommandApplicationService、LlmSessionRegistrationAdapter、ServiceRunRegistrationAdapter、ResponsesAgentToolStateCommandAdapter 都在新建或修改 actor 前后启动对应 readmodel projection。对应查询侧也是真实消费：workflow binding/execution 查询、service lifecycle/serving/invocation resolution、governance admission、LLM session lookup、service-run lookup、responses tool-state 查询都读这些 materialized readmodel。

判断	证据	影响
不是死代码	多个 application/infrastructure 调用点 + 测试覆盖	删除会改行为
不是孤儿功能	Host/DI 注册 query readers 和 projection ports	查询路径正在用
不是可直接合并到现有简单抽象	未找到启动时或后台自动为每个 actor/kind 建 scope 的机制	需要 minimal/structural 迁移 owner

---

📎 完整 codex 原始输出(存档备查)

---
solver: delete
issue: 732
cluster: cluster-006-command-path-projection-lifecycle
verdict: abstain
---

## Classification
e) Genuinely needed and right-sized for current runtime mechanics.

The feature is not architecturally right in the final shape, but it is not safely deletable in a delete-only pass. The current projection scope actor only attaches observation after `EnsureProjectionAsync` dispatches `EnsureProjectionScopeCommand`; deleting command-path activation without adding another activation owner would make first-event readmodel materialization unreliable.

## Recommended action (English)
Do not delete this path in the delete solver. Keep the projection activation capability and let the minimal/structural solver move activation out of command request handling into an explicit actor-owned setup/background materialization path. A safe implementation must preserve the current behavior that workflow binding, workflow execution materialization, service catalog/revision/deployment/serving/rollout/traffic, governance configuration, service-run, LLM-session, and responses-tool-state readmodels have an active projection scope before committed events are expected to appear in query results.

## Recommended action (中文)
delete solver 不建议删除这条路径。当前投影激活能力必须保留，由 minimal/structural solver 把激活动作从 command 请求栈迁到显式的 actor-owned setup 或后台物化路径。安全实现必须保留现有语义：workflow binding、workflow execution materialization、service catalog/revision/deployment/serving/rollout/traffic、governance configuration、service-run、LLM-session、responses-tool-state 等 readmodel 在 committed event 进入查询结果前，需要已经有活跃的 projection scope。

## Concrete plan (if propose)
- Files to delete: none.
- Caller migrations: none proposed by delete solver.
- Tests to delete: none.
- LOC delta: -0.
- Tracking issue (if defer): not applicable; deferral is not a valid verdict for this run.

## Reverse-evidence (why this is safe to delete)
- Not safe to delete: `src/Aevatar.CQRS.Projection.Core/Orchestration/ProjectionScopeActivationService.cs` creates/ensures the projection scope actor and sends `EnsureProjectionScopeCommand`.
- Not safe to delete: `src/Aevatar.CQRS.Projection.Core/Orchestration/ProjectionScopeGAgentBase.cs` only attaches the observation relay after activation; if inactive, observed envelopes are ignored.
- Active command-path callers exist in `src/workflow/Aevatar.Workflow.Infrastructure/Runs/WorkflowRunActorPort.cs`, `src/platform/Aevatar.GAgentService.Application/Services/ServiceCommandApplicationService.cs`, `src/platform/Aevatar.GAgentService.Governance.Application/Services/ServiceGovernanceCommandApplicationService.cs`, `src/platform/Aevatar.GAgentService.Infrastructure/Adapters/LlmSessionRegistrationAdapter.cs`, `src/platform/Aevatar.GAgentService.Infrastructure/Adapters/ServiceRunRegistrationAdapter.cs`, and `src/platform/Aevatar.GAgentService.Infrastructure/Adapters/ResponsesAgentToolStateCommandAdapter.cs`.
- Active query consumers exist: workflow query/binding readers, service lifecycle/serving/invocation resolution readers, governance admission readers, LLM session current-state lookup, service-run lookup, and responses tool-state query paths read materialized readmodels.
- Tests are not merely dead coverage. Existing tests assert projection activation/registration behavior in `test/Aevatar.Workflow.Host.Api.Tests/WorkflowRunActorPortBranchTests.cs`, `test/Aevatar.GAgentService.Tests/Application/ServiceCommandApplicationServiceTests.cs`, `test/Aevatar.GAgentService.Tests/Infrastructure/LlmSessionRegistrationAdapterTests.cs`, and projection infrastructure tests.
- No external repo dependency is involved: grep over the violating files found no `NyxID`, `chrono-storage`, or `chrono-ornn` references.
- The public projection port surface is active and registered through DI; deleting it would touch application abstractions such as `IWorkflowBindingProjectionActivationPort`, `IWorkflowExecutionMaterializationActivationPort`, `IServiceCatalogProjectionPort`, `IServiceConfigurationProjectionPort`, and current-state projection ports.

## Risks
- If there is an unobserved runtime feature that automatically creates projection scopes for every actor/kind before first commit, this abstain may be too conservative. I did not find such a mechanism in the DI registrations or startup hosted services.
- If all affected query surfaces tolerate missing first events and rely on manual repair/replay, deletion could be technically possible, but that would contradict the repository rules against normal-path replay and projection priming.
- The command-path activation still violates the issue's architecture rule; abstain means deletion is the wrong tool, not that the current code should stay unchanged forever.

## Escalation triggers (if any)
- None. This is a normal abstain: the feature is live and needs a structural/minimal replacement, not a delete plan.

## Reasoning trace (internal — for meta-judge)
- Why I claim this cannot be deleted:
  - The active projection scope is the current mechanism that subscribes readmodel materializers to committed actor events.
  - The observed command-path calls are not dead wrappers; they activate projections for user/system-visible query paths.
  - Removing them without a replacement would likely lose early committed events for newly created actors.
- What I checked to verify safety:
  - `gh issue view 732 --comments --json ...`
  - `.refactor-loop/runs/audit-iter-18.md`
  - `CLAUDE.md` deletion-first clause.
  - `rg` callers for `EnsureProjectionAsync`, `ActivateAsync`, projection ports, and issue evidence symbols.
  - `git log --oneline` and `git log -p --follow -S` for the flagged workflow/service files.
  - DI registrations and startup hosted services for workflow, service, and governance projections.
  - External dependency grep for NyxID/chrono keywords in the violating files.
- What I cannot decide alone:
  - Whether the replacement should be a background materializer, an explicit resource activation API, or actor-owned binding created as part of actor lifecycle. That is implementation design for minimal/structural solvers.

SOLVER_DONE:delete:abstain:projection activation is live; pure deletion would break readmodel observation before first committed events

[loning]

🤖 structural solver 建议升级为架构决策

TL;DR

• 这是什么: issue 732 的 structural solver 方案，按 CLAUDE 口径评估 command path 里同步启动 projection 的问题。
• 结论: 我给 escalate，因为干净方案需要新增 Actor 化的 projection activation coordinator 或等价 lifecycle phase。
• 下一步: maintainer/meta-judge 需要决定是否接受新增 coordinator；不建议用注释例外或把 EnsureProjectionAsync 搬到另一个 write-path helper。

📢 cc 原作者:@eanzhao @loning 请 sanity-check coordinator 是否符合你们对 projection lifecycle 的目标态。

---

详细说明

当前证据不是单点误用：WorkflowRunActorPort 在 dispatch 前启动 binding/execution materialization，service command port 在每个 command 前确保 read projection，LlmSessionRegistrationAdapter 在注册命令前确保 current-state projection。这让 accepted ACK 容易被理解成 readmodel 已准备好，违背“写路径只 dispatch command/event，readmodel 可见性异步观察”的口径。

我建议的结构是新增 ProjectionActivationCoordinatorGAgent：这是一个 Actor 化 coordinator，负责记录 durable materialization activation intent，并通过现有 ProjectionScopeGAgent / IActorDispatchPort 启动 projection scope。IActorDispatchPort 是 actor 之间投递 envelope 的标准通道；这样 command service 只保留 target resolve + dispatch，projection lifecycle 从 write request stack 中移出。

方案	代价	判断
新增 coordinator	约 +620 / -95 LOC，+2 envelope per first activation	结构最干净，但需 human nod
每个 domain 自己做后台 activator	约 +260 / -95 LOC	改动小，但 lifecycle 规则重复
注释例外或搬到 provisioner	最少	不解决 ACK 语义，仍在 write path

Escalation: ESCALATE_REASON:new-core-actor-type、ESCALATE_REASON:new-proto-contract、ESCALATE_REASON:new-pipeline-phase、ESCALATE_REASON:ack-contract-change。

---

📎 完整 codex 原始输出(存档备查)

---

solver: structural
issue: 732
cluster: cluster-006-command-path-projection-lifecycle
verdict: escalate

CLAUDE clause violated (quoted verbatim)

• 投影编排 Actor 化：Projection 运行态（会话、订阅、关联）必须由 Actor 或分布式状态承载；禁止中间层进程内注册表/字典持有事实状态。
• 读写分离：Command -> Event，Query -> ReadModel；异步完成通过事件通知，不在会话内拼装流程。
• committed domain event 必须可观察：write-side 完成 committed event 后必须送入 projection 主链；禁止只落 event store 而不进入可观察流。
• 命令骨架内聚：标准生命周期 Normalize -> Resolve Target -> Build Context -> Build Envelope -> Dispatch -> Receipt -> Observe；业务模块只负责目标解析与载荷/结果映射。
• ACK 诚实：同步返回只承诺已达到阶段（默认 accepted + stable command id）；committed/read-model observed 等强保证须通过独立契约或异步观察获取。
• 禁止 query-time replay/priming：QueryPort/QueryService/ApplicationService 不得在请求路径读 IEventStore、重放 events、临时重建 state mirror；不得在 query 方法内同步补投影或补跑 ES/materialization。刷新须通过正式 projection 会话、后台 materializer 或写侧预挂接 projection 完成。
• 不得 query-time priming：查询前若需要先“确保投影存在/刷新 read model”，该动作必须在显式 activation、lease、binder 或后台物化流程中完成；禁止在 query 方法内同步补投影。

Recommended framing (English)

The violation is that command/application adapters make projection materialization a synchronous write-path precondition: WorkflowRunActorPort activates binding/execution materialization before dispatch, service command ports ensure read projections before every command, and session registration ensures current-state projection before the registration command. The structurally clean fix is to remove projection ports from command services and move durable readmodel activation into an actor-owned projection activation coordinator: command paths dispatch business envelopes only; a projection activation coordinator records required materialization scopes and uses existing ProjectionScopeGAgent/IActorDispatchPort to activate scope actors asynchronously. This eliminates the violation by construction because command ACKs can no longer wait on readmodel setup, while projection lifecycle facts remain actor-owned instead of process-local or scattered through application services.

Recommended framing (中文)

当前问题不是某一行 EnsureProjectionAsync 写错了，而是 command/application adapter 把读模型物化启动变成了写请求的同步前置条件：WorkflowRunActorPort 在 dispatch 前启动 binding/execution materialization，service command port 在每个 command 前启动 read projection，session registration 在注册命令前启动 current-state projection。结构化修复应把 projection port 从 command service 中移除，把 durable readmodel activation 收口到一个 Actor 化的 projection activation coordinator：写路径只投递业务 envelope；projection activation coordinator 记录需要启动的 materialization scope，并通过现有 ProjectionScopeGAgent / IActorDispatchPort 异步启动 scope actor。这样 ACK 无法再暗示 readmodel 已准备好，projection lifecycle 事实也由 Actor 持有，而不是散落在 application service 或进程内状态里。

Concrete plan

• New abstractions (if any): IProjectionActivationRequestPort (Aevatar.CQRS.Projection.Core.Abstractions, Abstractions/Ports/IProjectionActivationRequestPort.cs) accepts typed activation intents and returns accepted-only coordinator dispatch receipt; ProjectionActivationCoordinatorGAgent (Aevatar.CQRS.Projection.Core, Orchestration/ProjectionActivationCoordinatorGAgent.cs) owns activation intent state and dispatches existing EnsureProjectionScopeCommand to scope actors; IProjectionActivationBindingProvider (Aevatar.CQRS.Projection.Core.Abstractions) maps actor kind/event type to projection kind/mode.
• Existing primitives used: IActorDispatchPort for the extra inbox hop, existing EventEnvelope, existing ProjectionScopeGAgent and ProjectionScopeStartRequest, existing durable materialization mode, existing IAsyncEnumerable/projection pipeline only for observation after dispatch; do not use Channel as the authoritative lifecycle source.
• Files: modify src/workflow/Aevatar.Workflow.Infrastructure/Runs/WorkflowRunActorPort.cs to remove binding/materialization activation dependencies and calls; modify src/platform/Aevatar.GAgentService.Application/Services/ServiceCommandApplicationService.cs to remove all projection port dependencies and EnsureProjectionAsync calls; modify src/platform/Aevatar.GAgentService.Governance.Application/Services/ServiceGovernanceCommandApplicationService.cs similarly; modify src/platform/Aevatar.GAgentService.Infrastructure/Adapters/LlmSessionRegistrationAdapter.cs to remove projection ensure from registration; likely extend same pattern to sibling evidence-adjacent adapters ServiceRunRegistrationAdapter.cs and ResponsesAgentToolStateCommandAdapter.cs if included in implementation scope.
• New files: src/Aevatar.CQRS.Projection.Core/projection_activation_messages.proto; src/Aevatar.CQRS.Projection.Core.Abstractions/Abstractions/Ports/IProjectionActivationRequestPort.cs; src/Aevatar.CQRS.Projection.Core.Abstractions/Abstractions/Ports/IProjectionActivationBindingProvider.cs; src/Aevatar.CQRS.Projection.Core/Orchestration/ProjectionActivationCoordinatorGAgent.cs; src/Aevatar.CQRS.Projection.Core/Orchestration/ProjectionActivationRequestPort.cs; src/Aevatar.CQRS.Projection.Core/DependencyInjection/ProjectionActivationRegistration.cs; per-domain binding providers in Aevatar.Workflow.Projection and Aevatar.GAgentService.Projection.
• LOC delta: ~+620 / -95 if coordinator is introduced; ~+260 / -95 for a narrower per-domain background activator, but that narrower option leaves more duplicated lifecycle rules.
• Tests to add: 1 behavior test in test/Aevatar.GAgentService.Tests/Application/ServiceCommandApplicationServiceTests.cs asserting service commands dispatch without invoking projection ports; 1 behavior test in test/Aevatar.GAgentService.Tests/Application/GovernanceApplicationServicesTests.cs asserting governance commands dispatch without projection priming; 1 behavior test in test/Aevatar.GAgentService.Tests/Infrastructure/LlmSessionRegistrationAdapterTests.cs asserting registration creates actor and dispatches register command without synchronous projection ensure; 1 behavior test in test/Aevatar.Workflow.Host.Api.Tests/WorkflowRunActorPortBranchTests.cs asserting run creation dispatches binding command without materialization activation; 2 coordinator tests in a new test/Aevatar.CQRS.Projection.Core.Tests/ProjectionActivationCoordinatorTests.cs asserting duplicate activation intents are idempotent and projection scope ensure dispatch uses exact RootActorId + ProjectionKind + Mode.
• proto changes (if any): new projection_activation_messages.proto: ProjectionActivationCoordinatorState.bindings = 1; ProjectionActivationRequestedCommand.root_actor_id = 1, projection_kind = 2, mode = 3, source_actor_id = 4, source_event_type_url = 5, requested_at = 6; ProjectionActivationRecordedEvent with same semantic fields plus binding_id = 7. No new EventEnvelope kind.
• Runtime cost: write ACK removes current synchronous materialization calls, saving ~1-3 projection activation awaits per command path. Coordinator path adds ~1 accepted actor inbox dispatch plus ~1 scope ensure dispatch per new actor/projection binding; estimated +2 envelopes and +3-6 KB short-lived allocations per activation. Local latency for readmodel first visibility increases by ~1-5 ms; distributed Orleans latency increases by ~10-50 ms per first activation, but command ACK latency should drop by the same number of removed projection awaits.

Risks

• This trades lower command-path latency and cleaner ACK semantics for eventual readmodel availability that is one coordinator hop later; API responses and tests must stop asserting projection readiness from command ACK.
• The coordinator can become over-engineered if it tries to become a generic projection bus. Keep it bounded to durable materialization activation intents only; session/live observation leases stay in interaction binders where the caller is explicitly observing a command.
• If implementation only moves EnsureProjectionAsync into target provisioners, the violation remains because activation is still inside the command request stack.
• If implementation uses Channel or fire-and-forget Task.Run to decouple activation, the lifecycle is not actor-owned and will fail the same architecture review.

Escalation triggers (if any)

• ESCALATE_REASON:new-core-actor-type:ProjectionActivationCoordinatorGAgent is a new projection lifecycle actor.
• ESCALATE_REASON:new-proto-contract:projection activation intent/state messages must be added before implementation.
• ESCALATE_REASON:new-pipeline-phase:activation-on-actor-fact/background-materializer semantics must be approved so first readmodel visibility is explicitly eventual.
• ESCALATE_REASON:ack-contract-change:existing tests and possibly clients must stop interpreting command return as projection readiness.

Reasoning trace (internal — for meta-judge)

• Why this structure beats a documented exception: a comment saying "projection ensure is allowed here" would keep ACK semantics false and spread readmodel lifecycle through command services; the coordinator removes the dependency edge entirely.
• Why I picked this abstraction over alternatives: IProjectionScopeActivationService<TLease> already actorizes individual scope state, but it is currently called synchronously by write adapters; a coordinator gives one actor-owned activation interface for workflow, service catalog, governance, and session current-state projections. Channel is insufficient because it is not an authoritative lifecycle source.
• What I cannot decide alone: whether the repo wants a new projection activation coordinator actor, or whether maintainers prefer a smaller per-domain explicit setup API with weaker automation.

SOLVER_DONE:structural:escalate:new-projection-activation-coordinator-required

[loning]

🤖 meta-judge 结论：升级给 maintainer 做架构取舍

TL;DR

• 这是什么: issue 732 的 Phase 9 r1 meta-judge 仲裁结果。
• 结论: escalate；已触发硬性 architecture-philosophy 条件，不进入 convergence。
• 下一步: maintainer 需要明确选 accept-minimal-exception、accept-structural-coordinator，或给出第三个具体 lifecycle 规则。

📢 cc 原作者:@eanzhao @loning Auric 请 sanity-check projection lifecycle owner 的边界选择。

---

详细说明

3 个 solver 没有达到 3/3 unanimous。minimal solver 的方向是给顶层 CLAUDE.md / AGENTS.md 增加窄例外，允许 command path 在 dispatch 前做 actor-owned durable projection bootstrap，但不承诺 readmodel freshness；structural solver 的方向是新增 ProjectionActivationCoordinatorGAgent，也就是一个 Actor 化的 projection activation coordinator，负责把 durable readmodel activation 从 command request stack 中移出去；delete solver abstain，确认这条路径是活跃机制，不能纯删除。

这里不是普通“哪几个文件怎么改”的分歧，而是顶层规则例外 vs 新 Actor / 新 lifecycle phase 的架构取舍。按 prompt 的硬规则，新增 actor type、新 pipeline phase、顶层 CLAUDE/AGENTS 规则例外都必须升级给 human，不能由 meta-judge 发明混合方案或自动 dispatch implement。

方向	代价	meta-judge 判断
minimal exception	文档/guard 小改，生产代码 0 LOC	触发顶层规则例外，需要 maintainer 点头
structural coordinator	约 +620 / -95 LOC，新 proto + coordinator actor	触发新 actor type / lifecycle phase，需要 maintainer 点头
delete	-0 LOC	solver 已 abstain；会破坏首批 committed event 的 readmodel observation

建议 maintainer 在本 issue 评论一个明确选择：accept-minimal-exception、accept-structural-coordinator，或写出第三个可执行的 lifecycle 边界。评论后 controller 应按“每条 maintainer 回复重置 round”的规则重新跑 3 solver。

---

📎 完整 codex 原始输出(存档备查)

    ---
    issue: 732
    cluster: cluster-006-command-path-projection-lifecycle
    convergence_round: 1
    solver_verdicts:
      minimal: escalate
      structural: escalate
      delete: abstain
    decision: escalate
    ---
    
    ## Decision (English)
    Escalate to human. The hard architecture-philosophy triggers fire before consensus is computed: the minimal solver asks to change top-level CLAUDE/AGENTS projection and command-path rules by adding a narrow exception, and the structural solver proposes a new `ProjectionActivationCoordinatorGAgent`, new proto activation contracts, and a new projection activation lifecycle phase. The delete solver abstains and confirms the path is live, so this is not a deletion or false-positive case. Because the split is over repository architecture policy and projection lifecycle ownership, another convergence round would only ask solvers to choose a philosophy that the hardcoded rules reserve for maintainers.
    
    ## Decision (中文)
    升级给 human 决策。这里在计算共识前已经触发硬性 architecture-philosophy escalation：minimal solver 要在顶层 CLAUDE/AGENTS 投影与 command-path 规则里新增窄例外；structural solver 要新增 `ProjectionActivationCoordinatorGAgent`、新的 proto activation contract，以及新的 projection activation lifecycle phase。delete solver abstain，并确认当前路径是活跃机制，不是可删除代码或 false-positive。因此分歧点不是普通技术收敛问题，而是 repo 架构规则与 projection lifecycle owner 的取舍，继续 convergence 会让 solver 代替 maintainer 做哲学决策。
    
    ## If consensus
    - Chosen framing: N/A
    - Implement plan: N/A
    - Implementation owner: N/A
    - Add `auto-loop-resume` label to issue 732: N/A
    
    ## If converge
    - Convergence question (specific): N/A
    - What each solver should address explicitly: N/A
    - Round number this fires: N/A
    
    ## If escalate
    - Trigger category: philosophy
    - What needs human input (specific question): Maintainer needs to choose the allowed lifecycle boundary for command-path projection activation: either authorize a top-level narrow rule exception that permits pre-dispatch actor-owned durable projection bootstrap without freshness guarantees, or authorize a structural actor-owned activation coordinator/new lifecycle phase that moves all durable readmodel activation out of command request handling. If neither direction is acceptable, maintainer should state the desired third boundary explicitly because none of the three solver outputs can be auto-implemented under the current rules.
    - Suggested next step for human: Add/keep `design-philosophy` or `auto-loop-stuck` on issue 732, then comment with one explicit choice: `accept-minimal-exception`, `accept-structural-coordinator`, or a concrete alternative lifecycle rule. After that maintainer comment, per policy, the controller should reset and run a fresh 3-solver round.
    
    ## Round audit trail (links to local artifacts)
    - solver-minimal: /Users/auric/aevatar/.refactor-loop/runs/phase9-issue732-r1-minimal.md
    - solver-structural: /Users/auric/aevatar/.refactor-loop/runs/phase9-issue732-r1-structural.md
    - solver-delete: /Users/auric/aevatar/.refactor-loop/runs/phase9-issue732-r1-delete.md
    
    META_JUDGE_DONE:escalate:philosophy:new actor/lifecycle phase versus top-level rule exception requires maintainer decision

[loning]

📊 当前状态 — Phase 9 r1 meta-judge escalate philosophy

维度	值
阶段	🆘 需要人介入
Meta-judge	META_JUDGE_DONE:escalate:philosophy:new actor/lifecycle phase versus top-level rule exception requires maintainer decision
触发	architecture-philosophy(新 actor 类型 / lifecycle phase 触发)
是否需要人介入	✅ 需要 maintainer 决策:command path projection lifecycle 新增 actor / 加 lifecycle phase;详见 r1 三 solver + judge

🤖 controller status banner