fix(sdk): fail the build when list-ingredients fails, instead of repacking stale

[MattDHill]

s9pk.mk could print ✅ Build Complete!, exit 0, and leave the previous s9pk in place — omitting the changes just made to the package, with nothing to indicate anything was wrong.

Cause

INGREDIENTS := $(shell start-cli s9pk list-ingredients 2>/dev/null)
$(BASE_NAME)_%.s9pk: $(INGREDIENTS) $(GIT_DEPS) | check-deps

list-ingredients produces the s9pk's entire source-dependency list, ./javascript/index.js included. Nothing else in the file ties the package to its TypeScript.

$(shell) discards exit status. When the command fails it exits 9, its stderr is swallowed by 2>/dev/null, and INGREDIENTS is simply empty — so:

• every source file detaches from the s9pk's prerequisites;
• javascript/index.js is orphaned from the graph entirely, so its own rule (which does correctly depend on $(shell find startos -type f)) is never visited;
• the target's only surviving prerequisites are .git/HEAD and .git/index. If the existing s9pk is newer than both, make declares it up to date;
• arch/% has no file behind it, so its recipe runs regardless and prints the success banner.

Reproduced with source at 09:36:01, s9pk at 09:36:00, .git/index at 09:28:42:

$ make x86
Network Error: Failed to resolve hostname: demo.local
✅ Build Complete!
$ echo $?
0                       # s9pk mtime unchanged — not rebuilt

The window is the ordinary inner loop: edit a source file, rebuild, no git activity in between. Run git add first and .git/index is newer, so the target is out of date, reaches pack, and fails loudly (exit 2) — which is why this presents intermittently and reads as a network problem rather than a stale build.

Fix

Append a sentinel on failure and $(error) on it. Deliberately not $(.SHELLSTATUS): it is undefined on the GNU Make 3.81 that macOS still ships, where ifneq ($(.SHELLSTATUS),0) would fire the guard on every build.

Verified

Against a real package (tor-startos) with the configured host unresolvable:

• failure path — errors with the message below, exit 2, no s9pk produced;
• success path — with list-ingredients returning normally, INGREDIENTS holds the clean list with no sentinel, the guard stays silent, and a touched source file correctly triggers an ncc rebuild (exit 0) — the very rebuild the bug was suppressing.

s9pk.mk:14: *** `start-cli s9pk list-ingredients` failed, so make cannot tell
which files the s9pk depends on and would silently repack the previous build.
Run it directly to see the error — a host in .startos/config.yaml that no longer
resolves is a common cause, since start-cli resolves it even for commands that
contact no server.  Stop.

Relationship to #3601

#3601 is today's trigger: start-cli resolves the configured host even for commands that contact no server, so a workspace naming a .local box that is off the LAN fails every invocation. That remains a separate fix. This one is independent — it keeps any future failure of list-ingredients from silently producing a stale package, which is the part that can ship wrong bits.

🤖 Generated with Claude Code

Also here

projects/start-os/AGENTS.md listed projects/start-sdk/s9pk.mk under "don't edit generated binding files", beside the ts-rs osBindings. Nothing generates it, and this repo is where it is meant to be edited — its DO NOT EDIT header addresses package authors reading the copy npm put in their node_modules. Followed as written, that line forbids the fix above.