fix(workflows): simplify completed workflow UI without losing delivery evidence

[yxr-2025]

Closes #173

Problem

Completed background workflows repeat the same state across the status row, follow-up wrapper, and completion report. Routine diagnostics such as Run dir, Log, Agents, and Delivery id also remain expanded in the conversation.

This makes successful completion more visually prominent than the running state and pushes the actual workflow return value below transport and diagnostic details.

UI simplification must not remove the model-visible delivery identities, recovery evidence, artifacts, or deduplication facts required by the workflow lifecycle.

Value

This PR makes successful workflow completions easier to scan:

• collapsed completions have one compact status summary;
• workflow name, status, agent coverage, and duration appear once;
• the workflow return value is prioritized over transport wrappers and routine logs;
• routine diagnostics remain available after expansion;
• failures, uncertainty, dropped work, retained worktrees, and worktree handoffs remain visible while collapsed.

The model still receives the complete delivery evidence required for recovery, retries, and deduplication.

Screenshots

Successful completion, collapsed

The normal success path keeps one compact summary and prioritizes the workflow result. Routine diagnostics stay behind expansion.

Successful completion, expanded

Expansion restores the full report, including the run directory, per-agent status, complete result, and delivery ID.

Exceptional completion, collapsed

Failed-agent evidence remains prominent while routine diagnostics stay collapsed and the workflow result remains visible.

## Approach

The change separates canonical runtime facts, model-visible completion context, and the operator-facing UI projection.

The user-visible projection now:

• stores bounded display fields instead of carrying the full WorkflowDetails runtime object;
• renders one compact completion summary while collapsed;
• keeps run directories, delivery IDs, agent details, routine logs, and artifact paths behind expansion;
• renders workflow return/result previews ahead of routine diagnostics;
• highlights failed and uncertain agents, dropped work, retained worktrees, and successful worktree handoffs;
• builds the expanded operator report independently from model-facing completion copy;
• fails closed when persisted display data is malformed;
• preserves terminal-control sanitization, narrow-terminal expansion guidance, and display byte budgets;
• applies a shared bounded budget to batch completion displays.

The model-visible projection remains independent. Stable delivery IDs are placed in a dedicated bounded delivery-facts envelope, so large batched results remain recoverable and deduplicable even when result text must be truncated.

Pipeline drops now carry structured kind: "pipeline-drop" evidence. A bounded English and Chinese fallback remains for older persisted runs, including negation handling to avoid false positives such as no items dropped.

Validation

Passed for the changed workflow surfaces:

• bun run typecheck;
• focused Biome lint checks for the modified workflow sources and tests;
• focused completion, rendering, prompt, narrator, and delivery tests: 45/45 passed;
• single and batch completion renderer coverage;
• separate user-visible projection and model-visible payload coverage;
• stable delivery-ID preservation under large batch truncation;
• malformed persisted projection fail-closed coverage;
• narrow-width rendering coverage;
• failed, uncertain, dropped-work, retained-worktree, and worktree-handoff summaries.

Existing Windows baseline failures

bun run check and bun run test do not currently complete successfully in this Windows checkout. To determine whether this PR introduced those failures, both commands and the relevant failing suites were reproduced in a completely clean main worktree at e34551d, using the same dependencies and Windows environment.

The comparison showed:

• bun run check reports the same 256 repository-wide CRLF formatting differences on clean main;
• bun run test reproduces the same Windows process, path-separator, and file-permission failures on clean main;
• the background-terminal manager suite has the same result on clean main and this branch: 10 passed, 6 failed, 4 skipped;
• the compared failure-focused suite has the same result on clean main and this branch: 42 passed, 6 failed;
• the full Node test process can remain alive after those failures because of retained Windows process handles.

These Windows baseline failures are tracked and being handled separately from this PR. They predate this branch and are reproducible without any of its changes.

The repository CI runs bun run check and bun run test on ubuntu-latest; the Ubuntu CI result remains the merge gate.

Impact

User-visible behavior: Successful workflow completions are compact by default. Full reports, diagnostics, and artifact paths remain available after expansion. Exceptional evidence remains visible while collapsed.

Model-visible context: The completion payload remains independent from the UI projection. Stable delivery IDs, recovery facts, and deduplication facts survive batch truncation.

Runtime/lifecycle: Completion, retry, persistence, recovery, sanitization, and delivery semantics remain unchanged. Structured pipeline-drop provenance is added so abnormal evidence does not depend only on diagnostic prose.

Persisted data: The display projection is bounded and versioned. Workflow logs may contain the optional backward-compatible kind: "pipeline-drop" field. Older persisted runs remain supported.

