The Conductor and the Deterministic Refinery

Wave Summary

Field	Value
purpose	replace the split-brain, host-coupled autonomous merge engine with a durable deterministic refinery; move standing control-plane infrastructure off the operator workstation and onto a dedicated Conductor VM
development window	August 7–9, 2026—from the redesign document through Conductor migration, three-lane proof, idempotent repository onboarding, and the self-explaining live refinery surface
triggering incidents	the “5385” page showed a completed green gate as a one-hour zero-pass run; sharded-suite state pollution mislabeled innocent branches; launchd KeepAlive made process-level pauses unsafe; control-plane services were still anchored to pompom
source baseline	40a9622c before the redesign branch; activation began at 94e80a7b, the Conductor migration merged at d434f0aa, host portability reached 86b3dc46, and the final reviewed/deployed release is 4f5a183b
core redesign	refinery-reliability-ys-yes-x802, 25 commits through 3db9126b; merged by the normal eight-shard gate at 77d114f5
redesign change surface	69 files, 28,790 insertions, 1,959 deletions; 24 implementation Beads closed under yes-0f10 / ys-yes-x802
activation hardening	secure capability token, PID-reuse fencing, observable provider cancellation, serial-in-shard MicroVM execution, provider-start evidence repair, and schema-init deadlock fixes through the 94e80a7b candidate
Conductor migration	refinery-conductor-qii1, 17 commits through 6597a7f5; merged by the deterministic refinery at d434f0aa; tracked by yes-1358 / ys-yes-qii1
live topology	pompom is an operator client; seykhl is only the Proxmox hypervisor; VM 112 yesod-dispatch runs the standing control plane; dertog serves visualization/read surfaces; homestar stores immutable artifacts; AWS MicroVMs run the Yesod gate
production scope	three configured lanes: yesod through eight MicroVM shards with one pytest worker per shard; scr-wrap through one local serial gate; and yesod.work through the exact local npm ci, npm run check, npm run build profile; other projects remain explicitly outside active intake until reviewed
evidence	277 targeted refinery acceptance tests; independent reviewer rechecks; repeated eight-MicroVM gates with zero failures or infrastructure errors; 53 focused fleet/API/browser/migration tests plus an eight-test tripwire follow-up; 59 focused onboarding/source/runtime tests plus two installed-CLI no-op replays; controller and supporting units active with zero restarts; public dashboard HTTP 200 and visually checked; Blob mount verified byte-for-byte; all nine yesod.work onboarding checks green; and sentinel ys-ysw-6kot reaching main, deleting its queue row, and closing ysw-p9l automatically
checkpoint type	final operational and source-code exit for the deterministic-refinery/Conductor migration; the factory is active on three reviewed lanes with the legacy supervisor absent
exit status	achieved: the migration is promoted, heartbeat/artifact/fleet visibility are live, the operator inbox is empty, host placement is explicit, a real third-lane terminal write-back completed, and new repositories now have one idempotent command plus a nine-invariant readiness check

Wave 7 asked whether the factory could tell a coherent story. Wave 8 began when the refinery told a story that was coherent, current-looking, and false.

The Refineries page showed a MicroVM whose identifier ended in 5385 as roughly one hour old with zero passing tests. The actual remote job had already finished green: 5,845 passed, 26 skipped, zero failed, in 243.3 seconds. The page had joined fresh VM uptime, a stale pending gate row, and an idle merge pipeline as though they described one live execution.

That incident was not a display typo. It exposed a refinery whose lifecycle authority was distributed across queue labels, process memory, worker rows, merge locks, gate files, provider jobs, fleet snapshots, and several APIs. An LLM supervisor could react to symptoms, but it could not supply fencing, exactly-once effects, or a single answer to “what attempt owns this gate?”

Wave 8 replaced that arrangement and then moved the replacement onto the host where standing infrastructure belongs.

The Run Began With a Real Pause

The first operational decision was to stop the old refinery without damaging the work already in flight. The supervisor was unloaded from launchd, not merely killed or kickstarted. That distinction mattered because KeepAlive can relaunch a killed process, while an unloaded job is absent from the service manager and cannot fight the operator’s pause.

