Tudo o que o tema mostra são dados, e `app/app.config.ts` é onde um site os
declara. Não há um segundo ficheiro de configuração: a mesma chave `duxt`
transporta o tema, as fontes de documentação e os links do próprio site.

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

Cada chave e o seu valor por omissão estão na
[referência de configuração](/reference/configuration); a entrada `sources` tem
[uma página própria](/reference/sources).

## Como a tua configuração é combinada

O teu objeto `duxt` é combinado chave a chave sobre os valores por omissão da
camada, e **um array teu substitui o da camada** em vez de lhe ser acrescentado.
Isso importa porque a combinação de `app.config` do Nuxt faz o contrário:
concatena arrays, o que te deixaria sem poder remover uma única entrada da barra
de navegação que a camada traz. Por isso a camada não entrega listas nenhumas em
`app.config` e combina-as ela própria.

A regra prática: substitui `footer.copyright` e `footer.legal` fica intacto;
declara `navigation` e a única entrada da camada desaparece.

## Duas chaves são lidas em tempo de compilação

`sources` e `locales` decidem as coleções, as rotas e os links `hreflang`, e as
três ficam definidas antes do primeiro pedido. Alterar qualquer uma delas exige
nova compilação; tudo o resto tem efeito assim que a configuração é recarregada.

## Algumas chaves são geradas, não escritas

`resolvedSources`, `layerVersion` e `layerRepository` aparecem na configuração
em tempo de execução e pertencem à compilação. `resolvedSources` é o manifesto
que o tema realmente lê — que coleção serve que prefixo de URL — resolvido a
partir da lista `sources` que escreveste. Escrever qualquer um dos três à mão é
sobrescrito.

## O que a camada não presume saber

`links`, `aside.links` e `footer.legal` são entregues **vazios**. Um
repositório, um gestor de issues, uma comunidade e um aviso legal nomeiam cada
um um projeto concreto, pelo que um valor por omissão com os do duxt entregaria
aos teus leitores um «Star on GitHub» que marca o trabalho de outra pessoa.

`sections` é entregue vazio pela razão vizinha: nomeia as partes de topo da tua
árvore de documentação, e a camada não pode saber como lhes chamaste. Define-o
quando a tua documentação tiver secções; até lá a linha fica escondida e a barra
lateral mostra a árvore inteira.

```ts
sections: [
  { label: 'Guias', to: '/guides', icon: 'lucide:book-open' },
  { label: 'Referência', to: '/reference', icon: 'lucide:list' }
]
```

Escreve os teus — como texto simples, ou como registo por locale se o site
servir vários idiomas:

```ts
links: [
  {
    icon: 'simple-icons:github',
    to: 'https://github.com/tu/o-teu-projeto',
    label: { 'en-GB': 'Repository', 'pt-PT': 'Repositório' }
  }
]
```

::callout{type="warning" title="duxt.defaults.* não é teu"}
As chaves i18n da camada traduzem os valores por omissão que ela entrega. São
internas: renomear uma não é uma alteração incompatível, e o i18n responde a uma
chave em falta imprimindo a chave — a quebra seria portanto silenciosa no teu
site. Usa um literal, uma chave tua, ou a forma de registo acima.
::

## A origem do site

O duxt não consegue adivinhar o domínio a partir do qual será servido, e quatro
coisas precisam dele: `hreflang`, `canonical`, o sitemap e as imagens Open
Graph. Indica-o uma vez, onde o Nuxt já o pergunta:

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

ou como `NUXT_PUBLIC_I18N_BASE_URL` no deployment. A camada copia-o para
`site.url`, que é onde os módulos de SEO procuram. Se ficar por definir, cada um
deles recai em saída relativa em vez de inventar um domínio — um `canonical`
relativo ainda resolve, um adivinhado está ativamente errado. Ver
[SEO](/concepts/seo).