[Proposal] Separate model-authored commentary from runtime activity in long-running turns

[hqhq1025]

English

Summary

Maka should expose two separate kinds of in-turn observability:

1. Model-authored commentary: short, user-visible text in which the model explains what it is about to do, reports a meaningful finding, or marks a change of direction.
2. Runtime-derived activity: deterministic facts projected from tool and execution events, such as "read 3 files" or "ran 2 commands."

They may appear next to each other in the conversation, but they are not the same channel and should not share one message type.

Model provider
├── reasoning ───────────────────────> Thinking disclosure
├── user-visible text
│   ├── phase=commentary ────────────> Model progress narration
│   └── phase=final_answer ──────────> Terminal answer
└── tool calls
    └── RuntimeEvent / SessionEvent
        └── Activity projection ─────> Deterministic execution summary

This proposal is about inline observability during an active turn. It does not propose exposing hidden reasoning, dumping raw event-log rows into the transcript, or changing the continuation model discussed in #3567.

Problem

Long-running Maka turns can currently feel silent: the model calls tools, the UI shows tool activity, and the first model-authored user-visible text often arrives only after the work is complete.

There are three separate causes:

1. The main-session system prompt contains identity and response-format guidance, but no contract requiring preambles or meaningful progress updates (source).
2. The model text pipeline has no provider-neutral phase. ModelStreamEvent, TextDeltaEvent, TextCompleteEvent, RuntimeEventTextContent, and AssistantMessage all represent text without distinguishing commentary from the final answer (model protocol, session events, stored message).
3. Provider metadata can already contain OpenAI's phase, and Maka preserves text-end provider metadata, but it remains provider-owned metadata rather than a normalized product semantic (adapter).

The renderer is not fundamentally unable to show commentary. The timeline already preserves text/tool ordering, and finalAssistantReplyText() explicitly describes text between tool calls as work-in-progress narration (source). The missing pieces are model behavior, normalized semantics, and distinct presentation.

As one bounded observation rather than a project-wide benchmark, I inspected a recent local development workspace:

• 50 recent provider-request artifacts contained no commentary/progress instruction.
• 43 assistant rows contained 7 explicit final_answer phases and no commentary phase.
• Across 6 tool-using turns, 0 had non-empty model text before the first tool, 0 had model text between tools, and 5 had text only after the final tool.

This supports the narrower diagnosis that Maka is generally not producing commentary today; it is not merely producing it and losing it in the renderer.

Product contract

Maka should treat four channels as distinct:

Channel	Author	Model history	Purpose
Thinking	Model/provider reasoning channel	Provider-specific replay	Optional reasoning disclosure
Commentary	Model	Yes	Concise progress, findings, and immediate next action
Activity	Runtime projection	No	Deterministic execution facts
Final answer	Model	Yes	Terminal response for the turn

Commentary

Commentary is assistant-authored text. It can be contextual and personalized:

I found that the renderer already supports text before tools. I am checking whether the phase is lost at the Runtime Host boundary.

It costs output tokens, is persisted as model text, and may need to be replayed with its provider step.

Runtime activity

Runtime activity is derived from execution facts:

Read 3 files · Ran 2 commands

It must not be stored as assistant-authored text, included in model history, or charged as model output. The live form should be projected from SessionEvents; the settled form should reconcile against durable messages and RuntimeEvents, following the existing live/durable tool-activity pattern. This is a compact projection over the event stream, not a raw event-log dump.

Recommended architecture

1. Add a provider-neutral assistant text phase

export type AssistantTextPhase = 'commentary' | 'final_answer';

Carry an optional phase through the existing text lifecycle rather than adding parallel commentary_delta / commentary_complete event types:

• model adapter / ModelStreamEvent;
• TextDeltaEvent and authoritative TextCompleteEvent;
• RuntimeEventTextContent;
• AssistantMessage;
• Runtime Host SessionAssistantDelta and active stream state;
• Desktop live projection and settled timeline;
• TUI transcript entries;
• external Codex session import.