The pause was taken after the active gate completed. The merge lock was free, no runner was building, and the one queue row labeled gating was proven to be stale state with no live gate behind it. This established the boundary for the redesign: no mid-merge interruption, no orphaned lock, and no new work entering while the source of truth changed.

The flake evidence also narrowed the problem. Several innocent notes had been escalated to rework because different full-suite runs failed different test modules, while the same subsets passed locally and under isolated -n auto runs. The failure was cross-worker xdist state pollution, not seven unrelated product regressions. The new production Yesod profile therefore preserves parallelism across machines while running one pytest worker inside each MicroVM.

An Attempt Became the Unit of Truth

The redesign’s primary object is no longer a queue row or a supervisor cycle. It is one immutable merge attempt in one repository/target lane.

PostgreSQL now holds first-class records for:

• project lanes and their current attempt;
• immutable attempts, candidate SHAs, leases, fencing generations, and terminal outcomes;
• concrete local or MicroVM gate executions;
• append-only attempt events and external-effect evidence;
• bounded artifact metadata pointing into Yesod Blob; and
• an operator inbox for facts the controller cannot safely infer.

The normal lifecycle is monotonic:

requested → claimed → preparing → gating → gate_green → pushing
          → deploying → succeeded

Retries create successor attempts; they do not reopen terminal records. A worker must present the current owner and fencing token for every mutation. If its lease expires and another controller acquires a higher token, the old process can no longer record progress, terminal evidence, or artifacts.

A lane is repository identity plus target branch. One attempt may push within that lane, while unrelated lanes may prepare and gate concurrently. The global merge loop has become a bounded scheduler over independently serialized lanes.

External Effects Became Reconciled Facts

Git pushes and provider submissions are not database transactions. A process can receive success, lose the response, and die before recording it. Treating that as a normal retry risks a duplicate gate or a repeated push.

The new brokers therefore separate intent, observation, and completion:

1. persist an idempotent external-effect intent;
2. perform the provider or Git operation outside the database transaction;
3. observe the real external state;
4. record confirmed-applied, confirmed-not-applied, or outcome-unknown; and
5. reconcile unknown outcomes by stable identity instead of repeating them blindly.

Local and MicroVM gates implement the same provider contract: submit, find by idempotency key, observe, cancel, and fetch immutable artifacts. A lost submit response can be recovered from the deterministic provider job identifier. A green gate authorizes only the exact candidate SHA it tested; if the target branch moves first, the controller must construct and gate a new candidate.

Review Found Two Missing Invariants

The first implementation passed its focused broker, scheduler, runtime, and UI suite, but review exercised two cases the tests had not actually proved.

First, a provider that still reported running one second past the configured deadline left the gate pending=true forever. The earlier test covered only a provider job missing at deadline. The fix preserves the final running observation, requests cancellation when supported, observes the cancellation outcome, and then settles the execution under the bounded lost policy. A remote provider cannot extend the controller’s reconciliation deadline merely by continuing to say “running.”

Second, gate idempotency was global over candidate SHA and profile. Two different project lanes with the same SHA/profile could collide, causing the second lane to reuse or reject the first lane’s execution. The identity now includes repository/target lane identity, so equal candidates in independent projects produce independent gates and provider jobs.

Those fixes landed as c58994e4 and a91dfa86; 3db9126b recorded them in the acceptance matrix. The final targeted acceptance run reported 277 passing tests.

Activation Required More Than Green Tests

The reviewer approved merge but withheld activation until three operational boundaries were hardened.

Boundary	Hardening
active capability	the token must be a regular mode-0600 file, owned by the service identity, with one hard link and exact reviewed contents
local process ownership	the controller records and checks process identity rather than trusting a reusable PID after a crash
overdue provider work	cancellation is an explicit external effect whose observed outcome is retained; “marked lost” is not treated as equivalent to “provider stopped”

The activation branch also changed the Yesod MicroVM profile from nested xdist to eight machines with -n 1 inside each guest. Parallelism remains eight-wide at the infrastructure level, where each shard has isolated process and database state. The old shared-process pollution channel disappears.

