duxt is a layer, not a template. You extend it, and every file it ships becomes
overridable: put a file of the same name in your own project and Nuxt resolves
yours first. Nothing is copied into your repository, so an upgrade is a version
bump rather than a merge.

## What that means in practice

| You want to                        | You do                                                  |
| :--------------------------------- | :------------------------------------------------------ |
| Change a string, a link, a switch  | Set the key in your `app/app.config.ts`                 |
| Replace a piece of the layout      | Create `app/components/DuxtFooter.vue` in your project   |
| Restyle the theme                  | Redefine a CSS variable in your own stylesheet           |
| Add a page                         | Write Markdown in `docs/`                               |

The order is deliberate: the first three are progressively larger commitments,
and a component you replace is a component you now maintain. See
[Override the theme](/guides/override-the-theme).

## What it takes away

A layer never knows the project standing on it. Two consequences a consumer
feels:

- **`@` is yours, not the layer's.** The alias belongs to whoever extends duxt,
  so the layer's own imports use `@duxt` instead. Yours keeps pointing at your
  `app/`.
- **A collection resolves against the layer, not against you.** Content records
  each collection's root as the layer that declared it, so a relative `cwd` in
  duxt's own config would point into duxt. The layer therefore computes an
  absolute path at load time — which works because `content.config.ts` is
  executed code rather than a data file, and that seam is what the whole
  `sources` shorthand sits on.

## Why it's built this way

The alternative is a starter template: `nuxi init`, and the theme is now a copy
inside your repository. That gives total freedom and no upgrade path — every
improvement to the theme is a diff someone has to apply by hand. A layer inverts
it: you inherit improvements, and you pay only where you disagreed.

What pins this down is the public surface. A component, page or `app.config` key
you can override is a name you depend on, so renaming one is a breaking change
of the layer — which is what the [reference](/reference) documents.