ThingStudio's command-line interface (CLI) used to reinstall every library imported by a MicroPython flow, even when the board's firmware already contained the same code. One test flow pushed 13 libraries and about 40 KB into /lib on every deployment. The new path reads the board's startup inventory and sends only libraries whose content hash is missing or different.
The bug was hidden in how MicroPython bytecode is built. Its compiler records the source filename in the output, so compiling font_body12 under a different temporary name produced different bytes and a different hash. ThingStudio now compiles deployable libraries through the editor's own WebAssembly compiler with the same /in.py filename used to build the firmware inventory. Tests pin a known board hash, check the skip rule, and confirm that the JavaScript and Python hash implementations agree.
This is a narrow fix with a useful lesson for embedded test systems: content-addressed deployment works only when every build path produces identical bytes. Teams using ThingStudio for scripted hardware-in-the-loop tests, where software drives a real board and checks its response, should see shorter setup time and less flash churn on every run. The next measure worth publishing is the elapsed deployment time before and after this change on the project's 13-library flow.