fix(cli): handle /new in the TUI chat surfaces (closes #6265)#6284
Merged
Conversation
`/new` was unhandled in both terminal-UI slash dispatchers, so it fell through to "unknown command":
- `librefang tui` chat tab (`tui/mod.rs::handle_slash_command`) had no `/new` arm.
- `librefang chat` (`tui/chat_runner.rs::handle_slash_command`) gates every command on the central registry returning a def whose scope contains `Scope::CLI`, but `/new` was registered `Scope::CHANNEL`-only.
The dashboard and channel surfaces already handle `/new`; only the TUI was broken.
`/new` now resets the agent's backend session and clears the local transcript — matching the shared command registry's contract ("Reset session (clear messages)") and the channel behavior (#4868), and distinct from `/clear`, which only wipes the on-screen transcript. The registry scope is widened to `Scope::CHANNEL | Scope::CLI` so the chat_runner gate admits it; the existing description fits both surfaces unchanged. Daemon backends POST to `/api/agents/{id}/session/reset`; in-process backends call `kernel.reset_session(.., ResetScope::Agent)` on a scoped runtime (the TUI main thread is not itself on a tokio runtime, so a `block_on` is safe). Adds the en/uk/zh-CN strings and a registry regression test.
CI's rustfmt wraps the long assert!-with-message form while the local toolchain keeps it on one line; short message-less asserts are formatted identically by every version, so the fmt lane stops flapping. The doc comment carries the #6265 rationale.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Closes #6265.
/newprinted "unknown command" in both terminal-UI chat surfaces:librefang tuichat tab (tui/mod.rs::handle_slash_command) had no/newarm.librefang chat(tui/chat_runner.rs::handle_slash_command) gates every command on the central registry returning a def whose scope containsScope::CLI, but/newwas registeredScope::CHANNEL-only.The dashboard (
ws.rs→create_agent_session) and channels (bridge.rs, #4868) already handle/new; only the TUI was broken.Fix
/newnow resets the agent's backend session and clears the local transcript.Why reset, not create
My triage comment floated aligning with the dashboard's create-new-session semantics. On implementation I went with reset instead, for two concrete reasons:
agent_idand never tracks an explicit session id, socreate_agent_sessionwould mint a session the TUI does not switch to — an orphan.reset_session(ResetScope::Agent)actually affects the conversation the user is in (a real "start fresh")./newas "Reset session (clear messages)" and channels implement exactly that (Channel/newwipes ALL agent sessions, not just the channel-derived one #4868). Reset keeps the CLI surface consistent with the registry contract it consults, and is distinct from/clear, which only wipes the on-screen transcript without touching the backend session.The pre-existing dashboard divergence (its
/newcreates) is out of scope here; unifying all three surfaces is a separate decision (noted on the issue).Changes
librefang-channels/src/commands/mod.rs— widen/newscope toScope::CHANNEL | Scope::CLIso thechat_runnergate admits it; description unchanged (already fits both). Adds a registry regression test.tui/chat_runner.rs+tui/mod.rs—/newarms: daemon backends POST/api/agents/{id}/session/reset; in-process backends callkernel.reset_session(.., ResetScope::Agent)on a scoped runtime (the TUI main thread is not on a tokio runtime, soblock_onis safe). Both clear the local view + confirm.tui/mod.rsalso gains a/helpline.locales/{en,uk,zh-CN}/main.ftl— the five new strings, parity-complete.Verification
cargo check -p librefang-cli -p librefang-channels— clean (Docker dev image).cargo test -p librefang-channels --lib commands::tests::new_command_is_reachable_from_cli_and_channel— pass.cargo test -p librefang-cli --test i18n_checks— 3/3 pass (no_dead_locale_keys,locales_cover_used_i18n_keys,no_untranslated_strings), so locale parity holds.