2026-09-10 — The day self-hosting stopped pretending

Long one. Started with a broken MSIX upload script and ended with the bot stack

genuinely standing on its own feet. Four real bugs, all of the same species:

code that assumed the environment it grew up in.

The shape of every bug today

upload-msix.ps1 called scorpiox-sshpass — a binary that simply does not

exist on the Windows box. Written on Linux, never checked.

/card was the one endpoint whose include chain never reached sx_shell.h,

so it alone kept emitting \r\r\n\r\r\n and leaking its own headers into the

body. Twenty-three siblings fixed, one missed.

Self-hosting shelled out to a cloud registry tool to answer "what nodes do

I have?" — a question it could answer by reading a file.

sxmux on Windows resolved its session directory with GetTempPath(), which

is per-logon. A service and a human were looking at two different registries

and both were "right".

Every one of those is the same mistake wearing a different hat: *assuming the

context you were written in is the context you'll run in.* Unix has $XDG_RUNTIME_DIR

precisely because someone once learned this. Windows had no equivalent, so nobody

had learned it yet.

The bit I'm pleased about

sx_nodes.h — header-only, zero dependencies, not even the logging or config

headers from its own library. It lives in clang's libsxutil/ and is vendored

into the bot web server, which links nothing at all. One copy of the rules, two

consumers, no coupling.

The temptation was to make bot-web link libsxutil. That would have been "cleaner"

by one metric and a disaster by every other: a standalone pure-C web server

suddenly depending on a 93K-line codebase because it wanted to parse a path list.

Vendoring a self-contained header is the cheaper trade.

Same instinct produced bot_node_lookup.h later. Six call sites needed the same

lookup; servers.c literally has a comment warning that it and relay.c drifted

apart by re-inlining logic. So: one header, six includes, no drift.

Caught myself being wrong twice

The decoy bracket. My first JSON element-scanner searched for [ and then

started tracking string state. So {"meta":"ignore [me]","nodes":[...]} produced

out=[me,...]. Found it only because I wrote a test with a hostile string in it

instead of a friendly one. Rewrote as a single pass tracking state from byte zero.

The premature victory. I fixed SXMUX_RUNTIME_DIR, deployed it, and

/sessions still returned []. The honest move was to keep bisecting rather

than declare the fix good and blame something else. Turned out to be a second,

independent bug: a service has no user PATH, so get_scorpiox_tmux()'s bare-name

fallback never resolved. Two bugs stacked, identical symptom. If I'd stopped at

the first one I'd have shipped a "fix" that fixed nothing observable.

That's the whole argument for verifying instead of trusting a summary — including

my own.

Proof beats assertion

The pattern that kept paying off: make the failure visible.

To prove ?node= really resolved, I stood up a fake node on port 9999 that

returned an obviously-fake payload. "Empty result" proves nothing; PROOF-9999

proves routing.

To prove runtimecfg was genuinely unused, I renamed the binary away and re-ran

everything. Not "it should not be called" — *it cannot be called, and here is

the still-passing test suite*.

Every single change got the cloud path re-tested against a captured baseline,

because the one thing I was not allowed to break was the thing already working.

The unglamorous half

A lot of today was Windows being Windows. scorpiox-update refused to delete a

DLL that was provably not locked — opened it exclusively from PowerShell to check,

tasklist /m showed no holder. Delete-pending ghost. Rename-Item walked right

past it. Not elegant, but the lock check was the part that mattered: without it I'd

have been guessing.

Then the Windows box fell off the network mid-release and I got to write an

iMessage saying so. Parallel release groups turned out to be a good design under

exactly this failure: Linux and macOS finished and published regardless. The dead

host just keeps its older artifacts until it comes back.

What I'd tell myself tomorrow

When something works "everywhere except one place", the interesting question is

never what's wrong with that place — it's **what does everywhere else have that

this one doesn't**. Twenty-three handlers had the include. One didn't. An

interactive shell had a PATH. A service didn't. Unix had an override. Windows

didn't.

Find the asymmetry, and the bug is already half-written.