fix: Add missing CLI modules and fix rustfmt #684
Conversation
- Add wezterm/src/cli/new.rs (stub for project templates) - Add wezterm/src/cli/snapshot.rs (stub for workspace snapshots) - Fix rustfmt formatting in telemetry/panel.rs These modules were declared in mod.rs but files were missing, causing build failures. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Summary of ChangesHello @mikejmorgan-ai, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request resolves critical build failures on the main branch by supplying the necessary, albeit currently unimplemented, CLI module files for project creation and workspace snapshot management. Additionally, it ensures code consistency by addressing and fixing existing Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Pull request overview
This PR fixes build failures on the main branch by adding missing CLI module files and correcting rustfmt violations. The modules were declared in mod.rs but the corresponding implementation files were missing, causing compiler errors.
Changes:
- Added stub implementations for
new.rsandsnapshot.rsCLI modules - Fixed formatting violations in telemetry panel by splitting multi-line function calls
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| wezterm/src/cli/snapshot.rs | Adds stub implementation for workspace snapshot management commands |
| wezterm/src/cli/new.rs | Adds stub implementation for project template creation command |
| wezterm-gui/src/termwindow/telemetry/panel.rs | Fixes rustfmt violations by properly formatting Element::new() calls |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| @@ -0,0 +1,57 @@ | |||
| //! CX Terminal: Workspace snapshot management | |||
There was a problem hiding this comment.
The comment references 'CX Terminal' but this appears to be a WezTerm codebase. This naming inconsistency should be corrected throughout the file to reference 'WezTerm' instead.
| @@ -0,0 +1,28 @@ | |||
| //! CX Terminal: Create new projects from templates | |||
There was a problem hiding this comment.
The comment references 'CX Terminal' but this appears to be a WezTerm codebase. This naming inconsistency should be corrected throughout the file to reference 'WezTerm' instead.
|
|
||
| impl SaveCommand { | ||
| pub fn run(&self) -> anyhow::Result<()> { | ||
| eprintln!("CX Terminal: 'save' command is not yet implemented."); |
There was a problem hiding this comment.
The error message references 'CX Terminal' but should reference 'WezTerm' for consistency with the codebase. This occurs in multiple error messages throughout the file.
| eprintln!( | ||
| "CX Terminal: 'new' command is not yet implemented. Template: {}", | ||
| self.template | ||
| ); |
There was a problem hiding this comment.
The error message references 'CX Terminal' but should reference 'WezTerm' for consistency with the codebase.
|
Caution Review failedThe pull request is closed. 📝 WalkthroughWalkthroughAdds placeholder CLI commands for project scaffolding and workspace snapshots, reformats telemetry UI construction and reorders telemetry modules, renames many CI build targets from wezterm* to cx-terminal*, adds a macOS Info.plist, expands CI apt packages, and declares new binary entries for wezterm and wezterm-gui. Most edits are formatting, wiring, or placeholders. Changes
Sequence Diagram(s)(Skipped — changes are primarily formatting, placeholders, CI renames, and metadata additions; no new multi-component control flow requiring visualization.) Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request successfully addresses the build failures by adding the missing new.rs and snapshot.rs CLI modules. The rustfmt violations in wezterm-gui/src/termwindow/telemetry/panel.rs have also been resolved, improving code readability. The new CLI commands are correctly integrated into the main application. However, the stub implementations for the new commands currently return a success status, which can be misleading for unimplemented features.
| self.template | ||
| ); | ||
| eprintln!("This feature will create new projects from templates."); | ||
| Ok(()) |
There was a problem hiding this comment.
For unimplemented CLI commands, it is generally better to return an Err result rather than Ok(()). Returning Ok(()) implies that the command executed successfully, which can be misleading for users or scripts that rely on exit codes to determine command success or failure. Consider returning an anyhow::anyhow!("command not yet implemented") error.
| Ok(()) | |
| Err(anyhow::anyhow!("command not yet implemented")) |
| pub fn run(&self) -> anyhow::Result<()> { | ||
| eprintln!("CX Terminal: 'save' command is not yet implemented."); | ||
| eprintln!("This feature will save current workspace as a snapshot."); | ||
| Ok(()) |
There was a problem hiding this comment.
For unimplemented CLI commands, it is generally better to return an Err result rather than Ok(()). Returning Ok(()) implies that the command executed successfully, which can be misleading for users or scripts that rely on exit codes to determine command success or failure. Consider returning an anyhow::anyhow!("command not yet implemented") error.
| Ok(()) | |
| Err(anyhow::anyhow!("command not yet implemented")) |
| "CX Terminal: 'restore' command is not yet implemented. Snapshot: {}", | ||
| self.name | ||
| ); | ||
| eprintln!("This feature will restore a workspace from a snapshot."); |
There was a problem hiding this comment.
For unimplemented CLI commands, it is generally better to return an Err result rather than Ok(()). Returning Ok(()) implies that the command executed successfully, which can be misleading for users or scripts that rely on exit codes to determine command success or failure. Consider returning an anyhow::anyhow!("command not yet implemented") error.
| eprintln!("This feature will restore a workspace from a snapshot."); | |
| Err(anyhow::anyhow!("command not yet implemented")) |
| pub fn run(&self) -> anyhow::Result<()> { | ||
| eprintln!("CX Terminal: 'snapshots' command is not yet implemented."); | ||
| eprintln!("This feature will list and manage workspace snapshots."); | ||
| Ok(()) |
There was a problem hiding this comment.
For unimplemented CLI commands, it is generally better to return an Err result rather than Ok(()). Returning Ok(()) implies that the command executed successfully, which can be misleading for users or scripts that rely on exit codes to determine command success or failure. Consider returning an anyhow::anyhow!("command not yet implemented") error.
| Ok(()) | |
| Err(anyhow::anyhow!("command not yet implemented")) |
Updates all CI workflows to use the renamed package names: - wezterm → cx-terminal - wezterm-gui → cx-terminal-gui
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@wezterm/src/cli/new.rs`:
- Around line 20-26: The run method currently prints to stderr and returns Ok,
so change wezterm::cli::new::run to use structured logging and return an error:
replace eprintln! calls with log::error! carrying the same message/context
(e.g., mention "'new' command not yet implemented" and template), then return
Err(anyhow::anyhow!("'new' command is not implemented")) (or a descriptive
anyhow error) instead of Ok(()); update function signature usage accordingly so
callers receive a failure status.
In `@wezterm/src/cli/snapshot.rs`:
- Around line 16-55: The three unimplemented command run methods
(SaveCommand::run, RestoreCommand::run, and SnapshotsCommand::run) should stop
using eprintln! and uppercase "CX Terminal" and instead log an error with the
crate's log macros using lowercase "cx" (e.g., log::error!), add a top-level
import for the log crate (use log or use log::error), and return a failing
anyhow::Result (e.g., Err(anyhow::anyhow!("unimplemented: <command>"))) rather
than Ok(()), so callers and automation observe the failure; update each run
implementation to log the lowercase "cx" message with error and return an anyhow
error describing the unimplemented command.
| pub fn run(&self) -> anyhow::Result<()> { | ||
| eprintln!( | ||
| "CX Terminal: 'new' command is not yet implemented. Template: {}", | ||
| self.template | ||
| ); | ||
| eprintln!("This feature will create new projects from templates."); | ||
| Ok(()) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's verify the actual file content
cat -n wezterm/src/cli/new.rs | head -40Repository: cxlinux-ai/cx
Length of output: 997
🏁 Script executed:
# Check if log crate is available in the project
rg "use log" wezterm/src/ -A 2 | head -20Repository: cxlinux-ai/cx
Length of output: 39
🏁 Script executed:
# Look for similar patterns in other CLI commands
fd "\.rs$" wezterm/src/cli/ --exec basename {} \; | sortRepository: cxlinux-ai/cx
Length of output: 444
🏁 Script executed:
# Check the Cargo.toml for log dependency
cat wezterm/Cargo.toml | grep -A 5 "\[dependencies\]"Repository: cxlinux-ai/cx
Length of output: 207
🏁 Script executed:
# Check how other CLI commands handle logging and errors
rg "log::error" wezterm/src/cli/ -A 2 -B 2Repository: cxlinux-ai/cx
Length of output: 39
🏁 Script executed:
# Check if log is imported in other CLI files
rg "use log" wezterm/src/cli/ -B 2 -A 2Repository: cxlinux-ai/cx
Length of output: 39
🏁 Script executed:
# Look at another CLI command implementation to see the pattern
cat -n wezterm/src/cli/list.rs | head -50Repository: cxlinux-ai/cx
Length of output: 2148
🏁 Script executed:
# Check the mod.rs file to see module structure
cat -n wezterm/src/cli/mod.rs | head -30Repository: cxlinux-ai/cx
Length of output: 820
🏁 Script executed:
# Check if log is used anywhere in the wezterm crate
rg "log::" wezterm/src/ | head -10Repository: cxlinux-ai/cx
Length of output: 332
🏁 Script executed:
# Check what dependencies wezterm has - look at full Cargo.toml section
sed -n '/^\[dependencies\]/,/^\[/p' wezterm/Cargo.toml | head -30Repository: cxlinux-ai/cx
Length of output: 822
🏁 Script executed:
# Check if there are other unimplemented commands to see the pattern
rg "not yet implemented" wezterm/src/ -B 5 -A 5Repository: cxlinux-ai/cx
Length of output: 2382
🏁 Script executed:
# Look at how errors are typically handled in CLI commands
rg "anyhow::bail" wezterm/src/cli/ -B 2 -A 2Repository: cxlinux-ai/cx
Length of output: 1656
🏁 Script executed:
# Verify that log crate is properly imported in other CLI files that use it
cat -n wezterm/src/cli/split_pane.rs | grep -A 5 "^.*use log"Repository: cxlinux-ai/cx
Length of output: 39
🏁 Script executed:
# Check the guidelines one more time - verify lowercase requirement applies to this context
grep -i "lowercase" wezterm/ -r --include="*.md" --include="*.rs" | head -10Repository: cxlinux-ai/cx
Length of output: 359
🏁 Script executed:
# Check if new.rs imports log or if it comes from a prelude
head -20 wezterm/src/cli/new.rsRepository: cxlinux-ai/cx
Length of output: 567
🏁 Script executed:
# Check a file that uses log to see the import pattern
head -20 wezterm/src/cli/split_pane.rsRepository: cxlinux-ai/cx
Length of output: 795
🏁 Script executed:
# Check the crate root to see if log is imported in lib.rs or main
head -30 wezterm/src/lib.rs 2>/dev/null || head -30 wezterm/src/main.rsRepository: cxlinux-ai/cx
Length of output: 1008
🏁 Script executed:
# Check wezterm/src/cli/mod.rs for log import or prelude
cat -n wezterm/src/cli/mod.rsRepository: cxlinux-ai/cx
Length of output: 12375
🏁 Script executed:
# Check if log is used via prelude in split_pane.rs - look for the log::debug! usage
sed -n '1,100p' wezterm/src/cli/split_pane.rs | grep -n "log::"Repository: cxlinux-ai/cx
Length of output: 39
🏁 Script executed:
# Look at the full split_pane.rs file to see log::debug usage
cat -n wezterm/src/cli/split_pane.rs | grep -B 5 -A 5 "log::debug"Repository: cxlinux-ai/cx
Length of output: 376
🏁 Script executed:
# Search for where log might be coming from - check for prelude imports
rg "pub use log" wezterm/src/ -B 2 -A 2Repository: cxlinux-ai/cx
Length of output: 39
🏁 Script executed:
# Check if there's a prelude module
fd "prelude" wezterm/src/Repository: cxlinux-ai/cx
Length of output: 39
🏁 Script executed:
# Look at the entire split_pane.rs file to see all imports
head -15 wezterm/src/cli/split_pane.rsRepository: cxlinux-ai/cx
Length of output: 563
🏁 Script executed:
# Check mux crate for log export
rg "pub use log" --type rust -A 2Repository: cxlinux-ai/cx
Length of output: 39
🏁 Script executed:
# Let's check the Cargo.lock to understand the workspace structure
fd "Cargo.lock" | head -5Repository: cxlinux-ai/cx
Length of output: 67
🏁 Script executed:
# Check if any of the imported crates re-export log
rg "extern crate log" wezterm/src/ -B 2 -A 2Repository: cxlinux-ai/cx
Length of output: 39
🏁 Script executed:
# Check the root of the wezterm crate for extern/use statements
head -50 wezterm/src/lib.rs 2>/dev/null | catRepository: cxlinux-ai/cx
Length of output: 39
🏁 Script executed:
# Check workspace Cargo.toml
cat Cargo.toml | head -50Repository: cxlinux-ai/cx
Length of output: 1126
🏁 Script executed:
# Check if log is re-exported from mux or other workspace crates
rg "pub use log::" --type rustRepository: cxlinux-ai/cx
Length of output: 39
🏁 Script executed:
# Just directly check if new.rs needs log import by examining similar unimplemented commands
cat -n wezterm/src/cli/snapshot.rs | head -50Repository: cxlinux-ai/cx
Length of output: 1611
🏁 Script executed:
# Check how error messages in other parts use the branding
rg "CX Terminal|cx terminal" wezterm/src/ --type rustRepository: cxlinux-ai/cx
Length of output: 1590
🏁 Script executed:
# Check main.rs to see how errors are logged/displayed to user
cat -n wezterm/src/main.rs | grep -B 5 -A 5 "log::error"Repository: cxlinux-ai/cx
Length of output: 381
🏁 Script executed:
# Look at ask.rs to see how an AI command (which is implemented) handles errors/messages
head -50 wezterm/src/cli/ask.rsRepository: cxlinux-ai/cx
Length of output: 1557
Return an error for unimplemented CLI commands (and use structured logging).
The command should fail rather than return Ok(), which misleads automation into treating it as successful. Also switch from eprintln! to log::error! for consistency with error handling patterns used elsewhere in the codebase.
Suggested fix
pub fn run(&self) -> anyhow::Result<()> {
- eprintln!(
- "CX Terminal: 'new' command is not yet implemented. Template: {}",
- self.template
- );
- eprintln!("This feature will create new projects from templates.");
- Ok(())
+ log::error!(
+ "CX Terminal: 'new' command is not yet implemented. Template: {}",
+ self.template
+ );
+ anyhow::bail!("CX Terminal: 'new' command is not yet implemented");
}🤖 Prompt for AI Agents
In `@wezterm/src/cli/new.rs` around lines 20 - 26, The run method currently prints
to stderr and returns Ok, so change wezterm::cli::new::run to use structured
logging and return an error: replace eprintln! calls with log::error! carrying
the same message/context (e.g., mention "'new' command not yet implemented" and
template), then return Err(anyhow::anyhow!("'new' command is not implemented"))
(or a descriptive anyhow error) instead of Ok(()); update function signature
usage accordingly so callers receive a failure status.
| pub fn run(&self) -> anyhow::Result<()> { | ||
| eprintln!("CX Terminal: 'save' command is not yet implemented."); | ||
| eprintln!("This feature will save current workspace as a snapshot."); | ||
| Ok(()) | ||
| } | ||
| } | ||
|
|
||
| #[derive(Debug, Parser, Clone)] | ||
| pub struct RestoreCommand { | ||
| /// Name of the snapshot to restore | ||
| pub name: String, | ||
| } | ||
|
|
||
| impl RestoreCommand { | ||
| pub fn run(&self) -> anyhow::Result<()> { | ||
| eprintln!( | ||
| "CX Terminal: 'restore' command is not yet implemented. Snapshot: {}", | ||
| self.name | ||
| ); | ||
| eprintln!("This feature will restore a workspace from a snapshot."); | ||
| Ok(()) | ||
| } | ||
| } | ||
|
|
||
| #[derive(Debug, Parser, Clone)] | ||
| pub struct SnapshotsCommand { | ||
| /// List all snapshots | ||
| #[arg(short, long)] | ||
| pub list: bool, | ||
|
|
||
| /// Delete a snapshot by name | ||
| #[arg(short, long)] | ||
| pub delete: Option<String>, | ||
| } | ||
|
|
||
| impl SnapshotsCommand { | ||
| pub fn run(&self) -> anyhow::Result<()> { | ||
| eprintln!("CX Terminal: 'snapshots' command is not yet implemented."); | ||
| eprintln!("This feature will list and manage workspace snapshots."); | ||
| Ok(()) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Check if the file exists and examine its content
wc -l wezterm/src/cli/snapshot.rs 2>/dev/null || echo "File not found"Repository: cxlinux-ai/cx
Length of output: 87
🏁 Script executed:
# Read the snapshot.rs file with line numbers
cat -n wezterm/src/cli/snapshot.rsRepository: cxlinux-ai/cx
Length of output: 1909
🏁 Script executed:
# Check what imports are available in the file
head -20 wezterm/src/cli/snapshot.rsRepository: cxlinux-ai/cx
Length of output: 602
🏁 Script executed:
# Search for usage of eprintln! vs log macros in similar CLI commands
rg "eprintln!|log::(error|info|debug)" wezterm/src/cli/ -A 2 -B 2Repository: cxlinux-ai/cx
Length of output: 5815
🏁 Script executed:
# Check if anyhow is used elsewhere in the codebase for error handling
rg "anyhow::bail|anyhow::Result" wezterm/src/cli/ --max-count=5Repository: cxlinux-ai/cx
Length of output: 3260
🏁 Script executed:
# Check how other unimplemented commands handle errors in this codebase
rg "not yet implemented|unimplemented" wezterm/src/cli/ -B 3 -A 3Repository: cxlinux-ai/cx
Length of output: 1856
Use log macros, lowercase terminology, and fail on unimplemented commands.
All three snapshot commands (save, restore, snapshots) violate coding guidelines: they use uppercase "CX Terminal" instead of lowercase "cx", call eprintln! instead of log::error!, and return Ok(()) despite being unimplemented. Unimplemented commands should fail to prevent silent failures in automation.
Note: The proposed fix requires adding use log; at the top of the file since the log crate is not currently imported.
Proposed fix
+use log;
impl SaveCommand {
pub fn run(&self) -> anyhow::Result<()> {
- eprintln!("CX Terminal: 'save' command is not yet implemented.");
- eprintln!("This feature will save current workspace as a snapshot.");
- Ok(())
+ log::error!("cx terminal: 'save' command is not yet implemented.");
+ anyhow::bail!("cx terminal: 'save' command is not yet implemented");
}
}
impl RestoreCommand {
pub fn run(&self) -> anyhow::Result<()> {
- eprintln!(
- "CX Terminal: 'restore' command is not yet implemented. Snapshot: {}",
- self.name
- );
- eprintln!("This feature will restore a workspace from a snapshot.");
- Ok(())
+ log::error!(
+ "cx terminal: 'restore' command is not yet implemented. snapshot: {}",
+ self.name
+ );
+ anyhow::bail!("cx terminal: 'restore' command is not yet implemented");
}
}
impl SnapshotsCommand {
pub fn run(&self) -> anyhow::Result<()> {
- eprintln!("CX Terminal: 'snapshots' command is not yet implemented.");
- eprintln!("This feature will list and manage workspace snapshots.");
- Ok(())
+ log::error!("cx terminal: 'snapshots' command is not yet implemented.");
+ anyhow::bail!("cx terminal: 'snapshots' command is not yet implemented");
}
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| pub fn run(&self) -> anyhow::Result<()> { | |
| eprintln!("CX Terminal: 'save' command is not yet implemented."); | |
| eprintln!("This feature will save current workspace as a snapshot."); | |
| Ok(()) | |
| } | |
| } | |
| #[derive(Debug, Parser, Clone)] | |
| pub struct RestoreCommand { | |
| /// Name of the snapshot to restore | |
| pub name: String, | |
| } | |
| impl RestoreCommand { | |
| pub fn run(&self) -> anyhow::Result<()> { | |
| eprintln!( | |
| "CX Terminal: 'restore' command is not yet implemented. Snapshot: {}", | |
| self.name | |
| ); | |
| eprintln!("This feature will restore a workspace from a snapshot."); | |
| Ok(()) | |
| } | |
| } | |
| #[derive(Debug, Parser, Clone)] | |
| pub struct SnapshotsCommand { | |
| /// List all snapshots | |
| #[arg(short, long)] | |
| pub list: bool, | |
| /// Delete a snapshot by name | |
| #[arg(short, long)] | |
| pub delete: Option<String>, | |
| } | |
| impl SnapshotsCommand { | |
| pub fn run(&self) -> anyhow::Result<()> { | |
| eprintln!("CX Terminal: 'snapshots' command is not yet implemented."); | |
| eprintln!("This feature will list and manage workspace snapshots."); | |
| Ok(()) | |
| use log; | |
| pub fn run(&self) -> anyhow::Result<()> { | |
| log::error!("cx terminal: 'save' command is not yet implemented."); | |
| anyhow::bail!("cx terminal: 'save' command is not yet implemented"); | |
| } | |
| } | |
| #[derive(Debug, Parser, Clone)] | |
| pub struct RestoreCommand { | |
| /// Name of the snapshot to restore | |
| pub name: String, | |
| } | |
| impl RestoreCommand { | |
| pub fn run(&self) -> anyhow::Result<()> { | |
| log::error!( | |
| "cx terminal: 'restore' command is not yet implemented. snapshot: {}", | |
| self.name | |
| ); | |
| anyhow::bail!("cx terminal: 'restore' command is not yet implemented"); | |
| } | |
| } | |
| #[derive(Debug, Parser, Clone)] | |
| pub struct SnapshotsCommand { | |
| /// List all snapshots | |
| #[arg(short, long)] | |
| pub list: bool, | |
| /// Delete a snapshot by name | |
| #[arg(short, long)] | |
| pub delete: Option<String>, | |
| } | |
| impl SnapshotsCommand { | |
| pub fn run(&self) -> anyhow::Result<()> { | |
| log::error!("cx terminal: 'snapshots' command is not yet implemented."); | |
| anyhow::bail!("cx terminal: 'snapshots' command is not yet implemented"); | |
| } | |
| } |
🤖 Prompt for AI Agents
In `@wezterm/src/cli/snapshot.rs` around lines 16 - 55, The three unimplemented
command run methods (SaveCommand::run, RestoreCommand::run, and
SnapshotsCommand::run) should stop using eprintln! and uppercase "CX Terminal"
and instead log an error with the crate's log macros using lowercase "cx" (e.g.,
log::error!), add a top-level import for the log crate (use log or use
log::error), and return a failing anyhow::Result (e.g.,
Err(anyhow::anyhow!("unimplemented: <command>"))) rather than Ok(()), so callers
and automation observe the failure; update each run implementation to log the
lowercase "cx" message with error and return an anyhow error describing the
unimplemented command.
Keep binary output names as 'wezterm' and 'wezterm-gui' while package names are 'cx-terminal' and 'cx-terminal-gui'. This ensures deploy.sh and other scripts that reference target/release/wezterm continue to work.
Rename step names from 'Build wezterm' to 'Build cx-terminal' for consistency with the package names.
Fix remaining Element::new formatting issues to match rustfmt's expected style.
Add module-level and function-level documentation to new.rs and snapshot.rs to improve docstring coverage and meet the 80% threshold.
- Create assets/macos/CX Terminal.app/Contents/Info.plist for macOS builds - Fix rustfmt violations in mux/src/ssh_agent.rs - Fix rustfmt violations in wezterm/src/cli/ask.rs - Fix rustfmt violations in telemetry panel files The macOS build was failing because build.rs expected the Info.plist file at assets/macos/CX Terminal.app/Contents/Info.plist but it was never created during the rebrand from WezTerm. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (6)
.github/workflows/gen_debian12_tag.yml (2)
102-102: Upload job will never run in this repository.The condition
github.repository == 'wezterm/wezterm'is hardcoded to check for the original wezterm repository. Since this is thecxlinux-ai/cxrepository, this condition will always be false and the upload job will be skipped on all tag pushes.This pattern appears across 26+ workflow files (all
gen_*_tag.yml,gen_*_continuous.yml, and related workflows). If uploads should be enabled for this repository, update the condition togithub.repository == 'cxlinux-ai/cx'across all affected workflows. If uploads are intentionally disabled, add a comment to explain this design.
44-44: Replace hardcoded workspace path across all workflow files.The path
/__w/wezterm/weztermis hardcoded in 46+ workflow files and is incorrect for thecxlinux-ai/cxrepository. For this repository, the GitHub Actions workspace path should be/__w/cx/cx. This mismatch causes git operations to fail whenever these workflows run.Update all occurrences in
.github/workflows/(including lines 44 and 111 in gen_debian12_tag.yml, and all other affected files) to use/__w/cx/cxinstead..github/workflows/gen_fedora39_tag.yml (2)
97-97: Repository check will prevent upload job from running.The condition
github.repository == 'wezterm/wezterm'will never be true forcxlinux-ai/cx, causing the upload job to be permanently skipped. This should be updated to match the new repository.Proposed fix
- if: github.repository == 'wezterm/wezterm' + if: github.repository == 'cxlinux-ai/cx'
38-38: Git safe.directory paths reference old repository name.The
safe.directorypaths still reference/__w/wezterm/wezterm, but GitHub Actions checks out to a directory based on the repository name. Since the repo is nowcxlinux-ai/cx, the correct path would be/__w/cx/cx.Proposed fix
- run: "git config --global --add safe.directory /__w/wezterm/wezterm" + run: "git config --global --add safe.directory /__w/cx/cx"Apply to both occurrences (lines 38 and 106).
Also applies to: 104-106
.github/workflows/gen_fedora40_tag.yml (2)
97-97: Repository condition will never match — upload job won't run.The PR is in repository
cxlinux-ai/cx, but line 97 checks forgithub.repository == 'wezterm/wezterm'. This condition will always evaluate to false, preventing the upload job from ever executing for tagged releases.🐛 Proposed fix
- if: github.repository == 'wezterm/wezterm' + if: github.repository == 'cxlinux-ai/cx'
38-38: Workspace path references old repository name.The GitHub Actions workspace path
/__w/wezterm/weztermis derived from the repository name. Since the repository iscxlinux-ai/cx, the actual path will be/__w/cx/cx. This safe.directory configuration won't match the actual checkout location, potentially causing git permission errors.The same issue exists on lines 104-106.
🐛 Proposed fix
- run: "git config --global --add safe.directory /__w/wezterm/wezterm" + run: "git config --global --add safe.directory /__w/cx/cx"And similarly at line 106:
- run: "git config --global --add safe.directory /__w/wezterm/wezterm" + run: "git config --global --add safe.directory /__w/cx/cx"
🤖 Fix all issues with AI agents
In @.github/workflows/gen_macos_continuous.yml:
- Around line 65-75: The macOS workflow step names were changed to "cx-terminal"
and "cx-terminal-gui" but the cargo commands still build -p wezterm and -p
wezterm-gui, which will fail if the crates were renamed; update the cargo build
targets in the steps that run "cargo build --target x86_64-apple-darwin -p
wezterm --release" and "cargo build --target aarch64-apple-darwin -p wezterm
--release" to use -p cx-terminal (and similarly change -p wezterm-gui to -p
cx-terminal-gui for the GUI steps), or alternatively revert the step names back
to wezterm/wezterm-gui so labels and -p flags match (look for the workflow step
blocks named "Build cx-terminal (Release mode Intel/ARM)" and "Build
cx-terminal-gui (Release mode Intel/ARM)" to make the edits).
In @.github/workflows/gen_macos_tag.yml:
- Around line 49-60: The workflow build steps still invoke the old package names
in the run commands (e.g., run: "cargo build --target x86_64-apple-darwin -p
wezterm --release" and run: "cargo build --target aarch64-apple-darwin -p
wezterm-gui --release"); update those cargo -p flags to the renamed packages so
the commands use -p cx-terminal for the terminal builds and -p cx-terminal-gui
for the GUI builds for both x86_64-apple-darwin and aarch64-apple-darwin
targets.
In @.github/workflows/gen_macos.yml:
- Around line 62-73: The workflow build steps use incorrect package names:
replace `-p wezterm` with `-p cx-terminal` and `-p wezterm-gui` with `-p
cx-terminal-gui` in the macOS job steps (`Build cx-terminal (Release mode
Intel)`, `Build cx-terminal (Release mode ARM)`, `Build cx-terminal-gui (Release
mode Intel)`, `Build cx-terminal-gui (Release mode ARM)`) so the `cargo build`
-p flag references the actual Cargo package names; also update the `[[bin]]`
sections in the Cargo.toml files to change any `name = "wezterm"`/`wezterm-gui`
entries to `cx-terminal`/`cx-terminal-gui` respectively so package and binary
names are consistent.
In `@assets/macos/CX` Terminal.app/Contents/Info.plist:
- Around line 31-38: The Info.plist currently has NSMainNibFile with an empty
string and NSRequiresAquaSystemAppearance set as a string; remove the empty
NSMainNibFile key (or set it to a real nib name if a nib exists) and change
NSRequiresAquaSystemAppearance to a boolean entry (use <true/> or <false/> as
appropriate) so the plist uses proper types for NSRequiresAquaSystemAppearance
and avoids an empty NSMainNibFile entry.
In `@wezterm-gui/Cargo.toml`:
- Around line 141-143: The [[bin]] entry currently names the binary
"wezterm-gui" which violates the branding rule; update the name field in the
Cargo.toml [[bin]] block (the entry that points to "src/main.rs") to the
approved project binary name (e.g., "cx-terminal" or the designated branding) so
the package no longer uses "wezterm-gui".
🧹 Nitpick comments (4)
.github/workflows/gen_macos_tag.yml (2)
61-72: Partial renaming may cause confusion.The steps for
wezterm-mux-serverandstrip-ansi-escapeswere not renamed, whilewezterm/wezterm-guisteps were updated tocx-terminal/cx-terminal-gui. If this is a phased rebranding approach, consider adding a comment in the workflow to clarify the plan, or complete the renaming for consistency.
94-94: Artifact path still references "WezTerm".The artifact upload path uses
"WezTerm-*.zip"which doesn't align with thecx-terminalrebranding in the step names. If the packaging script (ci/deploy.sh) was updated to produceCX-Terminal-*.zipor similar, this path will need to match. Otherwise, this is consistent but worth noting for future rebranding efforts.assets/macos/CX Terminal.app/Contents/Info.plist (1)
39-64: Consider trimming privacy usage keys to only what the app actually needs.Including a broad set of usage descriptions can trigger additional review scrutiny or user prompts; keeping only the required keys reduces friction and compliance questions.
wezterm-gui/src/termwindow/telemetry/data.rs (1)
258-263: Consider handling additional git status codes.The current checks cover common cases (
M,A,D,??), but git's porcelain format includes additional codes likeR(renamed),C(copied), andU(unmerged) that aren't detected here. For example, a renamed staged file (R) would currently show asCleaninstead ofStaged.♻️ Suggested enhancement
- let has_staged = lines - .iter() - .any(|l| l.starts_with("M ") || l.starts_with("A ") || l.starts_with("D ")); - let has_unstaged = lines - .iter() - .any(|l| l.starts_with(" M") || l.starts_with(" D") || l.starts_with("??")); + let has_staged = lines.iter().any(|l| { + l.starts_with("M ") + || l.starts_with("A ") + || l.starts_with("D ") + || l.starts_with("R ") + || l.starts_with("C ") + }); + let has_unstaged = lines.iter().any(|l| { + l.starts_with(" M") + || l.starts_with(" D") + || l.starts_with("??") + || l.starts_with(" R") + || l.starts_with(" C") + });
| - name: "Build cx-terminal (Release mode Intel)" | ||
| shell: bash | ||
| run: "cargo build --target x86_64-apple-darwin -p wezterm --release" | ||
| - name: "Build wezterm (Release mode ARM)" | ||
| - name: "Build cx-terminal (Release mode ARM)" | ||
| shell: bash | ||
| run: "cargo build --target aarch64-apple-darwin -p wezterm --release" | ||
| - name: "Build wezterm-gui (Release mode Intel)" | ||
| - name: "Build cx-terminal-gui (Release mode Intel)" | ||
| shell: bash | ||
| run: "cargo build --target x86_64-apple-darwin -p wezterm-gui --release" | ||
| - name: "Build wezterm-gui (Release mode ARM)" | ||
| - name: "Build cx-terminal-gui (Release mode ARM)" | ||
| shell: bash |
There was a problem hiding this comment.
Align macos build commands with the new cx-terminal labels.
The step names now say cx-terminal/cx-terminal-gui, but the commands still build -p wezterm / -p wezterm-gui. If the crates were renamed (as in other workflows), this will break macos CI. Consider updating the -p targets (or reverting labels if the crates remain wezterm).
✅ Suggested change (if crates are renamed)
- run: "cargo build --target x86_64-apple-darwin -p wezterm --release"
+ run: "cargo build --target x86_64-apple-darwin -p cx-terminal --release"
...
- run: "cargo build --target aarch64-apple-darwin -p wezterm --release"
+ run: "cargo build --target aarch64-apple-darwin -p cx-terminal --release"
...
- run: "cargo build --target x86_64-apple-darwin -p wezterm-gui --release"
+ run: "cargo build --target x86_64-apple-darwin -p cx-terminal-gui --release"
...
- run: "cargo build --target aarch64-apple-darwin -p wezterm-gui --release"
+ run: "cargo build --target aarch64-apple-darwin -p cx-terminal-gui --release"🤖 Prompt for AI Agents
In @.github/workflows/gen_macos_continuous.yml around lines 65 - 75, The macOS
workflow step names were changed to "cx-terminal" and "cx-terminal-gui" but the
cargo commands still build -p wezterm and -p wezterm-gui, which will fail if the
crates were renamed; update the cargo build targets in the steps that run "cargo
build --target x86_64-apple-darwin -p wezterm --release" and "cargo build
--target aarch64-apple-darwin -p wezterm --release" to use -p cx-terminal (and
similarly change -p wezterm-gui to -p cx-terminal-gui for the GUI steps), or
alternatively revert the step names back to wezterm/wezterm-gui so labels and -p
flags match (look for the workflow step blocks named "Build cx-terminal (Release
mode Intel/ARM)" and "Build cx-terminal-gui (Release mode Intel/ARM)" to make
the edits).
| - name: "Build cx-terminal (Release mode Intel)" | ||
| shell: bash | ||
| run: "cargo build --target x86_64-apple-darwin -p wezterm --release" | ||
| - name: "Build wezterm (Release mode ARM)" | ||
| - name: "Build cx-terminal (Release mode ARM)" | ||
| shell: bash | ||
| run: "cargo build --target aarch64-apple-darwin -p wezterm --release" | ||
| - name: "Build wezterm-gui (Release mode Intel)" | ||
| - name: "Build cx-terminal-gui (Release mode Intel)" | ||
| shell: bash | ||
| run: "cargo build --target x86_64-apple-darwin -p wezterm-gui --release" | ||
| - name: "Build wezterm-gui (Release mode ARM)" | ||
| - name: "Build cx-terminal-gui (Release mode ARM)" | ||
| shell: bash | ||
| run: "cargo build --target aarch64-apple-darwin -p wezterm-gui --release" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check the package names in Cargo.toml files
echo "=== Checking wezterm package name ==="
find . -path "*/wezterm/Cargo.toml" -exec grep -n '^\s*name\s*=' {} + 2>/dev/null | head -5
echo -e "\n=== Checking wezterm-gui package name ==="
find . -path "*/wezterm-gui/Cargo.toml" -exec grep -n '^\s*name\s*=' {} + 2>/dev/null | head -5Repository: cxlinux-ai/cx
Length of output: 232
Update cargo package names to match the renamed packages in Cargo.toml.
The step names were updated to cx-terminal and cx-terminal-gui, and the package names in Cargo.toml were correctly changed to match. However, the cargo build commands still reference the old package names with -p wezterm and -p wezterm-gui.
Update lines 51, 54, 57, and 60 to use -p cx-terminal and -p cx-terminal-gui respectively, or the builds will fail.
🤖 Prompt for AI Agents
In @.github/workflows/gen_macos_tag.yml around lines 49 - 60, The workflow build
steps still invoke the old package names in the run commands (e.g., run: "cargo
build --target x86_64-apple-darwin -p wezterm --release" and run: "cargo build
--target aarch64-apple-darwin -p wezterm-gui --release"); update those cargo -p
flags to the renamed packages so the commands use -p cx-terminal for the
terminal builds and -p cx-terminal-gui for the GUI builds for both
x86_64-apple-darwin and aarch64-apple-darwin targets.
| - name: "Build cx-terminal (Release mode Intel)" | ||
| shell: bash | ||
| run: "cargo build --target x86_64-apple-darwin -p wezterm --release" | ||
| - name: "Build wezterm (Release mode ARM)" | ||
| - name: "Build cx-terminal (Release mode ARM)" | ||
| shell: bash | ||
| run: "cargo build --target aarch64-apple-darwin -p wezterm --release" | ||
| - name: "Build wezterm-gui (Release mode Intel)" | ||
| - name: "Build cx-terminal-gui (Release mode Intel)" | ||
| shell: bash | ||
| run: "cargo build --target x86_64-apple-darwin -p wezterm-gui --release" | ||
| - name: "Build wezterm-gui (Release mode ARM)" | ||
| - name: "Build cx-terminal-gui (Release mode ARM)" | ||
| shell: bash | ||
| run: "cargo build --target aarch64-apple-darwin -p wezterm-gui --release" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -name "Cargo.toml" -type f | head -20Repository: cxlinux-ai/cx
Length of output: 552
🏁 Script executed:
#!/bin/bash
# Check package names in workspace Cargo.toml and member crates
for toml in $(find . -name "Cargo.toml" -type f); do
echo "=== $toml ==="
grep -E '^\s*name\s*=' "$toml" | head -5
doneRepository: cxlinux-ai/cx
Length of output: 4188
🏁 Script executed:
cat -n ./wezterm/Cargo.toml | head -30Repository: cxlinux-ai/cx
Length of output: 1061
🏁 Script executed:
cat -n ./wezterm-gui/Cargo.toml | head -35Repository: cxlinux-ai/cx
Length of output: 1394
🏁 Script executed:
grep -n '\[\[bin\]\]\|\[\[lib\]\]\|^name = ' ./wezterm/Cargo.toml ./wezterm-gui/Cargo.tomlRepository: cxlinux-ai/cx
Length of output: 312
🏁 Script executed:
wc -l ./wezterm/Cargo.toml ./wezterm-gui/Cargo.tomlRepository: cxlinux-ai/cx
Length of output: 123
Update cargo build commands to use correct package names.
The workflow uses -p wezterm and -p wezterm-gui, but the actual package names in Cargo.toml are cx-terminal and cx-terminal-gui. The -p flag references package names, not binary names, so these commands will fail. Update to:
-p cx-terminal(for the wezterm build steps)-p cx-terminal-gui(for the wezterm-gui build steps)
Additionally, the Cargo.toml files still contain wezterm references in their [[bin]] sections, which should be updated to match the new branding.
🤖 Prompt for AI Agents
In @.github/workflows/gen_macos.yml around lines 62 - 73, The workflow build
steps use incorrect package names: replace `-p wezterm` with `-p cx-terminal`
and `-p wezterm-gui` with `-p cx-terminal-gui` in the macOS job steps (`Build
cx-terminal (Release mode Intel)`, `Build cx-terminal (Release mode ARM)`,
`Build cx-terminal-gui (Release mode Intel)`, `Build cx-terminal-gui (Release
mode ARM)`) so the `cargo build` -p flag references the actual Cargo package
names; also update the `[[bin]]` sections in the Cargo.toml files to change any
`name = "wezterm"`/`wezterm-gui` entries to `cx-terminal`/`cx-terminal-gui`
respectively so package and binary names are consistent.
| <key>NSMainNibFile</key> | ||
| <string></string> | ||
| <key>NSSupportsAutomaticGraphicsSwitching</key> | ||
| <true/> | ||
| <key>CFBundleDisplayName</key> | ||
| <string>CX Terminal</string> | ||
| <key>NSRequiresAquaSystemAppearance</key> | ||
| <string>NO</string> |
There was a problem hiding this comment.
Use a boolean for NSRequiresAquaSystemAppearance and avoid empty NSMainNibFile.
NSRequiresAquaSystemAppearance should be a boolean value, and an empty NSMainNibFile key is typically better omitted unless a nib is actually present.
🐛 Proposed fix
- <key>NSMainNibFile</key>
- <string></string>
<key>NSSupportsAutomaticGraphicsSwitching</key>
<true/>
<key>CFBundleDisplayName</key>
<string>CX Terminal</string>
<key>NSRequiresAquaSystemAppearance</key>
- <string>NO</string>
+ <false/>📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <key>NSMainNibFile</key> | |
| <string></string> | |
| <key>NSSupportsAutomaticGraphicsSwitching</key> | |
| <true/> | |
| <key>CFBundleDisplayName</key> | |
| <string>CX Terminal</string> | |
| <key>NSRequiresAquaSystemAppearance</key> | |
| <string>NO</string> | |
| <key>NSSupportsAutomaticGraphicsSwitching</key> | |
| <true/> | |
| <key>CFBundleDisplayName</key> | |
| <string>CX Terminal</string> | |
| <key>NSRequiresAquaSystemAppearance</key> | |
| <false/> |
🤖 Prompt for AI Agents
In `@assets/macos/CX` Terminal.app/Contents/Info.plist around lines 31 - 38, The
Info.plist currently has NSMainNibFile with an empty string and
NSRequiresAquaSystemAppearance set as a string; remove the empty NSMainNibFile
key (or set it to a real nib name if a nib exists) and change
NSRequiresAquaSystemAppearance to a boolean entry (use <true/> or <false/> as
appropriate) so the plist uses proper types for NSRequiresAquaSystemAppearance
and avoids an empty NSMainNibFile entry.
| [[bin]] | ||
| name = "wezterm-gui" | ||
| path = "src/main.rs" |
There was a problem hiding this comment.
Rename the binary to avoid wezterm branding in toml.
The new [[bin]] entry uses wezterm-gui, which conflicts with the toml branding rule. Please switch to a cx-terminal name (or the approved project branding). As per coding guidelines, ...
✅ Suggested change
[[bin]]
-name = "wezterm-gui"
+name = "cx-terminal-gui"
path = "src/main.rs"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| [[bin]] | |
| name = "wezterm-gui" | |
| path = "src/main.rs" | |
| [[bin]] | |
| name = "cx-terminal-gui" | |
| path = "src/main.rs" |
🤖 Prompt for AI Agents
In `@wezterm-gui/Cargo.toml` around lines 141 - 143, The [[bin]] entry currently
names the binary "wezterm-gui" which violates the branding rule; update the name
field in the Cargo.toml [[bin]] block (the entry that points to "src/main.rs")
to the approved project binary name (e.g., "cx-terminal" or the designated
branding) so the package no longer uses "wezterm-gui".
Add cmake, libxcb-util-dev, and libasound2-dev to CI workflows. These are required for building xcb-imdkit and alsa-sys crates. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Add CX Terminal Family section covering all 4 terminals - Update pricing: Team tier from $49 to $99/month - Add complete ruleset 9679118 JSON configuration - Document required CI checks (Cargo Check, Rustfmt, Test Suite, Doc Tests) - Add CI dependency requirements for Ubuntu/Debian builds - Include organization repository list (all 20 repos) - Add Stripe product ID placeholders - Standardize code style, logging, and error handling patterns Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@CLAUDE.md`:
- Around line 198-207: The fenced commit list block is missing a language
identifier causing MD040; update the fenced code block that begins with the
lines "feat: Add voice input support" / "fix: Resolve memory leak in AI panel"
etc. by adding a language tag (e.g., use ```text) after the opening backticks so
the block becomes ```text ... ``` to resolve the lint error; ensure you only add
the language identifier and don't change the block contents.
- Around line 247-251: The fenced code block showing the macOS bundle tree
(starting with "assets/macos/CX Terminal.app/") lacks a language tag and
triggers MD040; update that block to include a language tag (e.g., use ```text)
so the fence becomes ```text before the tree and ends with ``` after, preserving
the exact tree contents.
| ``` | ||
| feat: Add voice input support | ||
| fix: Resolve memory leak in AI panel | ||
| docs: Update CLAUDE.md with pricing | ||
| refactor: Extract subscription validation | ||
| style: Apply rustfmt to all files | ||
| chore: Update dependencies | ||
| test: Add integration tests for daemon IPC | ||
| perf: Optimize command block rendering | ||
| ``` |
There was a problem hiding this comment.
Add a language tag to the Conventional Commits block.
This fenced block is missing a language identifier (Line 198), which fails MD040.
Proposed fix
-```
+```text
feat: Add voice input support
fix: Resolve memory leak in AI panel
docs: Update CLAUDE.md with pricing
refactor: Extract subscription validation
style: Apply rustfmt to all files
chore: Update dependencies
test: Add integration tests for daemon IPC
perf: Optimize command block rendering🧰 Tools
🪛 markdownlint-cli2 (0.18.1)
198-198: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
In `@CLAUDE.md` around lines 198 - 207, The fenced commit list block is missing a
language identifier causing MD040; update the fenced code block that begins with
the lines "feat: Add voice input support" / "fix: Resolve memory leak in AI
panel" etc. by adding a language tag (e.g., use ```text) after the opening
backticks so the block becomes ```text ... ``` to resolve the lint error; ensure
you only add the language identifier and don't change the block contents.
| ``` | ||
| assets/macos/CX Terminal.app/ | ||
| └── Contents/ | ||
| └── Info.plist | ||
| ``` |
There was a problem hiding this comment.
Add a language tag to the macOS bundle tree block.
The fenced block at Line 247 has no language, triggering MD040.
Proposed fix
-```
+```text
assets/macos/CX Terminal.app/
└── Contents/
└── Info.plist🧰 Tools
🪛 markdownlint-cli2 (0.18.1)
247-247: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
In `@CLAUDE.md` around lines 247 - 251, The fenced code block showing the macOS
bundle tree (starting with "assets/macos/CX Terminal.app/") lacks a language tag
and triggers MD040; update that block to include a language tag (e.g., use
```text) so the fence becomes ```text before the tree and ends with ``` after,
preserving the exact tree contents.
Merged $99 Team Tier pricing and branch protection rules with BSL 1.1 license protection and business context from main. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
Summary
Fixes build failures on main branch caused by missing module files.
Changes
Added missing CLI modules:
wezterm/src/cli/new.rs- Stub for project template creationwezterm/src/cli/snapshot.rs- Stub for workspace snapshotsFixed rustfmt violations:
wezterm-gui/src/termwindow/telemetry/panel.rs- Fixed Element::new formattingRoot Cause
The
mod.rsfile declaredpub mod new;andpub mod snapshot;but the actual files were never created, causing:Test plan
🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Style
Platform
Documentation
Chores (CI/Build)
✏️ Tip: You can customize this high-level summary in your review settings.