documentar-projeto-laravel-vue

The full skill.

Original instructions from the publisher’s SKILL.md

# Documentar Projeto Laravel + Vue

## Objetivo
Gerar documentacao tecnica e funcional de requisitos do sistema, partindo de um caminho de pasta principal, com foco forte em:
- regras de negocio
- origem dos dados

A saida deve ser sempre um arquivo em Markdown.

## Entradas Esperadas
- `projectRootPath` (obrigatorio): caminho absoluto da pasta principal do projeto.
- `outputDocPath` (opcional): caminho do arquivo `.md` de saida.

Padrao quando `outputDocPath` nao for informado:
- `<projectRootPath>/docs/REQUISITOS_SISTEMA.md`

## Adaptacao Obrigatoria de Stack
Assumir:
- Backend: PHP Laravel (Controllers, UseCase, Gateway, Models)
- Frontend: Vue + Inertia

## Foco Principal (prioridade alta)
1. Regras de negocio (dominio, validacoes, restricoes, excecoes, permissoes).
2. Origem dos dados (DB, APIs externas, arquivos, imports, servicos terceiros).

## Escopo de Leitura Recomendado

### Backend (Laravel)
- routes/web.php
- app/Http/Controllers/**
- app/UseCase/**
- app/Gateway/**
- app/Models/**
- app/Exceptions/**
- database/migrations/**

### Frontend (Vue)
- resources/js/Pages/**
- resources/js/Components/**
- resources/js/Layouts/**
- chamadas HTTP via axios e rotas via route(...)

### Config e contexto
- `README.md`
- `composer.json`
- `package.json`
- `.env.example` (se existir)

## Processo Obrigatorio

### 1. Ler contexto do projeto
- identificar modulos funcionais e areas de negocio.
- identificar fluxos principais de entrada/saida.

### 2. Extrair regras de negocio
- mapear regras por modulo.
- registrar condicoes, validacoes e efeitos.
- mapear permissoes e controle de acesso.
- mapear excecoes e seus gatilhos.

### 3. Mapear origem dos dados
Para cada fluxo principal, identificar:
- origem de entrada (UI, API, arquivo, job, webhook).
- fonte persistente (tabelas e entidades).
- fontes externas (gateways/APIs).
- transformacoes e validacoes no caminho.
- destino final (resposta, tabela, arquivo, evento).

### 4. Gerar requisitos do sistema
Produzir requisitos claros, rastreaveis e verificaveis:
- requisitos funcionais
- requisitos de integracao
- requisitos de dados
- regras de negocio
- requisitos nao funcionais (seguranca, performance, observabilidade) quando houver evidencia

### 5. Escrever documento final em Markdown
Criar arquivo `.md` no caminho de saida definido.

## Estrutura Obrigatoria do Documento Markdown
Usar esta estrutura minima:

```markdown
# Requisitos do Sistema

## 1. Visao Geral
- objetivo do sistema
- escopo funcional
- stack principal (Laravel + Vue)

## 2. Contexto de Negocio
- dominios/modulos identificados
- atores e responsabilidades

## 3. Regras de Negocio
### 3.1 [Modulo X]
- RN-001: descricao da regra
- RN-002: descricao da regra

## 4. Origem e Fluxo dos Dados
### 4.1 [Fluxo X]
- entrada:
- origem primaria:
- validacoes:
- persistencia:
- saida:

## 5. Requisitos Funcionais
- RF-001: descricao
- RF-002: descricao

## 6. Requisitos de Integracao
- RI-001: descricao

## 7. Requisitos de Dados
- RD-001: entidade/tabela/campo relevante
- RD-002: regra de consistencia

## 8. Requisitos Nao Funcionais
- RNF-001: seguranca
- RNF-002: desempenho
- RNF-003: auditabilidade

## 9. Rastreabilidade (Regra -> Codigo)
- RN-001 -> `app/UseCase/...`
- RF-001 -> `app/Http/Controllers/...`
- RD-001 -> `database/migrations/...`, `app/Models/...`

## 10. Lacunas e Hipoteses
- itens sem evidencia clara no codigo
- hipoteses assumidas
```

## Modulos que devem ser priorizados neste projeto
- Dashboard financeiro e composicao previsto/realizado
- Previsto x Realizado (conciliacao manual e automatica)
- Importacao OFX
- Importacao/Exportacao de previstos por planilha
- Cadastros: usuarios, contas, instituicoes, categorias
- Anotacoes

## Regras de Qualidade da Documentacao
- Nao inventar regra sem evidencia.
- Registrar lacunas quando algo nao estiver claro.
- Citar caminho de arquivo para cada requisito relevante.
- Priorizar regras de negocio e fluxo de dados.

## Checklist de Entrega
- [ ] Caminho raiz (`projectRootPath`) utilizado na analise.
- [ ] Documento gerado em `.md` no caminho final.
- [ ] Regras de negocio detalhadas por modulo.
- [ ] Origem dos dados mapeada por fluxo.
- [ ] Requisitos funcionais e de dados documentados.
- [ ] Secao de rastreabilidade preenchida com paths reais.
- [ ] Lacunas explicitas sem suposicoes ocultas.

## Erros Comuns
- produzir documento generico sem citar regras reais.
- focar apenas em classes e ignorar regras de negocio.
- nao mapear origem de dados externos.
- nao gerar arquivo Markdown final (apenas resposta no chat).
- nao incluir rastreabilidade para o codigo-fonte.