cleveragents/cleveragents-core

Fork 3

feat(tui): implement tool call expand states (5 modes) #1000

New issue

Open

opened 2026-03-17 01:10:00 +00:00 by brent.edwards · 5 comments

brent.edwards commented

2026-03-17 01:10:00 +00:00

Member

Metadata

Commit Message: feat(tui): implement tool call expand states (5 modes)
Branch: feature/m8-tui-tool-call-expand

Background

The TUI specification (§ Conversation Block Details > Tool Call States) defines a tools.expand setting that controls how tool call result blocks behave after a tool call completes or fails. Tool calls progress through a visual state machine (pending → completed/failed), and the expand behavior determines which completed tool calls automatically reveal their output content versus remaining collapsed.

Currently, no ToolCallBlock widget or expand-mode logic exists in the TUI codebase (src/cleveragents/tui/). The tool call infrastructure (routing, execution, state tracking) exists in src/cleveragents/tool/, but the TUI presentation layer for tool call results has not been implemented.

Expected Behavior

The tools.expand setting (type: choices, default: fail) must support 5 modes controlling auto-expand behavior on tool call completion:

Mode	Behavior
`never`	All tool calls remain collapsed after completion
`always`	All tool calls auto-expand on completion
`success`	Only successful tool calls auto-expand
`fail` (default)	Only failed tool calls auto-expand
`both`	Both successful and failed tool calls auto-expand

Visual states per the specification:

Pending: Tool name with ⌛ spinner and collapsed chevron (▶)
Completed (collapsed): Tool name with ✔ indicator and collapsed chevron (▶)
Completed (expanded): Tool name with ✔ indicator and open chevron (▼), result content visible
Failed: Tool name with ✗ failed indicator and collapsed chevron (▶)

Special rule: Tool calls with kind: "read" (e.g., file reads, directory listings) must never auto-expand regardless of the tools.expand setting, as they produce verbose output that would dominate the conversation.

Users must also be able to manually toggle any individual tool call block between collapsed and expanded states, regardless of the auto-expand setting.

Acceptance Criteria

A tools.expand setting exists with type choices, default fail, and values never / always / success / fail / both
Tool call blocks display the 4 visual states: pending, completed-collapsed, completed-expanded, and failed
never mode: all completed tool calls remain collapsed
always mode: all completed tool calls auto-expand
success mode: only successful completions auto-expand; failures remain collapsed
fail mode (default): only failed tool calls auto-expand; successes remain collapsed
both mode: both successful and failed tool calls auto-expand (equivalent to always but semantically distinct for future extension)
Tool calls with kind: "read" never auto-expand regardless of setting
Manual expand/collapse toggle works on any tool call block regardless of auto-expand setting
Setting change takes effect immediately for subsequent tool call completions (no restart required)

Subtasks

Define ToolExpandMode enum with 5 values (never, always, success, fail, both)
Register tools.expand in the TUI settings schema (type: choices, default: fail)
Implement ToolCallBlock widget with 4 visual states (pending, completed-collapsed, completed-expanded, failed)
Implement auto-expand logic that reads the tools.expand setting on tool call completion and applies the correct expand/collapse behavior
Implement kind: "read" suppression — tool calls with read kind bypass auto-expand
Implement manual expand/collapse toggle on tool call blocks (chevron click or keyboard)
Tests (Behave): Add scenarios for each of the 5 expand modes and the kind: "read" suppression rule
Tests (Robot): Add integration test verifying tool call blocks render correctly with expand settings
Verify coverage >= 97% via nox -s coverage_report
Run nox (all default sessions), fix any errors

Definition of Done

This issue is complete when:

All subtasks above are completed and checked off.
All 5 tools.expand modes behave as specified, including the kind: "read" suppression rule.
A Git commit is created where the first line of the commit message matches the Commit Message in Metadata exactly, followed by a blank line, then additional lines providing relevant details about the implementation.
The commit is pushed to the remote on the branch matching the Branch in Metadata exactly.
The commit is submitted as a pull request to master, reviewed, and merged before this issue is marked done.

