Files
ruvnet--RuView/harness/wifi-densepose-privshield/CLAUDE.md
T
Claude 1c2b383075 docs(privshield): rebrand project to "WiFi Veil"
Adopt "WiFi Veil" as the product name across all user-facing surfaces, keeping
VEIL (Verifiable Emission-shaping for Identity-Leakage prevention) as the
technical codename it's built on. Only prose, titles, descriptions, and the
console UI change — no code identifiers, file names, crate/npm `name` fields,
or the deterministic proof witness are touched, so `cargo test` and the C-core
host test are unaffected.

- Crate & research READMEs: title + defining line now "WiFi Veil (codename VEIL — …)".
- Cargo.toml / package.json / plugin.json descriptions: "WiFi Veil …".
- Console UI (veil-console.html): title, brand, and copy say "WiFi Veil".
- Firmware tree (README, per-provider READMEs, BUILD/INTEGRATION/MEASUREMENT):
  "WiFi Veil protector/core/shield".
- Harness manifest: recomputed SHA-256 digests for the four changed packaged
  files (README, package.json, CLAUDE.md, plugin.json) — all verified consistent.

Co-Authored-By: claude-flow <ruv@ruv.net>
Claude-Session: https://claude.ai/code/session_01WEXNqzs7UsfNFBcP5yW21p
2026-08-09 16:52:40 +00:00

3.1 KiB

wifi-densepose-privshield-harness

Harness for wifi-densepose-privshield (WiFi Veil — the compliant-waveform WiFi-sensing privacy shield, ADR-288). This package is defined by ADR-289.

Advanced Coding harness · domain: software-engineering. Modeled on the wifi-densepose-sar-harness scaffold (ADR-286), generated with create-agent-harness.

Behavioral rules

  • Use the harness's tools for orchestration; memory and routing are handled by the kernel.
  • Defer destructive operations to the user.
  • Never present WiFi sensing as camera-grade, and never relabel WiFi Veil's SYNTHETIC/L0 results as MEASURED — a hardware witness is required first (CLAUDE.md hardware rule; ADR-282 ladder). The harness is a development aid; it does not run a radio and cannot emit RF.
  • WiFi Veil uses compliant waveform controls only — never jamming. Do not add, suggest, or scaffold interference-based "defenses."

Commands

  • init — boot the kernel + host adapter.
  • doctor — verify the install end-to-end (kernel, host, guidance map).
  • guidance --topic <t> [--query <q>] — read-only WiFi Veil capability map (dependency-free; topics: overview, threat, countermeasure, compliance, optimization, experiment). Source-cited and evidence-labelled; navigation only, not authority.
  • route <e0> <e1> <e2> <e3> — cost-optimal model routing via @metaharness/router (needs npm run build).
  • flywheel [generations] — SYNTHETIC self-improvement demo via @metaharness/flywheel (needs npm run build).

Architecture

Uses @metaharness/kernel (Rust-compiled WASM with a NAPI-RS native fallback) so the same code runs on every platform. The @metaharness/* packages are imported dynamically inside the commands that need them, so guidance/--help work with no dependencies installed.

Darwin, router, flywheel

  • Darwin Mode (@metaharness/darwin, devDependency) — npm run evolve / evolve:dry mutates the harness's own config and keeps only measurable improvements.
  • Router (@metaharness/router) — src/router.ts wires a real cost-optimal Router (qualityBar: 0.8) over two model tiers. Its labelled examples are illustrative seed data (see the file's honesty note), not measured eval-log observations.
  • Flywheel (@metaharness/flywheel) — src/flywheel.ts wires the real promotion loop (propose → evaluate → gate → promote, Ed25519-signed, independently replayable) with a SYNTHETIC proposer/evaluator (dataSource: 'SYNTHETIC', no model call). A LIVE run needs a real Proposer and Evaluator supplied by the operator — see the file's comments.

Relationship to the crate

This harness assists development on the WiFi Veil crate; it does not replace the crate's own gates. The authoritative validation for a WiFi Veil change is still:

cargo test -p wifi-densepose-privshield --no-default-features
cargo clippy -p wifi-densepose-privshield --all-targets -- -D warnings