Wave Summary

Wave 8 proved that the deterministic refinery could safely own three production lanes. Wave 9 answered the harder operational question: could a project become a full Yesod citizen through one idempotent command, and could the fleet prove that every intended repository really had both a dispatch path and a merge path?

The answer at this checkpoint is yes. The reviewed fleet policy classifies 25 repositories as managed and eight catalog entries as explicitly excluded. All 25 managed projects have a unique note namespace, a canonical server-backed Beads identity, runner coverage, a deterministic repository lane, live controller ownership, and a terminal acceptance attempt. The fleet audit fails closed when a repository is missing from policy or any one of those boundaries drifts.

This wave also exposed three failures that a declaration-only audit would have missed. A Linux gate for sjbgtd followed a macOS-resolved machine-learning lock into multi-gigabyte CUDA packages and exhausted the Conductor’s 20 GiB root disk. Later, successful sentinel merges could update PostgreSQL while failing to close their linked root Beads because the controller lacked repository-local routing metadata. Finally, the bridge lane declared Ruff as its gate but did not install the repository’s locked development extra, so a fresh gate failed before lint began. These failures became versioned invariants, not operator folklore.

The final placement model remains intentionally strict:

  • pompom is an interactive client workstation, with no standing factory infrastructure;
  • seykhl is the Proxmox boundary and runs no Yesod application code directly;
  • the yesod-dispatch guest is the Conductor and owns standing dispatch, refinery, bridge, polling, and collection services;
  • dertog is the read/visualization box and cannot claim or merge work;
  • homestar stores durable content-addressed artifacts; and
  • AWS Lambda MicroVMs exist only for a remote gate lifecycle and its short, bounded idle-reap window.

The Starting Point Was Three Proven Lanes, Not a Fleet

The three-lane activation was real and healthy: yesod, scr-wrap, and yesod.work had all crossed their terminal boundaries. But an empty refinery dashboard only described those configured lanes. It said nothing about the other repositories already present in the catalog.

The immediate yesod.work defect made the distinction concrete. Notes had previously been created under ys-yes-*, the namespace owned by Yesod itself, instead of ys-ysw-*. Fixing the prefix was necessary, but a prefix alone did not provide a runner checkout, a Dolt workspace, a deterministic gate, a controller checkout, or a serialized merge lane.

Wave 9 therefore treated onboarding as a whole-system convergence problem. The unit of readiness was no longer “a tool exists in the catalog.” It was “a note can be created, claimed, implemented, gated against an exact candidate, merged, projected terminal, and traced back to the correct root Bead.”

Fleet Membership Became Reviewed Policy

config/onboarding-fleet.yaml is now the fail-closed inventory. Every catalog entry with repository metadata must have one reviewed disposition:

Disposition Count Meaning
managed 25 Yesod owns dispatch, runner provisioning, and a deterministic merge lane
excluded 8 the entry is deliberately outside factory ownership and carries a durable reason
unclassified 0 required for a green fleet audit

The managed set is:

alphatok-cost-opt, als, amplifier, aysp, chunkpdf, clip-together, csync, dadtool, engage-watch, hnalg, instasort, mvr, nbgen, ppg-pdf, scr-rename, scr-wrap, shup, sjbgtd, sjbis, submgk, substack-sjbg-bridge, thmb, ttrac, yesod, and yesod.work.

The excluded set is equally deliberate: canva, gascity, gastown, gogcli, hyperframes, local, media-tooling, and synapse. They are SaaS identities, local sentinels, upstream-owned repositories, or team-owned legacy workspaces. An exclusion does not mean “forgotten”; it means “Yesod is not authorized to own this repository’s merge lane.”

This closes a dangerous semantic hole. A repository newly added to the catalog does not quietly appear ready. Until policy, workspace, and lane declarations are reviewed, yesod onboard status --all reports drift and exits nonzero.

Onboarding Became One Idempotent Operation

The human-facing contract is small:

yesod onboard --github https://github.com/OWNER/REPOSITORY
yesod onboard REPO_STUB status
yesod onboard status --all --jobs 8

