Step

A step is one program that does one job on the run's worktree.

What it isCopy Anchor Link

A step is one program that does one job on the run's worktree. It might check the spec, implement the change, review the diff, run your Verification commands, or write the delivery commit. The pipeline is those jobs in order. A step does not own the product; it owns one kind of work.

Built-in steps are the defaults. A new factory already has names such as spec-check, build, review, verify, and deliver. You keep them, drop them, or point the same slot at something else. Any step can be your own: a program you write, listed in kusaw.yaml next to the built-ins. To the pipeline a built-in and a program you added look the same. One job, one result, then the next step.

The step runs in a copy of the repo for that run, not in your checkout. If it edits files, it edits the copy. If it fails, the copy still holds what it did, and a later try or a person can look.

What you seeCopy Anchor Link

In kusaw.yaml you see a list of named steps and then a pipeline that refers to those names. On a run in the Dashboard you see the same names as stations: which step is running, which passed, which failed, which was skipped. Logs and artifacts for a step are part of the run's evidence.

A built-in verify step runs the commands from the task's Verification section. A built-in deliver step writes the local commit and SUMMARY.md. Review looks at the diff. You do not have to know how those programs are packaged. You see their names, their output, and whether they passed.

A step you write is still a name in that list. You point the factory at the program. You see it on the run the same way as a built-in. Custom steps, as a guide, are their own section of these docs when that guide is published; until then, treat a step you add as one more named job in the pipeline.

Retries are per step. If a step fails and still has tries left, you see another attempt of that same job, not a new run. That is separate from a pipeline loop, which repeats a group of steps as another try.

What you decideCopy Anchor Link

You decide which jobs exist in this factory and which of them a run should hit. You decide whether a built-in is enough or whether a job has to be yours — a security check, a generator, a deploy preview, anything the pipeline should run the same way every time.

You decide how long a step may run and whether a failure should be retried. You decide nothing about the worktree layout: the step is given the copy, and it should leave your checkout alone. You decide whether a step is interactive (intake, at your terminal) or unattended (the pipeline).

You decide the pipeline shape. After a step has a result, the next job on that path can run.

Where to go nextCopy Anchor Link

Meet a step in kusaw.yaml under steps, on the run detail page as a named station, and in the CLI as the same names on status output.

• Pipeline — how steps are ordered, grouped, and repeated
• Evidence — logs and artifacts a step leaves
• Recipes — optional overlays that change which steps run
• kusaw.yaml — how a step is named