Guide 1

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-trigger deny. worker-compose.yaml pins 1.8.7. A ladder on 1.8.1 looks wired and enforces nothing.
  • shell::exec spawns a program and is not a shell. git add -A && git commit failed as a program name, and the commit silently never ran.
  • shell::exec returns 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.