yesod.work

Direction · a decision record

Where the factory
goes next.

These are initiatives, not tickets: higher-level commitments that may bundle zero, one, or many yesod notes — and are not always code. Some are content, some are design, one is a two-socket server in a laundry-room alcove. These sheets are living drawings: revised constantly as decisions land, with each sheet carrying its own revision log.

Init-01

AWS-Native Yesod

A durable Mayor with a software factory behind it — not a remote shell into Stephen's machine. Install yc, connect with a scoped credential, brainstorm locally, and let an AWS-hosted control plane own durable state, centralized planning, dispatch, execution, and recovery. Serverless-first: API Gateway + Lambda, Aurora Serverless v2, disposable Lambda MicroVMs; scale-to-zero by default.

What it takes

  • Freeze the v1 product and authority contract — one deployment, one tenant (design)
  • Portable Yesod distribution: explicit configuration, no host-specific defaults (code)
  • Serverless knowledge plane: API Gateway, Lambda, Aurora Serverless v2, private Dolt (code · operations)
  • yc client, users, and the local Codex Mayor experience (code · design)
  • Centralized Planner and leased Dispatcher; Lambda MicroVM workers (code)
  • Security hardening, threat model, and recovery drills before internet exposure (operations)

Revisions

  • Design record opened
  • Initiative published with the 46-note ledger and phase plan
  • Re-anchored successor roadmap entered execution
  • Vultr runner trial recorded the Beads/Dolt low-latency placement constraint
Init-02

Public Factory Explorer

Anyone should be able to open yesod.work and watch a real software factory run — the notes moving, the refinery deciding, the models earning their keep, and what it all costs.

What it takes

  • Live feed projector, built by the factory itself — sanitized snapshots pushed to live.yesod.work (code)
  • Live notes and refinery pages, model economics scoreboard, and per-model detail pages (code · design)
  • Station guides and editorial framing aligned with the book (content)
  • SigNoz as the canonical source for public aggregates (operations)

Landed so far

  • Live pages shipped with a labeled demo fallback; they flip to LIVE when the projector publishes
  • Model scoreboard with AI tier verdicts, plus twenty per-model detail pages
  • Whole-record statistics and spend, framed as one operator's real instance
  • Change log reproduced verbatim from the book's wave ledger

Revisions

  • Live pages, model scoreboard with AI verdicts, and per-model detail pages shipped
  • Projector feature request armed — the factory is building its own public window
  • Whole-record statistics and spend published; change log synced from the book
Init-03

Infrastructure Upgrade: the Verification Fabric

The new PowerEdge R740xd (44 cores, 256 GB ECC) is not a bigger test runner — it is a pool of disposable factory cells: isolated, production-shaped miniature Yesods with their own databases, Git remotes, and telemetry identities, for acceptance gates, incident replay, and fault injection. The cell architecture is an exploratory direction; the hardware is committed.

What it takes

  • Hardware build and commissioning — $2,496 committed, UPS, mirrored boot, placement (hardware)
  • Proxmox buildout and cell provisioning on the new fabric (operations · code)
  • External acceptance gates that outlive a coding agent's wall-clock (code)
  • Sanitized production-shaped snapshots for replay and fault injection (code · operations)

Landed so far

  • Hardware specified and purchased; build tracker maintained in the ROADMAP record
  • NVMe adapters and the CyberPower UPS in hand; boot SSDs and the server build still inbound

Revisions

  • R740xd base server paid; NVMe adapters ordered
  • Final configuration confirmed; UPS ordered; NAS drives released
  • Build tracker published
  • NVMe adapters and CyberPower UPS received
Init-04

Coder-Plan Aware Scheduling

Subscription coder plans — Codex, Claude, z.ai, Kimi — are prepaid capacity with their own windows and limits. The dispatcher should treat each plan as a schedulable resource and pack work to keep every plan maximally utilized before a single metered token is spent.

What it takes

  • Per-provider plan-usage telemetry: windows, limits, and remaining capacity (code)
  • Scheduling policies and dispatcher integration — plan-first routing with metered overflow (code · design)
  • A cost model that separates plan capacity from metered spend on every run (code)
  • Routing experiments to learn which work each plan absorbs best (research)

Revisions

  • Initiative drafted; awaiting its first feature-request notes
Project
Yesod Software Factory
Sheet
Roadmap · 4 initiatives
Revised
Aug 24, 2026
Drawn by
Stephen + the factory

The roadmap records intent, not a schedule; an initiative graduates by shipping, not by promising. Individual feature requests flow through the factory — watch them on the live floor.Graduated: deterministic refinery verification — see Wave 8 and the merge system.