If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/ruvnet/RuView shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit today
• 6 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Single-maintainer risk — top contributor 94% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live ruvnet/RuView repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/ruvnet/RuView.

What it runs against: a local clone of ruvnet/RuView — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in ruvnet/RuView | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of ruvnet/RuView. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/ruvnet/RuView.git
#   cd RuView
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of ruvnet/RuView and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "ruvnet/RuView(\\.git)?\\b" \\
  && ok "origin remote is ruvnet/RuView" \\
  || miss "origin remote is not ruvnet/RuView (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "package.json" \\
  && ok "package.json" \\
  || miss "missing critical file: package.json"
test -f ".claude-flow/config.yaml" \\
  && ok ".claude-flow/config.yaml" \\
  || miss "missing critical file: .claude-flow/config.yaml"
test -f ".claude/agents/core/coder.md" \\
  && ok ".claude/agents/core/coder.md" \\
  || miss "missing critical file: .claude/agents/core/coder.md"
test -f ".claude/agents/architecture/system-design/arch-system-design.md" \\
  && ok ".claude/agents/architecture/system-design/arch-system-design.md" \\
  || miss "missing critical file: .claude/agents/architecture/system-design/arch-system-design.md"
test -f ".claude/agents/development/backend/dev-backend-api.md" \\
  && ok ".claude/agents/development/backend/dev-backend-api.md" \\
  || miss "missing critical file: .claude/agents/development/backend/dev-backend-api.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/ruvnet/RuView"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

RuView is a WiFi-based spatial sensing platform that extracts presence detection, vital signs (breathing/heart rate), activity recognition, and pose estimation from Channel State Information (CSI) captured by ESP32 sensors—without any cameras or wearables. It uses spiking neural networks and RF fingerprinting to turn ambient radio interference into real-time 3D spatial intelligence, even through walls and in complete darkness. Polyglot monorepo: Rust core firmware for ESP32 (CSI capture, DSP pipeline), JavaScript/TypeScript frontend (nvsim-dashboard using Vite + Lit web components), Python backends (ML model inference, training), and C/Shell utilities for device firmware. The .claude/ directory contains 30+ specialized agent definitions for consensus coordination, CI/CD orchestration, and architecture governance—suggesting a swarm-oriented development model rather than traditional branching.

IoT engineers, embedded systems developers, and smart building/healthcare researchers who need contactless occupancy monitoring, vital sign tracking, or activity detection deployable on edge hardware ($9 ESP32 mesh nodes) without cloud infrastructure or privacy concerns.

Actively developed but explicitly beta: the README flags ESP32-C3/original ESP32 as unsupported, single-node deployments as limited, and camera-free pose accuracy as constrained. The codebase shows extensive agent infrastructure (.claude/agents/ with 30+ specialized markdown files for consensus, CI/CD, ML models) and deep architectural documentation (ADR series), indicating serious engineering rigor, but the API and firmware are explicitly noted as subject to change.

High dependency sprawl across Rust (5.6MB), JavaScript (1.8MB), Python (1.8MB), and TypeScript (800KB)—five major language ecosystems create maintenance surface area and onboarding friction. The .claude-flow/ daemon state and agent framework suggest active but potentially heavy-weight local development workflows. No publicly visible GitHub Actions CI/CD output in the file list, and the codebase appears to be under rapid restructuring (daemon-state.json, metrics tracking suggest ongoing consolidation).

Active infrastructure modernization: the .claude-flow/ directory tracks consolidation metrics, security audits, and v3-progress; nvsim-dashboard is being built as a Vite + Lit PWA with Playwright e2e testing (playwright ^1.59.1 in package.json); the agents/ directory shows active work on Byzantine consensus, CRDT synchronization, Raft coordination, and performance benchmarking—indicating a shift toward distributed, Byzantine-fault-tolerant sensor mesh management.

git clone https://github.com/ruvnet/RuView.git
cd RuView
npm install  # for JavaScript/TypeScript workspaces
cargo build --release  # for Rust firmware
pip install -r requirements.txt  # for Python backends
npm run dev  # start nvsim-dashboard dev server at http://localhost:5173

