Define backend async operation contract for CQRS writes

[louis4li]

---

id: cluster-triage-backend-async-cqrs-write-contract
severity: high
requires_design: true

来源

本 issue 由 maintainer 手动开，triage codex 深度调研补 evidence。

核心问题

Backend write APIs 已局部遵守 202 Accepted，但 accepted / committed / observed / ready / failed 没有一套跨 Workflow、Scripting、GAgentService、Studio 的统一 contract。结果是 CQRS Core 的 accepted-only skeleton、capability-specific readiness query、Studio observation endpoint、service run status URL 各自存在，solver 很容易在新 write path 里重新把 readmodel 可见性、invoke readiness 或 post-acceptance failure 拼回同步 API。

该问题不是“缺少字段”本身，而是 backend operation 阶段语义没有统一 ownership: 同步 ACK 只能证明 dispatch admission；readmodel freshness / readiness / terminal failure 必须通过明确 observe/readiness/readmodel surface 暴露。

Evidence

1. IActorDispatchPort 只承诺 accepted，但上层 operation contract 还没统一

src/Aevatar.Foundation.Abstractions/IActorDispatchPort.cs:67

// Refactor (iter149/issue1132): Old pattern: handled-dispatch side contract implied actor-turn completion.  New principle: IActorDispatchPort exposes accepted-only runtime/inbox admission.
public interface IActorDispatchPort
{
    /// <summary>
    /// Admits an envelope to the specified actor runtime/inbox boundary.
    /// Completion only means accepted-for-dispatch with a stable command id; it does not mean handled,
    /// committed, or observed by a read model.
    /// </summary>
    Task<DispatchAdmission> DispatchAsync(string actorId, EventEnvelope envelope, CancellationToken ct = default);
}

违反点: 基础层已经把 ACK 语义收紧到 accepted-only，但 capability HTTP/API response shape 没有统一表达后续 observeUrl / readinessUrl / readModelUrl / terminal failure，导致每个能力入口继续自行解释 stronger stage。

2. CQRS Core 已删除 stream-RPC outcome contract，但缺少跨能力 operation response 标准

src/Aevatar.CQRS.Core.Abstractions/Commands/ICommandDispatchService.cs:3

// Refactor (iter158/cluster-001-stream-actor-outcome-rpc):
// Old: outcome dispatch used stream subscribe + TCS to treat the first outcome as an RPC reply, violating stream request-reply boundaries and honest ACK semantics.
// New: Delete the outcome-dispatch contract with no replacement; callers use accepted receipts plus readmodel queries or typed continuation events.
public interface ICommandDispatchService<in TCommand, TReceipt, TError>
{
    Task<CommandDispatchResult<TReceipt, TError>> DispatchAsync(
        TCommand command,
        CancellationToken ct = default);
}

违反点: accepted receipts plus readmodel queries or typed continuation events 是方向，但各 backend write API 没有统一最小 response shape，post-acceptance failure 也没有统一 observation contract。

3. Binding command path 是 transition point: 旧 readmodel polling 已被删除，但 readiness 还没有进入共享 contract

src/platform/Aevatar.GAgentService.Application/Bindings/ScopeBindingCommandApplicationService.cs:56

// Refactor (iter2/cluster-006):
//   Old pattern: Upsert dispatched lifecycle commands then polled service catalog and serving readmodels before ACK.
//   New principle: Upsert returns accepted lifecycle ids; readmodel freshness is observed through explicit read paths.
public async Task<ScopeBindingUpsertResult> UpsertAsync(
    ScopeBindingUpsertRequest request,
    CancellationToken ct = default)

src/platform/Aevatar.GAgentService.Application/Bindings/ScopeBindingCommandApplicationService.cs:126

var expectedDeploymentId = $"{ServiceActorIds.Deployment(identity)}:{revisionId}";
// TODO(iter2/cluster-006): If callers need "invoke safe now", add an explicit read/projection
// observation path in a separate PR rather than blocking this command path on readmodels.
return desiredBinding.BuildResult(normalizedScopeId, identity.ServiceId, revisionId, expectedDeploymentId);

