EvolveHQ/docflow

bootstrap

Você está instalando (ou adaptando) um conjunto de convenções orientadas a documentação no repositório atual. O estado final é um repositório que pode ser dirigido tanto por humanos quanto por agentes de codificação a partir de um pequeno conjunto de arquivos canônicos. Aplique o mecanismo descrito aqui — nada sobre qualquer outro projeto.

Etapa 1 — Detectar a situação

Inspecione o repositório antes de perguntar qualquer coisa. Reutilize respostas explícitas e autorizações já fornecidas nesta sessão; nunca as substitua por padrões de perfil ou as solicite novamente. Antes de escrever, resuma a raiz do artefato resolvida, profundidade, fila, gate e modos de coordenação/integração com base nessas respostas. Se um host espelha uma pasta selecionada em uma sandbox, identifique o caminho de destino real e como as saídas verificadas alcançam a pasta selecionada; nunca considere um destino intocado como completo apenas porque um espelho de rascunho passou.

• Repositório novo (sem código-fonte, sem documentação): você está estruturando do zero.

• Repositório existente: você está adaptando.

  • Leia qualquer README.md, CONTRIBUTING.md, AGENTS.md, CLAUDE.md, docs/, adr/, .github/ atuais antes de propor alterações.
  • Preserve o conteúdo existente. Mescle, não sobrescreva. Se as convenções existentes entrarem em conflito com as abaixo, exiba o conflito em seu resumo de avaliação.
  • Se os ADRs já existirem em outro formato, proponha um plano de migração (renumerar, manter, traduzir) em vez de criar uma árvore paralela.

• Já é um repositório docflow (contém AGENTS.md + CONVENTIONS.md + um catálogo ADR): você está adicionando a uma configuração existente, não estruturando. Não reestruture o núcleo nem repita perguntas já resolvidas — leia as escolhas registradas de CONVENTIONS.md/AGENTS.md (formato ADR, ciclo de vida de status, raiz do artefato, modo multiagente e quais camadas opcionais já existem). Em seguida, ofereça-se para ativar qualquer camada opcional ainda ausente — plan/, _agent/, GLOSSARY.md, domains/, ou o segundo formato ADR (o template de tecnologia) — e escreva apenas as escolhidas, por mesclagem, sob a raiz do artefato registrada, deixando todo o resto intocado. Faça apenas as perguntas que as novas camadas precisam (por exemplo, a pergunta de coordenação ao ativar _agent/ — onde um único escritor sem um gate de verificação registrado e uma fila de planos termina corretamente sem _agent/ algum, e a camada simplesmente não é necessária). Este é o ponto de entrada para adicionar uma camada que você adiou na primeira inicialização. Um repositório que ainda contém arquivos de coordenação que um scaffold anterior escreveu os mantém: deixe-os no lugar aqui e deixe que a habilidade de auditoria relate o layout.

  Ativar GLOSSARY.md escreve o esqueleto canônico, nunca uma reescrita. Quando a camada é escolhida e o arquivo está ausente, escreva-o a partir de templates/GLOSSARY.md — o título opcional e a prosa, então a tabela Termo | Definição registrada no CONVENTIONS.md gerado §Glossário. Se o arquivo já existir, deixe-o intocado: ativar a camada não adiciona nada, e add-convention estende o arquivo existente na forma canônica ou audit oferece uma migração consentida.

  Ativar o segundo formato ADR é uma troca de esquema, não uma cópia de arquivo. É a única camada adiada que altera uma escolha já registrada, então escreva tudo de uma vez ou nada: substitua §Formatos ADR em CONVENTIONS.md pelo texto de dois formatos, adicione a ordem de seção de tecnologia e os marcadores de formato a AGENTS.md, escreva adr/0000-template-technology.md, e regenere INDEX.md com a coluna Formato. Os ADRs existentes mantêm seus números e permanecem capacidade — um campo shape: ausente já significa capacidade, portanto nenhum ADR é reescrito e nada é renumerado. Metade da troca deixa o repositório no estado que a verificação cruzada da Etapa 4.5 chama de contradição: um template de tecnologia que um esquema de formato único nunca selecionará.

  Um repositório já na codificação de intervalo legado recebe a oferta de migração. Alguns repositórios de dois formatos foram estruturados antes de o formato se tornar um campo declarado e o codificam no número: §Formatos ADR registra um ponto de corte (capacidade abaixo dele, tecnologia nele ou acima), e adr/ contém um template numerado diferente de 0000 (p. ex. adr/0100-template.md). Qualquer um desses sinais o identifica. Tal repositório não está faltando uma camada — ele já tem ambos os formatos — portanto, não ofereça a troca de esquema acima, que o deixaria com duas codificações rivais. Ofereça a migração para o campo declarado, nos mesmos termos que a habilidade de auditoria usa:

  • Mostre o mapa de numeração antigo para novo primeiro, como uma simulação: ADRs de capacidade mantêm seus números; ADRs de tecnologia recebem os números após o ADR de capacidade mais alto, em sua ordem relativa original. Junto a ele, liste as referências que seguem (depends-on, supersedes / superseded-by, links relativos adr/NNNN-*.md, INDEX.md, listagens de README.md de domínios, linhas de ADR proprietário em plan/todo/) e o que é deixado como histórico (rodapés de plan/done/, mensagens de commit, tags).
  • Não escreva nada sem uma confirmação explícita desse mapa. Recusar é um resultado válido: o repositório mantém a codificação de intervalo e continua passando em suas próprias regras.
  • Após a confirmação, aplique a migração exatamente como a etapa de migração da habilidade audit especifica — renumerar, carimbar shape: em cada ADR, reescrever toda referência no catálogo, substituir o template de limite com adr/0000-template-technology.md, reescrever §Formatos ADR para o campo declarado e remover qualquer cláusula de exceção de ADR semente, regenerar INDEX.md com a coluna Formato — e finalize como um commit cuja mensagem lista cada par antigo-para-novo. Esse procedimento é a única fonte da verdade; não parafraseie uma segunda variante dele aqui.
  • Em seguida, continue a reexecução normalmente para as camadas que realmente estão ausentes (plan/, _agent/, GLOSSARY.md, domains/).

