Adrienenjalbert/repo-architecture

Repo Architecture

Use When

• creating a new route or feature
• deciding where a file should live
• moving code
• reviewing whether generated code matches repo structure

Core Rules

• Keep src/app thin.
• Put feature-owned code in src/features/<feature>.
• Use src/shared only for cross-feature infrastructure.
• Use src/lib only for low-level infrastructure/utilities.
• Use src/components/ui for primitives.
• Use src/components/common only for truly generic cross-feature helpers.

Dependency Direction

src/app -> src/features -> src/shared -> src/lib

Generate new code in that direction.

Put Code Here

src/app

Allowed:

• page.tsx
• layout.tsx
• error.tsx
• not-found.tsx
• robots.ts
• route handlers
• metadata / generateMetadata
• generateStaticParams

Not allowed as default:

• large page composition
• new feature helpers
• feature datasets

src/features

Default home for:

• page composition
• feature shells
• sections
• clients
• feature data
• feature types
• feature schema wiring

src/shared

Current examples:

• src/shared/seo/JsonLd.tsx
• src/shared/sitemap/*

src/lib

Current examples:

• src/lib/seo/*
• src/lib/security/*
• src/lib/server/*
• src/lib/site/*
• src/lib/utils/*
• src/lib/calculators/*

Do not place new feature datasets here.

Current Reuse Hotspots

• src/features/career-hub/shared/*
• src/features/tools/shared/*
• src/features/roles/shared/*

These are active, not deprecated.

Forbidden Defaults

• new feature UI in src/components/career-hub/*
• new feature data in src/lib/data/*
• new feature support files in src/app/*

Output Standard

When you generate code, it should:

1. use a thin route file if a route is involved
2. place logic in the owning feature
3. reuse an existing shell/helper where possible
4. avoid architecture-wide cleanup unrelated to the task