Wave Summary

Field Value
purpose complete bounded hardening, retire optional self-work, and pivot to external delivery
development window July 13, 15:21 to July 14, 17:15 PDT—25 hours 54 minutes
baseline 557c6b28
final commit b838cd56
Git commits landed 100 on main across the wave range
recorded refinery merges 36 merge summaries
contributors 5 author identities
change surface 80 files, 9,936 insertions, 523 deletions
final gates 2 full exit gates green; zero failures
exit state 4 current runners; queue and gap 0; health 24/24; provisioning 108/108; 0 nonterminal Yesod notes

The commit and merge counts measure different things. The commit count is the Git ancestry introduced between the baseline and final commit; one refinery merge can carry several commits. The merge count comes from Yesod’s durable merge_summaries ledger and represents recorded integration events.

Every self-hosting system faces a dangerous moment. The machinery becomes interesting enough that improving the machinery feels like progress even when it delays the work the machinery was built to produce.

Yesod reached that moment in July 2026. The factory could plan, dispatch, isolate, gate, merge, deploy, and record its own changes. It also had a long tail of plausible improvements. The answer was not another open-ended hardening program. It was a locked exit wave: finish the agreed safety and operability batch, retire or consolidate the rest, and change the success metric from “Yesod improved Yesod” to “Yesod delivered another tool.”

This first wave entry exists because the interesting result was not one feature. It was the point at which a collection of mechanisms became credible as a production path for external projects.

The Cutoff Was a Feature

The wave began by drawing a boundary around the work. Existing bug reports and feature requests were classified into four groups:

  1. changes required for safe throughput;
  2. already-shipped or stale records that needed truthful closure;
  3. broader reliability ideas to preserve as roadmap knowledge;
  4. optional surfaces to retire explicitly rather than leave ambiguously open.

The distinction matters. An autonomous factory with an unlimited mandate to improve itself never finishes. A factory with a durable cutoff can distinguish a blocker from an attractive idea. During this wave, only faults that blocked the exit batch—or tiny observability changes needed to understand that batch—were allowed to expand the plan.

That governance became executable, not merely conversational. Yesod gained an orthogonal disposition axis—active, held, blocked, needs-rework, quarantined, or deferred—separate from lifecycle status. A task could remain awaiting_merge without being eligible to gate. Releasing a previously held task became an explicit audited action. This prevented the familiar failure in which a dashboard said “waiting” while a hidden policy said “never run.”

What Shipped

The following table groups the most important outcomes. Note identifiers are included because the catalog is the durable narrative; commits are included because the repository is the executable evidence.

Area Result Evidence
batch safety conflicted and cross-tool branches fail closed and cannot contaminate a shared gate tree ys-yes-gpgf, ab4384af
queue governance held work stays out of play; retry caps, dependency state, and needs-rework are durable rather than sentinel conventions ys-yes-d9yc, 283d3e71
external proof a real clip-together change traversed the automated merge lane successfully ys-cli-eij7, 489f9f0f
persistent evidence blob storage received guarded, persistent mount configuration rather than relying on a process-local filesystem ys-yes-e3ab, f34d45cf
gate cleanup proxy shutdown and failure paths terminate tracked instances and sweep orphans instead of leaking cloud capacity ys-yes-ph61, 947bfec0
tailnet enrollment gate guests join Tailscale during readiness using an ephemeral key fetched from Secrets Manager, with no key baked into the image ys-yes-bwoz, ec68fe5d
least privilege the gate can reach the telemetry collector without receiving general tailnet authority; the image includes an explicit security probe ys-yes-bwoz, ec68fe5d
live telemetry structured gate progress reaches the collector, and the Refineries view shows warming, running, progress, failure, and terminal green state ys-yes-x8yf, ab56e8b8
managed Beads truth yesod bd … backend uses the same resolved Dolt host, user, password, port, and TLS policy as routed execution without printing the password ys-yes-6ew3, 075df362
cold-start reliability /ready treats HTTP 503 as “still baking” for a bounded 180-second window while other HTTP and transport failures remain fail-fast ys-yes-bv5g, b838cd56

Several of these changes are small in diff size and large in operational effect. Passing executionRoleArn through the proxy fixed a cloud launch path that appeared idle from the control plane. Selecting the newest image by creation time prevented a lexicographic version mistake. Configuring Git identity inside the gate turned a baffling merge failure into an ordinary, testable precondition. Preserving terminal status after shutdown let an operator distinguish “nothing happened” from “the gate finished and the capacity was released.”