Later sentinel work corrected two more activation findings. Provider binding had written receipt acceptance time into started_at, conflicting milliseconds later with the provider’s real start time. Schema initialization could also deadlock when legacy intake and a newer process raced through migrations. Both were repaired before the reviewed 94e80a7b controller candidate was activated.

The Gate Is Remote; the Controller Is Not the Test Host

“Deterministic refinery” describes control semantics, not local execution. The standing controller runs on yesod-dispatch, but the Yesod gate runs on eight disposable AWS Lambda MicroVMs. Each guest receives the exact candidate, runs one serial pytest worker against its isolated in-image PostgreSQL, and reports a provider observation. The controller aggregates those observations into one durable gate execution.

This is the performance and reliability compromise the flake evidence called for:

• parallel across eight isolated machines;
• serial inside each machine;
• no workstation CPU contention;
• no cross-worker process state;
• no silent local fallback when the remote provider is unavailable; and
• a durable deadline and cancellation path when a remote job does not settle.

The scr-wrap lane remains a one-shard local serial gate because its reviewed profile is small. Local is a provider choice per lane, not a global fallback for Yesod.

The Workstation Stopped Being the Server Room

The initial activation still left a structural contradiction: the new controller and its support jobs were launch agents on pompom. The Mac Studio is a client workstation. Login state, GUI sessions, battery/workstation maintenance, and user experiments should not decide whether the software factory can merge.

The Conductor migration, tracked by ys-yes-qii1 / yes-1358, established a dedicated placement model:

Place	Authority and responsibility
pompom	interactive operator client: source checkouts, the Yesod CLI, interactive credentials, and preserved-but-disabled rollback plists; no standing Yesod, sjbis-gog, refinery, or OpenCode service
seykhl	Proxmox hypervisor only; owns VM 112 configuration and storage, but runs no Yesod application process directly
yesod-dispatch	VM 112, the Conductor; owns deterministic refinery control, gate proxying, fleet telemetry, factory dispatch, maintenance timers, status reporting, and human/question bridges
dertog	visualization and read surface: Yesod HTTP/API, live-viz WebSocket, public Refineries page, and the human-facing sjbis daemon; it does not claim or merge work
homestar	Synology NFS artifact store at /volume1/yesod-blobs, mounted by the Conductor at /mnt/nas/yesod-blobs
AWS Lambda MicroVMs	disposable gate workers; no durable authority survives an instance

On pompom, sixteen com.yesod.*, com.sjbis.gog, and ai.opencode.server launch-agent plists remain available for deliberate rollback, but every label is unloaded and persistently disabled. The stale sjbis bridge PID file was removed only after its PID was proven absent. A login or reboot can no longer resurrect the old refinery through KeepAlive.

On seykhl, VM 112 is configured with two cores, 4 GiB RAM, a 20 GiB local-lvm disk, onboot=1, and startup order 20. The application boundary is the guest: /etc/pve/nodes/seykhl/qemu-server/112.conf describes the VM; it is not a Yesod deployment directory.

The Conductor Has an Explicit Filesystem Contract

Inside yesod-dispatch, immutable code and mutable authority are separated:

Path	Purpose
/srv/yesod/releases/<commit>	immutable source plus locked environment for one reviewed commit
/srv/yesod/current	controller/proxy/dispatcher release; final reviewed release 4f5a183b
/srv/yesod/ops-current	independently pinned auxiliary-service release; live at 233e00b8 for this checkpoint
/var/lib/yesod	mutable repositories, controller workspaces, caches, evidence, gogcli state, SSH/AWS identity, and the yesod-control home
/var/lib/yesod/repos/yesod-aicoe	canonical checkout for the Yesod lane
/var/lib/yesod/repos/scr-wrap	canonical checkout for the scr-wrap lane
/var/lib/yesod/repos/yesod.work	canonical checkout for the yesod.work lane
/var/lib/yesod/dev5/{yesod-aicoe,scr-wrap,yesod.work}	manifested Beads mutation workspaces with canonical project identities
/var/yesod-workdir	recoverable dispatcher worktrees and run transcripts
/etc/yesod	root-controlled manifests, secrets, and explicit service-enable capabilities
/opt/yesod	pinned Node 22.23.2 and bd 1.1.0 host runtimes
/usr/local/bin	managed bd symlink plus reviewed static sjbis, gog, and sjbis-gog executables
/usr/local/libexec/yesod	host-level fleet telemetry helper
/mnt/nas/yesod-blobs	persistent content-addressed evidence mounted from homestar

