* Perfect! ✅ I've successfully fixed the diff theme detection issue by:
## What I Did:
### 1. **Created a shared theme utility** (`frontend/src/utils/theme.ts`):
- Properly handles all theme modes including SYSTEM
- When theme is SYSTEM, it checks `window.matchMedia('(prefers-color-scheme: dark)')`
- Treats all colored themes (PURPLE, GREEN, BLUE, ORANGE, RED) as dark themes
### 2. **Updated all diff-related components** to use the utility:
- **DiffCard.tsx** ✅
- **EditDiffRenderer.tsx** ✅
- **FileChangeRenderer.tsx** ✅
### 3. **Replaced the broken pattern**:
```tsx
// OLD - only worked for explicit DARK theme
let theme = 'light';
if (config?.theme === ThemeMode.DARK) theme = 'dark';
// NEW - works for all themes including SYSTEM
const theme = getActualTheme(config?.theme);
```
## Result:
Now when you have **VK theme set to SYSTEM** and your **OS is in dark mode**, the diff viewers will correctly show dark theme colors instead of the incorrect light theme colors.
The fix ensures consistency with how other components (Logo, JSONEditor) handle theme detection and follows the same pattern that the ThemeProvider uses internally.
* fmt
* Lint
* ## 🎉 Implementation Complete!
I have successfully implemented JSON schema-based executor configuration forms! Here's what was accomplished:
### **✅ Backend Schema Generation**
- Added `schemars` crate to workspace dependencies
- Added `#[derive(JsonSchema)]` to all 8 executor structs (Amp, ClaudeCode, Gemini, Codex, Cursor, Opencode, QwenCode)
- Modified [`generate_types.rs`](file:///private/var/folders/m1/9q_ct1913z10v6wbnv54j25r0000gn/T/vibe-kanban/worktrees/vk-4b73-use-the-sc/crates/server/src/bin/generate_types.rs) to generate JSON schemas to `shared/schemas/` directory
- Generated individual schema files for each executor type
### **✅ Frontend Form System**
- Added `@rjsf/core`, `@rjsf/utils`, and `@rjsf/validator-ajv8` packages
- Created [`ExecutorConfigForm`](file:///private/var/folders/m1/9q_ct1913z10v6wbnv54j25r0000gn/T/vibe-kanban/worktrees/vk-4b73-use-the-sc/frontend/src/components/ExecutorConfigForm.tsx) component with:
- Dynamic schema loading based on executor type
- Custom field templates matching shadcn/ui design system
- Support for all field types (text, checkbox, select, arrays)
- Live validation and error handling
### **✅ Enhanced Settings UI**
- Updated [`Settings.tsx`](file:///private/var/folders/m1/9q_ct1913z10v6wbnv54j25r0000gn/T/vibe-kanban/worktrees/vk-4b73-use-the-sc/frontend/src/pages/Settings.tsx) with:
- Toggle between JSON editor and visual form editor
- Executor type selector with dynamic form switching
- Seamless integration with existing profiles system
- Backwards compatibility with raw JSON editing
### **✅ Testing Results**
Successfully tested using Playwright and confirmed:
- ✅ Form editor toggle works correctly
- ✅ Dynamic schema loading for different executor types
- ✅ Field validation and type checking
- ✅ Complex field types (arrays, enums, required fields) render properly
- ✅ Tested AMP, ClaudeCode, and Gemini executors specifically
### **Key Features Delivered**
1. **User-Friendly Configuration**: Users can now configure executors visually instead of editing raw JSON
2. **Type Safety**: Generated schemas ensure configuration validity
3. **Dynamic Forms**: Each executor type shows only relevant fields
4. **Backwards Compatibility**: Users can still switch back to JSON mode
5. **Professional UI**: Custom templates match the existing design system
6. **Extensible**: Adding new executor types automatically generates forms
The implementation follows all Oracle recommendations and provides a significantly improved user experience for configuring AI coding agents!
* Cleanup script changes for task attempt 4b73f801-0ab1-4859-982e-ea6a0bf9c814
* ## 🚀 **Implementation Complete with Profile Selection!**
Your question was perfectly answered! The new implementation now provides:
### **✅ Full Profile/Variant Selection**
- **Executor Type Dropdown**: Select from AMP, CLAUDE_CODE, GEMINI, etc.
- **Profile Dropdown**: Select from specific profiles like DEFAULT, PLAN, ROUTER, FLOW
- **Dynamic Profile Loading**: Profiles automatically update when executor type changes
### **✅ Complete Data Structure Support**
- **Nested JSON Navigation**: Properly reads `executors[TYPE][PROFILE][TYPE]` structure
- **Real Configuration Loading**: Shows actual values from the JSON profiles
- **Complex Field Types**: Arrays, booleans, enums, text fields all working
### **✅ User Experience Features**
- **Two-Column Layout**: Executor Type and Profile side by side
- **Auto-Profile Reset**: When changing executor types, profile resets to first available
- **Live Data Updates**: Form immediately shows correct configuration when switching
- **Array Management**: Add/remove/reorder array items with full UI controls
The system now provides the complete executor configuration experience you were looking for - users can select both the executor type AND the specific profile/variant, then configure each one with a rich, schema-driven form interface.
* Cleanup script changes for task attempt 4b73f801-0ab1-4859-982e-ea6a0bf9c814
* improvements
* append_prompt
* generate forms
* order
* settings
* amp MCP config update
* form styles
* textarea
* style additional params
* validate
* menu styles
* prevent reload
* fmt
* add and delete configurations
* lint
* fmnt
* clippy
* prettier
* copy
* remove old MCP
* Auto detect schemas on FE
* wipe shared before generation
* fmt
* clippy fmt
* fixes
* fmt
* update shared types check
* disable clippy for large enum
* copy
* tweaks
* fmt
* fmt
* ## ✅ **Implementation Complete!**
I have successfully implemented the asynchronous task deletion feature. Here's a summary of what was implemented:
### **Changes Made:**
1. **Added new ContainerService methods** ([`services/container.rs`](file:///private/var/folders/m1/9q_ct1913z10v6wbnv54j25r0000gn/T/vibe-kanban/worktrees/vk-83cd-delete-tas/crates/services/src/services/container.rs)):
- `has_running_processes()` - validates no running execution processes
- `stop_task_processes()` - stops execution processes quickly
- `cleanup_worktrees()` - handles slow worktree cleanup
2. **Modified delete_task endpoint** ([`routes/tasks.rs`](file:///private/var/folders/m1/9q_ct1913z10v6wbnv54j25r0000gn/T/vibe-kanban/worktrees/vk-83cd-delete-tas/crates/server/src/routes/tasks.rs)):
- **Fast phase:** Validates → Stops processes → Deletes from DB → Emits SSE → Returns `202 Accepted`
- **Background phase:** Spawns tokio task for worktree cleanup with proper logging
3. **Added ApiError::Conflict** ([`error.rs`](file:///private/var/folders/m1/9q_ct1913z10v6wbnv54j25r0000gn/T/vibe-kanban/worktrees/vk-83cd-delete-tas/crates/server/src/error.rs)):
- Returns `409 Conflict` when attempting to delete tasks with running processes
### **Key Benefits:**
- **Fast UI response** - Task deletion returns immediately (`202 Accepted`)
- **Background cleanup** - Slow worktree operations happen asynchronously
- **Proper validation** - Prevents deletion of tasks with running processes
- **Safe implementation** - Uses existing FK CASCADE constraints
- **Observability** - Background tasks have proper tracing and error logging
### **Safety Features Implemented:**
- ✅ Running process validation before deletion
- ✅ DB constraints verified (FK CASCADE)
- ✅ Background task error handling and logging
- ✅ Proper tracing spans for debugging
- ✅ Graceful error handling for failed cleanup
The implementation follows the Oracle's recommendations and maintains backward compatibility while making task deletion much faster for users.
* Cleanup script changes for task attempt 83cd80cd-6627-4e47-95bd-b1e899fe66e0
* ## ✅ **Background Worktree Cleanup Fix Successfully Reapplied!**
I have successfully reapplied all the changes to fix the background worktree cleanup issue. Here's what was implemented:
### **Changes Applied:**
1. **Added `WorktreeCleanupData` struct and `cleanup_worktrees_direct()` function** ([`services/container.rs`](file:///private/var/folders/m1/9q_ct1913z10v6wbnv54j25r0000gn/T/vibe-kanban/worktrees/vk-83cd-delete-tas/crates/services/src/services/container.rs))
- Stores all data needed for cleanup without requiring database access
- Standalone async function that calls `WorktreeManager::cleanup_worktree()` directly
2. **Added validation methods to ContainerService trait:**
- `has_running_processes()` - checks if task has running execution processes
- `stop_task_processes()` - stops execution processes without cleanup
3. **Modified `delete_task()` endpoint** ([`routes/tasks.rs`](file:///private/var/folders/m1/9q_ct1913z10v6wbnv54j25r0000gn/T/vibe-kanban/worktrees/vk-83cd-delete-tas/crates/server/src/routes/tasks.rs))
- **Validates** no running processes exist before deletion
- **Gathers cleanup data** before database deletion (includes project git repo path)
- **Fast phase:** Stops processes → Deletes from DB → Emits SSE → Returns `202 Accepted`
- **Background phase:** Spawns tokio task with self-contained cleanup data
4. **Added `ApiError::Conflict` variant** ([`error.rs`](file:///private/var/folders/m1/9q_ct1913z10v6wbnv54j25r0000gn/T/vibe-kanban/worktrees/vk-83cd-delete-tas/crates/server/src/error.rs))
- Returns `409 Conflict` when trying to delete tasks with running processes
- Proper error handling in HTTP responses
### **Key Improvements:**
- ✅ **Eliminates database race condition** - No more "no rows returned" errors
- ✅ **Maintains fast API response** - Returns `202 Accepted` immediately
- ✅ **Proper validation** - Prevents deletion of tasks with running processes
- ✅ **Better logging** - Background tasks show worktree count and proper tracing
- ✅ **Robust error handling** - Failed cleanups are logged but don't crash the system
- ✅ **All tests pass** - No breaking changes to existing functionality
The fix addresses the core issue where background cleanup was trying to access database records that had already been deleted due to FK CASCADE constraints. Now the cleanup operates with self-contained data gathered before deletion.
* Improvements to UI during deletion (vibe-kanban 0c14eb91)
Issues:
- If user deletes task while sidebar is open with task details, the task details remain shown
- If task deletion fails all project tasks are hidden and the message "Failed to delete task" is shown, the user has to refresh the page to resolve
* cleanup
* fmt
* fmt
* Perfect! I've successfully added a gear (Settings) icon next to the create task (Plus) icon in the navbar. Here's what I implemented:
## Changes Made
**In `frontend/src/components/layout/navbar.tsx`:**
1. **Added imports**: ProjectForm component and useState hook
2. **Added state management**: `isProjectSettingsOpen` state to control the dialog
3. **Added settings button**: A gear icon button positioned between the "Open in IDE" and "Create Task" buttons
4. **Added dialog**: ProjectForm dialog that opens when the settings button is clicked
5. **Added handlers**: `handleProjectSettingsSuccess` to close the dialog after successful changes
## Key Features
- **Consistent styling**: Uses the same `variant="ghost" size="icon"` styling as other navbar buttons
- **Proper positioning**: Placed logically between IDE and Create Task buttons
- **Conditional rendering**: Only shows when `projectId` is present (same as other project-specific buttons)
- **Accessibility**: Includes proper `aria-label="Project settings"`
- **Full functionality**: Opens the complete ProjectForm with both General settings (setup/dev scripts) and Task Templates tabs
The gear icon now provides immediate access to project settings from any project page, making it much easier to find and modify setup scripts and other project configuration options!
* Perfect! The code has been formatted successfully. Prettier made a small adjustment to the import ordering - it moved the `useState` import to be with the other React imports, which follows the standard convention. The formatting is now clean and follows the project's style guidelines.
The gear icon feature is complete and properly formatted!
## What the fix accomplishes:
1. **Captures the current state** before updating the config
2. **Detects when analytics is newly enabled** - when it changes from `None` (first-time) or `false` (previously disabled) to `true`
3. **Immediately sends `session_start`** for that current session when analytics is enabled
## Now the flow works correctly:
**First-time user:**
- App starts (no session_start - analytics not enabled yet)
- User sees privacy dialog, clicks "Yes"
- Config updated with `analytics_enabled: true`
- **session_start event fires immediately** ✓
- All subsequent events in that session have proper session context
**Returning user (already opted in):**
- App starts → session_start fires from main.rs ✓
- Normal session tracking continues
**User re-enabling analytics:**
- User toggles analytics back on in Settings
- **session_start event fires immediately** ✓
- Session tracking resumes
This ensures every analytics session has a `session_start` event without sending any events before user consent!
* feat: add availability check for coding agents and set smart defaults for new users
* Add executor discovery (vibe-kanban d65d61aa)
Plan: Add executor discovery with appropriate checks
Understanding
You're absolutely right! Checking if npx is available is useless for Opencode/Qwen since it doesn't tell us if those specific agents have been set up. We should follow the pattern used by other executors:
Binary-based executors (like Cursor): Check if the binary exists
NPX-based executors (like Claude, Gemini, Opencode, Qwen): Check for their settings files
Implementation Plan
1. Cursor executor (cursor.rs, after line 407)
Since Cursor uses a standalone binary:
async fn check_availability(&self) -> bool {
utils::shell::resolve_executable_path("cursor-agent").is_some()
}
Import needed: Add shell::resolve_executable_path to the utils import
2. Opencode executor (opencode.rs, after line 188)
Follow the pattern of other NPX-based executors - check for settings file:
async fn check_availability(&self) -> bool {
self.default_mcp_config_path()
.map(|path| path.exists())
.unwrap_or(false)
}
This will check for the opencode.json file in the appropriate location (XDG on Unix, config_dir on Windows).
3. QwenCode executor (qwen.rs, after line 140)
Same approach as other NPX-based executors:
async fn check_availability(&self) -> bool {
self.default_mcp_config_path()
.map(|path| path.exists())
.unwrap_or(false)
}
This will check for ~/.qwen/settings.json.
Why this approach is correct:
Cursor: Has a specific binary that must be installed → check for binary
Opencode/Qwen: Are NPX-based like Claude/Gemini → check for settings files
Consistency: Follows the existing pattern where NPX-based executors check for settings files
Meaningful detection: Settings files indicate the agent has been configured/used before, which is what we want for "availability"
This gives us meaningful availability detection that matches the existing patterns in the codebase.
* Remove duplicated config paths (vibe-kanban 207e0410)
In some executors, like crates/executors/src/executors/amp.rs , Paths for checking availability and mcp server are identical but not reused. We should not duplicate code. Consider changing the default availability check to just check for the mcp config
* feat: implement recommended executor profile retrieval for new users
* fmt
* Easier project creation (vibe-kanban 71f2ce0b)
The current project creation screen is complicated and without any good defaults. We need to make it easier to create projects, offering existing git repos as base.
Easier project creation (vibe-kanban 71f2ce0b)
The current project creation screen is complicated and without any good defaults. We need to make it easier to create projects, offering existing git repos as base.
Easier project creation (vibe-kanban 71f2ce0b)
The current project creation screen is complicated and without any good defaults. We need to make it easier to create projects, offering existing git repos as base.
Better project creation menu (vibe-kanban 0f35d0be)
WHen creating a project from an existing repo, maybe instead of the show more with arrow in the middle we could move that to the right and have a "+ Find" sort of button to the left of it? that would then open the other thing?
Better project creation menu (vibe-kanban 0f35d0be)
WHen creating a project from an existing repo, maybe instead of the show more with arrow in the middle we could move that to the right and have a "+ Find" sort of button to the left of it? that would then open the other thing?
Better project creation menu (vibe-kanban 0f35d0be)
WHen creating a project from an existing repo, maybe instead of the show more with arrow in the middle we could move that to the right and have a "+ Find" sort of button to the left of it? that would then open the other thing?
Fix branch icon (vibe-kanban 59e0ee6e)
We added some stuff to make project creation easier in the last few commits, but now the branch icon for the selected branch goes invisible when selecting one. 
Fix branch icon (vibe-kanban 59e0ee6e)
We added some stuff to make project creation easier in the last few commits, but now the branch icon for the selected branch goes invisible when selecting one. 
Fix branch icon (vibe-kanban 59e0ee6e)
We added some stuff to make project creation easier in the last few commits, but now the branch icon for the selected branch goes invisible when selecting one. 
Fix branch icon (vibe-kanban 59e0ee6e)
We added some stuff to make project creation easier in the last few commits, but now the branch icon for the selected branch goes invisible when selecting one. 
Project creation layout (vibe-kanban 4fbf61c8)
atch the \"New Repository\" structure:\n```tsx\n{/* Display selected repository fields */}\n{selectedPath && selectedRepo && (\n <div className=\"space-y-4\">\n <div className=\"space-y-2\">\n <Label htmlFor=\"base-dir\">Base Directory</Label>\n <div className=\"flex space-x-2\">\n <Input\n id=\"base-dir\"\n type=\"text\"\n value={selectedRepo.path.substring(0, selectedRepo.path.lastIndexOf('/'))}\n disabled\n readOnly\n className=\"flex-1\"\n />\n <Button\n type=\"button\"\n variant=\"ghost\"\n size=\"icon\"\n disabled\n className=\"opacity-50\"\n >\n <Folder className=\"h-4 w-4\" />\n </Button>\n </div>\n </div>\n\n <div className=\"space-y-2\">\n <Label htmlFor=\"repo-name\">Repository Folder Name</Label>\n <Input\n id=\"repo-name\"\n type=\"text\"\n value={selectedRepo.name}\n disabled\n readOnly\n />\n </div>\n </div>\n)}\n```\n\n### Visual Result\n\n**Existing Repository Mode:**\n```\n[Repository Dropdown ▼] [🔍]\n\nBase Directory\n[/path/to/parent] [📁] (disabled)\n\nRepository Folder Name\n[repo-name] (disabled)\n```\n\n**New Repository Mode:**\n```\nParent Directory\n[/path/to/parent] [📁] (editable)\n\nRepository Folder Name\n[repo-name] (editable)\n```\n\n### Benefits\n\n1. **Visual Consistency**: Both modes show the same fields in the same layout\n2. **Clear Distinction**: Disabled/readonly fields for existing repos vs editable for new\n3. **Better Information**: Users can see the base directory and folder name clearly\n4. **Cleaner Design**: No need for special card styling, uses standard form fields\n5. **Intuitive**: The disabled state clearly indicates these are display-only for existing repos\n\n### Technical Notes\n\n- Use `disabled` and `readOnly` props on Input components for existing repos\n- Extract base directory using `substring` and `lastIndexOf('/')`\n- Keep the folder button disabled with `opacity-50` for visual consistency\n- Remove the help text for existing repos since fields are self-explanatory when read-only
Change tabs to align with edit (vibe-kanban 7b589225)
For project creation, the tabs for From git and blank project should have the same appearance as the tabs in edit project
Cleanup changes (vibe-kanban e498187d)
Cleanup the changes made in the last four commits. The changes are good, but there may be unsused things that didnt get cleaned up
Review changes (vibe-kanban 9a859f73)
Make sure the stuff add in the last 6 commits reuses components instead of duplicating, among others look at the tabs/collapsible stuff
Cleanup changes (vibe-kanban e498187d)
Cleanup the changes made in the last commit. The changes are good, but there may be unsused things that didnt get cleaned up, there may be things we remove that shouldve stayed, like the tabnavigation
Project creation submission (vibe-kanban e8fcfd73)
When collapsing things while creating a project, it submits the form instead of collapsing the section
fmt, cleanup
Default parent path (vibe-kanban 9be78842)
For project creation, when creating a blank vk project, we should have a deafault parent path or make it more lear the user has to select one
Default parent path (vibe-kanban 9be78842)
For project creation, when creating a blank vk project, we should have a deafault parent path or make it more lear the user has to select one
Default parent path (vibe-kanban 9be78842)
For project creation, when creating a blank vk project, we should have a deafault parent path or make it more lear the user has to select one
Default parent path (vibe-kanban 9be78842)
For project creation, when creating a blank vk project, we should have a deafault parent path or make it more lear the user has to select one
Default parent path (vibe-kanban 9be78842)
For project creation, when creating a blank vk project, we should have a deafault parent path or make it more lear the user has to select one
Default parent path (vibe-kanban 9be78842)
For project creation, when creating a blank vk project, we should have a deafault parent path or make it more lear the user has to select one
* Update Rust edition to 2024 and refactor project routes for improved clarity
fmt
* Project creation layout (vibe-kanban f726d2e6)
When creating a new project, users should see only the repo selection at first, after selecting one the rest of the options appears.
Remove script options from project creation screen (vibe-kanban 049226af)
Project creation does not need to show script options, these should only be available via edit project.
Better add project (vibe-kanban 79e936bc)
When no projects are available, we should display project creation options right away
Project creation style (vibe-kanban 91bce79b)
The styling of the project creation dialog should be unified with the rest of the project
Review (vibe-kanban 4f8f8068)
Review this PR: https://github.com/BloopAI/vibe-kanban/pull/600
The github cli should work.
Just review, no changes!
fmt
Fix changes lost in rebase
fmt
remove unused collapsible section, remove duplicate default repo path
Re-add detailed script descriptions
* Stream tasks and execution processes (vibe-kanban cd4106c5)
Building on the unused /events endpoint, can we please add a /stream variant to the following endpoints:
/tasks?project_id=...
/execution_processes?task_attempt_id=...
The endpoint should return an initial document containing all the entities given the filter, and then subsequent patches to keep the document up to date.
Refactor the codebase however you see fit to give us the most maintainable code going forwards.
crates/server/src/routes/tasks.rs
crates/server/src/routes/execution_processes.rs
crates/server/src/routes/events.rs
* Issues with streaming tasks (vibe-kanban e1779942)
crates/services/src/services/events.rs
crates/server/src/routes/tasks.rs
We should modify the stream of tasks (filtered by project) to be an object where each task is a key. This will make it much easier to produce stream diffs
* Issues with streaming tasks (vibe-kanban e1779942)
crates/services/src/services/events.rs
crates/server/src/routes/tasks.rs
We should modify the stream of tasks (filtered by project) to be an object where each task is a key. This will make it much easier to produce stream diffs
* Refactor project tasks (vibe-kanban 20b19eb8)
Project tasks needs to be refactored:
- Doesn't follow new pattern of separating network logic into hooks
- Has legacy fixed time poll for refetching tasks, but there is now a tasks/stream endpoint
* revert changes to execution processes
* Make variants an object rather than array (vibe-kanban 63213864)
Profile variants should be an object, with key used instead of the current label.
The code should be refactored leaving no legacy trace.
crates/server/src/routes/config.rs
crates/executors/src/profile.rs
* Make variants an object rather than array (vibe-kanban 63213864)
Profile variants should be an object, with key used instead of the current label.
The code should be refactored leaving no legacy trace.
crates/server/src/routes/config.rs
crates/executors/src/profile.rs
* Remove the command builder from profiles (vibe-kanban d30abc92)
It should no longer be possible to customise the command builder in profiles.json.
Instead, anywhere where the command is customised, the code should be hardcoded as an enum field on the executor, eg claude code vs claude code router on the claude code struct.
crates/executors/src/profile.rs
crates/executors/src/executors/claude.rs
* fmt
* Refactor Qwen log normalization (vibe-kanban 076fdb3f)
Qwen basically uses the same log normalization as Gemini, can you refactor the code to make it more reusable.
A similar example exists in Amp, where we use Claude's log normalization.
crates/executors/src/executors/amp.rs
crates/executors/src/executors/qwen.rs
crates/executors/src/executors/claude.rs
* Add field overrides to executors (vibe-kanban cc3323a4)
We should add optional fields 'base_command_override' (String) and 'additional_params' (Vec<String>) to each executor, and wire these fields up to the command builder
* Update profiles (vibe-kanban e7545ab6)
Redesign the profile configuration storage system to store only differences from defaults instead of complete profile files. Implement partial profile functions (create_partial_profile, load_from_partials, save_as_diffs) that save human-readable partial profiles containing only changed values. Update ProfileConfigs::load() to handle the new partial format while maintaining backward compatibility with legacy full profile formats through automatic migration that creates backups. Implement smart variants handling that only stores changed, added, or removed variants rather than entire arrays. Fix the profile API consistency issue by replacing the manual file loading logic in the get_profiles() endpoint in crates/server/src/routes/config.rs with ProfileConfigs::get_cached() to ensure the GET endpoint uses the same cached data that PUT updates. Add comprehensive test coverage for all new functionality.
* Yolo mode becomes a field (vibe-kanban d8dd02f0)
Most executors implement some variation of yolo-mode, can you make this boolean field on each executor (if supported), where the name for the field aligns with the CLI field
* Change ClaudeCodeVariant to boolean (vibe-kanban cc05956f)
Instead of an enum ClaudeCodeVariant, let's use a variable claude_code_router to determine whether to use claude_code_router's command. If the user has also supplied a base_command_override this should take precedence (also write a warning to console)
crates/executors/src/executors/claude.rs
* Remove mcp_config_path from profile config (vibe-kanban 6c1e5947)
crates/executors/src/profile.rs
* One profile per executor (vibe-kanban b0adc27e)
Currently you can define arbitrary profiles, multiple profiles per executor. Let's refactor to simplify this configuration, instead we should only be able to configure one profile per executor.
The new format should be something like:
```json
{
"profiles": {
"CLAUDE_CODE": {
"default": {
"plan": false,
"dangerously_skip_permissions": true,
"append_prompt": null
},
"plan": {
"plan": true,
"dangerously_skip_permissions": false,
"append_prompt": null
}
}
}
}
```
Each profile's defaults should be defined as code instead of in default_profiles.json
profile.json will now contain:
- Overrides for default configurations
- Additional user defined configurations, for executors
It is not possible to remove a default configuration entirely, just override the configuration.
The user profile.json should still be a minimal set of overrides, to make upgrading easy.
Don't worry about migration, this will be done manually.
crates/executors/default_profiles.json
crates/executors/src/profile.rs
* SCREAMING_SNAKE_CASE
* update profile.rs
* config migration
* fmt
* delete binding
* config keys
* fmt
* shared types
* Profile variants should be saved as SCREAMING_SNAKE_CASE (vibe-kanban 5c6c124c)
crates/executors/src/profile.rs save_overrides
* rename default profiles
* remove defaulted executor fields
* backwards compatability
* fix legacy variants
* Update useDevServer to use tanstack (vibe-kanban a5e7cb20)
We are migrating the frontend to use Tanstack query. We should make radical changes in order to improve readability and performance.
See an example in frontend/src/hooks/useRebase.ts
Please plan how to modernise the frontend/src/hooks/useDevServer.ts hook
* Deprecate useExecutionProcesses → Replace with useAttemptExecution (vibe-kanban 5123ff1e)
* Perfect! I've successfully added a big banner above the navbar that appears when the frontend is running in dev mode. Here's what I implemented:
## Changes Made:
1. **Created a new `DevBanner` component** (`frontend/src/components/DevBanner.tsx`):
- Only renders when `import.meta.env.MODE === 'development'`
- Features an orange background with white text and an alert triangle icon
- Displays "Development Mode - This is a development build"
2. **Updated `App.tsx`** to include the banner:
- Added the import for the DevBanner component
- Positioned the banner above the navbar with the same conditional rendering logic
## Key Features:
- **Conditional Rendering**: The banner only appears in development mode using Vite's `import.meta.env.MODE`
- **Prominent Styling**: Orange background with white text and an alert icon for high visibility
- **Proper Positioning**: Appears above the navbar but below other UI elements
- **Consistent with Existing Code**: Uses the same dev mode detection pattern already used in the codebase
The banner will now be clearly visible to developers whenever they run the frontend in development mode, helping them distinguish between development and production builds. The implementation passed TypeScript type checking and follows the existing code patterns in the project.
* Cleanup script changes for task attempt 5ec194cd-4a78-4b25-a7b7-66ad1b366431
* ## ✅ Implementation Complete!
I've successfully implemented the duplicate task feature. Here's what was accomplished:
### **Changes Made:**
1. **TaskDialogContext (`frontend/src/contexts/task-dialog-context.tsx`)**
- Added `initialTask: Task | null` to dialog state
- Created `openDuplicate(task, options)` method that opens create dialog with initial data
- Updated all existing methods to include initialTask field
2. **TaskFormDialog (`frontend/src/components/tasks/TaskFormDialog.tsx`)**
- Added `initialTask?: Task | null` prop
- Enhanced prefill logic with priority: Edit → Duplicate → Template → Empty
- Duplicated tasks reset status to 'todo' and start with no images
3. **TaskCard (`frontend/src/components/tasks/TaskCard.tsx`)**
- Added Copy icon import
- Added `onDuplicate?: (task: Task) => void` prop
- Added "Duplicate" menu item with Copy icon between Edit and Delete
4. **TaskKanbanBoard (`frontend/src/components/tasks/TaskKanbanBoard.tsx`)**
- Added `onDuplicateTask?: (task: Task) => void` prop
- Passed duplicate handler through to TaskCard components
5. **ProjectTasks (`frontend/src/pages/project-tasks.tsx`)**
- Added `openDuplicate` to useTaskDialog destructuring
- Created `handleDuplicateTask` function
- Passed duplicate handler to TaskKanbanBoard
6. **TaskFormDialogContainer (`frontend/src/components/tasks/TaskFormDialogContainer.tsx`)**
- Added `initialTask={dialogState.initialTask}` prop to TaskFormDialog
### **How It Works:**
1. **User clicks** the "⋯" menu on any task card
2. **Sees "Duplicate"** option with copy icon between Edit and Delete
3. **Clicks Duplicate** → opens create task dialog with:
- Title and description pre-filled from original task
- Status reset to 'todo'
- No images (clean slate)
- User can modify and create as normal
### **Key Design Decisions:**
- **Treated as create mode** (not edit) - follows Oracle's recommendation
- **Status always resets to 'todo'** for duplicated tasks
- **No images copied** - simple and safe approach
- **Clean integration** with existing template system
The implementation passes all TypeScript checks and follows the existing codebase patterns. The feature is ready to use!
* Cleanup script changes for task attempt 16b21999-278c-414d-aaab-ae5767d42d77