违反点: 代码已经知道 invoke safe now 不能阻塞 command path，但当前 issue 要把这个 TODO 升级为统一 backend operation contract，否则下一条 write API 仍会重新发明 polling/readiness 形状。

4. Readiness 已是显式 query surface，但状态 vocabulary 太 capability-specific

src/platform/Aevatar.GAgentService.Application/Bindings/ScopeBindingReadinessQueryService.cs:26

public async Task<ScopeBindingReadinessSnapshot> GetReadinessAsync(
    ScopeBindingReadinessRequest request,
    CancellationToken ct = default)

src/platform/Aevatar.GAgentService.Application/Bindings/ScopeBindingReadinessQueryService.cs:44

var service = await _serviceLifecycleQueryPort.GetServiceAsync(identity, ct).ConfigureAwait(false);
if (service == null)
{
    return new ScopeBindingReadinessSnapshot(
        normalizedScopeId,
        normalizedServiceId,
        ScopeBindingReadinessStatus.ServiceCatalogMissing,
        ServiceCatalogVisible: false,
        ServingSetVisible: false,
        EligibleServingTargetVisible: false,
        InvokeReady: false,
        ObservedAtUtc: observedAtUtc);
}

违反点: readiness query 是正确边界，但缺少 shared operation-level status vocabulary，例如 pending / ready / failed / timed_out 与 command/correlation id 关联，frontend 或 caller 只能理解 capability-specific missing states。

5. Workflow upsert dispatches lifecycle commands then reads readmodel/fallbacks inside write path

src/platform/Aevatar.GAgentService.Application/Workflows/ScopeWorkflowCommandApplicationService.cs:108

await _serviceCommandPort.CreateRevisionAsync(new CreateServiceRevisionCommand { Spec = revisionSpec }, ct);
await _serviceCommandPort.PrepareRevisionAsync(new PrepareServiceRevisionCommand
{
    Identity = identity.Clone(),
    RevisionId = revisionId,
}, ct);
await _serviceCommandPort.PublishRevisionAsync(new PublishServiceRevisionCommand
{
    Identity = identity.Clone(),
    RevisionId = revisionId,
}, ct);
await _serviceCommandPort.SetDefaultServingRevisionAsync(new SetDefaultServingRevisionCommand
{
    Identity = identity.Clone(),
    RevisionId = revisionId,
}, ct);
await _serviceCommandPort.ActivateServiceRevisionAsync(new ActivateServiceRevisionCommand
{
    Identity = identity.Clone(),
    RevisionId = revisionId,
}, ct);

src/platform/Aevatar.GAgentService.Application/Workflows/ScopeWorkflowCommandApplicationService.cs:132

var workflowSummary =
    await _scopeWorkflowQueryPort.GetByWorkflowIdAsync(normalizedScopeId, normalizedWorkflowId, ct) ??
    new ScopeWorkflowSummary(
        normalizedScopeId,
        normalizedWorkflowId,
        desiredDisplayName,
        ServiceKeys.Build(identity),
        ScopeWorkflowCapabilityConventions.NormalizeOptional(request.WorkflowName),
        expectedActorId,
        revisionId,
        expectedDeploymentId,
        "active",
        DateTimeOffset.UtcNow);

违反点: write-side upsert 用 readmodel 做结果增强，并在缺失时现场拼 fallback summary。即使不是 polling，这仍让 caller 难以区分 command accepted、readmodel observed、invoke ready。

6. Existing endpoints show local patterns but not one contract

src/platform/Aevatar.GAgentService.Hosting/Endpoints/ServiceEndpoints.cs:410

