Every new project starts with the same quiet anxiety: which folder shape, which lint rules, which CI stub, which auth story, and which “temporary” script becomes permanent? You tell yourself you will clean it up later, but later is where the real work lives — and the scaffolding debt compounds before the product even has a name.
Forge is how I front-load those decisions into something inspectable. Instead of a README wishlist, I keep a manifest graph: nodes for contracts, routes, content types, and integrations, with edges that say who depends on whom. The payoff is not documentation for its own sake — it is mechanical generation. The scaffold engine reads that graph and emits the boring, error-prone parts: directories, stubs, policy files, and cross-checks that would be tedious to keep aligned by hand.
On dimstack.net, the workout app, and a handful of LifeOS experiments, the loop looks the same: declare the shape, run the generator, then edit the human parts. When something moves — say a content schema change — the graph answers “who breaks?” before the compiler does. That is the difference between guessing blast radius and knowing it.
Concrete example: the workout app started as a handful of Flutter screens and an Isar cache, but the manifest already named Supabase sync, HealthKit boundaries, and the offline contract. Forge did not write the UI magic — it wrote the skeleton that kept those concerns from collapsing into one giant lib/ junk drawer.
Where this is headed: forge-denv pushes richer snapshots into Supabase so a public dashboard (and authenticated views) can show phase progress and graph health without opening a terminal. A small MCP registry sits on the same spine so editors and agents ask structured questions against the manifest instead of grepping blindly. Forge is not trying to replace your framework — it is trying to replace the part where you reinvent the same scaffolding decisions for the hundredth time.