0-to-1 is my whole thing, so I want the model to lay down a real repo I can take the wheel on, not one 600-line file I have to explode by hand.
What finally worked was treating the folder tree as a signed contract: it proposes the tree, I approve it, then it can only fill files that exist in the approved tree. When I skipped the approval gate it kept sneaking in a utils/helpers.ts grab-bag that became a dumping ground.
Curious how others structure the lib vs. server boundary so the model doesn't leak server-only code into client components.
Act as a senior engineer scaffolding a new repo. Work in two phases and STOP after phase 1 for my approval.
PHASE 1 (plan): Propose a complete folder tree for a {PROJECT_TYPE} app. Group by feature, not by type. For each top-level folder write one line on what belongs there and, critically, what must NOT go there. Mark every module as 'server-only', 'client-only', or 'shared'. Do not write any code yet.
PHASE 2 (after I say 'approved'): Generate the files. Constraints:
- Respect the server/client/shared markers. A file marked client-only may not import a server-only module. Server-only files start with `import 'server-only'`.
- No catch-all files: no utils/helpers.ts, no misc.ts, no lib/index dumping ground. Every function lives in a named, single-purpose module.
- Each module exports a typed public API and keeps internals unexported.
- Include a top-of-file comment in each file: its layer, its one responsibility, and its allowed dependencies.
Finish with a dependency-direction check: confirm imports only flow client -> shared and server -> shared, never client -> server.