Compatibility/risk: The main risk is renderer behavior across single, batched, malformed, exceptional, and narrow-width completion states. These paths have focused regression coverage. No provider, model-selection, permission, or setup behavior changes.

[somewan820]

Issue #173 要求精简完成态 UI，同时保留模型上下文、持久化证据、恢复能力、异常证据和交付语义。静态审查覆盖完整 diff 及 completion projection、renderer、预算、交付、日志持久化和 worktree evidence 的直接上下文。

阻塞问题

本轮未发现阻塞问题。

已验证事实：

• extensions/workflows/completion-projection.ts:24-36 只生成一次紧凑完成摘要；extensions/workflows/index.ts:2381-2440 的 collapsed 路径不显示完整报告，因此普通成功态不会常驻 Run dir:、Log:、Agents: 或 Delivery id:。
• extensions/workflows/completion-projection.ts:67-102 保留失败、不确定、丢弃工作和 worktree/handoff 证据，并由 extensions/workflows/index.ts:2417-2436 显示。
• extensions/workflows/completion-projection.ts:104-169 保留展开态报告；extensions/workflows/prompt.ts:214-271 增加稳定 delivery facts，同时保留有界交付正文。
• extensions/workflows/index.ts:2387-2397 仍支持旧格式 details 回退；新增 display validator 失败时回到已清理的消息正文。

非阻塞简化建议

未发现有充分证据的简化项。新增层同时承担有界投影、异常证据优先级、旧格式兼容和 renderer 输入校验，直接消费者可追踪；不建议删除仍可达的安全、取消、清理或交付恢复逻辑。

未验证项与残余风险

• 本轮未运行 bun run check、bun run test 或真实 TUI smoke，因此没有测试通过结论。
• 仍需在已加载该 head 的真实 Pi/TUI 中验证单条、批量、极窄宽度以及失败/不确定完成态。
• 批量交付新增 manifest 也受 48 KiB transport 上限约束；固定事实超过上限时会显式失败并进入既有重试路径，极端数量或超长路径场景需要运行时验证其可观测性。

[somewan820]

P2 Should-Fix：extensions/workflows/prompt.ts:217、236 构造包含全部 pending delivery 的无界 JSON manifest，超过 48 KiB 会抛错；result-delivery.ts:37、101、109-136 会把整批重新入队，导致同一 oversized batch 永久失败并阻塞后续完成通知。completion-projection.ts 的 MAX_DISPLAY_ENTRIES 只限制 operator details，不限制 model delivery。请按 envelope 分块发送或设计有界 manifest，并增加跨越 transport limit 后最终成功投递的测试。静态审查，未运行测试。

[yxr-2025]

Addressed in fce1268.

The review identified a real transport-boundary issue: the completion delivery facts manifest was included in one unbounded message. A large batch could exceed the 48 KiB transport limit, causing the delivery callback to throw and the durable queue to re-enqueue the entire batch indefinitely.

The fix splits completion deliveries into bounded transport batches. Each chunk independently contains:

• a bounded model-facing delivery-facts manifest;
• the corresponding projected completion results;
• the matching operator-facing display entries.

Each run keeps its original stable delivery ID and remains covered by the existing per-run receipt and retry semantics. Oversized batches no longer block later completion notifications.

Added regression coverage verifies that 128 large completions are split into multiple payloads, every payload stays within 48 KiB, and every delivery ID appears in exactly one chunk.

Validation:

• focused completion batch tests: passed;
• focused workflow completion/rendering/delivery tests: 65 passed, 3 pre-existing Windows dashboard failures;
• bun run typecheck: passed;
• focused Biome checks: passed.

[tt-a1i]

按精确 head 05166b6 复核。上一轮无界 delivery manifest 已改为有界分块，方向正确；但当前分块实现会把每个完成项都立即作为单独消息发送，3 条输入稳定得到 3 个 [1,1,1] batch，128 条就会产生 128 次 pi.sendMessage(... triggerTurn: true)。这会把原本的批量完成通知退化为消息/turn 风暴，并且现有测试只断言 batches.length > 1，所以错误实现仍全绿。PR 当前也与 main 冲突；修正算法并同步 main 后再复核。

[tt-a1i]

[P1] 这个条件在每个新 batch 的第一项上必然成立，因此第一项立即被 push 并清空 current；后续永远无法与它合并。结果不是“接近 48 KiB 时分块”，而是每条 completion 一条 follow-up。请持续累积直到加入下一项会超限时才 flush；测试应断言小批次只有 1 个 batch，并为 128 项断言 batch 数显著小于 entry 数及每条 deliveryId 恰好一次。