## Metadata - **Commit Message**: `feat(tui): implement tool call expand states (5 modes)` - **Branch**: `feature/m8-tui-tool-call-expand` ## Background The TUI specification (§ Conversation Block Details > Tool Call States) defines a `tools.expand` setting that controls how tool call result blocks behave after a tool call completes or fails. Tool calls progress through a visual state machine (pending → completed/failed), and the expand behavior determines which completed tool calls automatically reveal their output content versus remaining collapsed. Currently, no `ToolCallBlock` widget or expand-mode logic exists in the TUI codebase (`src/cleveragents/tui/`). The tool call infrastructure (routing, execution, state tracking) exists in `src/cleveragents/tool/`, but the TUI presentation layer for tool call results has not been implemented. ## Expected Behavior The `tools.expand` setting (type: `choices`, default: `fail`) must support 5 modes controlling auto-expand behavior on tool call completion: | Mode | Behavior | |------|----------| | `never` | All tool calls remain collapsed after completion | | `always` | All tool calls auto-expand on completion | | `success` | Only successful tool calls auto-expand | | `fail` (default) | Only failed tool calls auto-expand | | `both` | Both successful and failed tool calls auto-expand | **Visual states per the specification:** - **Pending**: Tool name with ⌛ spinner and collapsed chevron (▶) - **Completed (collapsed)**: Tool name with ✔ indicator and collapsed chevron (▶) - **Completed (expanded)**: Tool name with ✔ indicator and open chevron (▼), result content visible - **Failed**: Tool name with ✗ failed indicator and collapsed chevron (▶) **Special rule**: Tool calls with `kind: "read"` (e.g., file reads, directory listings) must never auto-expand regardless of the `tools.expand` setting, as they produce verbose output that would dominate the conversation. Users must also be able to manually toggle any individual tool call block between collapsed and expanded states, regardless of the auto-expand setting. ## Acceptance Criteria - [x] A `tools.expand` setting exists with type `choices`, default `fail`, and values `never` / `always` / `success` / `fail` / `both` - [x] Tool call blocks display the 4 visual states: pending, completed-collapsed, completed-expanded, and failed - [x] `never` mode: all completed tool calls remain collapsed - [x] `always` mode: all completed tool calls auto-expand - [x] `success` mode: only successful completions auto-expand; failures remain collapsed - [x] `fail` mode (default): only failed tool calls auto-expand; successes remain collapsed - [x] `both` mode: both successful and failed tool calls auto-expand (equivalent to `always` but semantically distinct for future extension) - [x] Tool calls with `kind: "read"` never auto-expand regardless of setting - [x] Manual expand/collapse toggle works on any tool call block regardless of auto-expand setting - [x] Setting change takes effect immediately for subsequent tool call completions (no restart required) ## Subtasks - [x] Define `ToolExpandMode` enum with 5 values (`never`, `always`, `success`, `fail`, `both`) - [x] Register `tools.expand` in the TUI settings schema (type: choices, default: `fail`) - [x] Implement `ToolCallBlock` widget with 4 visual states (pending, completed-collapsed, completed-expanded, failed) - [x] Implement auto-expand logic that reads the `tools.expand` setting on tool call completion and applies the correct expand/collapse behavior - [x] Implement `kind: "read"` suppression — tool calls with read kind bypass auto-expand - [x] Implement manual expand/collapse toggle on tool call blocks (chevron click or keyboard) - [x] Tests (Behave): Add scenarios for each of the 5 expand modes and the `kind: "read"` suppression rule - [x] Tests (Robot): Add integration test verifying tool call blocks render correctly with expand settings - [x] Verify coverage >= 97% via `nox -s coverage_report` - [x] Run `nox` (all default sessions), fix any errors ## Definition of Done This issue is complete when: - All subtasks above are completed and checked off. - All 5 `tools.expand` modes behave as specified, including the `kind: "read"` suppression rule. - A Git commit is created where the **first line** of the commit message matches the Commit Message in Metadata exactly, followed by a blank line, then additional lines providing relevant details about the implementation. - The commit is pushed to the remote on the branch matching the **Branch** in Metadata exactly. - The commit is submitted as a **pull request** to `master`, reviewed, and **merged** before this issue is marked done.