Indique qual situação se aplica em uma linha antes de fazer as perguntas de avaliação.

Etapa 2 — Layout de destino

<repo>/
  AGENTS.md              # regras rígidas para agentes de codificação — ponto de entrada
  CLAUDE.md              # linha única: @AGENTS.md
  README.md              # resumo do projeto para humanos (preservar se existir)
  CONVENTIONS.md         # regras de criação: ADRs, nomenclatura, status, auditoria, git
  INDEX.md               # tabela gerada de todos os ADRs
  GLOSSARY.md            # termos compartilhados (opcional — veja Q7)
  adr/
    0000-template.md     # template ADR de capacidade (sempre)
    0000-template-technology.md  # template ADR de tecnologia (apenas se dois formatos — veja Q2)
    NNNN-<kebab-slug>.md # um ADR por decisão, numeração contígua
  domains/<slug>/README.md   # opcional (veja Q7)
  plan/
    README.md
    todo/NNNN-<slug>.md
    done/<YYYY-MM-DD>-<slug>.md
  _agent/                # o contrato operacional do agente (veja Q5) — opcional
    ROLES.md             # quem escreve o quê (apenas vários escritores)
    LOCKS.md             # o mutex de reivindicação de arquivo (apenas checkout compartilhado)
    prompts/autonomous.md  # como uma execução não supervisionada se comporta (apenas com um
                         #   gate de verificação — Q8 — E uma fila de planos — Q4a)
  federation.md          # apenas multirrepositório (Q11): back-pointer deste repositório
  federation-index.md    # apenas multirrepositório (Q11): índice de membros — apenas repositório base

Posicionamento. A árvore acima mostra a opção raiz. AGENTS.md e CLAUDE.md sempre ficam na raiz do repositório; adr/, plan/, _agent/, INDEX.md e CONVENTIONS.md vão sob a raiz do artefato escolhida em Q12 (padrão .docflow/, p. ex. .docflow/adr/, .docflow/plan/).

Descoberta. As ferramentas localizam a raiz do artefato sem ler CONVENTIONS.md primeiro: um diretório .docflow/ na raiz do repositório é a raiz; para qualquer outra raiz, o bootstrap escreve um arquivo .docflow na raiz do repositório — um ponteiro de uma linha, root: <path> (p. ex. root: docs/, root: .). Nenhum dos dois presente significa um repositório pré-contrato (as ferramentas sondam docs/, depois a raiz do repositório, em busca de um CONVENTIONS.md nomeando uma raiz de artefato) ou não é um repositório docflow.

