Core Principle

Orchestratable Flow

The whole change lifecycle is a declarative state machine. One authorization — openlogos next --auto — and an AI driver runs it end to end, pausing only at the hard safety line.

The engine
STATE MACHINE

A flow you can derive, not a script you run

The engine models the whole change lifecycle as subflow → node → gate → loop. It is the single source of truth: status, next and watch passively derive the current frontier from the template — the engine keeps no state of its own. A project overlay can extends: builtin:launched and only write the diffs.

1 plan — the change proposal
2 spec — spec deltas
3 merge — merge deltas into the docs
4 slice — plan the [code] slices
5 implement — the slice loop ↻
6 deliver — verify / deploy / smoke
7 close — archive & push
openlogos flow show --resolved renders the exact orchestration after overlays
Each stage exits through a gate
Authorization
GATES

Two tiers: human checkpoints vs. standing authorization

Every subflow exits through a gate (type: human or none, with skippable: true|false). How gates behave depends on the tier you chose for this run.

Behaviour

  • Semi-auto (default) — merge, verify, deploy, smoke, archive and push stay human confirmation points.
  • Full-auto (--auto) — a standing, run-scoped authorization for the whole chain.
  • Auto-passes skippable gates; auto-runs verify / smoke / archive / push once the code is green.
  • Every auto-pass appends one line to a GATE_AUTO_PASSED audit trail (audit, not state).
Semi-auto is the default. Full-auto is opt-in, one authorization per run.
The one gate automation can never skip
Safety base
HARD RED LINE

The implement loop never ships untested code

After merge, slice-planner divides the merged spec into well-formed [code] slices. The implement stage then loops until the objective signal is met.

↻ Loop until code_slices_green (all slices done ∧ last run's tests pass)
30 The loop has an iteration ceiling (max_iters)
! Hitting it unresolved escalates to a non-skippable loop-exhausted gate
No mode — not even --auto — ever auto-passes code that did not pass tests

Isn't full-auto dangerous?

The safety base is a hard red line: the loop-exhausted gate is non-skippable in every mode, so full-auto never releases code that failed its tests. Beyond that, --auto only auto-passes gates you explicitly marked skippable, and every pass is recorded in an append-only GATE_AUTO_PASSED audit trail.

How is this different from a CI pipeline?

CI runs after you have written the code. The flow orchestrates the whole change — proposal, spec deltas, slicing, implementation, verification, delivery — as one derivable state machine. Because state is derived, not stored, status / next / watch always agree on the single next action, and an AI driver can execute it unattended.

See the flow in your project

Run openlogos flow show --resolved to render the orchestration, or openlogos watch to stream live state.

flow show Next: Flow Spec →