feat(ui): add debug-log visibility toggle for chat

[LiusCraft]

Summary

• add a new show_debug_logs setting (persisted in local app settings) and expose it in the Settings panel under 会话显示
• classify System/Client/Tool/Trace entries as debug logs, and filter them from the chat stream when the toggle is off
• default debug-log visibility to off for new users, while keeping the switch configurable at runtime

Validation

• cargo test -p host-app-gpui

[opencode-agent]

Code Review Summary

Correctness ✓

• The filtering logic correctly hides System/Client/Tool/Trace messages when show_debug_logs is false
• State management follows the existing draft/apply pattern correctly
• Persistence correctly defaults to false for new users

Code Quality Issues

1. Inefficient double iteration (panel.rs:105-118):

   let filtered_messages = self.chat_messages.iter()...collect();
   let hidden_debug_message_count = self.chat_messages.len().saturating_sub(filtered_messages.len());

   The messages are iterated twice. Could be done in one pass with a fold or by counting during filtering.

2. Missing tests: No test coverage for the debug log filtering logic or the toggle functionality.

Edge Cases

• ✓ Empty message list handled correctly
• ✓ None in persisted settings defaults to false
• ⚠️ Consider: Does "follow latest" work correctly with filtered messages? (it does - total_messages uses filtered count)

Minor Suggestions

• ChatRole::is_debug_log() could be const since it's a simple match
• The Chinese text in settings panel could be more explicit about what "DEBUG 日志" means

Verdict

Approve - Functionally correct implementation. The double iteration is a minor optimization opportunity but not a regression risk. Missing tests should be addressed before merge.

opencode session  |  github run

[github-actions]

Based on my review, the PR is functionally correct. The implementation:

1. Correctly filters System/Client/Tool/Trace messages when show_debug_logs is false
2. Properly persists the setting with correct default (false for new users)
3. Follows the draft/apply pattern for state management
4. Renders correctly - the message_index passed to render functions refers to the original array, which is correct since the active message tracking operates on the original unfiltered array

The earlier review mentioned a double iteration inefficiency in panel.rs:103-112, but this is a minor optimization opportunity, not a correctness bug.

No issues found that meet the high-confidence, actionable threshold.

opencode session  |  github run