_agent/ é o contrato operacional do agente — quem escreve o quê, o único mutex real e como uma execução não supervisionada se comporta. Ele não contém nada que o git já registra: nenhum registro de envio duplicado, nenhum painel do que está em andamento, nenhum instantâneo do estado atual, nenhuma transferência. Quais dos três arquivos acima existem decorrem inteiramente de Q5, Q8 e Q4a, e um repositório sem nenhum diretório _agent/ é um resultado válido.

Núcleo vs camadas opcionais. Apenas o núcleo é sempre escrito: AGENTS.md, CLAUDE.md, CONVENTIONS.md, adr/0000-template.md e INDEX.md. Um repositório com apenas isso é um repositório docflow leve e válido — um catálogo ADR clássico com convenções. Todo o resto é uma camada opt-in: a fila plan/ (Q4a), o contrato _agent/ (Q5 + Q8 + Q4a — um único escritor sem um gate de verificação e uma fila de planos não recebe nada disso), GLOSSARY.md e domains/ (Q7). Omitir qualquer camada opcional é um estado válido, não um erro; uma habilidade de ciclo de vida que precisa de uma camada ausente recusa de forma limpa e nomeia o que está faltando.

Para um produto multirrepositório (um produto distribuído por vários repositórios — veja Q11), dois arquivos extras aparecem: federation.md, um pequeno back-pointer que cada repositório membro carrega, e federation-index.md, a lista de membros autoritativa que vive apenas no repositório base/estabelecedor. Todos os artefatos de federação — federation.md, federation-index.md e o roll-up derivado ROLLUP.md — são colocados sob a raiz do artefato configurada. Um repositório independente não tem nenhum deles.

Etapa 3 — Convenções a instalar

1. ADRs são a fonte da verdade. Uma decisão por ADR. Divisões tornam-se novos ADRs que substituem; nunca expanda o escopo dentro de um existente.
2. Até dois formatos ADR, declarados por campo. Um repositório que distingue os dois registra a distinção no campo de metadados shape: de cada ADR (capability ou technology; um campo ausente significa capacidade) — nunca em uma faixa de números. Cada ADR recebe o próximo número contíguo qualquer que seja seu formato, e cada formato tem seu próprio template, ambos numerados 0000.
   • ADR de Capacidade (o que o sistema deve fazer). Ordem das seções: metadados → Contexto → Declaração de capacidade → Histórias de usuário / cenários → Critérios de aceitação → Fora do escopo → Perguntas em aberto → Referências → Histórico de revisão → Aprovações.
   • ADR de Tecnologia (como é construído). Ordem das seções: metadados → Contexto → Decisão → Racional → Consequências → Critérios de aceitação → Fora do escopo → Perguntas em aberto → Referências → Histórico de revisão → Aprovações. O racional deve nomear alternativas consideradas e fornecer razões específicas de rejeição (não "mais simples" / "mais idiomático").