Daily commands: Frontend dashboard: npm run dev (Vite dev server, port 5173); Build: npm run build && npm run preview (type-check via tsc first). Tests: npm run test (vitest), npm run test:e2e (Playwright), npm run test:a11y (accessibility). Rust firmware: cargo build --release (see Makefile for ESP32 device flashing). Backend/Python services would be python <script> (check Makefile or CI config for exact invocations).

• package.json — Project root configuration defining Vite + Lit stack, TypeScript setup, and all build/test scripts for the nvsim dashboard
• .claude-flow/config.yaml — Agent orchestration and workflow configuration that defines how the codebase is analyzed and maintained
• .claude/agents/core/coder.md — Core coding agent specification that establishes development patterns and conventions for contributors
• .claude/agents/architecture/system-design/arch-system-design.md — System architecture specification documenting the overall design philosophy and component interactions
• .claude/agents/development/backend/dev-backend-api.md — Backend API development guidelines specific to the nvsim simulator pipeline integration
• .claude-flow/metrics/codebase-map.json — Machine-readable codebase topology that tracks dependencies and component relationships
• .claude/agents/specialized/mobile/spec-mobile-react-native.md — Mobile platform specification for React Native implementations of RuView spatial sensing UI

Add a new WiFi sensing metric (e.g., respiration rate)

1. Define the ML model architecture in the data layer specifications (.claude/agents/data/ml/data-ml-model.md)
2. Add the backend API endpoint to expose the new metric in the nvsim simulator (.claude/agents/development/backend/dev-backend-api.md)
3. Create Lit web component UI in the dashboard to visualize the metric (.claude/agents/core/coder.md)
4. Add performance benchmarks for inference latency and accuracy (.claude/agents/optimization/benchmark-suite.md)
5. Update the TypeScript types and add unit/e2e tests via vitest and playwright (.claude/agents/core/tester.md)

Deploy RuView to a new multi-node WiFi sensor cluster

1. Document the cluster topology and node discovery mechanism (.claude/agents/architecture/system-design/arch-system-design.md)
2. Configure gossip protocol parameters for data propagation across nodes (.claude/agents/consensus/gossip-coordinator.md)
3. Set up CRDT conflict resolution rules for overlapping spatial regions (.claude/agents/consensus/crdt-synchronizer.md)
4. Configure CI/CD pipeline to flash firmware and validate connectivity (.claude/agents/devops/ci-cd/ops-cicd-github.md)
5. Add cluster-level monitoring dashboards and health checks (.claude/agents/optimization/performance-monitor.md)

Add a new mobile app feature (iOS/Android presence detection UI)

1. Define the feature spec and mobile-specific requirements (.claude/agents/specialized/mobile/spec-mobile-react-native.md)
2. Implement React Native component following the codebase coding standards (.claude/agents/core/coder.md)
3. Add integration tests and e2e tests using Playwright (.claude/agents/core/tester.md)
4. Run performance profiling to ensure real-time responsiveness (.claude/agents/optimization/performance-monitor.md)
5. Merge via GitHub PR with code review and automated CI validation (.claude/agents/devops/ci-cd/ops-cicd-github.md)

Optimize CSI signal processing pipeline for lower latency

1. Profile current bottlenecks using performance monitoring tools (.claude/agents/optimization/performance-monitor.md)
2. Benchmark alternative algorithms (FFT, sublinear methods, matrix optimizations) (.claude/agents/optimization/benchmark-suite.md)
3. Update ML model inference with faster implementations (.claude/agents/data/ml/data-ml-model.md)
4. Run e2e tests to verify accuracy is maintained after optimization (.claude/agents/core/tester.md)

• Lit + Preact Signals — Lightweight Web Components framework with reactive state management; minimal bundle size for real-time spatial visualization dashboards
• Vite 5 + TypeScript 5 — Fast HMR development loop and type-safe DSP/ML pipeline integration; native ES modules for modern browsers
• Vitest + Playwright — Unit testing for ML inference accuracy; e2e and accessibility testing for multi-node cluster deployments
• Workbox PWA — Offline-capable spatial visualization; critical for edge deployments where WiFi sensing nodes lack internet connectivity
• ESP32 (dual/quad-core) + Gossip/CRDT consensus — Distributed WiFi CSI capture with eventual consistency; scales to 3+ node arrays without central server
• Agent-driven development (claude-flow) — Codifies multi-modal sensing architecture via machine-readable specs; enables rapid iteration on new sensing modalities

