Repository navigation
fix(tui): say work, not act, in the /statusline Mode hint - #7012
Conversation
/statusline describes the Mode item as "plan · act · operate", but the chip it turns on reads "work" in the footer, and codewhale-hq#6466 settles that user-facing text says Work. The setting value stays `agent`; only the hint text changes. Signed-off-by: Lstarsky0 <59827030+Lstarsky0@users.noreply.github.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d5c0248c37
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| pub fn hint(self) -> &'static str { | ||
| match self { | ||
| StatusItem::Mode => "plan · act · operate", | ||
| StatusItem::Mode => "plan · work · operate", |
There was a problem hiding this comment.
Localize the changed mode hint
When /statusline is opened under a locale whose mode names differ from English (for example Korean), StatusPickerView renders this zero-argument hint() directly at status_picker.rs:297, so the changed copy is always shown as English plan · work · operate instead of using the locale already stored on the view. Route this touched user-visible string through a typed MessageId, or compose it from the localized mode labels, so the terminology change reaches every locale.
AGENTS.md reference: crates/tui/AGENTS.md:L25-L26
Useful? React with 👍 / 👎.
|
🤖 This reply is from Claude Opus 5.5, an AI agent working on behalf of the Codewhale maintainers. It is posted through @Hmbown's account, but Hunter did not write it. Thank you @Lstarsky0. The — Written by Claude Opus 5.5 (AI agent) on behalf of the maintainers. |
The product names the modes Plan · Work · Operate (CURRENT_DECISIONS §21 places the Act->Work label fix in 0.10.2; #7012 already fixed the /statusline hint). The footer chip, mode name and description, hotbar action, settings error copy, `/hooks` help, `/context` and export output, and the matching locale strings still said Act. - AppMode::label() -> WORK, display_name() -> Work, description() -> Work mode. as_setting() stays "agent", and parse still accepts act/agent/work. - New AppMode::hook_label() keeps returning ACT/PLAN/OPERATE, and both hook call sites (mode-change and base hook context) use it, so DEEPSEEK_MODE and DEEPSEEK_PREVIOUS_MODE are byte-identical to before. The hook contract change is 0.11 work. - Locale packs: HomeYoloModeTip, AppModeYoloHint, ConfigHintDefaultMode, HomeAgentModeTip, HomePlanModeChecklistTip, KbAltJumpPlanAgentYolo, HotbarActionModeYoloName/Description (and hi's preset description) use each pack's existing ChipModeAct word. No keys renamed. - Golden fixtures that encode the label (diagnostics system/context dumps, stable-branches.json, export baselines) updated; existing assertions updated. No external consumer parses "ACT": codewhale-app canonicalizes act/work/agent alike, and the remaining label() uses are logs, diagnostics and receipts. - Left for a follow-up: command-contract CommandMode::display_name() still returns "Act" but has no callers. Drafted by DeepSeek-Flash (V4.1-Flash-1017) via Codewhale exec in a scratch export, reviewed hunk by hunk. Checks (local): cargo fmt --check OK; CI-form clippy -p codewhale-config -p codewhale-tui -p codewhale-localization --all-targets --all-features -D warnings clean; codewhale-config 800+9+1 passed, codewhale-localization 54 passed; dev-test tui (commands:: settings hooks shell:: export context_report session_acceptance hotbar contract app_mode mode conformance::) 3048 passed; tui-locale-parity PASS; product vocabulary OK; sync-changelog --check; check-versions; check-facts; runtime-contract budget PASS (55 at budget, measured on a binary rebuilt after the change). Refs #6466 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NBKbhx19BRbZtvWK8rVKjz
Both PRs merged with an unread Codex review finding. I merged them without reading the review thread; these are the follow-ups. #7022 (/statusline height, P2): the picker budgeted one footer row (rows + 7), but render_modal_footer wraps the action hints. In German at 80x24 the 60-column inner width wraps "Space umschalten … Enter speichern / Esc abbrechen" onto two rows, so Git branch was still hidden until you scrolled. The picker now builds its hints once, measures them with action_footer_lines at the popup's inner width (the width centered_modal_area will give it, minus border and padding) and budgets rows + 6 + footer rows. The hints array is reused by render_modal_footer. #7024 (settings choice rail, P2): the rail paints the last column of the choice rows, but each choice hitbox still spanned the full inner width, so hovering or clicking the paint-only rail selected (and live-previewed) the choice on that row. Hitboxes now give up that column when the rail is drawn, matching the label width. The third finding (#7012, P1: the /statusline mode hint shown in English) was already fixed: StatusItem::hint(locale) routes through MessageId::StatusPickerModeHint. Verified in a real TUI at 80x24 with an isolated HOME (CW/artifacts/approval-card-20261018/run-statusline-{de,en}.sh): - German, before (codewhale-after6): the list ends at "[ ] Workspace", footer on two rows - German, after: "[ ] Git branch" shown above the two footer rows - English, after: all 11 items and the one-row footer, as before The rail-hitbox change was checked by reading handle_mouse's use of last_choice_hitboxes; no mouse event was driven. Checks: - cargo test -p codewhale-tui --lib -- views:: config_view edit_theme settings status_picker statusline: 528 passed; 0 failed; 1 ignored - cargo clippy -p codewhale-tui --all-targets --all-features --locked with CI's flags: clean; cargo fmt --check: clean Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NBKbhx19BRbZtvWK8rVKjz
What and why
/statuslinedescribes the Mode item asplan · act · operate, but the chip it turns on readsworkin the footer. At 80×24, before:and the footer under it:
After:
#6466 sets the rule that user-facing text says Work while the stored value stays
agent. This hint isn't in that issue's list of places, so I'm noting it here. It's the only change; the rest of #6466 (theAppModelabels, toasts and the hookDEEPSEEK_MODEcontract) is untouched.Issue
Refs #6466 (partial: the /statusline hint only)
How I tested it
/statusline, with this change and with a build from before it. The rows above come from those screens.cargo fmt --all -- --check,cargo clippy -p codewhale-tui --all-targets --all-featureswith CI's flags, andcargo check -p codewhale-tui --all-targets: clean. Clippy also on 1.99, pluscargo +1.89.0 check -p codewhale-tui.cargo nextest run -p codewhale-tui --lib: 15326 passed, none failed.Checklist
maincargo fmt --allpasses, and tests cover new or changed behaviordocs/features.toml(cargo test -p codewhale-tui --test feature_registrychecks it) — n/a