3. Ciclo de vida de status: Proposto → Aceito → Implementado → (Substituído | Descontinuado). Estados terminais alcançáveis de qualquer estado anterior. Status direciona a colocação na pasta do plano: Aceito → plan/todo/, Implementado → plan/done/.
4. Nomes de arquivo: adr/NNNN-kebab-slug.md, preenchido com zero de 4 dígitos, contíguo, sem lacunas reservadas. Referências cruzadas usam caminhos relativos.
5. Critérios de aceitação são testáveis e numerados. Os testes mapeiam de volta para eles quando prático.
6. Disciplina de auditoria. Alterações substantivas de ADR anexam uma linha de Histórico de Revisão. Alterações editoriais (erros de digitação, formatação, correções de links) são excluídas, mas sinalizadas editorial na mensagem de commit. A tabela de Aprovações é preenchida quando um ADR é Aceito e atualizada a cada revisão substantiva posterior.
7. INDEX.md é regenerado a partir dos metadados do ADR após qualquer alteração no ADR. Trate como derivado, não editado manualmente.
8. plan/ é a fila de trabalho. Quando o trabalho é enviado, git mv plan/todo/X plan/done/<data>-X, qualquer remoção de status do item do plano, avanço de status do ADR proprietário e regeneração de INDEX.md são agrupados no commit de conclusão. Sob integração direta ao main, esse commit é enviado para o branch de integração e o rodapé do arquivo movido nomeia o SHA do HEAD (e o id do artefato de implantação, se aplicável). Sob integração por pull request, essas alterações são o último commit no branch do pull request antes de ser marcado como pronto, o rodapé nomeia o pull request, e o merge é o evento de conclusão.
9. Coordenação é um contrato, não um log. _agent/ contém apenas o que o git não pode lhe dizer, e cada modo (Q5) prescreve exatamente seus próprios arquivos — nada mais é escrito lá. Em um checkout compartilhado, um agente anexa uma linha a _agent/LOCKS.md (<id-do-agente> | <caminho> | <timestamp ISO-8601>) antes de editar e a remove ao commitar; esse livro-razão é o único mutex real, e um item da fila é reivindicado no próprio item. Em worktrees separados, um item da fila é reivindicado enviando claim/<chave-do-item> — o nome do arquivo da fila sem sua extensão — mais um pull request de rascunho a partir dele, onde a integração é baseada em pull request; o push é o que exclui o segundo escritor, e nenhum livro-razão é mantido. Sob um único escritor, não há nada para serializar e nada para reivindicar. Nenhum modo mantém estado de envio duplicado, um painel do que está em andamento ou um instantâneo do estado atual: o histórico do git e plan/done/ são o registro, e os branches ativos e pull requests são o que está em andamento.
10. Contrato Git. Commits Convencionais. Rodapé Rationale: obrigatório em commits que tocam um ADR. Commits assinados, a menos que o usuário desista. Nenhum trailer Co-Authored-By para trabalho de agente, a menos que o usuário solicite um.
11. AGENTS.md é o ponto de entrada de regras rígidas; CLAUDE.md é a linha única @AGENTS.md para agentes compatíveis que o leem.
12. ADRs são artefatos internos — nunca visíveis ao usuário. Números de ADR, títulos de ADR e a existência do catálogo ADR NUNCA devem aparecer em caminhos de código de produto que alcancem um usuário: strings de UI, corpos de resposta de API, mensagens de erro, linhas de log emitidas para clientes, documentação pública, notas de versão, cópia de marketing ou comunicações de suporte. ADRs são para construtores, não para usuários.

Etapa 4 — Nível de profundidade

Antes de perguntar qualquer coisa, ofereça três níveis de profundidade:

• Expresso (:rocket:): pergunte apenas Q4a, Q5 e Q8. Aplique os padrões para Q1, Q2, Q3, Q6, Q7, Q9, Q10, Q11, Q12. Não exija uma resposta para cada uma — aponte que os padrões estão listados em CONVENTIONS.md e podem ser alterados posteriormente.
• Guiado: pergunte Q1, Q2, Q3, Q4a, Q5, Q7, Q8, Q10, Q11, Q12. Pule Q4b, Q6, Q9. Termine com um resumo e um convite para ajustar qualquer resposta.
• Completo: faça todas as perguntas abaixo, na ordem.

Q1 — Propósito do repositório

• Componente de biblioteca / SDK
• Aplicação de serviço / microsserviço
• Ferramenta CLI / utilitário
• Projeto de documentação / Conhecimento
• Configuração / Infraestrutura como código
• Monorepo (vários artefatos independentes)
• Modelo / Starter kit

Q2 — Formatos ADR

• Um formato — um único template de ADR de capacidade para todas as decisões
• Dois formatos — ADRs de capacidade (o que o sistema deve fazer) E ADRs de tecnologia (como é construído), com templates separados. Use dois formatos quando sua equipe precisa distinguir decisões de "o quê" de decisões de "como", ou quando ambas são numerosas. ADRs de tecnologia geralmente referenciam um ADR de capacidade como sua justificativa ou contexto.

Q3 — Nomenclatura de ADR

• kebab-slug (padrão) — adr/0001-nome-da-decisao.md
• Numérica apenas — adr/0001.md

Q4 — Fila de planos

Q4a — Usar plan/?

• Sim — ative plan/ como fila de trabalho (veja estrutura acima)
• Não — pule toda a camada plan/

Q4b — Estilo da fila (apenas se Q4a = Sim)

• Pull-request — cada item da fila é resolvido por seu próprio branch e pull request. A conclusão é uma mesclagem. O item movido recebe o link do PR em seu rodapé.
• Direto ao main — cada item pode ser commitado diretamente no branch de integração. A conclusão é o commit de envio. O item movido recebe o SHA do commit e, opcionalmente, um id de artefato.

Q5 — Modo de coordenação do agente

