feat(cli): redesign Dynamic Workflow execution console - #7892
Closed
qwen-code-dev-bot wants to merge 4 commits into
Closed
feat(cli): redesign Dynamic Workflow execution console#7892qwen-code-dev-bot wants to merge 4 commits into
qwen-code-dev-bot wants to merge 4 commits into
Conversation
github-actions
Bot
added
the
review/self-reported
Collaborator
|
|
Collaborator
Author
Terminal E2E reportResult: PASS
Raw ANSI-stripped capture: |
Collaborator
|
Thanks for the PR! Template looks good ✓ Problem: this is an observed UX gap, not theoretical hardening. Issue #7890 describes concretely how the current workflow detail view presents phases, logs, and errors as a uniform text stack, forcing users to scan lines to answer basic operational questions (is it healthy? which phase is active? how much agent work finished?). The issue was triaged and accepted for exploration under Direction: aligned — this is a TUI-only presentation upgrade for an existing shipped feature (Dynamic Workflows from #4721 / #5600). No runtime, persistence, scheduling, or API changes. The issue triage already confirmed direction alignment and the scope is well-contained within Size: not applicable — both changed files are in Approach: the scope feels right. The diff extends the existing Moving on to code review. 🔍 中文说明感谢贡献！ 模板完整 ✓ 问题：这是一个已观测到的 UX 差距，而非理论性加固。Issue #7890 具体描述了当前工作流详情视图如何将阶段、日志和错误呈现为统一的文本堆栈，迫使用户逐行扫描才能回答基本操作问题（运行是否健康？哪个阶段活跃？多少 agent 工作已完成？）。该 issue 已经过评审并在 方向：对齐——这是已发布功能（Dynamic Workflows，来自 #4721 / #5600）的纯 TUI 展示层升级。不涉及运行时、持久化、调度或 API 变更。Issue 评审已确认方向一致，范围明确集中在 规模：不适用——两个变更文件均在 方案：范围合理。diff 扩展了现有 进入代码审查 🔍 — Qwen Code · qwen3.8-max-preview Reviewed at |
Collaborator
Code ReviewIndependent proposal: for this redesign I would (1) compute a per-phase state (completed / active / queued) by merging declared phases from Comparison: the PR's approach matches this almost exactly. Three focused helpers ( No critical blockers found. No AGENTS.md violations. The i18n interpolation pattern ( One non-blocking observation: in a failed workflow, the phase that was active at failure time renders as ● (completed) because it's in the observed set and CI Test EvidenceThe main unit test suite is still running on this commit. No failures observed so far; macOS and Windows test jobs were skipped (not triggered for this PR event). The finalize workflow will update the table below once CI settles. Final CI results for
One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行（取最新一次运行），省略 skipped，失败项排在最前。 中文说明代码审查独立方案： 对于此次重新设计，我会 (1) 通过合并 对比： PR 方案与上述几乎完全一致。三个聚焦的辅助函数（ 未发现关键阻塞问题。未发现 AGENTS.md 违规。i18n 插值模式（ 一个非阻塞观察：在失败的工作流中，失败时活跃的阶段渲染为 ●（已完成），因为它在观测集合中且非运行状态的 CI 测试证据主要单元测试套件仍在此提交上运行。目前未观察到失败；macOS 和 Windows 测试作业被跳过（此 PR 事件未触发）。finalize 工作流将在 CI 完成后更新下方表格。 — Qwen Code · qwen3.8-max-preview Reviewed at |
Collaborator
|
Confidence: 4/5 — clean, focused implementation that matches the issue's acceptance criteria; only non-blocking nit is the failed-phase marker ambiguity. This is a well-scoped TUI upgrade. The three helpers ( The one reservation is minor: a failed workflow's last-active phase renders as ● (completed) rather than getting a distinct marker, since Approval deferred until CI lands green on 中文说明置信度：4/5 —— 干净、聚焦的实现，符合 issue 的验收标准；唯一的非阻塞细节是失败阶段标记的歧义。 这是一个范围良好的 TUI 升级。三个辅助函数（ 唯一的保留意见是次要的：失败工作流的最后活跃阶段渲染为 ●（已完成）而非获得不同标记，因为非运行状态的 审批推迟至 CI 在 — Qwen Code · qwen3.8-max-preview Reviewed at |
Contributor
Code Coverage Summary
CLI Package - Full Text ReportCore Package - Full Text ReportFor detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run. |
Collaborator
Author
Collaborator
Author
|
🤖 Reviewed the latest feedback — no changes needed. Why, point by point: · 已审阅最新反馈——无需改动。逐点说明原因如下： Autofix review round — no code changeThe only item in this round's feedback is a failed CI check:
There were no review comments, inline comments, or issue-level comments to Why the failure is unrelated to this PRThis PR changes exactly one production file (plus its test): The failing check runs the web-shell browser smoke suite
There is no code path from this change to the web-shell browser bundle, so this Why it could not be reproduced locallyThe exact check requires a launchable Chromium with system libraries. On this Local verification of the PR's own change
中文说明Autofix 审查轮次 —— 无代码改动本轮反馈中唯一的项目是一个失败的 CI 检查：
没有任何审查评论、行内评论或 issue 级评论需要处理。经过调查，无需进行代码改动：该失败检查与本 PR 的改动无关，并且无法在本运行环境中复现。 为什么该失败与本 PR 无关本 PR 仅改动了唯一一个生产文件（及其测试）： 失败的检查运行的是 web-shell 的浏览器冒烟测试套件（
从本次改动到 web-shell 浏览器打包产物之间不存在任何代码路径，因此本次改动不可能成为该冒烟测试失败的原因。浏览器冒烟测试套件对时序 / 视口 / SSE 很敏感，并且在 CI 中已经配置了 为什么无法在本地复现该精确检查需要一个可启动的、带有系统库的 Chromium。在本运行环境中，浏览器启动失败，报错为 对本 PR 自身改动的本地验证
Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 🧠 Handled by Qwen Code · model/模型 |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
Reviewed. Suggestions are inline.
中文说明
已审查。 建议见行内评论。
— qwen3.7-max via Qwen Code /review
| maxWidth: number, | ||
| ): { complete: string; remaining: string } | null { | ||
| if (dispatched <= 0) return null; | ||
| const cells = Math.min(10, dispatched, Math.max(3, maxWidth - 24)); |
Collaborator
There was a problem hiding this comment.
[Suggestion] Magic number 24 represents the non-meter character overhead in the agents row ("Agents" + spaces + "X/Y" count), but the actual overhead is 14–18 characters depending on agent-count digit width. At widths 25–34, the meter bar is needlessly short because 24 over-reserves by 6–10 characters. If the row label text changes (e.g. i18n of "Agents" into a longer translation), the number silently becomes incorrect.
Concrete cost: maxWidth - 24 ≤ 0 at narrow widths clamps cells to 3 via Math.max(3, …), which still renders but wastes space.
Suggested change
| const cells = Math.min(10, dispatched, Math.max(3, maxWidth - 24)); | |
| const METER_LABEL_OVERHEAD = 18; // "Agents"(6) + " "(2) + " "(1) + "X/Y"(3–7) + padding | |
| const cells = Math.min(10, dispatched, Math.max(3, maxWidth - METER_LABEL_OVERHEAD)); |
中文说明
[建议] 魔术数字 24 表示 Agents 行中非进度条部分的字符开销（"Agents" + 空格 + "X/Y" 计数），但实际开销仅 14–18 字符（取决于 agent 数量位数）。在宽度 25–34 时，进度条会因 24 多预留 6–10 字符而不必要地缩短。如果行标签文本变更（如 "Agents" 的 i18n 翻译更长），该数字会悄悄变得不正确。
具体代价：在窄宽度下 maxWidth - 24 ≤ 0 会通过 Math.max(3, …) 将格子限制为 3，虽然仍能渲染但浪费空间。
— qwen3.7-max via Qwen Code /review
Collaborator
Author
There was a problem hiding this comment.
Declined. The current 24 is a conservative reserve that renders correctly today, and the meter is already clamped to [3, 10] cells (Math.min(10, …) / Math.max(3, …)), so the practical rendering difference at narrow widths is negligible. The proposed 18 is itself an acknowledged estimate (a 14–18 range depending on agent-count digit width) rather than a derived constant, so the change would swap one approximate literal for another while introducing a small risk of under-reserving for wide counts (e.g. 100/250) and letting the row exceed maxWidth. The i18n concern applies to any hardcoded label width and is not resolved by naming the constant. Not worth the behavior change and diff growth.
中文说明
拒绝。当前的 24 是一个保守预留值，目前渲染正确；并且进度条已被限制在 [3, 10] 格（Math.min(10, …) / Math.max(3, …)），因此在窄宽度下实际渲染差异可忽略不计。建议的 18 本身也是一个被承认的估算值（取决于 agent 数量位数，范围为 14–18），而非推导出的常量，因此该改动只是把一个近似字面量换成另一个，同时引入对较大计数（如 100/250）预留不足、导致该行超出 maxWidth 的小风险。i18n 顾虑适用于任何硬编码的标签宽度，命名常量并不能解决它。综合行为变更与 diff 增长的成本，不值得改动。
Collaborator
Author
|
🤖 Addressed the latest review feedback (round 1/10). What changed, and what I pushed back on: · 已处理最新评审反馈（第 1/10 轮）。改动内容与我反驳保留之处如下： Review round summary — PR #7892Addressed the automated reviewer's inline suggestions on the Dynamic Workflow Feedback pointsrc:3662563575 — terminal workflows render skipped phases as
|
Collaborator
Author
|
🔀 Base updated: red check(s) [Test (ubuntu-latest, Node 22.x), review-pr] pass on current main — merged current main via update-branch; CI will re-run. 中文说明🔀 已更新 base：红色检查 [Test (ubuntu-latest, Node 22.x), review-pr] 在当前 main 上通过 —— 已通过 update-branch 合入当前 main，CI 将重新运行。 |
Collaborator
Author
|
🤖 Reviewed the latest feedback — no changes needed. Why, point by point: · 已审阅最新反馈——无需改动。逐点说明原因如下： Review round — no action takenThis round's feedback contains no reviews, no inline comments, and no issue-level comments to address. The only signal is a failed No code changes were made this round. 中文说明审查轮次 — 未采取任何操作本轮反馈中没有审查意见、没有行内评论、也没有 issue 级别的评论需要处理。 唯一的信号是 本轮未做任何代码更改。 Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 🧠 Handled by Qwen Code · model/模型 |
Collaborator
Author
|
Closing because this work was opened against the wrong product repository. The Dynamic Workflow TUI proposal belongs in qwen-code-dev-bot/oh-my-cli; no part of this PR should be merged here. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this PR does
This redesigns the Dynamic Workflow detail view as a compact execution console. It separates the run header, phase rail, live agent progress, recent signals, and terminal errors so users can understand a workflow at a glance without losing raw operational detail.
The phase rail distinguishes completed, active, and queued work with existing Qwen theme tokens, keeps the active phase visible when long workflows are truncated, and preserves phase token usage. The agent meter reports exact completed and dispatched counts only when agents were actually dispatched, avoiding invented percentages. Narrow terminals retain the same hierarchy through deterministic truncation.
The information hierarchy was informed by public Claude workflow posts about explicit planning, visible progress, and user intervention, without copying source code, product assets, or branding: https://x.com/claudeai/status/2010805682434666759 and https://x.com/claudeai/status/2010805687975379045.
Why it's needed
Dynamic Workflow runs currently present phases, logs, and failures as a largely uniform text stack. During a live run, users must infer which phase is active, what remains queued, whether parallel agents are making progress, and which lines are execution signals versus errors. The new hierarchy makes those states explicit while remaining faithful to the events emitted by the workflow runtime.
Reviewer Test Plan
How to verify
Run a Dynamic Workflow with multiple declared phases and open its detail view from the Background Tasks footer. Confirm that the header reports the actual terminal state and elapsed time, the rail marks completed, active, and queued phases distinctly, and the active phase detail appears directly beneath its marker. For a workflow that dispatches agents, confirm the meter uses exact completed/dispatched counts; for a workflow without agents, confirm the meter is absent. Resize the terminal and confirm the active phase remains visible with an honest count of omitted phases. Trigger an error and confirm it remains the strongest visual signal.
Evidence (Before & After)
Before: phase events, log messages, and errors appeared in one similarly weighted text stack, with no persistent execution rail or explicit separation between workflow structure and recent signals.
After, from a real 100x34 tmux session using
/release-readiness:Tested on
Environment (optional)
Built local branch with Node.js 22+, configured
qwen3.8-max-preview, and exercised the bundled CLI in a real 100x34 tmux session with Dynamic Workflows enabled.Risk & Scope
Linked Issues
Closes #7890
中文说明
本 PR 做了什么
本 PR 将 Dynamic Workflow 详情视图重新设计为紧凑的执行控制台。它分离运行头部、阶段轨道、实时 Agent 进度、最近信号和终止错误，使用户无需丢失原始运行细节即可快速理解工作流状态。
阶段轨道使用现有 Qwen 主题 token 区分已完成、进行中和排队中的工作；长工作流截断时仍会保留当前活动阶段，并保留阶段 token 用量。Agent 进度条只在真实派发 Agent 时展示精确的已完成数和派发数，不生成虚构百分比。窄终端通过确定性的截断保留相同的信息层级。
信息层级参考了 Claude 关于明确计划、可见进度和用户介入的公开工作流推文，但未复制源码、产品资源或品牌：https://x.com/claudeai/status/2010805682434666759 和 https://x.com/claudeai/status/2010805687975379045。
为什么需要
当前 Dynamic Workflow 运行会将阶段、日志和失败信息呈现为权重近似一致的文本堆栈。实时运行期间，用户需要自行推断当前活动阶段、后续排队内容、并行 Agent 是否在推进，以及哪些行属于执行信号或错误。新的信息层级明确展示这些状态，同时保持与工作流运行时发出的事件一致。
Reviewer 测试计划
如何验证
运行一个包含多个声明阶段的 Dynamic Workflow，并从 Background Tasks 底部入口打开详情视图。确认头部展示真实终止状态和耗时，轨道明确区分已完成、活动和排队阶段，活动阶段详情紧邻其标记显示。对于派发 Agent 的工作流，确认进度条使用精确的已完成数和派发数；对于未派发 Agent 的工作流，确认不展示进度条。调整终端尺寸，确认活动阶段仍然可见，并如实显示被省略的阶段数量。触发错误，确认错误仍是最强的视觉信号。
证据（改动前后）
改动前：阶段事件、日志消息和错误显示在视觉权重近似一致的文本堆栈中，没有持续展示的执行轨道，也没有明确区分工作流结构与最近信号。
改动后：上方英文部分展示了真实 100x34 tmux 会话中运行
/release-readiness的完整文本帧。测试平台
环境（可选）
使用 Node.js 22+ 构建本地分支，配置
qwen3.8-max-preview，并在启用 Dynamic Workflows 的真实 100x34 tmux 会话中运行打包后的 CLI。风险与范围
关联 Issue
关闭 #7890