diff --git a/apps/api/src/main.py b/apps/api/src/main.py index 757ea41..3460167 100644 --- a/apps/api/src/main.py +++ b/apps/api/src/main.py @@ -180,11 +180,11 @@ services: ports: - "3000:3000" command: > - sh -c "apt-get update && apt-get install -y curl git && + sh -c "apt-get update && apt-get install -y curl git tar && curl -fsSL https://opencode.ai/install | bash && - export PATH=\"$HOME/.local/bin:$PATH\" && + ln -sf $HOME/.opencode/bin/opencode /usr/local/bin/opencode && mkdir -p /workspace && - echo 'OpenCode installed. Use the Terminal button to start opencode.' && + echo 'OpenCode installed. Run: opencode' && tail -f /dev/null" stdin_open: true tty: true diff --git a/openspec/changes/tool-config-ui-rework/.openspec.yaml b/openspec/changes/tool-config-ui-rework/.openspec.yaml new file mode 100644 index 0000000..8b76914 --- /dev/null +++ b/openspec/changes/tool-config-ui-rework/.openspec.yaml @@ -0,0 +1,2 @@ +schema: spec-driven +created: 2026-05-20 diff --git a/openspec/changes/tool-config-ui-rework/design.md b/openspec/changes/tool-config-ui-rework/design.md new file mode 100644 index 0000000..ef05ff5 --- /dev/null +++ b/openspec/changes/tool-config-ui-rework/design.md @@ -0,0 +1,39 @@ +## Context + +The current tool configuration page at `/tool-configs` uses a simple flat list with dropdown selection. Each config only has `key`, `value`, `config_type`, and `file_path` fields. Users have requested: +1. A split-pane layout (list on left, detail on right) for better navigation +2. Additional configuration options like start command, port, working directory +3. Better organization of environment variables and volume mounts + +## Goals / Non-Goals + +**Goals:** +- Implement split-pane layout with tool config list on left and detail/edit panel on right +- Add new fields to tool config model: `start_command`, `port`, `working_directory`, `environment_variables`, `volumes` +- Support JSON editing for complex fields (environment variables, volumes) +- Maintain backward compatibility with existing configs +- Improve UX for managing multiple tool configurations + +**Non-Goals:** +- Changing the underlying Docker/container runtime behavior +- Adding new tool types +- Modifying the tool instance creation flow beyond config injection +- Real-time collaboration on configs + +## Decisions + +1. **Split-pane layout**: Use a responsive 2-column layout (30/70 split) that stacks on mobile. Left panel shows scrollable list of configs grouped by tool type. Right panel shows form for selected config. + +2. **New fields as JSON columns**: Store `environment_variables` and `volumes` as JSON in PostgreSQL to allow flexible key-value structures without rigid schema changes. + +3. **Port field**: Store as integer with validation (1-65535). Null means "use tool type default". + +4. **Form design**: Use tabs or sections within the right panel to organize: Basic (key, value), Runtime (start_command, port, working_directory), Advanced (env vars, volumes). + +5. **Validation**: Validate JSON structure on backend before saving. Show clear error messages in the UI. + +## Risks / Trade-offs + +- **Migration complexity**: Existing configs need default values for new columns. Mitigation: All new fields are nullable with sensible defaults. +- **JSON editing UX**: Raw JSON editing is error-prone. Mitigation: Provide structured key-value editors that generate JSON under the hood. +- **Mobile experience**: Split-pane may be cramped on small screens. Mitigation: Stack panels vertically on mobile breakpoints. \ No newline at end of file diff --git a/openspec/changes/tool-config-ui-rework/proposal.md b/openspec/changes/tool-config-ui-rework/proposal.md new file mode 100644 index 0000000..e0cc107 --- /dev/null +++ b/openspec/changes/tool-config-ui-rework/proposal.md @@ -0,0 +1,28 @@ +## Why + +The current tool configuration page (`/tool-configs`) presents all configs in a flat list with a basic form. As the number of tool types and configuration options grows, this becomes unwieldy. Users need a more organized way to browse, edit, and manage configurations per tool type. + +## What Changes + +- **Rework the tool config UI** from a flat list to a **split-pane layout**: list of tool configs on the left, detail/edit panel on the right +- **Add new config fields**: `start_command`, `port`, `working_directory`, `environment_variables` (JSON), `volumes` (JSON) +- **Update backend model** to support these new fields +- **Create database migration** for the new columns +- **Update API endpoints** to handle new fields +- **Update frontend types and API client** +- **Redesign the page** with proper navigation and editing experience + +## Capabilities + +### New Capabilities +- `tool-config-management`: Enhanced tool configuration management with extended fields and split-pane UI + +### Modified Capabilities +- `tool-types`: Tool type display will show associated configs in the new UI (presentation layer change only, no API changes) + +## Impact + +- **Backend**: `tool_configs` model, API endpoints, database migration +- **Frontend**: Complete rework of `ToolConfigsPage` component, new types, updated API client +- **Database**: New columns on `tool_configs` table +- **User Experience**: Significantly improved configuration management workflow \ No newline at end of file diff --git a/openspec/changes/tool-config-ui-rework/specs/tool-config-management/spec.md b/openspec/changes/tool-config-ui-rework/specs/tool-config-management/spec.md new file mode 100644 index 0000000..9f8012a --- /dev/null +++ b/openspec/changes/tool-config-ui-rework/specs/tool-config-management/spec.md @@ -0,0 +1,53 @@ +## ADDED Requirements + +### Requirement: Tool config supports runtime fields +The system SHALL support additional configuration fields for tool instances: `start_command`, `port`, `working_directory`, `environment_variables`, and `volumes`. + +#### Scenario: Create config with runtime fields +- **WHEN** user creates a tool config with start_command="npm start", port=3000, working_directory="/app" +- **THEN** the config is saved with all fields populated + +#### Scenario: Environment variables as JSON +- **WHEN** user sets environment_variables to {"NODE_ENV": "production", "API_KEY": "secret"} +- **THEN** the system stores and returns the config with the JSON object preserved + +#### Scenario: Volumes as JSON +- **WHEN** user sets volumes to [{"host": "/data", "container": "/app/data", "mode": "rw"}] +- **THEN** the system stores and returns the config with the JSON array preserved + +### Requirement: Split-pane UI for tool configs +The system SHALL present tool configs in a split-pane layout with a list on the left and detail/edit panel on the right. + +#### Scenario: Browse tool configs +- **WHEN** user navigates to /tool-configs +- **THEN** the left panel displays a scrollable list of all tool configs grouped by tool type + +#### Scenario: Select config to edit +- **WHEN** user clicks on a config in the left panel +- **THEN** the right panel displays the config details in an editable form + +#### Scenario: Create new config +- **WHEN** user clicks "New Config" button +- **THEN** a blank form appears in the right panel for creating a new config + +### Requirement: JSON editor for complex fields +The system SHALL provide user-friendly editors for JSON fields (environment_variables and volumes) that validate JSON syntax. + +#### Scenario: Valid JSON input +- **WHEN** user enters valid JSON in the environment_variables field +- **THEN** the form accepts the input and shows a green indicator + +#### Scenario: Invalid JSON input +- **WHEN** user enters invalid JSON in the environment_variables field +- **THEN** the form shows a red error indicator and prevents saving + +### Requirement: Config validation +The system SHALL validate tool config fields before saving. + +#### Scenario: Invalid port number +- **WHEN** user enters port=70000 +- **THEN** the system rejects the config with error "Port must be between 1 and 65535" + +#### Scenario: Missing required fields +- **WHEN** user attempts to save a config without key or tool_type_id +- **THEN** the system rejects the config with error "Key is required" \ No newline at end of file diff --git a/openspec/changes/tool-config-ui-rework/tasks.md b/openspec/changes/tool-config-ui-rework/tasks.md new file mode 100644 index 0000000..2564a99 --- /dev/null +++ b/openspec/changes/tool-config-ui-rework/tasks.md @@ -0,0 +1,59 @@ +## 1. Database Migration + +- [ ] 1.1 Create Alembic migration to add new columns to tool_configs table +- [ ] 1.2 Add columns: start_command (text), port (integer), working_directory (text), environment_variables (jsonb), volumes (jsonb) +- [ ] 1.3 Run migration locally and verify + +## 2. Backend Model Updates + +- [ ] 2.1 Update ToolConfig model with new fields +- [ ] 2.2 Update Pydantic schemas (ToolConfigCreate, ToolConfigResponse) +- [ ] 2.3 Add validation for port range (1-65535) +- [ ] 2.4 Add JSON validation for environment_variables and volumes + +## 3. Backend API Updates + +- [ ] 3.1 Update list_configs endpoint to return new fields +- [ ] 3.2 Update create_config endpoint to accept new fields +- [ ] 3.3 Update update_config endpoint to handle new fields +- [ ] 3.4 Add validation error handling with clear messages + +## 4. Frontend Types and API + +- [ ] 4.1 Update ToolConfig interface with new fields +- [ ] 4.2 Update API client functions to handle new fields +- [ ] 4.3 Add type definitions for JSON fields + +## 5. Frontend UI - Split Pane Layout + +- [ ] 5.1 Create split-pane layout component (left list, right detail) +- [ ] 5.2 Implement left panel: scrollable list grouped by tool type +- [ ] 5.3 Implement right panel: detail/edit form with tabs/sections +- [ ] 5.4 Add responsive design (stack on mobile) +- [ ] 5.5 Add "New Config" button and blank form state + +## 6. Frontend UI - Form Fields + +- [ ] 6.1 Add Basic section: key, value, config_type, file_path +- [ ] 6.2 Add Runtime section: start_command, port, working_directory +- [ ] 6.3 Add Advanced section: environment_variables (JSON editor) +- [ ] 6.4 Add Advanced section: volumes (JSON editor) +- [ ] 6.5 Implement JSON validation with visual feedback +- [ ] 6.6 Add form validation and error display + +## 7. Integration and Testing + +- [ ] 7.1 Test creating config with all new fields +- [ ] 7.2 Test updating existing config +- [ ] 7.3 Test JSON validation (valid/invalid cases) +- [ ] 7.4 Test responsive layout on different screen sizes +- [ ] 7.5 Verify backward compatibility with old configs + +## 8. Quality Gates + +- [ ] 8.1 Run backend linting (ruff) +- [ ] 8.2 Run backend type checking (mypy) +- [ ] 8.3 Run frontend type checking (tsc) +- [ ] 8.4 Run frontend linting (eslint) +- [ ] 8.5 Build frontend and verify +- [ ] 8.6 Commit and push changes \ No newline at end of file