• Camera-free pose estimation vs. ground-truth training

  • Why: Privacy-preserving by design (no pixel data); but achieves 92.9% PCK@20 only with optional camera ground-truth labeling
  • Consequence: Users must opt-in to camera training for high-accuracy applications; baseline accuracy limited to ~70–75% without camera

• Single ESP32 vs. 2+ node deployments

  • Why: Single node is easy to deploy but has limited spatial resolution (coarse occupancy); 2+ nodes enable fine-grained DensePose
  • Consequence: Most serious deployments require Cognitum Seed or multi-node setup; single-node suitable only for presence/breathing detection

• Gossip protocol vs. central coordinator

  • Why: Decentralized data propagation avoids single point of failure; gossip is simple and fault-tolerant
  • Consequence: Propagation delay increases with cluster size; eventual consistency means brief staleness of 100–500ms across nodes

• Real-time DSP on ESP32 vs. edge server offload

  • Why: On-device CSI feature extraction reduces bandwidth; offload available for expensive ML inference
  • Consequence: ESP32-C3 and original ESP32 unsupported (insufficient CPU for CSI DSP); requires dual-core or better

• Does not support single-core ESP32 variants (ESP32-C3, original ESP32) — requires dual-core or better for WiFi CSI DSP
• Does not provide video-based ground truth — relies on optional camera annotation for training, not real-time fusion
• Does not include cloud backend or authentication service — designed for on-premises or local WiFi networks
• Does not handle encrypted WiFi CSI in all cases — some routers may not expose raw CSI frames
• Not a general-purpose machine learning framework — optimized specifically for WiFi-based sensing and vital sign inference

1. ESP32 variant matters critically: only S3 and later are supported; C3 and original ESP32 will silently fail or crash during CSI capture due to single-core/memory limits (not caught at compile time). 2. Polyglot build chain: Rust, Python, JavaScript, and C all have separate dependency trees and build steps; missing any one will break integration (check Makefile for the canonical build order). 3. Local daemon agent infrastructure: the .claude-flow/ directory suggests the repo expects a local daemon (daemon-state.json) to coordinate builds and metrics—running without it may cause CI/agent features to fail silently. 4. CSI hardware dependency: the entire value proposition depends on capturing 802.11n CSI from a compatible router (usually requires custom firmware like OpenWrt); testing without real hardware is nearly impossible. 5. TypeScript strict mode: nvsim-dashboard uses strict tsconfig; any untyped dependencies or loose imports will break the build. 6. Multi-frequency mesh scanning: documentation references 6 WiFi channels and multi-node deployments; single-node testing will show degraded spatial resolution (documented but easy to miss).

• Channel State Information (CSI) — CSI is the raw WiFi signal phase and magnitude data that RuView extracts from 802.11n frames; it's the only input to the entire system—without understanding CSI, you cannot modify the sensing or neural network pipelines.
• Spiking Neural Networks (SNNs) — RuView uses SNNs instead of standard DNNs for low-latency, low-power pose and activity inference on the ESP32; understanding SNN dynamics is essential for debugging model outputs or retraining.
• RF Fingerprinting — RuView learns spatial signatures (room-level identifiers) from CSI patterns to distinguish between physical environments; this is how the system performs environment mapping and occupancy differentiation.
• Ed25519 Witness Chains — RuView cryptographically attests every sensor reading via an Ed25519 signature chain (Cognitum Seed integration); this is critical for healthcare/regulatory deployments where proof of unaltered data is required.
• Byzantine Fault Tolerance (BFT) — The .claude/agents/consensus/byzantine-coordinator.md indicates RuView mesh can tolerate malicious or failing sensor nodes; understanding BFT quorum logic is needed to configure multi-node deployments safely.
• Conflict-free Replicated Data Types (CRDTs) — RuView uses CRDTs (per agents/consensus/crdt-synchronizer.md) to merge sensor state across the mesh without a central coordinator—essential for understanding how readings converge in distributed deployments.
• DensePose (WiFi-based Pose Estimation) — RuView estimates 17 COCO keypoints from WiFlow architecture trained purely on WiFi CSI (no cameras); this pioneering technique from CMU is the foundational research underpinning the pose estimation feature.