phase remains optional because providers do not emit it consistently. A completed text event is authoritative; live deltas may remain phase-unknown until metadata or step structure resolves them.

Maka's Codex fixtures already contain both phase: "commentary" and phase: "final_answer", while the current importer drops the field (fixture, importer). Preserving it would also fix imported-session fidelity.

2. Normalize phase conservatively

Recommended precedence:

Explicit valid provider phase              -> use it
No phase + assistant step has tool calls   -> commentary
No phase + terminal text-only step         -> final_answer
Still streaming and structurally unknown   -> phase absent

Two invariants matter:

• A provider-labeled final_answer followed by a tool call is contradictory. Treat it as commentary for product behavior and retain the raw provider metadata for diagnostics.
• If a provider explicitly ends a request with phase=commentary and no final answer, do not silently accept that commentary as the successful terminal response. Allow one bounded continuation when the normal step budget permits, then fail visibly if the protocol remains inconsistent.

The second guard should use explicit phase, not language heuristics such as matching "I will" or "next I will."

3. Add a root-session responsiveness contract

The main-session prompt should ask the model to:

• send one concise preamble before the first non-trivial tool call in a multi-step or tool-heavy task;
• update at meaningful phase changes, when a finding changes the plan, and before a visibly high-latency action;
• continue into the tool call after commentary rather than ending the turn;
• avoid narrating routine calls or restating facts already visible in Runtime activity;
• skip commentary for simple direct answers;
• keep each update to one or two short sentences.

This should be event/phase driven, not timer driven. "Every N seconds" would be unreliable for the model and would encourage token-heavy filler.

The default should apply to user-facing root sessions. Child-agent output should stay governed by its orchestration surface rather than flooding the parent transcript.

4. Keep the activity projection separate

The activity UI should consume tool and execution events, aggregate adjacent facts, and expand into the existing detailed tool cards:

Commentary: I found the message phase is lost at the Host boundary.

Activity:   Read 4 files · Ran 3 commands
            [expand to existing tool activity]

The activity projection must never synthesize model-style claims such as "I found the root cause." It should only state facts supported by events.

5. Preserve final-answer identity

Only phase=final_answer should power:

• Copy answer;
• answer footer actions;
• final answer accessibility identity;
• any future answer-only export.

Commentary remains visible in chronological transcript/history but is not treated as the answer. Legacy phase-less turns retain today's last-text fallback.

Runtime Host compatibility

SessionAssistantDelta uses a strict allowed-key decoder (source). Adding an optional wire-level phase therefore requires a Runtime Host compatibility-epoch increment. The current main epoch is 76; older clients would otherwise reject the unknown field and tear down the connection.

Reconnect also needs the phase in active assistant stream state, or a client joining mid-turn can render the same text differently from a continuously connected client.

Why the narrower alternatives are insufficient

Prompt only

This is useful as a quick experiment and may immediately improve behavior because the existing timeline can display text around tools. It is not a complete feature:

• the UI cannot reliably distinguish commentary from a final answer;
• copy/footer semantics remain based on position;
• Runtime Host reconnect cannot preserve the distinction;
• imported Codex sessions continue losing their phase;
• explicit commentary cannot prevent premature successful completion.

Subscribe to the raw event log

This can produce the lower Runtime activity summary. It cannot produce the upper model-authored commentary, because execution events do not contain the model's contextual explanation or judgment.

The renderer should also continue consuming the Runtime Host's bounded SessionEvent projection rather than independently tailing the storage database. The Host already owns remote observation, reconnection, redaction, sequencing, and live/durable reconciliation.

Add separate commentary event types

This duplicates the existing text pipeline's streaming, persistence, truncation, redaction, replay, reconnect, and rendering behavior. An optional semantic phase on text is smaller and keeps one chronology.

Implementation slices

PR 1: Phase foundation

• Add AssistantTextPhase.
• Normalize provider metadata.
• Round-trip phase through core, RuntimeEvent, storage, Runtime Host, Desktop, TUI, and Codex imports.
• Increment the Runtime Host compatibility epoch.
• Preserve legacy phase-less behavior.