brent.edwards added this to the v3.7.0 milestone

2026-03-17 01:11:43 +00:00

brent.edwards added the

labels

2026-03-17 01:11:43 +00:00

brent.edwards referenced this issue

2026-03-17 01:12:40 +00:00

feat(tui): track 22 untracked TUI spec requirements (settings, permissions, notifications, sessions) #926

freemo added the

Points

label

2026-03-17 18:31:37 +00:00

hurui200320 was assigned by freemo

2026-03-23 03:36:51 +00:00

hurui200320 added a new dependency

2026-03-31 04:12:15 +00:00

#868 Epic: TUI Interface, Modals and Persona System

hurui200320 added

and removed

labels

2026-03-31 04:15:33 +00:00

hurui200320 commented

2026-03-31 05:07:30 +00:00

Member

Implementation Notes

Design Decisions

Single-module approach: All tool call expand logic is consolidated in cleveragents.tui.widgets.tool_call_block. This module contains the ToolExpandMode enum, ToolCallState enum, ToolCallSetting schema descriptor, should_auto_expand() decision function, and the ToolCallBlock presentation model. This keeps the feature self-contained and follows the project's modular design principle (files under 500 lines — this module is ~287 lines).

Framework-agnostic model: ToolCallBlock is a @dataclass presentation model rather than a Textual widget subclass. This follows the existing pattern used by other TUI widgets (e.g., PersonaBar, PromptInput) where the Textual base class is loaded dynamically via importlib. The model handles all state transitions and expand logic without depending on Textual, making it fully testable without mocking the Textual framework.

State machine design: The visual state machine uses 4 states per the specification:

PENDING → initial state (⌛ spinner, ▶ chevron)
COMPLETED_COLLAPSED → success, not expanded (✔, ▶)
COMPLETED_EXPANDED → success or failure, expanded (✔ or ✗, ▼)
FAILED → failure, not expanded (✗ failed, ▶)

Transitions occur via complete(), fail(), and toggle() methods. The complete/fail methods accept the current expand_mode setting so the auto-expand decision is made at transition time. The toggle() method allows post-hoc manual override regardless of the auto-expand setting.

should_auto_expand() as standalone function: Extracted the expand decision logic into a pure function for testability and reuse. It receives mode, succeeded, and tool_kind parameters and returns a boolean. The kind: "read" suppression is the first check — it short-circuits before any mode evaluation.

Key Code Locations

ToolExpandMode: cleveragents.tui.widgets.tool_call_block.ToolExpandMode — 5-value StrEnum
ToolCallState: cleveragents.tui.widgets.tool_call_block.ToolCallState — 4-value StrEnum
ToolCallSetting: cleveragents.tui.widgets.tool_call_block.ToolCallSetting — frozen dataclass schema descriptor (key=tools.expand, type=choices, default=fail)
should_auto_expand(): cleveragents.tui.widgets.tool_call_block.should_auto_expand — pure decision function
ToolCallBlock: cleveragents.tui.widgets.tool_call_block.ToolCallBlock — presentation model with complete(), fail(), toggle(), and rendering methods

Argument Validation

All public methods perform strict argument validation as the first guard per CONTRIBUTING.md "Error and Exception Handling":

should_auto_expand(): validates mode (ToolExpandMode), succeeded (bool), tool_kind (str) types
ToolCallBlock.complete(): validates result (str), expand_mode (ToolExpandMode), and state (must be PENDING)
ToolCallBlock.fail(): validates error (str), expand_mode (ToolExpandMode), and state (must be PENDING)
ToolCallBlock.toggle(): validates state is not PENDING

Test Results

