ucc

The UCC distribution: what a host installs, at which pins, and the rounds that prove a release before any host gets it.

It holds the installer (install.sh --floor 2|3|4), the current release (releases/current.md) and each release's immutable record (releases/v<N>.md), the changelog (CHANGELOG.md), the update SOP (UPDATE.md) and the command that runs it (ucc), the skill manifest (skills.md) and the round harness (rounds/).

Installing

A first install needs no agent when someone you trust sent you here: they are your trust boundary, and you run three commands yourself. Set the first three lines — UCC_FLOOR to 2, 3 or 4 (the floor table below), UCC_TOKEN to the token file you were given, UCC_ENV to your profile's env file — then paste the block; V is the release releases/current.md § version names:

UCC_FLOOR=3
UCC_TOKEN=$HOME/ucc.token
UCC_ENV=$HOME/ucc-profile.env
git clone -b release https://git.0xdao.app/caoer115/ucc.git && cd ucc
V=$(awk '/^## version/ {f=1; next} f && /^v[0-9]+$/ {print; exit}' releases/current.md)
./ucc stage --scripts --token "$UCC_TOKEN" "releases/$V.md"
./install.sh --floor "$UCC_FLOOR" --release "$V" --token "$UCC_TOKEN" --env "$UCC_ENV"

ucc stage --scripts is a step either way: install.sh runs the skills' installer and the sessions root's init, and places ccc-pages, the ccc-vm skill, the sessions-root template and at floor 4 the mods, only as that step recorded them, and without it refuses (rc 3, nothing written). What comes after is not on their word: an update comes from the release branch, not from the person who sent you here, so an agent on your host reads each one before it runs (§ Updating, UPDATE.md § sop). An agent given an install reads first, by the text below.

UCC install — read before you run. You are installing UCC into your own home on this machine. Nothing here asks you to run a script you have not read. Your owner names the mode: fast, or careful (UPDATE.md § careful); fast when not named. A first install has no diff: read everything once, dig on a finding, and go careful on your owner's word.

1. Clone the release branch and read it. git clone -b release https://git.0xdao.app/caoer115/ucc.git && cd ucc. Read, in this order: CHANGELOG.md (the entry for the release releases/current.md § version names); UPDATE.md (what an install and an update do, and what this repo can and cannot do to your machine); install.sh and ucc (the install's own two scripts); releases/v<N>.md (every binary the install downloads, its sha256 and where it comes from). Then what the install runs and places from the release set: ./ucc stage --scripts --token <the token file your owner gave you> releases/v<N>.md downloads the record's cc-continuity.tar.gz (the skills and their installer), ccc-pages.tar.gz (the ccc-pages skill), the sessions-root template, sessions-root/init and, on a release from v10, the Claude Code mods (mods.tar.gz, which a floor-4 install places and every patched seat loads at session start with no prompt) and, on a release from v12, ccc-vm (ccc-vm.tar.gz, the ccc-vm skill every floor places at shared/ccc-vm and links, its nix/desk/desk on PATH as desk), hashes each to the record, unpacks them at ~/.local/share/ucc/cache/diff-read/v<N>/ and records their sha256 in shown there; it runs none of them, only the release's mrd, hashed to the record, to read it. Read them as UPDATE.md § appendix: careful in detail says — what runs on this machine without a seat asking is in those trees.
2. Check what you read. install.sh and ucc do what UPDATE.md § what runs says and nothing else: every byte lands under your $HOME but the three that section names (the tmux socket at floor 3, the daemon's sweep scratch under $TMPDIR from floor 3, and on a later ucc update of a host that runs Paseo, the pinned @getpaseo/cli under npm's own global prefix, where that prefix is outside your $HOME); inside your $HOME it changes three things of yours, each named in the floor table's notes below; the network destinations are the hosts releases/v<N>.md names — get-ucc.sui.pics for the release set, storage.googleapis.com for the official Claude Code — the two git remotes it clones, the daemon it starts at 127.0.0.1:<port> (--port), and npm's registry for that pinned @getpaseo/cli; nothing is decoded or evaluated at run time, and nothing fetched is run but the record's own artifacts, each hashed to it, the tarballs only at the sha256 ucc stage --scripts recorded. The official Claude Code's sha256 is the vendor's own (claude-code-releases/<claude_code>/manifest.json, platforms.<your platform>.checksum): this read takes it on the record, and careful mode matches it to that manifest (UPDATE.md § careful step 3).
3. Anything you cannot explain — a line the SOP does not account for, a destination you do not know, a binary whose origin you cannot trace — you trace to its source, or you stop and ask your owner, quoting the lines. You do not install while a question is open.
4. When you are confident, install: ./install.sh --floor 2|3|4 --release v<N> --token <the token file your owner gave you> --env <your profile's env file>. The receipt is the last line of ~/.local/share/ucc/install.log; ucc status shows the installed lock, green. At floor 3 the install also starts tmux session agents, detached, where a seat the daemon spawns (a page's hook, ccc-agent spawn from its context) lands when no herdr session answers; ucc status names where such a seat lands (panes:), or why it cannot. From here your host tells you when a release is out, and UPDATE.md § sop is what you do then.