The mutating command converges canonical identity, note prefix, workspace manifest, coding-runner profile, deterministic merge profile, durable lane, all eligible runner hosts, Beads event schema, controller merge checkout, controller Beads route, and live controller ownership. Source manifests remain review authority: the command refuses to invent an unreviewed permissive gate.

The status command is read-only. Dispatch readiness now requires these nine pre-terminal invariants:

  1. catalog_identity;
  2. note_namespace;
  3. workspace_declaration;
  4. beads_workspace;
  5. dispatch_runner_coverage;
  6. controller_beads_workspace;
  7. runtime_lane_declaration;
  8. refinery_lane; and
  9. controller_lane_ownership.

terminal_acceptance is the tenth and final verification invariant. This distinction is useful: a new project can be structurally dispatch-ready before its bounded sentinel has proved the complete terminal boundary, but it is not reported verified until that proof exists.

Replaying onboarding is safe. Correct state reports unchanged; drift is either repaired from reviewed authority or refused with a bounded explanation. The command never uses a workstation-specific path as standing controller authority.

Coding Gates and Merge Gates Are Different Contracts

The coding runner and deterministic refinery serve different purposes. A runner profile answers whether an agent’s work is ready to hand off. The merge lane answers whether one exact candidate may reach a target branch. They may use different commands and they live under different authority.

Wave 9 removed legacy client repo_dir values from runner profiles and made host-portable workspace identity explicit. The server-side Dolt metadata._project_id is canonical; machine-local metadata is a cache and guard, not permission to create a new database identity.

The merge fleet deliberately uses two provider shapes:

Shape Lanes Reason
eight isolated AWS Lambda MicroVM shards 1 (yesod) the 6,000+ test suite benefits materially from fan-out and isolation
serial local Linux gate on yesod-dispatch 24 the project suites are small enough that MicroVM startup and per-repository key/IAM surface would cost more than it saves

“Local” here does not mean “on the operator’s laptop.” It means the gate runs under the restricted Conductor identity in an attempt-scoped worktree. Every repository and target branch remains serialized even though independent lanes can progress concurrently.

Twenty-Two Sentinels Tested the New Lanes

The three original lanes already had terminal evidence. Wave 9 created one bounded sentinel for each of the 22 newly managed lanes. Every sentinel branch contained an audited empty commit on that repository’s current main: no feature content, only a unique candidate that could exercise intake, gate, compare-and-swap push, note projection, queue cleanup, and root-Bead closure.

Nineteen passed on their first attempt. Three—sjbgtd, sjbis, and substack-sjbg-bridge—went red during one shared disk-pressure incident. The red evidence was preserved. No result was relabeled green, and no branch was merged around the refinery.

After disk recovery, sjbgtd passed under its versioned Linux profile and sjbis passed from an audited empty retry commit. A fresh bridge retry then exposed a separate profile error: the v1 command invoked Ruff without installing the dev extra that contained it. Profile v2 repaired that exact contract and the preserved sentinel subsequently completed terminal.

This was precisely why the sentinel sweep existed. A manifest comparison would have declared the fleet ready without ever exercising dependency resolution, disk consumption, the provider boundary, or terminal write-back.

A macOS Lock Was Not a Safe Linux Gate

The sjbgtd gate initially synchronized the repository’s full project lock on Linux. That lock includes sentence-transformers; on the Conductor it selected CUDA-enabled PyTorch and NVIDIA wheels even though the deterministic offline tests never exercise the real embedding model. Alongside a Rust target tree from sjbis, the download exhausted the 20 GiB root disk. The bridge lane then failed collaterally.

Recovery was bounded and evidence-preserving:

  • exact failed worker PIDs were proven and stopped;
  • only terminal attempt worktrees and the known failed Cargo target were removed;
  • the UV cache was pruned, reclaiming about 2.1 GiB;
  • no gate log, PostgreSQL attempt, or Blob artifact was deleted; and
  • retries waited until no active attempt owned those paths.