// Refactor (iter56/cluster-891-endpoint-ack-honesty): old=200-shaped accepted, new=202 + Location
//   Service invoke is accepted for dispatch; the run resource is the status surface for outcome.
//   Never point Location at the service definition root because that is not the command/run status.
receipt.StatusUrl = BuildServiceRunStatusUrl(identity, receipt);
return Results.Accepted(receipt.StatusUrl, receipt);

src/Aevatar.Studio.Hosting/Endpoints/StudioEndpoints.cs:760

var accepted = await service.SaveAsync(scopeContext.ScopeId, request, ct);
return Results.Accepted(
    uri: $"/api/app/scripts/{Uri.EscapeDataString(accepted.ScriptId)}/save-observation",
    value: accepted);

违反点: Service invoke 用 run status URL，Studio script save 用 save-observation URL。这些局部 pattern 都合理，但缺少统一 operation response vocabulary，后续 capability 无法知道应该暴露 statusUrl、observeUrl、readinessUrl、readModelUrl 中哪些字段。

违反条款

CLAUDE.md:

• 读写分离：Command -> Event，Query -> ReadModel；异步完成通过事件通知，不在会话内拼装流程。

• ACK 诚实：同步返回只承诺已达到阶段（默认 accepted + stable command id）；committed/read-model observed 等强保证须通过独立契约或异步观察获取。

• 命令骨架内聚：标准生命周期 Normalize -> Resolve Target -> Build Context -> Build Envelope -> Dispatch -> Receipt -> Observe；业务模块只负责目标解析与载荷/结果映射。

• 业务一致性与查询一致性分层：actor 间链路对"消息已接收/事件已提交/协议已推进"负责；readmodel 对"某 StateVersion 已物化可见"负责；禁止混用。

AGENTS.md:

• ACK 语义必须诚实：同步返回只能承诺已经真实达到的阶段，默认应是 accepted for dispatch + stable command id；committed、read-model observed 等更强保证必须通过独立契约或异步观察获取，禁止在弱语义 ACK 中暗示强保证。

• 命令骨架必须内聚：标准命令生命周期应收敛为 Normalize -> Resolve Target -> Build Context -> Build Envelope -> Dispatch -> Receipt -> Observe；业务模块只负责目标解析、载荷映射和结果映射，禁止各能力入口各自拼装一套流程。

docs/canon/cqrs-projection.md:

命令执行必须走 CQRS Core 标准命令骨架，不允许每个 capability 私自拼一套 resolve/ack/observe/finalize 生命周期；同时不引入与 runtime 平行的命令总线壳层。

统一返回 Accepted + commandId (+ actorId/correlationId)，只承诺可追踪，不承诺 committed / observed。

新原则

Backend write operation response 只能同步表达 accepted 阶段和可追踪身份；更强语义必须用显式 observe/readiness/readmodel URL 或 typed stream frame 暴露。

所有 capability write APIs 复用同一最小 operation receipt vocabulary；业务模块只补 target identity、payload mapping、domain-specific readiness requirements，不再各自拼 accepted/observe/ready/failure 生命周期。

Post-acceptance execution failure 是 operation contract 的一等状态，必须能通过 commandId/correlationId 或 run/readmodel 查询到，不能在 202 Accepted 后丢失。

Fix boundary

scope_paths:

• src/Aevatar.Foundation.Abstractions/IActorDispatchPort.cs
• src/Aevatar.CQRS.Core.Abstractions/Commands/ICommandDispatchService.cs
• src/Aevatar.CQRS.Core.Abstractions/Commands/CommandDispatchResult.cs
• src/Aevatar.CQRS.Core/Commands/DefaultCommandDispatchService.cs
• src/Aevatar.CQRS.Core/Interactions/DefaultCommandInteractionService.cs
• src/platform/Aevatar.GAgentService.Application/Bindings/ScopeBindingCommandApplicationService.cs
• src/platform/Aevatar.GAgentService.Application/Bindings/ScopeBindingReadinessQueryService.cs
• src/platform/Aevatar.GAgentService.Application/Workflows/ScopeWorkflowCommandApplicationService.cs
• src/platform/Aevatar.GAgentService.Application/Scripts/ScopeScriptCommandApplicationService.cs
• src/platform/Aevatar.GAgentService.Hosting/Endpoints/ServiceEndpoints.cs
• src/platform/Aevatar.GAgentService.Hosting/Endpoints/ScopeWorkflowEndpoints.cs
• src/platform/Aevatar.GAgentService.Hosting/Endpoints/ScopeScriptEndpoints.cs
• src/Aevatar.Studio.Hosting/Endpoints/StudioEndpoints.cs
• docs/canon/cqrs-projection.md
• docs/canon/chat-api.md

