Overview
Self-driving is the monitoring side of Coldtea's lifecycle. Once a day it watches a repository and the production signals you connect, then plans, files, and starts the work worth doing, so regressions and follow-ups get caught instead of piling up.
Self-driving is opt-in per repository. Do not assume it is active until the workspace shows a running delivery status for that project.
The daily loop
When self-driving is running for a repository, Coldtea repeats one loop each day in your timezone.
- A planner run starts in the morning.
- The planner sends out scouts to look for work worth doing.
- Scouts write proposals: things they found, each backed by real evidence.
- The planner reviews the proposals, removes duplicates, ranks what is left against a daily budget, and files the winners as tasks.
- Coldtea can start those tasks as cloud runs, supervised or not, depending on your settings.
- At the end of the day the planner writes a brief: what happened, what is next, and what is blocked.
The work self-driving starts runs as a cloud run, on a hosted machine rather than yours, so it proceeds whether or not your desktop is open. Open the task it filed to watch the run: each one shows a View session button, or Watch live while it is still going.
You read the brief, review any work that ran, and decide what ships. Coldtea does not merge agent-authored changes for you.
Where the work comes from
Scouts are how self-driving finds work. There are three of them, and each reads a different source:
- The diff scout reads recent changes to the repository.
- The slice scout reads one area of the codebase at a time.
- The signal scout reads the observability and deploy providers you have connected, such as errors, analytics, and deployments.
A separate codebase mapper keeps a picture of the repository up to date, so the scouts and planner know what the areas are and which ones matter. How it works covers all of this in detail.
Signals are optional but they sharpen it
The diff scout and slice scout only need the repository. The signal scout needs connected providers. Without any signals connected, self-driving still plans from the code, but it cannot see production errors, usage, or deploy state.
If you want the signal scout to have something to read, connect signals first. A focused signal, tied to a change and a window, is easier to act on than a general instruction to watch production.
What it is not
A filed task is a proposal with evidence, not a finished change. A started cloud run is agent work you still review. A quiet day is not proof that production is healthy: traffic may be low, or the right provider may not be connected.
Self-driving keeps the record so you can check it. Read the brief for the summary, open the tasks it filed, and review the diffs the way you would review any agent work.
Where to go next
- How it works for the planner run, the scouts, and the codebase mapper.
- Settings and permissions to set how much runs without you.
- Connect signals to give the signal scout something to read.