ruvnet--RuView

frank/ruvnet--RuView

Fork 0

mirror of https://github.com/ruvnet/RuView synced 2026-07-22 17:23:19 +00:00

Commit Graph

Author	SHA1	Message	Date
ruv	1c9727f9cf	feat(adr-185): P3 MAT bindings (wifi_densepose.mat) + parity harness Bind the ADR-024 MAT (Mass Casualty Assessment Tool) disaster-survivor detection + START triage surface into the wheel behind a gated [mat] extra / Cargo `mat` feature, mirroring the upstream disaster/ML gating. Also adds the [sota] superset extra (aether+meridian+mat). Surface (bound against the REAL code at HEAD, not the ADR wishlist): - DisasterType (9 variants) / TriageStatus (5, START) enums - DisasterConfig (builder-backed, continuous_monitoring forced off) - DisasterResponse: initialize_event / add_zone / push_csi_data / scan_once / survivors / survivors_by_triage - Survivor (id, triage_status, confidence, location, latest_vitals) - VitalSignsReading (breathing/heartbeat rate, movement, confidence) - ScanZone.rectangle / ScanZone.circle push_csi_data + scan_once are GIL-released. Honest deviations from ADR section 3.4 (documented in module header): - ADR proposed adding a Rust-side sync scan_once() (section 11.3). That was UNNECESSARY: the public async start_scanning() runs exactly one scan_cycle and returns when continuous_monitoring == false. The binding forces that flag off and drives one cycle on a private current-thread tokio runtime -- NO change to wifi-densepose-mat. - scan_cycle requires an active event + Active zone, which the ADR surface omitted; initialize_event + add_zone are bound as required additions. - Survivor.vital_signs is a history in the real code; bound as Survivor.latest_vitals -> Optional[VitalSignsReading]. - DisasterType has 9 variants at HEAD (adds Landslide/MineCollapse/ Industrial/TunnelCollapse); all bound. Parity (section 4.1, release-blocking): committed fixture mat_input.json (synthetic breathing-modulated CSI stream) -> native Rust reference (tests/mat_parity.rs, drives DisasterResponse directly) locks tests/golden/mat_result.sha256 over a canonical `count=<K>;triage_priorities=<sorted>` string (survivor UUIDs/timestamps excluded as non-deterministic); pytest (tests/test_mat.py) runs the same stream through the binding and asserts the identical hash. Both detect exactly 1 survivor, triage Delayed. Honest: synthetic fixture proves binding==native path equality, NOT live detection accuracy. Verified: cargo test --features mat --test mat_parity -> 2/2 pass maturin develop --features mat + pytest tests/test_mat.py -> 7/7 pass default cargo build clean, 0 mat/tokio refs in the default dep graph. WHEEL-SIZE FINDING (ADR-185 section 9): default-features=false drops MAT's `api` (axum) and `ruvector` features, but MAT still carries NON-optional tokio (rt/sync/time), wifi-densepose-nn (ort/ONNX + reqwest/hyper), rustfft, geo, ndarray. So a [mat] wheel exceeds the ADR-117 section 5.4 <=5 MB budget -- same leaf-crate-hoist follow-up as AETHER/MERIDIAN. The default wheel is untouched (feature-gated).	2026-07-21 16:49:49 -07:00
ruv	189ac9dfb0	feat(adr-185): P2 MERIDIAN bindings (wifi_densepose.meridian) + parity harness Bind the ADR-027 MERIDIAN cross-environment domain-generalization surface into the wheel behind a gated [meridian] extra / Cargo `meridian` feature. Inference/adaptation path only (tch-free), per ADR-185 section 3.3. Surface (bound against the REAL code at HEAD, not the ADR wishlist): - HardwareType / HardwareNormalizer / CanonicalCsiFrame (from wifi-densepose-signal::hardware_norm) - MeridianGeometryConfig / GeometryEncoder (64-dim, permutation-invariant) - RapidAdaptation / AdaptationResult (push_frame + adapt, LoRA deltas) - CrossDomainEvaluator + mpjpe (from wifi-densepose-train, NO tch-backend) All compute paths GIL-released (py.allow_threads). Honest deviations from ADR section 3.3 (documented in the module header): - ADR's RapidAdaptation.calibrate(windows) and AdaptationResult.converged DO NOT EXIST. Real API is push_frame + adapt(); result carries {lora_weights, final_loss, frames_used, adaptation_epochs}. Bound as-is. - ADR's HardwareType.detect exposed as a staticmethod delegating to the real HardwareNormalizer::detect_hardware. - ADR's normalize(frame: CsiFrame, hw) is really normalize(amplitude, phase, hw) over f64 vectors returning Result; bound faithfully. - CanonicalCsiFrame fields are singular amplitude/phase (ADR said plural). Training-time types (DomainFactorizer, GradientReversalLayer, VirtualDomainAugmentor) are out of P6 scope (need the libtorch tier). Parity (section 4.1, release-blocking): committed fixture meridian_input.json -> native Rust reference (tests/meridian_parity.rs, calls hardware_norm + geometry + rapid_adapt directly) locks tests/golden/meridian_output.sha256 over the concatenated f32 outputs (esp32+intel canonical frames, 64-dim geometry vector, rapid-adapt LoRA weights); pytest (tests/test_meridian.py) runs the same fixture through the binding and asserts the identical SHA-256. Both pass. Verified: cargo test --features meridian --test meridian_parity -> 2/2 pass maturin develop --features meridian + pytest tests/test_meridian.py -> 13/13 pass default cargo build clean, 0 train/signal/sensing-server refs in the default dep graph (gate keeps the base wheel lean). WHEEL-SIZE FINDING (ADR-185 section 9 / section 1.2): the libtorch risk the ADR feared is AVOIDED -- wifi-densepose-train's `tch` dep is properly optional (feature tch-backend, OFF), so no libtorch links. BUT train still carries NON-optional deps: tokio (rt subset), the five ruvector-* crates, and wifi-densepose-nn (which itself pulls `ort` / ONNX Runtime + reqwest/hyper). So a [meridian] wheel exceeds the ADR-117 section 5.4 <=5 MB budget (though lighter than AETHER's axum/tokio server tree). The clean fix is the same leaf-crate hoist: move the pure inference modules (geometry, rapid_adapt, eval, hardware_norm) into a tch/tokio/ort-free leaf crate. A required pre-release follow-up, not a functional blocker; P2 binds real code and proves parity today.	2026-07-21 16:38:17 -07:00
ruv	d060998e3b	feat(adr-185): P1 AETHER bindings (wifi_densepose.aether) + parity harness Bind the ADR-024 contrastive CSI embedding surface into the wheel behind a gated [aether] extra / Cargo `aether` feature, per ADR-185 section 3.2. Surface (bound against the REAL code at HEAD, not the ADR wishlist): - AetherConfig -> EmbeddingConfig {d_model,d_proj,temperature,normalize} - CsiAugmenter -> augment_pair(window, seed) - EmbeddingExtractor -> embed(csi): 128-dim L2-normed, GIL-released - info_nce_loss, cosine_similarity (module fns) ADR-185 section 3.2 also names aether_loss/VICReg components, alignment_metric, uniformity_metric, forward_dual, and vicreg_* config fields. None exist in embedding.rs at HEAD, so they are intentionally NOT bound (a Rust-side gap, not a binding gap) rather than fabricated. Parity (section 4.1, release-blocking): committed fixture aether_input.json -> native Rust reference (tests/aether_parity.rs, calls sensing-server EmbeddingExtractor directly) locks tests/golden/aether_embedding.sha256; pytest (tests/test_aether.py) runs the same fixture through the binding and asserts the identical SHA-256 of the LE f32 bytes. Both pass. Verified: cargo test --features aether --test aether_parity -> 2/2 pass; maturin develop --features aether + pytest tests/test_aether.py -> 9/9 pass; default cargo build clean with 0 sensing-server refs in the dep graph (gate keeps the base wheel lean). HONEST WHEEL-SIZE FINDING (ADR-185 section 9 / Open Q 11.1, unresolved): wifi-densepose-sensing-server is an Axum/tokio crate whose tokio/axum/ worldgraph/ruvector deps are NON-optional (only mqtt/matter are features), so default-features=false does NOT drop them. An [aether] wheel therefore links the full server tree and BREAKS the ADR-117 section 5.4 <=5 MB budget. The fix is the ADR-sanctioned hoist of embedding.rs (+ its graph_transformer/sona siblings) into a leaf crate so the wheel links pure compute only -- a change INSIDE wifi-densepose-sensing-server, owned by another agent this session, so deferred as a required pre-release follow-up. P1 binds real code and proves parity today; the hoist is a wheel-size optimization, not a functional blocker. Note: building required initializing the worldgraph/rufield/ruvector submodules (absent in the fresh worktree).	2026-07-21 16:28:14 -07:00

Author

SHA1

Message

Date

ruv

1c9727f9cf

feat(adr-185): P3 MAT bindings (wifi_densepose.mat) + parity harness

Bind the ADR-024 MAT (Mass Casualty Assessment Tool) disaster-survivor
detection + START triage surface into the wheel behind a gated [mat]
extra / Cargo `mat` feature, mirroring the upstream disaster/ML gating.
Also adds the [sota] superset extra (aether+meridian+mat).

Surface (bound against the REAL code at HEAD, not the ADR wishlist):
- DisasterType (9 variants) / TriageStatus (5, START) enums
- DisasterConfig (builder-backed, continuous_monitoring forced off)
- DisasterResponse: initialize_event / add_zone / push_csi_data /
  scan_once / survivors / survivors_by_triage
- Survivor (id, triage_status, confidence, location, latest_vitals)
- VitalSignsReading (breathing/heartbeat rate, movement, confidence)
- ScanZone.rectangle / ScanZone.circle
push_csi_data + scan_once are GIL-released.

Honest deviations from ADR section 3.4 (documented in module header):
- ADR proposed adding a Rust-side sync scan_once() (section 11.3). That was
  UNNECESSARY: the public async start_scanning() runs exactly one
  scan_cycle and returns when continuous_monitoring == false. The binding
  forces that flag off and drives one cycle on a private current-thread
  tokio runtime -- NO change to wifi-densepose-mat.
- scan_cycle requires an active event + Active zone, which the ADR surface
  omitted; initialize_event + add_zone are bound as required additions.
- Survivor.vital_signs is a *history* in the real code; bound as
  Survivor.latest_vitals -> Optional[VitalSignsReading].
- DisasterType has 9 variants at HEAD (adds Landslide/MineCollapse/
  Industrial/TunnelCollapse); all bound.

Parity (section 4.1, release-blocking): committed fixture mat_input.json
(synthetic breathing-modulated CSI stream) -> native Rust reference
(tests/mat_parity.rs, drives DisasterResponse directly) locks
tests/golden/mat_result.sha256 over a canonical
`count=<K>;triage_priorities=<sorted>` string (survivor UUIDs/timestamps
excluded as non-deterministic); pytest (tests/test_mat.py) runs the same
stream through the binding and asserts the identical hash. Both detect
exactly 1 survivor, triage Delayed. Honest: synthetic fixture proves
binding==native path equality, NOT live detection accuracy.

Verified:
  cargo test --features mat --test mat_parity -> 2/2 pass
  maturin develop --features mat + pytest tests/test_mat.py -> 7/7 pass
  default cargo build clean, 0 mat/tokio refs in the default dep graph.

WHEEL-SIZE FINDING (ADR-185 section 9): default-features=false drops MAT's
`api` (axum) and `ruvector` features, but MAT still carries NON-optional
tokio (rt/sync/time), wifi-densepose-nn (ort/ONNX + reqwest/hyper),
rustfft, geo, ndarray. So a [mat] wheel exceeds the ADR-117 section 5.4
<=5 MB budget -- same leaf-crate-hoist follow-up as AETHER/MERIDIAN. The
default wheel is untouched (feature-gated).

2026-07-21 16:49:49 -07:00

ruv

189ac9dfb0

feat(adr-185): P2 MERIDIAN bindings (wifi_densepose.meridian) + parity harness

Bind the ADR-027 MERIDIAN cross-environment domain-generalization surface
into the wheel behind a gated [meridian] extra / Cargo `meridian` feature.
Inference/adaptation path only (tch-free), per ADR-185 section 3.3.

Surface (bound against the REAL code at HEAD, not the ADR wishlist):
- HardwareType / HardwareNormalizer / CanonicalCsiFrame (from
  wifi-densepose-signal::hardware_norm)
- MeridianGeometryConfig / GeometryEncoder (64-dim, permutation-invariant)
- RapidAdaptation / AdaptationResult (push_frame + adapt, LoRA deltas)
- CrossDomainEvaluator + mpjpe (from wifi-densepose-train, NO tch-backend)
All compute paths GIL-released (py.allow_threads).

Honest deviations from ADR section 3.3 (documented in the module header):
- ADR's RapidAdaptation.calibrate(windows) and AdaptationResult.converged
  DO NOT EXIST. Real API is push_frame + adapt(); result carries
  {lora_weights, final_loss, frames_used, adaptation_epochs}. Bound as-is.
- ADR's HardwareType.detect exposed as a staticmethod delegating to the
  real HardwareNormalizer::detect_hardware.
- ADR's normalize(frame: CsiFrame, hw) is really normalize(amplitude,
  phase, hw) over f64 vectors returning Result; bound faithfully.