Decision questions

1. Shared backend receipt 是否应新增独立 DTO/abstraction，还是只定义 field vocabulary 并让现有 receipt types 实现一致 shape？
2. ready 是否必须统一为 operation status (pending/ready/failed/timed_out)，还是只要求 capability-specific readiness endpoint 返回这些顶层状态并保留细粒度 reason？
3. Post-acceptance failure 的 canonical query key 是 commandId、correlationId、run/resource id，还是三者都必须在 receipt 中暴露？
4. ScopeWorkflow upsert 的 readmodel summary fallback 应删除为 accepted-only handle，还是移动到 explicit observe/readiness endpoint？
5. 哪些 endpoints 必须首批纳入: Service lifecycle writes、Service invoke、Scoped script save、Scoped workflow upsert、User config LLM save？

original_authors

• src/platform/Aevatar.GAgentService.Application/Bindings/ScopeBindingCommandApplicationService.cs: eanzhao, louis.li, loning
• src/platform/Aevatar.GAgentService.Application/Workflows/ScopeWorkflowCommandApplicationService.cs: eanzhao
• src/platform/Aevatar.GAgentService.Application/Bindings/ScopeBindingReadinessQueryService.cs: louis.li
• src/Aevatar.Foundation.Abstractions/IActorDispatchPort.cs: loning
• src/Aevatar.CQRS.Core.Abstractions/Commands/ICommandDispatchService.cs: loning

📢 cc @loning @eanzhao @louis4li

⟦AI:AUTO-LOOP⟧

[louis4li]

Additional requirement: async error propagation must be part of the backend contract.

The backend contract must distinguish:

• pre-dispatch/start errors: validation, auth, target resolution, envelope creation, and dispatch acceptance failures; these can still return HTTP 4xx/5xx or a typed start error synchronously.
• post-acceptance execution failures: actor handler exceptions, business rule failures discovered during execution, downstream/tool/provider failures, timeout, cancellation, and projection/materialization failures; these must be surfaced through an explicit observable channel, not lost after 202 Accepted.

Expected backend surfaces:

• streaming interactions emit typed terminal failure frames/events.
• accepted-only commands have an operation/command observation read model or observe endpoint keyed by commandId/correlationId.
• read models that represent a run/session/operation expose terminal status and typed error information when the authoritative actor has committed failure.
• capability-specific readiness endpoints must return pending/ready/failed/timed_out rather than only ready/not ready.

Acceptance criteria should include at least one post-acceptance failure test that proves a frontend can retrieve the error by operation id after the original HTTP request has returned.

[loning]

🤖 Triage codex — accept: cluster-triage-backend-async-cqrs-write-contract

TL;DR

• 结论: accept，建议 cluster id 为 cluster-triage-backend-async-cqrs-write-contract。
• 调研找到 9 个高信号文件，核心问题是 backend write API 没有统一表达 accepted / observed / ready / failed 阶段。
• 下一步: 进入 Phase 9 design-solving，先定义最小 operation receipt/readiness/failure vocabulary，再收敛 GAgentService/Studio/Workflow/Scripting write surfaces。

📢 cc 原作者:@loning @eanzhao @louis4li 请 sanity-check 这个 cluster 边界。

---

详细说明

