# Evolução do simulador investeMoz — diagnóstico e progresso **Actualizado:** 2026-10-04 Auditoria de conclusão mais recente: [completion-audit-2026-10-04.md](completion-audit-2026-10-04.md). A suite PHP completa foi repetida em 2026-10-04 e passou 253/253 (2.590 asserções); frontend 124/124 e TypeScript passaram. Gates legais, SuiteCRM real e validação manual permanecem abertos. **Branch observada:** `main` (`4f35313`, `novas funcionalidades dos formulario`) **Âmbito:** sequência do pedido “Evolução sequencial do simulador multiuso da investeMoz”. Este documento regista evidência de código; não aprova regras fiscais, jurídicas, financeiras ou de produto. ## Resumo executivo O simulador público em `/simulador-fiscal` (alias `/Simulador`) passou a oferecer percursos por perfil e nível de detalhe, calculadoras financeiras educativas, projecção de tesouraria e plano financeiro empresarial com pressupostos exportáveis em CSV. Uma execução concluída pode agora ser copiada para o rascunho de investimento mediante consentimento explícito, preservando a versão e o relatório original. O contrato de resultados distingue cálculo, estimativa, indeterminação e não aplicabilidade. Para utilizadores anónimos, dados pessoais não são enviados nem devolvidos pelo fluxo de rascunho. A sequência não está totalmente concluída. Foram localizados catálogos oficiais e páginas de referência para legislação tributária, INSS, pauta aduaneira e câmbio, mas o texto consolidado, âmbito, vigência e aprovação dos parâmetros continuam por confirmar. Por isso, regras fiscais, contribuições, incentivos e alfândega permanecem indeterminados. A conversão para o rascunho está implementada parcialmente; integração/submissão real de projecto/CRM continua indisponível. A suíte automatizada PostgreSQL/PostGIS passou em base isolada; revisão manual de acessibilidade e validação de produto continuam pendentes. ## Estado do repositório e evidência de base - Aplicação Laravel 13.30.1, PHP CLI 8.5.11, React 19, Inertia 3, TypeScript 5.7 e Vite 8. PostgreSQL/PostGIS é usado pelo domínio/CI; `.env.example` agora indica PostgreSQL 5432 e papel de aplicação sem privilégios elevados, com PostGIS pré-provisionado. - O formulário existente guarda rascunhos e submete cálculos à API. O endpoint genérico existente recebe `base`, `rate` e `reduction`; `app/Jobs/RunSimulation.php` calcula a fórmula aritmética correspondente, não um motor para tributos moçambicanos. - Os documentos externos listados no pedido não estavam disponíveis nos caminhos Windows correspondentes. Não foram inventadas taxas ou regras a partir dos nomes desses ficheiros. - Na fase inicial da auditoria, `.env` e a base local não foram consultados. Em 2026-10-03, uma execução PHPUnit mal direccionada atingiu `investmoz_test:5432` e iniciou `migrate:fresh`, interrompida ao encontrar `skills_edu`; o risco de dados está descrito no registo de incidente abaixo. A suite foi depois executada em QA isolado na porta 55441. Nenhuma credencial foi exposta ao utilizador ou integração externa activada. ### Alinhamento de etapas com o anexo actual Este relatório segue a sequência do anexo “Evolução sequencial do simulador multiuso”: motor fiscal na Etapa 5, incentivos/extensões (incluindo aduaneiro e cambial) na Etapa 10 e verificação global na Etapa 11. Os documentos existentes `simulations/stage-10-gate.md` e `simulations/stage-11-gate.md` foram criados para pedidos anteriores e usam a numeração “Etapa 10 — motor fiscal” e “Etapa 11 — aduanas/câmbio”; foram acrescentadas notas de correspondência nos dois gates para evitar confundir o âmbito antigo com esta sequência. ## Reconciliação resumida mais recente (2026-10-03) Esta tabela substitui os estados/resumos anteriores quando divergirem; o detalhe histórico permanece abaixo. | Etapa | Estado técnico actual | Próxima lacuna determinante | | -------------------------------- | ------------------------------------------------------------------ | --------------------------------------------------------------------------------- | | 0 — diagnóstico | Concluída | Revisão manual de produto. | | 1 — contrato/API | Concluída tecnicamente | Aceitação operacional geral. | | 2 — jornadas/formulário | Parcial; validação automatizada extensa | Leitor de ecrã/dispositivo físico e revisão humana após o novo modo fiscal. | | 3 — calculadoras | Parcial, educativas | Revisão financeira institucional e necessidades pessoais adicionais. | | 4 — fontes/governação | Parcial; gate legal pendente | Textos integrais BR 186/187, parâmetros/fontes restantes e aprovação Fiscalista. | | 5 — motor fiscal | DSL, DAG e resolvedor internos parciais; cálculo público bloqueado | Leitura segura/RLS, integração de snapshots/explicação e casos fiscais aprovados. | | 6 — plano empresarial | Parcial, implementado em grande parte | Validação contabilística e cenários de incumprimento/fornecedores partilhados. | | 7 — ponte fiscal | Parcial; matéria colectável indeterminada | Classificação fiscal aprovada; manter sem imposto conclusivo. | | 8 — resultados/exportação | Parcial; CSV e snapshots implementados | Revisão assistiva; PDF não requerido pelo anexo. | | 9 — conta/Project/CRM | Parcial | Submissão real a Project/CRM e revisão do fluxo institucional. | | 10 — incentivos/aduaneiro/câmbio | Bloqueada para cálculo legal | Pauta/anexos íntegros, origem/câmbio e regras oficiais aprovadas. | | 11 — regressão/entrega | Regressão automatizada aprovada; etapa parcial | Aceitação manual/assistiva, incidente QA histórico e gates institucionais. | Regressao global mais recente: PHP 250/250 (2.582 assertions), frontend 115/115, TypeScript/PHPStan (0 erros), Pint e build (2.397 modulos) aprovados; smoke Edge em QA marcado passou. Leitor de ecrã/dispositivo e fontes fiscais continuam pendentes. ## Matriz das etapas | Etapa | Estado | Implementado/evidência | Lacunas e dependências | | -------------------------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 0 — diagnóstico | Concluída | Inspecção da estrutura, rotas, formulário, API, gates e testes; este registo actualizado. | Auditoria manual de UX não substitui validação com utilizadores. | | 1 — arquitectura e contrato | Parcial concluída | `resources/js/lib/simulation-contract.ts` e `docs/investmoz/simulations/data-contracts.md` definem valores decimais como strings, contexto versionado, moeda e estados explícitos; testes cobrem invariantes. | Contrato ainda não aplicado a todas as respostas/persistência da API. | | 2 — jornadas e formulário | Parcial | Percursos por perfil, menu/página pública, combobox por teclado e privacidade anónima; Edge desktop e mobile confirma layout sem overflow global e sem CTA sobre inputs. | Teste real com teclado/leitor de ecrã/dispositivo, revisão de produto e simplificação dos percursos partilhados continuam pendentes. | | 3 — calculadoras | Parcial | Orçamento, prestações/amortização, taxas nominais/efectivas, margem, break-even, défice de financiamento e cronograma de crédito; precisão monetária em cêntimos. | Estimativas educativas; não integram ofertas de credores nem cobrem todo o orçamento pessoal. | | 4 — fontes/governação fiscal | Parcial; gate bloqueado | Criado `docs/investmoz/simulations/official-source-register.md` com catálogos/páginas oficiais candidatos para AT, INSS, pauta aduaneira e câmbio e as lacunas de verificação. Nenhuma regra nova activada. | Textos integrais/consolidados, anexos, vigência, `scope_key`, classificação, parâmetros e aprovação do Fiscalista ainda pendentes. Gate humano necessário. | | 5 — motor fiscal | Bloqueada para cálculo | `simulation-fiscal-status.tsx` mantém IRPS, INSS, IVA, IRPC, ISPC e retenções como indeterminados sem regra aprovada. | Sem fórmulas/valores fiscais públicos. O endpoint aritmético genérico não é motor fiscal. | | 6 - plano empresarial | Parcial | Projecao mensal com agendas por produto para unidades, precos, custos, stock, encomendas, recepcao e parcelas de pagamento a fornecedores; recebiveis, despesas, pessoal, financiamento e tesouraria; snapshots v1-v16 e CSV testados. | Nao modela incumprimento nem fornecedores partilhados; validacao contabilistica institucional pendente. | | 7 — integração financeira/fiscal | Parcial | Ponte valida reconciliação contabilística, origens das cobranças, movimentos de recebíveis, pagamentos, fluxo líquido e saldos de caixa por mês. Matéria colectável continua indeterminada. | Classificação de dedutibilidade, ajustamentos e regras fiscais aprovadas ainda faltam; sem total fiscal ou aconselhamento conclusivo. | | 8 — resultados e exportação | Parcial | CSV local para calculadoras, fluxo de caixa, plano e resultado aritmético concluído; inclui pressupostos, fórmulas, períodos, moeda ou ausência, fontes e limitações, sem dados pessoais; células neutralizam fórmulas de folha de cálculo. | Sem PDF/relatório assinado nem arquivo imutável; moeda fiscal e parâmetros legais continuam indisponíveis. | | 9 — conta, projecto e CRM | Parcial | Conversão consentida, hash/versão íntegros, ETag e deduplicação; histórico paginado pessoal e de organizações com membership activa; regressões API/RLS executadas em PostgreSQL isolado. | Project/CRM não é submetido; revisão manual e validação do fluxo real de projecto pendentes. | | 10 — incentivos/extensões | Bloqueada para regras | Nenhuma elegibilidade, benefício ou taxa sectorial presumida. A AT identifica uma Pauta de Serviço 2026 pesquisável com 5.822 códigos e anuncia Excel/PDF; nenhum ficheiro foi obtido ou parametrizado. | Faltam ficheiro/hashes e reconciliação integral da pauta, origem/preferências, fontes cambiais e sectoriais versionadas; extensões continuam inactivas. | | 11 — verificação/entrega | Parcial | PHPUnit completo 230/230 (2.282 assertions), PHPStan global 0 erros, Pint dirigido, suite frontend, TypeScript, OpenAPI JSON e build Vite isolado passaram em 2026-10-03. | Sessão manual de acessibilidade/browser, integração real CRM/projecto e gates fiscais continuam pendentes; incidente `investmoz_test:5432` aguarda comparação com backup. | ### Etapa 11 — checklist de verificação global | Área pedida no anexo | Evidência actual | Estado | | ------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------- | | Fórmulas, precisão, escalões e vigência | Testes isolados cobrem fórmulas financeiras, cêntimos e cenários; escalões e vigência fiscais continuam sem fonte/parâmetros aprovados. | Parcial; fiscal bloqueado | | Ausentes, zero e negativos; créditos, benefícios e incompatibilidades | Contrato e calculadoras testam estados explícitos, zero, défices/valores negativos e denominadores inválidos; créditos/benefícios fiscais não são calculados. | Parcial | | Empréstimos, financiamento e tesouraria | Testes frontend cobrem juros zero, taxas nominais/efectivas, reembolso, reconciliação de financiamento e fluxo de caixa mensal. | Coberto em código/testes isolados | | Permissões, privacidade e duplicados | 2 testes unitários e 8 feature passaram com PostgreSQL/PostGIS sob papel sem SUPERUSER; incluem token alheio, consentimento, hash/versão, deduplicação, revogação e tombstone RLS. | Coberto em código/testes; CRM pendente | | Formulários públicos/autenticados, navegação, acessibilidade e telemóvel | Build e typecheck passaram; pesquisa com label/nome acessível foi corrigida e JSX-a11y dirigido não reporta campos sem rótulo. Sem sessão real de browser, leitor de ecrã ou dispositivo móvel. | Parcial; manual pendente | | Exportação, reprodução e regressão existente | CSV e snapshots têm testes frontend; build client passou. Suite PostgreSQL total: 219/223; quatro falhas remanescentes estão em Educação e rollback de migrações empresariais. | Parcial; fora do escopo actual | | Abuso de endpoints e logs sem PII | Endpoints de rascunho usam middleware de throttling e auditoria com metadados mínimos; revisão estática feita, sem teste de carga/abuso nem feature suite executada. | Parcial | ## Alterações por ficheiro - `resources/js/lib/simulation-contract.ts`, `docs/investmoz/simulations/data-contracts.md`: contrato comum de resultados, precisão, moeda e estados. - `resources/js/lib/simulation-form.ts`, `resources/js/components/simulation-form.tsx`, `resources/js/pages/PortalInvestidor.tsx`: jornadas e níveis de detalhe, ligação pública e apresentação de ferramentas. - `resources/js/pages/PortalInvestidor.tsx`, `resources/js/components/simulation-financial-tools.tsx`, `resources/js/components/simulation-cashflow-planner.tsx`, `resources/js/components/simulation-business-plan.tsx`: melhorias de nomes/associações acessíveis para pesquisa e opções de moeda. - `resources/js/lib/financial-calculators.ts`, `resources/js/components/simulation-financial-tools.tsx`: cálculos financeiros educativos em precisão exacta de cêntimos e relatório CSV local das ferramentas. - `resources/js/lib/monthly-cashflow.ts`, `resources/js/components/simulation-cashflow-planner.tsx`: tesouraria mensal e CSV local. - `resources/js/lib/business-financial-plan.ts`, `resources/js/components/simulation-business-plan.tsx`: plano empresarial, snapshot versionado, cenários, conversão cambial declarada e CSV. - `resources/js/lib/business-financial-plan.ts`, `resources/js/components/simulation-business-plan.tsx`, `tests/frontend/business-financial-plan.test.mjs`, `docs/investmoz/simulations/data-contracts.md`: movimento agregado de existências, prazo fixo de entrega, reconciliação de encomendas/recepções/stock em trânsito, falta declarada, compatibilidade de snapshots v1/v2/v3. - `resources/js/lib/financial-fiscal-bridge.ts`, `resources/js/components/simulation-business-plan.tsx`, `tests/frontend/financial-fiscal-bridge.test.mjs`: ponte por período entre resultado contabilístico e linhas candidatas fiscais, calendário de caixa separado e matéria colectável explicitamente indeterminada. - `resources/js/lib/simulation-form.ts`, `resources/js/components/simulation-form.tsx`, `tests/frontend/simulation-form.test.mjs`: exportação CSV do cálculo genérico concluído, versionado, sem dados pessoais e com moeda/fonte ausentes claramente indicadas. - `resources/js/components/simulation-fiscal-status.tsx`: apresentação explícita de tributos indeterminados sem valores fictícios. - `docs/investmoz/simulations/official-source-register.md`: registo de fontes oficiais candidatas e passos de validação fiscal/aduaneira; não activa parâmetros. - `docs/investmoz/simulations/stage-10-gate.md`, `docs/investmoz/simulations/stage-11-gate.md`: notas de correspondência documentam que a numeração desses gates é histórica face ao anexo actual. - `docs/investmoz/simulations/data-contracts.md`: compatibilidade de snapshots `business-plan-v1` a `business-plan-v6` e contratos do movimento de existências e cobrança. - `app/Services/SimulationFormDraftPrivacyPolicy.php`, `app/Services/SimulationFormDrafts.php`, `app/Http/Controllers/Api/V1/SimulationFormDraftController.php`, `app/Http/Requests/StoreSimulationFormDraftRequest.php`: filtragem e apresentação sem dados pessoais para rascunhos anónimos; validação dos novos campos económicos. - `app/Http/Requests/AttachSimulationToDraftRequest.php`, `routes/api.php`, `app/Http/Controllers/Api/V1/SimulationFormDraftController.php`, `app/Services/SimulationFormDrafts.php`: endpoint de conversão consentida, controlo de proprietário/token e permissão organizacional, snapshot cifrado, hash, evento de auditoria, idempotência e ETag; remoção da cópia quando o utilizador muda o consentimento para “não”. - `tests/frontend/*.test.mjs` (ficheiros específicos indicados abaixo), `tests/Feature/SimulationFormDraftTest.php`, `tests/Unit/SimulationFormDraftPrivacyPolicyTest.php`: cobertura de contrato, jornadas, cálculos, plano, exportação e privacidade. Nenhuma migration, configuração de ambiente, dado persistido ou integração externa foi alterada. A política impede gravação pessoal nova em rascunho anónimo e oculta dados pessoais de registos anónimos na resposta; eventuais snapshots históricos anteriores não foram apagados e requerem decisão própria de retenção/limpeza. ## Testes e comandos executados - `node --test tests/frontend/business-financial-plan.test.mjs tests/frontend/financial-calculators.test.mjs tests/frontend/monthly-cashflow.test.mjs tests/frontend/simulation-contract.test.mjs tests/frontend/simulation-form.test.mjs tests/frontend/simulator-entry.test.mjs tests/frontend/territory-path.test.mjs tests/frontend/portal-api.test.mjs` — **56 passaram, 0 falharam** (inclui exportação e separação dos snapshots de conversão). - `& 'C:\laragon\bin\php\php-8.5.11-Win32-vs17-x64\php.exe' vendor/phpunit/phpunit/phpunit --configuration phpunit.xml tests/Unit/SimulationFormDraftPrivacyPolicyTest.php` — **2 passaram, 2 asserções**. Teste unitário isolado, sem DB. - `npm.cmd run types:check` — passou (`tsc --noEmit`). - Build de produção isolado: `node_modules/.bin/vite.cmd build --configLoader runner --outDir --emptyOutDir`, com PHP 8.5.11 no `PATH` apenas para esse processo — **passou**, 2.386 módulos transformados e 107 ficheiros gerados; a saída foi removida da pasta temporária criada. O `fontaine` opcional está ausente, produzindo apenas aviso de optimização de fontes. - `npm.cmd run check` — não passou da resolução de config: Vite+ tentou criar `node_modules/.vite-temp/vite.config.ts.timestamp-…mjs` e recebeu `EPERM`. O `vite build` directo com `--configLoader runner` contornou essa escrita e compilou; ACLs e processos não foram alterados. - Lint PHP do novo request, serviço, controller e teste feature — sem erros de sintaxe. - `git diff --check` — passou, com aviso de normalização CRLF/LF em `simulation-form.tsx`. - Não foi executada a suite PHPUnit/PostgreSQL: `tests/TestCase.php` chama `DROP SCHEMA ... CASCADE` e outras remoções quando host é local, base `investmoz_test` e porta `55441`. `Test-NetConnection 127.0.0.1:55441` devolveu `False`; não redireccionei os testes para outra base/porta. ### Continuação — exportação das calculadoras financeiras - A Etapa 8 foi ampliada com `exportFinancialToolsCsv` e o botão “Exportar resultados em CSV” nas ferramentas públicas. O relatório inclui data/hora, versão do modelo, moeda, período do orçamento/custos fixos, entradas, fórmula, totais, estado indicativo, limitações e o plano detalhado de reembolso. - O CSV corresponde às fórmulas já exibidas e é gerado no navegador, sem autenticação, envio ao servidor ou dados pessoais. Rótulos introduzidos pelo utilizador que poderiam ser interpretados como fórmulas de folha de cálculo são neutralizados. - O período mensal/trimestral/anual/outro é explicitado e também rotula os custos fixos usados no ponto de equilíbrio; o utilizador deve escolher o mesmo período para valores comparáveis. - `node --test tests/frontend/financial-calculators.test.mjs` — **10 passaram, 0 falharam**; `npm.cmd run types:check` — passou. A regressão frontend completa com a nova cobertura passou com **56/56**. ### Etapa 9 — conversão consentida para rascunho (parcial) - `SimulationController::show` verifica proprietário/permissão ou token anónimo; `SimulationPolicy` controla visualização/alteração autenticada. `SimulationFormDrafts` cifra snapshots e aplica ETag/controlo de versão. - Criados `POST /api/v1/simulation-drafts/{id}/conversions` e consentimento específico antes de anexar. O servidor verifica proprietário/token da execução, estado concluído, relatório versionado, permissão para resultados organizacionais e ETag do rascunho; copia apenas `base`, `rate`, `reduction`, fórmula, resultado e relatório, sem identificadores pessoais. - O snapshot mantém `simulation_id`, versões, hashes e instante do consentimento dentro do snapshot económico cifrado. Uma segunda chamada para a mesma execução não duplica nem aumenta a versão. A acção é registada em `simulation_audit_events`; escolher “não” no campo de reutilização remove a cópia do rascunho. - Antes de anexar, o servidor agora exige hash SHA-256 válido, confere-o contra a representação JSONB canónica do PostgreSQL e verifica que o snapshot do relatório é igual ao resultado da execução. Relatório inconsistente ou adulterado devolve conflito; foram acrescentadas regressões para divergência e hash incorrecto. - O resultado `portal-tax-arithmetic-v1` continua a declarar `legal_interpretation=false`. Esta acção anexa a referência ao rascunho de investimento; não cria Project, não submete a CRM e não declara aprovação institucional. - Testes feature de consentimento, hash/versão, duplicação, revogação e token de outra sessão foram adicionados a `tests/Feature/SimulationFormDraftTest.php`, mas não executados devido ao gate da base de teste PostgreSQL descartável. ### Continuação — verificação da implementação e fontes oficiais - `node --test tests/frontend/business-financial-plan.test.mjs tests/frontend/financial-calculators.test.mjs tests/frontend/monthly-cashflow.test.mjs tests/frontend/simulation-contract.test.mjs tests/frontend/simulation-form.test.mjs tests/frontend/simulator-entry.test.mjs tests/frontend/territory-path.test.mjs tests/frontend/portal-api.test.mjs` — **56 passaram, 0 falharam** nesta verificação. - `npm.cmd run types:check` — passou nesta verificação. - PHP 8.5.11 `-l` nos cinco ficheiros PHP alterados — sem erros de sintaxe. - `phpunit --configuration phpunit.xml tests/Unit/SimulationFormDraftPrivacyPolicyTest.php` — **2 passaram, 2 asserções**; teste unitário isolado, sem acesso à base de dados. - Após a validação de integridade do relatório: PHP 8.5.11 `-l` no controller e feature test — sem erros de sintaxe; teste unitário de privacidade repetido — **2 passaram, 2 asserções**. A feature test com `RefreshDatabase` não foi executada devido ao PostgreSQL descartável indisponível. - Build de produção repetido com o loader do Vite `runner` e saída temporária isolada — **passou**; nenhuma saída ficou no worktree e a compilação não alterou ficheiros versionados gerados. - Revisão JSX-a11y dirigida a associações label/control — os avisos de pesquisa sem label e opções de moeda sem texto foram corrigidos. Typecheck e suíte frontend foram repetidos depois dessas alterações: **56/56 passaram**; build de produção isolado repetido — **passou**, 2.386 módulos/107 ficheiros. Ainda falta revisão manual com teclado e leitor de ecrã. - Verificação read-only das seis pastas de referência indicadas no anexo — todas ausentes nos caminhos equivalentes sob `C:\Users\macbook\Documents\TEMPO`; `127.0.0.1:55441` continuou inacessível. As limitações das Etapas 6, 9 e 11 permanecem registadas sem substituir fontes ou base de teste. - `git diff --check` — passou com o aviso de normalização CRLF/LF já referido. - A compilação final do cliente foi confirmada pelo Vite directo em saída temporária isolada; a invocação dos wrappers `npm run build` e `npm run check` continua limitada pelo `EPERM` do Vite+ ao escrever em `node_modules/.vite-temp`. Nenhum processo foi encerrado. - O inventário de fontes oficiais foi acrescentado em `docs/investmoz/simulations/official-source-register.md`. A página do Banco de Moçambique aberta nesta sessão define o cálculo/publicação da taxa de referência, mas não comprova a sua aplicação à alfândega. As páginas do INSS expiraram ao abrir; os diplomas e anexos continuam por obter e validar. Nenhum valor foi activado. - Reconfirmado que a porta PostgreSQL descartável `127.0.0.1:55441` não estava acessível na verificação anterior; testes feature com `RefreshDatabase` continuam por executar nesse ambiente. ### Etapa 6 — movimento agregado de existências - A projecção agora aceita compras mensais agregadas, calcula consumo a partir dos produtos, reconcilia saldo inicial/compras/consumo/saldo final e indica falta de stock mês a mês. Compras contabilizadas e pagamentos a fornecedores ficam separados; o fluxo de caixa não é alterado pelas compras de stock além dos pagamentos já declarados. - Sem compras mensais, dados legados mantêm o restante plano e marcam apenas as existências finais como indeterminadas. `business-plan-v2` grava o novo pressuposto e a leitura `business-plan-v1` continua suportada. - O movimento supõe compras disponíveis no próprio mês e não reduz as vendas planeadas quando há falta; o ecrã sinaliza essa condição. Não representa stock por produto, lead time ou um balanço contabilístico. - A comparação e o CSV de cenários agora incluem existências finais e falta de stock, além de receita, resultado e caixa. - Teste dirigido do plano empresarial — **11 passaram, 0 falharam**; suíte frontend completa — **57 passaram, 0 falharam**; `npm.cmd run types:check` — passou. JSX-a11y dirigido a control labels passou. Build isolado após esta alteração — **passou**, 2.386 módulos/107 ficheiros; saída temporária removida. - Na revisão final foi removida uma renderização duplicada do aviso e da tabela de existências. Após a correcção, a suíte frontend completa repetiu **57/57**, typecheck, `git diff --check`, regra JSX-a11y dirigida e build Vite isolado passaram. ### Continuação — prazo de entrega de existências (2026-10-02) - Acrescentei prazo de entrega fixo, entre 0 e 12 meses, para encomendas agregadas mensais. O modelo distingue encomendas, recepções, stock em trânsito, stock disponível, consumo e falta por mês; encomendas não recebidas no fim do horizonte ficam em trânsito. - O prazo afecta disponibilidade física de stock, não altera por si só o pagamento aos fornecedores ou as vendas planeadas. A facturação continua visível mesmo quando há falta, com alerta para rever os pressupostos. - Snapshot passou a `business-plan-v3`; leitores continuam a aceitar v1/v2 e interpretam planos antigos com prazo zero, preservando a hipótese anterior. Não há mudança em API, schema ou snapshots armazenados fora do campo actual do plano cifrado. - CSV, conversão de moeda e interface apresentam recepções e mercadoria em trânsito, mantendo consistência com os valores por período. - `node --test tests/frontend/business-financial-plan.test.mjs` — **12 passaram, 0 falharam**. A suíte frontend completa, typecheck e validação de formatação/diff são executadas nesta continuação abaixo. - `node --test tests/frontend/*.test.mjs` — **62 passaram, 0 falharam**; `npm.cmd run types:check` — passou; `vp fmt --check` nos três ficheiros TypeScript/TSX/MJS alterados — passou; `vp lint --jsx-a11y-plugin resources/js/components/simulation-business-plan.tsx` — passou depois de substituir anúncios `role=status` por ``; `git diff --check` — passou. - Build de produção isolado do Vite com PHP 8.5.11 no PATH do processo — passou, 2.387 módulos transformados e 107 ficheiros temporários gerados. Aviso não fatal: pacote opcional `fontaine` ausente; não instalei dependências. - Não executei a suíte Laravel/PostgreSQL: esta alteração afecta apenas o modelo financeiro frontend e snapshots JSON cifrados no campo existente, sem migration nem contrato API novo. - Limitações restantes: compras, stock e falta continuam agregados em dinheiro, não por produto; todos os pedidos usam o mesmo atraso fixo; não há atrasos incertos, devoluções, perdas nem ajuste automático de vendas. ### Etapa 7 — ponte contabilístico-fiscal (parcial) - `resources/js/lib/financial-fiscal-bridge.ts` e o CSV do plano transferem rendimentos, custos variáveis, despesas operacionais, pessoal, depreciação e juros reconhecidos, com origem e montantes por mês; o total das linhas reconcilia com resultado contabilístico antes de impostos. O CSV regista também as lacunas fiscais e o estado indeterminado. - Calendário de cobranças e pagamentos continua separado. Reembolso de capital figura só em caixa. O ecrã declara as linhas como “por classificar” e matéria colectável como indeterminada; nenhum benefício, dedução, imposto ou pagamento fiscal é presumido. - Teste dedicado verifica reconciliação exacta, ausência de dupla contagem entre facturação/cobranças, exclusão do capital reembolsado das despesas e propagação do estado indeterminado. A regra permanece incompleta até haver classificação fiscal, ajustamentos e parâmetros aprovados. ### Etapa 8 — exportação da execução aritmética - O resultado concluído pode ser exportado localmente em CSV com ID/versão, data, fórmula, valores substituídos, total exacto, moeda (ou ausência explícita), fontes e limitações. Campos pessoais do rascunho não fazem parte do exportador. - O CSV da ponte do plano inclui valores contabilísticos mensais e totais, classificação fiscal pendente e matéria colectável indeterminada. Verificação final desta continuação: 59/59 testes frontend, typecheck, JSX-a11y dirigido, diff check e build Vite isolado passaram. - Teste frontend cobre resultado/versão, precisão textual, ausência de dados pessoais e rejeição de resultados não concluídos ou montantes inválidos. O relatório é aritmético e declara ausência de interpretação legal. ## Riscos e pendências priorizados 1. **Crítica — regras fiscais:** obter textos normativos consolidados e anexos das fontes registadas, validar âmbito e parâmetros vigentes; manter todos os tributos indeterminados até aprovação fiscal/jurídica e testes dourados. 2. **Alta — consistência operacional:** configuração-exemplo alinhada com PostgreSQL/PostGIS; validar primeiro arranque/migrations apenas numa base descartável aprovada e sem reutilizar o papel de aplicação como SUPERUSER. 3. **Alta — dados históricos:** decidir retenção e eventual limpeza de informação pessoal guardada em snapshots anónimos antigos; nenhuma limpeza destrutiva foi feita. 4. **Alta — projecto/CRM:** executar os testes PostgreSQL da conversão numa base isolada e definir o fluxo real de Project/CRM; a conversão actual apenas anexa uma cópia ao rascunho. 5. **Média — relatórios:** decidir se PDF, persistência imutável e partilha autenticada são necessários; o CSV actual é local e educativo. 6. **Média — validação UX:** testar em dispositivos móveis, teclado e leitor de ecrã, incluindo mensagens e estados de erro. 7. **Média — plano empresarial:** validar pressupostos e modelo com utilizadores/contabilista; considerar stock por produto, calendários de compra variáveis e balanço após requisitos funcionais aprovados. ## Próximo passo recomendado Rever este relatório e os diffs; encaminhar os bloqueios fiscais para validação pelas fontes e especialistas competentes. Em paralelo, preparar ambiente PostgreSQL/PostGIS descartável para validar a conversão e executar testes de UX. O estado proposto é **gate parcial**, sem aprovação de publicação de regras fiscais ou submissão para CRM/projecto. ## Configuração, reversão e actualização de regras - Para validação do cliente, usar Node/dependências já instaladas e PHP 8.5.11; o comando de build Vite+ (`npm run build`) ainda falha ao escrever em `node_modules/.vite-temp` neste ambiente, embora o build directo `vite build --configLoader runner` tenha passado em pasta temporária isolada. `.env.example` usa PostgreSQL e espera PostGIS pré-provisionado; validar a configuração apenas num ambiente descartável antes da suite Laravel completa. - Não foram criadas migrations nem alterados dados. Para reverter este trabalho, rever o diff e desfazer apenas os hunks/ficheiros deste âmbito; não usar uma limpeza global do worktree porque contém alterações locais não relacionadas. Saídas temporárias do build já foram removidas. - Não publicar regras até seguir o processo e evidências de `docs/investmoz/simulations/official-source-register.md`, obter aprovação identificável do Fiscalista e passar casos dourados versionados. O gate proposto permanece parcial; nenhuma etapa posterior foi activada. ## Revisão obrigatória — reforma fiscal 2026 e microfinanças (2026-10-02) - Criada a matriz documental `docs/investmoz/simulations/fiscal-reform-2026-review.md`. O sumário oficial da INM confirma as Leis 7/2025–12/2025. O catálogo oficial lista BR 186 (30-09) e 187 (01-10) como disponibilizados em 02-10-2026, mas não foi possível obter o texto/sumário fiscal desses números nesta revisão; a presença e vigência dos regulamentos estão por confirmar no próprio BR. - Resolvidas divergências: revogação de regimes simplificados de IVA não revoga ISPC; não aplicar 32% plana a mais-valias IRPS; e corrigir o comunicado que cita Lei 12/2005 para IRPC e chama Lei 9/2025 de IRPC (o BR 248 confirma Lei 12/2025 como IRPC e Lei 9/2025 como ISPC). A regra IRPC de PE por serviços de 90 dias tem ressalva para serviços digitais. - O formulário recolhe ano/periodicidade/componente e questões condicionais exploratórias, residência auto-indicada com “não sei”, resultado de trabalho IRPS mensal/anual, estado de documentação, código pautal e estado do pedido de IVA. Não pede upload nem determina residência. Foi corrigido o dropdown para abranger o próximo ano, conforme a API. - A calculadora educativa de empréstimos permanece separada de registo de operadores. Decreto 50/2024 revoga Decreto 57/2004; BM marca o guia de 2022 como em actualização, lista Aviso 7/GBM/2017 e publica lista de operadores até 31-03-2025. Requisitos actuais por categoria, capital, limites e procedimento têm de ser reconfirmados. - Crédito estimado de IVA é separado de pedido, montante reconhecido e recebimento. Só imposto apurado e uma previsão de recebimento com mês explícito entram no fluxo; esta previsão é hipótese, não garantia. - Estado proposto: **parcial / gate fiscal bloqueado**. Não activar publicamente cálculo fiscal até ler os BR 186/187, obter fontes consolidadas, parâmetros por vigência e casos dourados aprovados. ### Continuação — revisão de tesouraria e verificação global (2026-10-02) - O planeador de tesouraria passou a aceitar imposto apurado mensal como saída de caixa e a mostrar, em campos distintos, crédito estimado de IVA, pedido, valor reconhecido e recebimento futuro previsto. Crédito/pedido/reconhecido não alteram caixa; somente a previsão de recebimento com mês explícito altera o mês correspondente e é rotulada como hipótese condicional, não garantida. CSV e tabela mensal identificam estas linhas. - O formulário fiscal permite períodos históricos desde 2000 até ao ano corrente e o ano seguinte, com componente e periodicidade; país de residência fiscal é opcional e só surge para componentes pertinentes, em campo privado. Para o percurso anónimo, não é enviado ao servidor. Não foram alterados resultados/snapshots anteriores nem criadas migrations. - `node --test tests/frontend/*.test.mjs` — **61 passaram, 0 falharam**; inclui caso que prova que crédito/pedido/reconhecimento não entram em caixa e só recebimento explícito no mês escolhido altera o saldo. - `npm.cmd run types:check` — passou. PHP 8.5.11 `-l app/Http/Requests/StoreSimulationFormDraftRequest.php` — sem erros. `git diff --check` — passou, com aviso de normalização CRLF/LF já observado no formulário. - Build Vite directo (`--configLoader runner`, saída temporária isolada) — **passou**, 2.387 módulos transformados/107 ficheiros. Aviso: dependência opcional `fontaine` ausente, apenas afecta optimização de fontes. - `npm.cmd run check` — falhou no verificador de formatação, que reportou 137 ficheiros em várias áreas do repositório. Não foi executado `--fix`, para evitar alteração em massa de ficheiros fora deste âmbito. Este resultado não determina se todos os avisos antecediam a execução. - Não foi executado browser real: não há Playwright/Puppeteer instalado. A verificação móvel, teclado e leitor de ecrã continua manual e pendente. Também não foi executada suite Laravel/PostgreSQL: a base descartável permanece sem evidência de disponibilidade e testes existentes podem apagar o schema dedicado. - Estado da Etapa 11 permanece **parcial**; gate fiscal/aduaneiro mantém-se bloqueado até fonte consolidada, parâmetros versionados e aprovação humana. ### Continuação — prazo de fornecimento no plano empresarial (2026-10-02) - O plano empresarial aceita um prazo fixo de fornecimento entre 0 e 12 meses. Mantém separados encomendas, pagamentos, recepções, rupturas de stock e mercadoria em trânsito; o prazo afecta disponibilidade de stock, sem alterar pagamentos ou resultados operacionais calculados. - Snapshots passam a v3 e preservam o prazo; snapshots v1/v2 são restaurados com prazo zero. A exportação inclui prazo, recepções previstas e stock em trânsito. - `node --test tests/frontend/*.test.mjs` — 62/62 passaram, incluindo equivalência do resultado e caixa para prazos distintos. `npm.cmd run types:check`, `npm.cmd exec -- vp fmt --check ...`, lint JSX-a11y dirigido e `git diff --check` passaram. - Limitação: prazo é constante para todas as compras, sem calendário por fornecedor/produto ou incerteza de entrega; pressupostos e modelo carecem de validação operacional. ### Continuação — calendário de cobrança da facturação (2026-10-02) - O plano conserva o modo anterior de cobranças mensais declaradas. Opcionalmente, permite declarar atraso fixo de 0–12 meses para cobrança integral das vendas mensais facturadas; mostra em linhas separadas facturação, cobranças da facturação, outras cobranças e saldo por cobrar dessa facturação no horizonte. As contas a receber de abertura não são incluídas na agenda porque o respectivo vencimento não é conhecido. - A previsão altera apenas liquidez/tesouraria; resultado antes de impostos e facturação não mudam com o prazo. Sem uma taxa de cobrança ou maturidades documentadas, o modelo declara a hipótese de cobrança integral, sem modelar incumprimento ou cobrança parcial. - Snapshot passa a `business-plan-v4`; versões v1–v3 continuam em modo manual para preservar o cálculo anterior. CSV e quadro mensal mostram os dois fluxos de cobrança separadamente. - `node --test tests/frontend/business-financial-plan.test.mjs` — 14/14 passaram; a suite completa passou 64/64, typecheck, formatter dirigido, lint JSX-a11y, `git diff --check` e build Vite isolado também passaram. O teste do CSV confirma o atraso, cobranças agendadas e saldo por cobrar. - Etapa 9: revisão do request/controller/service confirmou allowlist que exclui `simulation_sources` enviado pelo cliente, remoção do snapshot pessoal anónimo, consentimento, propriedade/token, `If-Match`, hash/versão do relatório e auditoria. Detectado e corrigido o modelo Eloquent que tratava UUID como inteiro; adicionada migration reversível para preservar soft-delete com RLS e manter tombstones filtrados nos endpoints. Regressões também foram ajustadas para respeitar políticas de leitura da auditoria anónima e imutabilidade dos relatórios publicados. - `php artisan test --filter=SimulationFormDraftTest` — 8/8 testes e 61 asserções passaram em base PostgreSQL/PostGIS temporária, propriedade de login sem `SUPERUSER`; base e papel foram removidos após a execução. A base partilhada `investmoz_test` não foi usada para `RefreshDatabase`. - `php artisan test --filter='SimulationExecutionTest|ApiContractTest'` — 15/15 testes e 100 asserções passaram na mesma configuração segura, incluindo imutabilidade, escopo RLS, token HMAC e entrada explícita de redução. - Suite Laravel completa, em base temporária `_test` e login sem `SUPERUSER`/com `CREATEROLE`: **219/223 passaram**. As duas falhas restantes são `EducationTest` (província obrigatória e resposta Inertia); os dois erros são rollbacks de testes empresariais bloqueados por FK dependente em `existing_business_rights`. Estes quatro problemas não foram alterados por estarem fora do simulador. - Validação final desta continuação: `node --test tests/frontend/*.test.mjs` — 64/64; `npm.cmd run types:check` — passou; `php artisan test --testsuite=Unit --filter=SimulationFormDraftPrivacyPolicyTest` — 2/2 testes e 2 asserções (aviso preexistente de `use Throwable` sem efeito em `bootstrap/app.php`); formatação dirigida, JSX-a11y e `git diff --check` passaram. - Build de produção isolado (`npm.cmd exec -- vite build --configLoader runner --outDir --emptyOutDir`) — passou, 2.387 módulos transformados. Aviso não fatal: pacote opcional `fontaine` não instalado. A saída foi dirigida para a pasta temporária fora do worktree. ### Continuação — confirmação de fontes fiscais e microfinanças (2026-10-02) - Revisão das referências oficiais em 02-10-2026 confirmou o sumário INM do Suplemento n.º 1 do BR 248: Leis 7/2025 (ICE), 8/2025 (Pauta), 9/2025 (ISPC), 10/2025 (IVA), 11/2025 (IRPS) e 12/2025 (IRPC). A INM lista BR 186/30-09 e 187/01-10, disponibilizados em 02-10; o sumário/texto acessível nesta consulta não confirma os regulamentos fiscais anunciados em 30-09. Continuam sem ativação até obter os diplomas publicados e respectivos artigos/transições. - A análise oficial do BM acrescenta comunicado cadastral de operadores de microcrédito (11-09 a 10-10-2026). É procedimento de actualização cadastral e não altera, isoladamente, capitais mínimos ou limites. O BM continua a marcar o guia de 2022 como em actualização, lista o Aviso 7/GBM/2017 e a lista pública consultada tem corte em 31-03-2025; compatibilidade, estado de recadastramento e requisitos vigentes permanecem pendentes. - A matriz fiscal foi actualizada em `docs/investmoz/simulations/fiscal-reform-2026-review.md`; o registo de fontes em `docs/investmoz/simulations/official-source-register.md`. Divergência editorial sobre o número das Leis 9/2025 e 12/2025 e confusão entre revogações simplificadas de IVA e ISPC continuam resolvidas/documentadas, sem converter resumos secundários em regras executáveis. - Corrigido o select do período: agora oferece anos desde 2000 até ao próximo ano, alinhando a implementação com a especificação/documentação existente. A matriz confirma que as perguntas fiscais são condicionais, residência aceita “não sei”, salário IRPS distingue estimativa líquida mensal/retenção/apuramento anual e não há carregamento de documentos. - `node --test tests/frontend/simulation-form.test.mjs` — 13/13 passaram; inclui período do próximo ano e perguntas fiscais condicionais. `npm.cmd run types:check` — passou. O check do formatter para os dois Markdown preexistentes ainda aponta formatação geral; não corri formatter de escrita em ficheiros de auditoria longos para evitar reformatar todo o texto. `git diff --check` — passou. - Estado proposto: calculadoras financeiras independentes podem continuar; activação pública fiscal permanece bloqueada por falta de texto consolidado/autenticado, regulamentos de 2026 confirmados, tabelas/parametrização versionadas e casos aprovados pelo Fiscalista. Percurso de registo de microfinanças permanece fora do simulador de empréstimo educativo. ### Continuação — cadastro de oportunidades de negócio (2026-10-02) - Adaptado o wizard autenticado existente `/investidor/negocios` à especificação recebida: tipos de oportunidade, campos condicionais, disponibilidade, valor/moeda/significado, proponente e representação, fonte/data, recursos com estado, hierarquia territorial e confirmações separadas. Contactos continuam cifrados e não entram automaticamente na projecção pública. - Criada migration aditiva para alargar modalidades sem editar migrations anteriores; reversão recusa perder registos com novos tipos. Mantidos rascunhos v1 com validação anterior; novos usam v2. Migration não foi executada. - Pendente: anexos/antivírus/classificação por ficheiro; relações territoriais canónicas, mapa e múltiplas localizações; CRM existente sem duplicação; ligações a corredores/clusters/zonas; suspensão/encerramento e confirmação periódica após publicação; testes feature e validação manual. - Exportadores existentes actualizaram `form-schema.json` e OpenAPI de oportunidades. `npm.cmd run types:check`, PHP lint dos seis ficheiros alterados e `git diff --check` passaram; PHPUnit não foi executado. - Estado do gate: cadastro privado parcial; publicação de oportunidades reais continua condicionada à revisão editorial/documental e às lacunas acima. ### Etapa 6 — cobrança parcial da facturação - O modo de cobrança por prazo permite declarar a percentagem da facturação cobrada no vencimento (0–100%, até seis casas decimais). O remanescente permanece em contas a receber ao longo do horizonte; não é presumida recuperação posterior. Facturação, recebimento e contas a receber continuam separados. - Arredondamento de cada recebimento é half-up ao cêntimo. Cenários aplicam a variação de cobrança tanto ao modo manual como à percentagem do modo agendado, limitada ao intervalo matematicamente possível de 0–100%. Snapshots avançam para `business-plan-v5`; v1–v4 são lidos com 100%, preservando a regra anterior. CSV declara a hipótese aplicada. - `node --test tests/frontend/business-financial-plan.test.mjs` — 15/15 passaram, incluindo recebimento parcial, acumulação por cobrar, meio cêntimo, limites, cenários com cobrança agendada, CSV e compatibilidade dos snapshots antigos. - `node --test tests/frontend/*.test.mjs` — 65/65 passaram, cobrindo também contratos, formulário, ponte fiscal, tesouraria e restauração de rascunhos do simulador. - `npm.cmd run types:check` — passou; `vp fmt --check` nos três ficheiros da implementação/testes — passou; `git diff --check` — passou (com aviso preexistente de CRLF no schema de oportunidades, fora deste incremento). - Limitações mantidas: valores a receber de abertura não entram na agenda porque não há vencimentos informados; a parte não cobrada não tem agenda de recuperação; o modelo não estima incumprimento. Etapa 6 permanece parcial e sujeita a validação institucional do plano. #### Complemento — montante total do projecto - A comparação campo a campo com o formulário recebido detectou que o projecto recolhia montante assegurado e financiamento procurado, mas não o investimento total estimado. Acrescentado `investment_total`, obrigatório e positivo apenas para `investment_project`, com precisão decimal textual de até quatro casas; o valor não é convertido em zero quando desconhecido. - O campo é limpo quando se muda o tipo da oportunidade, aparece apenas para projecto de investimento, e foi incluído nos artefactos gerados de schema e OpenAPI. Não foi introduzida reconciliação automática dos montantes; esta permanece a validar na revisão do proponente. - A migration de modalidades continua por aplicar; testes de integração do cadastro, uploads classificados, relações canónicas e acessibilidade manual permanecem pendentes. O gate continua parcial e privado. ### Etapa 6 — recebíveis de abertura com vencimento declarado - Acrescentada previsão opcional de um mês e uma percentagem (0–100%) para cobrar valores a receber existentes no início do plano. Sem mês indicado, não há entrada de caixa presumida. O recebimento previsto é apresentado em linha separada, os valores ainda por receber continuam visíveis e o recebimento não altera facturação, resultado nem o fundo de maneio inicial. - Snapshots passam a `business-plan-v6`; snapshots v1–v5 mantêm os seus pressupostos anteriores, com a nova cobrança por omissão desactivada. A conversão cambial e o CSV incluem a nova linha mensal e os totais. - Testes acrescentados para fluxo de caixa no mês escolhido, parcela remanescente, cêntimo de arredondamento, invariância do resultado/fundo de maneio, limite do horizonte e compatibilidade de snapshots v5. - `node --test tests/frontend/business-financial-plan.test.mjs` — 16/16 passaram; `node --test tests/frontend/*.test.mjs` — 66/66 passaram. - `npm.cmd run types:check`, `vp fmt --check` nos três ficheiros do plano e `git diff --check` passaram. O aviso CRLF continua a referir-se ao schema de oportunidades, fora desta etapa. - Build Vite de produção — passou, 2.387 módulos; manifest confirmado em `C:\Users\macbook\AppData\Local\Temp\investmoz-vite-stage6-20261002-001`. Aviso não fatal: dependência opcional `fontaine` ausente. A saída temporária foi preservada porque a limpeza foi rejeitada pelo executor. ### Etapa 7 — reconciliação da ponte por período - A ponte valida a previsão antes de criar o mapeamento: períodos ordenados, resultado contabilístico e facturação reconciliados, origens das cobranças compatíveis com o total mensal, pagamentos e reembolsos reconciliados com fluxo líquido, continuidade do caixa e movimentos de recebíveis de abertura. - O calendário separa cobrança de vendas agendadas, recebíveis de abertura, outras cobranças ou modo manual, saldos por receber e pagamentos. Capital reembolsado continua exclusivamente no calendário de caixa. Previsão inconsistente é rejeitada em vez de produzir uma ponte aparentemente válida. - Testes acrescentados para a combinação de vendas agendadas e recebíveis de abertura e para rejeição de saldo mensal de caixa corrompido. A matéria colectável continua indeterminada e as linhas permanecem não classificadas. - `node --test tests/frontend/financial-fiscal-bridge.test.mjs` — 3/3 passaram; `node --test tests/frontend/*.test.mjs` — 68/68 passaram. - `npm.cmd run types:check`, formatação dirigida e `git diff --check` passaram. A validação é da ponte financeira no cliente; não substitui testes de motor fiscal, que permanece bloqueado por ausência de regras aprovadas. ### Etapa 8 — segurança de células CSV - As exportações do plano, tesouraria, calculadoras financeiras e resultado aritmético usam agora um serializador comum de células. Texto iniciado por prefixo de fórmula de folha de cálculo (incluindo depois de espaços/caracteres de controlo) é tratado como texto; números decimais negativos permanecem intactos e delimitadores/aspas são escapados. - Testes cobrem rótulo de produto, metadado de execução, pressuposto de tesouraria, rótulo de orçamento, prefixos após controlo/BOM e preservação de défices numéricos. O conteúdo continua local ao navegador; não adiciona dados pessoais. - `node --test tests/frontend/*.test.mjs` — 73/73 passaram; `npm.cmd run types:check`, formatação dirigida e `git diff --check` passaram. - Build Vite de produção — passou, 2.388 módulos e manifest confirmado em `C:\Users\macbook\AppData\Local\Temp\investmoz-vite-stage8-20261003-001`. Aviso não fatal: dependência opcional `fontaine` ausente. Saída temporária preservada; a tentativa de limpeza é rejeitada pelo executor. ### Continuação — histórico pessoal de simulações (2026-10-03) - A Etapa 9 ganhou `GET /api/v1/simulations/history` e um painel paginado no `/simulador-fiscal` para contas autenticadas verificadas. O endpoint lista simulações pessoais e de organizações visíveis por membership activa, exclui registos anónimos e omite snapshots e devolve metadados mínimos; a abertura de cada resultado reutiliza a rota individual com as políticas de acesso existentes. - Foram acrescentados testes feature para isolamento entre dois utilizadores, exclusão do fluxo anónimo, ausência de snapshots na listagem e exigência de autenticação/email verificado. Os testes não foram executados porque `127.0.0.1:55441` está inacessível; não usei a base partilhada. - Evidência executada: PHP 8.5.11 `-l app/Http/Controllers/Api/V1/SimulationController.php` passou; `php vendor/bin/pint --test` nos três ficheiros PHP alterados passou; `npm.cmd run types:check` passou; `node --test tests/frontend/*.test.mjs` passou (73/73); validação JSON do OpenAPI passou; build Vite isolado passou (2.388 módulos, saída em `%TEMP%\\investmoz-stage9-history-20261003-002`); `git diff --check` passou com aviso de CRLF preexistente no schema do formulário empresarial. - O painel inclui execuções de organizações visíveis por membership activa, mas não permite filtrar por projecto. Etapa 9 permanece parcial: integração final com Project/CRM e validação manual assistiva ainda não estão confirmadas. ### Etapa 6 — parcelas de recebíveis de abertura (2026-10-03) - O plano aceita parcelas adicionais de recebíveis de abertura com mês e percentagem do saldo inicial. O recebimento legado de parcela única continua compatível; a soma das parcelas agendadas e do recebimento legado não pode ultrapassar 100%. - Cada parcela é calculada em cêntimos, arredondada half-up e limitada ao saldo ainda disponível, evitando saldo negativo por arredondamento. A cobrança altera tesouraria e saldo de recebíveis, nunca facturação nem resultado antes de impostos. - Snapshot passou a `business-plan-v7`; leitores v1–v6 continuam válidos. Cenários aplicam a variação de cobranças às parcelas declaradas dentro do saldo disponível. O resumo, a conversão cambial e o CSV mostram a agenda. - Cobertura: 19 testes focados no plano passaram, incluindo reconciliação mensal, cobrança única mais parcelas, soma excessiva, mês fora do horizonte, cêntimos independentes, snapshots v6, conversão de moeda e cenários. - `npm.cmd run types:check` passou; formatação dirigida passou. A validação contabilística institucional continua pendente; não foi activada regra fiscal. - Revalidação final após corrigir a base da variação de cobrança: `node --test tests/frontend/*.test.mjs` passou (75/75); `npm.cmd run types:check`, formatter dirigido e `git diff --check` passaram. Build Vite isolado passou com 2.388 módulos em `%TEMP%\investmoz-stage6-receivables-v7-20261003-002`; aviso não fatal: pacote opcional `fontaine` ausente. - Os cenários agora variam a percentagem própria da cobrança de recebíveis de abertura; não reutilizam a percentagem de cobrança das vendas facturadas. ### Etapa 6 — recuperação declarada de facturas vencidas (2026-10-03) - Snapshot passa a `business-plan-v8`. A agenda opcional declara mês e percentagem a recuperar sobre o saldo de facturas já vencidas e ainda aberto; facturas no próprio vencimento não são elegíveis para recuperação nesse mês. Sem evento, não se presume recuperação. - O cálculo mantém saldos por coorte de vencimento, aplica primeiro a cobrança inicial, depois recupera do saldo vencido por antiguidade, em cêntimos half-up e com limite ao saldo disponível. Relatório, quadro mensal, conversão e CSV distinguem cobrança inicial de recuperação. Cenários ajustam a hipótese declarada de recuperação. - Leitores v1–v7 preservam as hipóteses anteriores e recebem agenda vazia. Testes cobrem reconciliação após múltiplos eventos, nenhuma recuperação presumida, mês fora do horizonte, meses duplicados, percentagens inválidas e compatibilidade v7. - Este complemento é uma hipótese de tesouraria informada pelo utilizador; não estima incumprimento ou probabilidade de cobrança e não representa receita adicional. Validação contabilística institucional continua pendente. - Evidência desta continuação: `node --test tests/frontend/business-financial-plan.test.mjs` passou (20/20); `node --test tests/frontend/*.test.mjs` passou (76/76); `npm.cmd run types:check` passou; `vp fmt --write` dirigido aos cinco ficheiros desta alteração passou; build Vite isolado passou (2.388 módulos, saída `%TEMP%\investmoz-stage6-sales-recovery-v8-20261003`). `git diff --check` passou com aviso preexistente de CRLF no schema de oportunidades. `npm.cmd run check` foi executado e falhou porque o verificador global encontrou formatação em 125 ficheiros do repositório, incluindo ficheiros fora deste escopo; os cinco ficheiros alterados foram formatados de forma dirigida. ### Etapa 3 - persistencia das calculadoras financeiras no rascunho (2026-10-03) - Corrigida perda de valores ao navegar entre etapas: periodo do orcamento, linhas de receitas/despesas, emprestimo, ponto de equilibrio e necessidade de financiamento sao serializados como `financial-tools-v1` dentro do snapshot economico cifrado existente. Nao sao armazenados em separado nem incluem campos pessoais. - O codec limita o snapshot a 30 KB, valida a estrutura e versionamento, restaura pressupostos editaveis e descarta snapshots desconhecidos/malformados. A API aceita apenas a chave incluida na allowlist e aplica o mesmo limite de tamanho; os calculos existentes continuam a validar os montantes. - Testes cobrem round-trip, versao, tamanho e limite de linhas; verificam tambem a separacao em `economic_snapshot` e a inclusao no fluxo anonimo sem dados pessoais. - Evidencia: `node --test tests/frontend/*.test.mjs` passou (77/77); `npm.cmd run types:check`, `php -l app/Http/Requests/StoreSimulationFormDraftRequest.php`, Pint dirigido e build Vite isolado passaram (2.388 modulos; `%TEMP%\investmoz-stage3-financial-tools-v1-20261003`). O teste feature `php artisan test --filter=SimulationFormDraftTest` foi recusado pelo guard do bootstrap antes de executar casos: encontrou schema `skills_edu` preexistente e exige reconciliacao; nenhuma migration nem limpeza foi executada. `git diff --check` passa com aviso preexistente de CRLF no schema empresarial. ### Etapa 6 - estado explicito da reconciliacao do financiamento (2026-10-03) - A diferenca assinada entre usos iniciais e fontes de financiamento mantem a precisao em centimos e agora declara `balanced`, `shortfall` ou `surplus`. O resumo apresenta alerta de falta/excedente ou confirmacao de reconciliacao; o CSV separa estado e diferenca, evitando chamar excedente de deficit. - O caixa de abertura permanece separado: nao e somado silenciosamente as fontes de financiamento para mascarar diferencas entre usos e fontes. - Testes cobrem falta, equilibrio, excedente e propagacao do estado para a moeda de apresentacao. - Evidencia desta alteracao: `node --test tests/frontend/business-financial-plan.test.mjs` passou (20/20); `node --test tests/frontend/*.test.mjs` passou (77/77); `npm.cmd run types:check` passou; formatacao dirigida passou; build Vite isolado passou (2.388 modulos, `%TEMP%\investmoz-stage6-funding-reconciliation-20261003`); `git diff --check` passou com aviso de CRLF preexistente no schema empresarial. Sem migration ou alteracao da base de dados. ### Etapa 3 - categorias editaveis do orcamento (2026-10-03) - Cada linha de receita/despesa permite editar a descricao e o montante; linhas podem ser removidas sem deixar a categoria vazia. A interface limita cada lista a 50 itens, em conformidade com o codec do snapshot cifrado. - Os nomes e valores mantem-se no `financial-tools-v1`, reaparecem ao regressar a etapa e continuam incluidos no CSV. Nao se inferem categorias ou valores a partir de etiquetas livres. - Evidencia: `node --test tests/frontend/*.test.mjs` passou (77/77), `npm.cmd run types:check` passou e build Vite isolado passou (2.388 modulos; `%TEMP%\investmoz-stage3-budget-categories-20261003`). A formatacao dirigida da interface passou; `git diff --check` passou com aviso preexistente de CRLF. ### Etapa 6 - volumes vendidos por mes (2026-10-03) - O plano empresarial aceita `monthlyUnitsByPeriod` opcional por produto; snapshots novos usam `business-plan-v9`, mantendo a leitura v1-v8. Cada mes do horizonte (1-60) pode ter volume proprio; reduzir o horizonte preserva meses ocultos, e ampliar cria meses com a quantidade-base. O modo constante continua padrao. - O motor valida quantidade e comprimento da agenda e aplica os valores mensais a faturacao, custos variaveis, consumo de existencias e coortes de cobranca. Cenarios ajustam cada mes separadamente; totais e conversao cambial somam valores calculados em centimos. O CSV exporta as unidades por mes em JSON. - Testes cobrem sequencias sazonais, horizonte divergente, quantidade negativa ou com precisao excessiva, cenarios de volume, CSV e round-trip do snapshot. A validacao contabilistica institucional continua pendente; sao pressupostos declarados, nao previsoes de procura. - Versionamento: snapshots v1-v8 sem agenda mensal continuam no modo constante; a validacao v9 rejeita listas com tamanho diferente do horizonte. - Evidencia: `node --test tests/frontend/business-financial-plan.test.mjs` passou (23/23); `node --test tests/frontend/*.test.mjs` passou (80/80); `npm.cmd run types:check` passou; `vp fmt --check` passou nos quatro ficheiros de implementacao/teste/contrato; build Vite isolado passou (2.388 modulos; `%TEMP%\investmoz-stage6-monthly-units-20261003-003`); `git diff --check` passou com aviso preexistente de CRLF em `docs/investmoz/existing-business/form-schema.json`. - O formatter aplicado ao relatorio extenso de progresso indica inconsistencias nesse ficheiro; nao o reformatei integralmente para preservar secoes anteriores fora deste incremento. Nenhuma migration, base de dados, integracao ou ativacao externa foi tocada. - Complemento de interface: a agenda agora explica que meses fora do horizonte ficam guardados e que meses novos usam a quantidade-base. `vp check resources/js/components/simulation-business-plan.tsx` passou sem avisos nem erros; `node --test tests/frontend/*.test.mjs` passou (80/80); `npm.cmd run types:check` passou; build Vite isolado passou com 2.388 modulos em `%TEMP%\investmoz-stage6-monthly-units-20261003-005`; formatter dirigido e `git diff --check` passaram (com aviso de CRLF preexistente no schema do formulario empresarial). ### Etapa 6 - precos e custos unitarios mensais (2026-10-03) - Snapshot corrente passa a `business-plan-v10`, preservando leitores v1-v9. Cada produto pode declarar agendas opcionais de preco e custo variavel por mes, cobrindo o horizonte e ate 60 meses; sem agenda, aplicam-se os valores base. Agendas antigas de unidades continuam compativeis. - Receita, custo variavel, consumo de existencias e cenarios passam a calcular com os valores por periodo em centimos. Os cenarios ajustam cada preco/custo mensal declarado; o CSV inclui as agendas de unidades, preco e custo em JSON. A interface permite activar e editar cada agenda e preserva meses fora do horizonte. - Testes adicionados para alteracoes mensais de receita/custo/consumo e cenarios, valores invalidos, cobertura do horizonte, compatibilidade v9 e exportacao CSV. Esta extensao continua a ser um pressuposto editavel, nao uma previsao validada. - Evidencia desta continuacao sera registada apos executar novamente testes, verificacao de tipos, formatter dirigido e build isolado. - Evidencia final: `node --test tests/frontend/business-financial-plan.test.mjs` passou (25/25); `node --test tests/frontend/*.test.mjs` passou (82/82); `npm.cmd run types:check` passou; `vp check resources/js/components/simulation-business-plan.tsx` passou sem avisos/erros; `vp fmt --check` passou nos quatro ficheiros dirigidos; build Vite isolado passou com 2.388 modulos em `%TEMP%\investmoz-stage6-monthly-money-v10-20261003` (aviso nao fatal: pacote opcional `fontaine` ausente); `git diff --check` passou com aviso preexistente de CRLF no schema do formulario empresarial. ### Etapa 6 - despesas e pessoal por mes (2026-10-03) - Snapshot atual passa a `business-plan-v11`; snapshots v1-v10 continuam compativeis e sem agendas mensais inferidas. Foram acrescentadas agendas opcionais, ate 60 meses, para despesas operacionais reconhecidas, pagamentos operacionais, despesa de pessoal reconhecida e pagamentos de pessoal. Sem agenda, mantem-se o valor-base constante. - O calculo mantem despesa reconhecida no resultado contabilistico e pagamentos no fluxo de tesouraria. Cenarios ajustam cada agenda declarada; CSV exporta as quatro agendas e as colunas de pagamentos separadas. A interface permite alternar cada agenda e preserva meses fora do horizonte. - Testes cobrem reconcilacao por periodo, separacao resultado/caixa, variacao dos cenarios, cobertura do horizonte, montantes invalidos, leitura historica v10 e exportacao CSV. - Evidencia: `node --test tests/frontend/business-financial-plan.test.mjs` passou (27/27); `node --test tests/frontend/*.test.mjs` passou (84/84); `npm.cmd run types:check` passou; `vp check resources/js/components/simulation-business-plan.tsx` passou sem avisos/erros; formatter dirigido passou; build isolado passou com 2.388 modulos em `%TEMP%\investmoz-stage6-monthly-expenses-v11-20261003` (aviso nao fatal: `fontaine` opcional ausente). A validacao contabilistica institucional continua pendente. - Verificacao da fronteira da Etapa 7: a ponte contabilistico-fiscal foi exercitada com as novas agendas de despesa/pessoal. O teste confirma que apenas montantes reconhecidos entram nas linhas contabilisticas; pagamentos programados permanecem no calendario de caixa e a materia colectavel fica indeterminada. `node --test tests/frontend/financial-fiscal-bridge.test.mjs` passou (4/4), incluindo esta regressao. Suite frontend repetida: 85/85; typecheck, lint JSX, formatter dirigido e `git diff --check` passaram. - Rechecagem read-only do gate legal em 2026-10-03: o catalogo INM confirma BR 186/2026 (30-09; NID 22683) e BR 187/2026 (01-10; NID 22684), listados em 02-10. As fichas publicas nao disponibilizam sumario fiscal nem texto dos actos e encaminham para a loja. Registei a evidencia e mantive o gate sem ativacao em `fiscal-reform-2026-review.md` e `official-source-register.md`; nao comprei nem descarreguei conteudo nem presumi regras. ### Etapa 11 - execucao da suite PostgreSQL isolada (2026-10-03) - A porta documentada de QA estava fechada, mas o servico PostgreSQL 17 local estava ativo. Para testar com RLS real sem tocar nesse servico ou na base da aplicacao, criei um cluster temporario em `%TEMP%\investmoz-pg-test-55441`, na porta 55441, com extensoes PostGIS/pgcrypto e uma base `investmoz_test`. O papel da aplicacao de teste foi configurado sem `SUPERUSER` e com `CREATEROLE`, para exercitar policies RLS; o cluster foi separado do servico Laragon. - `php artisan test --filter='SimulationExecutionTest|SimulationFormDraftTest'` passou: 22/22 testes, 148 assercoes. A execucao revelou dois ajustes de teste: criacao de simulacao organizacional exige membership `admin` (o fixture `viewer` era invalido); a atualizacao append-only e bloqueada por RLS no papel restrito ou pelo trigger quando a policy permite chegar ao trigger. O teste agora valida ambos os caminhos e a ausencia de alteracao. - `php artisan test` completo: 219/225 passaram; 6 falhas fora do simulador: duas `EducationTest` (redirect 302 devido a provincia obrigatoria e resposta Inertia), duas `ExistingBusiness*Test` (respostas 200 onde se esperava 422) e dois erros de rollback (`existing_business_rights` impede remover `existing_business_objects`). Nao alterei essas areas fora do escopo. - Regressao frontend repetida: 85/85; `npm.cmd run types:check` passou; Pint no `SimulationExecutionTest.php` passou; `git diff --check` passou com aviso preexistente de normalizacao CRLF do schema empresarial. A suite emitiu tambem aviso PHP preexistente: `use Throwable` sem efeito em `bootstrap/app.php`. - O cluster foi criado apenas para teste e foi encerrado apos a verificacao; os dados restantes no diretorio temporario estao identificados abaixo. A infraestrutura e a base Laragon existentes nao foram alteradas. O gate fiscal continua bloqueado pelos actos sem texto oficial acessivel e por aprovacao especializada pendente. - Limpeza da QA isolada: `pg_ctl -D %TEMP%\investmoz-pg-test-55441 -m fast -w stop` confirmou `server stopped`; a porta 55441 fechou e a porta 5432 do servico existente permaneceu acessivel. A remocao recursiva da pasta de dados criada por esta execucao foi rejeitada pela politica de execucao mesmo apos validar o caminho absoluto e confirmar servidor parado. A pasta temporaria permanece em `%TEMP%\investmoz-pg-test-55441`; nao tentei contornar a restricao. ### Etapa 2/6 - limite e preservacao do snapshot empresarial (2026-10-03) - O request do rascunho limita `business_plan_snapshot` a 60.000 caracteres e o leitor cliente tambem recusava snapshots maiores, mas o serializer permitia cria-los. Agendas longas ou muitos produtos poderiam exceder esse limite e perder o round-trip. - `serializeBusinessPlanSnapshot` agora recusa exceder o limite. A interface apresenta o erro e conserva a edicao de trabalho em memoria para permitir reduzir produtos/agendas ate caber; um snapshot antigo ja acima do limite nao e substituido silenciosamente por um plano vazio. O contrato do request permanece 60.000. - Teste novo cobre a rejeicao de snapshots acima do limite. Evidencia: `node --test tests/frontend/business-financial-plan.test.mjs` passou (28/28); `node --test tests/frontend/*.test.mjs` passou (86/86); `npm.cmd run types:check`, lint JSX e formatter dirigido passaram; build isolado compilou 2.388 modulos em `%TEMP%\investmoz-stage6-snapshot-limit-20261003`, com apenas aviso nao fatal do pacote opcional `fontaine`; `git diff --check` passou com aviso preexistente de CRLF no schema empresarial. - Contrato OpenAPI da Etapa 9 alinhado em `docs/investmoz/simulations/openapi.json`: o snapshot do plano empresarial declara `maxLength: 60000`, a ferramenta financeira `maxLength: 30000`, e ambas as propriedades permanecem no snapshot economico cifrado. `ConvertFrom-Json` confirmou a validade do documento e os dois limites contra `StoreSimulationFormDraftRequest`. - Revalidacao depois de ocultar os valores por defeito quando um snapshot legado esta acima do limite: `node --test tests/frontend/*.test.mjs` passou (86/86); `npm.cmd run types:check`, `vp check resources/js/components/simulation-business-plan.tsx`, `vp fmt --check` e `git diff --check` passaram. O build final isolado compilou 2.388 modulos em `%TEMP%\investmoz-stage6-snapshot-limit-20261003-final`; aviso nao fatal: `fontaine` opcional ausente. ### Etapa 11 — revalidacao tecnica apos continuacao do plano (2026-10-03) - **Plano:** repetir testes frontend, typecheck, sintaxe e formatacao PHP e build isolado; depois executar regressao de API/RLS num PostgreSQL temporario dedicado. Ficheiros de aplicacao previstos: nenhum; registar evidencia somente neste relatorio. - `node --test tests/frontend/*.test.mjs` — 86/86 passaram. `npm.cmd run types:check` passou (`tsc --noEmit`). - PHP 8.5.11 `-l` passou nos oito ficheiros PHP validados. `php vendor/bin/pint --test` passou nos oito depois de formatar tres ficheiros PHP ja alterados: `SimulationFormDraftController.php`, `SimulationFormDrafts.php` e `SimulationFormDraftPrivacyPolicy.php`. - `php artisan test --filter='SimulationExecutionTest|SimulationFormDraftTest|ExistingBusinessIntakeTest::test_arbitrary_states_and_incomplete_or_expired_submission_are_rejected'` — 23/23 passaram, 153 assercoes, em `investmoz_test` no cluster temporario PostgreSQL 17/PostGIS da porta 55441. Inclui o teste de prazo expirado em submissao legada. Avisos nao fatais: import `Throwable` sem efeito em `bootstrap/app.php` e privilegios herdados do catalogo PostGIS durante `RefreshDatabase`. - Build Vite isolado passou, com 2.388 modulos, em `%TEMP%\investmoz-stage11-global-20261003`; aviso nao fatal de `fontaine` opcional ausente. A pasta temporaria foi preservada; nenhuma saida foi escrita em `public/build`. - `git diff --check` passou com aviso preexistente de normalizacao CRLF/LF em `docs/investmoz/existing-business/form-schema.json`. A suite Laravel completa foi repetida no mesmo PostgreSQL isolado: 220/225 passaram; duas falhas `EducationTest`, uma expectativa desactualizada de objecto em `ExistingBusinessWizardTest` (payload legado v1; a regra de objecto e aplicada pelo v2) e dois erros de rollback por FK de `existing_business_rights`. Nao houve sessao real de browser, leitor de ecra ou dispositivo movel. - **Gate da Etapa 11 continua PARCIAL.** Melhorou a evidencia automatizada; faltam validacao manual assistiva/movel, revisao final de produto, conclusao de CRM e gates legais das Etapas 4/5/10. Nenhuma componente fiscal ou integracao externa foi activada. ### Etapas 4/10 — rechecagem de fontes oficiais (2026-10-03) - O comunicado oficial do Governo de 30-09-2026 discrimina: novo regulamento ISPC que revoga Decreto 14/2009 e enumera sectores; alteração ao Regulamento IVA nos artigos 3, 7, 8, 15, 16-A, 18, 21, 23, 28, 36 e 37; e alterações regulamentares de IRPC e IRPS. Continua a ser anúncio oficial, sem os números/textos integrais dos decretos, vigência e transição. Os erros editoriais “Lei 12/2005” e Lei 9/2025 associada ao IRPC foram reconciliados com o sumário INM do BR 248: Lei 12/2025 = IRPC; Lei 9/2025 = ISPC. - A AT publica a página da Pauta Aduaneira de Serviço 2026 como tabela de 5.822 códigos com descrição, unidade, direitos, ICE e IVA, e anuncia ficheiros Excel/PDF. O HTML é uma SPA e referencia o bundle oficial `index-XEcizcP2.js`: 4.075.657 bytes; SHA-256 `ba71dd79dbad00588027c3557fceb7eb746aba8861fb5be64f4e368b95f4cd25`. A leitura read-only em memória encontrou 5.822 campos `codigo` distintos no bundle. Não validei todos os campos/taxas, não guardei/importei dataset e não usei valores para cálculo. Os ficheiros Excel/PDF continuam pendentes. - Evidência registada em `docs/investmoz/simulations/official-source-register.md` e `fiscal-reform-2026-review.md`. Os gates das Etapas 4/5/10 continuam sem aprovação de Fiscalista; motor e pautas não foram activados. Não houve alterações a regras, dados ou migrations. - Fontes oficiais: [comunicado do Governo](https://portaldogoverno.gov.mz/governo-introduz-alteracoes-nos-regulamentos-fiscais-para-reforcar-eficiencia-tributaria/), [catálogo INM](https://inm.gov.mz/pt-br/bulletin?field_tipo_de_produto_tid_br=43), [Pauta Aduaneira AT](https://www.at.gov.mz/servicos/pauta-aduaneira). ### Etapa 11 - proteccao contra abuso do endpoint de calculo (2026-10-03) - Adicionado teste feature para o limite publico de calculos: o mesmo token anonimo pode fazer dez pedidos por minuto; o decimo primeiro recebe HTTP 429, cabecalho `Retry-After` e mensagem de limite. Pedidos de teste sao invalidos e nao criam simulacoes nem acedem a dados pessoais. - Evidencia: `php artisan test --filter=SimulationRateLimitTest` passou (1/1; 13 assercoes) usando o PostgreSQL 17 isolado na porta 55441; `php -l tests/Feature/SimulationRateLimitTest.php`, Pint dirigido e `git diff --check` passaram. Aviso preexistente: import `Throwable` sem efeito em `bootstrap/app.php`. - Nenhum comportamento de producao foi alterado. O gate da Etapa 11 continua parcial; a suite global ainda tem as falhas preexistentes registadas acima. ### Etapa 11 - regressao de compatibilidade na submissao empresarial (2026-10-03) - A suite global encontrou que a confirmação por código não era validada para o wizard legado v1; agora o código submetido tem de corresponder ao código do registo. A regra de declaração de objecto para modalidades específicas do wizard v1 também é exercitada; payloads anteriores sem versão continuam no fluxo de compatibilidade existente. - `ExistingBusinessWizardTest` e `ExistingBusinessIntakeTest` passaram em PostgreSQL isolado: 8/8 testes, 123 asserções. Suite Laravel completa actualizada: 222/226 passaram. Restam duas falhas de `EducationTest` (província obrigatória e resposta Inertia) e dois erros em testes que chamam directamente rollback de migration fundacional enquanto `existing_business_rights` ainda referencia `existing_business_objects`; não usei `CASCADE` nem editei migrations executadas. - O teste público de rate limit também passou no conjunto global. Lint PHP e Pint dirigidos passaram; `git diff --check` passou com o aviso preexistente de normalização CRLF/LF em `docs/investmoz/existing-business/form-schema.json`. Aviso de bootstrap `use Throwable` sem efeito permanece. - O servidor temporário PostgreSQL 17/PostGIS da porta 55441 foi encerrado após a suite; a base Laragon não foi usada. A Etapa 11 permanece parcial pelas pendências manuais, funcionais e legais registadas acima. ### Actualizacao da suite global apos corrigir a ordem dos testes de rollback (2026-10-03) - Os dois testes de reversibilidade agora removem primeiro, em ordem inversa, a extensao de marketplace que depende da tabela fundacional e reaplicam-na depois. As migrations de aplicacao nao foram editadas; nao foi usado `CASCADE`. Os dois testes isolados passaram (2/2; 6 assercoes). - Reexecucao integral final de `php artisan test` no PostgreSQL 17/PostGIS temporario: 224/226 passaram. Restam somente as duas falhas de `EducationTest` ja identificadas (fixture sem `province_id` e expectativa de resposta Inertia); nao pertencem ao simulador nem ao fluxo empresarial. - Suite de fluxo empresarial antes da suite global: 8/8, 123 assercoes. Porta 55441 confirmada fechada apos execucao. Lint PHP, Pint dirigido e `git diff --check` passaram; aviso de normalizacao CRLF/LF no schema empresarial e aviso `Throwable` em bootstrap permanecem preexistentes. ### Etapa 1/8 - contrato de resultado aplicado ao snapshot API (2026-10-03) - A execucao aritmetica concluida passou a persistir, de forma aditiva, `contract_version`, `context` e `result`, preservando `indicative_total`, `formula_version` e `legal_interpretation` para clientes existentes. Data de referencia fica ancorada no `created_at` do cenario (não no instante de processamento); moeda e ruleset são explicitamente nulos sem declaração/regra; o valor do envelope é a mesma string decimal exacta do campo legado. - Estado `calculated` refere-se somente à operação aritmética e contém explicação que nega conclusão fiscal; sem fontes legais, `source_ids` fica vazio. O registo de entrada do utilizador continua separado em `simulation_result_sources`. - OpenAPI acrescenta os schemas `SimulationResult`, `SimulationResultContext` e `SimulationResultSnapshotV1`; o documento parseia como JSON e os campos obrigatórios foram verificados. - Evidência: teste PostgreSQL `SimulationExecutionTest::test_anonymous_execution_keeps_only_token_hash_and_reconciles_immutable_sources` passou (1/1; 25 asserções); PHP lint, Pint dirigido e `git diff --check` passaram. Aviso preexistente sobre `Throwable` no bootstrap. O PostgreSQL temporário foi encerrado. - Este é um envelope interno/compatível sobre a execução aritmética existente, não activa nem expõe motor fiscal. Etapas 1 e 8 continuam parciais até todos os endpoints/relatórios e percursos estarem reconciliados. ### Etapa 8 - reconciliação do CSV com o envelope do resultado (2026-10-03) - O CSV agora inclui contrato, data de referência, cenário, versão do motor, estado e explicação quando recebe snapshot v1. Valida o estado aritmético, moeda/regras explicitamente nulas, formato da data e igualdade textual exacta entre `result.value` e `indicative_total`; qualquer divergência bloqueia a exportação. Snapshots antigos sem envelope continuam compatíveis. - Teste de exportação cobre metadados, exclusão de PII, neutralização de fórmulas e divergência entre envelope/campo legado. Evidência: suite frontend completa `node --test tests/frontend/*.test.mjs` passou (87/87); `npm.cmd run types:check` passou; `npm.cmd exec -- vp fmt --check resources/js/lib/simulation-form.ts tests/frontend/simulation-form.test.mjs` passou; `git diff --check` passou com aviso de CRLF/LF preexistente no schema empresarial. - A Etapa 8 ainda não está concluída: resultados e relatórios fiscais permanecem indeterminados sem fonte/regra aprovada; reprodução de todos os relatórios e fluxos necessita validação global/manual. ### Etapas 2/8 - leitura reconciliada do resultado no ecrã e nos anexos (2026-10-03) - O cartão público, a lista de resultados copiados e o CSV usam agora `readArithmeticSnapshot`. Snapshots v1 só exibem o valor se estado, valor decimal, interpretação legal, moeda, versão de regras e contexto forem coerentes; versões desconhecidas/divergentes ocultam o valor e desactivam exportação/conversão. Snapshots antigos sem envelope mantêm leitura como legado. A interface mostra data do cenário e versão do motor em resultados anexados. - O dropdown pesquisável passou de `ul/li` com papéis incompatíveis para o padrão de combobox/listbox com `div` ARIA e opção activa focável; Enter/Espaço activam a opção pelo teclado. O bloco de resultado passou a live region (`aria-live=polite`, `aria-atomic=true`). - Evidência: `node --test tests/frontend/*.test.mjs` passou (88/88); `npm.cmd run types:check` passou; `npm.cmd exec -- vp fmt --check resources/js/lib/simulation-form.ts resources/js/components/simulation-form.tsx tests/frontend/simulation-form.test.mjs` passou; `npm.cmd exec -- vite build --outDir %TEMP%\\investmoz-stage8-result-ui-final-20261003` passou (2.388 módulos; aviso não fatal de `fontaine` opcional ausente); `git diff --check` passou com aviso preexistente de CRLF/LF no schema empresarial. - `vp lint --jsx-a11y-plugin resources/js/components/simulation-form.tsx` já não reporta papéis inválidos nas opções, opções clicáveis sem teclado ou status preferível a `output`; restam duas sugestões `prefer-tag-over-role` para `listbox/option`, necessárias ao combobox pesquisável e não configuráveis como `