Structure

Nome do projeto:
Versão do documento:
Status: [rascunho | revisando | aprovado]
Documentos base: Docs/stack.md, Docs/architecture.md, Docs/contract.yaml, Docs/deploy.md, Docs/plan.md
Data de criação:
Última atualização:

- A estrutura física deve refletir a arquitetura lógica
- Cada pasta deve ter responsabilidade clara e único dono funcional
- Arquivos devem ser localizados por domínio, não por conveniência momentânea
- Testes, scripts e automações devem ter local próprio
- Evitar pasta genérica sem responsabilidade definida
- Evitar duplicação de fonte de verdade

Estratégia recomendada: modular por domínio + camadas internas por responsabilidade
 
Modelo operacional:
- Documentação de governança: raiz + pastas dedicadas (Skills, Workflows, Quality)
- Documentação oficial do projeto: Docs/
- Protótipos navegáveis: Prototype/
- Templates: Templates/
- Código de execução: apps/, services/, packages/ ou src/ (conforme stack)

.
├── README.md
├── GUIDE.md
├── Docs/
│   ├── README.md
│   ├── brief.md
│   ├── project.md
│   ├── stack.md
│   ├── user-stories.md
│   ├── pages.md
│   ├── flow.md
│   ├── design-system.md
│   ├── tokens.json
│   ├── entities.md
│   ├── architecture.md
│   ├── contract.yaml
│   ├── structure.md
│   ├── deploy.md
│   ├── plan.md
│   ├── tasks.md
│   └── control.md
├── Manual/
│   ├── 00README.md
│   ├── 01GUIDE.md
│   ├── 02AGENTS.md
│   ├── 03NO-AGENTS.md
│   ├── 04COMPONENTS.md
│   ├── 05SCENARIOS-AGENTS.md
│   ├── 06SCENARIOS-NO-AGENTS.md
│   └── 07..14 CREATE-AGENT-*.md
├── Prototype/
│   ├── 00README.md
│   ├── 01GUIDE.md
│   ├── index.html
│   ├── pages/
│   └── assets/
├── Quality/
│   ├── 00README.md
│   ├── 01GUIDE.md
│   ├── gate.md
│   ├── realistic-tests.md
│   ├── anti-mock.md
│   ├── code-style.md
│   └── dependencies.md
├── Skills/
│   ├── 00README.md
│   ├── 01GUIDE.md
│   └── *.md
├── Workflows/
│   ├── 00README.md
│   ├── 01GUIDE.md
│   └── *.md
├── Templates/
│   ├── Full/
│   └── Quick/
├── apps/                # opcional — conforme stack
├── services/            # opcional — conforme stack
├── packages/            # opcional — conforme stack
├── src/                 # opcional — conforme stack
├── tests/               # opcional — conforme stack
├── scripts/             # opcional — conforme stack
└── .github/
    └── workflows/

Raiz:                  README.md, GUIDE.md
Pastas de governança:  00README.md, 01GUIDE.md
Artefatos em Docs/:    nomes curtos em minúsculo (project.md, plan.md, tasks.md)
Skills:                nome.md
Workflows:             nome.md
Templates Full:        nome-curto.md | .yaml | .json
Templates Quick:       mesmo nome do Full em Templates/Quick/

Governança (raiz):     PascalCase — Docs/, Skills/, Workflows/, Quality/, Templates/
Código executável:     kebab-case ou lowercase — src/, apps/, services/, packages/
Módulos de domínio:    kebab-case seguindo o nome da entidade/domínio

Tasks:      TASK-001, TASK-002, ...
Fases:      FASE-01, FASE-02, ...
Milestones: M1, M2, M3, ...
Entidades:  ENT-001, ENT-002, ...
Páginas:    PG-001, PG-002, ...
Fluxos:     FL-001, FL-002, ...

- Documento de governança não entra em pasta de código
- Documento oficial do projeto fora de Docs/ é inválido
- Script operacional não fica em pasta de testes sem justificativa
- Contrato de API é exclusivo de Docs/contract.yaml
- Nenhum conteúdo duplicado sem declaração explícita de fonte de verdade
- Protótipo de UI fica exclusivamente em Prototype/ — não em src/ ou apps/

Primeira task obrigatoriamente bootstrap_estrutural:
  - Criar a árvore completa prevista para o projeto
  - Incluir todos os arquivos de governança (README nos diretórios)
  - Criar GUIDE.md e estrutura de Docs/
 
A partir da segunda task — apenas edição:
  - Task de edição só modifica arquivos existentes
  - Jamais criar novo arquivo em task com política de edição
  - Novas pastas ou arquivos exigem task com política bootstrap_estrutural
 
Comprometimento por task:
  - Cada task concluída gera exatamente 1 commit
  - Toda task registra: hash, arquivos tocados, Quality Gate

- Estrutura deve ser verificável por script ou checklist
- Alteração estrutural atualiza structure.md e, quando necessário, plan.md/tasks.md
- Não concluir task com Quality Gate reprovado
- Manter compatibilidade de dependências conforme Quality/dependencies.md

- Antes de editar, localizar o arquivo oficial responsável pelo conteúdo
- Não criar novos caminhos em task de edição
- Toda alteração estrutural deve ser explícita e rastreável
- Em conflito entre documentos: seguir regra de precedência do framework
- Regra de precedência: GUIDE.md > Docs/ > Manual/ > Skills/ > Workflows/

( ) A árvore raiz está coerente com a estrutura canônica do framework
( ) Pastas de governança (Quality, Skills, Workflows) existem e estão completas
( ) Prototype/ existe para validação visual de fluxos
( ) Estrutura de código executável está definida (apps/, services/, packages/ ou src/)
( ) tests/ e scripts/ estão definidos quando aplicável
( ) Regra de bootstrap respeitada — toda árvore criada na task 001
( ) Regra de edição respeitada — nenhum arquivo novo fora de bootstrap
( ) Nenhum documento oficial salvo fora de Docs/

Este documento define:
  - onde cada coisa deve existir
  - como nomear arquivos, pastas e IDs
  - como evoluir sem degradar organização
 
Este documento evita:
  - crescimento desordenado
  - acoplamento estrutural acidental
  - perda de rastreabilidade entre tasks
 
Este documento exige:
  - consistência com arquitetura (Docs/architecture.md)
  - consistência com metodologia (bootstrap antes de edição)
  - consistência com qualidade (Quality Gate antes de fechar task)

Atue como SystemAgent.
Objetivo: criar Docs/structure.md com base em Docs/architecture.md
 
Carregue contexto base:
- GUIDE.md
- Skills/implementation.md
- Templates/Full/structure.md
- Docs/architecture.md
- Docs/stack.md
 
Preencha as 13 seções do template Full.
Seção 5: expanda a árvore canônica com as pastas de código do projeto (apps/, services/, src/)
         refletindo os módulos definidos em Docs/architecture.md seção 7.
Seção 6: adicione responsabilidades específicas das pastas de código do projeto.
Seção 7: adapte convenções de nomeação conforme a stack definida em Docs/stack.md.
Seção 12: verificar checklist antes de dar como pronto.

Docs/structure.md (aprovado)
    ↓
Docs/deploy.md   — pipeline alinhado com estrutura de pastas e scripts/
Docs/plan.md     — bootstrap estrutural é a primeira fase e primeira task
Docs/tasks.md    — TASK-001 é sempre bootstrap_estrutural baseado neste documento