feat(core): Adiciona funcionalidades e documentação de valuation

.prettierignore

@@ -63,4 +63,10 @@ tmp
 .env.*.local
 
 # Playground
-.playground
+.playground
+
+# Changelog
+CHANGELOG.md
+
+# GitHub
+.github

.windsurf/rules/architecture.md

@@ -0,0 +1,97 @@
+---
+description: Regras de arquitetura do projeto IBAV
+---
+
+# IBAV - Architecture Rules
+
+## Nuxt
+
+- O projeto utiliza Nuxt 4. Sempre verifique `nuxt.config.ts` antes de modificar configurações.
+- A data de compatibilidade está em `nuxt.config.ts`. Não altere sem necessidade.
+- Não adicione módulos automaticamente. Verifique `package.json` e `nuxt.config.ts` existentes.
+
+## Vue
+
+- Vue 3 Composition API é o padrão do projeto.
+- `<script setup>` é preferido para novos componentes.
+- Não crie componentes Options API sem justificativa técnica.
+
+## TypeScript
+
+- TypeScript é obrigatório para arquivos `.ts` e `<script setup lang="ts">`.
+- Evite `any`. Prefira tipos explícitos.
+- Aproveite a inferência de tipos do Nuxt e Vue quando segura.
+- Mantenha `tsconfig.json` e configurações geradas por Nuxt (`.nuxt/tsconfig.*.json`).
+
+## SSR
+
+- O projeto suporta SSR por padrão.
+- Composables e código executado no servidor devem respeitar as diferenças entre cliente e servidor.
+- Evite acessar APIs do navegador (`window`, `document`) sem `onMounted` ou verificação de `process.client`.
+
+## Client / Server
+
+- APIs server-side vivem em `server/`.
+- Lógica compartilhada pode usar `shared/` quando apropriado.
+- `app/` contém a aplicação Vue/Nuxt.
+- `public/` contém assets estáticos.
+
+## Composables
+
+- Use `composables/` para lógica reutilizável entre componentes.
+- Nomeie com `use*` e exporte como função nomeada.
+- Documente entradas, saídas e efeitos colaterais quando relevante.
+
+## Components
+
+- Componentes Vue em `app/components/` (ou `components/` se configurado).
+- Nome em PascalCase. Não crie componentes de uma única palavra sem necessidade.
+- Reutilize componentes existentes antes de criar novos.
+
+## Pages
+
+- Pages em `app/pages/` (ou `pages/` se configurado).
+- Use `vue-router` (via Nuxt) para navegação.
+- Cada página deve ter responsabilidade única.
+
+## Layouts
+
+- Layouts em `app/layouts/` (se existir).
+- Não crie layout novo se um existente já atender.
+
+## Plugins
+
+- Plugins em `app/plugins/` (se existir).
+- Registre em `nuxt.config.ts` se necessário.
+
+## Server
+
+- Server routes e middlewares em `server/`.
+- Valide entradas nas APIs.
+- Retorne respostas consistentes e com tipos claros.
+
+## Utils
+
+- Funções utilitárias puras em `app/utils/` ou `utils/`.
+- Prefira funções pequenas, testáveis e sem efeitos colaterais.
+
+## Configuração
+
+- `nuxt.config.ts` é a fonte de verdade para configuração do Nuxt.
+- `vitest.config.ts` para configuração de testes.
+- `eslint.config.mjs` para regras de lint.
+- `.prettierrc` para formatação.
+- `tsconfig.json` deve ser respeitado.
+
+## Imports
+
+- Utilize auto-imports do Nuxt quando disponível.
+- Imports explícitos são aceitáveis quando evitam conflitos ou melhoram clareza.
+
+## Reutilização de código
+
+- Antes de criar uma nova abstração:
+  - Procure por algo equivalente.
+  - Entenda a arquitetura atual.
+  - Reutilize o padrão existente quando possível.
+- Não crie arquitetura nova apenas por preferência.

.windsurf/rules/project.md

@@ -0,0 +1,82 @@
+---
+description: Regras permanentes do projeto IBAV
+---
+
+# IBAV - Project Rules
+
+## Nome do projeto
+
+IBAV (Instituto Brasileiro de Avaliação Veicular)
+
+## Stack
+
+- Nuxt 4
+- Vue 3
+- Vue Router
+- TypeScript
+- Nuxt UI
+- Nuxt Content
+- Nuxt Image
+- Nuxt SEO Utils
+- Vitest
+- Vue Test Utils
+- Nuxt Test Utils
+- ESLint (@nuxt/eslint-config)
+- Prettier
+- Changelogen
+- pnpm
+
+## Package manager
+
+O projeto utiliza **pnpm**.
+
+- Use `pnpm` para instalar, remover, atualizar ou executar scripts.
+- Nunca use `npm`, `yarn` ou `bun` a menos que o usuário solicite explicitamente.
+
+## Scripts disponíveis
+
+Verifique o `package.json` antes de sugerir qualquer comando. Scripts atuais:
+
+- `pnpm build`
+- `pnpm dev`
+- `pnpm generate`
+- `pnpm preview`
+- `pnpm postinstall`
+- `pnpm lint`
+- `pnpm test`
+- `pnpm test:watch`
+- `pnpm test:debug`
+- `pnpm format`
+- `pnpm format:check`
+
+Não invente scripts como `pnpm typecheck`, `pnpm test:unit`, `pnpm check` ou `pnpm validate`.
+
+## Localização da documentação
+
+- Documentação principal: `docs/docs.md`
+- Especificações técnicas: `docs/specs/`
+- Documentação pública: `docs/content/`
+
+## Fonte de verdade
+
+- `package.json` é a fonte de verdade para:
+  - Nome e versão do projeto
+  - Dependências e devDependencies
+  - Scripts
+  - Stack e versões
+- `docs/docs.md` é a fonte de verdade para a documentação pública do produto.
+
+## Convenções gerais
+
+- Trate `package.json` como fonte de verdade para dependências, scripts e stack.
+- Não hardcode versões de pacotes em Workflows ou Rules.
+- Não invente dependências, scripts ou configurações.
+- Caso um arquivo não exista, ignore-o. Não crie suposições.
+- Sempre consulte `package.json` e `docs/docs.md` antes de propor mudanças.
+
+## Regras de execução
+
+- Uma tarefa por vez.
+- Pare após cada tarefa e aguarde aprovação explícita do usuário.
+- Não continue automaticamente.
+- Não execute a próxima tarefa sem instrução explícita.

