Roadmap

The Alpha proves the design on one Linux machine, with sample repositories and containers standing in for the agent platforms. What comes next runs the generated files on the platforms themselves, with real repositories, then leads to a first release, and after that to the parts a company would pay for. Durations are estimates, and what real repositories turn up could stretch them.

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, 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:

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, Redis 8 and Python installed with uv: all generated today, none yet run, because the Alpha’s machine couldn’t reach them. The same 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: Codex, Claude Code and Jules first.
5. Checks on every pull request. A GitHub Action that runs check on every pull request that touches the setup, runs verify when the spec changes, and comments with what broke.
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.

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. Every Alpha test and measurement run again, with every install path on an open network and behind a proxy
3 to 6	Each target on its platform with 20 real repositories, and the fixes they call for
5 to 8	Java, Ruby, Rust and MySQL. New targets where formats have settled
7 to 10	The GitHub Action. detect on 100 public repositories
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. 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.

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. Whether it is published openly is part of the license decision.
• 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 and verify 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.
• 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

• The license. It will be chosen before the first public release. The plan is a proprietary engine, with an open-source branch under consideration. Whether the spec format is published openly is part of the same decision.
• 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.
• 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.