The non-login yesod-control account runs the controller and most supporting services. The codefactory dispatcher deliberately remains under the existing stephen runner identity because its model credentials and worktree ownership were already scoped there. Secrets were copied only into root- or service-owned mode-0600 files; no credential entered Git.

Two release symlinks prevent an operational hardening branch from becoming an unreviewed merge controller. ops-current can stage an exact auxiliary commit needed for cutover, while current remains pinned to reviewed main until a promotion decision.

Standing Services Moved as a Set

The migration moved more than the controller. The active systemd set on yesod-dispatch is:

• yesod-refinery-controller.service;
• yesod-gate-pool-proxy-8100.service;
• yesod-gate-fleet-poller.service;
• yesod-codefactory-dispatch.service;
• yesod-beads-collect.timer;
• yesod-archive-sweep.timer;
• yesod-status-push.timer;
• yesod-bridge-sjbis.timer;
• yesod-sjbis-gog.service; and
• mnt-nas-yesod\x2dblobs.mount.

The units use systemd sandboxing, explicit enable files, immutable entry points, and bounded writable paths. The controller additionally requires the separate active capability; installing or enabling its unit alone does not grant merge authority. The legacy supervisor unit is absent.

The Beads collector was changed to read server-backed readiness directly from SQL. Later terminal-projection acceptance added separate, manifested repository-local .beads control workspaces under /var/lib/yesod/dev5; those exist for mutation identity, while claimability collection intentionally remains PostgreSQL-authoritative. Label collection was reduced to bounded server-native queries. Auxiliary one-shots were pointed at ops-current, while the long-lived merge processes remain on current.

Status reporting now probes Linux systemd state rather than workstation PID files. Its snapshots identify yesod-dispatch, allowing the old pompom status rows and readiness-stale warnings to be retired instead of blended into one fictitious host.

Human Communication Became Standing Infrastructure Too

Two easily confused bridges now have explicit ownership:

• yesod-bridge-sjbis.timer is the Yesod human-authority mail bridge. It consumes the human channel and asks the sjbis daemon on dertog.
• yesod-sjbis-gog.service polls Gmail and Google Chat, classifies genuine questions, submits them through sjbis, and routes approved answers back.

The Conductor runs static, checksummed Linux builds of sjbis and sjbis-gog, plus official gogcli 0.34.1. Minimal OAuth/keyring material lives under /var/lib/yesod/.config/gogcli; the Fireworks key, keyring settings, and explicit gog account selector live in /etc/yesod/sjbis-gog.env. Gmail and Chat read-only preflight passed as yesod-control before the Mac singleton was stopped.

No standing OpenCode server was moved to the Conductor. Durable Yesod mail is PostgreSQL-backed and host-independent, but OpenCode wakeups and live session transport remain runtime-local. Centralizing one OpenCode server would only move the coupling. The host-neutral wakeup/adaptor problem remains documented in ys-yes-53ok.

One separate sjbis privacy issue also remains: message details are passed to a child sjbis ask process in its argument vector, making them locally visible to process inspection. That bug is tracked as ys-sjb-bhgx; it does not change refinery correctness, but it is part of the security boundary this wave made visible.

Cutover State Was Reconciled, Not Waved Away

The activation audit found fifteen awaiting_merge notes outside active v2 intake.

• One Yesod branch was already an ancestor of main. Its exact commit was backfilled and its note completed.
• Seven verified Yesod branches had their metadata repaired, known pre-cutover flaky counters cleared where appropriate, temporary holds removed, and deterministic v2 attempts created.
• Seven branches for other projects were verified on origin but kept under explicit holds pending reviewed v2 lanes. Their old “cutover in progress” labels were replaced with the true reason: production intake currently covers only yesod and scr-wrap.

