feat(tool-config): add categories, interfaces, and config management
Add support for tool categories, interface types, and per-tool configuration. Backend: - Add category and interfaces fields to ToolType model - Create ToolConfig model for storing tool-specific settings - Add tool_configs API endpoints (CRUD) - Update built-in tool types with categories and interfaces: - code-server: editor, [web] - jupyter-notebook: notebook, [web] - opencode: ai-assistant, [terminal] - Update instance API to include tool type interfaces - Create Alembic migrations 0008 and 0009 Frontend: - Update ToolType and Session interfaces with new fields - Conditionally show Open/Terminal buttons based on tool interfaces - Add API client for tool configs OpenSpec: tool-config-management change created and implemented.
This commit is contained in:
Fusion
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-05-20
|
||||
@@ -0,0 +1,65 @@
|
||||
## Context
|
||||
|
||||
Tool instances currently start with hardcoded compose templates. There's no way for users to provide API keys (OpenAI, Anthropic), custom settings, or files that tools need. We need a flexible config system that supports both environment variables and file-based configs.
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
**Goals:**
|
||||
- Store tool configs per user (global) and per project
|
||||
- Support env vars and file-based configs
|
||||
- Mount configs into containers at startup
|
||||
- Add tool categories (editor, notebook, ai-assistant)
|
||||
- Add interface types (web, terminal) to control UI
|
||||
- Add OpenCode as built-in terminal tool
|
||||
|
||||
**Non-Goals:**
|
||||
- Secret encryption at rest (for now)
|
||||
- Config validation beyond basic type checking
|
||||
- Per-instance configs (only global and project-scoped)
|
||||
|
||||
## Decisions
|
||||
|
||||
### Config scope: user-global and user+project
|
||||
|
||||
**Decision:** Two scopes - global (user-level) and project-specific (user+project level)
|
||||
|
||||
**Rationale:** Some configs (like OpenAI API key) are user-global. Others (like project-specific paths) are per-project.
|
||||
|
||||
### Config types: env and file
|
||||
|
||||
**Decision:** Support two config types: `env` (injected as environment variables) and `file` (written to files and mounted)
|
||||
|
||||
**Rationale:** Most tools need env vars. Some (like OpenCode) need config files.
|
||||
|
||||
### Tool categories as enum
|
||||
|
||||
**Decision:** Predefined categories: `editor`, `notebook`, `ai-assistant`, `other`
|
||||
|
||||
**Rationale:** Simple, predictable, drives UI behavior.
|
||||
|
||||
### Interfaces as array
|
||||
|
||||
**Decision:** ToolType.interfaces is a JSON array of strings: `["web"]`, `["terminal"]`, `["web", "terminal"]`
|
||||
|
||||
**Rationale:** Flexible, allows combination interfaces.
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
**[Risk]** Config files in container filesystem are readable by any process in container
|
||||
→ **Mitigation:** Document this. Future: use Docker secrets for sensitive values.
|
||||
|
||||
**[Risk]** Storing API keys in plain text in database
|
||||
→ **Mitigation:** Acceptable for MVP. Future: encrypt sensitive configs.
|
||||
|
||||
## Migration Plan
|
||||
|
||||
1. Create migrations for tool_types (category, interfaces) and tool_configs tables
|
||||
2. Update seed data for built-in types
|
||||
3. Deploy backend changes
|
||||
4. Update frontend to show categories and config UI
|
||||
5. Test with OpenCode instance
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Should we encrypt sensitive configs now or later?
|
||||
- Do we need config templates/tooling per tool type?
|
||||
@@ -0,0 +1,26 @@
|
||||
## Why
|
||||
|
||||
Tool instances need configuration (API keys, settings, files) that varies by user and project. Currently there's no way to manage these configs. Users need to store LLM API keys, editor preferences, and tool-specific settings that get mounted into containers at runtime.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Add ToolConfig model for storing key-value configs per user/project/tool
|
||||
- Add category and interfaces fields to ToolType model
|
||||
- Create API for managing tool configs (global and project-scoped)
|
||||
- Mount configs into containers when starting instances
|
||||
- Add OpenCode as built-in tool type with terminal interface
|
||||
- Update frontend to show tool categories and interface-appropriate actions
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
- `tool-config-management`: Store and manage tool configurations
|
||||
- `tool-categories`: Categorize tools and expose appropriate interfaces
|
||||
|
||||
### Modified Capabilities
|
||||
- `tool-types`: Add category and interfaces fields
|
||||
|
||||
## Impact
|
||||
- Backend: New model, API endpoints, container startup changes
|
||||
- Frontend: Config management UI, category display
|
||||
- Database: New tool_configs table, migrations for tool_types
|
||||
@@ -0,0 +1,46 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Tool configs can be stored per user
|
||||
The system SHALL allow users to store configuration values for tool types.
|
||||
|
||||
#### Scenario: Save global config
|
||||
- **WHEN** a user saves a config value for a tool type
|
||||
- **THEN** the config is stored with user_id and tool_type_id
|
||||
- **AND** it is available for all future instances of that tool
|
||||
|
||||
#### Scenario: Save project-specific config
|
||||
- **WHEN** a user saves a config value with a project_id
|
||||
- **THEN** the config is scoped to that project
|
||||
- **AND** it overrides global config for that project
|
||||
|
||||
### Requirement: Configs support env and file types
|
||||
The system SHALL support environment variable configs and file-based configs.
|
||||
|
||||
#### Scenario: Env config
|
||||
- **WHEN** a config has type "env"
|
||||
- **THEN** it is injected as an environment variable when starting the container
|
||||
|
||||
#### Scenario: File config
|
||||
- **WHEN** a config has type "file"
|
||||
- **THEN** it is written to a file in the container
|
||||
- **AND** the file path is configurable
|
||||
|
||||
### Requirement: Tool types have categories and interfaces
|
||||
The system SHALL categorize tool types and declare their interfaces.
|
||||
|
||||
#### Scenario: Web interface tool
|
||||
- **WHEN** a tool type has interface "web"
|
||||
- **THEN** the UI shows an "Open" button
|
||||
|
||||
#### Scenario: Terminal interface tool
|
||||
- **WHEN** a tool type has interface "terminal"
|
||||
- **THEN** the UI shows a "Terminal" button
|
||||
|
||||
### Requirement: OpenCode is available as built-in tool
|
||||
The system SHALL include OpenCode as a built-in tool type with terminal interface.
|
||||
|
||||
#### Scenario: Create OpenCode instance
|
||||
- **WHEN** a user creates an OpenCode instance
|
||||
- **THEN** it starts a container with opencode installed
|
||||
- **AND** the repo is mounted at /workspace
|
||||
- **AND** the user can access it via terminal
|
||||
@@ -0,0 +1,42 @@
|
||||
## 1. Database & Models
|
||||
|
||||
- [ ] 1.1 Add category and interfaces fields to ToolType model
|
||||
- [ ] 1.2 Create ToolConfig model with user/project/tool scopes
|
||||
- [ ] 1.3 Create Alembic migrations for tool_types and tool_configs
|
||||
|
||||
## 2. Backend - Tool Config API
|
||||
|
||||
- [ ] 2.1 Create GET/POST/PUT/DELETE endpoints for tool configs
|
||||
- [ ] 2.2 Support global and project-scoped configs
|
||||
- [ ] 2.3 Mount configs into containers when starting instances
|
||||
- [ ] 2.4 Update start_instance to inject env vars and write files
|
||||
|
||||
## 3. Backend - Tool Type Updates
|
||||
|
||||
- [ ] 3.1 Update ToolType API to include category and interfaces
|
||||
- [ ] 3.2 Update seed data with categories and interfaces
|
||||
- [ ] 3.3 Add OpenCode as built-in tool type
|
||||
|
||||
## 4. Frontend - Tool Config UI
|
||||
|
||||
- [ ] 4.1 Create tool config management page/component
|
||||
- [ ] 4.2 Support env var and file config types
|
||||
- [ ] 4.3 Show configs per tool type with global/project toggle
|
||||
|
||||
## 5. Frontend - Category & Interface Support
|
||||
|
||||
- [ ] 5.1 Display tool categories in lists
|
||||
- [ ] 5.2 Show interface-appropriate actions (Open for web, Terminal for CLI)
|
||||
- [ ] 5.3 Update instance list to check interfaces
|
||||
|
||||
## 6. OpenCode Integration
|
||||
|
||||
- [ ] 6.1 Create OpenCode compose template
|
||||
- [ ] 6.2 Ensure terminal access works
|
||||
- [ ] 6.3 Mount repo and configs correctly
|
||||
|
||||
## 7. Quality Gates
|
||||
|
||||
- [ ] 7.1 Run ruff and mypy
|
||||
- [ ] 7.2 Run frontend typecheck and lint
|
||||
- [ ] 7.3 Test end-to-end
|
||||
Reference in New Issue
Block a user