feat: InfrastructureNode with ports

[ggfevans]

Parent Epic

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

---

Summary

Implement InfrastructureNode to represent off-rack infrastructure endpoints (ISP handoffs, building power, remote equipment) with the same port model as devices.

Background

Connections often terminate at points outside the rack - ISP handoff, building power feeds, or remote equipment. InfrastructureNode represents these with the same PlacedPort structure as devices, enabling uniform connection handling.

Type Definition

type InfraNodeType = 
  | 'ups'
  | 'breaker-panel'
  | 'wall-outlet'
  | 'floor-pdu'
  | 'patch-panel-wall'
  | 'network-jack'
  | 'isp-demarcation'
  | 'external-switch'
  | 'other';

type InfraScope = 'facility' | 'room' | 'rack-local';

interface InfrastructureNode {
  id: string;
  node_type: InfraNodeType;
  name: string;
  description?: string;
  scope: InfraScope;
  location?: string;              // Freeform: "North wall", "Under desk"
  associated_rack_ids?: string[]; // For rack-local scope
  ports: PlacedPort[];            // Same as device ports!
  
  // Power infrastructure fields
  power_capacity_watts?: number;
  power_capacity_amps?: number;
  voltage?: number;
  circuits?: BreakerCircuit[];
}

interface BreakerCircuit {
  id: string;
  name: string;
  breaker_amps: number;
  is_gfci?: boolean;
}

Acceptance Criteria

• Create InfrastructureNode interface in src/lib/types/index.ts
• Create InfrastructureNodeSchema in src/lib/schemas/index.ts
• Create InfraNodeType and InfraScope enums
• InfrastructureNode has ports: PlacedPort[]
• Add infrastructure: InfrastructureNode[] to Layout
• YAML serialization for infrastructure nodes
• Connections can reference infrastructure node ports

Test Requirements

• InfrastructureNode schema validates correctly
• Ports on infrastructure nodes have valid IDs
• Connections can reference infrastructure node ports
• YAML round-trip preserves infrastructure nodes
• BreakerCircuit schema validates correctly

Related

• Parent Epic: feat: Connection Graph Model - Phase 1: Port-Based Architecture #362
• Depends on: feat: PlacedPort schema and port instantiation #363 (PlacedPort)
• Enables: Power path traversal
• Enables: External connection handling (feat: external connection handling #267)

[ggfevans]

Implementation Review - Critical Feedback

Problems Identified

1. Massive feature disguised as "medium" - Power infrastructure with BreakerCircuit, GFCI tracking, voltage, amp capacity is a separate product vertical, not a connection prerequisite.

2. No clear user problem - What user story is this solving? "As a homelab user, I need to track my breaker panel's GFCI status"? Show the demand.

3. Premature power modeling - power_capacity_watts, voltage, circuits[] - this is UPS management software, not rack visualization.

4. Dual port search complexity - Ports now exist on both PlacedDevice and InfrastructureNode. Finding a port by ID requires searching multiple arrays. Connection graph lookups become O(n+m).

5. associated_rack_ids: string[] - Array of rack IDs in a single-rack app. YAGNI.

6. Zero UX thinking - Where does InfrastructureNode appear? On the canvas? Sidebar? How do users add one? Not considered.

Recommendation

Defer entirely until cable visualization works.

When external endpoints are actually needed, start simple:

interface ExternalEndpoint {
  id: string;
  name: string;  // "ISP Handoff", "Wall Outlet A"
  type: 'network' | 'power' | 'other';
  ports: PlacedPort[];
}

Add power capacity, breaker circuits, voltage tracking as a separate feature when there's user demand and a UI design for it.

[ggfevans]

Closing as deferred - infrastructure nodes are out of scope for MVP.

Rationale: MVP Connection Graph should only connect devices within the rack. Off-rack endpoints (patch panels, ISP handoffs, WAN) are a future enhancement once basic cabling works.

When needed, we can add a simple 'external endpoint' concept without the full InfrastructureNode abstraction.