froot is a robot teammate that keeps software projects tidy on its own. Below: what it does, and the through-line of a recent rework. Each picture has a Simple view (no background needed) and a Detailed view (the real workflows and code). Use the toggle on each.
froot watches a set of code repositories. On a schedule it wakes up and does one of two things: improve the code (open a fix, let it merge only if it's trusted and the tests pass) or review other people's open changes (leave a helpful comment, never touch anything).
Every box marked Workflow is a durable, replayable
Temporal workflow; every leaf is an @activity.defn (all the
I/O lives there). Edges read top-to-bottom in execution order — the labels
are the logic. Two families: acting loops propose a PR a gate merges
or reverts; advisory loops scan open PRs and upsert one decaying
comment.
The change in one line: froot used to keep many separate copies of "how each task works"; now every task is described once in a single shared catalog, and everything else looks it up.
The same know-how was repeated in many places.
Describe a task once; the rest just reads it.
The loop enum used to be a key every consumer
re-interpreted with its own per-loop branching, with the dashboard and
starter carrying twin copies per family. Now each loop self-registers one
LoopSpec (a disposition-tagged union), and the spine, the
dashboard, and a single starter all read the registry.
Per-loop knowledge copied across the spine, the dashboard (two near-identical families), and three starter modules.
One spec per loop; the disposition (commit-or-revert vs emit-signal) is derived from the tail's type. A new loop is a registration, not edits across the codebase.