IActorDispatchPort（actor 之间发命令的标准通道）已经明确 DispatchAsync 只代表 accepted-for-dispatch，不代表 handled、committed 或 read model observed。CQRS Core 也已删除 stream-RPC outcome contract，要求 caller 使用 accepted receipt + readmodel query 或 typed continuation event。

但 capability 层还没有统一 backend operation contract: ScopeBindingCommandApplicationService 已从旧的 readmodel polling before ACK 迁出，但留下 invoke safe now readiness TODO；ScopeWorkflowCommandApplicationService 在 write path 里读 workflow readmodel 并 fallback 拼 summary；Service invoke 和 Studio script save 各自用不同 status/observation URL。问题不是某个 endpoint 写错，而是缺一套跨能力的 response vocabulary 和 post-acceptance failure observation 规则。

---

📎 investigation artifact 摘要

• Title tokens: Define, backend, async, operation, contract, CQRS, writes；补充语义 token: accepted, observe, readiness, readmodel。
• Cross-token 高信号文件:
  • src/Aevatar.Foundation.Abstractions/IActorDispatchPort.cs
  • src/Aevatar.CQRS.Core.Abstractions/Commands/ICommandDispatchService.cs
  • src/Aevatar.CQRS.Core/Commands/DefaultCommandDispatchService.cs
  • src/Aevatar.CQRS.Core/Interactions/DefaultCommandInteractionService.cs
  • src/platform/Aevatar.GAgentService.Application/Bindings/ScopeBindingCommandApplicationService.cs
  • src/platform/Aevatar.GAgentService.Application/Bindings/ScopeBindingReadinessQueryService.cs
  • src/platform/Aevatar.GAgentService.Application/Workflows/ScopeWorkflowCommandApplicationService.cs
  • src/platform/Aevatar.GAgentService.Application/Scripts/ScopeScriptCommandApplicationService.cs
  • src/platform/Aevatar.GAgentService.Hosting/Endpoints/ServiceEndpoints.cs
  • src/Aevatar.Studio.Hosting/Endpoints/StudioEndpoints.cs
• Git history 相关 commits:
  • 170ff5fd0 iter158 #1161: delete CQRS generic outcome stream-RPC(违反 ACK 诚实)
  • 8ef79e82a issue #1132: 删 IActorHandledDispatchPort + 全 caller 改 accepted-only
  • 9856c626d iter95 cluster-095: define runtime-neutral DispatchAdmission contract; split admission vs committed/handled/observed ACK
  • 0b7a1c24a iter160 #1200: Console Web 共享 async operation state helper(frontend-only)
• 命中条款:
  • CLAUDE: ACK 诚实：同步返回只承诺已达到阶段（默认 accepted + stable command id）...
  • AGENTS: 命令骨架必须内聚...禁止各能力入口各自拼装一套流程。
  • canon: 命令执行必须走 CQRS Core 标准命令骨架，不允许每个 capability 私自拼一套 resolve/ack/observe/finalize 生命周期...
• Duplicate check: 未发现 open auto-loop issue/PR 与 Define backend async operation contract for CQRS writes #592 标题和语义相似度 > 70%。#1200 是 frontend-only，#1419 是 ChatRun continuation 局部 slice，不覆盖 backend write operation contract。
• Full artifact: .refactor-loop/runs/triage-issue-592-investigation.md

⟦AI:AUTO-LOOP⟧

[loning]

🤖 delete solver：建议先删 workflow upsert 的同步 summary 拼装

TL;DR

• 这是什么: delete solver 对 Define backend async operation contract for CQRS writes #592 的 deletion-first 评估。
• 结论: 不建议删除 backend async operation contract；它是 Service invoke、Script save、Workflow write 都在使用的真实能力。
• 下一步: controller 可采用第一刀，删除 workflow upsert write path 内的 readmodel 查询和 fallback summary，改成 accepted-only 响应。

---

详细说明