A MicroVM Became a Managed Gate

Before the wave, the remote gate was best understood as a powerful execution endpoint with several dangerous edge cases. After the wave, it behaved more like a managed subsystem.

The host-side client can reach only a loopback pool proxy, not an arbitrary cloud runtime URL. The proxy owns launch serialization, one tracked instance, idle shutdown, explicit shutdown, failed-launch cleanup, and orphan sweeping. The guest receives runtime configuration at /ready, fetches short-lived credentials, joins the tailnet in userspace, initializes its repository and database, and reports structured progress. The collector receives evidence; the guest does not receive broad control-plane authority.

The final cold-start defect is a good example of why all these layers matter. A cold guest legitimately returned 503 while building its environment. The worker interpreted two immediate 503 responses as two failed gates even though no tests had run. The fix did not raise every retry count or make all errors slower. It introduced typed HTTP status on the gate error and retried only the expected readiness response, every five seconds, within a 180-second budget. Transport errors and HTTP 500 still fail immediately. Whole-gate attempts remain capped.

That is the desired pattern: identify the state that is actually transitional, give it a bounded budget, and keep every other failure sharp.

Evidence at the Exit

The wave closed with live evidence, not a declaration of confidence.

  • Thirty-six changes entered recorded merge summaries between the start of the locked evening batch and the final merge.
  • The managed-Dolt diagnostic reported managed:doltsvr:3306, reachable, on Dolt 2.1.10; the exact JSON acceptance probe exited successfully.
  • The final backend-diagnostic gate collected 4,636 tests, completed 4,614, skipped 22, reported zero failures, and returned green.
  • The final cold-readiness gate collected 4,639 tests, completed 4,617, skipped 22, reported zero failures, and returned green.
  • A post-merge live canary deliberately removed the warm instance, launched a fresh MicroVM, and reached /ready in 68.5 seconds through the deployed client. The canary then shut the instance down.
  • Four dispatch runners were active with no claimed work. The refinery was active with an empty queue, a free merge lock, and a zero queue gap.
  • PostgreSQL, every registered Dolt workspace, and the full 108-cell fleet-provisioning matrix reported healthy.
  • The operator checkout, editable runtime checkout, AME checkout, and all four dispatch runner runtimes resolved to b838cd56 after rollout; host-local runner configuration and backups were preserved across the fast-forward.

At the code exit, one old note remained in awaiting_verification: ys-yes-5mhm, a mail-broker remap experiment explicitly excluded from the locked final scope. Final disposition cleanup marked it wontfix and closed its Bead without merging. Its tested branch remains preserved at 6adc3e95 so future external-project evidence can justify a deliberate refile rather than silently resurrecting old self-work.

Ready Does Not Mean Configuration-Free

The factory is ready to work on an external project, but an external repository still needs a contract. Yesod must know where the repository and Beads workspace live, which lanes may execute it, which branch namespace the factory owns, what command constitutes a green gate, and whether a merge triggers a deployment. Secrets must be available on the hosts that need them without being copied into prompts or images.

The readiness claim is therefore specific. clip-together has recent end-to-end proof through dispatch, gate, refinery, and main. Several other owned tools already have complete refinery profiles. An arbitrary catalog tool is not automatically merge-ready: some have no profile or dedicated refinery checkout, and Git write authority is repository-specific. Before the first task, both a runner and the refinery host should prove remote access with ls-remote and a non-mutating push dry run. The foreign-tool guards fail closed against merging in the wrong repository, but missing configuration can still strand otherwise valid work.

The first task on a new project should therefore be a canary: small, reversible, representative of the real test toolchain, and valuable enough to merge. It should prove the complete path—note, Bead, role priming, branch, targeted test, remote push, refinery profile, gate, merge, and post-merge observation—before parallelism is increased.

This is not hesitation. It is how a factory converts a new project from an assumption into a known production line.

The New Metric

The exit criterion changes what Yesod should optimize.

Future maintenance is justified when external work exposes a concrete fault, when operating evidence shows a safety boundary is weak, or when a small change materially increases throughput across projects. It is not justified merely because Yesod can imagine another abstraction for itself.

The factory’s next meaningful chart is therefore not the number of Yesod notes closed. It is external lead time: how quickly a well-formed request becomes a tested, merged, observable change in another tool—and how often that happens without extraordinary operator intervention.