## Context

Tool instances (like VS Code Server, Jupyter notebooks) need a type system to define what development tools can be launched. The current system has projects and repositories but no way to define what tools can run against them. Tool types will provide Docker Compose templates that can be instantiated with project-specific variables.

## Goals / Non-Goals

**Goals:**
- Create a `ToolType` model to store tool definitions with Docker Compose templates
- Provide CRUD API endpoints for tool type management
- Implement template variable substitution (e.g., `{{REPO_PATH}}`, `{{PROJECT_NAME}}`)
- Include built-in tool types (code-server, jupyter-notebook)
- Validate Docker Compose templates on creation/update

**Non-Goals:**
- Actually launching/running tool instances (that's a separate feature)
- Complex template logic (loops, conditionals) - simple variable substitution only
- Tool type versioning or history

## Decisions

1. **Store Docker Compose templates as YAML strings in the database**
   - Rationale: Flexibility - templates can contain any valid Docker Compose config
   - Alternative: Normalized table structure. Rejected because Compose configs are too varied.

2. **Use Jinja2-style variable substitution with double braces `{{VAR}}`**
   - Rationale: Familiar syntax, easy to parse
   - Variables: `{{REPO_PATH}}`, `{{PROJECT_NAME}}`, `{{USER_ID}}`, `{{TOOL_NAME}}`

3. **Built-in tool types seeded on first startup**
   - Rationale: Users should have common tools available immediately
   - Can be disabled via env var if desired

4. **Simple validation: check template is valid YAML with required variables**
   - Rationale: Full Docker Compose validation is complex and error-prone
   - We validate structure and required vars, not runtime behavior

## Risks / Trade-offs

- **[Invalid templates]** → Validation catches YAML syntax errors and missing required vars
- **[Template injection]** → Only admin users can create/edit tool types
- **[Storage size]** → Templates are small YAML files, negligible impact

## Migration Plan

1. Create `tool_types` table via Alembic migration
2. Add API module for CRUD operations
3. Add frontend page for management
4. Seed built-in types on startup

Rollback:
- Drop `tool_types` table
- Remove API endpoints

## Open Questions

- Should tool types be global or per-user?
  - Decision: Global with admin-only creation, users can view all