This PR can be behavior-preserving except for imported-session fidelity.

PR 2: Commentary production and terminal semantics

• Add the root-session responsiveness prompt.
• Classify phase-less tool-bearing steps as commentary.
• Add the bounded explicit-commentary continuation guard.
• Add telemetry/diagnostics for contradictory provider phases.

PR 3: Presentation

• Render commentary with distinct but still assistant-authored styling.
• Add the separate compact Runtime activity summary.
• Keep detailed tool cards available on expansion.
• Make final-only copy/footer behavior phase-aware.

Before PR 3, prepare two or three rendered UI alternatives at matching viewports and states so the visual hierarchy can be selected independently of the protocol decision.

Acceptance tests

• Commentary streams before the first tool and remains visible after settlement.
• Multiple sequences preserve commentary → tools → commentary → tools → final_answer.
• Explicit provider phases survive persistence, replay, Runtime Host reconnect, Desktop, TUI, and Codex import.
• Phase-less tool-bearing steps fall back to commentary; terminal text-only steps fall back to final answer.
• Explicit terminal commentary receives at most one bounded continuation.
• Copy/footer/export select only the final answer when phase is known.
• Runtime activity creates no assistant message and enters no model history.
• Mixed old/new Runtime Host peers fail at handshake rather than mid-stream.

Relationship to existing work

• Never block the user on work in flight — aligning the tool, agent, and session layers #3567 establishes the broader principle that users should be able to watch, steer, and stop work in flight. This proposal addresses the inline "watch" surface only; it does not reopen park/poll/notify or work-handle semantics.
• [RFC] Session Inspector: a per-session runtime event trace, replay, and cost-attribution surface #1625 proposes a deep Session Inspector over the RuntimeEvent ledger. That is forensic and session-wide; this proposal is lightweight, inline, and active-turn focused.
• bug(runtime): Plan execution completes without a final assistant response #3884 fixed a separate case where a completed Plan could skip the final model continuation. It demonstrates why terminal-answer semantics matter, but it is not the same problem as producing commentary.

Questions for maintainers

1. Should AssistantTextPhase become a provider-neutral core semantic?
2. Should explicit terminal commentary trigger one bounded continuation?
3. Should concise commentary be enabled by default for multi-step root-session work?
4. Is the three-PR split above the right ownership boundary?
5. Should the compact Runtime activity summary be part of this feature or a follow-up after phase semantics land?

My recommendation is yes to questions 1-3, keep the three implementation slices, and treat the compact activity summary as the presentation half of the same product contract while preserving its independent runtime-derived data path.

Investigated and drafted with AI assistance (OpenAI Codex); code and observed behavior were verified against apache/maka main at 4cbe22413b29abf811de1f3fb3e8516ced7952ba.

中文

摘要

Maka 应当在一个活跃 Turn 内提供两种彼此独立的可观察信息：

1. 模型生成的 commentary：模型用简短自然语言说明接下来做什么、发现了什么、方案为何变化。
2. Runtime 生成的 activity：根据工具和执行事件确定性投影出的事实，例如“已读取 3 个文件”“运行了 2 条命令”。

它们可以在界面上相邻，但不应共用一种消息类型。

模型 Provider
├── reasoning ───────────────────────> Thinking 展示
├── 用户可见文本
│   ├── phase=commentary ────────────> 模型进展说明
│   └── phase=final_answer ──────────> 最终答复
└── tool calls
    └── RuntimeEvent / SessionEvent
        └── Activity projection ─────> 确定性执行摘要

这个提案解决活跃 Turn 内的轻量可观察性，不开放隐藏推理，不把 raw event log 原样塞进聊天，也不重新讨论 #3567 中的 park、poll、notify 和 continuation 机制。

当前问题

Maka 的长任务目前经常表现为：模型直接调用工具，界面显示工具活动，直到全部工作结束后才出现第一段模型自然语言。

原因分成三层：

