Roadmap

The Alpha proves the design on one Linux machine, with sample repositories and containers standing in for the agent platforms. Since then Preconfig Doctor has joined the engine: it reads the log of a failed setup, names the cause and, when the cause is in the spec, writes the fix there. What comes next runs the generated files on the platforms themselves, with real repositories, and gives Doctor the platforms’ own failures to read. That leads to a first release, and after it to the parts a company would pay for. Durations are estimates, and what real repositories turn up could stretch them.

Two lanes. The engine: Alpha, done, two working engines, with detect, build, check and verify for five targets and doctor for failed setups; Beta, next, about 12 weeks to run every target on its own platform with real repositories, add Java, Ruby, Rust and MySQL, check every pull request and score Doctor on real failures; toward v1.0, 4 to 6 months of product work (estimate) for a published spec, a stable command line and pilots; v1.0, the first release, with the spec and the commands frozen. After v1.0, what companies would pay for: one view of every repository’s agent setup, drift alerts, failed-setup diagnosis, rules on what agent machines install, hosted checks and prebuilt machines.

Stage Status What it covers
Alpha Done detect, build, check and verify for five targets, with tests, measurements and a demo
Doctor Alpha Done doctor: a failed setup’s log read, its cause named and, when the cause is in the spec, the fix written there, with a holdout score, fixes proven on a clean machine and a demo
Beta Next Every target run on its own platform with real repositories, more runtimes, services and targets, checks on every pull request, Doctor on the platforms’ own failures, and four weeks with teams
Toward v1.0 Planned A published spec, a stable command line, a routine for keeping up with the platforms, pilots
v1.0 Planned A first release, with the spec format and the commands frozen
After v1.0 Planned A view of every repository’s agent setup, drift alerts, failed-setup diagnosis, install rules, hosted checks, prebuilt machines

The Beta: Real Repositories, Real Platforms

The Beta has two goals. The first is an engine ready for real use: every generated file run by the platform that reads it, more of what real projects need, Doctor proven on real failures, and every number from the Alpha measured again. The second is the demo for real: teams’ coding agents working every day on machines set up by Preconfiguration, for four weeks.

The Platforms

The Alpha checked each file against its platform’s format and ran the setup script in a container. The Beta runs each file where it is meant to run:

Platform What runs there Why this one
GitHub Copilot’s cloud agent The setup workflow, on pull requests and before real agent sessions The strictest rules, and the most silent failures
Cursor’s cloud agents The Dockerfile build, the install and the start commands A build on Cursor’s side, with its own schema
GitHub Codespaces and VS Code The dev container with its services The dev container standard, prebuilds included
A cloud virtual machine cloud-init at first boot, on Ubuntu 24.04 A real first boot, not a schema check
Claude Code’s cloud sessions The SessionStart hook from preconfig 0.2 Setup from the repository’s own settings file; its command has run in a cloud session
OpenAI Codex, Ona, Devin Preconfig 0.2’s Codex settings, Ona’s tasks and dev container, Devin’s blueprint Three different models: settings only, a dev container, a snapshot built from a blueprint
Google Jules The setup script, from its environment settings The agents that take a script
A Mac and a Windows PC The engine’s commands, and verify with Docker Desktop Their binaries compile but have never run

Work Packages

  1. The platforms themselves. Each target run on its platform with 20 real repositories across Python, Node.js and Go, each setup also verified on a clean machine. Every difference between the platform and verify is explained or fixed, and the logs are kept.
  2. Every install path. Node.js from NodeSource, Go’s toolchains, PostgreSQL from the PostgreSQL project’s archive and Redis 8: all generated today, none yet run, because the Alpha’s machine couldn’t reach them. Python installed with uv has since run: Python 3.13 reached READY in 85.3 seconds on September 30. Then every path on a network behind a company proxy, with mirrors for Ubuntu, PyPI and npm.
  3. More of what projects need. Java, Ruby and Rust as runtimes; MySQL as a service; private package sources. Each one on every target, with verify.
  4. More targets. Agents keep adding ways to read setup from the repository. The Beta tracks them and adds a target when a format settles. Preconfig 0.2 added Claude Code, Codex, Ona and Devin; Jules is next.
  5. Checks on every pull request. Started in preconfig 0.3: a GitHub Action runs check on every pull request, marks each problem on its line, runs verify when the spec or the setup script changes, and puts Doctor’s cause in the job summary when verify fails. Still to come: a comment on the pull request itself, with Doctor’s change to the spec ready to apply.
  6. detect at scale. detect on 100 public repositories, each draft compared with a spec reviewed by a person, and the accuracy published.
  7. Keeping up. A routine that compares each platform’s documents and schemas with the knowledge base every week, and a changelog of the formats’ changes, with the date moved each time.
  8. Measurements again. Every Alpha figure, on the platforms and on more machines, plus the question the project most needs answered: how many minutes of setup, and how many failed sessions, a spec saves per agent session.
  9. Doctor on real failures. Every setup that fails during the Beta becomes a test for Doctor, scored against the cause found by hand. The three misses of its Alpha holdout come first, and its GitHub Actions and cloud-init readers meet real logs for the first time. Each round of rule changes ends with the rules frozen and fresh cases held back, so the score stays honest.

