> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.

# DeepWiki

> Diagramas de arquitetura, documentação, links para o código-fonte e muito mais para todos os seus repositórios

<div id="overview">
  ## Visão geral
</div>

Devin agora indexa automaticamente seus repositórios e produz wikis com diagramas de arquitetura, links para as fontes e resumos da sua base de código.

Use-o para se atualizar rapidamente sobre partes da sua base de código com as quais você não está familiarizado — confira [na sua barra lateral](https://app.devin.ai/wiki).

[Ask Devin](/pt-BR/work-with-devin/ask-devin) usará informações da Wiki para entender melhor e encontrar o contexto relevante na sua base de código. Os recursos avançados de pesquisa de código do Ask Devin, combinados com o DeepWiki, produzem respostas detalhadas e precisas baseadas no seu código.

<Tip> O DeepWiki será gerado automaticamente ao conectar repositórios durante o onboarding. </Tip>

<iframe width="840" height="473" src="https://www.youtube.com/embed/lDh9rho5XW8" title="DeepWiki" className="max-w-full" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen />

<div id="for-public-repos">
  ## Para repositórios públicos
</div>

Uma versão gratuita do **DeepWiki** e do [Ask Devin](/pt-BR/work-with-devin/ask-devin) que funciona com repositórios públicos do GitHub está disponível. Ela gera automaticamente diagramas de arquitetura, documentação e links para o código-fonte para ajudar você a entender rapidamente bases de código desconhecidas. Você também pode fazer perguntas complexas sobre a base de código para obter respostas específicas baseadas no contexto.

<Note>A experiência completa do Ask Devin, incluindo pesquisa avançada de código, planejamento e criação de sessões, está disponível no [aplicativo Devin](https://app.devin.ai). O DeepWiki público e o DeepWiki MCP fornecem recursos básicos de documentação e perguntas e respostas.</Note>

Visite [deepwiki.com](https://deepwiki.com/) para começar a explorar repositórios de código aberto populares como React, TensorFlow, LangChain e muitos outros. Você também pode enviar a URL do seu próprio repositório público do GitHub para indexação.

[Experimente o DeepWiki agora →](https://deepwiki.com/)

<div id="steering-deepwiki">
  ## Orientando o DeepWiki
</div>

<Frame>
  <img src="https://mintcdn.com/cognitionai-enterprise/wB0NnCGoy7CGkti6/images/work-with-devin/steering-deepwiki.png?fit=max&auto=format&n=wB0NnCGoy7CGkti6&q=85&s=ea76731afe16b9a910227754dc0d80b8" alt="Steerable Wiki UI" width="2892" height="1714" data-path="images/work-with-devin/steering-deepwiki.png" />
</Frame>

O arquivo `.devin/wiki.json` permite orientar o comportamento padrão de geração de wiki do Devin, o que é especialmente importante para repositórios grandes que podem atingir limites embutidos.

Se um arquivo `.devin/wiki.json` for encontrado no diretório raiz do seu repositório durante a geração da wiki, usaremos os `repo_notes` e `pages` fornecidos para orientar a geração da wiki. Se `pages` for fornecido, ignoraremos o planejamento padrão baseado em clusters e criaremos exatamente as páginas que você especificar. Isso garante que as partes importantes da sua base de código sejam documentadas mesmo quando o sistema automático normalmente as ignoraria.

<div id="configuration-format">
  ## Formato de configuração
</div>

Crie um arquivo `.devin/wiki.json` na raiz do repositório com a seguinte estrutura:

```json theme={null}
{
  "repo_notes": [
    {
      "content": "Este repositório contém os principais componentes de interface na pasta cui/, que devem ser priorizados na documentação",
      "author": "Líder de Equipe"
    }
  ],
  "pages": [
    {
      "title": "Visão Geral dos Componentes CUI",
      "purpose": "Documentar a estrutura da pasta cui/ e os principais componentes de interface",
      "parent": null
    },
    {
      "title": "Sistema de Autenticação",
      "purpose": "Documentar o fluxo de autenticação e os componentes relacionados",
      "parent": null
    },
    {
      "title": "Componentes de Login",
      "purpose": "Documentação detalhada dos componentes de interface relacionados ao login",
      "parent": "Sistema de Autenticação"
    }
  ]
}
```

<div id="configuration-options">
  ## Opções de configuração
</div>

<div id="repo_notes-array">
  ### repo\_notes (array)
</div>

Fornece contexto e orientação para ajudar o sistema de documentação a compreender melhor o seu repositório.

* **content** (string, obrigatório): Conteúdo da nota (máximo de 10.000 caracteres)
* **author** (string, opcional): Autor da nota

<div id="pages-array-optional">
  ### pages (Array, opcional)
</div>

Especifica exatamente quais páginas devem ser criadas na sua wiki.

Este campo é opcional. Se você incluir apenas repo\_notes, o sistema ainda assim gerará uma wiki, usando suas anotações para orientar a estrutura e o foco, sem exigir que você detalhe cada página.

Quando você fornece pages, elas são tratadas como instruções explícitas. Somente as páginas definidas no JSON serão geradas — nem mais, nem menos.

* **title** (string, obrigatório): O título da página (deve ser único e não vazio)
* **purpose** (string, obrigatório): O que esta página deve documentar
* **parent** (string, opcional): Título da página principal para organização hierárquica
* **page\_notes** (array, opcional): Anotações adicionais específicas desta página

<div id="validation-limits">
  ### Limites de validação
</div>

* No máximo 30 páginas (80 para Enterprise)
* No máximo 100 notas no total (repo\_notes + todas as page\_notes combinadas)
* No máximo 10.000 caracteres por nota
* Os títulos de página devem ser únicos e não podem estar em branco

<div id="practical-examples">
  ## Exemplos práticos
</div>

<div id="example-1-repo-notes-to-guide-wiki-generation">
  ### Exemplo 1: Repo Notes para orientar a geração do wiki
</div>

Se você preferir não definir páginas específicas, pode fornecer apenas repo\_notes para ajudar a orientar a geração do wiki. Isso permite que o Devin crie a estrutura da documentação automaticamente, ainda levando em conta suas prioridades e áreas de foco. Isso é útil quando você quer uma cobertura e ênfase melhores, sem precisar definir explicitamente cada página por conta própria.

```json theme={null}
{
  "repo_notes": [
    {
      "content": "O repositório contém três áreas principais: a pasta frontend/ com componentes React, a pasta backend/ com serviços de API e a pasta infra/ com scripts de deploy. A documentação deve enfatizar como essas partes interagem e destacar a camada de API do backend como a maior prioridade."
    }
  ]
}
```

<div id="example-2-ensuring-specific-folders-are-documented">
  ### Exemplo 2: Garantindo a documentação de pastas específicas
</div>

Se o seu repositório grande tiver pastas importantes que não estão sendo incluídas na wiki, especifique-as explicitamente:

```json theme={null}
{
  "repo_notes": [
    {
      "content": "A pasta cui/ contém componentes de interface críticos que devem ser documentados. A pasta backend/ contém a lógica principal da API. A pasta utils/ contém utilitários compartilhados utilizados em todo o código."
    }
  ]
}
```

<div id="example-3-addressing-missing-components">
  ### Exemplo 3: Abordando Componentes Ausentes
</div>

Se você notar que certas partes da sua base de código não estão sendo documentadas:

```json theme={null}
{
  "repo_notes": [
    {
      "content": "O diretório testing/ contém utilitários e padrões de teste importantes que os desenvolvedores precisam conhecer. O diretório scripts/ contém scripts de deploy e manutenção essenciais para as operações."
    }
  ]
}
```

<div id="example-4-hierarchical-documentation-structure">
  ### Exemplo 4: Estrutura de Documentação Hierárquica
</div>

Para repositórios complexos, organize as páginas de forma hierárquica:

```json theme={null}
{
  "repo_notes": [
    {
      "content": "Esta é uma aplicação full-stack com componentes distintos de frontend, backend e compartilhados que devem ser documentados separadamente, mas com relacionamentos claros."
    }
  ],
  "pages": [
    {
      "title": "Visão Geral da Arquitetura",
      "purpose": "Visão geral de alto nível da arquitetura da aplicação e como os componentes interagem"
    },
    {
      "title": "Frontend",
      "purpose": "Estrutura e componentes da aplicação frontend",
      "parent": "Visão Geral da Arquitetura"
    },
    {
      "title": "Componentes React",
      "purpose": "Documentação detalhada dos componentes React, suas props e uso",
      "parent": "Frontend"
    },
    {
      "title": "Gerenciamento de Estado",
      "purpose": "Como o estado da aplicação é gerenciado, incluindo stores e fluxo de dados",
      "parent": "Frontend"
    },
    {
      "title": "Backend",
      "purpose": "Serviços backend, APIs e camada de dados",
      "parent": "Visão Geral da Arquitetura"
    },
    {
      "title": "Endpoints da API",
      "purpose": "Documentação da API REST incluindo endpoints e formatos de requisição/resposta",
      "parent": "Backend"
    }
  ]
}
```

<div id="best-practices">
  ## Boas práticas
</div>

<div id="1-use-repo-notes-strategically">
  ### 1. Use Repo Notes de forma estratégica
</div>

* Forneça contexto sobre quais partes do seu codebase são mais importantes
* Mencione diretórios ou componentes específicos que devem ser priorizados
* Explique as relações entre diferentes partes do seu sistema

<div id="2-organize-pages-logically">
  ### 2. Organize as páginas de forma lógica
</div>

* Comece com páginas de visão geral de alto nível
* Use relações pai-filho para criar hierarquias claras
* Agrupe funcionalidades relacionadas

<div id="3-be-specific-in-page-purposes">
  ### 3. Seja específico sobre o objetivo de cada página
</div>

* Declare claramente o que cada página deve documentar
* Mencione diretórios, arquivos ou conceitos específicos em que a página deve focar
* Forneça detalhes suficientes para o sistema entender sua intenção

<div id="4-address-known-gaps">
  ### 4. Aborde Lacunas Conhecidas
</div>

* Se você sabe que certas partes da sua base de código estão ficando de fora, inclua-as explicitamente
* Use títulos descritivos que deixem claro o que deve ser abrangido

<div id="troubleshooting-common-issues">
  ## Solução de problemas comuns
</div>

<div id="only-certain-folders-are-being-documented">
  ### "Apenas algumas pastas estão sendo documentadas"
</div>

Este é o clássico problema de repositório grande.

**Solução:** Use `.devin/wiki.json` para especificar explicitamente quais partes da sua base de código devem ser documentadas.

<Tip>Comece atualizando apenas repo\_notes e gere a wiki novamente com esse contexto adicional para ver se a wiki atualizada incluirá as pastas ausentes. Só adicione o array pages se for necessário.</Tip>

<div id="important-components-are-missing-from-the-wiki">
  ### "Componentes importantes estão ausentes na wiki"
</div>

Adicione páginas específicas para esses componentes e use repo\_notes para destacar sua importância.

<Tip>Lembre-se: o DeepWiki irá gerar somente as páginas incluídas nesse array, portanto, certifique-se de que todas as páginas estejam presentes, não apenas a página ausente.</Tip>

```json theme={null}
{
  "repo_notes": [
    {
      "content": "O diretório [missing-component] é essencial para a aplicação e deve ser documentado detalhadamente."
    }
  ],
  "pages": [
    {
      "title": "Nome do Componente Essencial",
      "purpose": "Documentar o diretório [missing-component] e sua funcionalidade"
    }
  ]
}
```

<div id="getting-started">
  ## Primeiros passos
</div>

1. Crie `.devin/wiki.json` na raiz do seu repositório
2. Adicione `repo_notes` explicando a estrutura da sua base de código e suas prioridades
3. Se necessário, especifique **todas** as páginas que você quer criar, com títulos e objetivos claros
4. Faça o commit do arquivo e regenere sua wiki

O sistema agora criará documentação com base nas suas instruções explícitas, em vez de depender de análise totalmente automática, garantindo uma cobertura mais abrangente e precisa de repositórios grandes.