Your pipeline is a program.

The compiler infers a type for every step, Step<A, E, R, O, G>: A is the value it returns, E its typed failure, R the services it needs, O its named outputs and G the grants it declares. Three of them decide where a step fits, so the drawing cuts them into the part. E and O go on its data plate.

site is a Nix build, and its value is the store path. deploy names it in needs, so its body gets that StorePath and hands it to publish in deploy.ts. It ships the exact build that the checks in after: [typecheck, test] gated.

Each place where two parts meet in the drawing is a check tsc makes on ci.ts. Below are the five, each with an edit to the example you can make, the section where the fit is decided, and what the compiler says.

Calder.plan(project, event) returns the steps an event runs, without running any of them. The rule that matches the event is the live rail; the parts its steps need come along, pulled in.

So a pipeline can have tests, like any other code. This one plans pull request #7 and checks that deploy isn't in it.

Calder reads the program, so it knows what each step reads. A task's key is the git tree ids of its inputs, the key of the setup it starts from, its dev shell and its command, plus its env, outputs and the values it interpolates. Git has hashed every file already, so a key needs no pass over the files.

When a key already has a passed result, from main, a pull request or a check before pushing, the step settles at once and says where the result came from. Vitest.files gives each test file a key of its own, from what it imports plus the root manifests and the lockfile. Calder reuses a Nix build when its derivation hasn't changed.

calder check runs the working copy, in jj or git, like a pull request. calder watch <dirs> does the same in the background for every jj workspace below those directories, once a workspace's snapshot has stayed the same for a while, 120 seconds by default. That suits several agents working at once.

Calder keeps their results by key like any other, so the pull request that follows finds them, and so does main after the merge.

Pnpm.install, Bun.install, Vitest.files and Project.standard, the whole standard pipeline in one call, come from @calder-ci/std. They are ordinary functions that return steps. Your own modules work the same way, like the example's deploy from .calder/deploy.ts.

Actions are Effect code with typed failures. Step.retry and Step.timeout are policies you pipe a step through, as in .pipe(Step.retry({ times: 2 })) on deploy.