tui-events-log — Workgraph live mirror

Metadata

Status	done
Assigned	`agent-875`
Agent identity	`f51439356729d112a6c404803d88015d5b44832c6c584c62b96732b63c2b0c7e`
Created	2026-04-27T21:45:18.720753703+00:00
Started	2026-04-27T21:50:16.842249726+00:00
Completed	2026-04-27T22:00:41.146817844+00:00
Tags	`eval-scheduled`
Tokens	2909000 in / 8943 out
Eval score	0.91
└ blocking impact	0.90
└ completeness	0.95
└ coordination overhead	0.85
└ correctness	0.95
└ downstream usability	0.90
└ efficiency	0.85
└ intent fidelity	0.94
└ style adherence	0.90

Description

Proposal for the 'events' log view (one of the 3 modes from tui-log-view-4). User-reported issue with current rendering:

 ⌁ Bash → wg show test-task-2 2>&1 | head -30 && echo "---" && wg show test-task-3 2>&1 | head -30
 ✓ Task: test-task-2 this ...

Two problems:

Tool call shows as ⌁ Bash (space between symbol and tool name) with no inline indication of its outcome
A separate ✓ Task: ... line gets emitted afterward that disrupts the line formatting of the output

Desired end state

Tool-call rendering becomes a single inline element with a leading status prefix:

Running: ⌁Bash → <command> (no space between ⌁ and Bash; ⌁ alone signals 'in flight')
Success: ✓⌁Bash → <command>
Failure: x⌁Bash → <command> (or whatever nicer single-char/symbol fits — user is flexible: 'whatever nice equivalent char there is for ✓ on failure')

And: drop the separate ✓ Task: ... line entirely. Status belongs on the tool line, not on its own row that breaks the visual grouping.

Notes

Same control logic for the success/failure prefix should apply to all tool kinds (Bash, Read, Edit, Write, etc.), not just Bash
Layout: tool line should remain single-line until the tool result arrives; updating in place (or appending the prefix) when the result lands
'x' is just a placeholder — feel free to use ✗ / ✘ / ! / 🚫 / etc. if it fits the existing TUI character palette better; pick something that visually pairs with ✓

Validation

In events mode: a successful Bash tool call renders as one line with ✓⌁Bash prefix after completion
A failed Bash tool call renders with the failure prefix on the same line
No standalone ✓ Task: ... line appears in events mode
In-progress tool calls show ⌁Bash (no leading status, signaling 'still running')
Same prefix logic applies to non-Bash tools (Read, Edit, Write, etc.) — verify with at least 2 tool kinds in a manual smoke
Other 2 view modes (high-level, raw-with-pretty-printing) unchanged
cargo build + cargo test pass with no regressions

## Description

Proposal for the 'events' log view (one of the 3 modes from `tui-log-view-4`). User-reported issue with current rendering:

```
 ⌁ Bash → wg show test-task-2 2>&1 | head -30 && echo "---" && wg show test-task-3 2>&1 | head -30
 ✓ Task: test-task-2 this ...
```

Two problems:
1. Tool call shows as `⌁ Bash` (space between symbol and tool name) with no inline indication of its outcome
2. A separate `✓ Task: ...` line gets emitted afterward that disrupts the line formatting of the output

## Desired end state

Tool-call rendering becomes a single inline element with a leading status prefix:
- **Running**: `⌁Bash → <command>` (no space between ⌁ and Bash; ⌁ alone signals 'in flight')
- **Success**: `✓⌁Bash → <command>`
- **Failure**: `x⌁Bash → <command>` (or whatever nicer single-char/symbol fits — user is flexible: 'whatever nice equivalent char there is for ✓ on failure')

And: **drop the separate `✓ Task: ...` line entirely**. Status belongs on the tool line, not on its own row that breaks the visual grouping.

## Notes

- Same control logic for the success/failure prefix should apply to all tool kinds (Bash, Read, Edit, Write, etc.), not just Bash
- Layout: tool line should remain single-line until the tool result arrives; updating in place (or appending the prefix) when the result lands
- 'x' is just a placeholder — feel free to use ✗ / ✘ / ! / 🚫 / etc. if it fits the existing TUI character palette better; pick something that visually pairs with ✓

## Validation

- [ ] In events mode: a successful Bash tool call renders as one line with ✓⌁Bash prefix after completion
- [ ] A failed Bash tool call renders with the failure prefix on the same line
- [ ] No standalone `✓ Task: ...` line appears in events mode
- [ ] In-progress tool calls show `⌁Bash` (no leading status, signaling 'still running')
- [ ] Same prefix logic applies to non-Bash tools (Read, Edit, Write, etc.) — verify with at least 2 tool kinds in a manual smoke
- [ ] Other 2 view modes (high-level, raw-with-pretty-printing) unchanged
- [ ] cargo build + cargo test pass with no regressions

Depends on

done .assign-tui-events-log

Required by

(none)

Log

2026-04-27T21:45:18.686204273+00:00 Task paused
2026-04-27T21:45:33.069969435+00:00 Task published
2026-04-27T21:46:14.075707790+00:00 Lightweight assignment: agent=Careful Programmer (f5143935), exec_mode=full, context_scope=task, reason=Careful Programmer is the only implementer role available; Careful tradeoff matches UI work requiring attention to formatting precision; proven track record (0.71 score, 133 tasks).
2026-04-27T21:46:15.186705586+00:00 Spawned by coordinator --executor claude --model opus
2026-04-27T21:46:24.897664875+00:00 Starting work on tui-events-log: inline status prefix on tool calls
2026-04-27T21:50:12.727901946+00:00 Task unclaimed: agent 'agent-872' (PID 3019751) process exited
2026-04-27T21:50:16.842254104+00:00 Spawned by coordinator --executor claude --model opus
2026-04-27T22:00:04.949722096+00:00 Implementation present in working tree from prior attempt; verified all 17 log_render tests pass including 6 new events-mode tests: test_events_mode_paired_success_collapses_to_single_inline_line, test_events_mode_paired_failure_uses_failure_prefix, test_events_mode_inflight_call_has_no_status_prefix, test_events_mode_prefix_logic_applies_to_non_bash_tools (Edit + Read), test_events_mode_folds_native_executor_embedded_result, test_events_mode_does_not_affect_other_view_modes. The 7 failing tests (5 spawn_task variants, 1 provenance_coverage, 1 test_legacy_coordinator_tab_is_always_muted) are pre-existing and reproduce on main per tui-log-view-4 logs. cargo build + install pass.
2026-04-27T22:00:33.912955639+00:00 Committed: 801cb6b9a — pushed to origin/wg/agent-872/tui-events-log
2026-04-27T22:00:41.146828304+00:00 Task pending eval (agent reported done; awaiting `.evaluate-*` to score)
2026-04-27T22:01:48.065098241+00:00 agent-872 re-spawn observation: task already in pending-eval, implementation committed (801cb6b9a) by prior attempt and verified by agent-875 — no work to redo. All 17 log_render tests including 6 new events-mode tests still pass on this binary; cargo install --path . refreshed the global wg. Exiting without duplicate wg done since the original wg done call already moved the task to pending-eval.
2026-04-27T22:03:31.271267106+00:00 PendingEval → Done (evaluator passed; downstream unblocks)