FreeFlow

Concept design for exhaust headers. You give it two surfaces — where the runners start and where they have to end — and it routes tube between them, then tells you where it did badly.

A solver that refuses to be clever

The easy version of this optimises for packaging: shortest path, tightest bends, get it to fit. That version produces a header that fits beautifully and flows terribly, because a tube that fits is not the same as a tube gas wants to travel through.

So the priorities are stated up front, in the code, and the solver is not allowed to trade them away: bend radius safety and cross-section retention beat packaging. If the tidy route needs a bend that crushes the section, it doesn’t get the tidy route.

The part I’d defend hardest: it audits its own output rather than just emitting a path. It reports area retention through every bend and the spread of runner lengths across the set, because those two numbers are what separate a header that works from a header that merely exists. A solver that hands you a geometry and no verdict is a solver asking you to trust it, and there’s no reason to.

No dependencies. Not a flex — a constraint.

package.json has one script and it runs node --check. Sixteen files of vanilla ES modules: routing, math, preview, units, tuning, STEP intake.

That wasn’t minimalism for its own sake. It’s a tool that has to still run in five years, on whatever’s around, without a lockfile resurrection. Nothing here needs a framework and every dependency would have been a future problem in exchange for a present convenience.

The honest part

The STEP intake is half a feature. It parses reference faces and labels out of the file, and that’s it — the manual fields remain the source of truth for everything that matters. A real STEP kernel is a large piece of work, and the half that got built is the half that saved typing, not the half that reads geometry.

It’s marked as partial rather than quietly implied to be complete, which is the only defensible way to ship a stub.