§7 names eBuild's MVP responsibility as:
eBuild — Setup, configure, build, test, flash, monitor.
§7.1 gives the golden path verbatim:
ebuild setup
ebuild new hello-eos
cd hello-eos
ebuild configure --board <reference-board>
ebuild build
ebuild test
ebuild flash
ebuild monitor
Success criterion: a new developer should reach a verified first firmware run
quickly and repeatably.
Two of the eight commands do not exist:
ebuild setup EXISTS
ebuild new EXISTS
ebuild configure EXISTS
ebuild build EXISTS
ebuild test MISSING
ebuild flash EXISTS
ebuild monitor MISSING
Full command list today:
add analyze build clean configure firmware flash generate-board generate-boot
generate-project info install integration list-packages models new package
pipeline qemu repos sdk setup system
Twenty-three commands, and neither of the two the MVP definition names.
What this costs
The golden path stops at step 5 of 8. test is the step that makes the run
verified rather than merely completed, which is the stated success criterion —
without it a developer builds, flashes, and then has no way to find out whether
what they flashed works. monitor is how they would see it run at all.
ebuild qemu exists and is adjacent to monitor, but it is a different thing:
it launches an emulator, not a serial console onto whatever the developer just
flashed. Step 7 flashes real hardware; step 8 has to be able to watch real
hardware.
Scope
Two commands, following the CLI conventions already in ebuild/cli/commands.py:
ebuild test — build the project's tests and run them, reporting the
counts the underlying runner printed rather than inferring them from exit
status. Must fail when tests fail; a test command that cannot go red is worse
than none.
ebuild monitor — open a serial console on the target's port, with the
baud rate from the board configuration, --port and --baud overrides, and a
clean exit on Ctrl-C. Must report an actionable error when no device is
present rather than hanging.
Both need to work without hardware attached to be testable in CI: test runs on
the host, and monitor must fail cleanly and immediately with no port.
§7 names eBuild's MVP responsibility as:
§7.1 gives the golden path verbatim:
Two of the eight commands do not exist:
Full command list today:
Twenty-three commands, and neither of the two the MVP definition names.
What this costs
The golden path stops at step 5 of 8.
testis the step that makes the runverified rather than merely completed, which is the stated success criterion —
without it a developer builds, flashes, and then has no way to find out whether
what they flashed works.
monitoris how they would see it run at all.ebuild qemuexists and is adjacent tomonitor, but it is a different thing:it launches an emulator, not a serial console onto whatever the developer just
flashed. Step 7 flashes real hardware; step 8 has to be able to watch real
hardware.
Scope
Two commands, following the CLI conventions already in
ebuild/cli/commands.py:ebuild test— build the project's tests and run them, reporting thecounts the underlying runner printed rather than inferring them from exit
status. Must fail when tests fail; a test command that cannot go red is worse
than none.
ebuild monitor— open a serial console on the target's port, with thebaud rate from the board configuration,
--portand--baudoverrides, and aclean exit on Ctrl-C. Must report an actionable error when no device is
present rather than hanging.
Both need to work without hardware attached to be testable in CI:
testruns onthe host, and
monitormust fail cleanly and immediately with no port.