The orchestrator leaves home: from a workflow welded into one repo to a binary you install¶
Every post in this series so far has described a way of working that lived inside exactly one repository. You read the docs in the workflow docs. You ran the project dev wrapper. The orchestrator that turned tickets into reviewed code was the workflow subsystem subsystem, and it existed here, welded into this one board-game project. If you wanted the loop from From an idea in a chat window to a repo the robot can build or Tickets in, a game I can play out, the unspoken catch was: you would have to rebuild all that scaffolding yourself, by hand, in your own repo.
That is no longer the whole story. The orchestration layer has been pulled out of this repo and turned into its own thing: tempo, a standalone Go binary with its own release pipeline and a bootstrap command that drops the same way of working into a fresh project. The interesting claim -- the one that matters if you are learning to build this way -- is that the loop the earlier posts described is not bespoke to one repo. It is packaged. You install one binary and point it at your own project.
This post grounds that claim in the real the Tempo implementation tree so it reads as a thing that exists, not an aspiration. I will walk the three moves that turn a welded-in workflow into an installable tool -- it is built as a product, it scaffolds your project, and you adopt it -- and then, as always, I will tell you where the seams still show, because they do.
It is built as a product, not swapped in as an internal part¶
The first thing that has to be true for "you can install this" to mean anything is that there is something to install. Not a directory you copy. A built, versioned, downloadable artifact.
tempo has that, and the machinery is worth naming because it is the difference between "I refactored some scripts" and "I shipped a tool." The build is described by the Tempo implementation: it compiles cross-platform binaries for Linux, macOS, and Windows across amd64 and arm64 (Windows arm64 is deliberately skipped), with CGO_ENABLED=0 so each binary is a single static file with no C-library dependency to chase on the target machine. The same config has an sboms: block that emits a software bill of materials -- an SPDX document listing what went into each archive -- alongside every release. That is the kind of supply-chain hygiene you expect from a real distributable, and it is in the config, not on a wishlist.
None of that builds itself. Releasing is wired up in .github/workflows/tempo-release.yml. It triggers only on tags shaped like tempo-v* -- push tempo-v0.1.0, and GitHub Actions checks out the repo, pins the Go toolchain from the Tempo implementation, validates that the tag really looks like a semantic version, and runs GoReleaser to build the archives, write checksums.txt, and attach the SBOMs to a GitHub Release. The tempo-v* prefix is chosen on purpose: ordinary board-game commits and pull requests do not match it, so giving tempo a release pipeline does not turn the rest of the project's CI into a publisher. Release state lives on its own tag namespace.
Then there is the part a new user actually touches. the Tempo installer is a curl-pipe installer in the familiar shape. It reads uname to figure out your OS and CPU, builds the matching archive name (tempo_<version>_<os>_<arch>.tar.gz, or a .zip on Windows), downloads it from the GitHub releases URL, and drops the tempo binary into ~/.local/bin. You can point it at a fork with TEMPO_RELEASE_BASE_URL, pick a version with TEMPO_VERSION, choose the destination with TEMPO_INSTALL_DIR, or pass TEMPO_INSTALL_DRY_RUN=1 to just print the URL it would fetch without downloading anything. It is small, it is honest about what it does, and it matches the archive names GoReleaser actually produces -- the installer and the release config are two ends of one contract.
There is one more detail that makes the "single binary" claim more impressive than it sounds, and it is the kind of thing only this project would do. The orchestrator's smarter analysis -- the codemap engine that annotates code, scores risk, and maps tests to capabilities -- is written in Python, not Go. Rather than make you install a Python project on the side, tempo embeds the Python engine inside the Go binary and extracts it at runtime. Per the Tempo design memo, an installed tempo unpacks its bundled engine, requirements, and default assets into a managed cache directory and provisions a virtualenv there; the host only needs a python3 on PATH to serve as the base interpreter. So you get one self-contained Go binary to download, and it still runs a real Python engine under the hood. The two languages are an implementation detail you never have to manage.
tempo bootstrap scaffolds your project, not this one¶
A built binary that only worked on this repo would be a curiosity. The move that makes it a tool is bootstrap: the command that takes everything the earlier posts described as "stuff that exists in this repo" and writes it into a different project.
Per the Tempo design memo, pointing bootstrap at a fresh project writes three kinds of starting material into it:
- A workflow config. It writes the review configuration, the same kind of config file that tells the orchestrator which checks to run and where things live -- the file this very repo uses to drive review preflight.
- Codemap defaults. It drops a tempo-owned vocabulary, weights, and config under the codemap subsystem, plus an annotation-convention doc at
docs/CODE_ANNOTATION.md. These are not invented per project; they come from the defaultstempocarries embedded under the Tempo implementation and the Tempo implementation, and the loader checks that the bootstrapped copy is internally consistent before anything depends on it. - The vendored contracts. It writes the workflow's own documentation under the workflow docs -- the ticket-authoring contract, the run-record format, the batch-authoring guide, the data-shape reference. The embedded copies live under the workflow docs, so a bootstrapped project carries its own copy of the rules and does not have to reach back into this repository to know how a ticket is shaped or how a run record is written.
Read that list against the on-ramp post and the symmetry is the point. From an idea in a chat window to a repo the robot can build walked you, by hand, through standing up exactly these surfaces -- a config, the docs the AI reads, the ticket-and-run-record discipline. bootstrap is that on-ramp compressed into one command. The orchestrator stops being a one-off baked into a board-game repo and becomes a generic starting point you can lay over a project that has nothing to do with board games at all.
The payoff: you could actually adopt this¶
Here is why those two moves matter together, for the reader this series is written for.
If you are new to AI-assisted development, the honest risk in reading posts like this one is that you come away thinking you have just toured someone else's bespoke setup -- a clever rig that one person built for one project, admirable but unreachable. That is the framing this post exists to break. The build pipeline means the way of working is a downloadable artifact. The bootstrap command means it is a portable one. Put them together and the path from "I read about this loop" to "I am running this loop on my own code" is two steps: install the binary, bootstrap your project.
The concrete command lives in the private project wrapper for this workflow.
(The first line is the curl-pipe installer; the editor will swap in the public release URL at publish time. The second writes the config, codemap defaults, and vendored contracts into the current project.)
You do not have to copy this repo. You do not have to reverse-engineer the scaffolding from blog posts. The thing the earlier posts taught you to recognize is now a thing you can acquire. That is the whole reason the orchestrator was worth extracting: a loop that lives in one repo helps one project; a loop you can install helps anyone willing to run two commands.
If you want to know what you would be adopting once it is in place, the rest of this series is the manual. The builder's-eye view -- tickets in, reviewed code out, run the app, feedback becomes the next tickets -- is Tickets in, a game I can play out. The machine internals that bootstrap is seeding into your project are opened up in the deep-dive pair, The orchestration lifecycle: from phase to ticket to retro and Review surfaces and the AI-first guardrails. This post is about how that machine became something you can carry to a new project; those posts are about what it does once it gets there.
The honest edges¶
I would be selling you something if I stopped at "two commands and you are done," so here is where the seams still show -- and with a distributable tool, the seams are mostly about ownership, which is harder than building.
tempo is a scaffold, not a finished orchestrator. Be clear-eyed about what exists today. the Tempo design memo says so plainly: this first version proves it can provision its own toolchain, build cross-platform, embed and run the Python engine, and bootstrap a project -- but it does not yet port the full ticket / phase / review / ship / merge lifecycle that the live workflow runs through the orchestrator dispatcher. The README's own parity check exists precisely to list which lifecycle surfaces are still uncovered, so a future cutover happens deliberately instead of by mistaking a partial port for a complete one. The release pipeline and the bootstrap command are real; the claim that you can run your entire build loop through the installed binary today is not yet true. The packaging arrived before the full port did.
A distributed tool needs a maintenance model this project has only partly built. The moment you ship a binary that other people install, you have signed up for obligations a single in-repo workflow never had. The embedded Python engine has to be versioned against the Go binary that carries it -- ship a binary whose bundled engine has drifted from its requirements and you have a self-contained tool that is self-contained around the wrong thing. The vendored contracts that bootstrap writes are copies; when the authoring rules evolve in the source repo, every bootstrapped project is now carrying a snapshot that can fall behind, and nothing yet pulls those forward. And the installs themselves are invisible: a curl-pipe installer means people are running tempo on machines and projects you will never see, which is the entire promise of an installable tool and also the entire support burden of one. The README is candid that native package-manager channels like Homebrew and Scoop are deferred for exactly this reason -- each one needs its own ownership and token boundary before it is safe to publish through.
"Portable" is not the same as "zero-config." bootstrap writes generic web-project defaults: a starter vocabulary, a starter config, a starter set of contracts. They are a starting point, not a finished fit. Your project's real check suite, your real review gates, your real notion of what "done" means still have to be authored on top of what bootstrap lays down -- the same way this project's the review configuration is far more specific than any default could be. The binary gets you to the on-ramp fast. It does not drive the car.
None of these are reasons not to extract the orchestrator -- they are the shape of the deal you take on the moment a workflow stops being a private arrangement and becomes a product. You are trading "it only works here, but it fully works" for "it works anywhere, but the port and the ownership model are still being built." For a way of working this series spent five posts arguing is worth adopting, making it adoptable at all is the necessary first move. Being honest that the move is half-finished is the second.
That is the arc this post traces: the loop you read about was welded into one repo, and now it is a binary with a release pipeline, an SBOM, a curl-pipe installer, an embedded engine, and a bootstrap command that writes the same scaffolding into a project of your own. The earlier posts taught you to want this way of working. This one is about the moment it stopped being something you had to rebuild from scratch and started being something you could install.
If you have not seen what you would actually be installing, start with the builder's-eye loop in Tickets in, a game I can play out and the on-ramp it closes, From an idea in a chat window to a repo the robot can build. Then, when you want to look under the hood of the machine tempo bootstrap drops into your project, the deep-dive pair is waiting.
Or: subscribe to follow the port from scaffold to full orchestrator as the lifecycle verbs land in tempo.