1. 主会话系统提示词只有身份和回复格式，没有要求 preamble 或阶段性进展。
2. text pipeline 没有 provider-neutral 的 phase，无法区分 commentary 与 final answer。
3. OpenAI provider metadata 中已经可能存在 phase，Maka 也会保留 text-end metadata，但它仍是 provider 私有字段，没有成为产品语义。

UI 本身并非完全无法显示 commentary。现有 timeline 已经能保持“文字 → 工具 → 文字”的顺序，缺的是模型产出、统一 phase 和独立展示。

作为有限观察而非全局 benchmark，我检查了一个近期本地开发 workspace：

• 最近 50 个 provider request 工件没有 commentary/progress 指令。
• 43 条 assistant 记录里有 7 条明确的 final_answer，没有 commentary。
• 6 个工具 Turn 中，工具前文字为 0，工具之间文字为 0，5 个只在最后一个工具后出现文字。

因此当前主要问题是模型没有生成 commentary，而不是前端已经收到 commentary 后把它丢掉。

产品契约

四种通道应明确分开：

通道	产生者	进入模型历史	用途
Thinking	模型/provider reasoning 通道	provider-specific replay	可选推理展示
Commentary	模型	是	简短进展、发现和下一步
Activity	Runtime 投影	否	确定性执行事实
Final answer	模型	是	Turn 的最终答复

Commentary 是 assistant-authored text，会消耗 token、持久化，并可能需要随着 provider step replay。

Activity 来自执行事实，不应创建 assistant message、不应进入模型历史，也不应计为模型输出。实时部分从 SessionEvent 投影，settled 部分与 durable messages / RuntimeEvent 对账。它是 event stream 的紧凑展示，不是 raw event log dump。

推荐架构

1. 增加 provider-neutral phase

export type AssistantTextPhase = 'commentary' | 'final_answer';

在现有 text 生命周期上增加可选 phase：

• model adapter / ModelStreamEvent;
• TextDeltaEvent 与权威的 TextCompleteEvent;
• RuntimeEventTextContent;
• AssistantMessage;
• Runtime Host SessionAssistantDelta 与 active stream state;
• Desktop live projection 和 settled timeline;
• TUI transcript;
• Codex session importer。

不要增加一套平行的 commentary_delta / commentary_complete，否则会复制 text pipeline 的 streaming、持久化、redaction、replay、重连和渲染。

2. 保守判定 phase

Provider 给出合法 phase            -> 使用
没有 phase，同一步含 tool call     -> commentary
没有 phase，终态 text-only step    -> final_answer
流式期间无法确定                   -> phase 缺省

需要两条不变量：

• final_answer 后仍有 tool call 是协议矛盾。产品行为上按 commentary 处理，同时保留原始 metadata 做诊断。
• Provider 明确以 phase=commentary 结束、却没有 final answer 时，不能把 commentary 静默当作成功终态。step budget 允许时只进行一次有界 continuation，再次异常则明确失败。

第二条只能依赖明确 phase，不能用“我先”“我会”等语言关键词猜测。

3. 增加 root-session responsiveness prompt

主会话模型应当：

• 多步骤或工具密集任务第一次非平凡 tool call 前给一句简短说明；
• 只在阶段变化、发现改变方案、即将进行明显高延迟操作时更新；
• commentary 后继续进入 tool call，不能停在状态句；
• 不复述 activity 已经能表达的“读文件、跑命令”等事实；
• 简单直接回答不强制 commentary；
• 每次限制为一到两句。

不采用“每 N 秒更新”这种定时规则，以免产生不可执行且浪费 token 的填充文本。

默认只作用于用户可见 root session。子 agent 的输出由编排界面管理，避免淹没父会话。

4. Activity 保持独立

Commentary：我确认 phase 在 Host 边界丢失了，接下来检查重连协议。

Activity：已读取 4 个文件 · 运行了 3 条命令
          [展开为现有详细工具卡片]

Activity 只能陈述事件支持的事实，不能生成“我找到了根因”这种模型判断。

5. final answer 身份

只有 phase=final_answer 驱动：

• Copy answer；
• answer footer actions；
• final answer accessibility identity；
• 未来的 answer-only export。

