A factory anyone
can deploy.

Current implementation state

Status observed August 24, 2026 at 9:38 p.m. Pacific: this is a re-anchored implementation roadmap, not a deployed AWS system. None of the ten successor roots has merged. No AWS account bootstrap, live probe, DNS record, IAM role, secret, or deployment has been created for this initiative.

The sole active roadmap root is ys-yes-yrzz, which is revising the product, authority, data, and release contracts against the production factory. Its run, run-77eee3478772, is executing on yesod-runner-3. One documentation child has committed 3580e576, but the root is still running and that work is not on main.

The companion roadmap documentation PR is open and mergeable at 003947e8; it is review evidence, not shipped implementation.

What changed in the re-anchor

The July design assumed a parallel hosted control plane and a dedicated integration branch. The August re-anchor starts from what the production factory can already prove:

• Reuse the production state machine. Hosted work extends Lifecycle v2 notes and revisions, validator-backed plans, Bead roots, dispatch arms and runs, factory events, Refinery v2, onboarding, and release promotion. It does not introduce a parallel hp_* work/request/instance model.
• Keep the Mayor local and bounded. The Mayor is an operator-local control client. Its placement grants no authority: it may propose or invoke authenticated operations, but it cannot manufacture a human decision or approval.
• Keep authority transitions separate. Human approval, refinery landing, release promotion, and deployment evidence remain distinct records and gates.
• Land the early contracts through the existing main refinery lane. The retired aws-hosted-yesod branch is historical evidence and must not be revived. No aws-hosted-yesod-v2 ref exists today.
• Keep coding and verification credential-free. Coding workers and refinery gates receive no AWS credential. Offline fakes and contract tests come first.
• Broker any future live proof. A live AWS probe must pass through an allowlisted deterministic broker in an isolated lab account, with a separate lease, explicit approval, TTL, quotas, cleanup ownership, and kill authority.

What the Vultr runner trial proved

On August 23, a fresh Vultr runner successfully joined the factory and claimed both inference slots, but Beads-heavy work was not usable across the WAN. One bd dep list in Beads 1.1.0 opened roughly 136 TCP connections and issued about 190 statements—an estimated 1,200 round trips. The same operation that took seconds at roughly 3 ms LAN latency stretched to 30–60 seconds or more on the approximately 24 ms Vultr link and began timing out. The runner was deliberately shut down. See the observed slowdown, the protocol trace, and the operating decision.

That was a protocol-placement failure, not a shortage of remote compute and not evidence that Dolt was overloaded. It gives this roadmap a concrete constraint: Beads clients and their Dolt state must remain inside a genuinely low-latency network boundary, or the protocol must shed those round trips before WAN runners are treated as viable. A remote worker merely connecting and claiming work is not enough to prove the execution path.

The intended deployment shape

The target is still a durable Mayor with a serverless software factory behind it. The important correction is that this diagram describes the intended post-gate system—not infrastructure that exists today.

             Trusted operator workstation
   ┌────────────────────────────────────────┐
   │ Local Mayor control client + yc        │
   │ authenticated principal; no authority  │
   │ merely because the process is local    │
   └──────────────────┬─────────────────────┘
                      │ HTTPS + scoped credential
                      ▼
           Route53 + ACM + API Gateway
                      │
             Authenticated /v1 API
                      │
          ┌───────────▼────────────┐
          │ Production factory     │
          │ Lifecycle v2 + events  │
          │ approvals + promotion  │
          └───────────┬────────────┘
                      ▼
        Aurora PostgreSQL-compatible control plane
                      │
             Reconciler / admission
                      │
          ┌───────────▼────────────┐
          │ Disposable Lambda      │
          │ MicroVM execution      │
          └───────────┬────────────┘
              ┌───────┴────────┐
              ▼                ▼
       trusted Git broker   private Dolt
                           on EC2 + EBS

   Future live probes: isolated lab + deterministic broker only

Dependency-ordered delivery

The roadmap is deliberately serial. Exactly one roadmap root may be approved at a time until campaign admission exists. A root being planned does not mean it is approved for execution.