我按“先问能不能删”的角度反查了调用链。IActorDispatchPort 是 actor 命令进入 inbox 的标准通道，只承诺 accepted；Service invoke 已经返回 202 + StatusUrl，Script save 已经返回 202 + save-observation，所以 #592 的 operation observation/failure contract 不是无用 feature，不能整块删除。

可以删除的是一个具体过度实现：ScopeWorkflowCommandApplicationService.UpsertAsync 在 write path 里调用 IScopeWorkflowQueryPort.GetByWorkflowIdAsync，如果 readmodel 还没出现就现场拼一个 DeploymentStatus = "active"、UpdatedAt = DateTimeOffset.UtcNow 的 ScopeWorkflowSummary。这让 PUT /api/scopes/{scopeId}/workflows/{workflowId} 的 200 OK 看起来像已经 observed，但事实只是 lifecycle commands accepted。建议第一 slice 改为 202 Accepted + Location/observe/read URL + accepted identity；需要完整 workflow 的调用方走现有 GET /api/scopes/{scopeId}/workflows/{workflowId}。

项	删除/迁移
删除	workflow upsert command service 里的 readmodel lookup + fallback summary
改入口	ScopeWorkflowEndpoints 从 200 ScopeWorkflowUpsertResult 改为 accepted-only response
改调用方	binding tool 返回 accepted handle/read URL，不返回 inline summary
删测试	UpsertAsync_ShouldReturnFallbackSummary_WhenQueryReturnsNull
估算	first slice 约 -70 到 -110 LOC，取决于 accepted receipt DTO 形状

---

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

---
solver: delete
issue: 592
cluster: phase9-issue592
verdict: propose
---

## Classification
d) Genuinely needed but over-built

## Recommended action
不要删除 #592 代表的能力本身：backend write API 的 `accepted / observed / ready / failed` 语义是当前系统已经在使用的真实能力，Service invoke、Script save、Workflow run 都有面向调用方的状态/观察需求。删除方向应收窄为：先删掉 `ScopeWorkflowCommandApplicationService.UpsertAsync` 在 write path 内查询 `IScopeWorkflowQueryPort` 并临时拼 `ScopeWorkflowSummary` 的同步结果增强，把 workflow upsert 改成 accepted-only handle；调用方若需要完整 workflow 详情，改到现有 `GET /api/scopes/{scopeId}/workflows/{workflowId}` readmodel 查询，若需要 invoke readiness，改到 binding readiness/operation observation surface，而不是在 upsert ACK 中伪装为已 observed。

## Concrete plan (if propose)
- Files to delete: none as whole files; delete the synchronous workflow summary branch from `src/platform/Aevatar.GAgentService.Application/Workflows/ScopeWorkflowCommandApplicationService.cs`
- Caller migrations: `src/platform/Aevatar.GAgentService.Hosting/Endpoints/ScopeWorkflowEndpoints.cs` `PUT /{scopeId}/workflows/{workflowId}` -> return `202 Accepted + Location` with a narrow accepted receipt/readiness URL instead of `200 OK + ScopeWorkflowUpsertResult`
- Caller migrations: `src/Aevatar.AI.ToolProviders.Binding/Tools/ScopeWorkflowsUpsertTool.cs` -> surface accepted handle plus existing read URL, not inline `ScopeWorkflowSummary`
- Caller migrations: any UI/API caller requiring the materialized workflow -> use existing `IScopeWorkflowQueryPort.GetByWorkflowIdAsync` / `GET /api/scopes/{scopeId}/workflows/{workflowId}`
- Tests to delete: `test/Aevatar.GAgentService.Tests/Application/ScopeWorkflowCommandApplicationServiceTests.cs::UpsertAsync_ShouldReturnFallbackSummary_WhenQueryReturnsNull`
- Tests to change, not delete: endpoint/tool tests that assert `ScopeWorkflowUpsertResult.Workflow` should assert accepted receipt fields and observation/readiness URL instead
- LOC delta: about -70 to -110 net for first slice, mostly from deleting `IScopeWorkflowQueryPort` injection from the command service, fallback summary construction, and the fallback-summary test; exact delta depends on the accepted receipt DTO shape chosen by the implementing solver
- First slice: deletion/collapse slice: remove workflow-upsert readmodel lookup/fallback summary and return only accepted lifecycle identity (`revisionId`, `definitionActorIdPrefix`, `expectedActorId`, command/correlation handles if available) with HTTP `202`
- Later design slice: define the shared operation status/readiness/failure vocabulary across Service invoke, Script save, Workflow upsert, and Binding readiness; this is not a deferral claim, only the separate structural decision that should not block the deletion-first cleanup

