Greenfield S001: why the first session scaffolds a skeleton and zero modules

When you start a new project under FSE, the first session — S001 — builds the foundation files and scaffolds the solution. But it scaffolds a skeleton: the core projects, the host, the test projects, and the dependency wiring between them. It builds zero business modules. Not even an empty placeholder folder for the first one. That restraint is deliberate, and it's one of the cheapest insurance policies in the whole methodology.

What the skeleton actually is

The fixed structure: a shared-kernel project, a platform project, the host, and the test projects, with the dependency law wired between them — each project references only downstream, never up or across. That graph is an invariant. There's exactly one correct shape for it, so an automated first session can build it deterministically, command by command. No judgment required, no room to drift.

What's missing is just as deliberate: no modules. The modules folder doesn't even exist yet. It's born the day the first real module is.

Why no modules at S001

A business module is the opposite of the skeleton — it's the variable, judgment-laden, requirements-driven part of the system. And here's the trap: at hour zero, before any code exists, you don't actually know what your modules are. You have guesses. "I'll probably need Billing, Users, Reporting, Notifications…" That's a wishlist, not an architecture.

If S001 scaffolds modules from that wishlist, you get empty module shells built before anyone knows their real shape — and those shells become structural debt. They have folders, namespaces, maybe a DbContext, all asserting "a module goes here, in this form," before the requirement that would actually determine the form exists. You've committed to architecture you haven't earned yet.

This is the same failure pattern that the methodology's foundational lesson came from: filling a blank with a plausible guess and treating it as a decision. A speculative module list is exactly that, just at the structural level instead of the config level. The fix is the same: don't author it until it's real.

How modules are actually born

Each module gets scaffolded in its own session, when its requirements are real — when you actually know what it does, what its schema is, why it exists. It arrives with a reason, real schema, and a clean entry in the decision log. The module folder, its context boundary file, its DbContext — all created together, in the session that has the actual requirement in hand.

This isn't slower in any way that matters. You build modules exactly when you'd build them anyway — when you need them. S001 just doesn't pretend to know them in advance.

The one thing S001 does record about modules

There's a distinction worth making: S001 scaffolds no modules, but it can record a module naming taxonomy if the project has a predetermined one — a fixed scheme for what the module domains will be called. That's metadata about modules, not the modules themselves. It governs naming consistency across future module sessions without scaffolding anything. If no taxonomy is decided yet, that stays explicitly open — decided when the first module is.

Why the restraint is the point

A skeleton is safe to build deterministically because it has one correct form. Modules are unsafe to build speculatively because they have many possible forms and the right one depends on requirements that don't exist yet. S001 builds exactly the part that's knowable and refuses to guess the part that isn't. The empty modules folder that doesn't exist yet is a feature: it's the methodology declining to commit to architecture it hasn't earned.

Where it lives

The S001 skeleton discipline and the module activation threshold are part of FSE's structural rules in fse-core: github.com/Joticle/fse-core

If you've started a project by scaffolding modules you thought you'd need — and then watched them sit empty or get rebuilt once the real requirements showed up — that's a field report worth writing.