Commentary 保留在时间线中，但不被当作答案。旧的 phase-less Turn 继续使用当前 last-text fallback。

Runtime Host 兼容性

SessionAssistantDelta 使用严格 allowed-key decoder。增加 wire-level phase 必须提高 Runtime Host compatibility epoch。当前 main 的 epoch 是 76，否则旧 Client 会因未知字段在流中断开。

重连时 active assistant stream 也必须携带 phase，否则中途加入的 Client 会和持续在线的 Client 得到不同展示。

为什么两个简单方案不够

只改 prompt

可以作为快速实验，并可能立即改善产出，但不是完整 feature：

• UI 无法可靠区分 commentary 和 final；
• copy/footer 仍依赖位置；
• Runtime Host 重连无法保留语义；
• Codex import 继续丢 phase；
• explicit commentary 无法阻止错误终止。

只订阅 raw event log

只能生成下方 Runtime activity，无法生成上方模型 commentary，因为事件里没有模型的上下文解释和判断。

Renderer 也应继续消费 Runtime Host 的 bounded SessionEvent projection，而不是独立 tail storage DB。Host 已经负责 remote observation、重连、redaction、顺序以及 live/durable 对账。

实施分期

PR 1：Phase foundation

• 增加 AssistantTextPhase；
• normalize provider metadata；
• 贯穿 core、RuntimeEvent、storage、Runtime Host、Desktop、TUI 和 Codex import；
• 提高 compatibility epoch；
• 保持旧 phase-less 行为。

PR 2：Commentary production 与终态语义

• 增加 root-session responsiveness prompt；
• 无 phase 且含工具的 step 判为 commentary；
• 增加 explicit-commentary 的有界 continuation；
• 为 provider phase 矛盾增加诊断。

PR 3：Presentation

• Commentary 使用独立但仍属于 assistant-authored text 的样式；
• 增加独立的紧凑 Runtime activity summary；
• 展开后继续使用现有工具卡片；
• copy/footer 只识别 final answer。

PR 3 开始前先制作两到三个相同 viewport 和状态的 UI 方案，单独确定视觉层级。

与现有工作的关系

• Never block the user on work in flight — aligning the tool, agent, and session layers #3567 提出用户应当能观察、介入和停止进行中的工作。本提案只解决 inline “watch” surface，不重新讨论 continuation 或 work handle。
• [RFC] Session Inspector: a per-session runtime event trace, replay, and cost-attribution surface #1625 的 Session Inspector 是 session-wide 的深度诊断。本提案是轻量、inline、active-turn 的。
• bug(runtime): Plan execution completes without a final assistant response #3884 修复了 Plan 完成后跳过最终回复的独立 bug。它说明 final-answer 终态语义很重要，但不是 commentary 产出问题本身。

希望维护者确认的问题

1. AssistantTextPhase 是否应成为 provider-neutral core semantic？
2. Explicit terminal commentary 是否应触发一次有界 continuation？
3. 多步骤 root-session 是否默认开启简短 commentary？
4. 三个 PR 的 ownership boundary 是否合适？
5. 紧凑 Runtime activity summary 应与 phase feature 同期完成，还是后续跟进？

我的建议是问题 1-3 选择 yes，保持三个 implementation slice，并把 activity summary 视为同一产品契约的 presentation 部分，但继续维持独立的 runtime-derived 数据路径。

本调查和草稿由 OpenAI Codex 辅助完成；代码与观察行为已对照 apache/maka main 的 4cbe22413b29abf811de1f3fb3e8516ced7952ba 验证。

[Astro-Han]

Seeing #4270 carry phase through storage, Runtime Host, CLI, and UI made one tradeoff much clearer to me. I think the first slice can stop earlier.

What I want to fix is the silence inside the agent loop. Today, these text slots are often empty:

assistant text + tool call
        -> tool result
        -> assistant text + next tool call
        -> ...

A prompt change may already be enough to improve that. The model can say what it is about to do before the first non-trivial tool call, then update the user when it finds something important or changes direction. This works with Responses, Chat Completions, and Anthropic because they can all emit ordinary Assistant Text.

