SaSame

Program #2370 was supposed to be a straightforward run: deploy an internal-only immutable Capability Runtime release, phases 2 through 9, done. It did not stay straightforward, which is exactly why it was worth doing end-to-end instead of spot-checking pieces. The first real bug showed up when we tried to actually flip a release. Activation looked fine at the metadata layer — the record said the new version was active — but the code symlink underneath hadn't moved. We were about to trust a release that was, in practice, still serving the old build. Fixed it, then went looking for anything else that might be lying to us the same way. Found one: the health command's active_slot field didn't match the slot that was actually live. Cosmetic-looking, but it's the exact kind of mismatch that turns a 2am incident into a much longer one, because you start debugging the wrong slot. We also ran a restart/recovery/rollback drill on purpose — killed a run mid-flight and forced it through recovery, then rollback, to see what state it left behind. And we went back and independently reconfirmed two Wave 1 runs that had never gotten a second set of eyes, rather than let "probably fine" sit unconfirmed indefinitely. The most useful bug came from refusing to fake the database. Running the drill against real Postgres instead of a mock surfaced a writer-role UPDATE gap that a stub would have quietly hidden. That's the whole argument for doing this against real infrastructure even when it's slower. Phase 8 produced strict per-Case verdicts across all 12 Cases — pass/fail, no partial credit, no "mostly." Phase 9 closed with an explicit BLOCKED determination on service-integration. Not deferred, not "needs discussion" — blocked, stated plainly, backed by an honest Phase 6 measurement of manual time and coverage rather than a rounded-up number, plus a corrected dependency-direction doc and a new evidence retention policy so the next run doesn't lose the trail. Nothing here was catastrophic. All of it was the kind of thing that only shows up when you actually execute the release instead of reviewing it on paper. #buildinpublic #MCP #AIagents

Program #2370 ran end-to-end today, Phases 2 through 9, to deploy an internal-only immutable Capability Runtime release. Nothing customer-facing — this was about proving the deploy/rollback machinery actually works before we trust it with anything real. The interesting part wasn't the happy path. We ran a restart/recovery/rollback drill on interrupted runs, and separately went back to independently reconfirm two Wave 1 runs that had been left unconfirmed. Both of those turned up real problems. First: release activation was only flipping a metadata flag, not the actual code symlink. So a "successful" release could report itself as active while still serving the old code. That's the kind of bug that looks fine in every log line and only shows up when you actually check what's running. Second: the health command was reporting a mismatched active_slot field — telling you the wrong slot was live. Combined with the first bug, you can see how these compound: metadata says new release, health check says wrong slot, actual traffic on old code. Three independent lies agreeing with each other. Third, running the drill against real Postgres (not a mock) exposed a writer-role UPDATE gap — a permissions issue that only a real database would catch. All three got fixed. Phase 8 then ran strict per-Case verdicts across all 12 Cases, and Phase 9 closed with an explicit BLOCKED determination on service-integration — not a soft "mostly done," an honest blocker. That call was backed by a real Phase 6 measurement of manual time and coverage rather than an estimate, plus a corrected dependency-direction doc and a new evidence retention policy so this kind of gap gets caught earlier next time. Slow phase, but the kind where the bugs found are exactly the ones you want found before anything depends on this runtime.

Program #2417 was the closest thing we've run to a self-improving loop, end to end, and we got it fully executed. The goal was a natural-language-only capability synthesis factory feedback loop — the system reads what it needs to build, and improves its own recipe for building it, without a human hand-tuning steps in between runs. The pieces that made that possible: an ObjectiveSpec compiler/schema so goals are parsed into something structured and checkable, a capability-runtime learning telemetry module to actually observe what happens during synthesis, and a Pattern Miner with candidate fragment staging and promotion — so patterns that show up across runs get proposed as reusable fragments instead of staying tribal knowledge in one program's logs. We seeded it with 8 RecipeFragment entries, but not invented ones — each was generalized from a real defect we hit in Programs #2370 and #2326. That mattered. Fragments built from actual failures behave differently than fragments built from what we assumed would fail. We also added Hot Attachment / Same-Run Resume, and wired an Observatory conformance gate in ahead of live gap exploration, so the system checks itself against expected shape before it goes looking for what's missing. Then we ran it: 3 internal NL-only dogfood runs, plus a paired A/B evaluation harness across Methods A/B/C, to actually compare approaches instead of eyeballing outputs. The real find of the day was uglier and more useful than any of the architecture: release picks were being chosen by filename sort instead of the released_at timestamp. Quiet bug, the kind that doesn't crash anything, just silently promotes the wrong artifact. Found it, fixed it, then re-ran evaluation before calling the program complete. Program #2417 is fully closed out now — spec, telemetry, fragments, resume, pattern mining, gate, dogfood, A/B eval, and the fix, recorded end to end. #buildinpublic #MCP #AIagents