[beshrkayali]

You framed it better than I would. The part I'm still working through is making re-planning feel cheap when specs change. Right now if you change something early, downstream tasks get invalidated and the cascade isn't always obvious. Ideally when the project gets built, and then specs change, nothing of the generated code should change if an irrelevant part of the spec changed, this is a bit harder to do properly but I have some ideas.

I agree that, this is what makes it not waterfall. You're iterating on the spec and not backtracking from broken code. The spec is the "source code", replanning and rebuilding is just "recompiling".

[genxy]

I don't know what format your spec is in, but it should be graph for this very reason.

[beshrkayali]

Exactly, and it is a DAG (specs and tasks in the toml plan). Check the QOIzig example and its task graph if you’re curious!