For Responses, I would still preserve its native phase exactly as provider metadata, including the original text-item boundary when replay needs it. I am just not sure it needs to become a shared Maka field yet.

So the first slice I have in mind is small: update the prompt, and make sure Responses metadata survives replay. That solves the user-facing problem without asking Chat Completions and Anthropic to imitate a Responses-specific concept. It also avoids adding another authority that has to stay in sync across storage, Runtime Host, CLI, and UI.

I prefer this shape because it keeps the common path KISS. The shared layer only models what the protocols actually share, while provider-specific information stays with the provider.

This is only my current view. I may be missing a consumer or replay constraint that makes the broader phase model necessary, so please push back. I would rather work through those cases here before settling on the implementation.

中文

#4270 把 phase 一直贯穿到存储、Runtime Host、CLI 和 UI 以后，我更倾向于让第一阶段停得早一点。

我现在想解决的是 agent loop 中间没有文字的问题。模型在调用工具前、发现重要信息或改变方向时，输出普通的 Assistant Text 就够了。这是 Responses、Chat Completions 和 Anthropic 都有的能力。

Responses 原生的 phase 仍然可以作为 provider metadata 原样保存，replay 需要时也保留 text item 边界。但我暂时不想把它提升成 Maka 的跨协议字段。

这样第一阶段只需要改提示词，再确认 Responses metadata 能无损回放。公共层保持 KISS，也不会要求其他协议模拟 Responses，或者新增一套需要跨多个层级同步的 authority。

这只是我目前的判断。如果还有我没有考虑到的消费者或 replay 约束，欢迎直接 push back，我们可以继续在这里把它讨论清楚。

[hqhq1025]

Implementation update after prompt-only testing

I tested the smaller prompt-only direction proposed above and then followed the behavior through the Runtime, persistence, reconnect, CLI, TUI, and GUI paths. The experiment changed my conclusion in one important way: optional prompt guidance improves cooperative models, but it does not reliably create an observable update on phase-less providers. In a live test, a provider went directly to the work tools and emitted no progress text.

The implementation in #4270 now uses this boundary:

Provider-native text
├── Responses adapter with native phase
│   ├── commentary
│   └── final_answer
└── Phase-less provider
    ├── Runtime forces one ProgressUpdate prelude when real work tools exist
    ├── tool-bearing assistant step -> commentary
    └── terminal text-only step -> final_answer

Runtime events
└── deterministic activity disclosure

ProgressUpdate is a compatibility transport, not a new activity event:

• it is available only to phase-less root sessions that also have real work tools;
• the first progress update is forced even when the model supports parallel tool calls;
• it does not consume the caller's maxSteps, although it is still counted in provider telemetry;
• it is hidden from the runtime activity list and retained in model history as assistant-authored text;
• tool-free questions and child sessions do not pay the extra provider request.

This keeps the two visible layers separate:

1. Commentary is model-authored, contextual text.
2. Activity is a deterministic summary of reasoning/tool/runtime events.

The UI now reflects that hierarchy. During execution, commentary remains visible and the reasoning/tool records between updates sit in an inner processing disclosure. Once the final answer begins, all earlier work is moved under an outer duration disclosure and collapsed once. The final answer stays visible. A user's manual reopen is preserved.

The provider-neutral phase now has concrete consumers rather than being metadata propagated in anticipation of a future UI:

• final-only CLI output, copy actions, footers, and child summaries;
• the completed-work collapse boundary;
• reconnect, replay, stored-terminal seeding, and shared-transcript consistency;
• a bounded continuation when a provider explicitly ends with commentary but no final answer;
• faithful import of Codex sessions that already contain both phases.

Native OpenAI Responses phase remains native evidence only when the selected adapter actually preserves it. Open-responses compatibility adapters, Chat Completions, and Anthropic are treated as phase-less; Maka derives its own product semantic from step topology rather than claiming those protocols expose the Responses field.

