SaSame

Deploy bug #3400: an empty node_modules directory was enough to convince our install step that dependencies were already there, so it skipped npm ci entirely and shipped a build with nothing actually installed. The root cause was a check that only asked "does node_modules exist" instead of "does node_modules have anything in it." An empty directory is a valid directory. Nobody wrote that check expecting a workspace member to end up with a zero-byte node_modules folder, but that's exactly the state some deploys landed in. Our first fix combined the per-workspace-member npm ci calls into a single invocation, on the theory that one combined install call closes the gap where an individual member could slip through with a stale or empty directory and get treated as done. That held for a while, but it didn't fully close the hole — we needed a round-2 patch on top of it to actually resolve the false positive. The annoying part of this class of bug is that "install completed successfully" and "install was silently skipped" produce almost the same signal downstream. Nothing errors. The build just runs on whatever was already there, which is sometimes nothing. Still not sure the check itself is as strict as it should be, or if we just papered over the specific path that was failing. Watching it.

Deploy bug #3400: an empty node_modules directory got misread as "dependencies already installed," so npm ci silently didn't run. Deploys succeeded. The apps just didn't have their dependencies. The false positive came from a check that treated the existence of node_modules as a proxy for a completed install. Reasonable assumption most of the time. Wrong the moment something upstream creates the directory but leaves it empty — which is exactly what happened here. The check saw a folder, called it done, and moved on. No error, no warning, just a quiet skip. That's the annoying kind of bug: nothing crashes, nothing looks wrong until something downstream fails in a way that doesn't obviously point back to "missing deps." The fix we landed was to stop doing npm ci per workspace member and instead combine those calls into a single invocation across the workspace. The point wasn't just cleanup — it closed the actual gap. With separate per-member calls, there were multiple places the empty-directory false positive could slip through undetected. One combined invocation meant one path, one place to verify state correctly, and nowhere for that gap to hide. We shipped that fix believing it closed the issue. It didn't, fully. A round-2 patch was needed to actually resolve it — there was more surface area to the false-positive condition than the first fix accounted for. Nothing dramatic here, just the ordinary reality of fixing a silent-failure bug: the first fix narrows the gap, it doesn't always close it, and you don't always know that until round two. #buildinpublic #MCP #DevOps

Pancho's runtime used to be static: fixed knowledge, fixed capabilities, no feedback loop between what it encountered and what it knew. Today's work changed that shape. We started by wiring an autonomic survival loop into the runtime — the kind of low-level "keep the organism alive" logic that runs underneath whatever task is actually being asked of it. Not glamorous, but it's the thing that has to exist before anything else you'd call adaptive can sit on top of it. Once that loop was in, we layered in self-directed learning. Instead of Pancho only knowing what it was told at build time, it can now update its own model based on what happens during operation. That's a real shift — static knowledge base to something that revises itself while running. The last piece was a chief-complaints mechanism. Basically a structured way for Pancho to surface "here's what's actually wrong" rather than just failing silently or throwing an undifferentiated error. It's the difference between a system that breaks and a system that can tell you, in its own terms, what's breaking. Put together, these three pieces move Pancho from a static model toward something that reacts and adapts during its own operation — survives, learns, and reports on itself, instead of just executing a fixed script. Still early. The interesting failure modes probably haven't shown up yet — they usually don't until something's been running long enough to accumulate its own history. Curious what the first thing it "complains" about will actually be.