This is an important definition of “empty.” An empty v2 queue means no work is waiting in configured lanes. It does not mean every project in the catalog has been onboarded.

The resumed Yesod lane then proved real production behavior. A gate for ys-yes-6bdu ran across eight MicroVMs, reported 6,164 tests with zero failures, pushed the candidate, and completed the note. Subsequent re-gates continued from the reconciled queue without reviving the old launchd supervisor.

Two Final Alerts Improved the Design

The live dashboard initially reported attempt_heartbeat_stale even though the controller was healthy. The lease lasted 1,200 seconds and renewed 360 seconds before expiry, so the scheduler updated the attempt heartbeat only about every 840 seconds. The projection’s freshness threshold was 60 seconds. Both components were internally consistent and jointly wrong.

Commit 5bddfd9d added a fenced heartbeat-only update on every owned scheduler tick. It does not extend the lease expiry. The regression test advances time past 65 seconds and proves the heartbeat remains fresh, the lease deadline is unchanged, and the projection does not invent a stale attempt. The Conductor branch merged at d434f0aa, and the fix is live; subsequent gates showed a fresh advancing heartbeat without extending their lease deadlines.

The second alert was real. Two successful gates could not persist provider-status.json because yesod-dispatch inherited the Linux default /mnt/nas/yesod-blobs, but the NAS was not mounted. Gate verdicts remained valid by design and two gate_artifact_persistence_failed operator items opened.

The correction installed the NFS client, enabled a persistent systemd mount for 192.168.0.123:/volume1/yesod-blobs, proved that the path was actually NFS, and performed write, checksum, atomic-rename, and byte-for-byte read-back probes. The provider still retained both terminal reports. They were fetched, written to content-addressed Blob storage, read back, and referenced in the audited operator resolutions. The inbox returned to zero open items.

A Third Lane Proved the Whole Terminal Boundary

Onboarding yesod.work turned the last abstract invariant into a production test. Its tool prefix is ysw, so new notes are ys-ysw-* and linked root Beads are ysw-*; three earlier provisional ys-yes-* notes were superseded by correctly identified replacements. The reviewed lane is lane-v1-574981bc0bca351706b28b89, uses Node 22.23.2 on yesod-dispatch, and runs exactly:

npm ci
npm run check
npm run build

The first green sentinel exposed why “gate green” is not the factory’s terminal boundary. Its candidate reached main, but the root Bead remained open. The investigation found three independent host-boundary bugs:

1. terminal note projection committed before attempting Bead synchronization, but the synchronization result was discarded;
2. the service identity lacked a manifested yesod.work mutation workspace with the database’s canonical project_id; and
3. yesod-dispatch still ran bd 1.0.4, whose dependency query was incompatible with the current shared Dolt schema even though bounded reads succeeded.

The fixes landed in stages. aacbbf4d moved root-Bead synchronization after the terminal database commit. 032e1372 added the manifested yesod.work workspace, contained host-path failures at the adapter boundary, and documented service-identity provisioning. The canonical workspace control files were installed mode 0600 under mode-0700 .beads directories, and bd was upgraded to v1.1.0. A checksum-pinned installer now owns that runtime at /opt/yesod/beads-v1.1.0-linux_amd64.

The final sentinel was ys-ysw-6kot / ysw-p9l. Candidate 321a7275 passed the local lane, reached yesod.work main, projected the note to done, removed the legacy queue row, and closed the root Bead automatically. This proved task identity, gate execution, push, terminal projection, and cross-host Beads mutation as one chain.

One final portability pass then changed shared workspace persistence from raw host paths to ~/dev5/..., including migration of existing manifested rows. That prevents a Linux service registration from overwriting a Mac client’s workspace with /var/lib/yesod/..., or the reverse. The same pass records the canonical metadata.json.project_id as durable database identity rather than disposable machine state.