The cost is explicit: phase-less, tool-capable root turns make one additional provider request for the progress prelude. The benefit is a deterministic first user-visible update and stable final-answer identity across all consumers. Direct answers and native-phase providers avoid that cost.

I also verified the full path with paid models:

• Azure bridge gpt-5.6-sol
• coproxy Claude Sonnet 5

For the latest Claude run, the durable sequence was:

commentary
-> ProgressUpdate
-> Read / ArchiveRead
-> final_answer
-> completed

The PR includes matching before/after GUI captures and TUI/CLI coverage. It does not expose hidden reasoning or render the raw event log as commentary.

[hqhq1025]

Visual comparison

These captures use the same persisted turn, viewport (1483 x 820), application state, content, and zoom.

Flat baseline

This is the same turn rendered without the new outer work-log disclosure. Commentary, runtime activity, and the final answer have little visual separation:

Settled turn

When the final answer begins, prior commentary, reasoning, and runtime activity collapse under a duration header. The final answer stays in the normal transcript:

Reopened work log

Manual expansion restores the model-authored commentary and the nested event-derived activity disclosure. This shows the intended hierarchy: commentary and activity are adjacent, but they remain different semantic layers.

[Astro-Han]

Thanks for running this against real paid models — that's the right way to test it. I've read through #4270, and I think the shape has grown past what the problem needs. Four things, roughly in order of how much they weigh on me.

1. phase serves one adapter but is being asked of every protocol. The only place a native value is read is metadata.openai.phase in model-adapter.ts. Everything else is inferred, and the inference is one line:

providerPhase ?? (completedStep ? 'final_answer' : undefined)

For phase-less providers, phase just means "is this the last step" — no new information. Meanwhile the change reaches 61 files across core, runtime, runtime-host, cli, ui, and desktop, and bumps the compatibility epoch to 79. That's a narrow origin paying a repository-wide cost.

I'd keep it as a Responses/Codex adaptation: store it, preserve it faithfully, and let the adapter do the one check that genuinely needs the native value — a turn ending in explicit commentary with no final answer. The Codex importer dropping a field its own fixtures carry is a real bug and worth fixing on its own.

Most consumers don't need it. finalAssistantReplyText() already answers "which part is the final answer" from the timeline's last text entry, and its comment says intermediate text is work-in-progress narration. That covers the collapse boundary, copy, and footers. And your own CLI change keeps #explicitFinalOutput ?? #legacyFinalOutput — so the phase-less path still resolves a final output.

2. Splitting the step budget worries me more than the field does. runtimeSteps is currently the one step concept: budget checks, stepNumber telemetry, providerRequestTracker.setStep, and the runtimeSteps we return. #4270 moves all five budget checks to a new budgetSteps but leaves telemetry, the tracker, and the returned value on runtimeSteps. So maxSteps: 10 can now issue 11 provider requests, the returned runtimeSteps is no longer comparable to the limit the caller set, and telemetry step numbers sit one off from budget step numbers after the prelude. That's one authority becoming two, split along "which step doesn't count against the user" — and it's in service of a tool that does nothing.

3. The tool itself is heavier than the behaviour it buys. ProgressUpdate is a no-op — impl: () => ({ status: 'displayed' }) — used as a transport for text, so commentary ends up as assistant text on some providers and a tool call on others. The prompt fragment is 15 lines, much of it the model reasoning about when Runtime will force the call rather than talking to the user, including a rule I think is genuinely ambiguous: "Skip progress updates only when no tool is needed… unless Runtime explicitly requires ProgressUpdate for that step."

4. And I don't think prompt-only has been ruled out yet. The evidence against it is one live run where a provider went straight to tools. Your original baseline was thorough — 50 artifacts, 43 rows, 6 turns — so I'd want the counter-evidence at a similar bar before we conclude the simpler path can't work: which model, how many attempts, and what the prompt said then. The current fragment is written around the tool, so it can't stand in for a prompt-only version.

On the underlying goal — a user shouldn't stare at a silent turn — tool activity is already visible in the UI today. Making that a better summary is worth doing, and it needs neither phase nor a tool.

