`vendor/midstream` is a git submodule of RuView but no `v2/crates/*` depends
on a `midstreamer-*` crate and no Rust source uses one — i.e. it is vendored
but not consumed, the same state `vendor/rvcsi` was in before ADR-097.
ADR-098 evaluates whether to change that. The candidate seams (from the
prompt) were:
1. Streaming / pub-sub for the WS fan-out (today: `tokio::sync::broadcast`
at `wifi-densepose-sensing-server/src/main.rs:4769`).
2. CSI → DSP → event pipeline (today: rvcsi-events::EventPipeline, just
adopted by ADR-097).
3. Multi-source merging / TDM for the ESP32 mesh (ADR-029, ADR-073).
4. Backpressure / flow control between the UDP receiver and downstream
consumers (firmware `stream_sender` ENOMEM; host-side bounded
broadcast channel).
Reading all six midstream workspace crates end-to-end
(`vendor/midstream/crates/{temporal-compare,nanosecond-scheduler,
temporal-attractor-studio,temporal-neural-solver,strange-loop,
quic-multistream}/src/*.rs` — ~3,455 LOC) shows midstream's identity
unambiguously: `Cargo.toml:16` calls itself "Real-time LLM streaming with
inflight analysis", the README frames it as analyzing *LLM token streams*
in real time, and zero hits across the workspace for `csi|wifi|sensing|
sensor`. midstream's abstractions are LLM-token / dashboard-telemetry
shaped; RuView's pipeline is RF-frame / event-detector shaped.
Decisions:
D1 — WS fan-out: keep `tokio::sync::broadcast::channel::<String>(256)`.
midstream offers no equivalent in-process broadcast primitive.
D2 — CSI pipeline: keep `rvcsi-events::EventPipeline` (deterministic,
single-frame-at-a-time, replayable per ADR-095 D9). midstream's
attractor / LTL crates operate on multi-dimensional trajectories,
not validated single CSI frames.
D3 — TDM / aggregator: keep `wifi-densepose-hardware::aggregator` +
firmware-side TDM. midstream has no UDP merger and no cross-device
wall-clock scheduler.
D4 — Backpressure: the firmware ENOMEM rate-limit and the bounded host
`broadcast` channel are correct at each end; midstream's QUIC
primitives don't help the actual UDP+WS topology.
D5 — Carve-out: `midstreamer-temporal-compare` (DTW / LCS / Levenshtein)
is a plausible future-evaluation option if a *second* DTW use case
appears in RuView. RuvSense already has one (`gesture.rs`).
D6 — Carve-out: `midstreamer-scheduler` (deadline-aware, EDF / LLF /
RM) is a plausible future option if the cluster-Pi aggregator ever
takes over real-time scheduling. Today that lives in firmware.
D7 — Submodule: keep `vendor/midstream` pinned at `30fe5eb` as reference
material; do not advance the pin per-release (unlike vendor/rvcsi
under ADR-097 D7) because there is no in-build consumer.
D8 — Docs: cross-reference, don't import. ADR-098 added to
`docs/adr/README.md`.
Status: Rejected (with named re-evaluation triggers in §6 — second DTW use
case, host-side real-time scheduler, midstream gains a CSI adapter, or a
QUIC-to-external-client requirement that WS can't service).
ADR-098 rejected midstream as a *replacement* for RuView's existing seams.
ADR-099 is the other half: midstream's `temporal-compare` (DTW) and
`temporal-attractor-studio` (Lyapunov + regime classification) crates as a
*parallel* per-frame introspection tap, alongside the existing window-aggregated
event pipeline.
The 8 decisions:
D1 — Only midstreamer-temporal-compare 0.2 + midstreamer-attractor 0.2;
scheduler / neural-solver / strange-loop are out of scope of this ADR.
D2 — Tap point: post-validate, parallel to WindowBuffer::push in csi.rs.
The existing /ws/sensing path is unchanged.
D3 — New /ws/introspection topic + /api/v1/introspection/snapshot REST endpoint
carrying IntrospectionSnapshot { regime, lyapunov_exponent,
attractor_dim, top_k_similarity }.
D4 — Per-frame updates only, never window-blocked. Soonest-event latency on
the "shape recognized" path collapses from ~533 ms (16-frame @ 30 Hz
window) to ~33 ms (one frame), a ~16× win.
D5 — temporal-neural-solver (LTL) is out of scope (separate MAT audit ADR).
D6 — ESP32 firmware unchanged; deployment is host-side only.
D7 — Signature library is JSON, on-disk, customer-owned; three reference
signatures ship as developer fixtures.
D8 — Promotion bar is empirical: ≥10× p99 latency reduction vs. the existing
/ws/sensing event path, or the feature stays behind a CLI flag.
Indexed in docs/adr/README.md. Phased adoption (P0 spike + benchmark → P1 first
real signature library → P2 dashboard widget → P3 capture workflow → P4 optional
adaptive_classifier hook). Implementation lands as ~150–250 lines + one
integration test in v2/crates/wifi-densepose-sensing-server in follow-up PRs.
Co-Authored-By: claude-flow <ruv@ruv.net>
rvCSI was extracted to its own repo (PR #542→#544): 9 crates on crates.io @
0.3.1, `@ruv/rvcsi` on npm, vendored at `vendor/rvcsi`. RuView currently
*vendors but does not consume* it — zero `rvcsi-*` deps in `v2/`, zero
`use rvcsi_…` imports, zero `@ruv/rvcsi` JS imports. ADR-097 decides:
D1 — Depend on the published crates from crates.io, not the submodule path.
D2 — Pilot in `wifi-densepose-sensing-server` (smallest, best-bounded
touchpoint: UDP receiver + handlers + WS fan-out).
D3 — `wifi-densepose-signal` is *layered on top of* rvCSI, not replaced.
The SOTA / RuvSense modules go beyond rvCSI's scope and stay in
RuView; they consume `rvcsi_core::CsiFrame`. Overlapping basic DSP
primitives delegate to `rvcsi-dsp` or become thin shims.
D4 — `wifi-densepose-hardware` stops carrying ESP32 wire-format parsing;
the parser moves to a new `rvcsi-adapter-esp32` crate (ADR-095 §1.2
/ D15 follow-up, owned in the rvCSI repo).
D5 — `wifi-densepose-ruvector` (training pipeline) and `rvcsi-ruvector`
(runtime RF memory) stay separate for now; a follow-up unifies them
once the production RuVector binding lands.
D6 — `rvcsi_core::CsiFrame` is the boundary type at the runtime edge;
one explicit `From`/`Into` conversion point at that edge.
D7 — Track via `rvcsi-* = "0.3"` SemVer ranges + bump the `vendor/rvcsi`
submodule pin per RuView release for reproducible offline builds.
D8 — Once every consumer depends on crates.io, decide (separately)
whether to drop the submodule.
Adoption is phased (P1 pilot → P2 signal shim → P3 ESP32 adapter →
P4 clean-up → P5 submodule review); each phase is one PR with tests.
Indexed in docs/adr/README.md.
Co-Authored-By: claude-flow <ruv@ruv.net>
Explains why ADRs matter for AI-generated code (prevents drift,
provides constraints and rationale), how they work with DDD domain
models, and indexes all 44 ADRs by category.
Also fixes ADR count 43 -> 44 in main README.
Co-Authored-By: claude-flow <ruv@ruv.net>
rUv
Claude