## ADDED Requirements

### Requirement: Tool Type Model

The system SHALL provide a `ToolType` model to store tool definitions.

#### Scenario: Model structure
- GIVEN a tool type definition
- THEN the model SHALL have:
  - `id`: UUID primary key
  - `name`: unique string (e.g., "code-server")
  - `display_name`: human-readable string (e.g., "VS Code Server")
  - `description`: optional text
  - `category`: string (e.g., "editor", "notebook")
  - `interface_type`: single string — "web" or "terminal"
  - `requires_port`: boolean indicating if port/tunnel configuration is needed
  - `compose_template`: Docker Compose YAML string
  - `dockerfile_template`: Dockerfile string
  - `definition_type`: string — "compose" or "dockerfile"
  - `required_variables`: list of required template variables
  - `startup_command`: optional text — command to run before interactive shell for terminal sessions
  - `is_builtin`: boolean flag for system-defined types
  - `created_at`/`updated_at`: timestamps

### Requirement: CRUD API Endpoints

The system SHALL provide REST API endpoints for tool type management.

#### Scenario: List tool types
- GIVEN an authenticated user
- WHEN they GET /api/tool-types
- THEN the system returns all tool types (built-in and custom)
- AND returns 200 OK

#### Scenario: Create tool type
- GIVEN an admin user
- WHEN they POST /api/tool-types with valid data
- THEN the system creates a new tool type
- AND validates `interface_type` is "web" or "terminal"
- AND validates `requires_port` is boolean
- AND validates the compose template YAML (if definition_type is "compose")
- AND validates all required variables are present in template
- AND accepts optional `startup_command` field
- AND returns 201 Created with the new tool type

#### Scenario: Get tool type
- GIVEN an authenticated user
- WHEN they GET /api/tool-types/{id}
- THEN the system returns the tool type details
- AND returns 200 OK

#### Scenario: Update tool type
- GIVEN an admin user
- WHEN they PUT /api/tool-types/{id} with valid data
- THEN the system updates the tool type
- AND accepts optional `startup_command` field
- AND returns 200 OK with updated tool type

#### Scenario: Get tool type includes startup command
- GIVEN an authenticated user
- WHEN they GET /api/tool-types/{id}
- THEN the response includes `startup_command` if set

#### Scenario: Delete tool type
- GIVEN an admin user
- WHEN they DELETE /api/tool-types/{id}
- THEN the system deletes the tool type
- AND prevents deletion of built-in types
- AND returns 204 No Content

### Requirement: Template Variable Substitution

The system SHALL support variable substitution in Docker Compose templates.

#### Scenario: Supported variables
- GIVEN a compose template with variables
- THEN the system SHALL support:
  - `{{REPO_PATH}}` - absolute path to repository
  - `{{PROJECT_NAME}}` - project name
  - `{{USER_ID}}` - user's UUID
  - `{{TOOL_NAME}}` - tool instance name

#### Scenario: Variable validation
- GIVEN a new tool type with required variables
- WHEN the template is created or updated
- THEN the system validates all required variables exist in the template
- AND returns 400 Bad Request if variables are missing

### Requirement: Built-in Tool Types

The system SHALL seed common tool types on first startup.

#### Scenario: Default tool types
- GIVEN a fresh database
- WHEN the application starts
- THEN the system creates built-in tool types:
  - code-server (VS Code in browser)
  - jupyter-notebook (Jupyter Lab)

### Requirement: Compose Template Validation

The system SHALL validate Docker Compose templates.

#### Scenario: YAML validation
- GIVEN a compose template string
- WHEN creating or updating a tool type
- THEN the system parses the YAML
- AND returns 400 Bad Request if YAML is invalid

#### Scenario: Required structure
- GIVEN a valid YAML compose template
- THEN the system SHALL require:
  - `services` key present
  - At least one service defined

### Requirement: Port requirement indication
The system SHALL allow tool types to indicate whether they require port configuration.

#### Scenario: Web tool requires port
- GIVEN a tool type with `interface_type` = "web"
- WHEN the tool type is created or updated
- THEN `requires_port` SHALL default to true
- AND port-related configuration is shown in the UI

#### Scenario: Terminal tool does not require port
- GIVEN a tool type with `interface_type` = "terminal"
- WHEN the tool type is created or updated
- THEN `requires_port` SHALL default to false
- AND port-related configuration is hidden in the UI

### Requirement: Single interface validation
The system SHALL enforce that each tool type has exactly one interface type.

#### Scenario: Invalid interface type
- GIVEN a tool type creation request with `interface_type` = "invalid"
- WHEN the request is processed
- THEN the system returns 400 Bad Request
- AND the error message indicates valid values are "web" or "terminal"

#### Scenario: Missing interface type
- GIVEN a tool type creation request without `interface_type`
- WHEN the request is processed
- THEN the system returns 400 Bad Request
- AND the error message indicates interface_type is required