The collapse hierarchy is a different matter, and the captures sold me on it. I'd keep that and the import fix and drop the cross-protocol parts. Since epoch 79 is a protocol break, I'd rather we agree before spending it.

Tell me where I've got this wrong — especially on how narrow phase really is, since that's carrying most of my argument.

简体中文

感谢你拿真实的付费模型跑了验证——这是测试这件事的正确方式。我读了 #4270，觉得方案的形态已经超出问题本身的需要了。四点，大致按分量排序。

1. phase 只服务一个 adapter，却要求所有协议都实现它。 唯一读取 native 值的地方是 model-adapter.ts 里的 metadata.openai.phase。其余全靠推断，而推断只有一行：

providerPhase ?? (completedStep ? 'final_answer' : undefined)

对 phase-less 的 provider，phase 的含义就是「这是不是最后一步」——没有新信息。与此同时，这次改动铺到 core、runtime、runtime-host、cli、ui、desktop 共 61 个文件，并把兼容 epoch 提升到 79。一个来源很窄的概念，付出的是全仓库范围的成本。

我倾向把它保留为 Responses/Codex 的适配：存下来、忠实保留，并让 adapter 去做那个唯一真正需要 native 值的检查——显式以 commentary 结束且没有 final answer 的那一轮。Codex importer 丢掉自己 fixture 里就有的字段是真实的 bug，值得单独修。

大多数消费者并不需要它。finalAssistantReplyText() 已经用 timeline 里最后一条 text 回答了「哪一段是最终答案」，它的注释也写明中间文本是 work-in-progress narration。折叠边界、copy、footer 都被这条覆盖了。而且你自己的 CLI 改动保留了 #explicitFinalOutput ?? #legacyFinalOutput——说明 phase-less 路径依然能解析出 final output。

2. 比起字段本身，拆分步数预算更让我担心。 runtimeSteps 目前是唯一的步数概念：预算判断、stepNumber 遥测、providerRequestTracker.setStep，以及我们返回的 runtimeSteps。#4270 把 5 处预算判断全部迁到新的 budgetSteps，却把遥测、tracker 和返回值留在 runtimeSteps。于是 maxSteps: 10 现在可以发出 11 次 provider 请求，返回的 runtimeSteps 不再能与调用方设的上限对照，遥测里的步号在 prelude 之后与预算步号永久相差 1。这是一个权威变成了两个，拆分线是「哪一步不计入用户预算」——而这一切是为了一个什么都不做的工具。

3. 工具本身比它换来的行为更重。 ProgressUpdate 是个 no-op——impl: () => ({ status: 'displayed' })——被用作文本的传输通道，于是 commentary 在一部分 provider 上是 assistant text，在另一部分上是 tool call。提示词片段有 15 行，其中相当一部分是让模型推理 Runtime 何时会强制调用，而不是与用户对话，其中有一条规则我认为确实有歧义：「Skip progress updates only when no tool is needed… unless Runtime explicitly requires ProgressUpdate for that step」。

4. 另外我认为 prompt-only 还没有被排除。 反对它的证据是一次实测中某个 provider 直接去调了工具。你原来的基线很扎实——50 个 artifact、43 行、6 个 turn——所以在断定更简单的路走不通之前，我希望反面证据也能达到类似标准：哪个模型、试了几次、当时的提示词是什么。现在这版片段是围绕工具写的，无法代表 prompt-only 版本。

至于底层目标——用户不该盯着一个沉默的 turn——工具活动今天在 UI 上本来就是可见的。把它做成更好的摘要值得做，而这既不需要 phase 也不需要工具。

折叠层级是另一回事，截图说服了我。我会保留它和导入修复，去掉跨协议的那些部分。另外 epoch 79 是协议破坏性变更，我更希望先达成一致再花掉它。

如果哪里我判断错了，请直接指出——尤其是 phase 到底有多窄，我的大部分论点都建立在这上面。

(Drafted with AI assistance; I verified the adapter's phase source, the step-budget change, the CLI fallback, and the prompt fragment against #4270's diff myself.)