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.
65 lines
2.3 KiB
Markdown
65 lines
2.3 KiB
Markdown
## 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? |