ruvnet--RuView

frank/ruvnet--RuView

Fork 0

mirror of https://github.com/ruvnet/RuView synced 2026-07-24 17:43:20 +00:00

Commit Graph

Author SHA1 Message Date

Author	SHA1	Message	Date
Dragan Spiridonov	2febbb813c	revert(python): keep the small base wheel — P6 stays source-build-only for now Reverses the release-wheel packaging change from `3ed43e9a` after review. That commit built the published wheels with `--features sota` so `pip install wifi-densepose[aether]` would work. But it did so by abandoning a DELIBERATE, guarded design: `default = []`, the RuView#1387-default-wheel-budget-config fix-marker, and the wheel-size-budget job exist specifically to keep the base wheel small and make SOTA opt-in (ADR-117 §5.4). Building SOTA into every published wheel makes the base fat, turns the `[aether]`/`[mat]`/`[meridian]` extras into inert no-ops, and — worse — leaves the PUBLISHED wheel un-budget-checked (the budget job only builds the no-features wheel), so the ONNX Runtime dependency the fix-marker anticipates for `mat` would later balloon the shipped wheel past 5 MiB silently. A pip extra cannot enable a cargo feature on a prebuilt wheel, so "small base + opt-in SOTA in binary wheels" is only achievable by splitting into separate packages — tracked as #1412. Until that lands, P6 is source-build-only, and the honest thing is to say so. This commit: - Restores pip-release.yml to its original state (no --features in the release build; original smoke test). Net packaging change across the branch is now ZERO — the small-base design is fully intact. - Points the aether/mat/meridian import shims at the real interim path: a source build with `--features <x>` (or `--features sota`), and #1412 for the binary wheels follow-up. The earlier revision wrongly claimed "the official wheels include it", which is only true once #1412 ships. KEPT from `3ed43e9a` (correct regardless of packaging): the AETHER parity tests are now arch-portable — they compare a golden VECTOR within tolerance instead of a SHA-256 of raw f32 bytes, which only ever matched the one architecture that generated it and failed on the aarch64/macOS-arm wheels this project builds. Verified on aarch64/macOS with a `--features sota` build (as python-ci does): test_aether 13, test_mat 7, test_meridian 13 pass; full suite unaffected. Co-Authored-By: Ruflo & AQE	2026-07-24 11:47:19 +02:00
Dragan Spiridonov	3ed43e9a2f	fix(python): ship SOTA bindings in release wheels; make parity tests arch-portable Three coupled defects, all found by building the wheel and running the real suite on Apple Silicon rather than trusting green CI. 1. THE P6 SOTA BINDINGS NEVER REACHED USERS (release blocker). `pip-release.yml`'s cibuildwheel built the DEFAULT feature set, so published wheels contained none of aether/mat/meridian. `pip install wifi-densepose[aether]` then raised ImportError — and the extra is empty, so its own error message ("install the [aether] extra") sent users in a circle. A pip extra cannot enable a Rust cargo feature on an already-built wheel, so the only way P6 reaches PyPI is to compile it in. Fix: the RELEASE build opts in via `MATURIN_PEP517_ARGS="--features sota"` (per-platform, since CIBW_ENVIRONMENT_LINUX overrides CIBW_ENVIRONMENT). `default = []` in Cargo.toml, the RuView#1387-default-wheel-budget-config fix-marker, and the wheel-size-budget job are all left UNTOUCHED — they keep guarding the small base compile. Measured published wheel: 1.68 MiB, well under the ADR-117 §5.4 5 MiB budget. Proven: built via the exact PEP517 path, `import wifi_densepose.aether/mat/meridian` all succeed. 2. THE WHEEL SMOKE TEST COULD NOT SEE #1. CIBW_TEST_COMMAND only asserted `hello()` and PRINTED `__build_features__`. The one signal that would reveal missing bindings was dumped to stdout and ignored, so a featureless wheel published green. It now ASSERTS the p6 features are present and imports the three modules. Proven red→green: fails on the old featureless wheel ("missing SOTA bindings: [...]"), passes on the fixed one. 3. THE AETHER PARITY TESTS WERE NOT PORTABLE ACROSS THE WHEEL MATRIX. `test_aether.py` and the native `aether_parity.rs`/`aether_weights_parity.rs` hashed the raw f32 embedding bytes (SHA-256) against a committed golden. The embedding is pure f32 with transcendental ops (ln/sqrt/cos) that are not bit-reproducible across CPUs/libm, so the hash only ever matched the one arch that generated it. This passed in python-ci (x86) but fails on the aarch64 / macOS-arm wheels this same project ships — latent until #1 is fixed and the bindings actually load. Every tolerance/behavioral assertion already passed; only the two byte-hash tests failed, which is the signature of a non-portable golden, not a logic bug. Fix: compare to a committed golden VECTOR within tolerance (atol=rtol=1e-4 — ~100x cross-arch f32 drift, ~100x under any real algorithm change), on both the Python and native sides against the SAME golden. Native ≈ golden and binding ≈ golden together prove binding ≈ native, portably. `.sha256` goldens replaced by `.json` vectors. Also: the aether/mat/meridian import shims told users to `pip install wifi-densepose[<x>]` on a missing feature — an empty extra that cannot help. Corrected to name the real fix (rebuild with `--features <x>`); message tests updated to assert the honest message and forbid the misleading one. Verified on aarch64/macOS: full `python/tests/` suite 227 passed against a wheel built with the new mechanism; `cargo check --tests --features aether` clean. The native `.rs` parity tests were converted by inspection and cargo-checked but not executed — they link against the PyO3 crate and no workflow runs them today (a pre-existing gap; wiring `cd python && cargo test --features sota` into python-ci would make the native anchor actually run). Co-Authored-By: Ruflo & AQE	2026-07-24 10:45:00 +02: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

