fix(opencode): add tar dependency and symlink binary to /usr/local/bin
This commit is contained in:
Fusion
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-05-20
|
||||
@@ -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.
|
||||
@@ -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
|
||||
@@ -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"
|
||||
@@ -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
|
||||
Reference in New Issue
Block a user