6c. The §2.1 round against staging (acceptance.yml)

Weekly (Mondays 02:30 UTC) and by hand from the Actions tab — Run workflow on acceptance. It is the only thing that drives STAGE2.md §2.1 steps 2 to 6 against the deployed system as a customer reaches it: a new owner invited, joined, enrolled and signed back in with a code; then the portal's own routes and the Releases screen's own buttons. About 45–50 minutes: two model calls and six tenant deploys. acceptance/live/round.ts is the account of what each step asserts.

**Its company is acceptance, never heatco**, in the test fleet's account. Heatco's production is what staging.yml's doctor --require reads on every push, and step 6 breaks production on purpose.

What it leaves standing, and why each week can follow the last:

• **acceptance** — production, one revision behind the latest: step 6 ends rolled back, and next week's step 3 deploys that revision forward. The runner plans a migration from what a target runs only when that is the revision before the one it deploys, so the round never leaves a target further behind.
• **acceptance-blank** — never has a revision. Step 2 describes into it and declines.
• **Trial round** of acceptance — kept open (acceptance-round-prod), one Worker, database and bucket for good rather than one set a week. Step 4 brings it to production's revision before trying a change in it.
• Revisions — three a week (a field added, promoted, then renamed to break production), and a model that grows by one optional field a week.
• **A standing owner, acceptance@owners.release-journey.divvent.invalid** (Ant, 2026-09-28; DESIGN.md §17, decisions 47 and 109) — at the release test's reserved owner domain, which no mail can reach, composed by reservedOwnerAddresses and never spelled in the round; ours only because staging names DIVVENT_INTERNAL_DOMAIN in vars.staging. The one before, acceptance@divvent.dev, is retired by the round once this one has joined. An account always keeps an owner, with no exemption for a test company or an operator's command (proposal 34, rule 5), so the week's owner (acceptance+<run>-<attempt>@…) can be removed at the end only because this one stays. The round makes sure of it before anything else: account create --owner acceptance@… --reissue answers joined every week after the first, and otherwise the round joins it over /join with a password it throws away. Nobody signs in as it; it is there to be the owner that stays. Never remove it: the next round would re-open it, but the one that found it gone could not remove its own owner and says so.

Waiting on the runner. Every deploy is a request. The round runs no pass of its own: it dispatches deploys.yml while the request is queued (at most once every 15 minutes), and waits while that pass holds it — up to 40 minutes per request, which is two whole passes of four jobs (plan, a build leg per hash, collect, deploy; about eighteen minutes each). A step that runs out says which request, its target, its state and who held it. claimed by deploys.yml-… for 40 minutes is a runner that died with the claim; claims go stale at 20 minutes, so the next pass takes it back — re-run the workflow. The job's ceiling is 180 minutes.

When a round stopped part-way, the next one heals it — re-run, or wait for Monday. A revision is only ever written after step 3 has put production on the latest, so neither target is ever more than one revision behind: step 3 says "already runs … Nothing to deploy" where production is at the latest, and step 4 brings the trial to production's revision. That holds for a failure at any single point, and was worked through for each.

**What it cannot heal is acceptance moved by hand.** A revision approved or deployed outside the round can leave a target two revisions behind, and then a deploy fails in the runner's ledger (table "…" already exists — the runner planned from scratch, because the target is not at the revision before). There is no command that deploys a revision other than the latest, and a trial that has been deployed cannot be closed: divvent destroy leaves the control plane's row naming its revision, which is what closeTrial refuses on. Leave acceptance to the round.

It needs, in the staging environment: the secrets staging.yml's tenant steps already have, PREVIEW_ACCOUNT_ID and PREVIEW_DEPLOY_TOKEN, and the portal's Anthropic federation configured (step 2's no-credential names the missing setting).