The refinery itself enforced the final correction. The first portability candidate went red because two MicroVM assertions still encoded absolute host paths; its failing shard otherwise reported 760 passes. After those assertions were corrected and existing manifested rows gained automatic migration, the successor candidate 86b3dc46 ran on eight distinct MicroVMs. The provider reported 6,258 tests collected, 6,231 executed, zero failures, zero retries, and zero infrastructure errors, then pushed the exact green candidate to main.

Promotion used the durable admission fence: revision 22 paused to 23, the immutable release was installed and verified, /srv/yesod/current advanced atomically, and admissions resumed at revision 24. The proxy, controller, and dispatcher all returned active with zero restarts; the active scheduler then reported a fresh heartbeat, zero tick errors, three idle lanes, an empty queue, and no operator items.

Onboarding Became an Idempotent Command

The successful third lane still depended on an operator remembering every place a repository had to exist. That was not a real onboarding procedure. A repository could have a catalog entry but no runner workspace, a workspace but the wrong note namespace, or a lane row that the active controller did not own.

Wave 8 therefore ended with two explicit commands:

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

The mutation converges catalog identity, note prefix, runner-workspace declaration, gate profile, controller manifest, PostgreSQL lane, runner provisioning, Conductor checkout, and active controller ownership. It takes its own exact-revision admission pause for lane registration. Repeating the real yesod.work command returned changed=false, converged=true, and eight unchanged steps; it did not duplicate any tool, workspace, profile, lane, checkout, or scheduler ownership.

Status proves nine named invariants: catalog identity, note namespace, workspace declaration, Beads workspace, dispatch-runner coverage, runtime lane declaration, refinery lane, controller ownership, and terminal acceptance. yesod.work returned both verified=true and dispatch_ready=true; all three runners resolved the same canonical server project identity, and the expected prefix remained ysw.

Two implementation defects were found by exercising the installed command, not its source-tree tests. First, a partially initialized Beads schema could return a fresh UUID without a metadata table in which to persist it. Empty workspace identity now requires both the issues and metadata tables before a canonical identity is minted. Second, a VCS/uv-tool installation looked for source-controlled manifests relative to site-packages. Release e9a39099 made manifest discovery prefer the invoking source checkout or an explicit YESOD_SOURCE_ROOT, and mutating onboarding now refuses to write outside a reviewable checkout.

The completion audit found two more fail-closed gaps before the command was declared finished. The readiness model now requires the runtime declaration directly rather than relying on controller ownership to fail indirectly. Both runner provisioning and read-only status retry one transient routed Beads read once; a second failure remains visible. Convergence JSON now separates changed from converged, and an incomplete non-dry-run exits one. Release 4f5a183b passed 59 focused tests and an eight-MicroVM gate with 6,330 collected, 6,302 executed, zero failed, and 551.8 seconds of provider time.

The durable procedure is documented in repository onboarding.

The Refineries Page Became Self-Explaining

The redesigned page was authoritative but still assumed the operator knew its vocabulary. It also showed how many provider instance identities were linked to a gate without saying how many MicroVMs AWS actually reported running. Those are different facts: assignment is exact historical gate identity; fleet liveness is a separately timestamped provider observation.

Release 2d61e8f5 added the Conductor fleet poller’s singleton PostgreSQL row to the same repeatable-read projection as lanes and schedulers. The browser still fetches only /api/refineries/v2; it does not race a legacy fleet endpoint or infer liveness from shard assignments. A prominent seventh summary card now says MicroVMs running, names AWS as the source, and shows observation age and freshness. Per-attempt rows instead say “N MicroVMs assigned to this gate.”

Small keyboard-focusable question-mark controls now accompany summary metrics, scheduler policy, lane and attempt state, gate progress, assignment identity, freshness, and attempt-detail sections. Every explanation gives four things: meaning, what it blocks, authoritative source, and expected operator action. Escape, outside click, focus return, responsive placement, and complete-script parsing are covered by the browser contract.