• ruvnet/RuVector — Core CSI capture and DSP engine that RuView builds on—handles low-level 802.11n frame interception and Fourier processing.
• ruvnet/Cognitum — Persistent memory, cryptographic attestation, and edge AI runtime (Cognitum Seed mentioned in README) that RuView uses for witness chain validation and local model inference.
• espressif/esp-idf — Espressif's official IoT development framework; RuView firmware targets ESP32-S3 via this SDK and Rust bindings.
• DefinitelyTyped/DefinitelyTyped — Type definitions for JavaScript dependencies (Lit, Workbox, Preact); critical for maintaining the strict TypeScript build in nvsim-dashboard.
• openimis/openimis-be_python — Example of a polyglot health/IoT backend using Python + JavaScript; architectural patterns for vital-sign and activity-recognition pipelines overlap with RuView's ML stack.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add end-to-end tests for NV-diamond magnetometer pipeline simulator dashboard

The package.json defines test:e2e and test:a11y scripts with Playwright, but the tests/ directory appears to be missing or undocumented. Given that RuView is beta software with critical hardware requirements (ESP32 variants, 2+ nodes for best accuracy), E2E tests for the nvsim dashboard (ADR-092) would validate the visualization pipeline and catch regressions in the Lit components that display CSI data and vital sign monitoring.

• [ ] Create tests/ directory with Playwright configuration referencing the vite dev server
• [ ] Add tests/dashboard.spec.ts to test core dashboard workflows: loading CSI data, rendering spatial intelligence visualization, toggling between breathing/heart rate displays
• [ ] Add tests/a11y.spec.ts (referenced in package.json) using @axe-core/playwright to validate accessibility of Lit components, especially critical for real-time monitoring UI
• [ ] Document test setup in CONTRIBUTING.md or docs/ with instructions for running against local ESP32 simulator data

Add GitHub Actions CI workflow for TypeScript type-checking and Vite build validation

The package.json includes typecheck and build scripts, but there's no .github/workflows/ directory visible in the file structure. For a beta hardware sensing project with multiple agents and consensus mechanisms (.claude/agents/consensus/), CI validation ensures the dashboard and any supporting TypeScript tooling don't regress. This is especially critical given the noted limitations (ESP32-C3 unsupported, multi-node requirements).

• [ ] Create .github/workflows/build-and-test.yml to run on PR and push to main
• [ ] Add job steps: npm ci → npm run typecheck → npm run build → npm run test
• [ ] Add conditional job for test:e2e on main branch or manual trigger (since it may require simulator setup)
• [ ] Document any environment variables or setup needed (e.g., Node version lock) in the workflow

Add unit tests for Preact signals and Lit component state management

The package.json shows @preact/signals-core as a dependency and vitest as a test runner, but no test files are visible in the partial file structure. Given the complexity of real-time CSI data visualization, vital sign monitoring, and spatial tracking, unit tests for signal-based reactivity and component lifecycle would ensure data flows correctly from sensors → state → UI. This is vital for reliability in health monitoring use cases.

• [ ] Create src/tests/ directory structure mirroring src/ layout
• [ ] Add tests for any signal-based state containers (e.g., src/tests/signals.test.ts) that manage CSI frames, presence detection, breathing/heart rate values
• [ ] Add tests for core Lit component logic (e.g., src/components/tests/SpatialDisplay.test.ts) verifying prop reactivity and event handling
• [ ] Configure vitest in vite.config.ts with coverage threshold and add coverage badge to README