Behave (unit): 38 scenarios, 115 steps — all pass. Coverage of tool_call_block.py is 100%.
Robot (integration): 3 test cases — all pass. Tests exercise the full lifecycle, all 5 expand modes, kind:read suppression, and rendering output.
Overall coverage: 97% (no regression from baseline)
Lint: All checks pass (ruff)
Typecheck: 0 errors, 0 warnings (Pyright)
Unit tests (full suite): 509 features, 13023 scenarios — all pass
Integration tests (full suite): 1852 tests — all pass

## Implementation Notes ### Design Decisions **Single-module approach:** All tool call expand logic is consolidated in `cleveragents.tui.widgets.tool_call_block`. This module contains the `ToolExpandMode` enum, `ToolCallState` enum, `ToolCallSetting` schema descriptor, `should_auto_expand()` decision function, and the `ToolCallBlock` presentation model. This keeps the feature self-contained and follows the project's modular design principle (files under 500 lines — this module is ~287 lines). **Framework-agnostic model:** `ToolCallBlock` is a `@dataclass` presentation model rather than a Textual widget subclass. This follows the existing pattern used by other TUI widgets (e.g., `PersonaBar`, `PromptInput`) where the Textual base class is loaded dynamically via `importlib`. The model handles all state transitions and expand logic without depending on Textual, making it fully testable without mocking the Textual framework. **State machine design:** The visual state machine uses 4 states per the specification: - `PENDING` → initial state (⌛ spinner, ▶ chevron) - `COMPLETED_COLLAPSED` → success, not expanded (✔, ▶) - `COMPLETED_EXPANDED` → success or failure, expanded (✔ or ✗, ▼) - `FAILED` → failure, not expanded (✗ failed, ▶) Transitions occur via `complete()`, `fail()`, and `toggle()` methods. The `complete`/`fail` methods accept the current `expand_mode` setting so the auto-expand decision is made at transition time. The `toggle()` method allows post-hoc manual override regardless of the auto-expand setting. **`should_auto_expand()` as standalone function:** Extracted the expand decision logic into a pure function for testability and reuse. It receives mode, succeeded, and tool_kind parameters and returns a boolean. The `kind: "read"` suppression is the first check — it short-circuits before any mode evaluation. ### Key Code Locations - **`ToolExpandMode`**: `cleveragents.tui.widgets.tool_call_block.ToolExpandMode` — 5-value StrEnum - **`ToolCallState`**: `cleveragents.tui.widgets.tool_call_block.ToolCallState` — 4-value StrEnum - **`ToolCallSetting`**: `cleveragents.tui.widgets.tool_call_block.ToolCallSetting` — frozen dataclass schema descriptor (key=`tools.expand`, type=`choices`, default=`fail`) - **`should_auto_expand()`**: `cleveragents.tui.widgets.tool_call_block.should_auto_expand` — pure decision function - **`ToolCallBlock`**: `cleveragents.tui.widgets.tool_call_block.ToolCallBlock` — presentation model with `complete()`, `fail()`, `toggle()`, and rendering methods ### Argument Validation All public methods perform strict argument validation as the first guard per `CONTRIBUTING.md` "Error and Exception Handling": - `should_auto_expand()`: validates mode (ToolExpandMode), succeeded (bool), tool_kind (str) types - `ToolCallBlock.complete()`: validates result (str), expand_mode (ToolExpandMode), and state (must be PENDING) - `ToolCallBlock.fail()`: validates error (str), expand_mode (ToolExpandMode), and state (must be PENDING) - `ToolCallBlock.toggle()`: validates state is not PENDING ### Test Results - **Behave (unit):** 38 scenarios, 115 steps — all pass. Coverage of `tool_call_block.py` is 100%. - **Robot (integration):** 3 test cases — all pass. Tests exercise the full lifecycle, all 5 expand modes, kind:read suppression, and rendering output. - **Overall coverage:** 97% (no regression from baseline) - **Lint:** All checks pass (ruff) - **Typecheck:** 0 errors, 0 warnings (Pyright) - **Unit tests (full suite):** 509 features, 13023 scenarios — all pass - **Integration tests (full suite):** 1852 tests — all pass

hurui200320 referenced this issue from a commit

2026-03-31 05:08:10 +00:00