Order	Live factory record	Contract or proof	Grounded state
1	ys-yes-yrzz	Re-anchor product, authority, data, and release contracts	In progress — sole admitted root
2	ys-yes-oqrc	Reconcile the hosted schema with Lifecycle v2	Planned / held
3	ys-yes-zwk3	Define the Lambda MicroVM adapter boundary	Planned / held
4	ys-yes-keyd	Audit the PostgreSQL-to-Aurora compatibility seam	Planned / held
5	ys-yes-ucwr	Define the authenticated /v1 API and yc evolution	Planned / held
6	ys-yes-sefx	Re-anchor the threat model and security gates	Planned / held
7	ys-yes-etn0	Define fresh-account bootstrap, payer, credential, and MicroVM state contracts	Planned / held
8	ys-yes-ydq7	Enforce PostgreSQL-authoritative campaign admission with max_inflight=1	Planned / held
9	ys-yes-gn4m	Bind target-branch delivery to immutable planning inputs	Planned / held; mandatory replan first
Safety gate	ys-yes-ml7r	Build the deterministic AWS live-probe broker and lab guardrails	Off the serial path, but mandatory before any live probe

The Mayor’s current serial delivery order under the temporary one-root-at-a-time rule is yrzz → oqrc → zwk3 → keyd → ucwr → sefx → etn0 → ydq7 → replan → gn4m. This is an operating choice, not the dependency graph’s critical path.

The underlying DAG branches. yrzz unlocks both oqrc and zwk3; oqrc unlocks keyd and ucwr; sefx waits for yrzz, oqrc, zwk3, keyd, and ucwr; and etn0 waits for all six. From etn0, one branch proceeds through ydq7 to the required replan and gn4m. The separate ml7r branch waits for etn0, zwk3, and sefx, and remains mandatory before any live AWS test.

Authority and safety gates

• One root at a time. Until ys-yes-ydq7 lands, the operator approves at most one roadmap root and pins it to a dedicated runner with concurrency one.
• No ambient AWS authority. Coding agents, planners, and refinery gates do not receive AWS credentials.
• No guessed live identifiers. Account, Region, domain, VPC, KMS key, bucket, budget, approver, and cleanup owner remain deliberately unbound until a revisioned human approval package supplies them.
• No hidden branch switch. Initial contract work lands through the configured main refinery lane. A future integration branch may be created only after target identity is implemented and replanned against the then-current reviewed main SHA.
• No casual canary. The first live probe is synthetic, uses no provider credential, has no interactive shell-token authority, and runs in a separate lab account with an independent cleanup path.

What the roadmap can reuse today

The AWS successor roots begin from an already-running production factory, rather than from an empty architecture diagram. The reusable baseline includes:

• PostgreSQL-backed Lifecycle v2 notes and revisions;
• validator-backed plans and durable Bead trees;
• explicit dispatch arms and run records;
• factory events, runner lifecycle, and Refinery v2;
• repository onboarding and release promotion;
• current provider lanes and cost evidence.

Five records in the historical campaign produced useful prior art: ys-yes-7iex, ys-yes-uan9, ys-yes-bnnv, ys-yes-llvz, and ys-yes-kmpi. They cover the original control-plane contract, threat model, portability, yesod-client/yc, and product contract. They are inputs to the re-anchor, not proof of a live AWS deployment.

The retired ledger

The old roadmap:aws-hosted-yesod inventory now contains 50 terminal records: 5 done and 45 wontfix. The old 46-row page was therefore neither a current work queue nor an accurate status report. The re-anchor is recorded in ys-yes-8kom.

origin/aws-hosted-yesod remains frozen at 1ea1e99f. It must not be revived, merged forward, or treated as the source of a v2 branch. Successor work is tagged roadmap:aws-hosted-yesod-v2 and epoch:reanchor-2026-08-24, and it moves through note-level dependencies on the current production factory.

What proves progress next

The next meaningful milestone is not an AWS resource. It is the completed, reviewed, and refinery-landed contract re-anchor from ys-yes-yrzz. Only then does the schema re-diff begin. The sequence continues through offline adapter and compatibility proofs before any separately approved, brokered live AWS experiment.

This ordering is intentional: make authority and recovery precise first, make the adapter testable second, and spend money only when a bounded live probe can produce durable evidence and clean up after itself.