Bondsmith

A generic workflow engine in Rust - development workflow enforced in typed code.

MVP · 7 of 10 shippedRoadmap ↓

From the blog:Bondsmith: Hard Bonds for Soft Claims

aderustdioxus

Capabilities

  • Generic Flows, fitting your specialized needs

    A Flow is plain data: the ordered Phases a Feature moves through, read from disk at run time. Bondsmith runs whichever Flow a Feature is bound to.

    In the Flow editor, the feature Flow's Phases are opened one after another. The implement Phase lists its Steps in order, each marked as a Gate or a headless Worker, with its entry and exit checks beside them.

  • Steered from the terminal

    flowctl drives every run, one Phase at a time. Nothing advances until every Postcondition holds.

    flowctl implement --step -v runs the test Gate for Task T2: 41 tests pass, the count is captured as the baseline, and the Beat advances.

  • Observable from every angle

    The Bondsmith UI shows each run live: the Phase a Feature is in, the Beat in flight, and the Task graph across every bound repo.

    The checkout-discounts Feature in its implement Phase: the make_green Beat for the total-line Task finishes, a lint Gate runs and passes and adds its green mark to the Task graph, and the review Beat starts.

  • Agent runs under control

    Each Worker is a disposable Claude Code session spawned for one Step. Its Session transcript streams live: every file read, edit and test run.

    The Beat overlay for the total-line Task's make_green Step: the Worker reads the failing test, edits CartTotals, sees a test run fail, fixes the guard and runs the tests again.

  • No LLM grades its own homework

    A Postcondition either passes or hard-blocks the Beat. There is no softer outcome and no assert-and-warn escape hatch.

Roadmap

  1. Shipped: Generic Flow engine: any Flow, each Phase a typed contract
  2. Shipped: Typed Postconditions, hard-blocked on failure
  3. Shipped: Flows read from disk at run time, editable without a rebuild
  4. Shipped: Bondsmith UI: a live, read-only Feature inspector and Flow editor
  5. Shipped: Session log and live Session transcript for every Worker Beat
  6. Shipped: Triage rules: decide a Review unit without the human
  7. Shipped: Multi-repo Checkouts, one clone per bound repo
  8. In progress: learn-from-reports: mining Findings into the Knowledge base
  9. Planned: Bondsmith host: Bondsmith in a dev container on a remote host
  10. Planned: Worker containers: each Worker sandboxed in its own container

MVP · 7 of 10 shipped

After MVP

  1. Planned: Bondsmith UI write actions: drive a run from the UI
  2. Planned: Task loop: run the Task graph to done, unattended
  3. Planned: Notifications: alert the human when a run is waiting on them, blocked or done
  4. Planned: Model routing: choose each Worker's model per Step
  5. Planned: Step cost statistics across runs
  6. Planned: Session log analysis: mining past Worker sessions
  7. Planned: Cloud Workers: Workers run on remote machines
  8. Planned: Pi target

Bondsmith is the workflow engine I run my own feature work through: a Rust CLI that drives a Feature through a Flow of Phases, from exploration to shipped code, and refuses to advance when the work doesn't hold up.

The premise is that an LLM is non-deterministic by construction, so the answer isn't to trust it harder. It's to make everything around it deterministic. A Feature moves through the Phases of the Flow it is bound to, each one a typed contract with Postconditions the engine evaluates itself, in Rust. No LLM grades its own homework: a failed Postcondition is a hard block.