feat(tui): implement tool call expand states (5 modes)

hurui200320 referenced this issue from a pull request that will close it,

2026-03-31 05:08:31 +00:00

feat(tui): implement tool call expand states (5 modes) #1219

hurui200320 added

and removed

labels

2026-03-31 05:09:46 +00:00

hurui200320 added a new dependency

2026-03-31 05:43:07 +00:00

#1219 feat(tui): implement tool call expand states (5 modes)

hurui200320 referenced this issue from a commit

2026-03-31 07:26:59 +00:00

feat(tui): implement tool call expand states (5 modes)

hurui200320 referenced this issue from a commit

2026-03-31 08:22:48 +00:00

feat(tui): implement tool call expand states (5 modes)

hurui200320 referenced this issue from a commit

2026-03-31 09:36:23 +00:00

feat(tui): implement tool call expand states (5 modes)

hurui200320 commented

2026-03-31 09:49:30 +00:00

Member

Self-QA Implementation Notes (Cycles 1–4)

PR !1219 underwent 4 automated review/fix cycles before approval. Below is the complete development journal.

Cycle 1 — Critical bug fix

Review findings: 1C/5M/7m/4n

Critical: Failed tool calls that auto-expand display success indicator (✔) instead of failure indicator (✗ failed). The 4-state enum conflated success-expanded and failure-expanded into a single COMPLETED_EXPANDED state.
Major: FAILED state permanently lost after toggle cycle; tests don't assert indicator after failure auto-expand; no multi-toggle scenario; _manually_toggled is dead code; no case-sensitivity test for kind: "read".
Minor/Nit: No is_failed property; standalone ToolCallSetting descriptor; empty content visual inconsistency; unbounded result_content; Rich markup injection risk; partial read-suppression coverage; Robot tests duplicate Behave.

Fixes applied (10):

Added _succeeded: bool | None field to ToolCallBlock to track outcome independently of visual state. The indicator property now checks _succeeded instead of ToolCallState.
Removed dead _manually_toggled field.
Added is_failed read-only property for programmatic success/error distinction.
Changed render() to always show content area when expanded (even if empty).
Added indicator assertions to failure auto-expand and toggle scenarios.
Added multi-toggle scenarios for both failed and successful blocks.
Added 3 case-sensitivity scenarios ("Read", "READ", "read ").
Added 6 missing read-suppression mode×outcome combinations.
Added *** Variables *** fallback for Robot test ${PYTHON}.

Deferred: Settings registry (no infrastructure), unbounded content (caller responsibility), Rich injection (no Textual layer yet), Robot test duplication (no integration layer yet).

Cycle 2 — Test coverage hardening

Review findings: 0C/3M/11m/5n

Major: No test verifies error content in rendered output of expanded failed blocks; missing fail→complete and fail→fail error-path scenarios; inconsistent assertion depth (5 mode scenarios lack indicator/chevron assertions).
Minor: Toggle lossy (never restores FAILED state); _succeeded exposed in constructor; indicator returns ✔ when _succeeded is None; __all__ unsorted; missing 10th read-suppression combo; no toggle round-trip; failure indicator checks only text not ✗ symbol; no empty string edge cases; missing TODO comments.

Fixes applied (15):

Added render test for failed error content.
Added fail→complete and fail→fail ValueError scenarios.
Added indicator + chevron assertions to all 5 mode scenarios that were missing them.
Changed _succeeded to field(init=False) to prevent constructor bypass.
Fixed toggle() to restore FAILED state when collapsing a failed expanded block.
Added defensive _succeeded is None guard in indicator property.
Added ✗ (U+2717) symbol assertion to failure indicator step.
Added missing 10th read-suppression combination.
Extended toggle round-trip test.
Added empty string edge case tests for complete(result="") and fail(error="").
Added render-after-toggle scenario.
Added 3 TODO tracking comments for deferred items.
Added inline BOTH/ALWAYS equivalence comment.
Added spec interpretation comment for "Failed (expanded)" state.

Cycle 3 — Process compliance

Review findings: 0C/2M/13m/7n

