Data Model: Configuration

Part of the domain model; identity and the endpoint are shared by every spec. Types live in midi-harbor-core unless noted.

Configuration (FR-049..053)

The persisted root. YAML, atomically written, schema-versioned (R-011).

Configuration {
    schema_version:  u32
    preferences:     Preferences
    endpoints:       Vec<Endpoint>      // every kind, tagged by EndpointKind
    peers:           Vec<PeerConfig>
    routes:          Vec<RouteConfig>
}

Revised during implementation (2026-09-20). The original sketch split endpoints into four parallel lists — virtual_ports, network_sessions, physical_devices, bluetooth. They were collapsed into one endpoints list because Endpoint already carries a kind tag and all four share every other field. Four lists would have meant four parallel code paths for validation, lookup, renaming and conflict detection, with no gain: the TOML stays readable because each entry carries kind = "virtual_port" explicitly.

What is persisted vs. runtime: enabled, names, ids, fingerprints, policies and routes are persisted. ConnectionState, TrafficCounters, Events, discovered Peers and rssi are runtime-only. This split is what lets FR-050 apply config changes by diffing persisted state and touching only the affected connections.

Capability (FR-053)

Capability {
    name:      CapabilityName
    available: bool
    reason:    Option<UnavailableReason>
}

Queried at runtime so the UI renders unavailable features as unavailable rather than broken (Principle IV). Names cover VirtualPorts, NetworkSessions, BluetoothCentral, BluetoothPeripheral, ServiceManager, and MdnsResponder. This is the mechanism by which a documented platform limitation — such as the Bluetooth peripheral role on Windows — is communicated honestly instead of failing at use.

1.9 KiB Raw Blame History

Data Model: Configuration

Configuration (FR-049..053)

Capability (FR-053)

1.9 KiB

Raw Blame History