@qwen-code /triage

Thanks for the PR!

Template looks good ✓ — all required sections present, bilingual, linked to #4187.

On direction: clearly aligned. Issue #4187 explicitly calls for automated coverage of the rewind selector and handleRewindConfirm paths introduced in #4064. Test-only PR closing a known coverage gap — no direction concerns.

On approach: the scope matches the issue's acceptance criteria closely. The renderRewindHarness helper in AppContainer.test.tsx is a reasonable ~90-line reusable setup for exercising the orchestration branches, and the RewindSelector.test.tsx additions fill the remaining gaps (arrow-key navigation, isRestoring guard, legacy confirm cancel). Nothing feels over-scoped or speculative.

Moving on to code review and testing. 🔍

— Qwen Code · qwen3.7-max

2a. Code Review

Reviewed the diff against the source implementations of RewindSelector and handleRewindConfirm. The tests are well-aligned with the production code — every branch assertion I spot-checked maps correctly to the implementation logic.

RewindSelector.test.tsx — the new tests fill real gaps:

• Arrow-key navigation (up/down) in the pick list was previously untested (only Ctrl+P/N had coverage). New test covers this cleanly.
• isRestoring keypress guard — uses an unresolved Promise to hold the restoring state, then verifies Escape is blocked. Correct pattern.
• Legacy confirm cancel via n and Escape — parameterized test, both paths return to pick list. Matches the source handler's handleConfirmSelect(false) logic.
• "Never mind" option assertion added to the existing restore-options test.

AppContainer.test.tsx — the renderRewindHarness helper (~90 LOC) is a good reusable fixture. All 10 handleRewindConfirm test cases verified against the source:

• rewind(promptId, truncateHistory) flag logic correctly differs between modes
• The apiTruncateIndex < 0 compressed-turn check is tested with a deliberately-short apiHistory
• No-client fallback: conversation-only shows error, both-mode falls back to code-only with warning
• Outer try/catch: mocked getGeminiClient throwing is properly surfaced through addItem

No critical issues found. No AGENTS.md violations — follows existing test conventions (collocated .test.tsx, vi.mock/vi.spyOn, ink-testing-library).

2b. Test Execution

This is a test-only PR with no user-visible behavior changes, so tmux UI capture is N/A. Verification is the test suite itself:

$ cd packages/cli && npx vitest run src/ui/components/RewindSelector.test.tsx

 ✓ src/ui/components/RewindSelector.test.tsx (10 tests) 344ms

 Test Files  1 passed (1)
      Tests  10 passed (10)

$ cd packages/cli && npx vitest run src/ui/AppContainer.test.tsx

 ✓ src/ui/AppContainer.test.tsx (89 tests) 2510ms

 Test Files  1 passed (1)
      Tests  89 passed (89)

$ npm run typecheck

> @qwen-code/acp-bridge@0.17.1 typecheck
> tsc --noEmit

> @qwen-code/qwen-code@0.17.1 typecheck
> tsc --noEmit

> @qwen-code/qwen-code-core@0.17.1 typecheck
> tsc --noEmit

> @qwen-code/sdk@0.1.8 typecheck
> tsc --noEmit

> @qwen-code/webui@0.17.1 typecheck
> tsc --noEmit

All green. ✅

— Qwen Code · qwen3.7-max

This is a clean, well-scoped test coverage PR. It closes #4187 by adding regression tests for the two rewind surfaces from #4064 — RewindSelector (the 3-phase Ink component) and handleRewindConfirm (the ~140 LOC orchestration function).

What I liked:

• The renderRewindHarness helper is the right level of abstraction — it sets up all the mocks needed for the orchestration tests without over-engineering, and each test only overrides what it needs.
• Test coverage maps directly to the issue's acceptance criteria. Nothing is speculative; nothing is missing.
• The isRestoring keypress-guard test using an unresolved Promise to hold the restoring state is a clean pattern.

No concerns. The diff is test-only, follows existing conventions, and all 99 tests + typecheck pass.

Approving. ✅

— Qwen Code · qwen3.7-max

Runtime verification (real CLI in tmux + mutation testing)

Verdict: solid test-only PR — the new tests pass, are not flaky, have real teeth (they catch regressions in the production rewind code), and assert behavior that matches the real CLI. Recommend merge. One tiny optional follow-up below.

Since this is a test-only change (+453 lines, no production code), "verification" means three things beyond "does CI go green": do the tests actually exercise the code paths they claim (teeth), do they assert correct behavior, and are they stable. I checked all three.

Harness

• Branch 992537dc6, npm install (build + bundle), Node 22, Linux.
• vitest runs against source, so mutation testing needs no rebuild. The real-flow cross-check drives the actual qwen TUI under tmux (OpenAI-compatible auth → local mock server, isolated $HOME, a git workspace).

1. Tests pass and are stable

npx vitest run src/ui/components/RewindSelector.test.tsx src/ui/AppContainer.test.tsx → 99 passed (2 files). The new cases run (not skipped): 10 handleRewindConfirm cases + 4 RewindSelector cases. Ran the rewind suites 3× back-to-back — 32 passed each time, no flakiness (including the async Restoring... pending-guard test). tsc --noEmit on packages/cli passes; the cross-workspace tsc --build during install also passes.

2. The tests have teeth (mutation testing)

I injected a targeted bug into the production rewind code for each major branch and confirmed the matching test fails (genuine assertion failures, not compile errors), then reverted. A test that stays green under a real bug is vacuous coverage — none of these are.

6/6 mutations across both files were caught. The tests genuinely lock down the rewind orchestration and the selector's key handling.

3. The tests assert real behavior (tmux cross-check)

To make sure the assertions aren't internally-consistent-but-wrong, I drove the actual rewind flow in the real TUI (two prompts → /rewind) and compared the observable UI to the test assertions:

Every behavior the tests assert reproduces in the real CLI.

Minor (optional, non-blocking)

Of the 10 user-facing messages in handleRewindConfirm, 9 are asserted by the new tests. The only uncovered branch is No files needed to be restored. (file restore that changed nothing and failed nothing). Worth a one-line case if you want full message coverage, but not a merge blocker.

Conclusion

The PR does what it claims for #4187: it adds focused, non-flaky regression coverage for the rewind selector and the rewind-confirm orchestration, the coverage is real (mutation-proven), and it matches actual CLI behavior. Looks good to merge.