Todo lo que muestra el tema son datos, y `app/app.config.ts` es donde un sitio
los declara. No hay un segundo archivo de configuración: la misma clave `duxt`
lleva el tema, las fuentes de documentación y los enlaces propios del sitio.

```ts [app/app.config.ts]
export default defineAppConfig({
  duxt: {
    title: 'mi proyecto',
    version: 'v1.4.0',
    sources: [{ path: 'docs' }]
  }
});
```

Cada clave y su valor por defecto están en la
[referencia de configuración](/reference/configuration); la entrada `sources`
tiene [su propia página](/reference/sources).

## Cómo se combina tu configuración

Tu objeto `duxt` se combina clave por clave sobre los valores por defecto de la
capa, y **un array tuyo reemplaza el de la capa** en lugar de añadirse a él. Eso
importa porque la combinación de `app.config` de Nuxt hace lo contrario:
concatena arrays, lo que te dejaría sin poder eliminar una sola entrada de la
barra de navegación que trae la capa. Por eso la capa no incluye ninguna lista
en `app.config` y las combina ella misma.

La regla práctica: sobrescribe `footer.copyright` y `footer.legal` queda
intacto; declara `navigation` y la única entrada de la capa desaparece.

## Dos claves se leen en tiempo de compilación

`sources` y `locales` deciden las colecciones, las rutas y los enlaces
`hreflang`, y las tres quedan fijadas antes de la primera petición. Cambiar
cualquiera de ellas exige recompilar; todo lo demás surte efecto en cuanto se
recarga la configuración.

## Algunas claves se generan, no se escriben

`resolvedSources`, `layerVersion` y `layerRepository` aparecen en la
configuración en tiempo de ejecución y pertenecen a la compilación.
`resolvedSources` es el manifiesto que el tema lee realmente — qué colección
sirve qué prefijo de URL — resuelto a partir de la lista `sources` que
escribiste. Escribir cualquiera de los tres a mano se sobrescribe.

## Lo que la capa no presume saber

`links`, `aside.links` y `footer.legal` se entregan **vacíos**. Un repositorio,
un gestor de incidencias, una comunidad y un aviso legal nombran cada uno a un
proyecto concreto, así que un valor por defecto con los de duxt pondría ante tus
lectores un «Star on GitHub» que marca el trabajo de otra persona.

`sections` se entrega vacío por la razón vecina: nombra las partes de primer
nivel de tu árbol de documentación, y la capa no puede saber cómo las llamaste.
Defínelo cuando tu documentación tenga secciones; hasta entonces la fila
permanece oculta y la barra lateral muestra el árbol completo.

```ts
sections: [
  { label: 'Guías', to: '/guides', icon: 'lucide:book-open' },
  { label: 'Referencia', to: '/reference', icon: 'lucide:list' }
]
```

Escribe los tuyos — como cadena simple, o como registro por locale si el sitio
sirve varios idiomas:

```ts
links: [
  {
    icon: 'simple-icons:github',
    to: 'https://github.com/tu/tu-proyecto',
    label: { 'en-GB': 'Repository', 'es-ES': 'Repositorio' }
  }
]
```

::callout{type="warning" title="duxt.defaults.* no es tuyo"}
Las claves i18n de la capa traducen los valores por defecto que ella entrega.
Son internas: renombrar una no es un cambio incompatible, e i18n responde a una
clave inexistente imprimiendo la clave — así que la rotura sería silenciosa en
tu sitio. Usa un literal, una clave propia o la forma de registro de arriba.
::

## El origen del sitio

duxt no puede adivinar el dominio desde el que se servirá, y cuatro cosas lo
necesitan: `hreflang`, `canonical`, el sitemap y las imágenes de Open Graph.
Decláralo una vez, donde Nuxt ya lo pide:

```ts [nuxt.config.ts]
i18n: { baseUrl: 'https://docs.example.com' }
```

o como `NUXT_PUBLIC_I18N_BASE_URL` en el despliegue. La capa lo copia a
`site.url`, que es donde miran los módulos de SEO. Si no se define, cada uno de
ellos degrada a salida relativa en lugar de inventar un dominio — un `canonical`
relativo sigue resolviéndose, uno adivinado es activamente erróneo. Véase
[SEO](/concepts/seo).