How It Works

This section explains what gateline is and why it holds together. It is the conceptual layer: the shape of a run, the structure that keeps a named human in charge of it, and the separation that keeps the whole pipeline independent of any one model vendor. Three pages, read in any order, though the first sets up the vocabulary the other two use.

Each page is written from the framework's own records (the design documents, the contracts, and real completed runs), and every falsifiable claim carries a source comment in the page markup. Where a capability is supported but only partly exercised, these pages say so rather than rounding up.

The pages

How a run works

A run is one change carried from a one-page brief to a merged branch by a chain of specialized agents. This page covers the four gates and the question each asks, the run directory as the entire pipeline state, state.yaml as its spine, the three run profiles and how they nest, the two-step new → arm creation seam and the draft pull request, the two terminal states a run can reach (done and closed), and the one gate-less exception: historian sweeps.

How gates keep a human in charge

The engine dispatches agents and meters spend, but it cannot sign a gate. This page covers that structural prohibition, the seven-rule co-writer contract that lets a human and the engine share one file safely, the commit grammar that distinguishes their voices, one-authority topology and the blessed checkout, approve-and-hold, round caps and the escalation path, and the trust ladder that makes autonomy something earned and measured.

How gateline stays vendor-neutral

No role knows which model executes it. This page covers the design principles and the two that carry the weight, the closed role roster, the registry as the only place model IDs live, adapters as artifacts that gateline render generates rather than anyone writes, with a narrow-never-widen permission rule, and the cross-vendor decorrelation gradient stated honestly across the three shipped adapters.

Where to go next

For the background knowledge these pages assume (git's object model, how two writers safely share one file, how a prose contract gets parsed), see Onboarding. For field-level detail on anything named here, see the Reference pages, and for the package interfaces themselves, the API documentation.