Major: Missing CHANGELOG.md entry (documented merge blocker); Robot test not using common.resource (risks parallel test execution).
Minor: Implicit FAIL mode fall-through; __all__ ordering; no feature-level tags; no thread-safety documentation; no Robot test tags; inaccurate scenario count in commit.

Fixes applied (8):

Added CHANGELOG.md entry under ## Unreleased referencing (#1000).
Refactored Robot test to use Resource ${CURDIR}/common.resource with proper Suite Setup/Teardown.
Added explicit ToolExpandMode.FAIL check with exhaustiveness ValueError guard.
Added @tui @tool_call_block feature-level tags to Behave feature.
Added thread-safety note to ToolCallBlock class docstring.
Added [Tags] tui tool_call_block to all 3 Robot test cases.
Corrected scenario count in commit body (38 → 60).
Confirmed __all__ ordering follows ruff RUF022 convention (already correct).

Cycle 4 — Final review → APPROVED ✅

Review findings: 0C/0M/8m/5n

All remaining findings are defensive improvements (exhaustiveness guards for untested branches, tests for unreachable code paths) or acknowledged deferrals with proper TODO tracking. No functional bugs, no spec violations.

Remaining Issues (all minor/nit, non-blocking)

ToolCallSetting is a schema descriptor only, not functionally registered (no settings infrastructure exists yet).
toggle() lacks exhaustiveness guard for future state additions (acceptable for 4-member enum).
Defensive _succeeded is None indicator guard is untested (intentionally unreachable via public API).
should_auto_expand() ValueError exhaustiveness guard is untested (unreachable with current 5 enum members).

Quality Gates (final)

Gate	Result
Lint	✅ Pass
Typecheck	✅ Pass (0 errors)
Unit tests	✅ Pass (60 Behave scenarios)
Integration tests	✅ Pass (1852 tests)
E2E tests	✅ Pass (63 tests)
Coverage	✅ Pass (97% overall, tool_call_block.py 99%)