Dragan Spiridonov

2febbb813c

revert(python): keep the small base wheel — P6 stays source-build-only for now

Reverses the release-wheel packaging change from 3ed43e9a after review.

That commit built the published wheels with `--features sota` so
`pip install wifi-densepose[aether]` would work. But it did so by abandoning a
DELIBERATE, guarded design: `default = []`, the
RuView#1387-default-wheel-budget-config fix-marker, and the wheel-size-budget
job exist specifically to keep the base wheel small and make SOTA opt-in
(ADR-117 §5.4). Building SOTA into every published wheel makes the base fat,
turns the `[aether]`/`[mat]`/`[meridian]` extras into inert no-ops, and — worse
— leaves the PUBLISHED wheel un-budget-checked (the budget job only builds the
no-features wheel), so the ONNX Runtime dependency the fix-marker anticipates
for `mat` would later balloon the shipped wheel past 5 MiB silently.

A pip extra cannot enable a cargo feature on a prebuilt wheel, so "small base +
opt-in SOTA in binary wheels" is only achievable by splitting into separate
packages — tracked as #1412. Until that lands, P6 is source-build-only, and the
honest thing is to say so.

This commit:
- Restores pip-release.yml to its original state (no --features in the release
  build; original smoke test). Net packaging change across the branch is now
  ZERO — the small-base design is fully intact.
- Points the aether/mat/meridian import shims at the real interim path: a source
  build with `--features <x>` (or `--features sota`), and #1412 for the binary
  wheels follow-up. The earlier revision wrongly claimed "the official wheels
  include it", which is only true once #1412 ships.

KEPT from 3ed43e9a (correct regardless of packaging): the AETHER parity tests
are now arch-portable — they compare a golden VECTOR within tolerance instead of
a SHA-256 of raw f32 bytes, which only ever matched the one architecture that
generated it and failed on the aarch64/macOS-arm wheels this project builds.

