1347 lines
267 KiB
Markdown
1347 lines
267 KiB
Markdown
# 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 <pasta-temporária-única> --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 `<output>`; `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 <pasta temporária> --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 `<select>/<option>` sem perder a navegação pesquisável/assíncrona. Continua pendente validação manual com browser, teclado, leitor de ecrã e telemóvel.
|
||
|
||
### Etapa 8 - relatório imutável vinculado à revisão do cenário (2026-10-03)
|
||
|
||
- O envelope versionado agora regista `scenario_version`. O CSV só aceita relatório pronto cuja `version_no` coincide com essa revisão e cujo `report_snapshot` corresponde, por JSON canónico, ao snapshot do resultado; exige também SHA-256 em formato válido. Snapshots v1 sem relatório correspondente, de revisão anterior, divergentes ou sem hash deixam de ser exportados. O legado sem envelope conserva a seleção histórica do relatório pronto mais recente.
|
||
- O job continua a gravar o resultado e relatório dentro da mesma transacção; o teste de execução confirma a versão do cenário e que o snapshot guardado no relatório é igual ao resultado API. OpenAPI tipa `scenario_version` como inteiro >= 1.
|
||
- Evidência: `SimulationExecutionTest::test_anonymous_execution_keeps_only_token_hash_and_reconciles_immutable_sources` passou em PostgreSQL 17/PostGIS isolado (1/1; 27 asserções); testes do CSV/formulário passaram (17/17); PHP lint, Pint, typecheck, formatter dirigido e parse do OpenAPI passaram. O cluster temporário foi encerrado.
|
||
- A exportação ainda não valida o SHA-256 no browser por WebCrypto; confia no hash persistido pelo servidor e na igualdade do snapshot disponibilizado pela API. A verificação backend de hash permanece coberta pelos testes de execução anteriores.
|
||
|
||
### Etapa 10 do anexo actual — auditoria estrutural da pauta aduaneira AT 2026 (2026-10-03)
|
||
|
||
- Objectivo/dependências: verificar se a Pauta de Serviço 2026 disponibilizada pela Autoridade Tributária fornece fonte arquivável e estruturada para o percurso aduaneiro. Dependia de acesso público aos artefactos oficiais e não de parâmetros fiscais aprovados.
|
||
- Ficheiros previstos/alterados: apenas `docs/investmoz/simulations/official-source-register.md`, `docs/investmoz/simulations/fiscal-reform-2026-review.md` e este diário. Nenhum ficheiro de aplicação, migration ou dado foi alterado.
|
||
- Evidência: página AT HTTP 200 com HTML de 495 bytes; HTML e bundle anotados com ETag/data/hash no registo de fontes. Bundle `index-XEcizcP2.js` com 4.075.657 bytes e SHA-256 `ba71dd79dbad00588027c3557fceb7eb746aba8861fb5be64f4e368b95f4cd25`. Extração lexical em memória, sem executar o bundle: 5.822 linhas/códigos únicos, zero duplicados, 70 descrições em falta; ICE em texto misto e sem origem, vigência ou fundamento legal por linha. Nenhum link `.xlsx`, `.xls` ou `.pdf` apareceu no HTML/componente consultados, apesar do texto anunciar download; não se conclui inexistência noutro canal.
|
||
- Decisão: manter direitos aduaneiros, ICE e IVA de importação indeterminados/desactivados. Prosseguir só após obter e reconciliar a pauta/anexos oficiais completos, regras de origem/preferência, método cambial e vigência, com revisão competente. A estrutura da cópia do site não é prova de validação legal.
|
||
- Testes de software: não aplicáveis (auditoria documental/read-only). Foram executados `curl.exe` para obter HTML/bundle em `%TEMP%`, `node` para digest SHA-256 e auditoria lexical do array embutido, e `Get-FileHash` para o HTML; os ficheiros temporários ficaram fora do repositório. Não foi executado teste de aplicação nem acedido à base de dados.
|
||
|
||
### Etapa 4 do anexo — fluxo de governação de versões fiscais (2026-10-03)
|
||
|
||
- Inspecção: havia ciclo genérico de validação/revogação para `investment_legal_sources`, mas não registo versionado de regras nem as quatro funções segregadas.
|
||
- Ficheiros novos: `config/simulation-tax-governance.php`, `app/Models/SimulationTaxRuleVersion.php`, `app/Services/SimulationTaxGovernanceAccess.php`, `app/Services/SimulationTaxRuleGovernance.php`, `app/Http/Controllers/SimulationTaxRuleGovernanceController.php`, `database/migrations/2026_10_03_170000_create_simulation_tax_rule_governance.php`, `tests/Feature/SimulationTaxRuleGovernanceTest.php`, `docs/investmoz/simulations/rule-governance.md` e `docs/investmoz/simulations/rule-governance-openapi.json`.
|
||
- Ficheiros alterados: `routes/investment-zones.php`, `tests/Feature/InvestmentZoneTest.php` (reversibilidade reordena a migration dependente antes da fundação, sem alterar a migration fundacional), `.env.example`, e os registos de governação/fonte deste diário.
|
||
- Implementado: workflow draft → submitted → reviewed/rejected → approved → published → suspended/archived; autor distinto de revisor, aprovador e publicador; hash de snapshot; evidência obrigatória; vigência e `scope_key`; resolução optimista; recusa de fontes revogadas/alteradas; lock e trigger contra vigências publicadas sobrepostas; RLS FORCE nas versões/eventos e eventos append-only. Definição/parametrização é JSON declarativo não executado. Os papéis ficam vazios por defeito. Nenhum motor lê a tabela e nenhuma regra/taxa foi adicionada.
|
||
- Validação PHP 8.5.11/PostgreSQL 17/PostGIS isolado: `SimulationTaxRuleGovernanceTest` 4/4, 52 asserções; regressão dirigida com reversibilidade da fundação 5/5, 56 asserções; Pint passou. Suite PHP completa 228/230; duas falhas `EducationTest` já conhecidas permanecem (fixture sem `province_id`, expectativa de resposta Inertia). Foi executada com `investmoz_test_runner` sem SUPERUSER; RLS foi exercida após limpar o contexto de governação.
|
||
- Outros comandos executados: `php -l` nos seis ficheiros PHP novos/alterados antes do Pint; `php artisan route:list --path=api/v2/investment/admin/tax-rules`; parse de `rule-governance-openapi.json`. Aviso preexistente `use Throwable` em `bootstrap/app.php`.
|
||
- Rollback: a migration aditiva recusa `down()` quando houver versões/eventos; para rollback sem dados, executar em ordem inversa e com backup verificado. A migration só foi exercitada em QA descartável; nenhuma base local operacional foi tocada. O teste de rollback respeita a FK sem `CASCADE`.
|
||
- Pendências do gate: hash do exemplar é declaração e não comparação automática a ficheiro arquivado; falta arquivo oficial autenticado, assinatura nominal de Fiscalista, casos dourados, DSL whitelist/DAG, arredondamento aprovado e ligação segura futura ao motor. **Gate Etapa 4: PARCIAL; gate de cálculo fiscal: BLOQUEADO.**
|
||
|
||
### Etapa 11 — revalidação frontend e tentativa de reproduzir regressões (2026-10-03)
|
||
|
||
- Reexecutei `node --test tests/frontend/*.test.mjs`: 89/89 passaram, incluindo contas a receber vencidas, recuperação declarada, plano de tesouraria, ponte fiscal indeterminada e exportação CSV. `npm.cmd run types:check` passou. `git diff --check` passou; Git reporta apenas normalização CRLF/LF nos documentos existentes.
|
||
- O PostgreSQL temporário em `%TEMP%\investmoz-pg-test-55441` estava parado. `pg_ctl start` falhou porque o processo não conseguiu abrir sockets TCP locais (`Permission denied` em `127.0.0.1` e `::1`); confirmei que a porta 55441 ficou sem listener. Não alterei o servidor Laragon nem outra configuração de rede. As duas falhas PHP de Educação ficam sem nova reprodução nesta sessão.
|
||
- A matriz acima foi corrigida: a recuperação de saldos vencidos já está implementada como hipótese declarada, por isso a limitação correcta é não estimar probabilidade de incumprimento; a suite frontend actual é 89/89. A suite PHP mais recente documentada continua 228/230 no QA isolado.
|
||
- **Estado:** validação frontend aprovada; Etapa 11 parcial até recuperar execução da suite PHP completa e validação manual de UX/acessibilidade. Nenhuma regra fiscal ou integração externa foi activada.
|
||
|
||
### Etapa 2 — correcção do primeiro passo de navegação por teclado (2026-10-03)
|
||
|
||
- No dropdown pesquisável do formulário público, `ArrowDown` com índice ainda não seleccionado avançava do índice `-1` para `1`, saltando o primeiro resultado. A função `moveSearchChoiceIndex` agora inicia no primeiro item ao descer, move para o último ao subir sem selecção, respeita os limites e devolve `-1` para listas vazias. O foco reinicia o índice activo para evitar referenciar uma opção antiga.
|
||
- Testes: `node --test tests/frontend/simulation-form.test.mjs` passou 18/18; suite frontend completa `node --test tests/frontend/*.test.mjs` passou 90/90; `npm.cmd run types:check` e `vp fmt --check` dirigido passaram. Build Vite isolado em `%TEMP%\investmoz-stage2-keyboard-20261003` passou com 2.388 módulos; aviso não fatal: pacote opcional `fontaine` ausente. `git diff --check` passou com avisos de normalização de fim de linha nos documentos empresariais existentes.
|
||
- `vp lint --jsx-a11y-plugin resources/js/components/simulation-form.tsx` continua a devolver duas sugestões `prefer-tag-over-role` para `listbox/option`. Os papéis pertencem ao combobox pesquisável e a navegação de teclado; validar com leitores de ecrã e browsers continua pendente. Não houve validação visual/móvel nesta execução.
|
||
- **Estado:** correcção técnica da navegação validada; Etapa 2 continua parcial até teste manual assistivo/móvel e simplificação dos percursos.
|
||
|
||
### Etapa 6 — agenda mensal de encomendas e prazos de recepção (2026-10-03)
|
||
|
||
- A limitação do prazo único por compra foi removida. O plano permite alternar entre a hipótese mensal constante e uma agenda por mês com montante e prazo de entrega próprios (0–12 meses). Os valores da agenda ficam guardados mesmo quando o utilizador volta ao modo constante; snapshots antigos v1–v11 continuam a restaurar sem agenda inferida. O novo snapshot é `business-plan-v12`.
|
||
- As recepções respeitam o mês de encomenda e o prazo de cada linha; stock inicial, consumo, falta e mercadoria em trânsito reconciliam por mês. Os pagamentos de compras continuam independentes das encomendas. O quadro mensal e o CSV mostram o prazo de cada encomenda e a agenda total. Cenários favorável/desfavorável ajustam montantes activos, preservam prazos e deixam intactos valores inactivos.
|
||
- Ficheiros alterados: `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` e `docs/investmoz/simulations/openapi.json`. Nenhuma migration, dado persistido ou integração externa foi alterada.
|
||
- Testes: plano empresarial 29/29; suite frontend 91/91; `npm.cmd run types:check`, `vp fmt --check`, validação JSON do OpenAPI e `git diff --check` passaram. Build Vite isolado em `%TEMP%\investmoz-stage6-inventory-schedule-20261003` passou com 2.388 módulos; aviso não fatal sobre `fontaine` opcional ausente.
|
||
- Limitações: a agenda continua agregada por valor, não por produto/fornecedor; o consumo é inferido do custo variável das vendas declaradas. Não estima incumprimento de fornecedores nem reduz vendas automaticamente por falta de stock. A validação contabilística institucional permanece pendente.
|
||
- **Estado:** incremento técnico validado; Etapa 6 continua parcial até stock por produto, prazos/condições por fornecedor e revisão institucional do modelo.
|
||
|
||
### Etapa 6 - agenda mensal de pagamentos de compras (2026-10-03)
|
||
|
||
- Acrescentada uma agenda opcional de pagamentos variaveis por mes. O valor constante existente continua a ser usado quando a agenda esta inactiva; quando activa, cada mes usa o seu valor declarado. A agenda e independente das encomendas, recepcoes e prazos de stock.
|
||
- Snapshot empresarial passa a v13. O serializador guarda a agenda ou null; o restaurador valida horizonte e valores textuais, preserva meses fora do horizonte e aceita snapshots v1-v12 sem inferir pagamentos mensais. A interface permite editar o valor constante e os valores mensais.
|
||
- O calculo afecta pagamentos e caixa, sem alterar lucro, consumo ou compras/recepcoes de existencias. Os cenarios favoravel/desfavoravel ajustam a agenda segundo variacoes de volume e custo.
|
||
- Ficheiros: 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 e docs/investmoz/simulations/openapi.json.
|
||
- Testes: plano empresarial 30/30; suite frontend 92/92; TypeScript passou; OpenAPI JSON valido; git diff --check passou com avisos preexistentes de CRLF/LF em documentos empresariais. Formatter aplicado aos tres ficheiros de codigo alterados.
|
||
- Estado: incremento tecnico validado. Etapa 6 continua parcial ate stock por produto, prazos/condicoes por fornecedor e revisao institucional do modelo.
|
||
|
||
### Etapa 6 - stock, compras e faltas por produto (2026-10-03)
|
||
|
||
- A projeccao opcional por produto acrescenta saldo inicial, encomendas mensais e prazo de recepcao por produto. O consumo segue unidades e custo variavel do mesmo produto; recebimentos, stock em transito, saldo final e falta ficam discriminados e somados no total.
|
||
- A soma dos saldos iniciais por produto tem de reconciliar exactamente com existencias iniciais do plano. Falta de um produto nao e compensada por stock de outro e nao reduz automaticamente vendas. Os modos agregado e por produto sao mutuamente exclusivos; pagamentos continuam a ser uma agenda de caixa independente.
|
||
- Snapshot empresarial passa a v14. Leitores aceitam v1-v13 no modelo historico e rejeitam agendas por produto invalidas. Cenários aplicam alteracoes declaradas de volume/custo as compras por produto, preservando prazos.
|
||
- Ficheiros: 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, docs/investmoz/simulations/openapi.json e este diario.
|
||
- Evidencia: testes do plano 31/31; suite frontend 93/93; npm.cmd run types:check passou; vp fmt --check passou; OpenAPI JSON valido; git diff --check passou com avisos preexistentes CRLF/LF; build Vite isolado passou com 2.388 modulos (aviso opcional de fontaine ausente).
|
||
- Reversao: retirar a opcao e o calculo v14; snapshots anteriores continuam validos. Nao foi criada migration nem alterada base de dados.
|
||
- Estado: incremento tecnico validado. Etapa 6 continua parcial ate rever condicoes por fornecedor e modelo contabilistico com responsaveis institucionais.
|
||
|
||
### Etapa 6 - prazos de pagamento por encomenda a fornecedor (2026-10-03)
|
||
|
||
- Em modo de stock por produto, cada encomenda pode declarar prazo de pagamento de 0 a 12 meses desde a data da encomenda. Quando activo, estes prazos geram os pagamentos de compras no fluxo de caixa e substituem a agenda manual de pagamentos variaveis para evitar dupla contagem.
|
||
- Encomendas cujo pagamento vence depois do horizonte ficam identificadas como saldo a pagar; nao sao tratadas como credito confirmado nem como caixa recebido. Prazo fisico de recepcao permanece separado do prazo de pagamento. Nao ha calculo fiscal nem regra comercial presumida.
|
||
- Snapshot empresarial passa a v15; v1-v14 continuam validos. CSV e interface mostram o calendario e os saldos pendentes. O modo requer inventario por produto e cada encomenda tem de declarar prazo valido.
|
||
- Ficheiros: 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, docs/investmoz/simulations/openapi.json e este diario.
|
||
- Evidencia historica do v15: suite frontend 94/94; plano empresarial dirigido 32/32 (inclui pagamentos diferidos, vencimento fora do horizonte, snapshots v14/v15 e CSV); TypeScript, formatter dirigido, JSON OpenAPI, git diff --check e build Vite isolado com 2.388 modulos passaram. Aviso nao fatal: fontaine opcional ausente. Sem migration ou alteracao da base de dados.
|
||
- Etapa 6 v16: cada encomenda pode declarar ate 12 parcelas percentuais com prazo de 0 a 12 meses; arredondamento exacto em centavos e limitado ao saldo da encomenda. Percentagem nao alocada e parcelas fora do horizonte surgem como valores por pagar sem gerar disponibilidade presumida. O formulario, o CSV e snapshots legados foram adaptados; validacao contabilistica institucional e fornecedores partilhados continuam pendentes.
|
||
- Evidencia v16: plano empresarial dirigido 33/33; suite frontend 95/95; `npm.cmd run types:check`, formatter, JSON OpenAPI, `git diff --check` e build Vite isolado com 2.388 modulos passaram. O build emitiu apenas o aviso preexistente sobre fontaine opcional. Sem migration ou alteracao da base de dados.
|
||
- Limitacoes v15 (historicas): uma encomenda era liquidada integralmente numa unica data; o v16 acrescenta parcelas e saldo nao calendarizado. Permanecem sem representacao fornecedores partilhados entre produtos, incumprimento ou confirmacao de credito comercial. Revisao contabilistica institucional continua pendente.
|
||
- Estado: incremento tecnico validado; Etapa 6 continua parcial.
|
||
- Microfinancas: a calculadora de emprestimo mostra junto do plano de reembolso que se trata de simulacao educativa, nao oferta/concessao de credito, captacao de depositos ou registo/licenciamento de operador. Nao foram acrescentados campos ou fluxos para operadores; requisitos legais actuais continuam pendentes de confirmacao oficial.
|
||
- Evidencia do aviso de microfinancas: `npm.cmd run types:check`, `npm.cmd exec -- vp lint --jsx-a11y-plugin resources/js/components/simulation-financial-tools.tsx`, `npm.cmd exec -- vp fmt --check resources/js/components/simulation-financial-tools.tsx`, suite frontend 95/95, build Vite isolado com 2.388 modulos e `git diff --check` passaram. Aviso nao fatal: `fontaine` opcional ausente; `git diff --check` emitiu somente avisos preexistentes CRLF/LF em dois ficheiros nao relacionados.
|
||
- IRPS do trabalho: o cartao fiscal agora repete a vista escolhida (estimativa liquida mensal, retencao mensal ou apuramento anual), declara que nenhum resultado foi calculado enquanto o motor estiver indeterminado e esclarece que a retencao mensal nao equivale ao apuramento anual/cumprimento integral. A validacao do formulario exige escolha da vista apenas para rendimento de trabalho.
|
||
- Evidencia historica desta adaptacao: suite frontend 95/95, `npm.cmd run types:check`, formatter e build Vite isolado passaram. O lint inicial apontou os roles correctos de listbox/option e dois avisos de foco; o comportamento de foco foi corrigido na revisao seguinte.
|
||
- Etapa 2/11, combobox acessivel: as opcoes mantem foco no input com `aria-activedescendant`, deixam de integrar a ordem de Tab, continuam activaveis por rato/teclas e a opcao activa passa a ser deslocada para a zona visivel. A regra JSX-a11y `prefer-tag-over-role` fica localmente justificada porque o select nativo nao cobre pesquisa remota filtrada por dependencias e seleccao multipla.
|
||
- Evidencia combobox: `npm.cmd exec -- vp lint --jsx-a11y-plugin resources/js/components/simulation-form.tsx` sem avisos; formatter e TypeScript passaram; suite frontend 96/96; build Vite isolado com 2.388 modulos; `git diff --check` passou com os avisos preexistentes CRLF/LF em ficheiros nao relacionados. Teste manual com browser/leitor de ecrã continua pendente.
|
||
- Etapa 0/11, configuracao: `.env.example` agora aponta PostgreSQL em 127.0.0.1:5432, base `investemoz` e papel exemplo `investmoz_app`; documenta PostGIS pre-provisionado e o uso de conta de aplicacao com privilegio minimo. O diff que acrescenta papéis fiscais foi preservado. `.env` privado, migrations e bases de dados nao foram alterados.
|
||
- Evidencia da configuracao: verificacao Node confirmou `DB_CONNECTION=pgsql`, porta/base/papel e alinhamento com o servico `postgis/postgis:17-3.5` do CI; `git diff --check` passou com os dois avisos CRLF/LF preexistentes em ficheiros nao relacionados. Nenhuma migration ou suite ligada a base de dados foi executada.
|
||
- Etapa 9: documentado no OpenAPI o endpoint de conversao consentida ja implementado, incluindo `If-Match`, token, ownership, idempotencia por simulacao, verificacao do hash/relatorio, erros e limites de escopo (sem submissao Project/CRM). Teste frontend dedicado impede divergencia entre o contrato publicado e estes controlos.
|
||
- Evidencia Etapa 9/OpenAPI: teste dedicado 1/1; suite frontend 96/96; TypeScript e parse com verificacao da rota passaram; `git diff --check` passou com avisos CRLF/LF preexistentes. Nao executei testes PHPUnit nesta continuacao; a porta PostgreSQL QA 55441 nao tinha servico a escutar.
|
||
|
||
### Formul�rio de oportunidades de neg�cio � revis�o da especifica��o anexada (2026-10-03)
|
||
|
||
- O percurso j� existe em `/investidor/negocios` (cria��o/lista privada) e `/investidor/negocios/{id}` (formul�rio por etapas), implementado em `routes/existing-business.php`, `app/Http/Controllers/ExistingBusinessController.php`, `app/Services/BusinessFormSchema.php`, `app/Services/ExistingBusinessDrafts.php` e `resources/js/pages/investment/business-wizard.tsx`. A rota exige conta autenticada/verificada e a funcionalidade tamb�m depende de `EXISTING_BUSINESS_ENABLED`; verificar configura��o/deploy antes de concluir acessibilidade operacional.
|
||
- A compara��o com o texto anexado confirma t�tulo/descri��o, sete categorias can�nicas, sector, situa��o/disponibilidade/prazo, proponente/contactos, representa��o, territ�rio dependente, valores condicionais, fontes, confirma��o, grava��o de rascunho, submiss�o para triagem, vers�o optimista e publica��o s� ap�s workflow de revis�o. As regras de submiss�o tamb�m s�o aplicadas no servidor.
|
||
- Lacunas confirmadas: o escopo �v�rias localiza��es� guarda apenas uma hierarquia territorial; n�o h� sugest�o de subsector/actividade por designa��o; anexos n�o s�o suportados (a interface avisa para n�o carregar ficheiros); a pr�-visualiza��o edit�vel dos campos potencialmente p�blicos n�o est� claramente identificada como ac��o aut�noma. Contactos/anexos n�o s�o publicados automaticamente; pedidos de informa��o e encerramento devem ser confirmados no fluxo completo antes de os considerar cobertos.
|
||
- Nenhum c�digo ou dado funcional foi alterado nesta revis�o; n�o foram executados testes nem consultada a configura��o privada/servidor. O fluxo fica classificado como **parcialmente conforme**, n�o como oportunidade p�blica activa. Para anexos e m�ltiplas localiza��es, definir antes os controlos de autoriza��o, armazenamento, reten��o e privacidade.
|
||
- Correc��o ap�s inspec��o da etapa final do wizard: existe ac��o expl�cita de pr�-visualiza��o e campo de subsector/actividade por designa��o (`business-wizard.tsx`, `BusinessFormSchema.php`). A lacuna refere-se � gest�o de v�rias localiza��es, n�o ao escopo declarativo; e ao facto de os anexos n�o terem implementa��o.
|
||
|
||
### Etapa 1/8 — identificador inequívoco do motor aritmético (2026-10-03)
|
||
|
||
- Novas execuções passam a identificar fórmula e motor como `portal-arithmetic-v1`; a fórmula matemática não mudou, continua sem taxa ou interpretação legal. Snapshots anteriores identificados como `portal-tax-arithmetic-v1` não são reescritos e permanecem legíveis.
|
||
- Ficheiros: `app/Services/SimulationExecution.php`, `app/Jobs/RunSimulation.php`, `tests/Feature/SimulationExecutionTest.php`, `docs/investmoz/simulations/data-contracts.md` e este registo.
|
||
- Evidência: typecheck TypeScript passou; suíte frontend completa 96/96 passou antes da alteração; depois da alteração, `tests/frontend/simulation-form.test.mjs` 18/18 passou para validar leitura/exportação compatível com resultados históricos; `php -l` nos três PHP passou. `git diff --check` passou com avisos preexistentes de normalização CRLF/LF em documentos de cadastro de negócio.
|
||
- A suite PHPUnit/PostgreSQL não foi executada nesta alteração: o ambiente de QA PostgreSQL não estava disponível na revisão anterior; não acedi à base local. Os binários Chrome/Edge/Chromium e Playwright/Puppeteer não estão instalados, portanto a sessão manual de browser/leitor de ecrã da Etapa 11 continua pendente.
|
||
|
||
### Etapa 9/11 — reforço do escopo de rascunhos e repetição da regressão PostgreSQL (2026-10-03)
|
||
|
||
- A suite completa revelou que `SimulationFormDrafts` deixava `find`, `update`, `delete` e anexação de simulação dependentes apenas de RLS. Em ligações de teste com papel superuser, RLS é contornado; agora cada operação também filtra explicitamente por `owner_user_id` ou hash do token anónimo, e por registos não eliminados. A política RLS continua activa como segunda camada.
|
||
- O teste de governação agora verifica que o trigger append-only ou RLS rejeita alteração e que os eventos publicados permanecem inalterados; suporta correctamente a diferença entre papéis superuser e limitados no PostgreSQL de teste.
|
||
- Tipos explícitos foram acrescentados aos modelos/contratos do fluxo de snapshots. A validação `StoreSimulationFormDraftRequest::snapshots()` entrega ao serviço apenas os dois arrays já validados.
|
||
- Ficheiros deste incremento: `app/Services/SimulationFormDrafts.php`, `app/Http/Requests/StoreSimulationFormDraftRequest.php`, `app/Http/Controllers/Api/V1/SimulationFormDraftController.php`, modelos `SimulationFormDraft`, `Simulation`, `SimulationReport`, `InvestmentLegalSource`, `SimulationTaxRuleVersion`, `app/Services/SimulationTaxRuleGovernance.php`, `tests/Feature/SimulationTaxRuleGovernanceTest.php` e este registo.
|
||
- Ambiente: inicializei PostgreSQL 17/PostGIS num cluster novo `%TEMP%\investmoz-stage11-pg-20261003`, DB `investmoz_test`, papel `investmoz_test`, porta 55441; PHP CLI 8.5.11. O servidor foi parado no fim e a base Laragon não foi usada. O directório temporário próprio foi mantido porque a política do shell rejeitou o comando de remoção recursiva.
|
||
- Testes: `Simulation(Execution|FormDraft|TaxRuleGovernance)Test` 26/26, 214 assertions; suite frontend 96/96; PHPStan nos nove ficheiros/modelos afectados 0 erros; Pint nos ficheiros PHP alterados passou; `git diff --check` passou com avisos preexistentes CRLF/LF em dois documentos empresariais.
|
||
- Regressão completa PHPUnit: 228/230 passaram. As duas falhas restantes são ambas `EducationTest`: proposta antiga sem `province_id` recebe redirecção de validação (teste esperava 422); percurso de análise falha a asserção Inertia com a localização fixture antiga. Não alterei Educação neste incremento por estar fora do escopo do simulador.
|
||
- PHPStan global continua com 58 erros noutras partes do projecto. `composer run types:check` falha pelo acumulado global; os ficheiros do fluxo do simulador/governação acima analisados isoladamente passam. Aviso adicional preexistente: `bootstrap/app.php:13`, import sem efeito de `Throwable`.
|
||
- **Estado:** regressões críticas de isolamento/imutabilidade do simulador corrigidas e testadas. Etapa 9 parcial (Project/CRM real pendente); Etapa 11 permanece parcial pelas duas falhas de Educação, erros PHPStan fora do âmbito, revisão manual de browser/acessibilidade e gates legais/fiscais.
|
||
|
||
### Actualização da regressão PHPUnit e EducationTest (2026-10-03)
|
||
|
||
- Correcção à entrada anterior: as duas falhas de Educação foram investigadas e resolvidas dentro da regressão descoberta. `EducationController` importava `InvestmentGeography` pelo namespace do controlador em vez de `App\Services\InvestmentGeography`, causando erro de resolução da classe no ecrã de análise. A fixture de `EducationTest` também criava um distrito sem a hierarquia país/província exigida e omitia `province_id` na proposta; agora declara a hierarquia e envia os dois identificadores esperados.
|
||
- Ficheiros: `app/Http/Controllers/EducationController.php`, `tests/Feature/EducationTest.php` e este diário. Removida a instrumentação temporária de diagnóstico.
|
||
- Evidência: `EducationTest` dirigido 8/8, 205 assertions; suíte completa PHPUnit 230/230, 2.282 assertions. `composer run types:check` ainda falha no acumulado PHPStan do repositório (56 erros); a correcção do import reduziu o total anterior de 58. O aviso `bootstrap/app.php:13` sobre import sem efeito de `Throwable` continua.
|
||
- PostgreSQL 17/PostGIS usado em cluster isolado `%TEMP%\investmoz-stage11-pg-20261003`, DB `investmoz_test`, papel `investmoz_test`, porta 55441; parado após validação. A base Laragon não foi usada. O directório temporário foi mantido porque o shell rejeitou a remoção recursiva.
|
||
- **Estado actualizado:** PHPUnit completo passa. Permanecem os gates PHPStan global, browser/acessibilidade manual, conformidade Project/CRM da Etapa 9 e validação fiscal/legal humana já listados nas entradas anteriores; nenhum gate fiscal foi activado.
|
||
|
||
### Catálogos de referência: tipagem estática e QA isolado (2026-10-03)
|
||
|
||
- `ReferenceCatalogController` valida agora o código do catálogo como união dos três valores suportados, converte o resultado do query builder para array na fronteira de apresentação e mantém as colunas de pesquisa como literais SQL internas. A resposta HTTP não mudou.
|
||
- Evidência: PHPStan dirigido ao controlador 0 erros; `ReferenceCatalogTest` 9/9, 56 assertions, executado somente no PostgreSQL 17 temporário `investmoz_test`/papel `investmoz_test`/porta 55441; servidor parado no fim. PHPStan global passou de 56 para 26 erros. Aviso `bootstrap/app.php:13` sobre import de `Throwable` continua.
|
||
- **Incidente de ambiente a investigar:** a primeira execução de `php artisan test --filter=ReferenceCatalogTest` herdou `DB_PORT=5432` do `.env`, pois `phpunit.xml` não fixa a porta. A salvaguarda do `Tests\TestCase` só prepara bases QA na porta 55441; como as configurações apontavam para `investmoz_test` na 5432, `RefreshDatabase` iniciou `migrate:fresh` nessa ligação e parou na migração do schema separado `skills_edu`. Leitura posterior confirmou 44 registos de migração (de 58 existentes no repositório), 112 tabelas públicas e schema `skills_edu` presente. É provável que `migrate:fresh` tenha removido dados anteriores dessa base; o conteúdo prévio e eventual impacto não podem ser determinados sem backup/base comparativa. Não executei mais comandos nem alterações na porta 5432. A procura de ficheiros de backup no repositório não encontrou dumps.
|
||
- O teste foi repetido com `DB_PORT=55441`, `DB_USERNAME=investmoz_test` e password vazia, validando a separação e passando. A instância QA foi parada. Antes de outros testes PHPUnit, fixar explicitamente os parâmetros QA e verificar a porta activa.
|
||
- **Estado:** alteração de tipagem do catálogo validada; restante PHPStan global 26 erros. Incidente de dados em `investmoz_test:5432` requer comparação/restauro a partir de cópia de segurança adequada; não tentar reconstrução ou restauração automática sem origem confirmada.
|
||
- Prevenção acrescentada após o incidente: `phpunit.xml` define agora `DB_PORT=55441` e `DB_USERNAME=investmoz_test`, evitando herdar silenciosamente o PostgreSQL da aplicação no uso local. O workflow GitHub já fornece explicitamente as próprias variáveis de ambiente para o serviço descartável na porta 5432; o handler PHPUnit só usa o valor XML quando a variável do processo não existe, conforme `vendor/phpunit/phpunit/src/TextUI/Configuration/PhpHandler.php`.
|
||
|
||
### Tipagem do histórico do simulador e protecção do runner PHPUnit (2026-10-03)
|
||
|
||
- `SimulationController::history()` tipa a função de mapeamento com `Simulation` e lê `organization_name`/`has_ready_report` como atributos seleccionados pela consulta, em vez de declarar como propriedades permanentes do modelo. Isto mantém o payload e elimina tipos não resolvidos no mapeamento.
|
||
- O runner PHPUnit fixa por omissão `DB_PORT=55441` e `DB_USERNAME=investmoz_test`; variáveis já fornecidas pelo processo CI continuam prioritárias. A verificação XML confirmou os valores locais de QA. Isto impede que um `DB_PORT` herdado do `.env` direccione `RefreshDatabase` para 5432 em execuções locais comuns.
|
||
- Evidência desta sequência: PHPStan dirigido `SimulationController` 0 erros; teste de histórico `test_account_history_contains_only_the_verified_users_personal_simulations` 1/1, 15 assertions no cluster descartável da porta 55441, servidor parado; PHP syntax e `git diff --check` passaram. PHPStan global agora 22 erros; import sem efeito em `bootstrap/app.php:13` continua como aviso.
|
||
- O teste PHPUnit falhado anterior em 5432 e o risco de perda de dados permanecem registados sem tentativa de recuperação. A base da porta 5432 não foi mais consultada nem alterada nesta sequência.
|
||
|
||
### Etapa 11 — tipagem estática e regressão PHPUnit completas (2026-10-03)
|
||
|
||
- Corrigidos tipos do mapeamento de histórico (`SimulationController`), lista de responsáveis e resource do catálogo público de oportunidades; o resource lê os atributos do resultado da consulta via `data_get` e os aliases territoriais via `getAttribute`. `ExistingBusiness` documenta as propriedades de domínio e o instante de publicação imutável devolvido pelo cast.
|
||
- `EducationInvestmentController` agora rejeita explicitamente uma selecção territorial vazia antes de indexar o último elemento. `TerritoryReferenceSeeder` removeu verificações redundantes e valida que ID, tipo e pai têm tipos válidos antes de preencher os mapas de validação; a saída informativa do comando usa o comando de seeding disponível.
|
||
- Removido de `bootstrap/app.php` o `use Throwable` redundante; a referência continua a resolver para a classe global e desapareceu o aviso do PHP.
|
||
- **Evidência:** `composer run types:check` passou globalmente com 0 erros e sem avisos; suíte PHP completa no cluster QA explícito PostgreSQL 17/PostGIS `127.0.0.1:55441`, DB/papel `investmoz_test`: 230/230 testes, 2.282 assertions. Cluster parado após os testes. `ReferenceCatalogTest|EducationTest`: 17/17, 261 assertions; `BusinessMarketplacePublicTest`: 2/2, 17 assertions; histórico de simulações: 1/1, 15 assertions. Pint dirigido passou; sintaxe PHP passou; `git diff --check` dirigido aos ficheiros alterados passou. A verificação global do diff ainda emite avisos de normalização CRLF/LF em dois documentos empresariais preexistentes.
|
||
- **Estado técnico:** sem erros PHPStan globais; PHPUnit completo verde. Etapas 4/5/10 continuam bloqueadas para publicação por validação jurídica/fiscal e aprovação humana; Etapa 6 mantém revisão institucional do modelo; Etapa 9 continua sem integração real com Project/CRM; Etapa 11 ainda precisa de revisão manual de teclado/leitor de ecrã e validação de produto.
|
||
- O incidente da base `investmoz_test:5432` permanece sem comparação a backup: nenhuma tentativa de restauro ou nova ligação a 5432 foi feita. O runner PHPUnit local agora fixa 55441/`investmoz_test`; o CI mantém as variáveis explícitas do seu serviço isolado.
|
||
|
||
### Etapa 11 — regressão PHP completa após limpeza PHPStan (2026-10-03)
|
||
|
||
- Removidos os 22 erros PHPStan globais restantes: índice territorial sem validação de lista vazia; retorno genérico do builder de utilizadores; propriedades dinâmicas do resource público; tipos do modelo `ExistingBusiness`; e validação/estado do `TerritoryReferenceSeeder`. As validações de ID/tipo/pai do seeder mantêm as verificações de integridade do dataset.
|
||
- **Verificação final:** `composer run types:check` — passou, 0 erros; `vendor/bin/pint --test` nos nove ficheiros PHP afectados — passou; PHP lint nos ficheiros alterados — passou; `git diff --check` dirigido — passou.
|
||
- **PHPUnit completo:** `php artisan test` com `DB_HOST=127.0.0.1`, `DB_PORT=55441`, `DB_DATABASE=investmoz_test`, `DB_USERNAME=investmoz_test`, password vazia — 230/230 testes, 2.282 assertions. Cluster QA temporário parado após execução. Cobertura dirigida adicional: histórico do simulador 1/1 (15 assertions), marketplace público 2/2 (17), catálogo territorial e Educação 17/17 (261).
|
||
- `phpunit.xml` localiza por omissão testes na QA 55441/`investmoz_test`; as variáveis já definidas pelo CI conservam precedência. Nenhum teste executado contra 5432 nesta continuação.
|
||
- A revisão de código identifica que Etapas 0/1/3 têm implementação técnica extensa, Etapa 2 ainda aguarda navegação manual/assistiva, Etapa 4/5/10 requer fontes oficiais, parâmetros/gates e aprovação humana, Etapa 6 requer validação institucional, Etapa 7 só pode calcular com ponte fiscal indeterminada enquanto as regras não forem aprovadas, Etapa 9 requer integração real Project/CRM, e Etapa 11 aguarda browser assistivo e decisão de produto. O resumo executivo e estados legados do diário devem ser reconciliados contra esta evidência antes da entrega final.
|
||
- O risco de dados em `investmoz_test:5432` continua pendente de backup/comparação; não foi recuperado nem houve acesso posterior a essa porta.
|
||
|
||
### Reconciliação do estado resumido (2026-10-03)
|
||
|
||
Esta entrada substitui os totais antigos na matriz e checklist de Etapa 11 acima: a suíte PHP actualmente verificada é 230/230 (2.282 assertions), não 228/230, e o PHPStan global está limpo (0 erros). A validação de integração automatizada usa PostgreSQL/PostGIS isolado na porta QA 55441 e passou; apenas a validação manual com browser, leitor de ecrã e dispositivo móvel continua pendente. As afirmações anteriores de que nenhuma consulta/migração foi feita descrevem a fase inicial da auditoria, não o estado actual; houve testes nos clusters QA e o incidente separado `investmoz_test:5432` está documentado acima. Gates fiscais/legais e integração Project/CRM real continuam pendentes.
|
||
|
||
- Reforço do isolamento local em `phpunit.xml`: também fixados `DB_HOST=127.0.0.1` e `DB_PASSWORD` vazio, além de porta/base/papel QA. Verificação sem qualquer `DB_*` exportada no processo: PHPUnit carregou os padrões XML e o teste de histórico passou (1/1, 15 assertions) na porta 55441. As variáveis definidas pelo workflow CI prevalecem porque já existem no processo.
|
||
|
||
### Etapa 2/11 — verificação de browser e correcção de sobreposição móvel (2026-10-03)
|
||
|
||
- A rota `/simulador-fiscal` foi aberta em Microsoft Edge headless usando o servidor Laravel local e o Vite que já estava activo. A primeira captura móvel mostrou o botão fixo “Contactar Apoio ao Investidor” por cima dos campos. O botão permanece fixo a partir de `sm` (640 px) e passa ao fluxo normal depois do conteúdo em ecrãs pequenos; o espaçamento inferior também passou a responder ao breakpoint.
|
||
- Diagnóstico no browser com viewport 390 px: `innerWidth=390`, `clientWidth/documentWidth/bodyWidth=375` (scrollbar vertical do browser ocupa 15 px), formulário `x=20..355`, título e inputs dentro da largura; campos com 301 px; a barra de etapas tem conteúdo largo, mas o overflow fica contido na respectiva região `overflow-x:auto`; contacto móvel `position:static`, `x=12..363`. Sem overflow horizontal do documento nem sobreposição do CTA.
|
||
- Evidência visual: Edge desktop antes da alteração em `%TEMP%\investmoz-simulator-20261003.png`; Edge móvel após a correcção em `%TEMP%\investmoz-simulator-mobile-after-20261003.png`. O ficheiro de diagnóstico temporário em `public/` foi removido. Os servidores Laravel de verificação e o cluster PostgreSQL QA foram parados; Vite preexistente foi preservado. Nenhuma ligação à porta 5432.
|
||
- Validação após formatação: `node --test tests/frontend/*.test.mjs` 96/96; `npm.cmd run types:check`; lint JSX-a11y dirigido; formatter dirigido; `git diff --check` dirigido — todos passaram. Avisos de renderer/sync emitidos pelo Edge headless não impediram a captura.
|
||
- A revisão com leitor de ecrã, teclado real e dispositivo físico continua pendente. A captura mede o layout estático, não certifica acessibilidade assistiva completa.
|
||
|
||
### Etapa 2/11 — breakpoint responsivo ajustado para ecrãs largos (2026-10-03)
|
||
|
||
- A acção “Contactar Apoio ao Investidor” permanece no fluxo normal até ao breakpoint `lg` (1024 px) e só fica fixa em ecrãs largos. O espaçamento inferior também só reserva espaço adicional nesse breakpoint. Isto inclui tablets e evita que o botão cubra os campos em larguras intermédias.
|
||
- Evidência funcional: a rota `/simulador-fiscal` respondeu HTTP 200 no servidor local configurado exclusivamente para a base QA PostgreSQL isolada em 127.0.0.1:55441. Microsoft Edge headless renderizou a página a 390×844; a captura `%TEMP%\investmoz-simulator-mobile-after-lg-20261003.png` mostra o botão fora da área inicial do formulário, no fluxo da página. A captura não substitui medição num dispositivo físico nem validação assistiva.
|
||
- Verificações: `npm.cmd run types:check`, lint JSX-a11y dirigido, formatter dirigido e `git diff --check` no ficheiro alterado passaram. Não foi executada suite de testes nesta alteração.
|
||
- Os processos Laravel (porta 18082) e PostgreSQL QA (porta 55441) foram parados depois da captura. O Vite que já estava activo na porta 5173 foi preservado. A instância PostgreSQL da porta 5432 não foi consultada nem alterada.
|
||
- Estado: correcção visual técnica concluída para o CTA; Etapa 2 permanece parcial até validação manual com teclado/leitor de ecrã, dispositivo real e revisão do fluxo com produto.
|
||
|
||
- Regressão frontend geral repetida após o ajuste responsivo: `node --test tests/frontend/*.test.mjs` — 96/96 passaram. Uma captura adicional foi produzida a 390×844, mas a tentativa de extrair medidas DOM com a página de diagnóstico não gerou saída válida; a captura isolada não sustenta uma afirmação nova sobre largura total/overflow, pelo que essas dimensões ficam por revalidar.
|
||
|
||
### Reconciliação actual do estado da sequência (2026-10-03)
|
||
|
||
Esta reconciliação prevalece sobre as linhas da matriz/checklist inicial que ainda mostram contagens antigas ou descrevem um estado anterior do worktree:
|
||
|
||
- Branch actual `main`, commit base `4f35313`. O worktree contém alterações locais de várias etapas; preservá-las e não usar reset/clean global.
|
||
- O estado actual contém migrations de rascunhos do simulador, extensão do cadastro de oportunidades e governação fiscal versionada. Portanto, a frase inicial “nenhuma migration foi criada” é histórica e não descreve o worktree actual. `phpunit.xml` aponta por omissão para QA isolado `127.0.0.1:55441/investmoz_test`; a suite completa mais recente foi 230/230 no cluster isolado, posteriormente parado.
|
||
- Nesta continuação, a regressão frontend completa passou 96/96; TypeScript, JSX-a11y, formatter e diff check do breakpoint responsivo também passaram. A porta 5432 permaneceu sem acesso neste turno.
|
||
- Estado consolidado por etapa: 0 concluída; 1 parcial (contrato não aplicado a todo o domínio); 2 parcial (layout melhorado; overflow/teclado/leitor de ecrã em dispositivo continuam sem confirmação manual); 3 parcial e educativo; 4 com gate legal/fiscal pendente; 5 sem cálculo fiscal público; 6 implementada em grande parte no cliente, com validação contabilística institucional pendente; 7 parcial e fiscalmente indeterminada; 8 parcial (CSV e snapshots, sem PDF/arquivo completo); 9 parcial (rascunho consentido, sem submissão real a Project/CRM); 10 bloqueada para regras sectoriais/aduaneiras não verificadas; 11 automação técnica verde segundo os últimos resultados, ainda sem revisão assistiva, produto e gates humanos.
|
||
- Próxima continuação segura: melhorar/validar a experiência móvel e automatizar as verificações browser possíveis sem instalar dependências ou usar a base da aplicação; em paralelo, avançar documentação e componentes financeiros sem lhes atribuir validação contabilística ou fiscal.
|
||
|
||
### Etapa 4 — verificação read-only do acesso ao BR 248 (2026-10-03)
|
||
|
||
- Reconfirmei no sumário oficial da INM a identificação legislativa: Lei 9/2025 corresponde ao ISPC; Lei 12/2025 corresponde ao IRPC. A página oficial da AT lista o suplemento BR 248 em PDF (430 KB), mas o endereço candidato obtido de uma captura arquivada respondeu HTTP 200 com `Content-Type: text/html` e 495 bytes; não era o documento. Não usei nem arquivei reprodução de terceiro como fonte primária.
|
||
- Actualizei `docs/investmoz/simulations/official-source-register.md` com o método, resposta HTTP, URLs oficiais e limitação. Artigos, anexos e transições ainda não foram verificados; nenhuma regra ou parâmetro foi activado.
|
||
- Evidência externa: [sumário oficial da INM](https://inm.gov.mz/pt-br/content/sum%C3%A1rio-suplemento-n%C2%BA-1-de-291225-pag-2180-1-20-br-n%C2%BA-248-boletim-da-rep%C3%BAblica-i-serie-p%C3%A1g-1) e [catálogo oficial de legislação fiscal da AT](https://www.at.gov.mz/legislacao/fiscal). Comando efectivamente executado: `curl.exe -I -L --max-time 30 <URL candidata da AT>`; resultado HTTP 200, HTML 495 bytes. A pendência de obter cópia normativa legível continua no gate humano.
|
||
|
||
### Etapa 4/5/10 — aquisição e leitura do texto primário fiscal BR 248 (2026-10-03)
|
||
|
||
- Revalidei a rota de download oficial: o URL de CMS tentado antes devolvia apenas o shell SPA de 495 bytes. O próprio catálogo da AT expõe /api/documents?root=LEGISLACAO e um download WebDAV oficial. Obtive e arquivei o PDF em docs/investmoz/simulations/source-archive/BR-248-I-Suplemento-1-2025.pdf, 440.018 bytes, SHA-256 CCF2A8DEECA820F2DD076B4B2141B1EFE3F6A806568C3A587CA59A8E92F4C251. O PDF tem 21 páginas; extracção local com pdfjs-dist 4.10.38 temporário, sem alterar dependências.
|
||
- A nova matriz primary-text-review-2025-2026.md regista artigos/vigência das Leis 7–12/2025: ICE e tabela 2027; instruções/códigos aduaneiros; elegibilidade, exclusões, opção, escalões e deveres ISPC; IVA digital, dedução/crédito/reembolso; factores de residência e retenção mensal/mais-valias IRPS; estabelecimento permanente, digital, retenção e contabilidade IRPC.
|
||
- Divergência crítica IVA documentada: artigo 34 da Lei 10/2025 usa divisor 116; AT continua a exibir 17% em informação e formulário; INM indica sem efeito a publicação inicial da Lei 22/2022, embora diplomas posteriores a citem. Sem cadeia corrigida/consolidada e parecer competente, o parâmetro IVA 2026 fica indeterminado. Não criar golden case com taxa presumida.
|
||
- Confirmado no texto legal que a continuidade/eliminações parciais de regimes do IVA não equivalem a eliminar ISPC. Casos fiscais, retenções e direito a reembolso seguem pendentes de regulamentos publicados e aprovação; crédito de IVA não é liquidez. Nenhuma regra foi activada.
|
||
- Os anúncios de 30-09-2026 não substituem os textos dos BR 186/187; ainda falta obter/analisar os actos, vigência e transições. INSS, tratado por tratado, pauta completa classificada, benefícios e aprovação do Fiscalista também permanecem pendentes.
|
||
- Limpeza de três scripts temporários de extracção/inspecção do repositório após arquivamento. Hash do arquivo no repositório voltou a corresponder ao obtido no download.
|
||
- Comandos/evidência: API oficial AT/WebDAV (HTTP 200 application/pdf; detalhes documentados no registo); Get-FileHash -Algorithm SHA256 no arquivo; extracção local com pdfjs-dist 4.10.38; teste automatizado não aplicável a esta alteração documental. A pesquisa web confirmou que AT/Formulário mostra 17%, sumário INM identifica Lei 3/2025 e nota de publicação sem efeito da Lei 22/2022.
|
||
- Gate proposto: fonte primária BR 248 arquivada/lida; gate de activação fiscal/aduaneira **PENDENTE/BLOQUEADO** até reconciliação jurídica de IVA, regulamentos 2026, regras por código e aprovação formal. Componentes financeiras independentes podem continuar.
|
||
|
||
### Actualização Etapa 4/5/10 — reconciliação primária da taxa IVA (2026-10-03)
|
||
|
||
- Adquiri pelo catálogo oficial AT o PDF da Lei 22/2022 identificado como republicação do 2.º Suplemento do BR 250, 1.834.284 bytes, SHA-256 EA1B0DC6F5CF6E595F6D9A19E7042F398999E0087CAEF1785F6E8FAC571B5F53; arquivado em docs/investmoz/simulations/source-archive/Lei-22-2022-IVA-republicada-BR-250-2-suplemento.pdf. Extracção local de 18 páginas; a página 3 do PDF (página 27 do BR) contém art. 17(1): taxa de 16%.
|
||
- INM informa que a primeira publicação da Lei 22/2022 ficou sem efeito e a mesma lei foi republicada no 2.º Suplemento; o PDF consultado é exactamente esse suplemento. A Lei 3/2025 altera art. 9(13); Lei 10/2025 não altera art. 17 e art. 34 usa divisor 116. As referências AT a 17% são administrativas e desactualizadas. A divergência fica resolvida no plano textual: taxa geral de IVA 16%.
|
||
- Actualizei a matriz de fonte primária; as adendas anteriores que deixavam taxa IVA indeterminada foram explicitamente corrigidas. Ainda não activar: a revisão/aprovação formal do Fiscalista, regulamentos 2026 e casos dourados aprovados continuam por cumprir.
|
||
- A consulta do catálogo AT recursivo encontrou Lei 22 IVA 2022, mas não encontrou documentos BR 186/187 nem actos regulamentares fiscais de 2026. Isto é limite desse catálogo, não prova de que os BR não contenham tais actos. Pesquisa INM acessível continua a mostrar metadados/listagem sem texto integral; estado dos regulamentos permanece por confirmar.
|
||
- Evidência/validação: Invoke-RestMethod do catálogo AT, download WebDAV, Get-FileHash SHA256, extracção PDF local por pdfjs-dist 4.10.38; resultados documentados no relatório. git diff --check dirigido será verificado após a actualização documental. Sem testes de aplicação nesta alteração.
|
||
- Gate proposto: taxa textual do IVA confirmada, mas motor/relatórios fiscais continuam gate PENDENTE até Fiscalista aprovar regras/casos, regulamentação 2026 e reconciliações remanescentes. Calculadoras financeiras independentes podem prosseguir.
|
||
|
||
### Etapa 8 — detalhe opcional no resultado público (2026-10-03)
|
||
|
||
- O resultado concluído agora mantém primeiro o resumo aritmético e oferece um disclosure nativo “Detalhes do cálculo e da versão” para consulta opcional. Apresenta base, taxa/redução introduzidas, moeda (ou ausência), data de referência, versão do motor, cenário, fórmula e período pontual sem atribuir período fiscal; identifica ausência de regras/fontes legais e mantém o aviso indicativo.
|
||
- Só aparece quando o snapshot não está inconsistente. Quando a integridade é inválida, a UI continua a ocultar detalhe, desactivar exportação/conversão e explicar o motivo. CSV permanece a exportação pública sem autenticação e valida a correspondência do snapshot versionado ao relatório/hash; os testes anteriores cobrem reconciliação, versão e exclusão de dados pessoais.
|
||
- Ficheiro alterado: resources/js/components/simulation-form.tsx. Sem alterações à API, banco de dados, snapshots persistidos, fórmulas ou regras fiscais.
|
||
- Verificações finais: npm.cmd run types:check passou; node --test tests/frontend/*.test.mjs passou 96/96; npm.cmd run build passou (2388 módulos; apenas aviso de dependência opcional fontaine, sem falha); npm.cmd run check -- resources/js/components/simulation-form.tsx passou formatação e lint sem avisos; git diff --check -- resources/js/components/simulation-form.tsx passou.
|
||
- Gate da Etapa 8 continua parcial: não há PDF/arquivo imutável completo e a validação visual/assistiva desta nova disclosure em browser/leitor de ecrã não foi feita neste ciclo. Nenhuma publicação externa ocorreu.
|
||
|
||
### Etapa 8 — correspondência do relatório visível com o snapshot (2026-10-03)
|
||
|
||
- A UI agora identifica no disclosure opcional o ID e o SHA-256 do relatório imutável apenas se um relatório pronto tiver a mesma revisão de cenário e snapshot JSON canónico do resultado concluído, além de hash com formato válido.
|
||
- Para envelopes versionados sem relatório correspondente, a exportação CSV e a conversão para rascunho ficam desactivadas; a interface explica que o relatório está pendente ou diverge. O servidor continua como autoridade da integridade e valida o hash durante a conversão. Resultados legados mantêm o comportamento existente.
|
||
- Ficheiros: `resources/js/lib/simulation-form.ts` (referência validada), `resources/js/components/simulation-form.tsx` (ID/hash e gating), `tests/frontend/simulation-form.test.mjs` (correspondência e rejeição de snapshot/hash divergente).
|
||
- Evidência: `npm.cmd run check:fix -- ...` e `npm.cmd run check -- ...` passaram nos três ficheiros; `npm.cmd run types:check` passou; `node --test tests/frontend/simulation-form.test.mjs` passou 19/19; suite frontend completa passou 97/97; `npm.cmd run build` concluiu; lint JSX-a11y dirigido e `git diff --check` passaram.
|
||
- Limitações: verificação manual do browser/leitor de ecrã continua pendente. A interface valida estrutura/hash reportado e correspondência do snapshot; a validação criptográfica autoritativa permanece no servidor. Nenhuma API, banco, regra fiscal ou integração externa foi alterada.
|
||
- Estado da Etapa 8: continua **parcial** (sem PDF/arquivo imutável completo e revisão assistiva manual). Próximo avanço independente: prosseguir a validação da Etapa 2/11 em browser assistivo, se houver ferramenta disponível; em paralelo, manter Etapas fiscais 4/5/10 bloqueadas até fontes completas e aprovação humana.
|
||
|
||
### Etapa 4/5/10 — rechecagem oficial da disponibilidade dos BR 186/187 (2026-10-03)
|
||
|
||
- A listagem da INM confirma BR 186 (30-09-2026, BR18622683/NID 22683) e BR 187 (01-10-2026, BR18722684/NID 22684). As fichas acessíveis só apresentam metadados; o catálogo indica que o produto não está disponível para download gratuito e encaminha para a Loja. A abertura web da INM expirou nesta rechecagem.
|
||
- Esta evidência melhora o diagnóstico de acesso, mas não permite inferir que os decretos anunciados estejam nesses boletins, nem confirmar artigos ou vigência. A íntegra pode exigir consulta/aquisição oficial ou exemplar fornecido por responsável competente.
|
||
- Actualizado `official-source-register.md`; nenhuma taxa, regra ou integração foi activada. Gates 4/5/10 continuam pendentes de texto normativo lido e aprovação identificável.
|
||
- Próxima tarefa independente: continuar auditoria/validação das calculadoras financeiras e integração educativa, sem atribuir tratamento fiscal. Sem alteração de código nesta pesquisa read-only.
|
||
|
||
### Etapa 3/6 — precisão dos testes da calculadora de empréstimos (2026-10-03)
|
||
|
||
- A revisão de `buildLoanSchedule` confirmou que o cálculo já usa aritmética inteira/fixa, separa capital, juros e comissões, trata taxa zero, converte taxas efectivas pela periodicidade, aplica carência de juros e ajusta o último pagamento. Não foi encontrada falha de produção nesta inspecção.
|
||
- Reforcei `tests/frontend/financial-calculators.test.mjs`: a reconciliação de capital e saldo deixa de converter montantes para `Number` e soma cêntimos como `BigInt`; os testes reconciliam pagamentos mais comissão inicial ao total pago, cobrem amortização com taxa não redonda e taxa efectiva anual em periodicidade trimestral.
|
||
- Evidência: `node --test tests/frontend/financial-calculators.test.mjs` passou 12/12; `npm.cmd run check:fix -- tests/frontend/financial-calculators.test.mjs`, `npm.cmd run check -- ...`, `npm.cmd run types:check` e `git diff --check` passaram.
|
||
- Não alterei fórmulas, snapshots, dependências, UI, dados ou integrações. A calculadora permanece educativa e não representa proposta nem concessão de crédito. Validação institucional do modelo financeiro continua pendente; gates fiscais não foram activados.
|
||
|
||
### Etapa 6/7 — limite de previsão de recebimento do reembolso IVA (2026-10-03)
|
||
|
||
- A auditoria do planeador encontrou que o recebimento de IVA previsto podia exceder o valor reconhecido e ainda assim entrar na tesouraria. A validação agora rejeita esse cenário; crédito estimado, pedido e valor reconhecido continuam fora do caixa, e apenas recebimento declarado até ao montante reconhecido entra no mês indicado.
|
||
- Ficheiros: `resources/js/lib/monthly-cashflow.ts` e `tests/frontend/monthly-cashflow.test.mjs`.
|
||
- Evidência: `node --test tests/frontend/monthly-cashflow.test.mjs` passou 6/6; check/formatter dirigidos, `npm.cmd run types:check` e `git diff --check` passaram.
|
||
- Não se calculou elegibilidade, direito a reembolso nem prazo fiscal; é apenas consistência de uma previsão financeira introduzida pelo utilizador. O recebimento continua rotulado como hipótese não garantida. Etapas 6/7 permanecem parciais; gate fiscal inalterado.
|
||
|
||
### Reconciliación del estado principal — 2026-10-03
|
||
|
||
O resumo/matriz inicial deste ledger contém estados e totais históricos que ficaram desactualizados. Para não reescrever ou descartar o histórico, o quadro autoritativo reconciliado passa a ser `docs/investmoz/simulations/current-status-2026-10-03.md`. Ele incorpora a confirmação textual da taxa geral IVA de 16% (sem activar regras), a limitação de acesso aos BR 186/187, a validação de previsões de caixa e os totais de testes mais recentes. Continua a registar o incidente da base QA na porta 5432 e as pendências humanas, financeiras, assistivas e Project/CRM.
|
||
|
||
- Actualização da evidência 2026-10-03: depois das alterações financeiras, a suite `node --test tests/frontend/*.test.mjs` passou 98/98 e `npm.cmd run build` compilou 2.388 módulos. O build emite apenas aviso informativo de `fontaine` opcional. Foi confirmado que todos os documentos/PDFs ligados no quadro reconciliado existem no workspace.
|
||
- Ficheiro de referência actual: `docs/investmoz/simulations/current-status-2026-10-03.md`. Este quadro prevalece para o estado presente; entradas antigas permanecem para auditoria histórica.
|
||
|
||
### Etapa 2/11 — browser audit e foco por teclado no simulador (2026-10-03)
|
||
|
||
- Criei `tools/simulator-a11y-browser.mjs`, smoke test sem dependências de browser automation: liga-se a Edge CDP, abre `/simulador-fiscal`, verifica larguras 390/768/1024/1440, testa os primeiros 12 destinos de foco por Tab e recolhe nomes via DOM e árvore de acessibilidade Chromium. O relatório é agregado e não guarda conteúdo do utilizador.
|
||
- Execução em Edge 154 headless: zero overflow; 12 focos visíveis, nomeados e `:focus-visible`; zero campos/botões/links/AX controls sem nome; zero alertas visíveis; zero excepções JS. `node --check`, `npm.cmd run check:fix -- tools/simulator-a11y-browser.mjs`, `npm.cmd run check -- ...` passaram.
|
||
- Relatório: `docs/investmoz/simulations/simulator-browser-audit-2026-10-03.json`. Servidor Laravel local usou `APP_ENV=testing`, SQLite em memória e session/cache array; os pedidos da API de rascunho não foram validados nem os dados simulados. Servidor e Edge QA foram encerrados; Vite preexistente não foi alterado.
|
||
- Esta prova automatizada não substitui revisão com leitor de ecrã, teclado/dispositivo físico ou utilizador. Etapas 2/11 continuam parciais; nenhuma regra fiscal ou integração externa foi activada.
|
||
|
||
### Actualização do browser audit contra API real em PostgreSQL QA (2026-10-03)
|
||
|
||
- A primeira execução reportou zero APIs porque o browser smoke test não aguardava a resposta; corrigi o sincronismo para só passar depois de receber pelo menos um endpoint público. Esse primeiro ensaio usou SQLite em memória e não é evidência de API.
|
||
- Repeti o percurso sem login contra PostgreSQL 17/PostGIS QA já existente no cluster `%TEMP%\investmoz-stage11-pg-20261003`, `investmoz_test`/`investmoz_test`, `127.0.0.1:55441`. O GET `/api/v1/simulation-drafts/current` respondeu HTTP 200; zero chamadas API falhadas, zero alertas visíveis, zero controlos sem nome, zero overflow e zero excepções JS. Quatro viewports e 12 destinos de Tab continuam aprovados.
|
||
- Nenhuma execução aritmética, escrita de rascunho ou envio de dados foi submetido. O GET de rascunho é leitura; o teste não valida payloads persistidos, autorização de escrita, exportação nem conversão.
|
||
- Actualizei `tools/simulator-a11y-browser.mjs`, `docs/investmoz/simulations/simulator-browser-audit-2026-10-03.json` e o quadro actual. Check/formatter, `node --check` e execução browser passaram. Laravel, Edge QA e PostgreSQL temporários foram encerrados; portas 55441/18082/9224 confirmadas fechadas, serviço preexistente Vite 5173 preservado; a porta 5432 não foi usada.
|
||
- Etapas 2/11 continuam parciais: leitor de ecrã, dispositivo físico, teste manual de percurso, aprovação de produto e demais regressões globais permanecem pendentes.
|
||
|
||
### Etapa 2/11 — cálculo anónimo real no browser e correcção do autosave (2026-10-03)
|
||
|
||
- O browser público enviou um cenário anónimo de teste (base 1000, taxa hipotética 10%, redução hipotética 50%, contexto 2026/INSS) e recebeu 202; polling recebeu 200 e a interface apresentou resultado `50.000…`, aviso fiscal e estado “concluída”, sem alertas ou excepções JavaScript. `tools/simulator-calculation-browser.mjs` e evidência agregada `docs/investmoz/simulations/simulator-calculation-browser-2026-10-03.json`.
|
||
- O teste encontrou que o autosave anónimo enviava `personal_snapshot: []`, mas `required|array` rejeitava o array vazio. `StoreSimulationFormDraftRequest` agora exige campo presente e array; `SimulationFormDraftPrivacyPolicy` mantém o array pessoal anónimo vazio. Regressão em `SimulationFormDraftTest`; a protecção de limpeza entre esquemas reconhece somente a base QA adicional `investmoz_browser_e2e`, porta 55441, host localhost.
|
||
- `simulation-form.tsx` traduz os estados da execução para português. O browser verificou também GET corrente 200 e criação de rascunho 201 sem dados pessoais; o conjunto de testes verificou retoma anónima sem snapshot pessoal.
|
||
- Evidência final: PHPUnit `--filter SimulationFormDraftTest`: 9/9 testes, 67 asserções; frontend Node: 98/98; TypeScript, build Vite de 2.388 módulos, lint/format e `git diff --check` passaram. QA isolado ficou sem registos após a suite `RefreshDatabase`.
|
||
- Incidente de ambiente: execuções iniciais via `php artisan serve` retornaram cálculo concluído, mas não foram encontradas na base QA nomeada. Dado que o `.env` local aponta para `investemoz`/5432, duas escritas podem ter atingido essa base. Não foi consultada nem alterada. UUIDs para revisão pelo responsável: `809071e6-5aaf-4b8e-988e-3647542f06fd`, `731af461-c8c1-4d45-8f14-cf049c51d1f1`. Repetição segura feita apenas com `php -S` directo, variáveis de QA, base `investmoz_browser_e2e`/55441.
|
||
- Pendentes da etapa: revisão manual assistiva/produto. Gates fiscais continuam sem activação.
|
||
|
||
### Etapa 11 — suite PHP integral após correcção do QA de browser (2026-10-03)
|
||
|
||
- A primeira tentativa da suite com base nova falhou 25 testes numa guarda de segurança que requer nomes terminados em `_test`. Renomeei a base descartável e mantive a allowlist exacta, sem relaxar a protecção.
|
||
- Segunda tentativa: `php vendor/bin/phpunit` passou 231/231 testes, 2.288 asserções, 75,566 s em PostgreSQL QA `investmoz_browser_e2e_test`/55441. O ensaio focused `SimulationFormDraftTest` anterior também passou 9/9 (67 asserções).
|
||
|
||
### Revisão master consolidada — 2026-10-03
|
||
|
||
- Criada a matriz `consolidated-review-matrix-2026-10-03.md` com estado inicial, runtime, contratos/CI, conflitos resolvidos, requisitos do prompt master (§1–16), domínios, critérios de aceite, evidência, lacunas, prioridades e continuidade.
|
||
- Baseline nesta execução: frontend 98/98; TypeScript passou; PHPStan passou sem erros; build Vite passou com 2.388 módulos; lint dirigido passou nos dois ficheiros desta tranche. `vp check` continua bloqueado pelo ledger histórico não legível como texto; lint global encontrou cinco ficheiros anteriores a esta tranche. A suite PHPUnit de 231 testes não foi repetida porque PostgreSQL local 5432 está activo e o QA isolado 55441 está parado.
|
||
- Correcção de segurança documental: upload do catálogo passa a `quarantined/internal`, com evento de auditoria correspondente. `resource()` já exige documento público activo; a validação não permite catalogar o novo upload. Teste actualizado para quarentena e rejeição de catalogação; execução do teste depende do QA PostgreSQL isolado.
|
||
- Sem migration: o esquema vigente já aceita os estados `quarantined` e `internal`. Sem alterações à base de dados nesta execução.
|
||
- Pendências críticas: scanner antimalware e revisão documental autorizada antes de qualquer activação; suite PHP em QA isolado; leitura/reconciliação dos DOCX restantes e extração rastreável do relatório PII. As regras fiscais públicas permanecem bloqueadas por fontes/aprovação humana.
|
||
|
||
### Adenda de testes e segurança documental — 2026-10-03
|
||
|
||
- A QA PostgreSQL/PostGIS isolada foi iniciada na porta 55441 e encerrada após os testes. Alvo: `investmoz_browser_e2e_test`; nenhuma operação foi enviada à instância local da porta 5432.
|
||
- `php vendor/bin/phpunit --configuration=phpunit.xml --filter PortalServicesTest --do-not-cache-result`: 5/5 testes, 191 assertions, passou.
|
||
- `php vendor/bin/phpunit --configuration=phpunit.xml --do-not-cache-result`: 231/231 testes, 2.299 assertions, passou em 71,593 s.
|
||
- A contagem anterior registada de 2.288 assertions fica substituída por esta execução posterior; não houve falhas.
|
||
- O upload de documento do portal foi corrigido para quarentena interna. Não há scanner/fluxo autorizado de revisão no produto; não activar ficheiros enviados até existir esse controle.
|
||
|
||
### Revisão estrutural do PII — 2026-10-03
|
||
|
||
- Documento local identificado por SHA-256 `BCBF8EC976100CC5E978AEF54050C3E3E9D959B0D361FA80A788528A8E5049A6`; 2.520 parágrafos, 30 tabelas/353 linhas no corpo.
|
||
- Inventário das 13 tabelas de projectos (11–13, 15–21 e 23–25): 174 linhas preenchidas; 173 títulos normalizados, com uma ocorrência repetida; tabela 19 declara custo em USD/MZN, ambiguidade sem atribuição da moeda por linha.
|
||
- Responsável e estado de execução não são colunas uniformes nessas tabelas; localidades em texto não foram validadas cartograficamente. Nenhuma soma cambial, deduplicação, importação ou publicação realizada.
|
||
- Evidência e passos de staging registrados em `docs/investmoz/pii-extraction-review-2026-10-03.md`. Prontidão PII continua não pronta para importação/publicação até confirmação humana das divergências e das referências.
|
||
|
||
### Revalidação sequencial das etapas financeiras — 2026-10-03
|
||
|
||
- Releitura do anexo original confirma: Etapa 6 abrange investimento/activos, produtos/quantidades/preços, compras/consumo/existências, despesas/pessoal, fontes de financiamento, fundo de maneio, resultados, caixa mensal e défice; separar lucro/liquidez, factura/cobrança, despesa/pagamento, juros/capital, depreciação fiscal/contabilística e moeda FX explícita. A implementação financeira cobre esses grupos nos modelos `business-financial-plan.ts`, `monthly-cashflow.ts` e calculadoras educativas, com testes de reconciliação. A etapa permanece parcial até validação contabilística institucional e cobertura dos riscos não modelados.
|
||
- Etapa 7 mantém matéria colectável indeterminada sem regras aprovadas; a ponte não marca despesas automaticamente como dedutíveis e não converte crédito/pedido IVA em caixa. Revisão fiscal continua bloqueada por fontes oficiais e aprovação especializada.
|
||
- Etapa 8 oferece resultados/exportação CSV locais sem autenticação para simulação aritmética concluída; snapshots e relatórios versionados são conferidos contra o resultado antes de exportar/converter. PDF e revisão assistiva manual continuam pendentes.
|
||
- Etapa 11 foi revalidada nesta tranche: suite PHP 231/231 e 2.299 assertions, incluindo `PortalServicesTest` 5/5 e 191 assertions após pôr uploads em quarentena. PostgreSQL QA isolado `investmoz_browser_e2e_test`/55441 foi encerrado; 5432 local não foi usado.
|
||
- `current-status-2026-10-03.md` actualizado com o total de testes mais recente. Gates humanos/legal continuam abertos; a aprovação técnica dos testes não os substitui.
|
||
|
||
### Etapa 1 — contrato wire v1 tipado e validado — 2026-10-03
|
||
|
||
- Inspecção confirmou separação incompleta entre tipos internos camelCase e JSON público snake_case; o leitor do snapshot aritmético mantinha validação estrutural duplicada.
|
||
- `simulation-contract.ts` define tipos wire explícitos do envelope v1 e type guard de runtime. A validação exige correspondência exacta do decimal legado com `result.value`, preserva zero como valor conhecido, rejeita estados contraditórios e requer entradas em falta para indeterminação.
|
||
- `simulation-form.ts` reutiliza a guarda comum antes da validação específica do resultado aritmético. O `tsconfig` permite import explícito `.ts` para executar a mesma validação com Node e Vite; `allowImportingTsExtensions` é compatível com `noEmit` configurado.
|
||
- OpenAPI `SimulationResultSnapshotV1.indicative_total` aceita `null` para estado indeterminado/não aplicável; respostas calculadas existentes não mudaram e continuam a publicar decimal string.
|
||
- Evidência: testes focados de contrato/formulário 25/25; frontend completo 99/99; `npm.cmd run types:check` passou; `npm.cmd run check` dirigido passou; build Vite compilou 2.388 módulos; OpenAPI parseou e `git diff --check` passou.
|
||
- Limite: os restantes endpoints questionnaire/draft/history/jobs/errors ainda não usam um contrato TS comum validado. A Etapa 1 continua parcial; não foi alterado schema nem persistência.
|
||
|
||
### Etapa 1/11 — envelope da execucao e valores decimais da API (2026-10-03)
|
||
|
||
- `resources/js/lib/simulation-contract.ts` valida as respostas wire da execucao e `resources/js/components/simulation-form.tsx` aplica o guard na criacao, polling e leitura de historico; respostas malformadas e IDs divergentes sao recusados.
|
||
- `docs/investmoz/simulations/openapi.json` agora declara `base`, `rate` e `reduction` como strings decimais, tal como enviados pelo formulario e definido em `data-contracts.md`; adiciona tambem os schemas de criacao/leitura da execucao e liga-os aos endpoints. Limites de taxa continuam validados no servidor; nenhuma escala decimal adicional foi presumida.
|
||
- `tests/frontend/simulation-contract.test.mjs` verifica guards e alinhamento OpenAPI. `node --test tests/frontend/*.test.mjs`: 101/101; `npm.cmd run types:check`: passou; `npm.cmd run check -- ...` dirigido: passou; `npm.cmd run build`: passou, 2.388 modulos. Aviso nao impeditivo de `fontaine` opcional.
|
||
- A Etapa 1 permanece parcial: falta cobrir questionarios, drafts, historico paginado, relatórios, erros e round-trip de persistencia. Gates fiscais permanecem inalterados e bloqueados para ativacao.
|
||
|
||
### Etapa 1/11 — histórico, drafts e schemas das respostas API (2026-10-03)
|
||
|
||
- Foram acrescentados guards TypeScript para histórico paginado e ciclo de vida dos drafts: leitura (incluindo `data: null`), escrita e anexação. O caso aprovado de sessão anónima com `personal_snapshot: []` é explicitamente aceite; snapshots pessoais com conteúdo em array são rejeitados.
|
||
- `simulation-form.tsx` só actualiza estado com respostas válidas; mensagens de erro são extraídas de payloads não confiáveis apenas quando `message` é string.
|
||
- OpenAPI documenta e liga respostas de histórico, questionário, drafts, conversão, relatório e erro, preservando strings decimais no contrato de entrada.
|
||
- Evidência: `node --test tests/frontend/*.test.mjs` passou 102/102; `npm.cmd run types:check` passou; formatter/lint dirigido passou; parser JSON e verificador local resolveram todos os refs OpenAPI; `npm.cmd run build` compilou 2.388 módulos; `git diff --check` passou (avisos prévios de CRLF em documentos fora deste escopo). Aviso informativo de `fontaine` opcional.
|
||
- Etapa 1 continua parcial: falta revisar/testar jobs, o contrato completo de erros, round-trip persistido e respostas de endpoints ainda não consumidos pelo formulário. Gates fiscais mantêm o estado existente.
|
||
|
||
- Adenda: concluído também o schema OpenAPI de `GET /simulations/{id}/jobs`, conferido com a migration SQL e o método controlador; documenta estados, tentativas e `error_code`, sem expor detalhe de excepções. Verificação final repetida: 102/102 frontend, TypeScript, lint dirigido, build com 2.388 módulos, JSON OpenAPI e 60 refs locais válidas. A Etapa 1 continua parcial enquanto faltarem round-trip de persistência, maior cobertura de erros e guards para endpoints não consumidos actualmente.
|
||
|
||
### Etapa 1/11 — guards wire de questionário, relatório, jobs e erros (2026-10-03)
|
||
|
||
- `simulation-contract.ts` inclui agora guards para resposta de questionário publicado, relatório imutável, lista de jobs e payload de erro com `message`/`errors`. O formulário usa o guard de erro antes de mostrar mensagens de resposta; os restantes guards ficam disponíveis para os consumidores desses endpoints.
|
||
- Revalidação completa após as alterações: 103/103 testes frontend; `npm.cmd run types:check`, lint dirigido, `npm.cmd run build` (2.388 módulos), OpenAPI JSON/refs locais e `git diff --check` passaram. Aviso opcional de `fontaine`; avisos CRLF apenas em dois documentos preexistentes fora do escopo.
|
||
- A Etapa 1 segue parcial até round-trip de persistência e integração runtime das respostas para endpoints não consumidos actualmente serem verificados.
|
||
|
||
### Correcção da pendência round-trip e schema PATCH — Etapa 1 (2026-10-03)
|
||
|
||
- Revistos os testes PHP existentes: `SimulationExecutionTest` verifica que o snapshot/API corresponde ao relatório persistido e hashes canónicos; `SimulationFormDraftTest` cobre encriptação, retomada, actualização optimística e conversão. Assim, “round-trip de persistência” não está ausente; a lacuna é execução actual em QA e validação integrada adicional do cliente.
|
||
- Adicionado teste JSON.stringify/parse a todos os guards wire e schema para PATCH de cenário 202 + erros OpenAPI. Suite frontend completa: 104/104; focada de contrato: 11/11; JSON válido e 66 refs locais resolvidos.
|
||
- Não repeti PHP: porta PostgreSQL QA 55441 sem listener. Não usei a base local 5432. Etapa 1 continua parcial até execução integrada do teste PHP em QA e cobertura do restante client/API.
|
||
|
||
### Fecho tecnico da Etapa 1 — contrato wire completo e round-trip QA (2026-10-03)
|
||
|
||
- Todas as rotas de simulacao de `routes/api.php` estao no OpenAPI, com respostas de sucesso tipadas e cada resposta 4xx vinculada a `ApiErrorV1`. Teste percorre o documento e falha se encontrar 4xx sem o schema comum. Entradas base/taxa/reducao correspondem aos JSON strings decimais enviados pelo formulario.
|
||
- Runtime guards aplicam-se a criacao/polling/leitura, historico, drafts e conversao; guards e testes cobrem ainda questionario, relatorio, jobs e erros.
|
||
- Novo round-trip de `GET /simulations/{id}/reports/{reportId}` compara snapshot e hash persistidos com a resposta e rejeita token alheio. Teste de PATCH afirma ETag, versao e parametros decimais actualizados.
|
||
- PHP 8.5.11/PostgreSQL 17 QA: suite completa 231/231 e 2.305 assertions; teste focalizado final `SimulationExecutionTest` 14/14 e 111 assertions. Testes frontend 104/104, contrato focado 11/11, TypeScript/lint dirigidos, Pint e refs OpenAPI passaram.
|
||
- O cluster PostgreSQL QA foi iniciado apenas para estes testes e encerrado; porta 55441 confirmada parada, `5432` preservada. Nenhuma activacao externa ou fiscal ocorreu. Etapa 1 tecnicamente concluida; aceite operacional fica para o gate geral. Prosseguir para a proxima etapa tecnica segura.
|
||
|
||
### Etapa 2 — contrato real da execucao e validação acessivel no browser (2026-10-03)
|
||
|
||
- Corrigido o contrato wire em `resources/js/lib/simulation-contract.ts`: a criacao devolve `202`/`queued` sem `result_snapshot`; o campo pode faltar enquanto a execucao nao concluiu. Quando `status=completed`, continua obrigatorio. Teste de contrato cobre explicitamente o envelope queued sem snapshot e respostas completed malformadas.
|
||
- Browser Edge em PostgreSQL QA isolado confirmou validação acessivel: `aria-invalid=true`, `aria-describedby=error-base` ligado a alerta, foco no primeiro campo e zero POST antes da correcao. A submissao valida recebeu 202 e 12 leituras GET autenticadas 200; a fila nao avancou de `queued`, logo o calculo final permanece por validar neste ambiente.
|
||
- Evidencia registada em `docs/investmoz/simulations/simulator-calculation-browser-2026-10-03.json`. Suites frontend 104/104, TypeScript, lint/format dirigido, build (2.388 modulos), verificacao JS e `git diff --check` passaram. Build reportou somente ausencia do pacote opcional `fontaine`.
|
||
- PostgreSQL QA/55441, Laravel/18082 e Edge/9224 foram encerrados; confirmada apenas a porta 5432 existente, sem acesso ou alteracao.
|
||
- Proxima pendencia independente: diagnosticar configuracao/entrega do worker Laravel no ambiente integrado e repetir a jornada ate `completed`. Etapa 2 segue parcial; nao avanca gate fiscal nem etapa seguinte.
|
||
|
||
### Correcao critica de evidencias QA — 2026-10-03
|
||
|
||
Instrumentacao temporaria dentro do processo HTTP revelou que `artisan serve` usou `investemoz`/5432, nao o banco QA definido no processo pai. Foram enviados varios POSTs anonimos de simulacao e autosave com dados aritmeticos hipoteticos; os UUIDs conhecidos, o total de 13 jobs agregado observado sem atribuicao e os limites de auditoria estao em `docs/investmoz/qa-database-target-incident-2026-10-03.md`. A base nao foi consultada por linhas, alterada directamente nem limpa apos a descoberta; os processos do app/browser foram parados imediatamente. As anteriores declaracoes de isolamento QA para o browser smoke ficam revogadas. A validacao acessivel no browser permanece observada; execucao e persistencia integrada ainda carecem de repeticao segura. Proxima accao: harness cujo proprio worker HTTP force a configuracao QA e verificacao runtime antes de qualquer escrita; nao usar `artisan serve` ate provar propagacao do alvo.
|
||
|
||
### Etapa 2 — jornada completa verificada no router QA fixo (2026-10-03)
|
||
|
||
- Depois do incidente de ambiente, um router PHP em processo passou a forçar `APP_ENV=testing`, `DB_PORT=55442`, `investmoz_browser_e2e_test`, role QA e fila `database`; resposta territorial 200 trouxe marcador de alvo QA. Nao se usou `artisan serve` para as escritas desta repeticao.
|
||
- Edge/CDP com worker: validação vazia acessível e sem POST; cálculo hipotético base 1000 × taxa 10% × (1 − redução 50%) completou em resultado aritmético 50; API 202 queued seguido de GET 200; rascunho anónimo GET 200/POST 201; disclaimer e aviso de privacidade visíveis; zero erros JS e alertas visíveis. Evidência `simulator-calculation-browser-2026-10-03.json`, passed=true, UUID QA `d466c603-46bb-4b7e-ba1c-8bdb704ec735`.
|
||
- O estado da Etapa 2 passa a validado tecnicamente para este fluxo com worker activo, ainda sujeito a leitor de ecrã/dispositivo físico e revisão de produto. O incidente dos requests anteriores em `investemoz`/5432 continua aberto para reconciliação administrativa, sem acesso posterior à base nem remoção de dados.
|
||
|
||
### Competências — hierarquia territorial validada no servidor (2026-10-03)
|
||
|
||
- O cadastro educativo aceitava `geo_location_id` de qualquer tipo territorial existente, embora a UI ofereça níveis administrativos de província a localidade. A regra agora restringe o tipo no servidor e exclui registos eliminados; um teste envia uma entidade `country` e exige erro no campo.
|
||
- `EducationTest` em PHP 8.5.11/PostgreSQL QA 17, DB `investmoz_browser_e2e_test`, porta 55442, sem configuração PHPUnit padrão: 8/8 testes, 207 assertions; transacções por caso com rollback; Pint dirigido passou. Não houve reset/migration nem acesso à base 5432.
|
||
- D-06 melhora, mas mantém estado parcial enquanto faltarem validação especializada da correspondência oferta/procura, revisão de fontes e aceite assistivo/manual.
|
||
|
||
### CRM — consentimento canonico na conversao de interesse (2026-10-03)
|
||
|
||
- `ConvertInterestToLead` agora exige, dentro da transaccao e apos bloquear o pedido, consentimento canonico `respond_to_interest` correspondente ao pedido, concedido e vigente, nao revogado nem apagado logicamente. A verificacao ocorre tambem antes de devolver lead existente, impedindo replay apos retirada do consentimento.
|
||
- `CrmIntakeTest` cria o consentimento canonico nos fixtures e inclui caso de revogacao, verificando que nenhum lead, investidor, contacto ou tarefa e criado.
|
||
- PHP 8.5.11 / PostgreSQL 17 descartavel em 55442: `CrmIntakeTest` 6/6, 47 assertions. Pint dirigido, `php -l` nos dois ficheiros e `git diff --check` passaram. A role superuser existiu apenas no cluster QA temporario para instalar PostGIS; cluster parado apos o teste. Porta 5432 nao foi usada.
|
||
- CRM segue parcial: este teste nao cobre o percurso real de retirada na UI nem politica de retencao; reconciliacao do incidente de dados operacionais descrito no relatorio QA continua com o responsavel da base.
|
||
|
||
- Adenda CRM: o mesmo teste agora verifica tambem que consentimento apagado logicamente nao autoriza conversao. Reexecucao limpa em novo cluster descartavel: `CrmIntakeTest` 6/6, 50 assertions; Pint dirigido e `git diff --check` passaram. Cluster parado, sem listener QA em 55442.
|
||
|
||
### CRM — revogacao interna do consentimento de contacto (2026-10-03)
|
||
|
||
- A pagina interna do pedido agora expoe accao especifica para revogar `respond_to_interest`, separada da permissao de partilha com o proponente. O utilizador de gestao regista o motivo; a transaccao bloqueia o pedido e o consentimento, cifra a justificacao, grava a transicao e emite outbox sem email. Consentimento ja revogado/inactivo nao cria evento duplicado.
|
||
- `PortalManagementTest` verifica leitura da finalidade vigente e a revogacao/outbox; `CrmIntakeTest` cobre que consentimento revogado ou apagado logicamente bloqueia conversao e replay do CRM.
|
||
- PHP 8.5.11 / PostgreSQL 17 em cluster QA descartavel: `PortalManagementTest` + `CrmIntakeTest` passaram 16/16, 230 assertions. Pint dirigido, PHP lint e `npm.cmd run types:check` passaram. Cluster encerrado; 55442 sem listener e 5432 nao usada.
|
||
- A revogacao interna nao substitui canal publico do titular nem define retencao/eliminação; esses requisitos de privacidade continuam para validacao. Suite completa e aceitacao manual da interface nao foram executadas nesta tranche.
|
||
|
||
- Revalidacao final de CRM: a suite focada foi ampliada para incluir negativa de utilizador sem permissao e repeticao idempotente sem transicao/evento duplicados. Resultado final: 16/16 testes, 234 assertions; Pint, TypeScript e build Vite (2.388 modulos) passaram. Aviso de build: pacote opcional `fontaine` ausente. QA em cluster PostgreSQL 17 descartavel foi encerrado; listener 5432 e preexistente e nao foi usado.
|
||
|
||
- Adenda de integracao CRM: o teste agora percorre revogacao pela rota de gestao seguida de tentativa real de conversao; a conversao e rejeitada. Tambem verifica que utilizador sem papel nao revoga e que repeticao nao duplica outbox/transicao. Reexecucao final: 16/16 testes, 237 assertions. `npm run build` e TypeScript passaram; aviso opcional `fontaine`. O verificador Vite+ de formatacao considera este ficheiro legado fora do formato global; nao foi reformatado inteiro para evitar diff mecanico alheio ao escopo.
|
||
|
||
### Regressao global apos CRM — 2026-10-03
|
||
|
||
- A suite PHP global foi executada em cluster PostgreSQL 17 novo e isolado na porta 55441. O harness criou a base `investmoz_test`, aplicou todas as migrations antes da suite (dependencia de `AiGatewayTest`) e usou PHP 8.5.11. Resultado final: 233/233 testes, 2.345 assertions; zero falhas/erros.
|
||
- Suite frontend: 104/104. TypeScript, Pint dirigido, PHP lint, build Vite (2.388 modulos) e `git diff --check` passaram. Build emite aviso nao bloqueante do pacote opcional `fontaine`.
|
||
- Uma tentativa preliminar em DB vazio sem migrations terminou com 8 testes AI falhados por `ai_controls` inexistente; corrigido apenas o setup de QA, sem alterar testes ou codigo por causa desse resultado. A repeticao completa acima e a evidência final.
|
||
- Cluster encerrado e porta 55441 confirmada sem listener; a base local na porta 5432 nao foi consultada nem alterada. Permanecem pendentes: reconciliacao administrativa do incidente QA e gates humanos/legal/privacidade/manual descritos no estado actual.
|
||
|
||
### Gate documental — scanner antimalware indisponivel no ambiente local (2026-10-03)
|
||
|
||
A verificacao do ambiente nao encontrou os executaveis `clamscan`, `clamdscan` ou `clamd`, nem servico ClamAV instalado. Nao instalei nem activei scanner externo; os uploads continuam em quarentena interna e a publicacao de ficheiros novos permanece bloqueada. Proxima tarefa independente do plano: continuar a lacuna de localizacoes multipla/estruturadas no formulario privado; nao fabricar coordenadas nem publicar registos.
|
||
|
||
### Localizações administrativas múltiplas — 2026-10-03
|
||
|
||
- O rascunho privado agora admite 2–20 percursos administrativos, guardados em `payload.locations_json` dentro do payload já cifrado. O cliente limpa selecções descendentes ao mudar um nível; o servidor valida UUID, hierarquia na referência pública, mínimo/máximo e percursos repetidos ou sobrepostos. Não são recolhidas nem inventadas coordenadas.
|
||
- A resposta de leitura/gravação resolve os nomes dos percursos exclusivamente a partir da referência territorial pública. O resumo mostra os nomes depois de guardar. `wizard_version=2` consta do contrato OpenAPI; a rota legada conserva validação própria.
|
||
- Ficheiros desta tranche: `BusinessFormSchema.php`, `InvestmentGeography.php`, `ExistingBusinessController.php`, `business-locations.ts`, `business-wizard.tsx`, `business-types.ts`, `existing-business-openapi.mjs`, `ExistingBusinessWizardTest.php` e `business-locations.test.mjs`.
|
||
- Evidência: PHP 8.5.11 e PostgreSQL 17 descartável na porta 55441, migrations aplicadas apenas na base temporária; `ExistingBusinessWizardTest` 3/3, 49 assertions; testes frontend da localização 3/3; TypeScript, Pint dirigido, PHP lint e `git diff --check` passaram. O listener preexistente em 5432 não foi utilizado. Cluster parado; os ficheiros de dados QA permanecem no directório temporário `%TEMP%\investmoz-stage-multiloc` porque a limpeza automática foi bloqueada pelo executor.
|
||
- Sem migration nem alteração de esquema persistente. Rollback: reverter os trechos acima e remover os dois testes/helpers novos; não há dados existentes a migrar. Permanecem pendentes mapa/coordenadas, relação territorial canónica e associação a parques/zonas; esta entrega não autoriza publicação de oportunidade.
|
||
|
||
### Dados territoriais — pesquisa tolerante a acentos (2026-10-03)
|
||
|
||
- `GET /api/v1/investment/territory-options` agora normaliza o termo de pesquisa (`Str::ascii`) e compara nomes com `translate(lower(name), ...)`, além de manter correspondência por código e código de origem. Não altera nem translitera os nomes guardados, não instala extensão e mantém o escopo de território público e dependência hierárquica.
|
||
- `ExistingBusinessWizardTest`: 4/4 testes, 55 assertions no PostgreSQL 17 descartável, PHP 8.5.11/porta 55441; inclui pesquisas `maputo`, `provincia` e `Mapúto` contra `Província de Mapúto`. PHP lint, Pint dirigido, TypeScript, três testes de localização frontend e diff check passaram. Build Vite também passou nesta continuação anterior (2.389 módulos); aviso não bloqueante da dependência opcional `fontaine`.
|
||
- O cluster QA está parado. Porta 5432 permaneceu intocada. As limitações de cobertura oficial/importação de dados territoriais, reconciliação e aproximação sem fusão automática continuam. D-01 melhora, mas permanece parcial.
|
||
|
||
### Catálogo, lista e mapa — reconciliação das contagens (2026-10-03)
|
||
|
||
- A auditoria confirmou que catálogo web, pesquisa API e mapa derivam o conjunto base de `InvestmentCatalogue::query()` com os mesmos filtros. A lista não esconde oportunidades sem ponto: elas aparecem em `unlocated` no mapa, e `matched_count` inclui georreferenciadas e não georreferenciadas. O limite de 1.000 registos é explícito por `truncated`.
|
||
- Reforcei `InvestmentTerritoryTest` para comparar IDs e totais na página Inertia, endpoint de pesquisa e endpoint de mapa em três estados: oportunidade publicada sem coordenadas; coordenadas públicas confirmadas; oportunidade retirada. Resultado: 9/9 testes, 138 assertions, PHP 8.5.11/PostgreSQL 17 QA isolado, porta 55441; Pint e PHP lint passaram. Sem alteração funcional/dados de produção.
|
||
- A verificação confirma consistência para o fluxo amostrado, mas não prova exaustivamente filtros combinados, paginação acima de 1.000 ou aceitação visual assistiva. C-01 continua parcial até essas verificações; nenhuma coordenada foi fabricada. QA foi encerrado e a porta 5432 não foi consultada.
|
||
|
||
## Adenda — extracção de revisão não importável (2026-10-03)
|
||
|
||
O DOCX de origem voltou a ser localizado no caminho registado. O SHA-256 actual (`BCBF8EC976100CC5E978AEF54050C3E3E9D959B0D361FA80A788528A8E5049A6`) coincide com a proveniência acima. Foi criada `docs/investmoz/source-staging/pii-26-30-review-only.csv` com 174 linhas, preservando índice de tabela no XML, linha, legenda da tabela, chave, título, tipo, relação literal, localização, custo literal, cabeçalho literal da moeda e horizonte. Cada linha tem estado `review_only_not_importable`; nenhum registo canónico ou anúncio foi criado.
|
||
|
||
A extração confirma que “Terminal de Contentores – Porto de Nacala” ocorre em T16/L4 (`A07 - C02`, `110,000,000`) e T17/L4 (`A08 - C02`, `300.000.000`), ambos sob cabeçalho USD. São identificadores/valores distintos: manter ambas as linhas para reconciliação, sem deduplicar ou escolher um valor. As sete linhas da tabela XML 19 conservam o cabeçalho `Custo (USD/ MZN)` e ficam marcadas `currency_ambiguous_mixed_header`. O texto inclui “Taxa de câmbio: 1 USD = 64,00 MZN” imediatamente antes e depois desta tabela, mas não estabelece a moeda de cada linha, a aplicação dessa taxa às estimativas, a data/base da taxa nem a autoridade da conversão; por isso, nenhum valor foi convertido.
|
||
|
||
As colunas uniformes das 13 tabelas não identificam pessoa/entidade responsável nem fase de execução; no CSV ficam vazias, sem inferência. Localizações e relações permanecem literais, não validadas. Validação do artefacto: 174/174 linhas, 174 referências tabela/linha únicas, 7 linhas em T19 sinalizadas e 2 linhas do título repetido sinalizadas. Não houve escrita em base de dados nem alteração do DOCX. Gate V-01/D-02 continua parcial e bloqueado para importação/publicação até reconciliação pelo responsável do documento e validação dos topónimos, responsáveis, estados e moeda.
|
||
|
||
Rollback deste artefacto derivado: remover apenas `pii-26-30-review-only.csv` e esta adenda; o original e dados de aplicação permanecem intactos.
|
||
|
||
### Cadastro administrativo de corredores — 2026-10-03
|
||
|
||
- A auditoria confirmou que `development_corridors` e o modelo existiam, mas não havia CRUD na área de gestão: as rotas genéricas só aceitavam `projects` e `clusters`. Acrescentei `/management/corridors` com pesquisa/paginação e formulário privado para código, nome, estado e descrição, reutilizando o selector territorial existente na criação. Os estados aceites são os já definidos pela tabela (`proposed`, `active`, `closed`); não foi criada regra nem conteúdo oficial.
|
||
- O registo fica com classificação `internal`; o estado `active` é apenas estado operacional do corredor e não cria publicação. Não houve migration. Autorização, criação, leitura, edição e estado foram verificados em `InvestmentStructureTest`: 5/5 testes, 68 assertions, PostgreSQL 17 QA isolado na porta 55441, PHP 8.5.11. PHPStan: 0 erros; Pint, PHP lint, TypeScript, build Vite (2.389 módulos) e `git diff --check` passaram. Build assinala apenas a dependência opcional `fontaine` ausente. Cluster encerrado; 5432 não utilizada.
|
||
- D-02 permanece parcial: esta tranche só acrescenta CRUD básico de corredor. Associações corredor–projecto/cluster com fonte, evidência, vigência e revisão independente, catálogo de parques/zona, relações com PII e validação oficial dos dados ainda não estão concluídos. Nenhum corredor real foi inserido.
|
||
- Rollback: reverter `routes/web.php`, controller, tipos/páginas de estruturas, ligação no menu e o teste. Não há alteração de esquema ou dados a reverter.
|
||
|
||
### Publicação da carteira — aprovação separada da importação (2026-10-03)
|
||
|
||
- Corrigido um bypass verificado: `portfolio:import --approval=<texto>` aceitava qualquer texto arbitrário e publicava até 29 dossiers sem autenticar o proprietário nem confirmar revisão. O comando agora só corre o seeder idempotente e deixa os dossiers em rascunho privado. O parâmetro `--approval` deixou de existir; chamada com esse parâmetro foi executada e terminou com erro `The "--approval" option does not exist.`
|
||
- Fechada também a auto-publicação pela rota de gestão: um dossier sem editor atribuído não pode ser publicado (422); o editor não pode rever/publicar a própria edição (403); outro gestor tem de rever. O fluxo mantém versão optimista, evidência e auditoria. As fichas já publicadas/históricas não foram alteradas.
|
||
- `InvestmentPortfolioTest` + `InvestmentUnificationTest`: 15/15 testes, 224 assertions, incluindo importação repetida, ausência de publicação automática, preservação de edições, editor distinto e filtros com fixtures sintéticas explicitamente publicadas. PHPStan 0 erros; Pint e PHP lint dirigidos passaram. Testes em PostgreSQL 17 isolado, PHP 8.5.11/porta 55441. Não foi usada a base 5432.
|
||
- Sem migration. Rollback de código reabre os caminhos de auto-publicação; preservar o controlo actual salvo decisão expressa de política. O histórico documental de 26/09 sobre a autorização inicial foi mantido como histórico, não como instrução de execução actual.
|
||
|
||
### D-02 - Governed structure relations (2026-10-03)
|
||
|
||
- Added an incremental migration for `cluster_projects`, `corridor_projects` and `corridor_clusters`: association type, source/evidence references, validity dates, pending/validated/revoked status, editor and validator identities. Existing and imported relations receive the default `pending`; no old row is promoted to validated.
|
||
- Added manager endpoints to submit and independently validate/revoke each supported relation type. Submission requires source, evidence and validity start; reviewer must differ from editor; optimistic version check, transaction, audit event and row lock are used.
|
||
- The cluster-project management form now captures those fields and exposes pending relation validation to another manager. The existing cluster route also enforces the metadata and resets edits to pending. The public portfolio only traverses validated relations whose validity includes today; the existing imported mappings are therefore not public associations until evidence review.
|
||
- Added `InvestmentStructureTest` and updated the public origin-context test. PHP 8.5.11, QA PostgreSQL 17 on 55441: `InvestmentStructureTest` + `InvestmentPortfolioTest` passed 13/13, 217 assertions. Pint passed; PHPStan targeted controllers 0 errors; TypeScript passed; Vite build passed (2,389 modules); route:list confirmed the two governance routes; PHP lint and diff check passed. Build emitted only the existing optional fontaine warning. First QA attempts exposed that the temporary cluster role in phpunit.xml did not exist; tests were rerun successfully as the existing postgres cluster role. No connection to port 5432 was made.
|
||
- Rollback migration refuses when any relation contains non-default governance metadata, preserving submitted/reviewed evidence. A rollback with default-only rows removes only the added columns. Database migration has not been run against the local application database; feature tests used the isolated QA cluster.
|
||
- Remaining D-02 gaps: corridor-project and corridor-cluster submission endpoints are present but do not yet have equivalent editor forms; no imported relation has a validated official source; parks, ZEE/ZFI and PII reconciliation remain pending. D-02 remains partial; preserve public visibility gate.
|
||
|
||
### Etapa 1 - validacao de datas e estado dos relatorios (2026-10-03)
|
||
|
||
- Revalidacao do contrato runtime encontrou que `Date.parse` normaliza datas impossiveis (`2026-02-31`) e que o guard de relatorios aceitava `status=ready` sem snapshot/hash, ou estados pendentes com payload de relatorio. O parser agora verifica calendario gregoriano (incluindo ano bissexto) e exige snapshot + SHA-256 para `ready`; `queued`/`failed` exigem ambos nulos.
|
||
- Testes acrescentam data impossivel, dia bissexto e combinacoes de estado/snapshot inconsistentes. `node --test tests/frontend/simulation-contract.test.mjs`: 11/11; suite frontend completa: 107/107; `npm.cmd run types:check` passou; `npm.cmd run check:fix -- resources/js/lib/simulation-contract.ts` e `npm.cmd run check -- resources/js/lib/simulation-contract.ts` passaram.
|
||
- O contrato ainda nao esta aplicado de modo uniforme aos consumidores de questionnaire, reports e jobs nem ha round-trip de todos os endpoints; Etapa 1 permanece parcial. Sem alteracao de API, dados, migrations, motor fiscal ou configuracao externa.
|
||
|
||
### Etapa 1 - round-trip com respostas reais da API (2026-10-03)
|
||
|
||
- Os testes de integracao agora verificam os campos do questionario publicado, todos os campos nullable/temporais do job pendente e concluido, o contrato do relatorio ready, o historico paginado e a explicacao do resultado. Foi corrigida em `RunSimulation` uma mensagem de resultado cuja codificacao aparecia como texto corrompido; a mensagem continua a dizer explicitamente que nao e conclusao fiscal.
|
||
- PHP 8.5.11 + PostgreSQL 17 isolado na porta 55441: `SimulationExecutionTest`, `ApiContractTest` e `SimulationFormDraftTest` passaram 26/26, 263 assertions, repetidos depois da remocao de um import sem uso. Pint dirigido passou, PHPStan de `RunSimulation` passou sem erros, PHP lint passou. Cluster QA parado; porta 5432 nao utilizada.
|
||
- Isto acrescenta evidencia de respostas reais alem dos guards TypeScript e JSON round-trip sintetico. Etapa 1 continua parcial: falta aplicar os guards aos consumidores que venham a ler questionario/relatorio/jobs, cobrir erros por endpoint e efectuar round-trip completo de conversao e persistencia. O formulario actual continua a usar o percurso local existente e nenhum motor/regra fiscal foi activado.
|
||
|
||
### Etapa 2 - tratamento resiliente de respostas da API (2026-10-03)
|
||
|
||
- O formulario publico agora le corpos JSON de forma tolerante a respostas vazias, HTML ou malformadas e usa o contrato `ApiErrorV1` para apresentar erros estruturados sem expor excecoes do parser. A carga do catalogo tambem valida o envelope e descarta opcoes incompletas.
|
||
- Adicionados `resources/js/lib/simulation-api.ts` e `tests/frontend/simulation-api.test.mjs`; o componente afectado e `resources/js/components/simulation-form.tsx`.
|
||
- Evidencia: suite frontend `node --test tests/frontend/*.test.mjs` (via lista de ficheiros PowerShell): 109/109; TypeScript (`npm.cmd run types:check`) passou; lint/format (`npm.cmd run check` nos 3 ficheiros) passou. Nao foi usada base de dados nem servico externo.
|
||
- Etapa 2 permanece parcial: estes testes cobrem o parser e o contrato das mensagens, mas nao substituem testes de browser para todos os estados de falha e de rede. Proxima tarefa independente: auditar e cobrir visualmente o formulario para carregamento, catalogos vazios/indisponiveis, falha de submissao e falha de polling; manter as regras fiscais pendentes/indeterminadas.
|
||
|
||
### Etapa 2 - falha ao consultar estado da execucao (2026-10-03)
|
||
|
||
- A leitura do fluxo encontrou que um calculo aceite (HTTP 202) seguido por polling nao-2xx deixava apenas o estado pendente, sem explicar que a verificacao do estado falhou. O formulario agora mostra mensagem que preserva a distincao entre submissao aceite e estado ainda nao confirmado; se a API devolver `ApiErrorV1`, usa a mensagem validada.
|
||
- `simulation-api.ts` e `simulation-form.tsx` foram actualizados e foi adicionado teste de mensagem para erro estruturado e resposta sem corpo. Suite frontend: 110/110; TypeScript, lint/format e build passaram (2.390 modulos). O build continua a emitir apenas o aviso de dependencia opcional `fontaine` ausente.
|
||
- Sem browser E2E nesta tranche: os registos anteriores provam somente caminho feliz/responsivo, e nao cobrem falha injectada de polling. Ferramentas locais CDP e aplicacao isolada nao estao activas; nao iniciei servicos. Etapa 2 segue parcial ate validação browser dos estados de falha.
|
||
|
||
- Adenda da auditoria de catalogos: o combobox apresentava simultaneamente erro de carregamento e estado vazio, e nao oferecia nova tentativa. O erro agora substitui a mensagem de lista vazia e disponibiliza uma repeticao real da consulta remota; a lista vazia genuina continua distinta. Suite frontend permaneceu 110/110; TypeScript, lint/format dirigido e build (2.390 modulos) passaram. Continua pendente E2E com resposta remota injectada e revisao assistiva manual.
|
||
|
||
- Adenda de verificacao do catalogo: a normalizacao do envelope de opcoes passou para funcao pura partilhada e agora distingue `data: []` (lista vazia valida), elementos malformados (ignorados) e envelope invalido (erro). `simulation-api.test.mjs` cobre os tres casos. Suite frontend: 111/111; TypeScript, lint/format dirigido e `git diff --check` passaram. Nao foi possivel executar browser E2E: nao ha Edge CDP, Laravel QA ou PostgreSQL isolado activos; a unica porta PostgreSQL em escuta e 5432 e nao foi usada.
|
||
- Build repetido apos a extracao do parser do catalogo: passou, 2.390 modulos; apenas aviso do pacote opcional `fontaine`. A repeticao E2E continua suspensa ate recriar alvo PostgreSQL descartavel e router por-pedido que fixe/identifique o alvo; nao ligar o ensaio a porta 5432, conforme incidente QA documentado.
|
||
|
||
### Etapa 2 - verificacao E2E de falhas de API (2026-10-03)
|
||
|
||
- O browser Edge headless abriu a pagina publica real `/simulador-fiscal` servida por PHP 8.5.11 e confirmou o marcador do alvo QA PostgreSQL isolado `investmoz_browser_e2e_test:55443`. O router temporario foi corrigido para servir assets compilados de `public/`; `resources/js/app.tsx` recebeu resolver explicito de paginas Inertia para montar a pagina no bootstrap real.
|
||
- O teste `tools/simulator-api-errors-browser.mjs` injectou catalogo HTML/502, repeticao do catalogo com sucesso sintetico, calculo 202 e polling 503. Confirmou estado de erro sem falso estado vazio e botao de nova tentativa, aviso de polling e estado pendente. Leituras reais limitaram-se a GET `/api/v1/simulation-drafts/current` (200); criacao de simulacao, polling e escritas de rascunho foram interceptados no browser. Sem excecoes JS ou erros de consola. Relatorio: `docs/investmoz/simulations/simulator-api-errors-browser-2026-10-03.json`.
|
||
- Comando executado: `node tools/simulator-api-errors-browser.mjs http://127.0.0.1:18088/simulador-fiscal docs/investmoz/simulations/simulator-api-errors-browser-2026-10-03.json investmoz_browser_e2e_test:55443`; resultado `passed: true`. QA isolado mostrou 0 simulacoes e 4 rascunhos sinteticos antes e depois da execucao aprovada, sem aumento. Um probe exploratorio anterior, antes de interceptar autosave, criou um rascunho sintetico adicional apenas neste banco descartavel; nenhum registo contem dados reais, nenhum calculo foi persistido e a instancia foi encerrada e removida. A porta local 5432 nao foi usada.
|
||
- Verificacoes finais: suite frontend 111/111; `npm.cmd run types:check`; lint/format dirigido; build Vite (2.390 modulos, com aviso apenas do pacote opcional `fontaine`); `node --check tools/simulator-api-errors-browser.mjs`; `git diff --check`. Tudo passou; o diff check reportou somente avisos de normalizacao CRLF em dois documentos pre-existentes.
|
||
- Etapa 2 continua parcial: E2E cobre estes estados controlados, nao todas as condicoes de rede, navegadores, acessibilidade manual nem API fiscal real. O resultado e uma simulacao resiliente a falhas de transporte, nao validacao de regras fiscais nem autorizacao de publicacao.
|
||
- Rollback: reverter o resolver em `resources/js/app.tsx` e remover o teste de browser/relatorio se nao forem desejados; reverter as melhorias do formulario/API conforme o diff. Nao ha migration nem alteracao de dados persistente. Servicos, cluster e perfil temporarios de QA foram encerrados e removidos.
|
||
|
||
### Etapa 3 - reconciliação de cronogramas de crédito (2026-10-03)
|
||
|
||
- Reforcei `tests/frontend/financial-calculators.test.mjs` com uma matriz determinística para os seis intervalos permitidos (1, 2, 3, 4, 6 e 12 meses), taxas nominais e efectivas, taxa zero/positiva e carência. Em cada cenário, o teste exige soma do capital em cêntimos, saldo final zero, saldo não negativo, identidade abertura-capital-fecho e reconciliação entre prestações, comissão inicial, juros e total pago.
|
||
- Verificações executadas nesta tranche: `node --test tests/frontend/financial-calculators.test.mjs` (13/13); `npm.cmd run check -- tests/frontend/financial-calculators.test.mjs` (formatação e lint passaram); `git diff --check` passou, com avisos CRLF em dois documentos preexistentes não relacionados.
|
||
- Etapa 3 continua parcial: esta matriz valida aritmética dos cenários de crédito implementados, mas não valida propostas de credores, orçamento pessoal completo nem aconselhamento financeiro. Nenhuma regra fiscal foi usada ou activada.
|
||
|
||
### Etapa 3 - isolamento de erros por calculadora (2026-10-03)
|
||
|
||
- A revisão funcional encontrou que uma margem inválida fazia o bloco `try` abortar também o empréstimo, financiamento e orçamento. `calculateFinancialTools` agora executa cada indicador de forma independente; o formulário identifica cada erro, mantém os outros valores visíveis e impede exportação CSV enquanto qualquer componente estiver inválida.
|
||
- Ficheiros: `resources/js/lib/financial-calculators.ts`, `resources/js/components/simulation-financial-tools.tsx`, `tests/frontend/financial-calculators.test.mjs`. O teste regressivo confirma que margem inválida não esconde um empréstimo válido, um défice de financiamento nem um défice operacional.
|
||
- Evidência final: `node --test tests/frontend/financial-calculators.test.mjs` 14/14; `npm.cmd run check:fix -- resources/js/lib/financial-calculators.ts`; `npm.cmd run check -- resources/js/lib/financial-calculators.ts resources/js/components/simulation-financial-tools.tsx tests/frontend/financial-calculators.test.mjs`; `npm.cmd run types:check`; `npm.cmd run build` (2.390 módulos); `git diff --check`. Passaram. O build reporta somente o aviso da dependência opcional `fontaine`; o diff check reporta avisos CRLF em dois documentos preexistentes alheios à tranche.
|
||
- Etapa 3: critérios técnicos do escopo implementado estão verificados por testes independentes, pressupostos visíveis e tratamento de zero, défice e denominador inválido. A calculadora continua educativa e não contém ofertas de credores nem uma ferramenta completa de orçamento pessoal; isso não valida aconselhamento nem produtos financeiros.
|
||
|
||
### Registo de autorização do utilizador (2026-10-03)
|
||
|
||
O utilizador instruiu que validações e autorizações pendentes sejam consideradas autorizadas/válidas para prosseguir. Aplica-se como autorização do proprietário do projecto para continuar as tarefas técnicas e decisões internas reversíveis, sem nova confirmação rotineira. Não representa prova de conteúdo de diplomas, parecer de Fiscalista, validação de regulador/credor, execução de testes que não ocorreram ou aprovação por terceiros. Fontes e regras fiscais sem texto oficial verificável continuam sem cálculo/publicação; publicação de produção e activações externas continuam fora do âmbito autorizado pela especificação consolidada.
|
||
|
||
- Regressão frontend completa após a correcção: `node --test` sobre todos os `tests/frontend/*.test.mjs` passou 113/113.
|
||
|
||
### Revalidação das Etapas 6–7 — plano financeiro e ponte contabilístico-fiscal (2026-10-03)
|
||
|
||
- Revistos `business-financial-plan.ts`, `financial-fiscal-bridge.ts`, `monthly-cashflow.ts` e os testes associados. Os percursos exercitados distinguem receita/facturação de cobranças, despesa de pagamento, inventário de compras/recepção, juros de reembolso de capital, e crédito/pedido/reconhecimento de IVA de recebimento previsto. O cenário base/favorável/desfavorável usa pressupostos declarados e não cria valores fiscais.
|
||
- `node --test tests/frontend/business-financial-plan.test.mjs tests/frontend/financial-fiscal-bridge.test.mjs tests/frontend/monthly-cashflow.test.mjs`: 43/43 passaram. Esta revisão não encontrou defeito aritmético reproduzível nesses percursos; não alterou código destas etapas.
|
||
- A instrução do utilizador para considerar validações pendentes como autorizadas é registada como aceitação do proprietário do projecto para prosseguir e aceitar decisões internas do modelo. Não é certificação contabilística profissional nem validação por entidade externa. A ponte continua com matéria colectável explicitamente indeterminada, sem parâmetros fiscais aprovados no motor.
|
||
- As Etapas 6–7 permanecem parcialmente prontas para produto: incumprimento/fornecedores partilhados e validação operacional especializada não foram demonstrados por esta suíte; sem regra fiscal aprovada, a ponte não produz imposto nem aconselhamento.
|
||
|
||
### Fecho tecnico da Etapa 8 — resultados e exportacao (2026-10-03)
|
||
|
||
- Reconcilei o ecrã com a exportação CSV versionada: ambos lêem o mesmo snapshot aritmético concluído; o CSV recusa divergência entre `result.value` e `indicative_total`, versão de cenário incompatível ou relatório pronto cujo snapshot/hash não corresponde. O leitor do ecrã também recusa envelopes inconsistentes. O CSV não inclui identidade nem contactos.
|
||
- Evidências reexecutadas: `node --test tests/frontend/simulation-form.test.mjs tests/frontend/simulation-contract.test.mjs tests/frontend/simulation-api.test.mjs`: 34/34; o relatório browser da execução anónima confirma cálculo concluído, aviso fiscal visível e exportação só de aritmética genérica. Nenhuma taxa legal foi activada.
|
||
- A Etapa 8 fica tecnicamente concluída para a exportação CSV prevista no anexo: modo público, pressupostos/fórmula/versões/limitações, snapshot reprodutível e reconciliação estão cobertos. O anexo não exige PDF nem assinatura digital; esses itens não são gates desta etapa. Leitor de ecrã/dispositivo físico continuam sem ensaio nesta sessão e pertencem à validação de acessibilidade da Etapa 2/11.
|
||
- A autorização do proprietário registada nesta data permite considerar aceite o gate interno de produto; não altera a evidência técnica acima nem é aprovação fiscal, legal ou de terceiros.
|
||
|
||
### Revalidação da Etapa 9 — conversão para rascunho (2026-10-03)
|
||
|
||
- Inspecção actual confirmou conversão apenas após consentimento explícito e finalidade de investimento; o servidor obtém a execução e o relatório pela identidade/token, exige estado concluído e hash/snapshot canónico, verifica o âmbito organizacional, exige `If-Match`, bloqueia concorrência em transacção, cifra o snapshot, regista a auditoria e torna replay da mesma origem idempotente. O cliente não pode forjar `simulation_sources`; consentimento retirado remove a cópia na actualização do rascunho.
|
||
- Evidência de integração já registada no repositório: `SimulationFormDraftTest` 9/9, 67 asserções no PostgreSQL/PostGIS isolado; suite PHP global posterior 231/231. Nesta retoma foram reexecutados `node --test tests/frontend/simulation-draft-conversion-openapi.test.mjs tests/frontend/simulation-form.test.mjs`: 20/20. Nenhum teste desta retoma contactou base de dados.
|
||
- A conversão consentida para o rascunho do formulário integrado cumpre o critério do anexo; não cria/submete automaticamente um projecto/lead CRM e não certifica a oportunidade. A conexão com processos reais de CRM permanece fora desta operação técnica e requer fluxo institucional separado.
|
||
- Estado proposto da Etapa 9: concluída tecnicamente para histórico/rascunho/conversão sob consentimento; a activação pública do motor fiscal e a entrega global continuam bloqueadas por suas próprias condições. A autorização do proprietário regista aceitação interna, sem criar prova fiscal, legal ou de terceiros.
|
||
|
||
### Etapa 11 actual — verificação global executada em QA isolado (2026-10-03)
|
||
|
||
- Resolvi uma falha real do teste de auditoria de regras: o teste consultava eventos sem definir o contexto exigido pela policy RLS e interpretava a lista oculta como ausência de eventos. Agora a consulta de verificação executa com actor/governance context dentro de transacção. A trilha hash-chain e a imutabilidade continuam testadas.
|
||
- A primeira suite completa identificou, além disso, três falhas de setup nos testes que criam e assumem `simulation_rls_test`; o papel restrito de QA não podia criar/conceder papéis no PostgreSQL 17. Após a correção do teste de contexto RLS, o subconjunto `SimulationTaxRuleGovernanceTest|SimulationExecutionTest` passou 18/18 (213 assertions), depois de habilitar os privilégios necessários apenas no cluster descartável e executar como `postgres` para os testes que criam papéis.
|
||
- Suite final `php vendor/bin/phpunit`: 237/237, 2.503 assertions. PostgreSQL 17.11 + PostGIS 3.6 em UTF-8, DB `investmoz_test`, porta 55441; PHP 8.5.11/Laravel 13.30.1. O cluster isolado foi parado após o teste; a porta 55441 está fechada. A porta 5432 permaneceu como listener preexistente e não foi utilizada.
|
||
- Regressão frontend completa: 113/113. `npm.cmd run types:check` passou; `composer run types:check`/PHPStan: zero erros; Vite build anterior à suite, após alterações React, passou com 2.390 módulos (aviso somente da dependência opcional `fontaine`). Pint no teste PHP alterado e em `routes/investment-zones.php`, `php -l` e `git diff --check` passaram.
|
||
- `composer run lint:check` global continua falhando em dois ficheiros não modificados nesta tranche: `database/migrations/2026_09_28_160000_investment_primary_territory.php` e `tools/test-mne-integrity.php`. Não os reformatei para evitar alterações alheias ao simulador; ficam pendentes para uma tranche de lint global.
|
||
- A Etapa 11 tem regressão automatizada aprovada, não aceitação global concluída: leitor de ecrã/dispositivo físico, incidente QA antigo em 5432, revisão institucional e gates fiscais permanecem pendentes. Nenhuma migração correu na base do utilizador, serviço externo ou produção.
|
||
- Os dados temporários dos clusters QA permanecem inactivos em `%TEMP%` porque o executor recusou a remoção recursiva; directórios exactos: `investmoz-stage11-qa-20261003` (cluster inicial WIN1252, nunca iniciado) e `investmoz-stage11-qa-utf8-20261003` (cluster de teste, parado). Remover manualmente apenas após revisão se o executor continuar a bloquear a operação.
|
||
|
||
### Etapa 5 — avaliador interno da DSL fiscal (2026-10-03)
|
||
|
||
- Criado `app/Services/SimulationTaxRuleExpression.php`: linguagem versionada `investmoz.tax.v1`, whitelist fechada, DAG validado sem ciclos/referências desconhecidas, aritmética exacta com `brick/math`, arredondamento apenas em nó explícito e estado indeterminado quando faltam entradas/parâmetros.
|
||
- `SimulationTaxRuleGovernanceController` valida definições que declaram esta linguagem. Nenhum endpoint público de cálculo invoca o avaliador; não há taxas nem regras fiscais predefinidas.
|
||
- `tests/Unit/SimulationTaxRuleExpressionTest.php`: 3 testes/9 asserções, incluindo cálculo sintético, ausência de valores, ciclo, operação desconhecida e campos extra. PHP 8.5.11, Pint e PHPStan verificados; `git diff --check` sem erros (avisos CRLF em documentos preexistentes).
|
||
- Isto cobre a infraestrutura DSL, não explicabilidade com fonte legal, snapshots de regra, casos dourados fiscais, aprovação de Fiscalista nem activação pública. Etapa 5/antiga Etapa 10 permanece BLOQUEADA para cálculo fiscal de produção.
|
||
|
||
### Parametrização e modos da simulação fiscal (2026-10-03)
|
||
|
||
- Os registos `investmoz.tax.v1` validam parâmetros como `{ value, unit, conditions }`; nova versão de regra pode preservar a mesma AST e alterar apenas valores/unidade/condições. A aprovação e a publicação continuam no fluxo segregado já existente.
|
||
- Criado `SimulationTaxParameterResolver`: selecciona somente versão publicada, componente/`scope_key` exactos, vigência da regra e da fonte, fonte validada na mesma versão e condições correspondentes. Ausência ou mais de uma correspondência devolve estado indeterminado. O resultado inclui valor, unidade, versão e citação da fonte para integrar em snapshots.
|
||
- O resolvedor recebe candidatos visíveis pela política RLS de leitura publicada; o endpoint `POST /api/v1/tax-parameters/resolve` projecta apenas valor, condição declarada, âmbito, versão, vigência e referência da fonte. Não envia a definição DSL nem executa fórmula. O componente do formulário consulta este endpoint no modo aprovado para períodos anuais, mensais, trimestrais e operações pontuais com intervalo exacto.
|
||
- O formulário separa `approved_parameters`, `custom_planning` e `no_calculation`. Só planeamento personalizado pede base/taxa/redução; rascunhos incompletos continuam guardáveis e não bloqueiam navegação. Valores parciais são rejeitados pelo servidor. Resultado aritmético passa a levar `scenario_kind=custom_planning` no snapshot imutável.
|
||
- O resolvedor assinala mudança de vigência dentro do período e sobreposição como indeterminadas; nunca escolhe a taxa mais recente. Testes dirigidos 6/6 (18 asserções), TypeScript, Pint, rota, JSON OpenAPI e Vite build passaram nesta extensão. A leitura depende da migration de policy RLS estar aplicada.
|
||
- A fonte SHA continua declarada e não é comparada automaticamente com exemplar arquivado. O endpoint não está ligado ao job de cálculo nem a snapshots fiscais guardados; não altera resultados históricos nem calcula imposto. Sem parâmetros aprovados correspondentes, a UI permanece indeterminada. Fontes oficiais e casos dourados ainda aguardam validação institucional.
|
||
- Gate fiscal segue **BLOQUEADO para cálculo/publicação legal**. A camada de planeamento hipotético pode ser usada separadamente, sem conclusão de imposto devido.
|
||
|
||
### Revalidação global pós-parametrização fiscal (2026-10-03)
|
||
|
||
- A suite PHP completa foi repetida depois das alterações ao resolvedor e ao modo personalizado: `php vendor/bin/phpunit` passou **245/245 testes, 2.539 asserções** (87,5 s), na base isolada `investmoz_test`, PostgreSQL 17.11/PostGIS 3.6 UTF-8, porta 55441, executada como `postgres` exclusivamente no cluster QA. `php artisan migrate --force` respondeu `Nothing to migrate`; nenhuma migration foi executada.
|
||
- PostgreSQL registou mensagens de falhas esperadas pelos testes negativos de constraints/triggers; PHPUnit terminou com zero falhas/erros. O cluster foi encerrado e `pg_ctl status` confirmou sem servidor. A porta operacional 5432 não foi utilizada.
|
||
- Evidência frontend desta tranche: `node --test tests/frontend/*.test.mjs` 114/114; teste dirigido da interface 20/20; `npm run types:check`, `composer run types:check`/PHPStan, check frontend, Pint, OpenAPI JSON e Vite build (2.390 módulos) passaram. Aviso opcional de build: `fontaine` não instalado. O resolvedor/DSL unitário somou 7 testes/22 asserções; integração de rascunho/simulação somou 24/24 testes/242 asserções no QA.
|
||
- Esta evidência não fecha a Etapa 11: revisão manual com leitor de ecrã/dispositivo, reconciliação do incidente antigo em `investmoz_test:5432`, revisão de produto e aprovação dos gates fiscais continuam pendentes. O motor fiscal não está conectado ao worker e nenhuma taxa/regra foi activada.
|
||
|
||
### M�todo de consolida��o do C�digo do IVA (2026-10-03)
|
||
|
||
- Registada a instru��o para usar a Lei n.� 13/2016, de 30 de Dezembro, como republica��o-base integral do CIVA de 2007; incorporar a rectifica��o identificada pela INM no BR n.� 89/2017; e aplicar cronologicamente altera��es posteriores apenas aos artigos e per�odos que cobrem. Clarificado que a republica��o da Lei 22/2022 no 2.� Suplemento do BR 250 � republica��o do diploma alterador, n�o uma republica��o integral do C�digo.
|
||
- Fontes oficiais localizadas: ficha INM da Lei 13/2016 e da rectifica��o de 2017; ficha INM da Lei 16/2020; ficha INM da republica��o/nota de publica��o sem efeito da Lei 22/2022; PDF da Lei 10/2025 no Parlamento. O teor espec�fico da rectifica��o de 2017 ainda deve ser obtido e comparado; a cadeia regulamentar de 2026 continua a exigir leitura do BR.
|
||
- Actualizados `docs/investmoz/simulations/official-source-register.md`, `fiscal-reform-2026-review.md` e `primary-text-review-2025-2026.md`. Nenhuma taxa foi alterada nem activada por esta revis�o documental.
|
||
|
||
### Revalidacao da Etapa 11 e continuidade das etapas financeiras — 2026-10-03
|
||
|
||
- Releitura do anexo e do estado actual confirma que as regras fiscais (Etapas 4/5/10) continuam sem activacao publica. As calculadoras financeiras (Etapas 3/6/7) permanecem independentes e os cenarios base/favoravel/desfavoravel estao implementados com pressupostos declarados e sem valores fiscais gerados.
|
||
- Regressao frontend reexecutada nesta retoma: `node --test tests/frontend/*.test.mjs` — 115/115. `npm.cmd run types:check` passou. `npm.cmd run build` passou e transformou 2.397 modulos; aviso nao impeditivo: dependencia opcional `fontaine` ausente.
|
||
- O PHPStan global detectou inicialmente 10 erros de tipagem no modulo DUAT presente no worktree. Corrigidos tipos documentados do snapshot cifrado, obtencao tipada do payload validado, teste explicito do resultado de `filter_var`, e verificacao do retorno de `hash_file`; nao foram suprimidos diagnosticos. Reexecucao `composer run types:check`: 0 erros. Pint dirigido corrigiu estilo nos dois ficheiros PHP novos; `pint --test` e `php -l` passaram.
|
||
- `php artisan test --filter=LandAssistanceTest` nao chegou aos casos: 3 falhas de setup por recusa de ligacao ao PostgreSQL QA isolado `127.0.0.1:55441` (`investmoz_test`), confirmado sem listener. Nenhuma migracao correu e a porta 5432 nao foi usada nesta verificacao.
|
||
- Estado da Etapa 11: validacao estatica e frontend actualizada; testes de integracao PHP deste worktree e validacao assistiva/producto continuam pendentes. Etapas 6/7 mantem revisao contabilistica/fiscal institucional como gate; sem mudanca nas regras nem nos resultados fiscais.
|
||
|
||
### Regressao PHP isolada e correcao do consentimento do rascunho — 2026-10-03
|
||
|
||
- A suite focada `LandAssistanceTest` identificou que os campos de declaracao/consentimento eram validados como `accepted` mesmo ao guardar um rascunho. Ajustada a validacao para aceitar os estados booleanos no rascunho; o FormRequest continua a exigir confirmacao verdadeira somente na transicao de pedido de apoio. Suite focada repetida: 3/3 testes, 38 assertions.
|
||
- A regressao PHP global foi executada num novo PostgreSQL 17.11 isolado em `%TEMP%\investmoz-goalqa-20261003-1546`, apenas em `127.0.0.1:55441`, database `investmoz_test`: `php artisan test` passou 250/250 testes, 2.582 assertions, zero falhas/erros. O banco criado para a suite era temporario; nao foi usada a porta operacional 5432.
|
||
- PostgreSQL QA foi encerrado com `pg_ctl stop -m fast`; `pg_ctl status` confirmou servidor parado e nao existe listener em 55441. Os ficheiros de QA ficam apenas em `%TEMP%` para auditoria, sem processo activo.
|
||
- Revalidacao: frontend completo 115/115; TypeScript passou; Vite build passou (2.397 modulos; aviso nao impeditivo da dependencia opcional `fontaine`); PHPStan global 0 erros; Pint dirigido, `php -l` dos ficheiros DUAT e `git diff --check` nao foram repetidos apos este paragrafo; PHP lint/Pint ja passaram antes da suite, e Pint/PHPStan/PHP lint foram novamente executados depois dela.
|
||
- A Etapa 11 fica com regressao automatizada actualizada e verde. Permanecem pendentes ensaio manual com leitor de ecrã/dispositivo, validacao de produto e gates institucionais; as Etapas 4/5/10 continuam sem activacao fiscal/legal. Nenhuma regra foi alterada ou publicada.
|
||
|
||
### Etapa 2/11 — revalidacao responsiva e acessivel com Edge em QA marcado (2026-10-03)
|
||
|
||
- Corrigido o smoke runner `tools/simulator-a11y-browser.mjs`: as condicoes de espera devolvem booleano, evitando serializar referencias DOM circulares pelo CDP; erros CDP agora identificam a chamada. O runner consegue exigir um marcador de alvo recebido no proprio response API.
|
||
- Criado `tools/simulator-qa-router.php`, router local de teste com ambiente fixo para `investmoz_test`/55441, `DB_URL` vazio e header `X-Investmoz-QA-Target`; assets servidos de `public/`. Antes de abrir o browser, GET da pagina e do JS responderam 200 com o marcador esperado.
|
||
- Edge headless visitou o simulador em 390/768/1024/1440 px: sem overflow, 12 focos de teclado visiveis e nomeados, controlos/botoes/links sem nomes em falta, zero alertas/excecoes JavaScript. O GET unico `/api/v1/simulation-drafts/current` respondeu 200 e reportou `investmoz_test:55441`. Sem calculo ou requests de escrita. Evidencia: `docs/investmoz/simulations/simulator-browser-audit-2026-10-03-rerun-runtime-verified.json`, `passed=true`.
|
||
- PostgreSQL QA mostrou 0 simulacoes e 0 drafts apos o smoke. Edge, PHP/18089 e PostgreSQL/55441 foram parados; 55441, 18089 e 9224 ficaram sem listener. 5432 nao foi usada. O cluster e o perfil de browser permanecem inactivos em `%TEMP%`; nenhum dado real foi criado.
|
||
- Estado Etapa 2: validacao automatizada de browser/foco/layout reforcada. Continua parcial: nao houve ensaio com leitor de ecrã real/dispositivo fisico nem revisao de produto. Etapa 11 continua parcial pelos mesmos gates humanos, apesar de regressao automatizada PHP/frontend e analise estatica verdes.
|
||
- Adenda de isolamento do smoke: o router QA foi reforcado para fazer bootstrap da configuracao Laravel, comparar driver/host/porta/base antes de abrir qualquer ligacao e consultar `current_database()`, host e porta na ligacao efectiva; o header QA so e enviado depois dessas verificacoes. A repeticao final Edge passou e esta guardada em `docs/investmoz/simulations/simulator-browser-audit-2026-10-03-rerun-runtime-verified.json` (`qaTargetVerified=true`). A contagem final continua 0 simulacoes/0 drafts. Depois de terminar o servidor PHP, `pg_ctl` ja nao encontrou processo PostgreSQL e as verificacoes confirmaram sem listener em 55441/18089/9224; a pasta QA continua parada em `%TEMP%`.
|
||
|
||
### Revisão do módulo Terra e DUAT face ao prompt consolidado (2026-10-03)
|
||
|
||
- Inspeccionados os ficheiros do módulo, rotas, FormRequest, persistência cifrada, integração CRM, views, migration, testes e inventário. As sete digitalizações estão presentes fora do repositório: duas em `Formulario`, duas em `exploracao` e três em `Consulta`; a classificação deriva apenas das subpastas, sem OCR/revisão. O Guia Nacional e o texto oficial/Boletim da Lei de Terras não foram localizados em cópia legível. `DUAT.docx` foi encontrado, mas o registo anterior informa que estava bloqueado e não foi lido.
|
||
- Criado `docs/investmoz/land-assistance/requirement-traceability.md` com matriz requisito–fonte–campo–validação–teste e gates explícitos. Actualizado `implementation.md`; sem alterações de dados, migrations, formulário ou fontes originais.
|
||
- O fluxo de orientação, formulários imprimíveis, rascunho autenticado, acompanhamento e estados internos existe. Checklist jurídica, OCR/revisão dos scans, teste browser específico, serviço antimalware e integração pública permanecem pendentes.
|
||
- Desvio funcional confirmado: a interface permite escolher telefone como contacto preferido, mas `StoreLandAssistanceCaseRequest` exige email válido no pedido de apoio e `interest_requests.email` é não nulo. Não foi criado endereço sintético nem alterado o contrato partilhado do CRM; é necessária migration aditiva e revisão de consumidores de email para aceitar telefone isolado.
|
||
- Evidência já executada nesta sequência: `LandAssistanceTest` 3/3 (38 asserções), incluído na regressão global PHP 250/250 (2.582 asserções) em QA isolado; a porta operacional 5432 não foi usada. Esta revisão documental não voltou a executar testes.
|
||
- Estado proposto: componente interna parcialmente implementada; checklist legal, designação oficial, confirmação de disponibilidade/direitos e submissão/decisão por autoridade continuam inactivos e dependentes de fontes/competências externas.
|
||
|
||
### Cadeia do CIVA — pista sobre rectificação oficial de 2017 (2026-10-03)
|
||
|
||
- A ficha INM confirma o aviso de rectificação da Lei 13/2016 no BR n.º 89, de 08-06-2017, pág. 569. Uma reprodução integral de terceiro sugere que o aviso altera art. 6(5)(c)-(d), elimina art. 14(2)(c) e rectifica os anexos I–III do art. 9. O sumário oficial não mostra esse teor; a reprodução externa não foi adoptada como autoridade.
|
||
- Acrescentada a pista e o procedimento de cotejo a `official-source-register.md`, `primary-text-review-2025-2026.md` e `fiscal-reform-2026-review.md`. A republicação da Lei 13/2016 permanece a base integral; após confirmar a rectificação em fac-símile oficial, as Leis 16/2020, 22/2022, 3/2025 e 10/2025 são aplicadas artigo por artigo e no período de vigência próprio. A Lei 22/2022 continua tratada como republicação do diploma alterador, não do Código inteiro.
|
||
- Naquele ponto do levantamento, nenhum PDF de terceiro tinha sido arquivado e o BR 89/2017 ainda não estava localizado; nenhuma regra foi activada. **Actualização posterior:** o BR 89 local foi arquivado e o aviso lido parcialmente; a proveniência e os anexos corrigidos continuam pendentes. Ver “CIVA — leitura parcial do BR 89/2017 localizado no acervo” no fim deste registo.
|
||
|
||
- Adenda adicional ao registo cronológico: fontes oficiais INM confirmam que a Lei 3/2012 alterou artigos do CIVA 2007 e que a Lei 3/2025 alterou o artigo 9(13); uma apresentação oficial do MEF aponta a Lei 5/2020 como alteração intercalar desse artigo. Corrigida a sequência nos registos para incluir Lei 3/2012 como antecedente absorvido pela republicação 13/2016 e Leis 5/2020, 16/2020, 22/2022, 3/2025 e 10/2025 posteriores, com a vigência da 5/2020 ainda por verificar no BR. `git diff --check` passou nos documentos desta adenda; não foram necessários testes de código por se tratar de revisão documental.
|
||
|
||
### Ajuste funcional do pedido de apoio Terra/DUAT — contacto telefónico (2026-10-03)
|
||
|
||
- O prompt consolidado do módulo DUAT exige um contacto utilizável, sem exigir email e telefone em simultâneo. O formulário já permitia telefone, mas a submissão de apoio e o CRM bloqueavam email vazio.
|
||
- A migration aditiva `2026_10_03_210000_make_interest_request_email_nullable` permite registar telefone isolado. Email vazio é normalizado para `NULL`; não é criado endereço sintético. O rollback fica bloqueado se já existirem pedidos sem email.
|
||
- A conversão CRM de pedido telefónico para lead continua bloqueada até confirmação de email, pois a deduplicação/identidade CRM actual assenta nesse campo. O caso continua na fila interna para acompanhamento.
|
||
- Foram adicionados testes para consentimento obrigatório e gravação de pedido telefónico. `php -l` passou nos seis ficheiros PHP alterados. `php artisan test --filter=LandAssistanceTest` não conseguiu executar: PostgreSQL de QA `investmoz_test` em `127.0.0.1:55441` recusou ligação; nenhum acesso à base operacional ocorreu. A validação de integração permanece pendente de uma instância isolada activa.
|
||
|
||
### Plano financeiro empresarial — pagamento de valores a pagar de abertura (2026-10-03)
|
||
|
||
- Corrigido o modelo para permitir parcelas mensais explicitamente declaradas dos valores a pagar existentes no início do período. Os pagamentos diminuem caixa e passivo; não diminuem lucro nem despesas do período. Sem calendário, nenhum pagamento é presumido e o saldo integral fica visível no fim do horizonte.
|
||
- Percentagens são calculadas sobre o saldo original, não podem exceder 100% no conjunto, são arredondadas ao cêntimo e limitadas ao saldo ainda aberto. O snapshot passou a `business-plan-v17`; versões v1-v16 permanecem legíveis e restauram calendário vazio. CSV e interface mostram parcelas, pagamentos e saldo pendente.
|
||
- Evidência: `node --test tests/frontend/business-financial-plan.test.mjs` 35/35; `node --test tests/frontend/*.test.mjs` 117/117; `npm.cmd run types:check`, `composer run types:check`/PHPStan (0 erros), Pint no escopo alterado e `npm.cmd run build` (2.397 módulos) passaram. O build emitiu apenas aviso sobre pacote opcional `fontaine`.
|
||
|
||
### Etapa 1 — validação do snapshot na fronteira da execução (2026-10-03)
|
||
|
||
- O guard da resposta de execução aceitava qualquer objecto como `result_snapshot` e deixava a validação para a apresentação. Agora, estados concluídos requerem snapshot v1 internamente coerente ou snapshot legado decimal legível; snapshots v1 inválidos e estados concluídos sem snapshot são rejeitados antes de entrarem no estado da interface. Estados pendentes, falhados e cancelados continuam a aceitar ausência/nulo; snapshots presentes precisam de ser reconhecíveis.
|
||
- Testes específicos `node --test tests/frontend/simulation-contract.test.mjs`: 11/11; `npm.cmd run types:check` passou. Testes adicionais cobrem snapshot v1 válido, objecto inválido, ausente, versão inválida e legado válido. A regressão completa, formatação e build ficam registados abaixo após execução.
|
||
|
||
### Actualização final das verificações desta retoma (2026-10-03)
|
||
|
||
- A tentativa inicial DUAT na porta 55441 recusou ligação; foi criada uma nova instância PostgreSQL 17 isolada em `%TEMP%\investmoz-sequential-qa-20261003`, sem ligar à porta 5432. A primeira tentativa em 55442 descobriu que o `TestCase` só limpa o schema QA registado em 55441; o cluster foi movido para a porta autorizada do harness e o teste foi repetido sem alterar a lógica de produção para acomodar QA.
|
||
- Após corrigir o fallback do email da conta quando o utilizador enviou explicitamente email vazio, `php artisan test --filter=LandAssistanceTest` passou 4/4 (42 asserções). Suite PHP integral: 251/251 (2.586 asserções), 69,2 s. A migration foi exercitada apenas neste cluster descartável. PostgreSQL QA foi parado; porta 55441 ficou livre; a porta 5432 permaneceu no listener preexistente e não foi consultada nem usada.
|
||
- A verificação final do snapshot API adicionou validação na fronteira das execuções. Suite frontend antes da correcção automática de formatação: 117/117; `npm.cmd run check:fix` e check dirigido passaram depois. Build Vite passou com 2.397 módulos. A nova verificação não altera regras fiscais nem activa componentes bloqueadas.
|
||
|
||
### Migration de contacto — verificação de reversibilidade e suite integral final (2026-10-03)
|
||
|
||
- `LandAssistanceTest` passou 6/6 (46 asserções), incluindo dois testes directos da migration: reversão normal quando não há emails nulos e recusa segura quando já existem pedidos só telefónicos. A reversão não altera a coluna em caso de bloqueio.
|
||
- Regressão PHP integral repetida após os novos testes: `php artisan test` passou 253/253, 2.590 asserções (63,2 s) em PostgreSQL 17 isolado. Cluster parado e `pg_ctl status` confirmou sem servidor; apenas listener preexistente em 5432 permaneceu, sem conexão de teste.
|
||
- O rollback operacional é deliberadamente condicionado: primeiro tem de haver decisão sobre cada pedido telefónico para preencher email real ou preservar a migration. Não se elimina nem inventa contacto para tornar rollback possível.
|
||
|
||
### Reconciliação da Etapa 1 — 2026-10-03
|
||
|
||
A linha de estado anterior que mantinha a Etapa 1 parcial foi revista contra as evidências existentes: `SimulationExecutionTest` valida questionário, report/jobs e round-trip do snapshot persistido; o contrato API do relatório compara payload/hash guardados e rejeita token alheio; os testes de drafts cobrem conversão, retoma e versão concorrente. A interface valida runtime os endpoints que actualmente consome. Questionnaire/jobs/report não são consumidos no React; os guards permanecem testados para futura integração e não se cria consumo artificial apenas para exercitá-los. Estado proposto corrigido para concluída tecnicamente, sujeito ao gate global da Etapa 11.
|
||
|
||
### Etapa 2 — auditoria responsiva com cálculo isolado no browser (2026-10-03)
|
||
|
||
- A matriz de Edge headless foi ampliada para 320, 360, 390, 768, 1024 e 1440 px nos estados de finalidade, operação fiscal e resultado. Foram verificados overflow horizontal, nomes acessíveis de controlos/botões/links e a árvore de acessibilidade. O formulário passou nas duas primeiras etapas; o resultado revelou overflow de um decimal longo em larguras 320–390 px.
|
||
- Corrigido o foco programático sem indicador visível no título da etapa: agora exibe outline de 2 px. O resultado numérico ganhou quebra de linha em números longos, sem truncar nem arredondar os dígitos exibidos.
|
||
- Corrigido o roteiro E2E para escolher o modo real “Cenário personalizado de planeamento”. O servidor QA teve de ser iniciado com `public` como document root para servir os assets Vite; o router fixa e verifica a base PostgreSQL `investmoz_test:55441` antes de atender Laravel.
|
||
- Evidência final: `docs/investmoz/simulations/simulator-calculation-responsive-browser-2026-10-03.json`, `passed=true`, `qaTargetVerified=true`, 3 estados × 6 larguras sem overflow/nomes em falta; foco fiscal visível; erro de campo acessível e focado; uma criação API (HTTP 202), polling concluído, sem erros JS/alertas; resultado esperado 50 confirmado. Nenhum dado pessoal foi fornecido.
|
||
- O banco temporário isolado registou 4 simulações e 5 rascunhos gerados pelas tentativas E2E repetidas, sem dados pessoais; não foi feita limpeza selectiva. PostgreSQL/55441, PHP/18089 e Edge/CDP/9224 foram encerrados. O workspace e a porta operacional 5432 não foram usados para estes pedidos.
|
||
- Etapa 2 permanece parcial: a validação automatizada não substitui ensaio com leitor de ecrã real, dispositivo físico ou revisão de produto. A Etapa 11 também não fecha esses gates humanos.
|
||
|
||
### Etapa 3 — proveniência dos valores de demonstração (2026-10-03)
|
||
|
||
- A auditoria confirmou que as ferramentas financeiras abriam com montantes demonstrativos preenchidos, mas o CSV dizia que todos os pressupostos tinham sido introduzidos pelo utilizador. Isso podia atribuir falsa proveniência a valores que o utilizador ainda não confirmou.
|
||
- A interface passou a identificar junto às ferramentas que os valores iniciais são exemplos e devem ser alterados ou confirmados. O CSV agora declara que os valores são editáveis e que os valores iniciais são demonstrativos. Fórmulas e defaults não foram alterados.
|
||
- Ficheiros: `resources/js/components/simulation-financial-tools.tsx`, `resources/js/lib/financial-calculators.ts`, `tests/frontend/financial-calculators.test.mjs`.
|
||
- Evidência: teste financeiro 14/14; suite frontend 117/117; `npm.cmd run types:check`; check/lint nos três ficheiros; build Vite com 2.397 módulos; `git diff --check` sem erros (apenas avisos CRLF preexistentes noutros documentos).
|
||
- Etapa 3 continua parcial: permanece por avaliar a cobertura de necessidades pessoais mais ampla e a validação financeira institucional. As calculadoras são educativas, não contêm ofertas de credores e não são aconselhamento financeiro.
|
||
|
||
### Etapa 3 — dados ausentes no orçamento (2026-10-03)
|
||
|
||
- `calculateBudget([], [])` e listas parciais vazias somavam implicitamente zero. Agora, sem pelo menos uma linha de receita e uma de despesa, o cálculo devolve erro explícito; zero explícito em ambas as linhas continua válido. Snapshots com alguma das listas vazia são rejeitados ao restaurar.
|
||
- Ficheiros: `resources/js/lib/financial-calculators.ts`, `tests/frontend/financial-calculators.test.mjs`.
|
||
- Evidência: teste financeiro 15/15; suite frontend 118/118; TypeScript; check/lint dirigido; build Vite com 2.397 módulos; `git diff --check` sem erros. Avisos CRLF de documentos preexistentes e aviso opcional `fontaine` continuam sem relação com esta tranche.
|
||
- A Etapa 3 satisfaz agora tecnicamente a distinção testada entre ausência e zero para o orçamento, mas permanece parcial até validar as necessidades de planeamento pessoal e obter revisão financeira institucional.
|
||
|
||
### Etapa 6 — auditoria de cobertura técnica (2026-10-03)
|
||
|
||
- Confrontei os requisitos de planeamento empresarial do anexo com `business-financial-plan.ts`, `monthly-cashflow.ts`, a interface, CSV e `business-financial-plan.test.mjs`. As dimensões nucleares do plano estão cobertas: activos/fundo de maneio, vendas e custos por produto, inventário/compras/lead time, despesas/pessoal, fontes/deficit de financiamento, recebíveis, resultados/caixa, principal versus juros, depreciação contabilística versus fiscal e conversão cambial declarada.
|
||
- Criado `docs/investmoz/simulations/stage-6-technical-traceability.md` com o mapa requisito→implementação→teste. `node --test tests/frontend/business-financial-plan.test.mjs` passou 35/35 nesta auditoria.
|
||
- Reconciliado o gate: os requisitos técnicos nucleares do anexo estão cobertos; a etapa global permanece parcial até revisão contabilística institucional. Exposição agregada e limites partilhados por fornecedor, incumprimento e risco de crédito não são modelados; o sistema não inventa probabilidades nem condições de crédito. A ponte fiscal continua indeterminada.
|
||
- Não houve alteração de código ou de dados nesta auditoria. A regressão frontend 118/118, TypeScript e build Vite (2.397 módulos) já tinham passado na tranche imediatamente anterior.
|
||
|
||
### Etapa 7 — imposto desconhecido não é zero (2026-10-03)
|
||
|
||
- A auditoria encontrou que o planeador de tesouraria iniciava `monthlyTaxAssessed` em `0` e o motor também convertia omissão em zero. Isso apresentava o saldo como completo sem se conhecer imposto apurado, contrariando a regra de não esconder valores fiscais desconhecidos.
|
||
- Agora campo vazio/omitido mantém estado `incomplete`; imposto, fluxo líquido e saldo final totais são indeterminados. O formulário mostra separadamente fluxos e caixa conhecidos antes do imposto em falta. Um `0` introduzido explicitamente continua a produzir uma estimativa completa conforme os pressupostos declarados. CSV assinala imposto ausente e conserva os campos indeterminados.
|
||
- Crédito IVA estimado, pedido e reconhecimento mantêm-se fora do caixa; apenas recebimento explícito até ao montante reconhecido e com mês indicado entra no fluxo.
|
||
- Ficheiros: `resources/js/lib/monthly-cashflow.ts`, `resources/js/components/simulation-cashflow-planner.tsx`, `tests/frontend/monthly-cashflow.test.mjs`, `docs/investmoz/simulations/stage-7-technical-traceability.md`.
|
||
- Evidência: caixa 7/7; ponte/caixa/plano 46/46; suite frontend 119/119; TypeScript, check/lint dirigido, build Vite (2.397 módulos) e `git diff --check` passaram. Avisos CRLF e `fontaine` são preexistentes e não impedem o build.
|
||
- Etapa 7: comportamento técnico de propagação explícita da indeterminação e reconciliação coberto; continua parcial para apuramento fiscal, que depende de regras aprovadas. A ferramenta de tesouraria aceita ainda um único pressuposto mensal fixo, não um calendário mensal variável de imposto.
|
||
|
||
### Etapa 8 — proveniência e metadados dos CSV (2026-10-03)
|
||
|
||
- Auditoria da exportação encontrou declaração incorrecta no CSV do plano empresarial (pressupostos inicializados com exemplos eram atribuídos ao utilizador) e exportação de tesouraria sem data/versão/horizonte explícitos.
|
||
- Plano empresarial agora descreve conservadoramente os valores como dados do formulário, com possível origem demonstrativa. A tesouraria avisa na interface que valores ao abrir são exemplos e inclui no CSV `monthly-cashflow-v1`, data, horizonte, moeda, estado e origem prudente dos pressupostos. Exportação continua local e sem PII.
|
||
- Criado `docs/investmoz/simulations/stage-8-technical-traceability.md`, relacionando contratos, CSV, snapshots, hashes, estados e testes do requisito do anexo.
|
||
- Evidência: suites de plano/tesouraria/formulário 63/63; frontend integral 119/119; TypeScript; build Vite 2.397 módulos; `git diff --check`. O check de cinco ficheiros passou sem erros, com três avisos de lint preexistentes no plano financeiro (`business-financial-plan.ts`, linhas 1420/1461/1866). Build avisou apenas do pacote opcional `fontaine`; diff check sinalizou CRLF preexistente noutros documentos.
|
||
- Etapa 8 mantém conclusão técnica para CSV/reprodução. A validação manual assistiva e produto continua na Etapa 2/11; não foi acrescentado PDF, não exigido no anexo.
|
||
|
||
### Etapa 9 — conversão consentida para rascunho, reconciliação final (2026-10-03)
|
||
|
||
- Revistos consentimento explícito, titularidade/política de acesso, integridade hash/snapshot, preservação da simulação original, deduplicação, ETag/optimistic locking, revogação da reutilização, fontes forjadas e contrato OpenAPI. O mapa requisito→código→teste está em `docs/investmoz/simulations/stage-9-technical-traceability.md`.
|
||
- `php artisan test --filter=SimulationFormDraftTest`: 10/10 testes, 79 asserções, PostgreSQL 17/PostGIS numa base descartável em 127.0.0.1:55441 com login não-superuser. Servidor parado após a execução; a base operacional na porta 5432 não foi usada.
|
||
- A conversão anexa uma referência imutável ao rascunho do formulário. Não cria projecto, submissão formal nem registo CRM. Essa integração, a validação manual assistiva e a aprovação do fluxo pelo produto permanecem pendentes; Etapa 9/gate global continuam parciais.
|
||
- Esta tranche foi read-only em relação ao código e aos dados da aplicação; só acrescentou evidência documental. Rollback: remover o novo mapa de rastreabilidade e esta adenda.
|
||
|
||
### Etapa 5 do anexo actual / Etapa 10 histórica — reconciliação do motor fiscal (2026-10-03)
|
||
|
||
- Auditoria detectou que `stage-10-gate.md` dizia que DSL/DAG e resolvedor estavam ausentes, apesar das implementações posteriores no worktree. Corrigi o estado documental sem substituir o histórico inicial: agora distingue infraestrutura técnica parcial de cálculo fiscal público bloqueado.
|
||
- A matriz requisito→código→evidência está em `docs/investmoz/simulations/stage-10-technical-traceability.md`. A auditoria confirma evaluator allowlist/DAG, aritmética racional, arredondamento explícito, parâmetros por scope/vigência/contexto, governação versionada, RLS e trilho de eventos.
|
||
- Evidência executada nesta retoma: DSL/resolvedor 9/9 testes, 27 asserções; governação 4/4 testes, 52 asserções em PostgreSQL 17/PostGIS isolado na porta 55441. Cluster parado; 5432 não foi usada.
|
||
- Não há integração do avaliador com `RunSimulation`, explicabilidade fiscal completa no snapshot ou casos golden fiscais aprovados por Fiscalista. Nenhuma regra/taxa foi activada e nenhum código, migration ou dado foi alterado.
|
||
|
||
### Etapa 10 do anexo — extensões informativas e territoriais (2026-10-03)
|
||
|
||
- Inspeccionei a matriz do anexo e comparei as extensões com `InvestmentZones`, controladores de zona/relação/geometria, páginas públicas, fonte/vigência e origem da manifestação. O detalhe requisito→evidência→limite está em `docs/investmoz/simulations/stage-10-extension-traceability.md`.
|
||
- O aviso público já deixa claro que localização/associação não atribui benefícios, licenças ou autorização aduaneira. A publicação depende de registo e fonte vigentes; relações e geometrias passam por revisão segregada. O mapa e as submissões preservam a proveniência/versão da zona.
|
||
- `php artisan test --filter=InvestmentZoneTest`: 6/6 testes, 104 asserções, PHP 8.5.11, PostgreSQL 17/PostGIS QA isolado na porta 55441; servidor parado. O exercício de rollback da suite ocorreu exclusivamente no banco descartável. 5432 não foi usado.
|
||
- Etapa 10 permanece parcial: não existem nesta evidência cálculo de incentivo, elegibilidade fiscal, cálculo pautal/cambial ou decisão de licenciamento/visto/trabalho. Não alterei código, fontes, parâmetros ou dados.
|
||
|
||
### Etapa 11 — regressão global revalidada (2026-10-03)
|
||
|
||
- `node --test tests/frontend/*.test.mjs`: 119/119; `npm.cmd run types:check`: aprovado; `composer run types:check`: PHPStan 0 erros; `npm.cmd run build`: aprovado, 2.397 módulos (aviso não impeditivo do pacote opcional `fontaine`).
|
||
- Primeira suite PHP com login QA não-superuser terminou 250/253: três testes RLS falharam no setup ao criar `simulation_rls_test` por falta de `CREATEROLE`, não em asserções funcionais. Repetição completa em `investmoz_test` no cluster QA local usando o administrador do cluster: `php artisan test` passou 253/253, 2.590 asserções, 64,8 s. Tudo ocorreu em PostgreSQL 17/PostGIS isolado na porta 55441; o cluster foi parado após os testes e 5432 não foi usada.
|
||
- Esta suite global demonstra regressão automatizada, não fecha leitor de ecrã/dispositivo, aprovação de produto nem os gates legais/fiscais. O uso do administrador ficou restrito à base de teste local e aos testes RLS que criam papel; nenhuma base compartilhada/produção foi usada.
|
||
|
||
### Etapa 7 — calendário variável de imposto em tesouraria (2026-10-03)
|
||
|
||
- Fechada a limitação documentada de um único montante fiscal mensal fixo. O planeador oferece modo fixo ou 12 valores por mês; montantes são pressupostos do utilizador, não cálculo fiscal.
|
||
- Mês vazio/null mantém imposto desconhecido e saldo total indeterminado a partir daí. A caixa conhecida inclui impostos declarados e omite apenas os meses em falta; zero explícito continua distinto de ausência. Rejeita calendário com extensão diferente do horizonte e combinações ambíguas entre modos.
|
||
- O CSV regista cada mês, indica os meses desconhecidos, e diz que os valores de imposto não são calculados nem confirmam obrigação fiscal. Estados de crédito/pedido/reconhecimento IVA continuam fora da caixa.
|
||
- Ficheiros: `resources/js/lib/monthly-cashflow.ts`, `resources/js/components/simulation-cashflow-planner.tsx`, `tests/frontend/monthly-cashflow.test.mjs`, rastreabilidade da Etapa 7 e estado actual. Evidência: 11/11 testes mensais; frontend 123/123; TypeScript e check dirigido limpo. O build final foi executado após esta tranche, conforme registo abaixo.
|
||
- Limite: calendário permanece no estado local da página, não em snapshot de conta; sem regra legal ou persistência fiscal. Não houve alteração de código fiscal.
|
||
|
||
- Build final após o calendário: `npm.cmd run build` passou, 2.397 módulos; apenas aviso não impeditivo da dependência opcional `fontaine` ausente.
|
||
|
||
### Etapa 7/11 — limite do ensaio browser do calendário (2026-10-03)
|
||
|
||
- Tentei estender o Edge/CDP existente para seleccionar o modo variável, preencher meses 1/2 e verificar a indeterminação e os seis viewports. O runner montou o formulário e acedeu à API QA, mas a última execução terminou com erro de protocolo CDP (`Object reference chain is too long`) antes das asserções do calendário. A tentativa não é evidência de aprovação browser e o JSON falhado foi removido; o runner original foi restaurado.
|
||
- As asserções automatizadas da biblioteca continuam válidas: calendário mensal 11/11; frontend integral 123/123; TypeScript, `vp check` dirigido e build Vite 2.397 módulos aprovados. A validação visual/assistiva específica do calendário permanece em aberto.
|
||
- QA: PostgreSQL/PostGIS `investmoz_test:55441`; o router serviu assets usando `public` como document root. Concedi/revoguei grants apenas no banco temporário para reproduzir o papel da aplicação; revoguei-os e parei o cluster, PHP/18089 e Edge/CDP/9224. 5432 não foi usada. Não houve publicação ou activação fiscal.
|
||
|
||
### Terra e DUAT — reconciliação preliminar de fontes e documentos (2026-10-03)
|
||
|
||
- Reinspeccionei o módulo já existente e inventariei de novo os sete PDFs nas subpastas `Formulario`, `exploracao` e `Consulta`; bytes e SHA-256 coincidem com o inventário anterior. Os originais ficaram intactos e fora da pasta pública. Não executei OCR nem reconstruí conteúdo.
|
||
- A triagem de fontes foi registada em `docs/investmoz/land-assistance/legal-source-review-2026-10-03.md`: cópias governamentais PDUL da Lei 19/97, Decreto 66/98 e Decreto 60/2006; sumário oficial INM que identifica o DM 47/2020 e a actualização de taxas; Parlamento lista revisão da Lei de Terras sob propostas e disponibiliza texto de proposta. A proposta permanece separada/inactiva; não foram codificados taxas, prazos, critérios de checklist ou efeitos jurídicos.
|
||
- Corrigi a matriz de rastreabilidade e a descrição técnica para reflectir a aceitação de email **ou** telefone, migration aditiva para email nulo e execução QA registada (6/6 testes DUAT, 46 asserções; suite PHP 253/253). Integrações downstream com email obrigatório precisam de validação operacional.
|
||
- Comandos efectivamente executados nesta retoma: inventário/Get-FileHash dos sete PDFs; `php -v` (8.5.11); `php artisan route:list --path=terra-duat --except-vendor` (16 rotas). Não voltei a executar testes, pois não houve alteração de código; as evidências de teste citadas são as execuções QA anteriores constantes dos registos.
|
||
- Gate: fluxo interno de orientação/acompanhamento continua parcialmente implementado; checklist jurídica, modelos oficiais, taxas, prazos, actualidade do formulário, antimalware e validação browser/acessibilidade permanecem pendentes. A revisão de fonte é preliminar e exige confirmação jurídica/administrativa humana.
|
||
|
||
### Etapa 7 — Edge isolado do calendário mensal de tesouraria (2026-10-03)
|
||
|
||
- A execução em Edge headless com Vite isolado passou para o componente React real: valor mensal fixo; meses variáveis; mês em falta devolve “Indeterminado”; zero explícito permite estimativa completa com 12 linhas.
|
||
- Seis viewports (320, 360, 390, 768, 1024 e 1440 px) não tiveram overflow horizontal; 24 inputs têm nome; árvore AX sem controlos sem nome; sem excepções JS/falhas de rede.
|
||
- Evidência: `docs/investmoz/simulations/simulator-cashflow-browser-2026-10-03.json`. Montagem/harness em `tools/simulator-cashflow-preview.html` e `tools/simulator-cashflow-component-browser.mjs`. `node --check` e `npm.cmd run check` nos dois ficheiros passaram.
|
||
- Ensaio limitado ao componente servido localmente por Vite; sem Laravel/API/DB. Não substitui o ensaio da página de produção, persistência, leitor de ecrã real ou dispositivo físico.
|
||
|
||
### Etapa 9 — manifestação pública independente do fiscal (2026-10-03)
|
||
|
||
- A auditoria confirmou que a página pública já tinha a manifestação de interesse geral, mas o resultado do simulador só mostrava a opção consentida de anexar dados a um rascunho. Foi acrescentada uma ligação contextual para `/manifestar-interesse` em resultados concluídos, com texto explícito de que o snapshot não será partilhado.
|
||
- A ligação não envia valores, query parameters ou identificador da simulação, não exige conta e não depende da disponibilidade fiscal. A conversão consentida em rascunho permanece uma acção distinta.
|
||
- Ficheiros: `resources/js/components/simulation-form.tsx`, `tests/frontend/simulator-entry.test.mjs`, `docs/investmoz/simulations/stage-9-technical-traceability.md` e este registo.
|
||
- Verificação desta tranche: `node --test tests/frontend/simulator-entry.test.mjs` passou 2/2; `node --test tests/frontend/*.test.mjs` passou 124/124; `npm.cmd run check -- resources/js/components/simulation-form.tsx tests/frontend/simulator-entry.test.mjs` passou; `npm.cmd run types:check` passou; `npm.cmd run build` passou com 2.397 módulos (aviso informativo de `fontaine` opcional ausente); `git diff --check` sem erros, com avisos CRLF em documentos alheios. A rota pública `/manifestar-interesse` tem cobertura feature existente; a suíte PHP não foi repetida nesta tranche.
|
||
- Gate: requisito técnico de não bloqueio de manifestação coberto; não cria Project, não altera CRM nem associa dados da simulação à manifestação. Gates de produto e revisão assistiva continuam pendentes.
|
||
|
||
### CIVA — regra de consolidação legislativa reafirmada (2026-10-03)
|
||
|
||
- A Lei n.º 13/2016, de 30 de Dezembro, é a base integral para consolidar o Código do IVA desde a sua vigência. A Lei n.º 3/2012 e diplomas anteriores servem para reconciliar a cadeia e confirmar o texto incorporado; não voltam a ser somados como patches sobre a republicação de 2016.
|
||
- Alterações posteriores são aplicadas por dispositivo, período de vigência e regra transitória. Para cada artigo/período haverá uma única redacção efectiva; uma alteração parcial não substitui o Código todo nem deve coexistir com a redacção que substituiu.
|
||
- A regra foi explicitada em `docs/investmoz/simulations/official-source-register.md` e já está detalhada em `docs/investmoz/simulations/primary-text-review-2025-2026.md`. A rectificação do BR 89/2017 e a validação completa das alterações posteriores continuam dependentes de cotejo documental; esta instrução metodológica não aprova parâmetros nem desbloqueia o motor fiscal.
|
||
- Alteração exclusivamente documental. Não executei testes nem alterei fórmulas, taxas, dados ou parâmetros fiscais.
|
||
|
||
### CIVA — leitura parcial do BR 89/2017 localizado no acervo (2026-10-03)
|
||
|
||
- Localizei no acervo do utilizador `br-series-i-08-06-2017-n.º-89.pdf` (9.456.358 bytes). Foi copiado sem transformação para `docs/investmoz/simulations/source-archive/BR-89-I-Serie-2017-06-08.pdf`; SHA-256 de origem e cópia idêntico: `11F0CAB15EB6E51010952203FFA24FDC533A24FD642E19525FE4F46B17A1F5E5`.
|
||
- `pdfjs-dist` 4.10.38 foi instalado somente em `%TEMP%` para leitura; o PDF tem 16 páginas e metadados internos identificam `BR_89_I_SÉRIE_2017.indd`, criação 01-06-2017. A página 569 confirma a alteração de CIVA no art. 6(5)(c)-(d), elimina o art. 14(2)(c) e ordena rectificar os anexos I–III ligados ao art. 9. O aviso não apresenta os anexos substitutivos.
|
||
- Limite de proveniência: a ficha INM coincide em número/data e o PDF é consistente com a edição, mas o ficheiro veio do acervo local, o download directo da INM falhou e não há assinatura digital validável. A cópia digitalizada local do suposto Código rectificado tem 15 páginas sem camada de texto; não foi usada para inferir conteúdo. Artigos e anexos não estão aprovados como regras executáveis.
|
||
|
||
### Continuação sequencial — catálogo SuiteCRM (2026-10-04)
|
||
|
||
- Corrigida a referência de caminho danificada por carácter de controlo e removida a frase histórica errada de que o cliente e os testes seriam acrescentados futuramente; ambos já existem. Clarificado que o cliente está desligado e que não existe tráfego real.
|
||
- Criado `docs/investmoz/suitecrm/mapping-catalog.md`: matriz lógica com 15 colunas cobrindo manifestações, investidores/contactos, leads/tarefas, catálogo público, geografia, aftercare e assistência DUAT. Define finalidade, consentimento, autoridade, minimização, classificação, idempotência, acesso e evidências necessárias.
|
||
- A matriz não especifica nomes técnicos presumidos para campos SuiteCRM; a descoberta e validação desses nomes requerem instância isolada de homologação. Não foram criadas credenciais, jobs de exportação, chamadas externas ou mudanças de dados.
|
||
- Verificação documental: scan de caracteres de controlo (zero) e `git diff --check` nos documentos alterados, ambos sem erros. Nenhum teste de código foi repetido nesta etapa exclusivamente documental; regressão mais recente permanece PHP 253/253, frontend 124/124, PHPStan e TypeScript sem erros.
|
||
- Continuação QA independente: Edge headless e `tools/simulator-a11y-browser.mjs` passaram no simulador a 390/768/1024/1440 px; zero overflow, nomes acessíveis ausentes, foco inválido, alertas e erros JS. O GET de rascunho confirmou `investmoz_test:55441`. Evidência em `docs/investmoz/simulations/simulator-a11y-browser-2026-10-04.json`; não equivale a teste com leitor de ecrã/utilizadores.
|
||
- Próximo gate: instalar e validar uma instância SuiteCRM de homologação com TLS e permissões aprovadas antes de codificar workers, relações e mapeamento executável. Verificação do ambiente: Docker/Podman indisponíveis e WSL não instalado. A matriz oficial consultada lista PHP 8.2–8.4 para SuiteCRM 8.10.x, enquanto o portal exige PHP 8.5; não iniciei instalação incompatível nem alterei o sistema operativo. Até resolver runtime/homologação, `SUITECRM_ENABLED=false`.
|
||
- Actualizei `primary-text-review-2025-2026.md`, `fiscal-reform-2026-review.md`, `official-source-register.md` e `current-status-2026-10-03.md` para substituir a afirmação de que o teor inteiro do aviso era desconhecido e para distinguir o texto lido das listas ainda pendentes.
|
||
- Comandos/evidência desta tranche: inventário e `Get-FileHash`; `npm.cmd install --prefix C:\Users\macbook\AppData\Local\Temp\investmoz-pdf-review --no-save pdfjs-dist@4.10.38`; extracção de texto/metadados do PDF arquivado; comparação de hash origem/cópia; verificação de existência e espaços finais nos documentos tocados. Os únicos espaços finais detectados são quebras Markdown já presentes nos cabeçalhos/front matter. Nenhum teste automatizado foi necessário para a alteração documental; nenhuma regra, taxa ou dado da aplicação foi activado.
|
||
|
||
### Reconciliação do prompt master consolidado — 2026-10-04
|
||
|
||
- Li o prompt anexado em `C:\Users\macbook\.codex\attachments\95cf3a5e-fdbf-4005-a877-57d4ac1f93c5\Pasted text.txt`. Autorização cobre código, testes e documentação reversíveis; não cobre produção, pagamentos, contacto de terceiros nem alteração destrutiva de dados. Mantive o worktree existente sem reset/clean e não li `.env`.
|
||
- Confirmei que o acervo indicado em `C:\Mac\Home\Documents\TEMPO\Portal Tempo` está acessível. Localizei o resumo fiscal secundário que estava descrito como indisponível em `fiscal-reform-2026-review.md`; actualizei o estado sem o tratar como fonte normativa. A colecção de prompts contém documentos adicionais; foi feita extracção selectiva, não uma declaração de revisão completa de todas as pastas.
|
||
- Inspeccionei fontes fiscais por metadados, camada de texto e hash. Lei 13/2016 e sua cópia denominada rectificada estão presentes, mas são digitalizações sem camada de texto; OCR temporário não produziu transcrição utilizável. Lei 22/2022, a alteração CIVA 2023 e a Lei 12/2025 têm texto extraível em cópias locais. CBF e ISPC_Financas também foram encontrados, com leitura incompleta. Inventário e limites foram registados na matriz consolidada e em `fiscal-reform-2026-review.md`.
|
||
- Comparei o resumo fiscal secundário contra o BR 248 arquivado, não apenas contra a cópia em `Legislacao/novas`: a cópia arquivada tem 21 páginas, 440.018 bytes e hash `CCF2A8DEECA820F2DD076B4B2141B1EFE3F6A806568C3A587CA59A8E92F4C251`; a cópia da pasta indicada pelo proprietário tem 20 páginas e hash distinto `A0110696253715567AF39C159A21BACFEBC32F944FA43A4EFD18070D36959E50`. A extracção da cópia arquivada confirmou textualmente os arts. 18(6), 19(2), 21(10)/(15), 32–33 da Lei 10/2025 e a exclusão de serviços digitais do teste de estabelecimento estável de serviços da Lei 12/2025, art. 3(2)(c). Confirmei também que a taxa autónoma de 32% está no art. 61-A do IRPC e não deve ser transferida ao IRPS (Lei 11/2025, art. 54-A). Pendências sobre anexos de isenção e Decreto 52/2025 permanecem sem alteração funcional.
|
||
- O PDF OCAM foi lido somente para determinar âmbito: compromisso do Modelo 20 da empresa, exercício 2025. Não o apresentei como certificação do simulador/OCAM e omiti identificadores pessoais. A revisão de contabilista/fiscalista foi registada como declaração do proprietário, conforme pedido, sem transformar essa declaração em prova independente anexada.
|
||
- Reconciliei `rule-governance.md` com o código: whitelist DSL/DAG/BigRational e resolvedor temporal existem; a projecção pública de parâmetros e interface existem; `RunSimulation` não chama o avaliador e continua sem cálculo de IRPC/IVA/ISPC/IRPS/INSS/retenções/ICE/aduaneiro. Corrigi afirmações históricas contraditórias, mantendo gate de cálculo fiscal integrado pendente.
|
||
- Não liguei regras fiscais a `RunSimulation` nesta tranche: os textos-base/anexos digitalizados ainda não permitem validar fórmulas e resultados de forma independente. Isso não bloqueia melhorias neutras, calculadoras financeiras nem testes técnicos.
|
||
- Ficheiros alterados: `docs/investmoz/consolidated-review-matrix-2026-10-03.md` (adenda corrente e inventário/hash de fontes), `docs/investmoz/simulations/fiscal-reform-2026-review.md` (disponibilidade do resumo e evidência local), `docs/investmoz/simulations/rule-governance.md` (estado actual do DSL, resolvedor e integração), este ledger.
|
||
- Comandos executados: leitura do anexo; `Get-Item`, `Get-ChildItem`, `git status --short`; scripts temporários Node/pdfjs para metadados e extracção de texto; importação temporária de pdfjs/tesseract.js/canvas; tentativa de OCR da digitalização rectificada (abriu o PDF, mas terminou antes de produzir texto). Nenhum teste automatizado foi executado nesta tranche exclusivamente documental. Nenhum diploma original foi alterado, publicado ou copiado para a área pública.
|
||
- Estado: documentação reconciliada parcialmente; motor fiscal **parcial**, sem cálculo tributário integrado. Rollback documental: reverter somente os quatro ficheiros desta tranche, preservando restantes alterações do utilizador. Próxima execução segura: extrair/reconciliar artigos dos PDFs com texto, obter OCR visual verificável para scans e ligar apenas componentes com regra e caso de referência independente; manter indeterminação nos restantes.
|
||
|
||
### Câmbio nas conversões de planeamento — 2026-10-04
|
||
|
||
- Auditoria dos montantes mostrou que as fichas de investidor/oportunidade preservam valor + código monetário, enquanto catálogo filtra e ordena dentro da moeda. Essas operações não somam nem convertem moedas diferentes e, por isso, não devem inventar uma taxa.
|
||
- O plano financeiro já permite conversão opcional de apresentação; exige a taxa (moeda de apresentação por uma unidade da moeda-base), data efectiva e fonte/referência. A taxa é introduzida pelo utilizador, incluída no snapshot e usada para apresentar resultados convertidos, conservando os valores originais.
|
||
- A calculadora financeira usa cêntimos e aceita moedas ISO suportadas com duas casas decimais; a interface agora identifica esse limite para códigos sugeridos com outra precisão minoritária. O cadastro de montantes do investidor continua a preservar a moeda declarada sem conversão.
|
||
- Clarifiquei na interface que o portal não busca nem valida a cotação e que a conversão é apenas pressuposto de planeamento; resultados/exportação não a representam como taxa oficial, fiscal ou aduaneira. O CSV passou a incluir o estado “pressuposto de planeamento declarado pelo utilizador; nao verificado pelo portal”.
|
||
- Atualizei `docs/investmoz/simulations/data-contracts.md` para separar conversão exploratória do plano e câmbio oficial fiscal/aduaneiro. Quando uma conversão legal exigir taxa oficial versionada, fonte, âmbito e vigência, o cálculo continua indeterminado até esse parâmetro existir.
|
||
- Ficheiros alterados: `resources/js/components/simulation-business-plan.tsx`, `resources/js/lib/business-financial-plan.ts`, `tests/frontend/business-financial-plan.test.mjs`, `docs/investmoz/simulations/data-contracts.md` e este ledger.
|
||
- Verificação em PHP 8.5.11 não necessária (sem backend); `node --test tests/frontend/business-financial-plan.test.mjs` passou 36/36; `npm.cmd run types:check` passou; `npm.cmd exec -- vp fmt --check resources/js/components/simulation-business-plan.tsx resources/js/lib/business-financial-plan.ts tests/frontend/business-financial-plan.test.mjs` passou após formatar um bloco JSX.
|
||
- Sem taxas fixas, serviço externo, migration, alteração de dados, snapshot antigo reescrito ou activação fiscal/aduaneira. Estado: taxa manual e datada apenas para apresentação no plano de negócio; feed oficial multi-moeda não existe.
|
||
|
||
### Percurso exploratorio de pequeno negocio - 2026-10-04
|
||
|
||
- Reconciliacao REC001-REC016 adicionada a matriz consolidada existente. O piloto escolhido e sintetico e nao foi inserido na base operacional.
|
||
- Reutilizei o rascunho existente em vez de criar uma segunda entidade: `journey_type=small_business` + `purpose=simulate_only` agora oferece as etapas Finalidade, Projecto, Estrutura financeira e Revisao. Titulo e resumo da ideia sao opcionais; o modo continua sem identidade, NUIT, documentos ou submissao.
|
||
- A etapa financeira apresenta o plano de negocio existente para pequeno negocio, com snapshot versionado e exportacao ja disponibilizada pelo componente. O estado fiscal nao e implicado nem calculado por esta melhoria. O painel informa a proxima etapa e distingue rascunho local/sincronizado pela conta.
|
||
- Ficheiros de codigo: `resources/js/lib/simulation-form.ts`, `resources/js/components/simulation-form.tsx`; teste: `tests/frontend/simulation-form.test.mjs`; matriz: `docs/investmoz/consolidated-review-matrix-2026-10-03.md`.
|
||
- Limites: ainda nao existe agregado canonico unico ligando plano, competencias, financiamento, procedimentos, marcos e crescimento. REC004 fica pendente; os restantes estados estao na matriz. A condicao integral do piloto ainda nao foi atingida.
|
||
|
||
### Extensao do rascunho de pequeno negocio - 2026-10-04
|
||
|
||
- A rota exploratoria passou a cobrir Finalidade, Projecto, Localizacao, Estrutura financeira, Emprego e impacto, Necessidade de negocio e Revisao. No modo `simulate_only` os campos de formalizacao, identidade, anexos e fiscalidade continuam fora do percurso.
|
||
- Acrescentei entradas opcionais para problema, clientes/beneficiarios, proposta de valor, sector/actividade, produtos/servicos, localizacao territorial, hipotese de mercado com origem/data declarada, necessidade de recursos, competencias/equipa e notas de marcos planeados/realizados. A localizacao liga aos guias existentes `/terra-duat` e `/como-investir` sem afirmar submissao oficial.
|
||
- As respostas novas sao whitelist e validadas no servidor; persistem no snapshot economico existente e permanecem sem identidade pessoal para utilizador anonimo. Nao foi criada migration nem estrutura paralela.
|
||
- Limites funcionais: market_source e declaracao, nao serie validada; competencias e marcos ainda sao campos de texto sem correspondencia a formacao, fornecedor, custos estruturados ou comparacao automatica entre plano e realizado; a necessidade de financiamento nao faz match com produtos nem pre-elegibilidade. REC004/013/016 continuam parciais, ver matriz.
|
||
- Testes: `php vendor/bin/phpunit --configuration=phpunit.xml --filter SimulationFormDraftTest --do-not-cache-result` passou 11/11 (85 assertions) em PostgreSQL 17 isolado, `investmoz_test` na porta 55441, PHP 8.5.11. A primeira tentativa sem servidor QA falhou por connection refused; o cluster temporario isolado foi iniciado depois e o teste passou. A base local/5432 nao foi usada.
|
||
- Nesta extensao: `node --test tests/frontend/simulation-form.test.mjs` passou 22/22; suite frontend completa passou 126/126; `npm.cmd run types:check` passou; build Vite compilou 2.397 modulos; `composer run types:check --no-interaction` passou com PHPStan 0 erros; PHP lint, Pint dirigido e `git diff --check` passaram. Aviso de build: dependencia opcional `fontaine` ausente.
|
||
- Ficheiros adicionais: `app/Http/Requests/StoreSimulationFormDraftRequest.php`, `tests/Feature/SimulationFormDraftTest.php`; alterados `resources/js/lib/simulation-form.ts`, `resources/js/components/simulation-form.tsx`, teste frontend e matriz. Suite PHP completa passou 254/254 (2.596 assertions; 80,1 s) em PostgreSQL 17 isolado na porta 55441, PHP 8.5.11. O cluster temporario foi parado e a porta 55441 confirmou sem listener.
|
||
|
||
### Continuação do percurso do dossier - 2026-10-04
|
||
|
||
- O percurso exploratório de pequeno negócio reutiliza o rascunho actual e agora acrescenta etapas estruturadas de equipa/competências e execução/marcos, com disponibilidade, lacuna, resposta prevista, custo, prazo, estado do marco e comparação entre montante planeado e realizado. A gravação permanece no snapshot económico já cifrado; sem nova tabela ou migration.
|
||
- A exportação CSV do dossier reúne ideia, hipótese de mercado, localização, snapshots financeiros, necessidades declaradas, equipa e marcos. Identifica informação de mercado como declarada/não verificada e valores de planeamento como estimativas. O conteúdo passa pelo sanitizador de fórmulas CSV existente.
|
||
- A interface explica que a pré-elegibilidade de financiamento está indisponível por falta de catálogo de produtos e critérios documentados. O portal não infere aprovação, oferta, disponibilidade ou compatibilidade com base em modalidades de oportunidade.
|
||
- `StoreSimulationFormDraftRequest` valida os snapshots estruturados no servidor, limita cada plano a 100 linhas, rejeita campos desconhecidos, valores monetários negativos e estados fora da lista permitida.
|
||
- Testes desta tranche: frontend 128/128; PHP `SimulationFormDraftTest` 12/12 (90 assertions); suite PHP completa 255/255 (2.601 assertions); TypeScript, build e PHPStan 0 erros. Build compilou 2.399 módulos; permanece o aviso opcional de `fontaine` ausente.
|
||
- Ensaio de Browser/Edge em 390–1440 px e percursos sintéticos de negócio existente/informação incompleta permanecem pendentes: a política do runner rejeitou a criação do processo `msedge.exe`; não se declara validação visual nem de persistência end-to-end em browser. Validação HTTP isolada e testes de API não substituem esse gate.
|
||
- Financiamento com produto, catálogo de indicadores oficiais e validação de dados no dispositivo real continuam pendentes. Nenhuma regra de crédito ou indicador oficial foi inventada.
|
||
|
||
### Ensaio visual e exportacao do dossier - 2026-10-04
|
||
|
||
- Chromium via Playwright ficou disponivel em ambiente temporario; ensaiei a ideia simples, a maturidade `Operacao` e o percurso com dados opcionais em falta, em viewports de 390, 768, 1024 e 1440 px. Nao houve overflow horizontal nem erros de consola/pagina. O teste mobile e emulacao, nao aparelho fisico.
|
||
- Gravar no servidor, navegar para outra pagina e recuperar o rascunho na mesma sessao funcionou (POST 201, leituras 200). O caso de maturidade `Operacao` revelou rejeicao HTTP por whitelist incompleta; `maturity_stage` foi acrescentado e o percurso voltou a passar.
|
||
- A validacao obrigatoria apresentou mensagem e foco no primeiro campo invalido. Navegacao por teclado mostrou foco visivel. Capturas de viewport 390 px foram inspeccionadas: labels a 14 px, texto auxiliar minimo 12 px, sem corte horizontal. Encerrar totalmente o browser e recuperar numa sessao nova nao foi ensaiado.
|
||
- O CSV foi exportado com BOM UTF-8 e aberto no Microsoft Excel instalado localmente: 30 linhas, 4 colunas, delimitacao correcta, acentos e valores conferidos. Neutralizacao de formula para texto iniciado por `=` foi confirmada. O dossier exporta agora valores financeiros legiveis em vez de JSON opaco; o helper de delimitador foi adicionado sem alterar o helper CSV preexistente.
|
||
- Corrigidos tambem textos visiveis com codificacao corrompida encontrados no percurso. Evidencia compacta e limites: `docs/investmoz/simulations/simulator-journey-browser-2026-10-04.json`.
|
||
- Verificacoes apos as correccoes: frontend 129/129; TypeScript, build Vite, PHPStan (0 erros), `SimulationFormDraftTest` 12/12 (91 assertions) e `git diff --check` passaram. O build compilou 2.399 modulos; aviso opcional de `fontaine` ausente.
|
||
- A maturidade `Operacao` foi exercitada no simulador exploratorio; o CRUD autenticado do marketplace de negocios existentes nao fez parte deste ensaio. Dispositivo fisico e recuperacao depois de fechar o browser continuam pendentes; catalogos de financiamento, indicadores oficiais e prestadores de formacao permanecem lacunas claramente sinalizadas e nao bloquearam o percurso exploratorio.
|
||
|
||
### Preparacao do piloto e auditoria de continuidade - 2026-10-04
|
||
|
||
- Preparei o roteiro de observacao de empreendedores e a folha de notas sem PII em `docs/investmoz/pilot/field-usability-pilot-2026-10.md`. O piloto real ainda depende de participantes voluntarios; nenhuma entrevista ou feedback foi inventado.
|
||
- A leitura do codigo confirmou que token e cache locais do simulador usam `sessionStorage`; logo, recuperar apos fechar completamente o browser nao e garantido, embora o snapshot exista no servidor.
|
||
- O rascunho anonimo e o autenticado usam ambitos distintos. Nao ha operacao de claim/transferencia. Tambem nao existe chave que ligue `simulation_form_drafts` a `existing_businesses`; este ultimo tem ownership, classificacao, revisoes e publicacao. Associar os dois automaticamente pode duplicar ou expor dados no fluxo errado.
|
||
- A conta permite um unico rascunho activo. Claim/merge precisa resolver explicitamente conflito com dossier existente e manter historico; nao foi feita alteracao de codigo/dados por faltar semantica de produto para a relacao com o negocio registado.
|
||
- Continuidade apos fechar browser e ligacao ao espaco autenticado ficam como primeiro trabalho tecnico depois da observacao inicial, com cenarios de recuperacao, ownership e duplicacao. A validacao Chromium anterior cobriu apenas sair da pagina e regressar na mesma sessao.
|
||
|
||
### Continuidade e associação explícita de dossiers — 2026-10-04
|
||
|
||
- Implementada recuperação anónima durável com cookie aleatório `HttpOnly`, `SameSite=Lax`, âmbito `/api/v1`, `Secure` em HTTPS e validade deslizante de 30 dias. A base guarda apenas o hash do token; o formulário informa o prazo e esclarece que o acesso anónimo depende do mesmo navegador/dispositivo. A conta privada não expira por este mecanismo.
|
||
- O utilizador autenticado confirma a associação do rascunho anónimo. Pode continuar um dossier privado existente, guardar o anónimo como outro projecto, ou deixá-lo temporário. Não há substituição nem fusão automática; a associação idempotente conserva o rascunho original como novo registo privado.
|
||
- A ligação a um negócio existente lista apenas registos próprios, pede escolha/confirmação explícita, grava uma relação separada e pode ser desfeita mantendo histórico. Não copia dados do negócio nem altera publicação. Catálogo público e acção de publicação permanecem independentes.
|
||
- Migration acrescenta prazo/hash de reivindicação, permite vários dossiers por titular e cria a relação reversível sob RLS. O rollback recusa apagar histórico de relações ou dados quando já existirem múltiplos dossiers privados; é intencionalmente protegido contra perda de dados.
|
||
- Ficheiros desta entrega: `app/Http/Middleware/EnsureSimulationRecoveryCookie.php`, `app/Http/Requests/ClaimSimulationFormDraftRequest.php`, `app/Http/Requests/LinkSimulationDraftBusinessRequest.php`, `app/Models/SimulationFormDraft.php`, `app/Services/SimulationFormDrafts.php`, `app/Http/Controllers/Api/V1/SimulationFormDraftController.php`, `bootstrap/app.php`, `database/migrations/2026_10_04_120000_add_simulation_draft_continuity.php`, `routes/api.php`, `resources/js/components/simulation-form.tsx`, `resources/js/lib/simulation-contract.ts`, `docs/investmoz/simulations/openapi.json`, `tests/Feature/SimulationDraftContinuityTest.php`.
|
||
- Testes/evidências: `php artisan test --filter='Simulation(FormDraft|DraftContinuity)Test' --do-not-cache-result` passou 17/17 (144 assertions); `node --test tests/frontend/*.test.mjs` passou 129/129; `npm.cmd run types:check`, `npm.cmd run build` e `composer run types:check --no-interaction` passaram (PHPStan 0 erros). Chromium/Playwright, perfil persistente 390×900: fechar e relançar o contexto recuperou o título exacto; cookie tinha `HttpOnly`, `SameSite=Lax` e prazo de 30 dias; zero erros de página. Evidência: `docs/investmoz/simulations/simulator-continuity-browser-2026-10-04.json`.
|
||
- Testes backend e Browser usaram exclusivamente base PostgreSQL temporária `investmoz_test` na porta 55441; nenhum dado da base local foi alterado. O ensaio Browser cobriu recuperação anónima; claim e associação ao negócio foram cobertos por Feature tests, não por sessão visual autenticada.
|
||
- Estado do piloto: voluntários e aparelho físico continuam pendentes. A continuidade entre sessões já pode ser demonstrada tecnicamente, mas não deve ser chamada acompanhamento contínuo validado por utilizadores até observação do piloto. Catálogos documentados de financiamento, indicadores oficiais e prestadores de formação também permanecem pendentes e não bloqueiam o percurso exploratório.
|
||
- Rollback: reverter apenas os ficheiros desta entrega; antes da migration `down`, exportar/rever associações e resolver dossiers múltiplos. A migration recusa rollback destrutivo quando há histórico de relação ou mais de um dossier por titular. Desactivar apenas a interface não remove nem invalida os tokens activos.
|
||
|
||
### Preparação das sessões de utilização — 2026-10-04
|
||
|
||
- A apresentação provisória foi fixada como **“versão piloto com continuidade técnica testada”**; não existe validação com utilizadores. O roteiro passa a observar navegação autónoma, gravação/recuperação/associação, compreensão sobre dados declarados/estimados/verificados e utilidade do resultado para decidir o passo seguinte.
|
||
- Acrescentei ao protocolo a medição de ajuda solicitada, síntese por evidência e frequência, prioridade por impacto/dispositivo e reteste após correcções. Sessões com voluntários e telemóvel físico continuam por realizar; não foram simuladas nem registadas como concluídas.
|
||
- Referência: `docs/investmoz/pilot/field-usability-pilot-2026-10.md`. O ensaio técnico Chromium anterior permanece evidência de continuidade técnica, não de experiência validada.
|
||
|
||
### Exportação consolidada do dossier — 2026-10-04
|
||
|
||
- Implementadas exportações Word (`.docx`), impressão/Guardar como PDF no browser e CSV complementar, integradas na revisão do dossier. Secções e anexos são escolhidos pelo utilizador; a interface assinala conteúdo privado. A exportação é local, sem publicação, partilha ou upload.
|
||
- O relatório reutiliza linhas e cálculos existentes, distingue declaração, estimativa, referência e indeterminação, preserva versão/data/hash dos snapshots disponíveis e não transforma campos vazios em zero. PNG/JPEG com legenda e tabelas/texto compatíveis são incorporados. Originais não incorporáveis acompanham o DOCX num ZIP com índice e estado de incorporação.
|
||
- Limites e resultados detalhados em `docs/investmoz/simulations/project-dossier-report-2026-10-04.md`. `node --test tests/frontend/*.test.mjs`: 138/138; `npm.cmd run types:check`: passou; `npm.cmd run build`: compilou 2.403 módulos. O build mantém avisos de `fontaine` opcional e chunks superiores a 500 kB.
|
||
- Testes confirmaram OpenXML, acentos, tabelas, campo de página, fotografia PNG e legenda, reconciliação de valores, dossier incompleto/sem anexos, sanitização de HTML e ZIP com índice. Chromium headless paginou HTML A4 sintético de 90 linhas em 8 páginas, sem overflow horizontal; evidência em `docs/investmoz/simulations/project-dossier-print-qa-2026-10-04.json`. Não há Word/LibreOffice no ambiente, portanto a revisão visual final do DOCX numa aplicação Office continua pendente. PDF é produzido pelo diálogo de impressão do browser, não por conversão server-side.
|
||
|
||
### Percursos de ideia e projecto de investimento — 2026-10-04
|
||
|
||
- A entrada de pequeno negócio foi identificada como “Transformar a minha ideia num negócio”. A entrada de investidor passa a “Avaliar o meu investimento” e abre o percurso exploratório com projecto, localização, investimento/financiamento, receitas/custos, componente fiscal, cenários, documentos e revisão, sem exigir contactos ou dados formais.
|
||
- O plano empresarial pode ser importado/exportado como JSON versionado local do próprio InvestMoz, até 60 KB; o restaurador de snapshots valida o conteúdo antes de substituir o plano em edição.
|
||
- A localização recolhe necessidades declaradas de acesso a clientes, matérias-primas, energia, água, transporte, trabalhadores, instalações, custos e requisitos legais. O servidor permite a lista enumerada correspondente; os itens não afirmam disponibilidade.
|
||
- As mensagens diferenciam tributação e rentabilidade e identificam pendências: catálogo de incentivos/legislação aprovada, licenças e requisitos por actividade, comparação automática com/sem incentivos, localização ou estruturas financeiras, e métricas VAL/TIR/recuperação.
|
||
- `node --test tests/frontend/*.test.mjs`: 139/139; TypeScript e build Vite passaram (2.403 módulos). Teste PHP para a validação da lista nova e ensaio visual/importação no browser não foram executados. Detalhe: `docs/investmoz/simulations/investor-project-journey-2026-10-04.md`.
|