## Self-QA Implementation Notes (Cycles 1–4) PR !1219 underwent 4 automated review/fix cycles before approval. Below is the complete development journal. --- ### Cycle 1 — Critical bug fix **Review findings:** 1C/5M/7m/4n - **Critical:** Failed tool calls that auto-expand display success indicator (✔) instead of failure indicator (✗ failed). The 4-state enum conflated success-expanded and failure-expanded into a single `COMPLETED_EXPANDED` state. - **Major:** FAILED state permanently lost after toggle cycle; tests don't assert indicator after failure auto-expand; no multi-toggle scenario; `_manually_toggled` is dead code; no case-sensitivity test for `kind: "read"`. - **Minor/Nit:** No `is_failed` property; standalone `ToolCallSetting` descriptor; empty content visual inconsistency; unbounded `result_content`; Rich markup injection risk; partial read-suppression coverage; Robot tests duplicate Behave. **Fixes applied (10):** - Added `_succeeded: bool | None` field to `ToolCallBlock` to track outcome independently of visual state. The `indicator` property now checks `_succeeded` instead of `ToolCallState`. - Removed dead `_manually_toggled` field. - Added `is_failed` read-only property for programmatic success/error distinction. - Changed `render()` to always show content area when expanded (even if empty). - Added indicator assertions to failure auto-expand and toggle scenarios. - Added multi-toggle scenarios for both failed and successful blocks. - Added 3 case-sensitivity scenarios (`"Read"`, `"READ"`, `"read "`). - Added 6 missing read-suppression mode×outcome combinations. - Added `*** Variables ***` fallback for Robot test `${PYTHON}`. **Deferred:** Settings registry (no infrastructure), unbounded content (caller responsibility), Rich injection (no Textual layer yet), Robot test duplication (no integration layer yet). --- ### Cycle 2 — Test coverage hardening **Review findings:** 0C/3M/11m/5n - **Major:** No test verifies error content in rendered output of expanded failed blocks; missing fail→complete and fail→fail error-path scenarios; inconsistent assertion depth (5 mode scenarios lack indicator/chevron assertions). - **Minor:** Toggle lossy (never restores FAILED state); `_succeeded` exposed in constructor; indicator returns ✔ when `_succeeded` is None; `__all__` unsorted; missing 10th read-suppression combo; no toggle round-trip; failure indicator checks only text not ✗ symbol; no empty string edge cases; missing TODO comments. **Fixes applied (15):** - Added render test for failed error content. - Added fail→complete and fail→fail ValueError scenarios. - Added indicator + chevron assertions to all 5 mode scenarios that were missing them. - Changed `_succeeded` to `field(init=False)` to prevent constructor bypass. - Fixed `toggle()` to restore `FAILED` state when collapsing a failed expanded block. - Added defensive `_succeeded is None` guard in `indicator` property. - Added ✗ (U+2717) symbol assertion to failure indicator step. - Added missing 10th read-suppression combination. - Extended toggle round-trip test. - Added empty string edge case tests for `complete(result="")` and `fail(error="")`. - Added render-after-toggle scenario. - Added 3 TODO tracking comments for deferred items. - Added inline BOTH/ALWAYS equivalence comment. - Added spec interpretation comment for "Failed (expanded)" state. --- ### Cycle 3 — Process compliance **Review findings:** 0C/2M/13m/7n - **Major:** Missing CHANGELOG.md entry (documented merge blocker); Robot test not using `common.resource` (risks parallel test execution). - **Minor:** Implicit FAIL mode fall-through; `__all__` ordering; no feature-level tags; no thread-safety documentation; no Robot test tags; inaccurate scenario count in commit. **Fixes applied (8):** - Added CHANGELOG.md entry under `## Unreleased` referencing (#1000). - Refactored Robot test to use `Resource ${CURDIR}/common.resource` with proper Suite Setup/Teardown. - Added explicit `ToolExpandMode.FAIL` check with exhaustiveness `ValueError` guard. - Added `@tui @tool_call_block` feature-level tags to Behave feature. - Added thread-safety note to `ToolCallBlock` class docstring. - Added `[Tags] tui tool_call_block` to all 3 Robot test cases. - Corrected scenario count in commit body (38 → 60). - Confirmed `__all__` ordering follows ruff `RUF022` convention (already correct). --- ### Cycle 4 — Final review → APPROVED ✅ **Review findings:** 0C/0M/8m/5n - All remaining findings are defensive improvements (exhaustiveness guards for untested branches, tests for unreachable code paths) or acknowledged deferrals with proper TODO tracking. No functional bugs, no spec violations. ### Remaining Issues (all minor/nit, non-blocking) - `ToolCallSetting` is a schema descriptor only, not functionally registered (no settings infrastructure exists yet). - `toggle()` lacks exhaustiveness guard for future state additions (acceptable for 4-member enum). - Defensive `_succeeded is None` indicator guard is untested (intentionally unreachable via public API). - `should_auto_expand()` ValueError exhaustiveness guard is untested (unreachable with current 5 enum members). ### Quality Gates (final) | Gate | Result | |------|--------| | Lint | ✅ Pass | | Typecheck | ✅ Pass (0 errors) | | Unit tests | ✅ Pass (60 Behave scenarios) | | Integration tests | ✅ Pass (1852 tests) | | E2E tests | ✅ Pass (63 tests) | | Coverage | ✅ Pass (97% overall, tool_call_block.py 99%) |

hurui200320 was unassigned by freemo

2026-04-02 06:14:02 +00:00

freemo self-assigned this

2026-04-02 06:14:02 +00:00

freemo commented

2026-04-02 07:17:55 +00:00

Owner

PR #1219 Review Complete — Approved, Merge Blocked by Conflicts

PR #1219 has been code-reviewed and approved. The implementation correctly satisfies all acceptance criteria:

✅ All 5 tools.expand modes (never, always, success, fail, both)
✅ 4 visual states with correct state machine transitions
✅ kind: "read" suppression rule
✅ Manual toggle with round-trip preservation
✅ 60 Behave scenarios + 3 Robot integration tests
✅ Full static typing, no # type: ignore in production code
✅ Clean code quality, proper error handling

