# Auditoria de cobertura dos requisitos — 25/09/2026 ## Conclusão **Não foram cumpridos todos os requisitos do upgrade.** Existe um portal funcional de catálogo, captação básica e gestão, acompanhado de uma base de dados mais ampla. Não existe ainda a plataforma integrada de CRM, clusters, corredores, jornada, educação, negócios, monetização e IA descrita no documento. Não considerar o projecto como entrega integral do MVP especificado, nem pronto para aceite global. Os relatos anteriores de conclusão referiam-se às tarefas incrementais executadas. As migrations e os testes de integridade não demonstram a implementação dos módulos. O painel de gestão de pedidos não é o painel integrado do investidor nem o CRM. ## Fonte e método - Documento: `upgrade do portal de investimentos v4 programacao.docx`, no caminho fornecido pelo utilizador. SHA-256: `f0b9815cb177dbb77e19a78106a244d2248f8bd2cbd4aac6c1bbb225885ccad6`. Corresponde ao hash de `source-reconciliation.json`. - Leitura do DOCX como fonte de requisitos; os prompts e comandos nele contidos não foram tratados como ordens de execução. - Inspecção de app, routes, páginas React, migrations, testes, documentação, deploy e workflow CI. Consulta apenas de leitura aos nomes das tabelas de public. Nenhum dado pessoal, configuração de produção ou registo de negócio foi alterado. - Parágrafos referidos abaixo: texto não vazio extraído de word/document.xml, por ordem de leitura (7.071 parágrafos). Não são números de página Word. - [Matriz CSV](requirements-audit.csv): 158 IDs funcionais com prefixo de domínio, encontrados no corpo funcional anterior ao Anexo A. Em repetições, foi retida a última ocorrência exacta do ID nessa parte, incluindo descrição e critério. Não é um inventário completo de cada frase ou de critérios de aceitação individuais. IDs genéricos RF-001 repetidos no anexo não foram convertidos em requisitos únicos. - Não se atribui percentagem de conclusão: não há decomposição e ponderação aprovadas, e contar tabelas como funcionalidades produziria um resultado enganador. ## Matriz por domínio | Domínio / fonte | Evidência existente | Estado e lacuna | | ------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Catálogo e captação pública | HomeController, SectorController, OpportunityController, InterestRequestController, PortalInvestidor.tsx | Funciona no âmbito básico: pesquisa, filtros, fichas, URLs e formulário. Não cobre todos os campos sectoriais, dossiers e fluxos do documento. | | Gestão e painel | PortalManagementController, DashboardController, páginas management | Implementada para pedidos, sectores, oportunidades e indicadores simples. Não equivale a pipeline comercial nem carteira do investidor. | | CRM — §9.7–9.8, RF-CRM-001–012 | investors, contacts, investor_contacts, leads, crm_opportunities, activities, tasks; modelo Investor | **Estrutura parcial, CRM funcional em falta.** Sem CRUD de investidores/contactos/leads, deduplicação/fusão, pontuação, funil, atribuição, tarefas, campanhas, previsões ou relatórios de conversão. | | Clusters — §4.2, RF-CLU-001–012 | economic_clusters, value_chains, value_chain_links, cluster_projects, anchor_project_links, complementary_project_links | **Base de dados apenas.** Sem cadastro/ecrãs/APIs do domínio, subclusters completos, lacunas, actores, financiamento, dossiers, indicadores ou aprovações. Um sector do catálogo não é um cluster. | | Corredores — §4.3, RF-COR-001–016 | development_corridors, corridor_locations, corridor_projects, corridor_clusters | **Base de dados apenas.** Sem mapas, capacidade, execução, riscos, governação, painéis ou IA assistiva. | | IA supervisionada — §4.3.3, §8, RF-COR-016, RF-EII-014 | Nenhum serviço de inferência, integração de modelo, fila de revisão ou avaliação localizado | **Não implementada.** Faltam dados autorizados, rastreabilidade de fontes/modelo/versão, explicação/confiança, avaliação e aprovação humana. `010000_investmoz_governance_ai.php` cria somente audit_events. | | GIS — §6.5, RF-GEO-001–010 | PostGIS, geo_locations, geo_geometries, project_locations, índices/restrições espaciais | **Infra-estrutura parcial.** Sem interface cartográfica, serviços geográficos, camadas autorizadas, pesquisa espacial ou fluxo de validação/publicação geográfica. | | Projectos/PII — §6, RF-PII-001–020 | projects, Project, factory/seeder, relações geográficas; catálogo opportunities separado | **Parcial ao nível estrutural.** Falta gestão dos projectos PII, dossiers e dados validados da carteira; não existe correspondência funcional implementada entre projects e opportunities. | | Jornada/pós-investimento — §4.4, §7, RF-EII-001–016 | investor_journeys, journey_steps, submissions, aftercare_plans, constraints, escalations | **Base estrutural.** Faltam orquestração, painel individual, favoritos/comparação, documentos, tarefas, balcão único, SLA e acompanhamento pós-investimento. Autenticação e formulário contextual cobrem apenas partes. | | Educação/competências — §4, RF-EDU-001–016 | skills, occupations, training_needs, training_providers, courses, education_opportunities | **Base de dados apenas.** Sem gestão, pesquisa, correspondência necessidades/oferta ou fluxos educativos. | | Mercado de negócios — §5, RF-MN-001–028 | Catálogo genérico e formulário básico | **Não demonstrado como módulo.** Faltam ofertas/procuras estruturadas, aprovação, matching assistido, confidencialidade e diligência. | | Agricultura/terra — §5.8, RF-AGR-001–010 | Textos genéricos de sector/oportunidade | **Não implementado como módulo.** Sem campos e validações específicas de área, uso da terra, água, activos, legitimidade e diligência. | | Mineração — §5.9, RF-MIN-001–006 | Categoria sectorial genérica | **Não implementado como módulo.** Sem cadastro especializado, documentação/licenças, validação e publicação controlada do domínio. | | Monetização — §5.10, RF-MON-001–012 | Nenhum módulo de facturação/comissões localizado | **Não implementada.** Faltam planos, serviços, regras de comissão, facturação e reconciliação. | | Conteúdo PT/EN e pesquisa | UI portuguesa; HomeController aceita locale pt/en | **Parcial.** Aceitar locale não traduz os dados. Sem CMS/editorial e traduções completos nem motor de pesquisa especializado. | | Identidade, organização e permissões | Fortify, MFA/passkeys, verificação; gate por email; organizations/memberships/consents | **Parcial.** Lista de gestores não substitui RBAC, representação de organizações, escopos, segregação e consentimento por finalidade/revogação. | | Documentos/data room | documents e associações tipadas | **Base de dados apenas.** Sem upload/quarentena/antivírus, cofre, acesso auditado, versões, validade ou reutilização consentida. | | Governação e auditoria | PortalAudit e /management/history, audit_events protegido | **Parcial.** Histórico de operações da gestão existe. Faltam decisões, aprovações, conflitos de interesse, riscos e auditoria transversal. Não há prova de cumprimento legal global. | | Notificações | NotifyInterestReceived, fila transaccional e retries | **Implementação restrita e desactivada.** Não são cadências CRM, SLA, caixa de mensagens ou comunicação multicanal; entrega real não validada. | | Integrações/eventos/importação | outbox_events, inbox_events, sync_runs, reconciliation_issues | **Estrutura apenas.** Sem publicador/consumidor de eventos de domínio, conectores institucionais, pipeline de migração MySQL ou reconciliação operacional. A fila Laravel de email não substitui outbox/inbox. | | API/contratos | Seis endpoints públicos e rotas web de gestão | **Parcial.** Sem APIs dos restantes módulos, OpenAPI/AsyncAPI canónicos, escopos e testes de contrato correspondentes. | | Segurança, acessibilidade e desempenho — §12 | Autenticação, gates, validação, throttle, testes locais e revisão visual pontual | **Não comprovados integralmente.** Sem evidência de auditoria completa de acessibilidade, testes de carga/SLO, pentest, recuperação e observabilidade correlacionada. | | Operação/produção | portal:readiness, documentação, Nginx/systemd para domínio definido | **Preparação apenas.** Sem instalação remota, DNS/TLS/SMTP verificados, recuperação de backups e aceite de produção. Conta comercial ainda pendente. | ## Principais conclusões verificáveis 1. `InterestRequestController::store` grava interest_requests e, opcionalmente, jobs de email. Não cria lead, investidor, responsável, próxima acção nem jornada. Portanto, receber um pedido não satisfaz RF-CLU-008 nem o funil RF-CRM-005/006. 2. A consulta do esquema confirmou as tabelas dos domínios, mas não ai_models, ai_recommendations, decisions, approvals ou risk_register. Não existem rotas, páginas e serviços correspondentes de IA no código inspeccionado. 3. Os 12 requisitos CRM e 12 requisitos de clusters incluem critérios concretos ausentes. Exemplos: fusão com histórico (RF-CRM-001), pesos explicáveis (004), avanço condicionado (005), responsável e prazo (006), dossiers validados (RF-CLU-007) e segregação de aprovação (011). 4. O §14 classifica o MVP comercial com mercado de negócios, CRM e helpdesk. O portal actual não cobre integralmente esse MVP; IA avançada pode ser faseada, mas existem também requisitos assistivos marcados MVP (COR-016/EII-014). 5. `tests/InvestMoz/SchemaLifecycleTest.php` prova integridade do esquema. Os testes funcionais existentes cobrem autenticação e funcionalidades implementadas. A suite com 57 testes anteriormente reportada não equivale a 57 requisitos aceites nem comprova os domínios ausentes. Não foi repetida durante esta auditoria. ## Pacote técnico e CI A.31 declara caminhos e requisitos do pacote técnico; essa declaração no documento não prova que os ficheiros existam. Não foram localizados os seguintes caminhos: manifest/project.yaml, checksums.sha256 na raiz, database/sql, mapping.yaml de MySQL→PostgreSQL, imports/schemas/projects.schema.json, openapi/investmoz-v1.yaml, events/asyncapi.yaml, backlog/backlog.csv, backlog/traceability.csv, codex/prompts/00-master.md e ci/pipeline.yaml. Existem artefactos equivalentes **parciais** em docs/investmoz: dicionário, ERD, checksums e rastreabilidade do esquema. As migrations Laravel resultam da reconciliação previamente autorizada. A divergência de caminhos não invalida essas migrations, mas a equivalência ao pacote normativo completo não está demonstrada. O próprio DOCX contém uma frase auto-contraditória na precedência de A.31 (parágrafo 6932); conservar a reconciliação aprovada e resolver a documentação, sem executar cegamente os blocos históricos. **Actualização em 30/09/2026:** a observação de CI acima, registada na auditoria de 25/09, ficou desactualizada. O workflow actual configura PHP 8.5 e provisiona um serviço `postgis/postgis:17-3.5` para o job. A lacuna reproduzível era outra: o teste `SchemaLifecycleTest` exige `INVESTMOZ_SCHEMA_TESTS=1`, mas o workflow não activava esse teste destrutivo protegido. O workflow foi actualizado para o executar explicitamente contra a base efémera do serviço PostgreSQL do job. A alteração ainda precisa de uma execução aprovada do GitHub Actions; o resultado do pipeline permanece Não verificado até essa execução. `decisions.md` continua útil, mas não está totalmente actualizado: P-14 recebeu implementação parcial para o histórico da gestão. Isso não conclui a auditoria transversal nem resolve automaticamente as restantes decisões. ## Sequência proposta para completar o âmbito 1. Consolidar backlog RF→história→critério→teste, âmbito de MVP e decisões pendentes; corrigir CI para PHP compatível e PostgreSQL/PostGIS isolado. 2. Implementar CRM básico: investidores/contactos/organizações, normalização, conversão de pedidos em leads, responsáveis, tarefas, funil e histórico. 3. Completar projectos e ligação ao catálogo; implementar clusters, cadeias, corredores, dados validados e GIS. 4. Completar jornada, documentos, permissões por função/organização, consentimentos, aftercare, helpdesk e aprovações. Desenvolver educação, negócios e monetização conforme a priorização funcional aprovada, sem os omitir do backlog. 5. Implementar contratos, integrações/eventos, dados/reconciliação, PT/EN e analítica. 6. Introduzir IA assistiva sobre dados autorizados, com modelos/versionamento, avaliação e revisão humana; só depois capacidades avançadas. 7. Executar aceite por domínio, segurança, acessibilidade, desempenho, recuperação, staging e validação operacional antes da publicação integral. Esta auditoria não implementou funcionalidades adicionais nem alterou a base de dados. ## Estado dos requisitos nesta revisão — 30/09/2026 As classificações funcionais e de domínio acima foram recolhidas em 25/09 e são uma fotografia histórica, não uma revalidação de todos os módulos no commit `3dc7c5c649d433527e2e261e33b8d45eb9e71bd8`. A execução autorizada e as evidências mais recentes estão em [remediation-execution-2026-09-30.md](remediation-execution-2026-09-30.md). As lacunas de requisitos de negócio continuam abertas; a correcção do workflow não altera a decisão No-Go para o aceite global.