## Context

Currently, tool types use a JSON `interfaces` array (e.g., `["web"]`, `["terminal"]`, `["web", "terminal"]`) to define what interfaces a tool supports. This was designed for flexibility but in practice:
1. No tool needs both web and terminal simultaneously
2. Terminal tools don't expose ports or need tunneling
3. The UI shows checkboxes for both, allowing invalid multi-select combinations

The database migration `0008_tool_type_category` added the `interfaces` JSON column. All existing records use `["web"]` or `["terminal"]` as the first (and only) element.

## Goals / Non-Goals

**Goals:**
- Replace `interfaces` array with single `interface_type` string column
- Add `requires_port` boolean to indicate if port/tunnel config is relevant
- Update UI to use dropdown instead of checkboxes
- Conditionally hide port fields for terminal tools
- Migrate existing data safely

**Non-Goals:**
- No changes to tool instance runtime behavior
- No changes to tunnel/port infrastructure
- No changes to existing tool configs (port_override remains in schema)

## Decisions

**Decision: Replace interfaces array with single interface_type string**
- Rationale: Simplifies model, API, and UI. No legitimate use case for multiple interfaces.
- Alternative: Keep array but enforce single item — rejected because it keeps unnecessary complexity

**Decision: Add requires_port boolean instead of inferring from interface_type**
- Rationale: Explicit is better than implicit. Future interface types may have different port needs.
- Alternative: Infer from interface_type === "web" — rejected for flexibility

**Decision: Default requires_port = true for existing records, then update per actual type**
- Rationale: Most existing tools are web-based. Safer default.
- Migration will inspect existing interfaces[0] to set correct value.

**Decision: Keep port_override in tool_configs schema**
- Rationale: Even terminal tools might need port overrides in edge cases. The UI just hides it.
- Alternative: Remove column — rejected to avoid destructive migration

## Risks / Trade-offs

- **[Risk]** Existing API consumers expect `interfaces` array
  - **Mitigation:** This is a **BREAKING** change. Update frontend simultaneously. Document in changelog.
- **[Risk]** Data migration fails for unexpected interfaces values
  - **Mitigation:** Migration takes first array element. Add fallback to "web" with requires_port=true.
- **[Risk]** Tests break across backend and frontend
  - **Mitigation:** Update all test fixtures and assertions in single commit.

## Migration Plan

1. Create Alembic migration to:
   - Add `interface_type` string column (nullable temporarily)
   - Add `requires_port` boolean column (default true)
   - Migrate data: `interface_type = interfaces[0]`, `requires_port = (interfaces[0] == "web")`
   - Drop `interfaces` column
   - Make `interface_type` non-nullable
2. Update Pydantic schemas (Create/Update/Response)
3. Update SQLAlchemy model
4. Update frontend types and API client
5. Update tool workshop form (dropdown + conditional fields)
6. Update built-in seed data
7. Update tests
8. Run full test suite

## Open Questions

None