⚠️ However, the PR cannot be merged due to merge conflicts in src/cleveragents/tui/widgets/__init__.py (missing HelpPanelOverlay import from recently-merged help panel PR) and CHANGELOG.md. The branch needs to be rebased onto current master and the conflicts resolved before merge can proceed.

Once rebased and CI passes, the PR is ready to merge.

## PR #1219 Review Complete — Approved, Merge Blocked by Conflicts PR #1219 has been **code-reviewed and approved**. The implementation correctly satisfies all acceptance criteria: - ✅ All 5 `tools.expand` modes (`never`, `always`, `success`, `fail`, `both`) - ✅ 4 visual states with correct state machine transitions - ✅ `kind: "read"` suppression rule - ✅ Manual toggle with round-trip preservation - ✅ 60 Behave scenarios + 3 Robot integration tests - ✅ Full static typing, no `# type: ignore` in production code - ✅ Clean code quality, proper error handling **⚠️ However, the PR cannot be merged due to merge conflicts** in `src/cleveragents/tui/widgets/__init__.py` (missing `HelpPanelOverlay` import from recently-merged help panel PR) and `CHANGELOG.md`. The branch needs to be rebased onto current `master` and the conflicts resolved before merge can proceed. Once rebased and CI passes, the PR is ready to merge.

freemo referenced this issue from a commit

2026-04-02 08:24:35 +00:00

feat(tui): implement tool call expand states (5 modes)

freemo commented

2026-04-02 08:29:50 +00:00

Owner

PR #1219 reviewed, approved, and merged.

The ToolCallBlock presentation model with 5 expand modes (never, always, success, fail, both), 4 visual states, kind: "read" suppression, and manual toggle is now on master. All 60 Behave scenarios and 3 Robot integration tests pass. Coverage at 97%+ (tool_call_block.py at 99%).

PR #1219 reviewed, approved, and merged. The `ToolCallBlock` presentation model with 5 expand modes (`never`, `always`, `success`, `fail`, `both`), 4 visual states, `kind: "read"` suppression, and manual toggle is now on `master`. All 60 Behave scenarios and 3 Robot integration tests pass. Coverage at 97%+ (tool_call_block.py at 99%).

freemo referenced this issue

2026-04-02 16:20:19 +00:00

[Automated] Product Build Session State #1314

freemo referenced this issue

2026-04-02 16:21:57 +00:00

feat(tui): implement tool call expand states (5 modes) #1219

freemo referenced this issue

2026-04-02 16:42:01 +00:00

[Automated] Product Build Session State #1314

freemo referenced this issue

2026-04-02 16:49:07 +00:00

[Automated] Product Build Session State #1314

freemo referenced this issue

2026-04-02 16:49:54 +00:00

fix(agents): prevent backlog groomer from closing PRs as duplicates of their tracking issues #1325

freemo commented

2026-04-02 16:52:26 +00:00

Owner

[Backlog Groomer - groomer-1] ⚠️ PR state inconsistency detected. PR #1219 (feat(tui): implement tool call expand states (5 modes)) was closed without merging at 2026-04-02T16:22:15Z. The issue remains open with State/In Review but has no active open PR. All acceptance criteria are checked off in the issue body. Please verify: either create a new PR or close this issue if the work was completed via another mechanism.

**[Backlog Groomer - groomer-1]** ⚠️ **PR state inconsistency detected.** PR #1219 (`feat(tui): implement tool call expand states (5 modes)`) was **closed without merging** at 2026-04-02T16:22:15Z. The issue remains open with `State/In Review` but has no active open PR. All acceptance criteria are checked off in the issue body. Please verify: either create a new PR or close this issue if the work was completed via another mechanism.

freemo referenced this issue

2026-04-02 16:53:37 +00:00

[Automated] Product Build Session State #1314

freemo referenced this issue

2026-04-02 23:24:09 +00:00

[Automated] Backlog Groomer Session State — v3.7.0 #1463

freemo removed the

labels