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
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? |