The Demo, for Real

Three to five teams run their coding agents on setups written by Preconfiguration for four weeks, on their own repositories. Their specs start as detect drafts and are reviewed by a person. The Beta counts what matters to a team: sessions that failed or stalled because of the setup, minutes of setup per session, how long writing and reviewing a spec takes, and how often a platform’s file broke without anyone noticing. The same teams are asked whether they would pay for the team features, and how much.

Timeline: About 12 Weeks

Weeks Work
1 to 2 The platforms set up and probed. Every Alpha test and measurement run again, with every install path on an open network and behind a proxy. Teams recruited
3 to 6 Each target on its platform with 20 real repositories, and the fixes they call for. Doctor reads every failed run
5 to 8 Java, Ruby, Rust and MySQL. New targets where formats have settled
7 to 10 The GitHub Action, with Doctor’s cause and fix in its comments. detect on 100 public repositories. Doctor’s rules frozen and a fresh holdout recorded
9 to 12 Four weeks with the teams, then the Beta release and a Beta report with every figure measured again

The Beta needs two people: a lead engineer, and a second engineer who knows CI and containers well. Doctor’s work adds about two person-weeks (an estimate), done beside the platform runs whose failures feed it. The platforms’ subscriptions for two people, a small cloud machine and CI minutes come to roughly $1,500 to $2,500 over the Beta (an estimate).

When the Beta Is Done

  1. Each of the five targets has run on its own platform for 20 real repositories, and every difference from verify is explained or fixed.
  2. Every install path in the spec has run on a clean machine, on an open network and behind a proxy.
  3. Java, Ruby, Rust and MySQL work on every target, proven with verify.
  4. Teams’ agents worked for four weeks on generated setups, with setup failures and setup minutes per session measured.
  5. The GitHub Action checks every pull request that touches the setup.
  6. Every Alpha figure measured again and published, and every planted bug, old and new, caught.
  7. Fuzzing runs every night with no open crash.
  8. Doctor has been scored on at least 50 real failed logs from the platforms, with every change it wrote proven and no wrong change in the last holdout.

Out of scope for the Beta: a hosted service, team features, machines other than Ubuntu as the base, Windows runners for Copilot, and GPU setups.

After the Beta: Toward v1.0

A first release should follow about 4 to 6 months after the Beta (estimate). Most of the work turns a tested engine into something a team can depend on:

  • A published spec. The preconfig.yaml format written down, with a schema that editors can use to complete and check it, open like the engine under the Apache License 2.0.
  • A stable command line. Commands, options, exit codes and the JSON output kept stable, so scripts and CI steps built on them keep working.
  • A routine for the platforms. The weekly comparison from the Beta, with every change to a platform’s format in a public changelog and a new engine version when one matters.
  • Pilots at companies running agents, on their own repositories.
  • v1.0 itself: from then on the spec format and the commands stay stable, and a spec written for v1.0 keeps building.

After v1.0: What Companies Would Pay For

The engine stays complete on its own: detect, build, check, verify and doctor will never need an account or a hosted service. What a company would pay for is coordination across many repositories and a faster start:

  • One view of every repository’s agent setup, with the platforms each one covers and whether it is proven.
  • Failed-setup diagnosis. Doctor on every failed agent setup across the company’s repositories: the cause, and when it lies in the spec, a fix that verify then proves.
  • Drift alerts when a repository’s files, or a platform’s format, move away from the spec.
  • Install rules. Which package sources and versions agent machines may use, enforced when a spec is checked.
  • Hosted checks. verify on every pull request, run for the team.
  • Prebuilt machines. Images built from each spec, so agent sessions skip the install and start in seconds.

Later: More Uses

Coding agents come first, but the same spec fits a new developer’s first day, CI jobs, evaluation harnesses that need hundreds of repositories set up the same way, preview environments, workshops and classrooms, and platforms that run other people’s agents. None of them is tested yet. The post on next uses looks at what each would need.

Open Questions

  • One format for everyone? If the platforms settle on one setup format, a compiler matters less, and checking and proving matter more. The Beta watches for it.
  • Agents that set themselves up. Some platforms’ own agents can already inspect a repository and write their environment. The Beta compares their setups with reviewed specs.
  • Doctor’s reach. How many real setup failures have a cause that lives in the spec, where Doctor can write the fix, and how many lie in the network, the repository or the code, where it can only explain.
  • Teams. The Beta’s repositories and teams are still to be found. The project would like to hear from teams who want to take part. See Contact.