fix(opencode): add tar dependency and symlink binary to /usr/local/bin

2026-05-20 17:48:36 +02:00
parent f07a632c86
commit f2c3264be6
6 changed files with 184 additions and 3 deletions
@@ -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
@@ -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