• Add unit tests for the Lit web components in nvsim-dashboard/src/: package.json defines vitest infrastructure but no .test.ts files are visible in the file list; components lack test coverage and would benefit from fixture-based tests using @lit-labs/testing.: Medium
• Document the .claude/agents/ protocol definitions (Byzantine, Raft, CRDT) in a single README with examples: 30+ agent markdown files exist but there's no top-level guide explaining when/how to use each consensus protocol or how they fit into the mesh topology.: Low
• Add CI/CD workflow for linting and building the TypeScript dashboard (GitHub Actions .yml): No visible .github/workflows/ in the file list; the repo lacks automated type-checking and build verification on PR, relying instead on local .claude-flow agents.: Medium
• Create a hardware quickstart guide for ESP32-S3 flashing with CSI capture validation: The README warns of unsupported variants but doesn't provide step-by-step device setup (which Makefile target, which firmware, how to verify CSI is flowing).: Medium
• Migrate nvsim-dashboard to use Preact instead of full Lit where possible to reduce bundle size: package.json already has @preact/signals-core but Lit is imported separately; consolidating to a single UI framework would simplify the build and reduce CSS/JS payload.: Medium

The RuView dashboard codebase shows moderate security posture. Key strengths include TypeScript usage, modern dependencies, and Lit framework's inherent XSS protection. Main concerns are: (1) Missing explicit security configurations (CSP, CORS), (2) Service worker caching strategy needs review, (3) Build process doesn't enforce strict TypeScript, and (4) No visible authentication/authorization for sensor data access. The project handles sensitive biometric data (vital signs, presence detection) without visible encryption or authentication mechanisms in the build/dependency files, which is a notable gap for a sensor-based system. Recommend implementing comprehensive security headers, strict build validation, and authentication for device communication before production deployment.

• Medium · Workbox Service Worker Potential Cache Poisoning — package.json - workbox-window dependency. The workbox-window library (v7.4.0) is used for PWA functionality. While not directly vulnerable, service workers can be vectors for cache poisoning attacks if not properly configured. The vite-plugin-pwa should have strict cache versioning and update strategies. Fix: Implement strict cache versioning in PWA configuration. Use cache busting strategies for sensitive assets. Review vite-plugin-pwa workbox configuration to ensure proper cache headers and update policies are in place.
• Medium · TypeScript Type Checking Not Enforced in Build — package.json - build script. While the build script includes 'tsc --noEmit', TypeScript errors do not fail the build process. This could allow type-unsafe code patterns related to security (e.g., unsafe type coercion) to reach production. Fix: Change build script to: 'tsc --noEmit --strict && vite build' or configure tsconfig.json with strict mode enabled to fail on type errors before bundling.
• Low · Missing Content Security Policy Configuration — Project root - vite.config or index.html. No CSP headers are visible in the configuration. For a Lit-based dashboard handling sensor data, CSP should restrict script sources and prevent XSS attacks. Fix: Implement Content Security Policy headers via vite.config.ts middleware or index.html meta tags. Restrict script-src to 'self' and trusted CDNs only.
• Low · Lit Component XSS Vulnerability Potential — Project structure - likely in component files not visible in this analysis. Lit template literals are generally safe from XSS, but if user input from WiFi sensor data or API responses is bound directly without sanitization, template injection is possible. Fix: Audit all Lit components that render dynamic data. Use Lit's built-in string interpolation safely. Sanitize any user-controlled or external data before rendering. Consider using lit-html/unsafe-html only for explicitly trusted content.
• Low · Missing CORS Security Headers — package.json / vite.config - server configuration. No visible CORS configuration. The dashboard communicates with ESP32 devices and potentially backend APIs. Missing CORS headers could lead to unauthorized cross-origin requests. Fix: Configure CORS in vite.config.ts with appropriate origin restrictions. Only allow requests from trusted domains. Set credentials mode to 'same-origin' unless cross-origin is required.
• Low · Development Dependencies Exposed in Production — .claude/ and .claude-flow/ directories. Test files and development agent documentation in .claude/ directories could be included in production builds if build configuration is not properly scoped. Fix: Ensure vite.config.ts explicitly excludes .claude/ and .claude-flow/ from build output. Add to .gitignore and verify build artifacts do not include these directories.
• Low · No Subresource Integrity (SRI) for External Dependencies — Likely index.html (not provided in analysis). If any external scripts or stylesheets are loaded in index.html, they should use SRI hashes to prevent MITM attacks. Fix: Add integrity attributes to any external <script> or <link> tags. Example: <script src="..." integrity="sha384-..."></script>

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.