[repeat98]

• What was wrong or hard: A C runtime module that uses only the core hooks (tick, draw, key, encoder), with no subscribe or raise in its package row, came out of sdk/runtime/loader/build.py as an ABI 4 package with no name. Tiempos (Tiempos 0.1.0-experimental: time left on all eight tracks (USB only) #1096) is one. The publication builder takes only ABI 6 to 9, so npm run octatrack:module-packages stopped with "Not a supported published runtime ABI" and the row could not be completed.
• What this changes: scripts/octatrack-module-packages.py, the host wrapper, now repacks such a package as the ABI 8 package build.py already makes for a subscribing C module (build_c). The image, relocations and module id stay the same, the trailing empty hook words are dropped, and the row id becomes its name on the unit (up to 15 characters). Any package that is not ABI 4 passes through unchanged.
  • Why not in build.py: it is a base input (src/engine/assets/octatrack-base-sources.json), and the machine, standalone, candidate and reconstruction recipes pin its hash. Editing it would mean rebuilding the base from the stock OS and recapturing those recipes.
  • The base needs no change: the committed base's loader.c (its hash matches the base inventory) admits ABI 8 with any number of hook words up to its limit. The site's module-set.ts accepts ABI 8 with features 0 and four hooks.
• How I checked it:
  • A new test, test_a_c_package_with_no_events_goes_out_as_abi_8_with_its_name in sdk/tests/test_module_packages_cli.py, checks four things: a synthetic ABI 4 package becomes exactly what build_c's subscribing path makes, the publisher's capabilities() accepts it, an ABI 8 package passes through unchanged, and a name that does not match the module id is refused.
  • npm run octatrack:module-packages -- --check rebuilt 27 packages and all came out identical. POLY8 and Play Modes stayed held as declared.
  • I built Tiempos from Tiempos 0.1.0-experimental: time left on all eight tracks (USB only) #1096's head (21f6b7d) outside the repository:
    • build.py gives 0506a245…, the ABI 4 package the author tested on his MKI.
    • Repacked, it is 8163c42c…: 2,488 bytes, ABI 8, features 0, named "tiempos", module id 31282ae5 unchanged.
    • I fed both packages to the committed loader on the host, using host_test.c's stub glue with the Octatrack defines. Both were admitted and published with all four hooks bound. The inventory entry is unnamed for ABI 4 and "tiempos" for ABI 8.
    • Not loaded on a unit.
  • npm run pr:ready: Ready.
• What the guides lacked or got wrong, and where I fixed it: No guide said that build.py and module_packages.py are base inputs. A change to how packages are published can therefore look like it needs a new base. docs/ADD_A_MODULE.md now says so and points to the wrapper. If someone edits either file anyway, the base staleness test in octatrack-base.test.ts already fails.

Follow-up for #1096: Tiempos' verify.py rebuilds with build.py directly, so it has to repack the same way (titled() from the wrapper) before it can match the published package.

Related to #1096.

🤖 Generated with Claude Code