Open-Factory-Digital/openfactory-core

**An autonomous software factory.** It takes tickets from your board and returns reviewed pull
requests — planned, implemented, validated by *your* test suite, independently reviewed, and
merged under the policy you chose. Humans stop authorising every step and start evaluating
results; production stays behind a human gate, always.
It is **not a coding agent** — it orchestrates the ones you already use (Claude Code, Codex,
Kimi, OpenCode) behind one adapter contract. It is **not a SaaS** — it runs on your machines,
against your board, with your credentials, and no cloud account is required.
Why this one
- **Policies authorise, humans evaluate.** The manifest declares the merge policy, the quality
floor and the promotion chain; the factory refuses vacuous green — a project with no declared
test command is *held*, not "passed".
- **The box is proven before money is spent.** box prove runs your own setup: and
validate: inside the real sandbox before any ticket is picked up. A misconfigured
environment is a named finding, not a burned agent pass.
- **Every stall speaks.** A blocked job parks with executable options for a human; a silent
forever-wait is treated as the platform's own defect class.
- **Provider axes, not provider lock-in.** Tracker, board, forge, CI observer, notifier, coding
agent and sandbox are independent adapters — GitHub Issues + Projects, Jira, Azure DevOps
(work items → Azure Repos PRs, end to end), chosen per project in a registry.
- **An independent review, structurally.** The reviewer can run on a *different* engine from the
executor, so "you did not write this code" is true by construction.
- **Honest docs.** What does not work is written down (docs/STATUS.md)
before you decide anything.
Quickstart — one machine
The shortest path is your own repository and the coding agent you already pay for: **one
credential, no Docker, no account anywhere**. The factory branches from your repository, opens a
pull request in it, reviews the change and fast-forwards your base.
Prerequisites: git, Python 3.12+, and a coding agent on your PATH already signed in (claude,
codex, kimi or opencode).
openfactory serve serves the same thing in a browser at http://localhost:8787 — the Board, the
job, the pull request. The whole door is **docs/setup/one-machine.md**,
including what happens to your working tree when a merge lands.
Quickstart — with Docker, on a hosted forge
The other door: the compose stack, a real forge and a real board, several people watching the same
panel. **Two credentials are irreducible here** — the coding agent's
(CLAUDE_CODE_OAUTH_TOKEN from claude setup-token, or ANTHROPIC_API_KEY) and a forge
credential (a PAT to try things out, a GitHub App for real use). Docker is asked for at this hour,
not before.
**Docker. Only Docker.** No Python on the host, no sudo, one line:
| | |
|---|---|
| **read it first** | curl -fsSL https://openfactory.digital/install.sh -o install.sh && less install.sh && sh install.sh |
| **no script at all** | the four commands below |
> The worker mounts the host's Docker socket — that is how sandbox: container starts a box, and
> it is root-equivalent on the host. It is the same trade docker compose up has always made here.
> The installer sends nothing anywhere. There is no telemetry in this project.
Re-running the installer with --force is the upgrade path: it resolves the newest release, pulls
it, and restarts the stack. Every value in your .env.compose survives it, credentials included,
and only the pinned version moves. Your data lives in named volumes, which only --uninstall
removes.
**A specific version, or a release candidate.** --version installs that release instead of