The Factory and models

The Factory turns an issue into a pull request. A coding agent builds the change on its own branch in a sandbox, and the change is not ready until CI and a second agent have both passed that exact commit. Then a person merges. This chapter shows what you can try today, what a real factory needs, and where the models behind all of this come from.

Try the Factory on fake tickets

$ git clone https://github.com/lumbridge-corp/lumbridge-factory
$ cd lumbridge-factory
$ python3 -m unittest discover -s tests
$ bin/factory2 --db scratch.sqlite3 demo
$ bin/factory2 --db scratch.sqlite3 status
$ bin/factory2 --db scratch.sqlite3 tickets --all
$ bin/factory2 --db scratch.sqlite3 --json status

What a real factory needs

• A Gitea code host with Gitea Actions for CI. Gitea is the only code host today. GitHub is not supported.
• Server-side rules on that host: a pre-receive hook that lets the factory’s bot push only factory/* branches, and a branch rule on main whose merge list is people.
• A policy file, factoryd.json. It names who may ask for work, each repository with its required checks and CI runner, data rules, slots and budgets. factoryd refuses to start while a part is undecided.
• Two daemons under separate Unix users. factoryd decides: it polls the code host, makes tickets, reads the gates and posts comments. agentd runs the agent turns in a git worktree per ticket and holds no code host token.
• A coding agent with its own account. Claude Code is the one that runs today, headless, one process per turn.

$ python3 -m factory2.agentd --config /etc/factory2/acme/agentd.json
$ python3 -m factory2.factoryd --config /etc/factory2/acme/factoryd.json
$ export FACTORY2_DB=/var/lib/acme-control/factory.sqlite3
$ factory2 policy add-repo acme/api --runner acme-ci --check "CI / checks (pull_request)"
$ factory2 policy allow gitea dana
$ factory2 policy slots 2
$ factory2 status
$ factory2 show t-ccd41800
$ factory2 hold t-ccd41800 --release

What gates a change, and who merges

1. AskA person on the policy’s allowed list labels an issue factory or comments /factory. Text from anyone else is recorded and never acted on.
2. CIEvery required check must be green on the head commit of the pull request.
3. ReviewA separate reviewer session, in a read-only worktree pinned to that commit, must pass it. Findings and red checks go back to the same builder session.
4. Current mainThe branch must contain today’s main. A new commit starts the gates again.
5. MergeA person merges. The bot cannot push to main or merge, and agents never do.

Models

Every part that calls a model takes an OpenAI-compatible endpoint: a base URL and a model name in its own config file. Notes reads [ai] url, and Mail reads [ai] base_url with place set to local or hosted. You have two ways to provide that endpoint. Use Lumbridge 1, the model we host; see /models. Or serve open models on your own GPU box with Lumbridge Computer, which puts every model you run behind one address.

$ git clone https://github.com/lumbridge-corp/lumbridge-computer
$ cd lumbridge-computer
$ cargo build --locked --release
$ export LUMBRIDGE_COMPUTER_ROOT=examples/demo
$ ./target/release/lumbridge-computer scene ls
$ ./target/release/lumbridge-computer scene activate two --dry-run
$ ./target/release/lumbridge-computer scene activate two
$ ./target/release/lumbridge-computer status --json
# on gpu-box, with your own registry and scenes:
$ lumbridge-computer agent --listen 0.0.0.0:8011 --upstream 127.0.0.1:8001 --floor 3
$ curl http://gpu-box:8011/v1/models

That is the whole stack: terminals that stay, a workspace over them, agents that report and wait, more machines, your notes, library and mail, speech, a factory and models. Each product page lists what is not built yet, and it is the place to check before you depend on a part.