A profile signed in with a Claude account, not an API key: pass --env a file with none of ANTHROPIC_BASE_URL, ANTHROPIC_AUTH_TOKEN and ANTHROPIC_API_KEY — only lines the profile keeps (its proxy lines, a model name) or nothing at all — then sign in with /login in a seat. An install refuses such a file over a profile whose .env holds a key: to switch, move that .env aside first. On a Mac Claude Code keeps that login in the Keychain, which the daemon's credential sync does not read yet.

A release has a build for linux-x64 (its record's § artifacts) and, where its record carries § artifacts darwin-arm64, for Apple silicon Macs. A host on any other platform is refused before anything downloads, and the refusal names this host's platform and the release's.

On a Mac. Apple silicon on macOS 15.4 or later, with the Xcode Command Line Tools (xcode-select --install; git is theirs) and these from Homebrew in place first:

brew install jq tmux git-annex gitleaks zstd ripgrep bun

bun and python3 (the Command Line Tools') run the skills' scripts: without one the install goes on, its log names the interpreter absent, and the scripts that need it fail when run.

install.sh refuses an Intel Mac, a macOS before 15.4, or a Mac without the Command Line Tools or jq, before it writes a byte, and so a Mac without git-annex, gitleaks, zstd or ripgrep (macOS's own grep does not qualify) where it births the sessions root, whose init needs them; at floor 3 without tmux (or herdr) it installs and logs that a seat the daemon spawns has no terminal to start in. Floors 2 and 3 install as on Linux, from the record's § artifacts darwin-arm64 binaries. The follow tick and, at floor 3, the daemon's start are LaunchAgents in place of the systemd timer: ~/Library/LaunchAgents/ucc.follow.plist (every 10 minutes) and ucc.cccd-start.plist (starts tmux session agents and the daemon at login and every 5 minutes when either is not there), loaded into your login session's launchd domain (gui/<uid>, or user/<uid> from an ssh session), their logs in ~/Library/Logs/.

install.sh refuses, before it writes a byte, a clone whose HEAD is not the head of release on the remote the host will follow, or whose tracked files differ from that commit: what you read is what runs. Where it births the sessions root it refuses so a host without the tools the root's init needs: git-annex, gitleaks, zstd, tar, and ripgrep, ugrep or GNU grep. --release builds the stage under $UCC_HOME/releases/v<N>/stage from the clone's install.sh, ucc, skills.md, UPDATE.md and releases/current.md at its commit and every artifact of releases/v<N>.md, downloaded with the token and hashed, then runs the stage's install.sh. Over an existing install the same line reinstalls: --env is not needed, and the profile, port, desktop and sessions root are kept. The read it needs is the release's read on this host: ucc stage --scripts of that release, or the ucc diff an update of this host to it ran on, which that update's install keeps in $UCC_HOME/cache/diff-read/v<N>/shown with the template where that update's ucc bound it, as one from v10 on does; after an update an older ucc ran, --release refuses and names ucc stage --scripts until it runs. --from <stage> installs a stage already built — one install.sh --release or ucc update built and kept ($UCC_HOME/releases/v<N>/stage) — under the same read as --release: the stage's skills' installer, ccc-pages, ccc-vm and template, and init where it births the sessions root, must hash to the shown file of the read step, else it refuses (rc 3, nothing written), and its PINS must match releases/current.md § pins. A round's stage, rounds/build-tarball.sh's, installs with --round alone. install.sh --help lists every option.

Floor	What lands	Launchers
2	mrd, cccd (the record face cccd face, MCP server ccc), on a release from v12 ccc-vm (the record's bin/ccc-vm, beside them in ~/.local/bin) and the ccc-vm skill with its desk, the floor-≤2 skills, the key file config/mcp/ccc.md, the sessions root, ~/MERIDIAN.md merged with the four mounts (sessions, contracts, ucc, opt), the followed checkouts ucc/ and contracts/, opt/VERSION.md and opt/release.lock.md (installer-written, walked green), ucc-follow.timer (pull only)	ucc-claude (official Claude Code, seat minted on the face), ucc-codex, ucc-kimi, ucc-grok — each a thin wrapper around cccd mint
3	+ the ccc-statusd daemon (started), its hooks in the profile, the floor-3 skills	the same
4	+ the patched Claude Code build (the record's bin/claude-patched row; on a Mac its § artifacts darwin-arm64 row), the floor-4 skills	+ ucc-<profile> (patched, the daemon's HTTP entry)

• Everything lands under $HOME but what UPDATE.md § what runs names (the tmux socket, Paseo's npm prefix, and from floor 3 the scratch files the daemon's sweep of the sessions root makes under $TMPDIR and removes); nothing runs from the followed checkout $UCC_HOME/ucc (the script refuses to), and launchers and scripts are installed copies.
• opt/release.lock.md pins the contract sections the installed daemon's CONTRACTS.md pins, opt:VERSION.md § components (which names the ucc commit installed), ucc:releases/current.md § version and § pins, the installed opt:UPDATE.md § sop and every release record up to the installed one; ucc status is the walk and its answer. ucc-follow pulls the followed ucc branch and contracts main every 10 minutes and walks it.
• Floor 4 installs as floors 2 and 3 do, by the same token: every link on the release set takes it, the patched build's too. Which floors a release's proof covers on each platform, its CHANGELOG.md entry says.
• Seats run without permission prompts. Every UCC seat profile's settings.json sets Claude Code's permissions.defaultMode to bypassPermissions and skipDangerousModePermissionPrompt, its .claude.json has the bypass mode accepted, and its env sets CCC_TOOL_USE_ALLOW_ALL=1, with which the daemon's hook (floor 3 and up) approves every tool call and permission request it is asked about but the ones its own guards stop. --desktop does the same for your own Claude Code: it merges into ~/.claude/settings.json the profile's hooks and env (CCC_TOOL_USE_ALLOW_ALL=1 among them), permissions.defaultMode bypassPermissions where you set none, and skipDangerousModePermissionPrompt, so every session that reads ~/.claude — the Desktop Code tab and a plain claude alike — runs without asking; your first copy is kept as ~/.claude/settings.json.pre-ucc. It also adds the MCP server ccc (cccd face, the record face) to ~/.claude.json's mcpServers, so every claude you run loads it; that file's first copy is kept as ~/.claude.json.pre-ucc.
• A git identity, where you have none: the sessions root's commits need one. A user.name or user.email git finds outside any repo — in your global or system git config, or a file either includes — is yours and is kept. Where one is missing, the install puts a default — your login name, <login>@<hostname>.invalid — at the top of your global git config (~/.gitconfig, else ~/.config/git/config when only that exists), which every repo you commit in afterwards reads; any identity set below it in that file or in a file it includes, an includeIf one too, wins over it. A git config that git cannot read is left as it is, and the install log says so.
• Your login shell's rc gets one line that sources $UCC_HOME/env.sh, so ucc and the launchers are on PATH in a new shell: ~/.zshrc (under $ZDOTDIR when set) for zsh; for bash ~/.bashrc, and on a Mac, whose Terminal opens login shells that never read it, the first of ~/.bash_profile, ~/.bash_login, ~/.profile there is (~/.bash_profile when none is); ~/.profile for any other shell.
• skills.md is the manifest: skill → floor → core range; install.sh cuts the rows above the floor (ls $UCC_HOME/shared/skills is the test) and names a skill outside its core range in opt/VERSION.md § skills.
• ccc-vm, on a release from v12: its skill comes from the record's ccc-vm.tar.gz alone (a stage whose cc-continuity carries one of its own is refused) and its command is the record's bin/ccc-vm (on a Mac bin.darwin-arm64/ccc-vm) at ~/.local/bin/ccc-vm, first on PATH. UCC places ccc-vm's desk, the desktop driver its skill names, through skills-bin, last on PATH, so a desk of your own wins; desk runs ssh, jq and ccc-vm from PATH (on a Mac jq is on the brew line above; on Linux install it with the host's package manager, as ucc itself needs it). desk pw, its opt-in browser mode, needs desk-pw, which a release does not ship.

Crossing

A home another installer set up — its own profiles, ucc-* launchers and skills under ~/.local/share/ucc, its own daemon and sessions root, and no opt/VERSION.md — crosses to the release once, in place: what it holds is upgraded where it stands, never replaced by a second environment. A plain install.sh over such a home refuses (rc 2) before it writes a byte. A ucc first install killed before it wrote opt/VERSION.md (a power loss, an OOM kill) reads the same way: move ~/.local/share/ucc aside, then install again. After the crossing the host updates as any host does, ucc diff then ucc update, and every later install keeps what the crossing kept.

From a fresh clone of release, after § Installing's read step (ucc stage --scripts):

./install.sh --cross --check --floor 3 --release "$V" --token "$UCC_TOKEN" --profile <name> --port <n>
./install.sh --cross --floor 3 --release "$V" --token "$UCC_TOKEN" --profile <name> --port <n>

• --profile names the host's profile ucc-claude launches on, --port the port this home's daemon serves (CCC_STATUSD_MCP_PORT in user-env.sh). The crossing is floor 3 alone, a later install takes floor 4; it takes no --env and no --desktop.
• The census runs first and writes nothing outside the read's scratch (cache/, install.log, config/get-ucc.token, releases/, update.lock). It refuses on: a port another process holds; a daemon daemon.pid names that is not this home's (another account's, one that runs no build of the host's own ~/.local/bin/ccc-statusd or cccd, or one that does not hold 127.0.0.1:<port>); a host with neither ss nor lsof, by which it tells who holds the port; a port other than --port that the release's daemon would serve, CCC_STATUSD_MCP_PORT as default-env.sh and then user-env.sh leave it over --port (read only from a line of its own at the file's top, after no return or exit: a number, ${CCC_STATUSD_MCP_PORT:-<n>}, the key itself, or unset; a value that ends unset, empty or not exported, a write in a block, and any other form refuse too), or a --port that is no number from 1 to 65535; a primary root outside $HOME, without its MERIDIAN.md, at formats the release's daemon does not read, or other than the one $UCC_HOME/sessions or CCC_SESSIONS_ROOT names; a mount table the release's mrd would not load, or a mount that already carries sessions, contracts, ucc or opt for another root; a ucc/, contracts/ or opt/ that is not ucc's; a hook or status line that runs a file the landing removes, or a launcher it keeps that names one by its skills-bin or shared/skills path and would not run it after; too little disk for the backup; a contracts main that does not hold the release's contracts pin, or a contract row off the fingerprint the release names. --check runs the census, prints the plan (each path kept, backed up, new or cut, and each skills-bin name no skill of the release carries, kept or dropped and why) and exits 0.
• Kept as it stands: every profile, byte for byte (opt/VERSION.md § install names it on a - kept: line, and no later install writes it); every launcher ucc did not write; each skills-bin name no skill of the release carries, whatever calls it, where its link ends at the host's own executable outside what the landing replaces, where neither that file nor its folder has the other-write bit (a fleet ucc-<profile>'s ucc-shadow-ensure, in the fleet's own shared/cc-continuity; owner, group write, ACLs and the folders above are not read): skills-bin links it again there by its physical path, on every install, until that file or the skills-bin link goes; the sessions root the table names primary, bound by a link at $UCC_HOME/sessions, with no init, and ucc adopt refuses on it; the blocks of ~/MERIDIAN.md; user-env.sh, default-env.sh and the host's services; every skill ucc did not place, above the floor too, unless the release carries a skill of that name at the floor (that one is backed up and replaced by the release's).
• Backed up, then replaced: ~/.local/bin/{mrd,cccd,ccc-statusd,ccc-agent} (and ccc-vm, with shared/ccc-vm, where the release carries ccc-vm), ~/MERIDIAN.md (ucc's mounts are added), shared/skills, shared/agents, skills-bin, the launchers ucc wrote, the followed checkouts ucc/ and contracts/, the daemon's stores and the files ucc writes in place. The daemon's stores (data/ccc-status, cache/ccc-status) are copied at one point, the last before a release-build daemon can write them: once the old daemon stops, just before the release's starts, or with the rest of the backup where no daemon runs; each SQLite file by sqlite3 .backup where the host has sqlite3. The stop and the copy hold the daemon's start lock (cache/ccc-status/daemon.start.lock), so no seat's hook starts a daemon meanwhile; a daemon that comes up anyway (a supervisor's) is stopped and the copy taken again, and a third stops the crossing. The backup is $UCC_HOME/cross/<UTC stamp>/; its MANIFEST has one row per path: the original, then its copy, or - where none stood (a launcher, a checkout, the $UCC_HOME/sessions link, runtime/ where no daemon ran), which a stop removes.
• The daemon on --port restarts onto the release's cccd, under default-env.sh and then user-env.sh.

Live seats. Every seat that was running loses its ccc tools at the daemon's restart. Its MCP config still points at --port with the kept token. In each seat's own pane (herdr's or tmux's), type /mcp, reconnect ccc, and check that roots answers. A seat that does not reconnect: exit it, then start it again through its own launcher with --resume <session id>. A seat Paseo started (paseo ls) has no pane to type /mcp in: once it is idle (paseo wait <id>), paseo agent reload <id> restarts its process on the same session, through the launcher and environment Paseo starts it with; then paseo send <id> 'Call the ccc roots tool and reply with the roots it lists.' and check that the reply names them. Hooks run the release's cccd from the binaries step on.

A stop puts the old environment back. A crossing that stops after its backup stops the daemon daemon.pid names (unless it is still the one that ran before, which a stop before the restart never stopped), the placed mrd's resident, the follow timer, on a Mac the daemon's start job (ucc.cccd-start), and the tmux server it started where none ran before (by the pid it recorded then, and only while it holds no session but agents; a server that ran before stays), and moves each MANIFEST row back, holding the daemon's start lock. Where no daemon ran before the crossing, it stops one that came up meanwhile. It signals or counts a daemon only where it runs as your account and runs the host's own ccc-statusd or cccd (as the census read them, or as they stand then), and one /health names only where it holds the port /health answers on; one that does not it leaves alone, starts nothing in its place, and names in opt/VERSION.md, where what a process outside your files answered is written in a safe character set. It then starts the daemon that ran before as the census saw it run — the file it ran, with its command line, on its port, under default-env.sh and then user-env.sh — unless that build answers there already, and checks that /health names that build and its pid. opt/VERSION.md then reads INCOMPLETE and says how many rows came back, which daemon answers, and what the stores lose: what a daemon wrote to them after their copy. Run install.sh --cross again from a fresh clone; it admits that stop. Records seats wrote on the root in the meantime stay, and the old mrd rebuilds the root's .meridian index. A row the put-back could not move is named in opt/VERSION.md as the command to run by hand — rm -rf <path> && mv <copy> <path>, or rm -rf <path> for a - row — after which you start the old daemon yourself.

What changes for the host. Your shell's rc gets the line that sources $UCC_HOME/env.sh after the host's own env files: skills-bin moves from first to last on PATH, and DISABLE_AUTOUPDATER=1 is set. Where Paseo runs, the first ucc update moves it to the record's paseo= pin (ucc diff says so). The other installer's own updater must not run on a crossed host from then on: ucc diff and ucc update are its updater.

Updating

A release is one push to release: releases/v<N>.md born (pins, artifacts with sha256s and links — rounds/lib/release-record.sh writes it from the stage), releases/current.md § version and § pins bumped, and a CHANGELOG.md entry that names every tooling file it changes. Within the follow timer every behind host's walk reads red on the release record alone, its seats' first-turn line reads install behind and ucc status reads install behind — read it: ucc diff, then ucc update, or ask your owner. Then two steps, UPDATE.md § sop:

1. ucc diff prints the CHANGELOG entries since the installed release, the diff of install.sh, ucc, skills.md and UPDATE.md against what the host last ran, the installed record beside the target's, each of the target's tarballs fetched, hashed and unpacked at $UCC_HOME/cache/diff-read/v<N>/ with the files it changes against the host's copy, and the commits, and records the commit, the record and each tarball's sha256. The agent checks the diff against the entry, and asks its owner on anything it cannot explain.
2. ucc update runs that commit and nothing else — it refuses when no diff was shown, the branch moved since, or the diff showed another record or another tarball: the record's binaries downloaded and hashed, the commit's installer run from the stage, the lock walked last. --rollback installs the previous release and --to v<N> another recorded one, through the same steps, each read first by ucc diff with the same flag. Either lands a release whose core pins the contract sections at the fingerprints the installed one does — a CONTRACTS.md row with another sha256 in the records ucc diff shows is the sign it does not — and across a contract change step 7 stops, rc 6, the installed release restored: going back over it is the owner's question.

A host whose ucc is below v8 is refused by the release's installer before it writes a byte (the old ucc update has by then moved an installed Paseo to the release's pin), and is installed again from a fresh clone of release as § Installing says, over its install.

Red anywhere but the release record stops ucc update with nothing applied, and the agent asks its owner. ZT's fleet never runs it (UPDATE.md § fleet hosts).

Rounds

A round is a fresh VM, a UCC release installed into two test users' homes, a scripted exchange per harness kind with an expected observable for every step, planted faults scored caught or missed, a record, and the VM destroyed. Like CI, but run by agents experimenting; a round that stays green three times becomes a Woodpecker job.

flowchart LR
  B["build-tarball.sh<br/>on workstation-nyc-2"] --> V["run.sh: spine vm create --desk none<br/>vm install the ucc-round image"]
  V --> I["install-round.sh<br/>as zt2 and as zitao2"]
  I --> X["exchange per kind:<br/>message · card · handoff readback"]
  X --> F["planted faults F1–F7"]
  F --> R["steps.jsonl → score.py → the round record"]
  R --> D["spine vm destroy --no-backup"]
  S["stop-rule.sh: api error, 429 or login prompt<br/>→ that kind's seats killed, scored n,<br/>one line to the leader"] -.-> X

File	Does
rounds/build-tarball.sh	the round's input, built on workstation-nyc-2 from the forge: a static ccc-statusd at a main sha and at its parent (N−1), the pinned mrd and the previous one, the patched and the official Claude Code at the pin, cc-continuity at ucc-v2, the ccc-pages skill, the sessions-root template (the public pack rounds/sessions-root.base pins with rounds/rules/ laid over its rules/); PINS names every input
rounds/install-round.sh	install.sh --floor 4 --round for one test user. round-host.sh installs zt2 at floor 3 (the official binary, no patched build — the M1 user) and zitao2 at floor 4 (the patched kind, the daemon-swapping faults); --round adds the socket recorder, the face profile and launchers the U6 rows use, and the refusal of a home that holds a UCC install which is not a round's; the root is the release's template, as for every install
rounds/m1.sh	the milestone rows (exchange/m1.md): the floor-3 install log, no patched build, the lock walk, the four mounts, the launchers, the skills by floor, the follow timer, the stock seats' writes through mcp__ccc__put with the triple
rounds/run.sh	one round end to end on a spine hypervisor (or --host local)
rounds/round-host.sh	the round on the host it runs on: install, exchange, faults, collect
rounds/stop-rule.sh	a kind whose account answers badly leaves the round
rounds/exchange/<kind>.md	each kind's steps and expected observables: claude-patched, claude-stock-tui, claude-stock-p, codex, kimi, grok; k3-register.md the client-contract rows across kinds
rounds/steps.d/*.sh	a unit's own rows, sourced by round-host.sh after the planted faults with its helpers in scope — one file per unit, so parallel units merge clean; 90-u8.sh is the update check (exchange/u8-update.md), on the round's own ucc remote, from run.sh --tarball-next
rounds/lib/release-record.sh	releases/v<N>.md from a stage — the one writer of a release's record, for a cut release and for a round's release at the round's links
rounds/lib/mcp.py	one MCP call against a test user's face — for faults a seat cannot plant on itself
rounds/lib/transcript.py	the reads of a seat's transcript the scoring uses
rounds/lib/score.py	a round folder as the record: pass/fail per step with artifacts, then counts
rounds/darwin-round.sh	the darwin stage (launch D), run from devstation-nyc-1 (the host that reaches zmax-1): a clone of the golden macOS image on zmax-1 born for the round under the clone lock, darwin.sh run as its admin (role a, the gui/ domain) and as a standard, hidden user made in it (role b), their folders copied back, the clone deleted, the lock dropped and both read back on every exit — the host steps are leader-mac-vm's clone recipe, in one block; run.sh --darwin <its --out> folds the rows
rounds/darwin.sh	the stage: --darwin rows under /bin/bash 3.2: mac1 installs at floor 3 and proves the platform (the scripts parse, the darwin section's binaries, the follow and daemon launchd agents, an installer re-run that starts the daemon without the caller's tmux and revokes a page endpoint's site trust as v7 left it, a tmux seat spawned from the daemon's launchd environment into session agents, a message); mac2 runs the update door against a round stage and a file:// remote on the Mac

The faults: F1 a released section edited (a scratch lock until the contracts repo exists), F2 an incompatible pair (the previous engine build against this one), F3 a daemon off its installed binary, F4 a message to a vacant seat, F5 a forged _meta, F6 a daemon restart with a held request (an AskUserQuestion wait), F7 seats started on N−1 and the daemon upgraded to N.

Accounts: every Claude seat is the official or the patched binary on GLM through ANTHROPIC_BASE_URL — no Anthropic account, no /login. Native kinds use only the logins ZT made on their VMs; a kind without one scores n.

Running one

On workstation-nyc-2:

rounds/build-tarball.sh --cccd <ccc-statusd sha> --out ~/round-build
image=$(git -C <agent-backbone> show origin/main:images/ucc-round.json | jq -r .image)
rounds/run.sh --round r01 --tarball ~/round-build/ucc-round-<sha8>.tar.gz --env <glm env file> \
  --out ~/rounds --host <spine hypervisor> --image "$image"
rounds/lib/score.py ~/rounds/r01/out

The env file holds ANTHROPIC_BASE_URL, ANTHROPIC_AUTH_TOKEN and the model names of a GLM profile; it is copied 0600 and never printed.

The darwin stage beside it, from a checkout at the same commit and the same stage (one built with bin.darwin-arm64/), run on devstation-nyc-1 — the host that reaches zmax-1 — with the folder copied back for the fold:

rounds/darwin-round.sh --round r01 --stage <ucc-round-<sha8>.tar.gz copied from workstation-nyc-2> --env <glm env file> \
  --out <work>/r01-darwin [--candidate releases/v<N>.md]
scp -r <work>/r01-darwin workstation-nyc-2:rounds/r01-darwin
rounds/run.sh … --darwin ~/rounds/r01-darwin   # on workstation-nyc-2
# or, after the launch's record step, the late fold (rounds/run.sh § The late fold):
cp -a ~/rounds/r01-darwin ~/rounds/r01/record/darwin && rounds/lib/score.py ~/rounds/r01/record --artifacts-at r01 > ~/rounds/r01/record/score.md.txt