## Reverse-evidence (why this is safe to delete)
- No public API breaks from deleting the fallback summary alone if the endpoint is intentionally versioned/changed as part of #592: current workflow upsert is already a write operation and should not promise readmodel observation in a `200 OK` body.
- `git grep`/`rg` shows the workflow query surface already exists separately: `IScopeWorkflowQueryPort.GetByWorkflowIdAsync`, `GET /api/scopes/{scopeId}/workflows/{workflowId}`, and `ScopeWorkflowQueryApplicationService` build the real readmodel-backed summary.
- The fallback summary is not load-bearing truth: when the readmodel is missing, it manufactures `DeploymentStatus = "active"` and `UpdatedAt = DateTimeOffset.UtcNow` inside the write service, which is exactly the query/write boundary violation #592 is trying to remove.
- Existing neighboring surfaces prove the accepted/observe pattern is active, not hypothetical: service invoke returns `202 + StatusUrl`; scope/studio script save returns `202 + save-observation` URL.
- No external repo dependency is involved. NyxID / chrono-storage / chrono-ornn are untouched and not needed for the proposed deletion slice.
- Tests covering the fallback path are themselves asserting the problematic behavior: `UpsertAsync_ShouldReturnFallbackSummary_WhenQueryReturnsNull` verifies an invented summary when projection has not observed the write.

## Risks
- Existing clients may depend on `PUT /workflows/{workflowId}` returning the full `ScopeWorkflowSummary` immediately. If so, that dependency is precisely relying on a weak ACK pretending to be an observed readmodel; migration must be explicit in API notes/tests.
- If no accepted receipt can expose command/correlation handles for each internal lifecycle command, the first slice can still return stable expected resource identities plus `Location`, but post-acceptance failure correlation will remain incomplete until the structural operation contract lands.
- If the AI binding tool currently requires the inline summary to continue a chain, it must switch to returning accepted identity plus read URL, otherwise the tool would keep coupling write ACK to query freshness.

## Escalation triggers (if any)
- ESCALATE_REASON: deletion-touches-public-api if controller requires preserving the exact `ScopeWorkflowUpsertResult` response shape for already released clients

## Reasoning trace (internal — for meta-judge)
- Why I claim this can be deleted: the only concretely deletable part is the workflow write-path readmodel lookup/fallback summary; it duplicates the existing query endpoint and creates local "active" status before projection observation.
- What I checked to verify safety: read issue 592 body/comments; read audit iter 832; read CLAUDE deletion-first clause; inspected `ScopeWorkflowCommandApplicationService`, `ScopeWorkflowEndpoints`, `ScopeBindingReadinessQueryService`, service invoke endpoints, studio/script save observation endpoints, model records, tests, `rg` call sites, and git history for workflow upsert and script observation.
- What I cannot decide alone: exact shared DTO name/field vocabulary for operation receipts, and whether public API compatibility requires a staged endpoint/version strategy.

SOLVER_DONE:delete:propose:collapse workflow upsert by deleting synchronous readmodel summary fallback and returning accepted-only operation identity:first-slice=remove ScopeWorkflowCommandApplicationService readmodel lookup/fallback summary; change workflow PUT to 202 accepted with observation/read URL
⟦AI:AUTO-LOOP⟧

⟦AI:AUTO-LOOP⟧