Draft planning artifact generated via spec-kit — see specs/004-transport-abstraction/ (spec, plan, research, data-model, contracts, quickstart, tasks).
⚠️ Unverified draft: authored without a build environment (no Gradle/JDK 17/network/TIBCO/DuckDB). On branch t/yolo-d76fe7 (not yet pushed).
Tasks (mirrors specs/004-transport-abstraction/tasks.md)
Phase 1: Setup
Phase 2: Foundational (Blocking Prerequisites)
Phase 3: User Story 1 - Existing Rendezvous capture works unchanged through the abstraction (Priority: P1) 🎯 MVP
Phase 4: User Story 2 - Core, ledger, and UI no longer depend on TIBCO Rendezvous types (Priority: P2)
Phase 5: User Story 3 - A new transport backend can be added without changing the core (Priority: P3)
Phase 6: Polish & Cross-Cutting Concerns
Draft planning artifact generated via spec-kit — see
specs/004-transport-abstraction/(spec, plan, research, data-model, contracts, quickstart, tasks).t/yolo-d76fe7(not yet pushed).Tasks (mirrors
specs/004-transport-abstraction/tasks.md)Phase 1: Setup
Phase 2: Foundational (Blocking Prerequisites)
Transportport (connect / subscribe(subject,sink)→Subscription / publish /NeutralMessage(sendSubject/destination, replySubject,Subscription(closeable handle hiding the backend's native subscription type) inTransportExceptionwrapping backend-specific exceptions so they neverTransportKind(stable string id, e.g. "rendezvous"; registry key and persistedConnectionmodel (id/identity, description, subjects, transportKind,TransportFactorySPI (kind()→TransportKind, create(Connection)→Transport) and thecom.tibco.tibrv.TibrvMsg: wrapNeutralMessageTransportRegistryas a Guice singleton populated by aPhase 3: User Story 1 - Existing Rendezvous capture works unchanged through the abstraction (Priority: P1) 🎯 MVP
TibrvMessageCodecround-trip test (TibrvMsg → NeutralMessageTibrvMessageCodec(inbound TibrvMsg → NeutralMessage walkingTibrvMsgField,RendezvousTransport(implementsTransport): split the driver logic out ofRendezvousTransportFactoryregistering kind "rendezvous" incom.tibco.tibrv.*importsPhase 4: User Story 2 - Core, ledger, and UI no longer depend on TIBCO Rendezvous types (Priority: P2)
NeutralMessage/NeutralFieldtests: field-tree ordering, repeated field names,NeutralMessageproduces the sameNeutralField(notTibrvMsg/TibrvMsgField) inNeutralMessageinNeutralMessageinNeutralMessageinNeutralMessage/ the adapter codec instead ofTibrvMsginTibrvMsg: serialize/deserialize selections via the neutralcom.tibco.tibrv.appears only inPhase 5: User Story 3 - A new transport backend can be added without changing the core (Priority: P3)
TransportRegistrytest: a declaredTransportKindresolves to itsLoopbackTransport(publish delivers back to its ownLoopbackTransportFactoryregistering the loopback kind inPhase 6: Polish & Cross-Cutting Concerns
Transportport + registry, how to add a backend