Initial public release of Warp.
Repo-Sync-Origin: warpdotdev/warp-internal@12af1d983b
This commit is contained in:
David Stern
@@ -0,0 +1,31 @@
|
||||
# Disable Suggested Rules Setting
|
||||
|
||||
## Summary
|
||||
|
||||
Add a user-facing toggle to disable the AI's suggested-rules chips that appear after agent responses. When disabled, the AI will not present inline rule-suggestion chips to the user.
|
||||
|
||||
Figma: none provided
|
||||
|
||||
## Behavior
|
||||
|
||||
1. A new setting, **Suggested Rules**, appears in the **Knowledge** section of AI settings (Settings → Oz → Knowledge), directly below the existing **Rules** toggle. The setting is only present when the `SuggestedRules` feature flag is enabled.
|
||||
|
||||
2. The **Suggested Rules** toggle is on by default (`true`). The description reads: "Let AI suggest rules to save based on your interactions."
|
||||
|
||||
3. When **Suggested Rules** is on, the agent may show inline rule-suggestion chips at the bottom of an agent response block after the response completes, as it does today. No change to existing behavior.
|
||||
|
||||
4. When **Suggested Rules** is turned off, no rule-suggestion chips appear at the bottom of any agent response block — including responses that would otherwise have generated suggestions. Suggestions that have already been rendered (from a past response in the same session) are not retroactively hidden; only future responses are affected.
|
||||
|
||||
5. The toggle is independently controllable from the parent **Rules** toggle (which gates whether saved rules are included in agent requests). Turning **Rules** off does not automatically turn **Suggested Rules** off, and vice versa.
|
||||
|
||||
6. The toggle is synced to the cloud across devices via the standard global sync mechanism (same behavior as other Active AI settings such as Prompt Suggestions).
|
||||
|
||||
7. The setting is scoped to the `agents.warp_agent.active_ai.rule_suggestions_enabled` TOML key. Users who set this key in their settings file have their preference respected on next launch.
|
||||
|
||||
8. The **Suggested Rules** toggle is disabled (greyed out, not interactive) when the top-level global AI toggle (**Oz**) is off, matching the visual and interaction behavior of all other AI sub-settings.
|
||||
|
||||
9. The setting is not visible in the settings UI when the `SuggestedRules` feature flag is disabled. The setting value is still persisted if previously set, so enabling the flag later restores the user's preference.
|
||||
|
||||
10. Agent mode workflow suggestion chips (the fallback shown when there are no rule suggestions) are unaffected by this setting — they are controlled by the `SuggestedAgentModeWorkflows` feature flag.
|
||||
|
||||
11. A **"Don't show again"** button appears in the suggestions footer of the AI block, to the left of the existing **Dismiss** button, whenever one or more rule-suggestion chips are visible. Clicking it permanently disables the **Suggested Rules** setting (same effect as toggling it off in Settings) and immediately removes the rule-suggestion chips from the current block.
|
||||
@@ -0,0 +1,109 @@
|
||||
# Disable Suggested Rules Setting — Tech Spec
|
||||
|
||||
See `PRODUCT.md` for user-visible behavior.
|
||||
|
||||
## Context
|
||||
|
||||
Rule suggestions are inline chip views shown at the bottom of an AI block after the agent response completes. The feature is gated by `FeatureFlag::SuggestedRules`.
|
||||
|
||||
**Relevant files:**
|
||||
|
||||
- `app/src/settings/ai.rs` — `AISettings` settings group; all Active AI toggles (`prompt_suggestions_enabled_internal`, `code_suggestions_enabled_internal`, etc.) follow the same `define_settings_group!` + getter pattern.
|
||||
- `app/src/ai/blocklist/block.rs (2137–2189)` — `handle_complete_output` creates `SuggestionChipView` instances for each suggested rule. The check `if FeatureFlag::SuggestedRules.is_enabled()` guards the entire block.
|
||||
- `app/src/settings_view/ai_page.rs` — `AIFactWidget` renders the Knowledge section. Contains the `ToggleRules` and `ToggleWarpDriveContext` toggle rows.
|
||||
|
||||
The pattern for an opt-out Active AI setting already exists verbatim for Prompt Suggestions (`prompt_suggestions_enabled_internal` / `is_prompt_suggestions_enabled`) and Code Suggestions.
|
||||
|
||||
## Proposed Changes
|
||||
|
||||
### 1. New setting (`app/src/settings/ai.rs`)
|
||||
|
||||
Add `rule_suggestions_enabled_internal: RuleSuggestionsEnabled` to the `define_settings_group!(AISettings, …)` macro:
|
||||
|
||||
```
|
||||
rule_suggestions_enabled_internal: RuleSuggestionsEnabled {
|
||||
type: bool,
|
||||
default: true,
|
||||
supported_platforms: SupportedPlatforms::ALL,
|
||||
sync_to_cloud: SyncToCloud::Globally(RespectUserSyncSetting::Yes),
|
||||
private: false,
|
||||
toml_path: "agents.warp_agent.active_ai.rule_suggestions_enabled",
|
||||
description: "Controls whether the agent suggests rules to save after responses.",
|
||||
feature_flag: FeatureFlag::SuggestedRules,
|
||||
}
|
||||
```
|
||||
|
||||
The `feature_flag` field causes the setting to be excluded from the user-facing JSON schema when `SuggestedRules` is not enabled for the current build channel.
|
||||
|
||||
Add the getter to `impl AISettings`:
|
||||
|
||||
```rust
|
||||
pub fn is_rule_suggestions_enabled(&self, app: &warpui::AppContext) -> bool {
|
||||
self.is_active_ai_enabled(app) && *self.rule_suggestions_enabled_internal
|
||||
}
|
||||
```
|
||||
|
||||
This follows the same pattern as `is_prompt_suggestions_enabled` and `is_code_suggestions_enabled`.
|
||||
|
||||
### 2. Enforcement in `handle_complete_output` (`app/src/ai/blocklist/block.rs`)
|
||||
|
||||
Change the guard from:
|
||||
|
||||
```rust
|
||||
if FeatureFlag::SuggestedRules.is_enabled() {
|
||||
```
|
||||
|
||||
to:
|
||||
|
||||
```rust
|
||||
if FeatureFlag::SuggestedRules.is_enabled()
|
||||
&& AISettings::as_ref(ctx).is_rule_suggestions_enabled(ctx)
|
||||
{
|
||||
```
|
||||
|
||||
This is the single chokepoint where `SuggestionChipView::new_rule_chip` instances are created. No other code path renders rule-suggestion chips.
|
||||
|
||||
### 3. UI toggle in `AIFactWidget` (`app/src/settings_view/ai_page.rs`)
|
||||
|
||||
- Add `rule_suggestions_toggle: SwitchStateHandle` to `AIFactWidget`.
|
||||
- Add `RuleSuggestionsEnabled` to the `use crate::settings::{…}` import block.
|
||||
- Add `ToggleRuleSuggestions` variant to `AISettingsPageAction`.
|
||||
- Add a handler for `ToggleRuleSuggestions` in `handle_action` that calls `settings.rule_suggestions_enabled_internal.toggle_and_save_value(ctx)`.
|
||||
- Add a `render_rule_suggestions_toggle` method to `AIFactWidget` following the same structure as `render_warp_drive_context_toggle`.
|
||||
- In `AIFactWidget::render`, call `render_rule_suggestions_toggle` conditionally:
|
||||
```rust
|
||||
if FeatureFlag::SuggestedRules.is_enabled() {
|
||||
column.add_child(self.render_rule_suggestions_toggle(view, ai_settings, app));
|
||||
}
|
||||
```
|
||||
Insert this between the rules toggle + "Manage rules" button and the Warp Drive context toggle.
|
||||
|
||||
The toggle renders with `is_any_ai_enabled` as the `is_toggleable` argument (not `is_active_ai_enabled`), consistent with other Knowledge-section toggles like `ToggleRules`.
|
||||
|
||||
### 4. "Don't show again" button (`app/src/ai/blocklist/block.rs`, `app/src/ai/blocklist/block/view_impl/output.rs`, `app/src/ai/blocklist/block/view_impl.rs`)
|
||||
|
||||
A second dismiss button is added to the suggestions footer that permanently disables the setting in addition to clearing the chips.
|
||||
|
||||
**`block.rs`:**
|
||||
- Add `disable_rule_suggestions_button: ViewHandle<ActionButton>` field to `AIBlock`.
|
||||
- Create the button in `AIBlock::new` with label `"Don't show again"` and theme `SuggestionDismissButtonTheme`, dispatching `AIBlockAction::DisableRuleSuggestions` on click.
|
||||
- Add `AIBlockAction::DisableRuleSuggestions` variant. The handler:
|
||||
1. Calls `conversation.dismiss_current_suggestions()` on the history model (for persistence of the dismissal).
|
||||
2. Sets `settings.rule_suggestions_enabled_internal` to `false` via `set_value`.
|
||||
3. Calls `self.suggested_rules.clear()` to immediately remove the chip views from the block, ensuring the footer disappears even if `conversation.existing_suggestions` has not yet been populated by `mark_request_completed`.
|
||||
|
||||
**`output.rs` (`Props` and `render_suggested_rules_and_prompts_footer`):**
|
||||
- Add `disable_rule_suggestions_button: &'a ViewHandle<ActionButton>` to `Props`.
|
||||
- In `render_suggested_rules_and_prompts_footer`, build a `right_buttons` row that conditionally prepends `disable_rule_suggestions_button` (with `margin_right: 4.0`) before `dismiss_suggestion_button` when `has_suggested_rules` is true.
|
||||
|
||||
**`view_impl.rs`:**
|
||||
- Pass `disable_rule_suggestions_button: &self.disable_rule_suggestions_button` when constructing `output::Props`.
|
||||
|
||||
## Testing and Validation
|
||||
|
||||
- **Behavior 1–2 (toggle placement and default):** Open Settings → Knowledge. Confirm the toggle appears under the Rules toggle and is on by default.
|
||||
- **Behavior 3 (on = chips appear):** With the toggle on, run an agent interaction that returns rule suggestions. Verify chips appear as before.
|
||||
- **Behavior 4 (off = chips suppressed):** Turn the toggle off. Run a new agent interaction. Verify no rule-suggestion chips appear. Existing chips from prior responses in the session remain visible.
|
||||
- **Behavior 5 (independence):** Turn Rules off; verify Suggested Rules toggle state is unchanged and vice versa.
|
||||
- **Behavior 8 (greyed out when global AI off):** Turn global AI off. Confirm the Suggested Rules toggle is visually disabled and non-interactive.
|
||||
- **Behavior 9 (hidden without feature flag):** In a build without `SuggestedRules` enabled, confirm the toggle is absent from the settings UI.
|
||||
@@ -0,0 +1,16 @@
|
||||
# Session Restore: Preserve PWD for WSL and Git Bash
|
||||
|
||||
## Summary
|
||||
When Warp restores a session that was running in WSL or an MSYS2-based shell (Git Bash, MSYS2), it re-opens that terminal in the same working directory the user was in when the session was saved.
|
||||
|
||||
## Behavior
|
||||
|
||||
1. When a Warp session is snapshotted (e.g. on app quit, window close, or session save), the current working directory is persisted as part of the session state.
|
||||
|
||||
2. When a WSL session is restored, the new terminal opens with its working directory set to the same path the user was in before. For example, if the user was in `/home/user/projects`, the restored terminal starts there.
|
||||
|
||||
3. When an MSYS2 or Git Bash session is restored, the new terminal opens with its working directory set to the same path the user was in before. For example, if the user was in `/c/Users/user/projects`, the restored MSYS2 session starts in `/c/Users/user/projects`.
|
||||
|
||||
4. If the working directory stored in the snapshot no longer exists, the terminal opens with no startup directory override — falling back to the shell's default.
|
||||
|
||||
5. Session restore behavior for plain Windows shells (PowerShell, Cmd) and native-Unix shells is unaffected.
|
||||
@@ -0,0 +1,58 @@
|
||||
# Session Restore PWD for WSL and Git Bash — Tech Spec
|
||||
|
||||
See `PRODUCT.md` for user-visible behavior.
|
||||
|
||||
## Context
|
||||
|
||||
When Warp saves a session snapshot it records the terminal's current working directory via `TerminalView::active_session_path_if_local`, which calls `ShellLaunchData::maybe_convert_absolute_path` on the raw Unix-style `$PWD` string the shell reports:
|
||||
|
||||
- For WSL, `/home/user/projects` → `\\WSL$\<distro>\home\user\projects` (Windows UNC path).
|
||||
- For MSYS2/Git Bash, `/c/Users/user/projects` → `C:\Users\user\projects` (native drive path).
|
||||
|
||||
So by the time the path is written into `TerminalSnapshot::cwd`, it is already a Windows-native path.
|
||||
|
||||
**Relevant files:**
|
||||
|
||||
- `crates/warp_terminal/src/shell/mod.rs (768–790)` — `ShellLaunchData::maybe_convert_absolute_path`, which performs the Unix → Windows conversion at snapshot time.
|
||||
- `app/src/terminal/view.rs (6506–6528)` — `active_session_path_if_local`, which calls `maybe_convert_absolute_path` and is the write path into the snapshot.
|
||||
- `app/src/pane_group/mod.rs (1533–1570)` — session restore logic that reads `TerminalSnapshot::cwd` and computes `startup_directory`.
|
||||
|
||||
## Why we store host-native paths in sqlite
|
||||
|
||||
The snapshot stores `cwd` as a Windows-native path rather than the guest-native Unix path for three reasons:
|
||||
|
||||
1. **`CreateProcessW` requires it.** `lpCurrentDirectory` must be a Windows path. Storing it host-native means no conversion is needed at restore time.
|
||||
2. **`is_dir()` works natively.** Windows can stat `\\WSL$\<distro>\...` paths directly, letting the restore code verify the directory still exists without any extra logic.
|
||||
3. **Avoids per-shell branching at restore time.** Storing the guest-native path and re-converting at restore time would require extracting the distro or MSYS2 executable from `shell_launch_data` again — exactly the logic that caused the original bug.
|
||||
|
||||
## Root Cause
|
||||
|
||||
The restore code in `pane_group/mod.rs` was re-running the Unix→Windows conversion on `cwd`, passing the already-converted Windows path back into `convert_wsl_to_windows_host_path` / `convert_msys2_to_windows_native_path`. Both functions expect a Unix-style input; given a Windows path they fail and return `None`, so `startup_directory` was always `None` for WSL and MSYS2 sessions, causing the restored terminal to open in the shell's default directory instead of the saved one.
|
||||
|
||||
The `TODO(CORE-3130)` comment in the old WSL branch also noted that the resulting path was being ignored downstream — a sign the whole conversion was unnecessary.
|
||||
|
||||
## Proposed Changes
|
||||
|
||||
**`app/src/pane_group/mod.rs`**
|
||||
|
||||
Replace the `shell_launch_data`-aware path conversion block with a direct `PathBuf::from(cwd)`:
|
||||
|
||||
```rust
|
||||
let startup_directory = terminal_snapshot
|
||||
.cwd
|
||||
.map(PathBuf::from)
|
||||
.filter(|path| path.is_dir());
|
||||
```
|
||||
|
||||
`CreateProcessW`'s `lpCurrentDirectory` accepts both forms:
|
||||
- `\\WSL$\<distro>\...` UNC paths — `wsl.exe` translates these back to Linux paths on startup.
|
||||
- Native `C:\...` drive paths — MSYS2's `bash.exe` maps them to the corresponding MSYS2 path (e.g. `/c/...`) via its own mount table on startup.
|
||||
|
||||
The `chosen_shell` / `wsl_distro` / `msys2_executable` locals derived from `shell_launch_data` are no longer needed for path conversion. `chosen_shell` (used only for `AvailableShells::get_from_shell_launch_data`) is retained in a simplified form; the other two are removed. The `convert_msys2_to_windows_native_path`, `msys2_exe_to_root`, and `WindowsPath` imports that were used solely for the now-deleted conversion are also removed.
|
||||
|
||||
## Testing and Validation
|
||||
|
||||
- **Behavior 2 (WSL):** Open a WSL terminal, `cd` to a non-default directory (e.g. `~/projects`), quit Warp, relaunch. Confirm the restored WSL tab opens in `~/projects`.
|
||||
- **Behavior 3 (MSYS2/Git Bash):** Open a Git Bash terminal, `cd /c/Users/<user>/projects`, quit Warp, relaunch. Confirm the restored tab opens in `/c/Users/<user>/projects`.
|
||||
- **Behavior 4 (missing directory):** Delete the saved directory before relaunching. Confirm the tab opens without error, falling back to the shell default.
|
||||
- **Behavior 5 (unaffected shells):** Verify PowerShell and Cmd session restore continues to work as before.
|
||||
Reference in New Issue
Block a user