What ghola does not do
Read this first. Every item below is something ghola does badly, or not at all, or only under conditions nobody wrote down until now. A tool with no stated failure mode reads like a sales page, and you would find these anyway.
None of it is a promise to fix. Some of it is on purpose.
Decisions, not gaps
No upgrade path. You clone this and it is yours. Nothing here tracks a version, and nothing will migrate you when the built-in pipeline changes. That is deliberate: a starter kit that owned your configuration would not be yours. Want a later change? Read the diff and take the parts you want.
No CLI. make is the whole operator surface. A
command you install goes stale. Every target here is four lines of shell, and
you can read all of them.
No HTTP surface. The iii console is the interface. A dashboard of ours would be a second thing to maintain, and a worse trace view than the one already running on port 3133.
Nothing merges itself. No configuration removes the pull request. Want a factory that lands its own work? Wrong starting point. The gate is not a setting, so there is nothing here to turn off.
ask never becomes allow. Not at
dark, not anywhere. An unattended factory that reads "ask" as
"yes" has answered a question nobody put. When a rule marked ask
refuses work you want, the rule is what to change.
Gaps, and how much they cost
One machine. The engine, the workers and the worktrees
share one box. ghola has no scheduler, no queue across hosts, and no way to run
two factories against one repository. Set concurrency = 1 in
repos.toml for any repository whose prepare command allocates a
port.
Cost reads $0.00. The router prices some
models at null, so session_cost_usd comes back zero. That means
the number in the job record and in the audit log is not one you can bill
anybody for. settings/pricing.yaml takes fallback prices. Nobody
has filled it in.
Two forges, and one of them is a file.
github and local ship. GitLab, Gitea and Bitbucket
are each a forges/<name>.py away. Nobody has written one.
The seam is real and tested, and a seam with one production driver behind it is
still a seam with one production driver behind it.
The local forge cannot tell you anything. A
file has no notifications, so ghola says nothing when it reads your comment or
finishes with the branch. You find out by looking.
A squash merge defeats the local forge. That
driver reads a merge as "the branch is an ancestor of the base", and a squash
leaves no ancestry. If you squash, set the status to closed in the
request file. Or use GitHub.
Evals cost money and nothing runs them for you.
make eval is manual on purpose. Nothing hooks it to a commit, to
CI, or to a schedule. A gate nobody can afford to run is a gate people learn to
skip. Run it before a prompt change.
The improve lane needs a record to read. On a fresh clone it has an empty audit log, so it finds nothing and says so. Give it a few weeks. It is useless on day one and it will tell you that.
Prompts are the least tested thing here.
prompts/*.md is the easiest file to change and the hardest to
check. Two evals discriminate. The other four phases have none, so a prompt
edit is the change with the weakest net under it.
Things that have gone wrong, and now cannot
Kept on purpose. A list of fixed bugs tells you what kind of system this is, and what to watch for in the parts nobody has exercised yet.
- Harness 1.8.1 ignored a
pre-triggerdeny.worker-compose.yamlpins 1.8.7. A ladder on 1.8.1 looks wired and enforces nothing. shell::execspawns a program and is not a shell.git add -A && git commitfailed as a program name, and the commit silently never ran.shell::execreturns a non-zero exit in the payload rather than raising. A refused commit read as a success and disabled the revision loop.- Two processes appended to the audit log. The chain failed its own verification while nothing had tampered with it. One worker owns it now, and every other worker asks that one.
- A turn ran with no filesystem scope and read the wrong repository's charter. Then it refused to edit anything, because the repository it could see was not the one its instructions described.
- The improve lane's request template quoted its own comment heading, and a job reworked itself against its own document.
Before you adopt this
If you have a working process and a team that follows it, this will not make it faster. What it does is make an unattended process auditable. It becomes worth something only once some part of your process already runs unattended.
I would keep one part of this: the ladder. Everything else is a pipeline you could write yourself. The rung is the idea.