The first production gate made the distinction visible in real time. The gate had eight assigned instance IDs while the first AWS fleet snapshot reported seven RUNNING; the next observation reported eight. Candidate 2d61e8f5 then completed green across eight distinct MicroVMs with 6,316 collected, 6,288 executed, zero failed, and a 537.8-second provider execution. The fleet returned to zero after push.

A post-deploy audit found one final inconsistency: the poller did not store the legacy endpoint’s derived launch-storm tripwire, so v2 initially rendered an empty tripwire object. Follow-up b1ec256c derives the configured threshold from the authoritative running count itself. Its regression proves that 17 running instances trip the default threshold of 16 and degrade the page. That follow-up also passed an eight-MicroVM gate: 6,317 collected, 6,289 executed, zero failed, and 523.5 seconds.

The publish path produced one useful operational trap. Calling deploy-dertog.sh by absolute filename is insufficient because its payload paths are relative to the current working directory. Post-deploy API checks caught an initial no-op/stale publish. The correction ran the script from inside a fresh clone whose HEAD was the reviewed main SHA. Future promotions must preserve that working-directory invariant and verify a new API field, not only HTTP 200.

The final state is main and deployed release 4f5a183b, admissions active at revision 38, a fresh zero-error controller heartbeat, a fresh fleet snapshot with zero running instances and a healthy threshold-16 tripwire, two idle dertog services, and all Conductor services active with zero restarts. The global operator CLI is pinned to the same release.

What Is Live

The live deployment is healthy and active:

Fact	Evidence
admissions	active at revision 38 after exact fenced promotion
controller	active on yesod-dispatch, zero restarts
old supervisor	unloaded and absent from launchd
merge ownership	lanes and attempts authoritative in PostgreSQL; merge lock free outside pushes
gate execution	Yesod remote eight-by-one; scr-wrap local one-by-one; yesod.work local exact npm check/build profile
operator inbox	zero open items after artifact recovery
artifact storage	active NFSv4 mount plus verified Blob round trip
visualization	public Refineries dashboard on dertog returns HTTP 200; contextual help and the fresh AWS RUNNING count are live
workstation	sixteen rollback plists preserved, zero relevant labels loaded, all persistently disabled

The source and deployment boundaries now agree. The Conductor migration, per-tick heartbeat, Blob inventory, third-lane profile, terminal write-back, workspace portability, idempotent onboarding, authoritative fleet visibility, and pinned host runtimes are all represented on main at 4f5a183b. Promotion remains explicit—merging never silently retargets /srv/yesod/current—but the reviewed immutable release was advanced under the same admission fence and single-controller procedure used for activation.

The Exit Criterion Was Met

Wave 8 has already crossed the operational threshold that justified it: the factory no longer depends on a logged-in workstation or an LLM supervisor to interpret refinery state. A durable attempt owns every active gate, a stale worker cannot write past its fence, and the test workload runs on isolated machines rather than the client Mac.

The final code exit was deliberately narrow and is now satisfied:

1. refinery-conductor-qii1 passed its normal gate and landed at d434f0aa;
2. yesod-dispatch promoted the merged controller, and per-tick heartbeat evidence stays fresh without extending lease expiry;
3. ordinary terminal gates persist evidence through the mounted Blob path;
4. the production boundary is explicitly three lanes, with other projects admitted only through the idempotent onboarding/status contract;
5. terminal acceptance now includes automatic root-Bead closure, not merely a green gate and Git push;
6. the Refineries page distinguishes actual AWS fleet liveness from gate assignment identity and explains its operational vocabulary in place; and
7. main, the Conductor release, dertog API/UI, and the globally installed CLI converge on 4f5a183b.

The sjbis argument-vector exposure and host-neutral OpenCode wakeup gap remain visible follow-ups. They do not weaken the refinery exit, and they were not allowed to disappear into its success story.

The durable lesson is that determinism is not synonymous with centralization or serialization. The controller is deterministic because identity, authority, deadlines, and effects are explicit. The gate is fast because execution is parallel across isolated MicroVMs. The host map is safe because standing services live on a boot-managed Conductor, visualization lives on a read-oriented box, artifacts live on durable storage, and the workstation is free to be a workstation again.