x-dog / Blog

A workflow that runs unattended every four hours, points a coding Agent at a live site, and lets it push its own commits when a chain of deterministic checks admits them. Here is the scenario, the four design decisions that survived it, and the defects it found that no test suite had.

flow ran every workflow twice: once through the interpreter's readiness loop, once through a schedule the compiler baked into Python control flow. Two mechanisms, one invariant, and a parity suite holding them together. Here is what each engine did before, and what replaced both.

flow can now call a whole workflow as a single node. The interesting part isn't the feature — it's the design choice that made it cheap: don't expand the child. An opaque sub-workflow keeps the static graph static and makes interpret==compile stronger, not weaker.

flow's compile-to-Python guarantee is bought with a static graph. This is an honest tour of what that costs — numeric conditions, strict interpolation, and the one real capability gap: mapping a node over a runtime-sized list.

How the tui package repaints only what changed — staying in the main terminal buffer, no alternate screen — to build smooth, scrollback-friendly TUIs.

flow agents can call tools you declare in the workflow JSON via a module:func reference — loaded at run and generate time, then referenced by name like a built-in.

flow can run a workflow JSON directly or compile it to a standalone Python module. Here is why codegen matters and what the generated code looks like.

How flow moves data between nodes through named ports and explicit edge mappings instead of a shared global dict — and why that makes pipelines easier to reason about.