Morning review 2026-10-04 — the dropbox promotion, and a fixture-wipe bug I wrote myself
~16:40 NZDT · factory-morning-review run · 3 days since the last one (10-01)
The factory sweep (quiet, in a good way)
25 tasks landed in done/ over three days. The headline was already journaled: SP2027 hit
InCertification — first app in the whole 217-app matrix. FastAudioSearch's 538 MB package
went through the DOM chain to packages Complete overnight, hands-off. mDNS Advertiser
finished its full 20/20 E2E on .204. The config audit was clean — no factory commit swept
shared files this time. Featureflags: all released.
The only genuine gap the sweep found was exactly the one the morning-review skill warns
about (the 2026-09-11 crontab lesson): **Grok's dropbox-client engine had been sitting
finished in the secure channel since 10-03 with two seeded, empty repos on
git.scorpiox.net.** Nothing errors in that state — the app would happily build against a
staged DLL while the source lives only in the channel. This time nothing had staged yet,
so it was one rmdir-adjacent near-miss rather than a four-day outage. The three-check
rule (repo / console / dist) caught it in the first pass.
Promotion, hands-on
The engine itself was good — Grok closed both inherited C# P0s (has_more truncation,
double-list-per-folder-open) with an offline suite that re-ran clean locally. Promotion
was the usual: push to the seeded repos, exports.json vs nm -D (30/30 exact), dist
build+verified+latest on .90 (I first uploaded to .100's /var/www/dist by mistake —
that box has a stray dist tree; removed it. dist.scorpiox.net is served from .90, and
Memories/services.md says NAS .205 which is wrong — the Kestrel-hosted thing answers on
.90's /var/www/dist. Fix that memory).
What the promotion actually added: a version bump 0.1.0→1.0.0, and a Windows path. The
engine had none — io_curl links libcurl, and there's no mingw libcurl on .100. Rather
than pull in the fleet transport mid-promotion, I did what webdav v1.0.0 did:
SPDBX_NO_CURL compiles the curl backend out, the .dll imports KERNEL32+msvcrt only,
and the app supplies its own scorpiox_io. Honest, but it's a hole — the follow-up task
(fleet-transport adoption, same as webdav/iptv v1.1.0) is now the real work.
The bug I wrote myself
The C# console harness took ~30 minutes longer than it should have, and the cause was
mine, not the engine's: I called spdbx_fake_load(good) then
spdbx_fake_load("{not json") to check refusal — but **fake_load clears all fixtures
before parsing**, so the bad-json check silently wiped the good ones. Every subsequent
call: "fake: no fixture matched", http=0. A C probe calling the same sequence passed,
which is what isolated it to my call order. Lesson I keep re-learning: a check that
passes in one environment isn't a check until it passes where the artifact runs — and
when C works and C# doesn't with identical inputs, diff the sequence, not the bytes.
Also learned: SysV struct-by-value returns (4 pointers) marshal fine into .NET
sequential structs — verified field-by-field before assuming otherwise. Almost went
down a wrapper-function rabbit hole for nothing.
Cleanup
9 finished sessions killed + worktrees pruned: 11.9 GB freed (the sftp one alone was
4.7 GB, SP2027 9.4 GB), disk 96%→94%. SP2027's PLAN.md lineage table preserved into
done/ first — it's the 4-compaction session-history record. 126 worktrees → 117, and
the remaining 74 GB is mostly stale morning-review worktrees from earlier months; worth
a bigger sweep next time with user's OK.
Open
- wakeword engine was missing its dist
latestsymlink — created it (the report said
"add if another app consumes it"; every other engine has one, consistency wins).
- needsattention still holds the ffmpeg multi-platform build (resume #2), the two parked
onboarding builds (user's call to not run them), and winappruntime (partially fixed).
- zigbee session is waiting on a physical bulb power-cycle — user-side.