- CanonicalCsiFrame fields are singular amplitude/phase (ADR said plural).
Training-time types (DomainFactorizer, GradientReversalLayer,
VirtualDomainAugmentor) are out of P6 scope (need the libtorch tier).

Parity (section 4.1, release-blocking): committed fixture
meridian_input.json -> native Rust reference (tests/meridian_parity.rs,
calls hardware_norm + geometry + rapid_adapt directly) locks
tests/golden/meridian_output.sha256 over the concatenated f32 outputs
(esp32+intel canonical frames, 64-dim geometry vector, rapid-adapt LoRA
weights); pytest (tests/test_meridian.py) runs the same fixture through
the binding and asserts the identical SHA-256. Both pass.

Verified:
  cargo test --features meridian --test meridian_parity -> 2/2 pass
  maturin develop --features meridian + pytest tests/test_meridian.py
    -> 13/13 pass
  default cargo build clean, 0 train/signal/sensing-server refs in the
    default dep graph (gate keeps the base wheel lean).

WHEEL-SIZE FINDING (ADR-185 section 9 / section 1.2): the libtorch risk
the ADR feared is AVOIDED -- wifi-densepose-train's `tch` dep is properly
optional (feature tch-backend, OFF), so no libtorch links. BUT train
still carries NON-optional deps: tokio (rt subset), the five ruvector-*
crates, and wifi-densepose-nn (which itself pulls `ort` / ONNX Runtime +
reqwest/hyper). So a [meridian] wheel exceeds the ADR-117 section 5.4
<=5 MB budget (though lighter than AETHER's axum/tokio server tree). The
clean fix is the same leaf-crate hoist: move the pure inference modules
(geometry, rapid_adapt, eval, hardware_norm) into a tch/tokio/ort-free
leaf crate. A required pre-release follow-up, not a functional blocker;
P2 binds real code and proves parity today.

2026-07-21 16:38:17 -07:00

ruv

d060998e3b

feat(adr-185): P1 AETHER bindings (wifi_densepose.aether) + parity harness

Bind the ADR-024 contrastive CSI embedding surface into the wheel behind
a gated [aether] extra / Cargo `aether` feature, per ADR-185 section 3.2.

Surface (bound against the REAL code at HEAD, not the ADR wishlist):
- AetherConfig       -> EmbeddingConfig {d_model,d_proj,temperature,normalize}
- CsiAugmenter       -> augment_pair(window, seed)
- EmbeddingExtractor -> embed(csi): 128-dim L2-normed, GIL-released
- info_nce_loss, cosine_similarity (module fns)

ADR-185 section 3.2 also names aether_loss/VICReg components,
alignment_metric, uniformity_metric, forward_dual, and vicreg_* config
fields. None exist in embedding.rs at HEAD, so they are intentionally NOT
bound (a Rust-side gap, not a binding gap) rather than fabricated.

Parity (section 4.1, release-blocking): committed fixture
aether_input.json -> native Rust reference (tests/aether_parity.rs, calls
sensing-server EmbeddingExtractor directly) locks
tests/golden/aether_embedding.sha256; pytest (tests/test_aether.py) runs
the same fixture through the binding and asserts the identical SHA-256 of
the LE f32 bytes. Both pass.

Verified: cargo test --features aether --test aether_parity -> 2/2 pass;
maturin develop --features aether + pytest tests/test_aether.py -> 9/9
pass; default cargo build clean with 0 sensing-server refs in the dep
graph (gate keeps the base wheel lean).

HONEST WHEEL-SIZE FINDING (ADR-185 section 9 / Open Q 11.1, unresolved):
wifi-densepose-sensing-server is an Axum/tokio crate whose tokio/axum/
worldgraph/ruvector deps are NON-optional (only mqtt/matter are
features), so default-features=false does NOT drop them. An [aether]
wheel therefore links the full server tree and BREAKS the ADR-117 section
5.4 <=5 MB budget. The fix is the ADR-sanctioned hoist of embedding.rs
(+ its graph_transformer/sona siblings) into a leaf crate so the wheel
links pure compute only -- a change INSIDE wifi-densepose-sensing-server,
owned by another agent this session, so deferred as a required
pre-release follow-up. P1 binds real code and proves parity today; the
hoist is a wheel-size optimization, not a functional blocker.

Note: building required initializing the worldgraph/rufield/ruvector
submodules (absent in the fresh worktree).

2026-07-21 16:28:14 -07:00

3 Commits