What the tools cover
Five areas. Which binary answers a given question is named in your session at the moment it runs, and the set grows without this page changing.Watching a board
RTT and serial capture, the ESP-IDF monitor driven by the agent rather than by you, and log handling that keeps a very large capture readable. A captured log is often the largest thing in a session, and loading one whole is what ends it early: searching by pattern and reading by line range is what keeps that from happening. One real capture cost 333,000 tokens loaded whole, and a few thousand read this way. For examplertt-logger.
Looking at the radio
Over-the-air BLE capture, so you can see what left the antenna rather than what your code intended to send, and the host-controller bus between your application and the radio, where a surprising number of BLE bugs actually live. Together with the application log these are the 3-layer debug: a flow that works on paper and fails in practice broke at exactly one of the three, and correlating them tells you which. For examplenrf-sniffer.
Bringing a modem up
An interactive shell to a running board that speaks both AT commands to the modem and Zephyr shell commands to the application, and a capture from inside the modem of the network signalling your application never sees. Both earn their keep in cellular. For examplemodem-trace.
Reading a crash
Fault dumps resolved to the function and the line that faulted, on nRF and ESP alike.Proving the product
An SBOM from the real build, a ranked scan of it against the published vulnerability databases, and a secure-by-design posture check read from your actual configuration: debug left enabled, secure boot off, a hardcoded credential. These drive the CRA readiness run end to end.Why they are not part of the extension
The obvious way to ship a tool is inside the release, and it has a specific flaw: a CVE database moves faster than an extension release. A scan engine whose advisory mappings are pinned to whenever we last shipped is a scan engine that is wrong most of the time. So the tools are delivered from the registry instead. Three consequences, all of them the point:They update between releases
A fix to a decoder reaches you the next time it runs, not the next time we ship.
They carry an author
Every tool names the engineer who wrote it, in the session that uses it.
They are verified before they run
Checked against a published hash. A tool that does not match does not execute.
How resolution works
1
A newer registry copy wins
A fix to a decoder reaches every machine the next time that decoder runs, whatever version of the extension is installed.
2
The bundled copy is the fallback
No network, restricted site, offline bench: the extension still has a working copy of every open tool. Nothing stops working because a registry is unreachable.
3
A tool waits for the extension it needs
Each tool states the oldest extension it will run on. One that needs a newer extension than yours is not downloaded and not run: it waits, rather than half-working against an API it does not have.
Open and proprietary
The rule is simple and worth stating plainly, because it is easy to get the wrong impression from “registry”:Every tool bundled in the extension is open source, Apache-2.0. The loggers, the sniffer, the decoders, the fault decoder, the action drivers: all of them, in the VSIX, under a licence that lets you read and fork them.The registry also serves Adsum’s own commercial tools, the CRA scan engines and the cellular tooling among them. Nothing bundled in the extension is proprietary.
Knowledge bits
The other half, and the one that came first: curated expertise rather than executables. Who wrote it, what the credit line in your session means, and what its tier tells you about how far it has been proven.