• Checkout compartilhado — múltiplos agentes no mesmo clone, editando e commitando do mesmo checkout. É necessário LOCKS.md (mutex de reivindicação de arquivo). ROLES.md é necessário se houver mais de um escritor.
• Worktrees separados — cada agente opera em seu próprio checkout (clone ou worktree git). Os itens da fila são reivindicados enviando claim/<chave>. Nenhum LOCKS.md é mantido. ROLES.md é necessário se houver mais de um escritor.
• Escritor único — apenas um agente (ou humano) escreve por vez. Nenhum _agent/ é necessário.

Q6 — Nomeação de ADR de domínio

Se domínios são usados, deve um ADR ser nomeado com um slug de domínio (p. ex. adr/0001-auth-nome-da-decisao.md)? Útil em monorepos ou projetos multifuncionais.

• Sim
• Não (padrão)

Q7 — Camada de conhecimento

• Nenhuma (padrão) — sem glossário, sem domínios
• Apenas GLOSSARY.md — um arquivo glossário compartilhado na raiz
• Apenas domínios/ — pastas de domínio fatiadas (cada uma com seu README.md para documentação específica do domínio)
• Ambos — glossário E pastas de domínio

Q8 — Gate de verificação

• Manual — o humano revisa antes do merge / conclusão. Sem automatização.
• Automatizado — CI executa testes, linters, verificações de formato ADR, auditoria de INDEX.md. A conclusão falha se alguma verificação falhar.
• Nenhum — sem gate; o trabalho é movido para done/ por declaração.

Q9 — Estratégia de versionamento

• Semver estrito — versões devem ser estritamente SemVer 2.0.0. Commits entre releases não devem quebrar o esquema.
• Semver flexível — compatível com SemVer, mas versões de patch podem conter mudanças menores compatíveis com versões anteriores não críticas (documentação, refatoração, dependências de desenvolvimento).
• Data-relativa — versões baseadas em data (p. ex. 2025.03.01). Sem garantias de compatibilidade.
• Hash / SHA — sem versionamento formal; o commit SHA é o identificador.

Q10 — Convenção de commits

• Commits Convencionais (padrão) - Conventional Commits 1.0.0
• Commits Livres — sem estrutura de mensagem obrigatória

Q11 — Produto multirrepositório?

• Repositório independente (padrão) — sem arquivos de federação
• Repositório base (estabelecedor) — este repositório estabelece o produto. Ele contém federation-index.md e todos os membros contêm federation.md. O repositório base também detém quaisquer ADRs de fronteira/arquiteturais que abrangem membros.
• Repositório membro — este repositório é parte de um produto multirrepositório. Ele contém federation.md apontando para o repositório base. ADRs que abrangem membros vivem no repositório base.

Q12 — Raiz do artefato

O diretório no repositório onde adr/, plan/, _agent/, INDEX.md e CONVENTIONS.md residem. Deve ser relativo à raiz do repositório. Padrão: .docflow/.

• .docflow/ (padrão) — diretório oculto, agnóstico à estrutura do projeto
• docs/ — visível aos humanos, raiz da documentação do projeto
• . — raiz do repositório (não aninhado). Simples, mas polui o diretório raiz.
• Outro (especificar caminho)

Etapa 4.5 — Verificação cruzada do formato ADR

Se você respondeu "Dois formatos" em Q2, verifique:

• O template adr/0000-template-technology.md existe?
• CONVENTIONS.md menciona o campo shape: e lista ambos os formatos?
• AGENTS.md menciona a ordem de seção de tecnologia?
• INDEX.md tem a coluna Formato?
• Não há ADR de tecnologia codificado por número (ou seja, nenhum ADR com número >= um limite de corte definido)?

CORREÇÃO: Se a configuração de dois formatos estiver incompleta, corrija os arquivos ausentes. Se o repositório estiver usando codificação de intervalo para formato, ofereça migração.

Etapa 5 — Reunir compromissos, avaliar respostas, sinalizar respostas padrão, então escrever

1. Pergunte Q1-Q12 por ordem (apenas as relevantes para o depth escolhido). Nunca pule uma pergunta apenas porque a resposta é "padrão" — a menos que esteja no modo Expresso e a pergunta seja omitida. Nunca invente padrões que não estejam listados aqui.
2. Depois que o usuário responder, compile as respostas e os padrões não substituídos na tabela abaixo. Sinalize quais respostas são padrão, quais são explícitas. Um "padrão" significa que a pergunta não foi feita (Expresso) OU que o usuário respondeu "padrão". Qualquer outra resposta é explícita.
3. Mostre um resumo das escolhas resolvidas. Inclua a raiz do artefato, se a fila de planos está ativa e o estilo, o modo de coordenação, o gate de verificação, a camada de conhecimento e o modo de integração. Peça confirmação antes de escrever.
4. Escreva os arquivos. Use o modelo templates/ para conteúdo. Sempre mescle, nunca substitua conteúdo de usuário identificado.

