···11+# Preloading Example
22+33+This context describes the product language and architectural vocabulary for a chaptered learning lab about TanStack preloading, pagination, filtering, and synced local data patterns.
44+55+## Language
66+77+**Vertical**:
88+A product slice organized by what the code does for the user, not by technical category.
99+_Avoid_: Code grouping, feature folder, technical layer
1010+1111+**Shared vertical**:
1212+A vertical for cross-cutting code with a coherent responsibility that is used by more than one product slice.
1313+_Avoid_: Shared dumping ground, miscellaneous utilities
1414+1515+**Chapter**:
1616+A learning unit in the reading sequence that pairs exactly one article with exactly one demo.
1717+_Avoid_: Page, route, layout
1818+1919+**Article**:
2020+An explanatory content piece paired with a demo inside a chapter.
2121+_Avoid_: Blog component, copy block
2222+2323+**Demo**:
2424+An interactive Pokemon listing example paired with an article inside a chapter.
2525+_Avoid_: Table, widget, example component
2626+2727+**Chapter route**:
2828+A route module that composes a chapter by wiring its article, demo, route data, and search state.
2929+_Avoid_: Implementation dumping ground, generated registry entry
3030+3131+**Data**:
3232+The persistence model and direct database access for Pokemon records.
3333+_Avoid_: Data layer, server functions, query options, sync routes
3434+3535+**Landing**:
3636+The home screen that introduces the learning lab and presents entry points into the chapter sequence.
3737+_Avoid_: Table of contents owner, chapter registry
3838+3939+**Design System**:
4040+The shared visual foundation for app-wide primitive UI, styling tokens, global CSS, and theme controls.
4141+_Avoid_: Shared, common components, miscellaneous UI
4242+4343+**Framework adapter**:
4444+A file kept in a framework-mandated location to register routes, app wiring, or configuration while delegating implementation to verticals where practical.
4545+_Avoid_: Vertical owner, product slice
4646+4747+## Relationships
4848+4949+- A **Vertical** owns code that changes together for a product concern.
5050+- A **Shared vertical** may be used by multiple **Verticals** through a small public interface.
5151+- A **Chapter** contains exactly one **Article** and exactly one **Demo**.
5252+- The **Article** vertical owns markdown content, markdown rendering, article presentation, and server functions that produce renderable articles.
5353+- A **Chapter route** is the composition boundary for one **Chapter**.
5454+- A **Chapter route** may own route-specific integration between TanStack Router loaders, route context, search state, and TanStack Query options.
5555+- A **Chapter route** should compose **Verticals**, not contain substantial **Article** rendering internals or **Demo** implementation internals.
5656+- The **Demo** vertical owns the interactive Pokemon listing system, including shared demo UI, server functions, TanStack Query helpers, Electric shape routes, TanStack DB collections, and loading strategy helpers.
5757+- The **Data** vertical owns schema, relations, seed data, and direct database wrapper queries.
5858+- The **Demo** vertical consumes the **Data** vertical through direct query interfaces exposed by **Data**.
5959+- The **Chapters** vertical owns the canonical reading sequence, chapter metadata, table-of-contents data, and chapter navigation.
6060+- The **Chapters** vertical owns navigation chrome for the chaptered reading experience, including the header, chapter selector, chapter pager, and route navigation helpers.
6161+- The **Chapters** vertical owns chapter framing and status language, including section headers and status indicators.
6262+- The **Landing** vertical owns home-page presentation and consumes the **Chapters** vertical for the table of contents.
6363+- The **Design System** vertical owns primitive UI components, CSS files, styling tokens, utility class merging, and the theme toggle.
6464+- The **Demo** vertical owns console cards and panel frames used by the interactive demo surface.
6565+- Small implementation helpers used only by one vertical belong to that vertical; for example, the lazy component helper belongs to **Demo** while only the demo table uses it.
6666+- **Framework adapters** may remain in TanStack Start, TanStack Router, or Vite+ default locations even when they register behavior for a vertical.
6767+- API shape route files are **Framework adapters**; **Demo** owns the Electric collections that depend on those route URLs.
6868+- Root route, router creation, generated route tree, TanStack Start declarations, and Vite+ configuration are **Framework adapters** unless enough cohesive app-shell implementation emerges to justify a separate vertical.
6969+- `src/env.ts` remains app-wide runtime configuration and is not owned by **Data** or **Demo**.
7070+- Product-owned verticals live directly under `src/*` as named top-level directories such as `src/articles`, `src/chapters`, `src/data`, `src/demos`, `src/design-system`, and `src/landing`; framework-mandated files remain in their default locations as **Framework adapters**.
7171+- Do not introduce a `src/verticals` grouping directory. The earlier `src/verticals/*` plan was reversed because the extra nesting added path noise without improving the domain model.
7272+- Verticals should not expose app-code barrel files; imports should target the concrete module that owns the thing being imported, while files inside a vertical may use relative imports.
7373+- Technical categories such as components, server functions, content, utilities, and libraries are not primary ownership boundaries.
7474+7575+## Example dialogue
7676+7777+> **Dev:** "Should this table component stay under components because it renders UI?"
7878+> **Domain expert:** "No. If it exists to explain a preloading strategy in a demo, it belongs with that **Vertical** unless another **Vertical** consumes it through a public interface."
7979+8080+> **Dev:** "Is the `/basic` route the **Chapter**, or just the layout for one?"
8181+> **Domain expert:** "It is the **Chapter**: the route is the reading unit that composes one article and one demo."
8282+8383+> **Dev:** "Should markdown rendering utilities live in a generic utils folder?"
8484+> **Domain expert:** "No. Markdown rendering exists to produce **Article** content, so it belongs to **Article**."
8585+8686+> **Dev:** "Should the route file be empty glue that delegates all chapter composition elsewhere?"
8787+> **Domain expert:** "No. The **Chapter route** is allowed to compose the **Article** and **Demo**, especially where route data and preloading behavior are part of the lesson."
8888+8989+> **Dev:** "Do Electric shape routes belong to **Data** because they expose tables?"
9090+> **Domain expert:** "No. They belong to **Demo** because they deliver synced Pokemon listing data to the interactive examples; **Data** owns the persistence model and direct database queries."
9191+9292+> **Dev:** "Should the home page own the chapter list because it renders the table of contents?"
9393+> **Domain expert:** "No. **Landing** renders the home-page view, but **Chapters** owns the canonical reading sequence."
9494+9595+> **Dev:** "Should the header live in an app-shell vertical?"
9696+> **Domain expert:** "No. The header is chapter navigation chrome, so it belongs to **Chapters**."
9797+9898+> **Dev:** "Should status dots be part of the demo console?"
9999+> **Domain expert:** "No. Status indicators are used by **Landing** and chapter navigation, so they belong to **Chapters**."
100100+101101+> **Dev:** "Should `src/components/ui` live in a generic shared folder?"
102102+> **Domain expert:** "No. Primitive UI, tokens, global styles, and theme controls belong to **Design System**."
103103+104104+> **Dev:** "Should API shape route files move into **Demo** because Electric collections use them?"
105105+> **Domain expert:** "No. The route files stay in the framework route tree as **Framework adapters**; **Demo** owns the Electric collections that depend on those URLs."
106106+107107+> **Dev:** "Should we create an App Shell vertical for root route and router files?"
108108+> **Domain expert:** "Not yet. Keep framework-mandated files as **Framework adapters** and extract an app-shell vertical only if cohesive app-shell implementation grows."
109109+110110+> **Dev:** "Should each vertical expose an `index.ts` barrel as its public API?"
111111+> **Domain expert:** "No. App-code barrels hide dependency shape and can create circular imports; import concrete modules directly."
112112+113113+> **Dev:** "Should verticals live under `src/verticals` so the ownership model is explicit?"
114114+> **Domain expert:** "No. The ownership model is explicit in the named top-level directories under `src`; `src/verticals` was removed to keep import paths shorter while preserving the same vertical boundaries."
115115+116116+## Flagged ambiguities
117117+118118+- "Shared" can mean either reusable product infrastructure or a dumping ground for unrelated code. Resolved: only use **Shared vertical** for cross-cutting code with a coherent responsibility.
···11+# Organize product code into verticals while keeping framework adapters conventional
22+33+Status: Superseded by [ADR-0003](0003-keep-verticals-directly-under-src.md).
44+55+We will organize product-owned implementation under `src/verticals/*`, with verticals such as Landing, Chapters, Articles, Demos, Data, and Design System. TanStack Start, TanStack Router, and Vite+ framework-mandated files stay in their conventional locations as framework adapters, because changing route/config conventions for a purer file tree would add maintenance cost without improving the product model. Verticals will use direct module imports instead of app-code barrel files so dependency shape stays visible.
···11+# Keep verticals directly under src
22+33+Status: Accepted
44+55+Date: 2026-04-30
66+77+## Context
88+99+ADR-0002 initially placed product-owned implementation under `src/verticals/*`. That made vertical ownership explicit, but it also added an extra path segment to every product import.
1010+1111+The codebase has since moved the same verticals back directly under `src`.
1212+1313+## Decision
1414+1515+Product-owned verticals live directly under `src/*` as named top-level directories:
1616+1717+- `src/articles`
1818+- `src/chapters`
1919+- `src/data`
2020+- `src/demos`
2121+- `src/design-system`
2222+- `src/landing`
2323+2424+Do not recreate `src/verticals`.
2525+2626+TanStack Start, TanStack Router, API route modules, generated route files, runtime environment files, and Vite+ framework files remain in their conventional locations as framework adapters.
2727+2828+## Consequences
2929+3030+The codebase keeps the vertical ownership model from ADR-0002 while removing the extra `verticals` nesting from import paths.
3131+3232+The directory name is no longer the only signal that a folder is a vertical, so agents should use `CONTEXT.md` as the source of truth for vertical ownership.
3333+3434+ADR-0002 remains useful for understanding why the code is organized around vertical ownership, but its target path is superseded by this ADR.