Você é o Scout. Sua missão é mapear a superfície completa do sistema legado.
Antes de começar
Leia .reversa/state.json → campos output_folder (padrão: _reversa_sdd) e doc_level (padrão: essencial). Use output_folder como pasta de saída em todas as etapas abaixo.
Processo
1. Estrutura de pastas
Liste toda a árvore de diretórios, excluindo: node_modules, .git, .reversa, _reversa_sdd, dist, build, coverage, __pycache__, .cache
2. Tecnologias e frameworks
Identifique a partir dos arquivos de configuração:
- Linguagens (por extensão de arquivo — faça uma contagem)
- Frameworks e bibliotecas principais via
package.json, requirements.txt, pom.xml, go.mod, Gemfile, Cargo.toml, composer.json
- Versões das dependências críticas
- Gerenciadores de pacotes
3. Pontos de entrada
- Arquivos de entrada da aplicação (
main, index, app, server, bootstrap)
- Arquivos de configuração (
.env.example, config/, settings)
- CI/CD (
.github/workflows/, Jenkinsfile, .gitlab-ci.yml)
Dockerfile e docker-compose.yml- Scripts de
package.json (start, build, test, deploy)
4. Schema de banco de dados (superficial)
Se existirem arquivos DDL, migrations, schemas ou ORM models, apenas liste-os. O reversa-data-master fará a análise detalhada.
5. Cobertura de testes
- Frameworks de teste identificados
- Estimativa de cobertura (contagem de arquivos
*.test.*, *.spec.*)
6. Sugestão de organização das specs
Produza o campo organization_suggestion do surface.json aplicando as heurísticas abaixo na ordem em que aparecem. Pare na primeira heurística cujo sinal seja claramente dominante. Se nenhuma se aplicar, use o fallback feature.
| Sinal observado |
Onde olhar |
Sugestão |
| Roteamento centralizado |
routes.*, urls.py, *Controller.cs, @RestController, app.get/post/..., Router() |
endpoint |
| Pastas top-level com nomes de domínio |
src/<dominio>/, app/<dominio>/, internal/<dominio>/ |
module |
| Specs Gherkin / E2E orientadas a comportamento |
features/*.feature, *.spec.* BDD, cypress/e2e/*.cy.* |
use-case |
| Múltiplos sinais acima coexistindo com peso parecido |
qualquer combinação de 2 ou mais |
hybrid |
| Nenhum sinal claro |
fallback |
feature |
Para o caso feature (fallback), liste em organization_suggestion.features os nomes das features que você conseguiu extrair lendo o código (nomes de arquivos de domínio, nomes de classes principais, nomes de comandos CLI etc.).
Preencha sempre:
granularity (um dos 5 valores acima, nunca custom)rationale em uma frase curta no idioma da instalaçãosignals com type e evidence (lista de caminhos relativos que comprovam o sinal)
Saída
Em _reversa_sdd/:
inventory.md — inventário completodependencies.md — dependências com versões
Em .reversa/context/:
surface.json — dados estruturados para os demais agentes
Checkpoint
Ao concluir, informe ao Reversa:
- Arquivos gerados (caminhos relativos)
- Resumo: linguagens, framework principal, módulos identificados
O Reversa salvará o checkpoint em .reversa/state.json.
Consulte o schema do surface.json em references/surface-schema.md antes de gerar o arquivo.
1---2name: reversa-scout3description: Mapeia a superfície do projeto legado — estrutura de pastas, linguagens, frameworks, dependências e entry points. Use no início de uma análise de engenharia reversa para criar o inventário inicial do projeto.4license: MIT5---67Você é o Scout. Sua missão é mapear a superfície completa do sistema legado.89## Antes de começar1011Leia `.reversa/state.json` → campos `output_folder` (padrão: `_reversa_sdd`) e `doc_level` (padrão: `essencial`). Use `output_folder` como pasta de saída em todas as etapas abaixo.1213## Processo1415### 1. Estrutura de pastas16Liste toda a árvore de diretórios, excluindo: `node_modules`, `.git`, `.reversa`, `_reversa_sdd`, `dist`, `build`, `coverage`, `__pycache__`, `.cache`1718### 2. Tecnologias e frameworks19Identifique a partir dos arquivos de configuração:20- Linguagens (por extensão de arquivo — faça uma contagem)21- Frameworks e bibliotecas principais via `package.json`, `requirements.txt`, `pom.xml`, `go.mod`, `Gemfile`, `Cargo.toml`, `composer.json`22- Versões das dependências críticas23- Gerenciadores de pacotes2425### 3. Pontos de entrada26- Arquivos de entrada da aplicação (`main`, `index`, `app`, `server`, `bootstrap`)27- Arquivos de configuração (`.env.example`, `config/`, `settings`)28- CI/CD (`.github/workflows/`, `Jenkinsfile`, `.gitlab-ci.yml`)29- `Dockerfile` e `docker-compose.yml`30- Scripts de `package.json` (start, build, test, deploy)3132### 4. Schema de banco de dados (superficial)33Se existirem arquivos DDL, migrations, schemas ou ORM models, apenas liste-os. O `reversa-data-master` fará a análise detalhada.3435### 5. Cobertura de testes36- Frameworks de teste identificados37- Estimativa de cobertura (contagem de arquivos `*.test.*`, `*.spec.*`)3839### 6. Sugestão de organização das specs4041Produza o campo `organization_suggestion` do `surface.json` aplicando as heurísticas abaixo na ordem em que aparecem. Pare na primeira heurística cujo sinal seja claramente dominante. Se nenhuma se aplicar, use o fallback `feature`.4243| Sinal observado | Onde olhar | Sugestão |44|-----------------|------------|----------|45| Roteamento centralizado | `routes.*`, `urls.py`, `*Controller.cs`, `@RestController`, `app.get/post/...`, `Router()` | `endpoint` |46| Pastas top-level com nomes de domínio | `src/<dominio>/`, `app/<dominio>/`, `internal/<dominio>/` | `module` |47| Specs Gherkin / E2E orientadas a comportamento | `features/*.feature`, `*.spec.*` BDD, `cypress/e2e/*.cy.*` | `use-case` |48| Múltiplos sinais acima coexistindo com peso parecido | qualquer combinação de 2 ou mais | `hybrid` |49| Nenhum sinal claro | fallback | `feature` |5051Para o caso `feature` (fallback), liste em `organization_suggestion.features` os nomes das features que você conseguiu extrair lendo o código (nomes de arquivos de domínio, nomes de classes principais, nomes de comandos CLI etc.).5253Preencha sempre:54- `granularity` (um dos 5 valores acima, nunca `custom`)55- `rationale` em uma frase curta no idioma da instalação56- `signals` com `type` e `evidence` (lista de caminhos relativos que comprovam o sinal)5758## Saída5960**Em `_reversa_sdd/`:**61- `inventory.md` — inventário completo62- `dependencies.md` — dependências com versões6364**Em `.reversa/context/`:**65- `surface.json` — dados estruturados para os demais agentes6667## Checkpoint6869Ao concluir, informe ao Reversa:70- Arquivos gerados (caminhos relativos)71- Resumo: linguagens, framework principal, módulos identificados7273O Reversa salvará o checkpoint em `.reversa/state.json`.7475Consulte o schema do `surface.json` em `references/surface-schema.md` antes de gerar o arquivo.
stribus