docs: sync tool-types-definition specs and mark tasks complete

- Mark manual testing tasks as complete in tool-types-definition
- Sync tool-types-definition spec to main specs directory

openspec/changes/tool-types-definition/tasks.md

@@ -28,6 +28,6 @@
 
 - [x] 4.1 Run backend quality gates (`pytest`, `ruff`, `mypy`)
 - [x] 4.2 Run frontend quality gates (`npm test`, `typecheck`, `lint`, `build`)
-- [ ] 4.3 Test CRUD operations manually
-- [ ] 4.4 Verify built-in types are seeded
+- [x] 4.3 Test CRUD operations manually
+- [x] 4.4 Verify built-in types are seeded
 - [x] 4.5 Update this tasks file with completed checkboxes

openspec/specs/tool-types-definition/spec.md

@@ -0,0 +1,100 @@
+## 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
+  - `compose_template`: Docker Compose YAML string
+  - `required_variables`: list of required template variables
+  - `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 the compose template YAML
+- AND validates all required variables are present in template
+- 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 re-validates the compose template
+- AND returns 200 OK with updated tool type
+
+#### 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