Tabela de configuração:

Chave	Resposta	Fonte
Q1	Propósito	padrão / explícita
Q2	formatos ADR (um/dois)	padrão / explícita
Q3	nomenclatura	padrão / explícita
Q4a	fila de planos	padrão / explícita
Q4b	estilo da fila (se Q4a)	padrão / explícita
Q5	modo de coordenação	padrão / explícita
Q6	nomeação de domínio	padrão / explícita
Q7	camada de conhecimento	padrão / explícita
Q8	gate de verificação	padrão / explícita
Q9	versionamento	padrão / explícita
Q10	convenção de commits	padrão / explícita
Q11	estrutura do produto	padrão / explícita
Q12	raiz do artefato	padrão / explícita

Arquivos a escrever

AGENTS.md

Ponto de entrada de regras rígidas para agentes. Contém no máximo três seções:

1. Regras universais — aplicam-se a todos os agentes neste repositório.
2. Regras específicas de função — aplicam-se dependendo da tarefa (desenvolvimento, auditoria, CLI, etc.). Conteúdo específico depende da configuração.
3. Contrato operacional — referência a _agent/ se houver múltiplos escritores, caso contrário omitido.

Duas linhas essenciais:

• A primeira linha: "# Regras do agente para nome-do-repo"
• Referencie "Consulte CONVENTIONS.md para o contrato completo de criação de ADR."
• Se Q11 for membro ou base, referencie federation.md e o repositório base.

CLAUDE.md

Uma linha: @AGENTS.md — delega para AGENTS.md.

README.md

Apenas se o repositório estiver vazio. Caso contrário, preserve. Se existir, adicione uma seção de convenções se ausente.

CONVENTIONS.md

Todas as convenções relevantes para as respostas. Inclui:

• §ADR Shapes — formato(s) ADR, templates, campos
• §Lifecycle — ciclo de vida de status
• §Naming — nomenclatura de arquivos
• §Acceptance criteria — critérios de aceitação
• §Audit — disciplina de auditoria
• §INDEX.md — regras de regeneração
• §Planning — fila de planos (se aplicável)
• §Glossary — definições de termos (se camada de conhecimento incluir glossário)
• §Coordination — contrato de coordenação (se aplicável)
• §Git — contrato git
• §Documentation — documentação, comentários, padrões de código
• $outro — qualquer coisa específica do repositório que o agente deve saber

adr/NNNN-template.md (capacidade) e adr/NNNN-template-technology.md (tecnologia)

Arquivos de template para novos ADRs.

plan/ (se Q4a = Sim)

• plan/README.md
• pastas plan/todo/ e plan/done/

_agent/ (se Q5 ≠ escritor único)

• Se Q5 = checkout compartilhado: _agent/LOCKS.md (cabeçalho de tabela)
• Se Q5 = worktrees separados: nenhum LOCKS.md
• Se houver mais de um escritor (com base em Q5): _agent/ROLES.md
• Se Q8 = automatizado ou manual (ou seja, um gate) E Q4a = Sim: _agent/prompts/autonomous.md

GLOSSARY.md (se Q7 incluir glossário)

Template de glossário com tabela de exemplo.

domains//README.md (se Q7 incluir domínios)

Arquivos de esqueleto de domínio.

federation.md & federation-index.md (se Q11 = base ou membro)

Arquivos de federação com ponteiros para o repositório base e lista de membros.

INDEX.md

Gerado a partir de metadados ADR. Esqueleto se vazio.

Etapa 6 — Instalar

d

Após escrever os arquivos:

• Liste cada arquivo criado ou modificado com seu caminho relativo.
• Confirme que o layout corresponde à especificação da Etapa 2.
• Se aplicável, lembre o usuário de commitar as alterações. Uma sugestão de mensagem de commit: bootstrap: scaffold docflow conventions (depth: <express|guided|full>, product: <standalone|base|member>, layer: <core|+plan|+coord|+knowledge>)
• Para uma reexecução (repositório já docflow): bootstrap: add layer <nome-da-camada> to existing docflow repo