.windsurf/rules/quality.md

@@ -0,0 +1,73 @@
+---
+description: Regras de qualidade do projeto IBAV
+---
+
+# IBAV - Quality Rules
+
+## TypeScript strict
+
+- Utilize tipos explícitos e evite `any`.
+- Prefira interfaces e tipos nomeados.
+- Mantenha consistência com as configurações de `tsconfig.json`.
+
+## Código simples
+
+- Funções pequenas com responsabilidade única.
+- Máxima clareza sobre máxima abstração.
+- Evite lógica desnecessária.
+
+## Responsabilidades claras
+
+- Um componente, composable ou função deve ter um propósito claro.
+- Separe lógica de apresentação quando apropriado.
+
+## Evitar duplicação
+
+- Extraia funções comuns para `utils/` ou `composables/`.
+- Não copie e cole código em vários locais.
+
+## Testes
+
+- Novos comportamentos devem receber testes quando aplicável.
+- Os testes vivem em `test/**/*.{test,spec}.{js,ts}`.
+- Não modifique testes apenas para fazer a implementação passar.
+- Se um teste estiver incorreto, explique o motivo antes de alterá-lo.
+
+## Lint
+
+- O comando `pnpm lint` executa `eslint . --fix`.
+- Como o `--fix` modifica arquivos, verifique `git diff` após a execução.
+- Não execute lint indiscriminadamente em tarefas que possam afetar arquivos fora do escopo.
+
+## Formatação
+
+- Use `pnpm format:check` para validação.
+- Use `pnpm format` somente quando necessário corrigir formatação.
+- Verifique `git diff` após `pnpm format`.
+
+## Build
+
+- Considere `pnpm build` como validação quando alterar:
+  - `nuxt.config.ts`
+  - módulos
+  - plugins
+  - pages
+  - server
+  - configuração de build
+  - runtime
+  - imports
+  - SSR
+  - componentes críticos
+- Não execute build desnecessariamente para alterações puramente documentais.
+
+## Alterações mínimas
+
+- Uma tarefa deve modificar apenas o código necessário para o seu objetivo.
+- Não refatore código não relacionado.
+- Problemas encontrados fora do escopo devem ser reportados, não corrigidos automaticamente.
+
+## Validação
+
+- As validações devem ser baseadas exclusivamente em scripts existentes em `package.json`.
+- Antes de executar qualquer comando, verifique se ele existe no `package.json`.
+- Não crie comandos fictícios como `pnpm typecheck`.

.windsurf/workflows/core/analyze-product.md

@@ -0,0 +1,33 @@
+---
+description: Analyze the product and existing project context
+---
+
+# /analyze-product
+
+## Purpose
+
+Understand the project, its goals, and existing architecture before proposing any change.
+
+## Steps
+
+1. Read `package.json` to understand the project name, version, stack, dependencies, and scripts.
+2. Read `docs/docs.md` to understand the product goals and domain.
+3. Read `README.md` for the public description.
+4. List `app/`, `server/`, `shared/`, `test/`, `public/`, and `docs/`.
+5. Read `nuxt.config.ts`, `tsconfig.json`, `vitest.config.ts`, `eslint.config.mjs`, and `.prettierrc` if they exist.
+6. Identify the current architecture, patterns, and conventions.
+7. Summarize findings without proposing implementation.
+
+## Output
+
+- Project overview
+- Stack and versions (from `package.json`)
+- Main documentation location
+- Current architecture and conventions
+- Known risks or ambiguities
+
+## Constraints
+
+- Do not invent dependencies or scripts.
+- Do not modify production code.
+- Do not create specifications at this stage unless requested.

.windsurf/workflows/core/create-spec.md

@@ -0,0 +1,67 @@
+---
+description: Create a detailed specification for a feature
+---
+
+# /create-spec <feature-name>
+
+## Purpose
+
+Create a complete specification for a new feature or change.
+
+## Steps
+
+1. Read `package.json`.
+2. Read `docs/docs.md`.
+3. List and analyze the current project structure.
+4. Read files related to the feature area.
+5. Identify existing patterns and conventions.
+6. Identify risks and ambiguities.
+7. Create the spec file at `docs/specs/<feature-name>.md`.
+
+## Spec template
+
+```markdown
+# <Feature>
+
+## Problem
+
+## Goal
+
+## Scope
+
+## Non-goals
+
+## Current Architecture
+
+## Proposed Solution
+
+## Functional Requirements
+
+## Technical Requirements
+
+## Data Flow
+
+## API / Interfaces
+
+## Error Handling
+
+## Testing Strategy
+
+## Documentation
+
+## Acceptance Criteria
+
+- [ ] ...
+
+## Risks
+
+## Open Questions
+```
+
+## Critical rule
+
+- After creating the spec: **STOP**.
+- Do not create tasks.
+- Do not implement code.
+- Do not modify production files.
+- Wait for explicit user approval before running `/create-tasks`.