Modes

Modes

maintain runs in one of three modes. They share everything except who decides the next action. That shared path is the point: the sandbox, the manifest gates, the validation binding, readiness, and publication are identical, so the modes differ only in judgment, and the benchmarks can measure that difference.

baseline

No model. The pipeline selects the smallest eligible upgrade, applies it, normalizes manifests, validates the exact result, and freezes a proposal if readiness passes. It cannot edit source, so any upgrade that breaks the build ends as regressed, an honest non-result with no claim. Use it to see what a repository's upgrade would do with no repair, as a control in benchmarks, and as the floor the agents are measured against.

Selection order: patch before minor before major, then the first module in alphabetical order that has a target in that class, then the highest version of that module in that class. Only versions allowed by the policy and, unless -min-age 0, published at least -min-age ago (72 hours by default) are eligible.

With -select vulnerable the selection is different: baseline mode scans for known vulnerabilities and picks the lowest eligible upgrade that clears them, in a direct or an indirect dependency, then proposes it only if a second scan shows the advisory gone and nothing new. This is the only place a vulnerability influences what is upgraded: the scripted and model modes refuse the flag. Standard-library findings are reported but not fixed. See Vulnerabilities: Reporting and Fixing.

scripted

A declared list of tool calls is replayed through the runtime, the full tool set, and the policy. The decisions are fixed, so this proves the orchestration and control behaviour deterministically: that a write to a protected file is denied, that a scope crossing pauses for approval, that a proposal is frozen with the right files. It says nothing about a real model's judgment. Scenarios are embedded in the binary; -scenario S2 names one.

model

A model decides. Each step, the agent renders the run's recorded steps into a message list, asks the model through the runtime's accounting caller, and turns the first tool call in the reply into a decision. The runtime then validates the arguments, evaluates policy, and executes or refuses exactly as in the other modes. The rendering and the reply mapping are the runtime's render package; the facts, the prompt, the opening message, and the tool-result format are Repo Steward's.

A reply with no executable tool call, or one cut off by the per-call output cap, is recorded as an invalid decision: it costs a step, shows up in runs show and the event log, and the next request tells the model what was wrong and asks for exactly one tool call. Nothing partial is executed, and there is no second model call hidden inside one step.

The system prompt is fixed and never contains repository content. Files, dependency sources, and command output reach the model only inside tool results, each labelled as data. The model has no handle to the policy, the store, the network, or a shell.

Two providers are wired, both the runtime's own adapters: ollama:<model> for local models, and anthropic:<model> for paid measurements. Nothing in development, tests, or CI constructs the paid one; it refuses to run without a key, without a known price, and without a -max-cost-usd cap. That split is a decision, not a gap: the workflow is built against free models, and the paid model is an instrument for measuring the gap between them.

Recording and replay

-record DIR stores every model response keyed by the exact request. -replay DIR serves those responses and never calls the provider, which is how model mode runs in CI with the server pointed at a closed port. A recording is invalidated by any change to the system prompt, a tool's description or schema, or the shape of a tool result, because those are part of the request. Re-record after such changes. Moving the renderer into the runtime was not such a change: it reproduces the previous renderer byte for byte, and the committed recordings replay unchanged.

Choosing a mode

Goal	Mode
See whether an upgrade applies cleanly without any repair	baseline
Prove a control behaves as designed	scripted
Actually repair breakage	model
Measure a model	bench run -mode model