Fusion
63ae706dd0
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.
2.3 KiB
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
- Create migrations for tool_types (category, interfaces) and tool_configs tables
- Update seed data for built-in types
- Deploy backend changes
- Update frontend to show categories and config UI
- Test with OpenCode instance
Open Questions
- Should we encrypt sensitive configs now or later?
- Do we need config templates/tooling per tool type?