The reviewed sjbgtd profile became pytest:sjbgtd-linux-offline-v2. It uses a lock-independent Python 3.14 environment containing only the lightweight runtime dependencies needed by the deterministic suite. It runs 371 offline tests and explicitly leaves three environment boundaries outside the merge gate: the stale Supabase client contract, the live self-hosted stack, and the cached Hugging Face model smoke.

This is not a permissive quarantine. The exact excluded files and the reason for each are versioned. A regression test forbids the merge profile from silently returning to the project lock or a CUDA dependency graph.

A Declared Linter Is Not an Installed Linter

substack-sjbg-bridge already locked Ruff in its optional dev extra, but the v1 merge command ran uv run ruff against only production dependencies. The provider correctly returned red with ruff: No such file or directory; this was a profile defect, not a project regression.

The reviewed profile became lint:substack-sjbg-bridge-critical-v2 and now runs both commands with uv run --locked --extra dev. The exact corrected command passed against the preserved failed candidate before the source change entered the normal Yesod MicroVM gate. That source gate reported 6,322 passed, 28 skipped, and zero failed across eight distinct guests. After release promotion, the unchanged bridge candidate received a new immutable provider identity through the versioned profile, passed, reached main, cleared its queue row, and automatically closed root Bead ssb-9l5.

Terminal Projection Needed Its Own Controller Workspace

The first 19 green sentinels found a second boundary. PostgreSQL notes became terminal and branches reached main, but controller logs showed that several linked root Beads remained open. The controller had clean merge checkouts under /var/lib/yesod/repos, while the Beads router correctly looked for host-portable workspaces under the service home. Only the original three lanes had those routing workspaces.

The fix preserves the separation instead of cloning every repository twice. For each managed project, onboarding creates a lightweight workspace at:

/var/lib/yesod/dev5/<repo-dirname>/.beads

It contains reviewed server metadata, config, and the Dolt port—no second source checkout and no .env password. The protected service-level dolt.toml retains credentials. The canonical project ID is resolved from the Dolt database, existing database or project-ID conflicts fail closed, files are owned by yesod-control with restrictive modes, and the command proves yesod beads info TOOL --json under the controller’s actual environment.

controller_beads_workspace is now a dispatch-readiness invariant. This makes the terminal write-back route part of every future onboarding, and the final sentinel proves not only a green gate and merge but the root-Bead closure that operators actually depend on.

The 19 notes that had already completed before this route existed were reconciled individually only after their terminal attempts and missing root closures were verified. The final three recovered sentinels—sjbgtd, sjbis, and the bridge—then closed their roots automatically through the new route.

Placement Did Not Drift During Expansion

Universal project intake did not turn the workstations or hypervisor into a server room.

pompom

The client keeps the global CLI, source checkouts, interactive credentials, and user-started Codex/OpenCode/SSH processes. It runs no standing controller, runner daemon, refinery supervisor, gate poller, bridge, status publisher, OpenCode server, or Yesod web service. Preserved launch-agent plists remain disabled rollback material, not active infrastructure. The bare yesod command resolves through ~/.local/bin/yesod to the stable ~/yesod-services-clone venv at canonical main; it is not a frozen package snapshot and does not execute from Stephen’s mutable development checkout.

seykhl

The Mac Studio is the Proxmox node. It owns VM 112’s compute and disk boundary, but no /srv/yesod, /var/lib/yesod, application credential, or Yesod service belongs on the hypervisor. The applications live inside the guest.

yesod-dispatch

The Conductor guest owns the deterministic controller, an operator-only codefactory daemon, loopback MicroVM proxy, fleet poller, collectors/timers, service-health publisher, human-authority bridges, immutable releases, 25 clean merge checkouts, and 25 lightweight Beads routing workspaces. The codefactory daemon is alive for management and maintenance but has operator: true, so it never claims coding work; the three Linux coding runners remain the worker tier. Global refinery-lane capacity is two. The controller is mechanical; it does not host an LLM decision loop.

dertog, homestar, and MicroVMs

