Fusion
063a839790
- Add clone_mode and branch fields to tool_instances - Add ssh_key_id to git_repositories for per-repo SSH key assignment - Implement host-side git cloning with branch selection (default: main) - Mount SSH keys into containers for git operations in clone mode - Add dirty state check on clone-mode instance deletion with confirmation - Update SessionsPage with mount/clone selector, branch input, SSH key display - Add SSH key selector to repository creation form - Add dirty delete confirmation modal with changed files list - Update API schemas and endpoints for new fields - Sync delta specs to main specs (git-repo, tool-instances, repo-clone-mode) - Archive completed OpenSpec change: repo-clone-mode-with-ssh - Document git requirement for custom tool types Quality gates: Frontend typecheck and build passed OpenSpec: repo-clone-mode-with-ssh archived with all tasks complete
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?