duxt es una capa, no una plantilla. La extiendes y cada archivo que trae se
vuelve sobrescribible: pon un archivo del mismo nombre en tu propio proyecto y
Nuxt resolverá el tuyo primero. Nada se copia a tu repositorio, así que una
actualización es un cambio de versión y no una fusión.

## Qué significa esto en la práctica

| Quieres                                    | Haces                                                  |
| :----------------------------------------- | :----------------------------------------------------- |
| Cambiar un texto, un enlace, un interruptor | Definir la clave en tu `app/app.config.ts`             |
| Reemplazar una pieza del diseño            | Crear `app/components/DuxtFooter.vue` en tu proyecto    |
| Rediseñar el tema                          | Redefinir una variable CSS en tu propia hoja de estilos |
| Añadir una página                          | Escribir Markdown en `docs/`                            |

El orden es deliberado: los tres primeros son compromisos progresivamente
mayores, y un componente que reemplazas es un componente que ahora mantienes.
Véase [Sobrescribir el tema](/guides/override-the-theme).

## Qué te quita

Una capa nunca conoce el proyecto que se apoya en ella. Dos consecuencias que
nota quien la consume:

- **`@` es tuyo, no de la capa.** El alias pertenece a quien extiende duxt, así
  que las importaciones de la propia capa usan `@duxt`. El tuyo sigue apuntando
  a tu `app/`.
- **Una colección se resuelve contra la capa, no contra ti.** Content registra
  como raíz de cada colección la capa que la declaró, de modo que un `cwd`
  relativo en la configuración de duxt apuntaría dentro de duxt. Por eso la capa
  calcula una ruta absoluta al cargar, lo cual funciona porque
  `content.config.ts` es código ejecutado y no un archivo de datos: sobre esa
  costura se asienta todo el atajo de `sources`.

## Por qué está construido así

La alternativa es una plantilla de inicio: `nuxi init`, y el tema pasa a ser una
copia dentro de tu repositorio. Eso da libertad total y ningún camino de
actualización — cada mejora del tema es un diff que alguien debe aplicar a mano.
Una capa lo invierte: heredas las mejoras y solo pagas donde discrepaste.

Lo que fija todo esto es la superficie pública. Un componente, una página o una
clave de `app.config` que puedes sobrescribir es un nombre del que dependes, así
que renombrar uno es un cambio incompatible de la capa — que es justo lo que
documenta la [referencia](/reference).