dertog serves the public dashboard and read APIs. It can display PostgreSQL and fleet projections but has no merge capability. homestar exposes the NFS artifact store and interprets no factory state. MicroVMs receive one exact gate candidate and disposable credentials, then disappear; they retain neither authority nor durable evidence.

Interim Disk Headroom Without a Placement Change

The sentinel sweep made the Conductor’s 20 GiB root-disk limit operationally visible: one clean Rust build took the guest to 90% utilization even after bounded cache cleanup. At a quiescent boundary, VM 112’s thin-provisioned disk was expanded online on seykhl from 20 GiB to 64 GiB; partition 1 and ext4 were grown in place without rebooting or moving a service. The final snapshot showed roughly 45 GiB free.

This is explicitly interim headroom while a much beefier host is forthcoming. It does not authorize Yesod code on the Proxmox host and does not collapse the Conductor, builder, or sandbox roles. The release was staged as a shallow exact canonical commit from the trusted workstation because the interactive guest account intentionally has no GitHub deploy key; no new standing credential was added to yesod-dispatch.

The Operational Commands Are Boring on Purpose

For a new Yesod-owned repository:

yesod onboard --github https://github.com/stephenVertex/NEW-REPO
yesod onboard NEW-REPO status --json

For the whole reviewed fleet:

yesod onboard status --all --jobs 8 --json

The fleet is not universally ready unless that last command reports:

managed=25
dispatch_ready=25
verified=25
excluded=8
unclassified=0
fleet_ready=true

The public operator surface remains:

https://dertog.tailb4b58.ts.net/yesod/viz/refineries.html

Its queue describes the configured fleet, not the catalog in the abstract. Question-mark help defines the operational fields, and MicroVM fleet state is reported separately from lane state so “one active lane” is never mistaken for “one running guest.”

What Is Live

  • Canonical GitHub main and /srv/yesod/current: 958326e7fe42eb852a95983f86a696fc81e10f1e.
  • Active scheduler: global-refinery-v2, controller version refinery-controller-v1, PID 576980, 25 configured lanes, global capacity two. The operator-only codefactory daemon is PID 608904 from the same release.
  • Admissions: active at revision 90, with a fresh heartbeat and zero tick errors.
  • Managed fleet: 25 dispatch-ready and 25 terminal-verified.
  • Exclusions: eight reviewed, zero unclassified repositories.
  • Client CLI: bare yesod resolves from ~/yesod-services-clone at 958326e7; the fleet-wide onboard --all --jobs surface is available.
  • Providers: one eight-shard MicroVM lane and 24 serial local Conductor lanes.
  • Final source gate: eight distinct MicroVMs, 6,322 passed, 28 skipped, zero failed; the final idle snapshot reports zero running MicroVMs and a healthy idle proxy.
  • Queue and work: merge queue empty, no active refinery attempts, and no running dispatches at the final verification snapshot.
  • Dispatcher health: yesod-dispatch is a fresh operator runner with zero claims. Its operational probe is anchored to the lightweight yesod Beads route; the inherited workstation-era clip-together probe was removed because that source checkout intentionally does not exist on the Conductor.
  • VM 112 root disk: 64 GiB provisioned, about 45 GiB free after online growth.
  • Public dashboard: HTTP 200 from dertog.

The Exit Criterion

Wave 9 is complete only when “you can file a task for any managed Yesod project” has one unambiguous meaning:

  1. the note is created in that project’s unique namespace;
  2. an eligible runner can claim it against the canonical Dolt workspace;
  3. the worker’s branch enters the correct repository/target lane;
  4. the reviewed deterministic gate runs on the intended provider;
  5. only the exact green candidate may reach main;
  6. PostgreSQL, the queue, and the lane record the terminal result; and
  7. the linked root Bead closes through the controller’s own routing workspace.

The fleet audit and sentinel ledger now test that statement rather than asking an operator to remember it. Future repositories still need a reviewed policy entry and gate; “universal” means every intended managed project follows one repeatable onboarding contract, not that Yesod silently assumes ownership of every URL in the catalog.