Proposal: URML (substrate-neutral robot intent) capability-manifest mapping for TinyGo — Go-on-MCU firmware-language substrate

[idoco2003]

Hi @tinygo-org team,

Proposing a URML v0.1 capability-manifest mapping for TinyGo over tinygo-org/tinygo. URML (Universal Robot Language, Apache-2.0) is an open spec for substrate-neutral robot intent.

TinyGo brings the Go language to MCU substrates spanning RP2040, SAMD21/51, nRF52, STM32, AVR, and WebAssembly. URML's manifest declares which firmware-language substrate is loaded; TinyGo joins MicroPython, CircuitPython, native C/C++, and Arduino C++ in the substrate enum URML's sibling Move-13 MCU + maker RFCs populate. The 90+ TinyGo targets need an identifier-mapping convention in URML's manifest (similar to PlatformIO's 900+ board catalog).

This is proposal-only, posted as part of URML's Move #13 outreach (15 engageable RFCs in this wave).

Full RFC: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0183-tinygo-outreach.md

Questions worth tinygo-org maintainer input on:

1. Firmware-language substrate manifest fields. URML's v0.1 has no tinygo firmware-language declaration. Spec RFC queued. Manifest field expectations from the TinyGo perspective?
2. TinyGo-target catalog identifier scheme. Should URML's manifest use TinyGo's target-id directly, or a separate URML identifier mapped to it?
3. WebAssembly target scope. Should URML's manifest declare WebAssembly as a valid TinyGo target (non-MCU substrate), and how does that compose with URML's robotics-class manifest assumptions?
4. Adapter home. URML repo (reference/edu-runtime/TinyGoAdapter), TinyGo-community-maintained tinygo-org/tinygo-urml-bridge, or external?
5. Conformance listing. Would the tinygo-org maintainers consider a README link to URML's compatible-runtimes registry once a working adapter ships?
6. Anything else.

Ido Yahalomi (URML maintainer, urml.dev, greenvh@gmail.com)

---

AI-assisted prose, maintainer-reviewed before posting (see VIBE.md). Human-only correspondence available on request.