Verified on aarch64/macOS with a `--features sota` build (as python-ci does):
test_aether 13, test_mat 7, test_meridian 13 pass; full suite unaffected.

Co-Authored-By: Ruflo & AQE

2026-07-24 11:47:19 +02:00

Dragan Spiridonov

3ed43e9a2f

fix(python): ship SOTA bindings in release wheels; make parity tests arch-portable

Three coupled defects, all found by building the wheel and running the real
suite on Apple Silicon rather than trusting green CI.

1. THE P6 SOTA BINDINGS NEVER REACHED USERS (release blocker).
   `pip-release.yml`'s cibuildwheel built the DEFAULT feature set, so published
   wheels contained none of aether/mat/meridian. `pip install
   wifi-densepose[aether]` then raised ImportError — and the extra is empty, so
   its own error message ("install the [aether] extra") sent users in a circle.
   A pip extra cannot enable a Rust cargo feature on an already-built wheel, so
   the only way P6 reaches PyPI is to compile it in.

   Fix: the RELEASE build opts in via `MATURIN_PEP517_ARGS="--features sota"`
   (per-platform, since CIBW_ENVIRONMENT_LINUX overrides CIBW_ENVIRONMENT).
   `default = []` in Cargo.toml, the RuView#1387-default-wheel-budget-config
   fix-marker, and the wheel-size-budget job are all left UNTOUCHED — they keep
   guarding the small base compile. Measured published wheel: 1.68 MiB, well
   under the ADR-117 §5.4 5 MiB budget. Proven: built via the exact PEP517 path,
   `import wifi_densepose.aether/mat/meridian` all succeed.

2. THE WHEEL SMOKE TEST COULD NOT SEE #1.
   CIBW_TEST_COMMAND only asserted `hello()` and PRINTED `__build_features__`.
   The one signal that would reveal missing bindings was dumped to stdout and
   ignored, so a featureless wheel published green. It now ASSERTS the p6
   features are present and imports the three modules. Proven red→green: fails
   on the old featureless wheel ("missing SOTA bindings: [...]"), passes on the
   fixed one.

3. THE AETHER PARITY TESTS WERE NOT PORTABLE ACROSS THE WHEEL MATRIX.
   `test_aether.py` and the native `aether_parity.rs`/`aether_weights_parity.rs`
   hashed the raw f32 embedding bytes (SHA-256) against a committed golden. The
   embedding is pure f32 with transcendental ops (ln/sqrt/cos) that are not
   bit-reproducible across CPUs/libm, so the hash only ever matched the one arch
   that generated it. This passed in python-ci (x86) but fails on the aarch64 /
   macOS-arm wheels this same project ships — latent until #1 is fixed and the
   bindings actually load. Every tolerance/behavioral assertion already passed;
   only the two byte-hash tests failed, which is the signature of a non-portable
   golden, not a logic bug.

   Fix: compare to a committed golden VECTOR within tolerance
   (atol=rtol=1e-4 — ~100x cross-arch f32 drift, ~100x under any real algorithm
   change), on both the Python and native sides against the SAME golden. Native
   ≈ golden and binding ≈ golden together prove binding ≈ native, portably.
   `.sha256` goldens replaced by `.json` vectors.

Also: the aether/mat/meridian import shims told users to `pip install
wifi-densepose[<x>]` on a missing feature — an empty extra that cannot help.
Corrected to name the real fix (rebuild with `--features <x>`); message tests
updated to assert the honest message and forbid the misleading one.

Verified on aarch64/macOS: full `python/tests/` suite 227 passed against a wheel
built with the new mechanism; `cargo check --tests --features aether` clean.
The native `.rs` parity tests were converted by inspection and cargo-checked but
not executed — they link against the PyO3 crate and no workflow runs them today
(a pre-existing gap; wiring `cd python && cargo test --features sota` into
python-ci would make the native anchor actually run).

Co-Authored-By: Ruflo & AQE

2026-07-24 10:45:00 +02: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

3 Commits