Fusion
8dd350286e
- Add Docker Compose and Dockerfile support for tool definitions - Implement readiness probes with configurable command, timeout, interval - Create ConfigFolder model for reusable file collections with project overrides - Add rich tool config fields: port_override, start_command, working_directory, env vars, volumes - Build unified Tool Workshop UI at /tool-workshop replacing /tool-configs and /tool-types - Update instance creation to support dockerfile builds, config folder mounting, readiness probes - Add 3 database migrations for tool_types, tool_configs, and new config_folders table - Create docker_build.py and readiness_probe.py services - Add config_folders API with CRUD and project override endpoints Quality gates: frontend build passes, Python syntax valid, all phases complete Addresses tool-workshop OpenSpec change
3.6 KiB
3.6 KiB
Capability: Tool Workshop
Overview
The Tool Workshop is the unified interface for defining, configuring, and managing development tools. It consolidates tool type management, tool configuration, and config folder management into a single powerful interface.
Functional Requirements
FR-1: Tool Type Definition
- Users can create new tool types with either Docker Compose or Dockerfile
- Tool types specify: name, display name, description, category, interfaces, port, definition type, template
- Built-in tool types can be viewed but not edited
- Tool types can be deleted (with cascade deletion of associated configs)
FR-2: Tool Configuration
- Users can create tool configurations per tool type
- Configs can be global (all projects) or project-scoped
- Configs support: key-value pairs (env/file), port override, start command, working directory, environment variables, volumes
- Configs are mounted into containers when instances are created
FR-3: Config Folder Management
- Users can create named collections of configuration files
- Each folder has a default mount path in containers
- Folders can be activated/deactivated
- Folders support per-project overrides
- Active folders are automatically mounted into new instances
FR-4: Readiness Probes
- Tool types can define a readiness probe command
- Instance creation waits for the probe to succeed
- Probes have configurable timeout and check interval
- Failed probes mark instances as "failed" with logs
FR-5: Instance Integration
- Instance creation uses tool type definition (compose or dockerfile)
- Instance creation applies tool configs (env vars, files, volumes)
- Instance creation mounts active config folders
- Instance creation executes readiness probe
- Instance status reflects probe result
Non-Functional Requirements
NFR-1: Performance
- Tool Workshop page loads in < 2 seconds
- Config folder operations complete in < 500ms
- Instance creation with dockerfile build completes in < 5 minutes
NFR-2: Usability
- UI is intuitive for both technical and non-technical users
- Clear validation messages for all fields
- Progressive disclosure of advanced options
- Responsive design for mobile devices
NFR-3: Security
- Users can only access their own tool types, configs, and folders
- File paths in config folders are sanitized (no path traversal)
- Dockerfile builds run in isolated context
- Config values are never logged or exposed
State Diagram
┌─────────────┐
│ DRAFT │
└──────┬──────┘
│ Create
▼
┌─────────────┐ Edit ┌─────────────┐
│ ACTIVE │◀────────────▶│ UPDATED │
└──────┬──────┘ └─────────────┘
│
│ Delete
▼
┌─────────────┐
│ DELETED │
└─────────────┘
API Specification
See design.md for complete endpoint list.
UI Specification
See design.md for complete UI mockups.
Acceptance Criteria
- User can create a tool type with dockerfile and start an instance
- User can create a tool type with compose and start an instance
- User can create config folders and mount them into instances
- User can set project overrides on config folders
- Readiness probes wait for tools to be ready before marking running
- Failed readiness probes show clear error messages
- All new fields are persisted and retrieved correctly
- UI is responsive and intuitive