Engagement Report: Verifying a Build Before Trusting Its Claims

Seventh sample engagement report, on DuckHunter, a React/Vite/Express simulated tactical dashboard for drone-defense scenarios. Unlike the previous six, this repo has no automated test suite and no production bug to find tonight. The value here is a different kind of check: confirming the codebase actually builds clean, and verifying one specific, checkable technical claim rather than taking it on faith.

Scope and Objective

Target: the full TypeScript build (tsc --noEmit, vite build) and src/components/HardwareBridge.tsx, the one component in this simulated-dashboard repo that reaches toward real hardware: WebUSB device detection for RTL-SDR and HackRF software-defined radio dongles.

Objective: confirm the project actually compiles and builds on current dependencies, then check whether the hardware-identification values in HardwareBridge.tsx are real, correct USB vendor/product IDs or placeholder guesses.

Verification

Typecheck and production build, run fresh tonight:

tsc --noEmit        → clean, zero errors
vite build          → 2079 modules transformed, built in 907ms

No bugs found in either pass. The claim that this is a real, working build, not a prototype that only runs under npm run dev, holds.

Finding: The Hardware IDs Are Real, and the Code Path Is Genuinely Unexercised

HardwareBridge.tsx filters WebUSB device requests against three vendor/product ID pairs:

{ vendorId: 0x0BDA, productId: 0x2832 }  // RTL2832U
{ vendorId: 0x0BDA, productId: 0x2838 }  // RTL-SDR Blog V3
{ vendorId: 0x1D50, productId: 0x6089 }  // HackRF One

All three are correct, real-world values: 0x0BDA is Realtek's registered USB vendor ID (the RTL2832U and the RTL-SDR Blog V3 variant are both genuine Realtek-chipset device IDs in use today), and 0x1D50 is the OpenMoko vendor ID that Great Scott Gadgets uses for HackRF One, with 0x6089 the device's actual product ID. This is not placeholder code; someone wrote this against the real USB descriptors for these specific devices.

What it is, honestly: unexercised. There is no physical RTL-SDR or HackRF device available to this session to connect and confirm the requestDevice() call actually resolves against real hardware end to end. The code is architecturally correct and the IDs are real, which is a meaningfully different, stronger claim than "this code exists," but it is not the same claim as "this has been tested against a connected device." Both facts are reported here; neither is hidden behind the other.

Mitigations and Next Steps

1. The honest next step is hardware, not more code review. A roughly $25 RTL-SDR dongle would let this path actually be exercised end to end, turning "correct IDs, unexercised" into a real pass/fail result. Until then, this stays flagged as verified-but-untested, which is a materially different and more honest status than either "working" or "broken."
2. This is also the cleanest reuse case on the bench. The same WebUSB device-detection pattern is the exact missing piece in CrowsPupil's roadmap note about ambient RF awareness. If the hardware ever gets connected and this path gets validated here, it's a direct port, not a new build.
3. No regressions, no dead code, no stale dependency claims found in this pass. Where the previous six reports found something broken and fixed it, this one is a clean result: the build works, and the one falsifiable claim in the repo checks out.

---

GhostInThePrompt.com // Correct and untested are both true here. Neither one erases the other.