The getting-started journey in Cadora: write a topology of nodes wired by dependencies and gates, launch it past the preflight trust banner, watch the run execute in dependency-order waves, see a deterministic gate hold a node honest, and finish with a sealed evidence pack you can prove.

Cadora · run a gated workflow

Ship agent-built software you can prove

Cadora drives a coding agent through a topology — a graph of nodes, each with a role and a prompt, wired by dependencies. After every node a deterministic gate re-runs the real build and tests, and the whole run is archived as evidence. This is the journey from a YAML file to a sealed pack.

Surface · terminal + local dashboardRole · operator / authorPath · topology → gates → evidence
01

Write a topology

A topology is a DAG of nodes. Each node names a role and a prompt; depends_on wires the order; and a gate names the deterministic check that must pass before the run moves on. Cadora topo-sorts the graph into dependency waves.

build-a-service.topology.yaml
name: build-a-service gates: spec-check: { cmd: "test -f aidlc-docs/requirements.md", setup: off } build-test: { cmd: "ruff check . && pytest -q", setup: auto } nodes: - id: requirements # wave 1 role: analyst prompt: "Read vision.md, write the requirements." gate: spec-check - id: design # wave 2 role: architect depends_on: [requirements] prompt: "Turn the requirements into a component design." gate: spec-check - id: construction # wave 3 role: engineer depends_on: [design] prompt: "Generate the code and tests; run the suite until green." gate: build-test

A node can also carry review: true to pause for a human — that is the human-in-the-loop journey. Here every gate is deterministic: a shell command Cadora re-runs itself.

02

Launch — past the trust gate

You point Cadora at the topology, an executor (the agent CLI), and a vision. Because the agent runs autonomously with --dangerously-skip-permissions inside your --cwd, Cadora prints a blast-radius banner first and asks once before it starts.

zsh — cadora run
$ cadora run build-a-service.topology.yaml \ --executor claude --model claude-opus-4-8 \ --vision vision.md --cwd ./demo

In automation there is no one to answer, so --yes (or CADORA_ASSUME_YES=1) prints the banner for the record and proceeds. A piped, TTY-less run does the same — the banner is the audit trail, and CI is never blocked.

03

The run executes, wave by wave

Each node runs in dependency order. Cadora announces the node, streams a heartbeat while the agent works, then — the moment the agent claims done — runs the gate and the toolchain-integrity check itself and prints the verdict. The agent's own "ok" never decides the line.

zsh — cadora run
cadora · executor=claude · funding=subscription · run=build-a-service-20260717-0904 requirements · claude-opus-4-8 · running… (generating documents; this can take a few minutes) requirements $0.3100 gate:spec-check ok integrity:ok design · claude-opus-4-8 · running… design $0.4600 gate:spec-check ok integrity:ok construction · claude-opus-4-8 · running… construction $1.2700 gate:build-test ok integrity:ok run complete -> runs/build-a-service-20260717-0904

Independent nodes in the same wave can run concurrently with --max-parallel N — only the agent sessions overlap; gates, integrity, and archiving stay sequential and deterministic.

04

Watch it live

In another terminal, cadora dashboard serves the same archive. The run detail page is a DAG canvas: each node is a cost-and-quality map carrying its cost, context tokens, and badges for its gate, integrity, and review outcomes — so a bad gate shows up right on the node.

127.0.0.1:8765/runs/build-a-service-20260717-0904
build-a-serviceclaude · 3 nodes · $0.7700 so far
running
completed
requirements
analyst
gate okintegrity ok
$0.3100ctx 22.4k
running
design
architect
$0.4600ctx 31.8k
idle
construction
engineer
ctx —

The dashboard is a read-only cockpit over the run archive — no login, no database, loopback by default. A FinOps panel breaks the same cost down by model, executor, and funding.

05

A gate holds it honest

Green means proven, not claimed. When a node's gate does not truly pass, the run stops there — fail-closed. Here construction exited zero, but the suite ran no tests: the gate reports VACUOUS and refuses to certify it.

zsh — cadora run
construction · claude-opus-4-8 · running… construction $1.0200 gate:build-test VACUOUS integrity:ok collected 0 items — a suite that runs zero tests verified nothing stopped at node 'construction': gate 'build-test' blocked -> runs/build-a-service-20260717-0912

The status vocabulary is precise: failed (a real defect), vacuous (ran nothing), packaging_failed (declares a package that will not build), and blocked_prerequisite (external tooling missing — not the agent's to fix). Add --remediate N and a remediable status drives a fresh, constrained session, then the same gate re-runs to decide green.

06

The run is proven

Every gate cleared, the run finishes and its evidence pack is sealed. The DAG reads at a glance — three green nodes, each stamped with its gate and integrity outcome — and the archive records exactly which command ran, what it printed, and what it cost, node by node.

127.0.0.1:8765/runs/build-a-service-20260717-0904
build-a-serviceclaude · 3 nodes · $2.0400 · sealed
completed
completed
requirements
analyst
gate okintegrity ok
$0.3100ctx 22.4k
completed
design
architect
gate okintegrity ok
$0.4600ctx 31.8k
completed
construction
engineer
gate okintegrity ok
$1.2700ctx 58.1k
report.htmlSEALEDopen
report.jsonSEALEDopen
checksums.txtSHA-256open

Off the archive you can run cadora report for a portable pack, cadora eval for the deterministic checks, or cadora compare to diff the same topology run on a second backend.

The screens above reproduce the live Cadora terminal and dashboard exactly — rendered as editable HTML rather than raster captures, so they can be lifted into Figma or iterated directly. Every gate is deterministic and fail-closed, every run is archived, and "green" is a fact Cadora observed and kept — not a sentence the model emitted.