feat: MVP Connection model

[ggfevans]

Parent Epic

Part of #362 (Connection Graph Model - Port-Based Architecture)

Supersedes: #261 (Cable data model) / PR #355

---

Summary

Implement a minimal Connection model using port IDs. Start simple, add complexity when needed.

Background

The original Cable model (#261) used string references like a_device_id + a_interface. This is fragile. The new model references PlacedPort.id directly.

MVP Type Definition

interface Connection {
  id: string;           // UUID
  a_port_id: string;    // PlacedPort.id
  b_port_id: string;    // PlacedPort.id
  label?: string;       // Optional user label
  color?: string;       // Hex color for visualization
}

That's it. No connection_class, no status, no role, no redundancy_group, no CableProperties nesting. Add those when users actually need them.

Acceptance Criteria

• Create Connection interface in src/lib/types/index.ts
• Create ConnectionSchema in src/lib/schemas/index.ts
• Add connections: Connection[] to Layout (default: [])
• YAML serialization for connections
• Basic validation (a_port_id ≠ b_port_id)

Test Requirements

• Connection schema validates correctly
• Self-connection rejected (a_port_id === b_port_id)
• YAML round-trip preserves connections
• Empty label/color handled correctly

Design Decisions

1. No connection class/type: Users can use label + color to distinguish network vs power vs console
2. No status field: Everything is "connected" - if it's in the data, it exists
3. No nested CableProperties: Color and label are flat fields
4. No role/redundancy_group: YAGNI - add when users request

Future Enhancements (NOT in MVP)

These can be added later if users need them:

• Connection classes (network, power, console)
• Connection status (planned, decommissioning)
• Cable properties (type, length, length_unit)
• Redundancy groups
• Bidirectional relationship tracking

Related

• Parent Epic: feat: Connection Graph Model - Phase 1: Port-Based Architecture #362
• Depends on: feat: PlacedPort schema and port instantiation #363 (PlacedPort) ✅ Merged in PR feat: add PlacedPort schema and port instantiation (#363) #389
• Enables: spike: cable path rendering algorithm #262 (Cable visualization)

[ggfevans]

Implementation Review - Critical Feedback

Problems Identified

1. Over-engineered taxonomy - ConnectionClass, ConnectionStatus, ConnectionRole, redundancy_group - this is enterprise NetOps tooling. Does a homelab user need decommissioning status?

2. Confusing nomenclature - "Supersedes feat: cable data model and schema #261 (Cable data model)" but Cable already exists. Are Cable and Connection different? Same? A cable is physical; a connection is logical. You can have connections without cables (WiFi, virtual, iLO).

3. Asymmetric naming - a_port_id / b_port_id implies directionality in a bidirectional relationship. Confusing.

4. CableProperties nested in Connection - Conflating physical with logical. What about wireless? Virtual networks? Bonded links with multiple cables?

5. No UX consideration - How do users create connections? Drag between ports? Select and link? No UI thinking.

Recommendation

Start with MVP:

interface Connection {
  id: string;
  type: 'network' | 'power' | 'other';
  port_ids: [string, string];  // Tuple, symmetric
  label?: string;
}

Add later when there's UI for it:

• status, role, cable_properties
• Only after the basic "draw a line between ports" works

Clarify nomenclature:

• Cable = physical object (type, color, length)
• Connection = logical link (which ports, label)
• A Connection MAY have Cable properties attached