Vamos criar uma versão do portal do investidor 
a partir do que está a ser desenvolvido actualmente. (Upgrade), 
onde:
 
T
odo o fluxo é gerido por inteligência artificial, 
onde deve existir  o controlo do fluxo, associado ao CRM
Criar um CRM para apoio e seguimento das actividades
 desde a manifestação de interesse até 
a
 conclusão 
O conteúdo e os fluxos de trabalho do portal devem reflectir rigorosamente o quadro legal vigente em Moçambique
, 
com a Lei de Investimentos Privados
, 
lei de terras, 
leis e decretos de licenciamento de actividades económicas (Bau, Ministérios, institutos públicos Banco de Moçambique
,
 entre outros) 
Lei de Investimentos e Regulamentação:
Alinhamento directo com as garantias legais de protecção da propriedade privada e 
de não 
discriminação entre investidores nacionais e estrangeiros.
Clareza 
sobre 
os limites mínimos de capital para elegibilidade a incentivos específicos do regime de investimento privado.
Facilitação Cambial e Repatriamento:
Instruções claras sobre a obrigatoriedade de registo do capital de entrada junto do Banco de Moçambique
,
 para assegurar o direito 
à
 transferência de lucros, dividendos e capital investido de volta ao país de origem.
Incentivos Fiscais e Aduaneiros:
Incorporação das reduções e isenções previstas (ex
.
: redução d
as
 taxas de IRPC para 
a 
agricultura e
 os
 transportes, isenções de direitos aduaneiros para bens de equipamento da Classe K).
Simplificação de Processos
 no licenciamento de empresas
:
Mecanismo de 
licenciamento simplificado, 
Mera Comunicação Prévia para actividades de baixo risco económico, eliminando burocracias e reduzindo prazos de resposta das entidades licenciadoras.
Deve ter 
Alinhamento jurídico e regulatório
Quadro Legal Acessível:
 repositório claro de documentos jurídicos essenciais para descarregar, como a 
Nova Lei de Investimentos Privados
, o regulamento das Zonas Económicas Especiais (ZEE), e o guia de 
Regulamentação Cambial do Banco de Moçambique
 para repatriamento de capitais.
Guias de processos passo a passo:
 deve existir uma secção dedicada que explique, de forma visual e textual, a rota do investidor: constituição d
a
 empresa, obtenção de NUIT, registo na APIEX, licenciamento simplificado
,
 quando aplicável, abertura de conta bancária e registo cambial.
Recursos multilingues e suporte
Idioma:
 Sendo Moçambique um polo de 
atração
 de investimento internacional, o portal necessita obrigatoriamente de alternância fluida entre 
Português
 e 
i
nglês
 (e idealmente francês ou Mandarim).
Canais de Suporte Directo:
 Além do contacto genérico por e-mail
 ou 
telefone, seria muito vantajoso ter um sistema de agendamento de reuniões virtuais com assistentes da APIEX ou um 
helpdesk
 
dedi
cado 
a
o investidor.
Nota de validação:
 Todas as referências a benefícios fiscais, taxas reduzidas, incentivos aduaneiros, repatriamento de capitais e licenciamento deve
m
 ser confirmadas com a legislação vigente e com as entidades competentes antes da publicação final no portal. O portal deve apresentar informaç
ões
 orientadora
s
, mas 
deve 
evitar substituir parecer jurídico, decisão administrativa ou confirmação oficial das autoridades
.
A página principal deve incluir uma secção curta com cinco passos para novos investidores: 
identificar o sector de interesse, 
consultar requisitos legais e incentivos aplicáveis, 
preparar documentos básicos, 
solicitar orientação ou reunião de facilitação 
integra
r 
funcionalidades 
transacionais
, monitoria de investimentos e ligação operacional com sistemas públicos, sempre mediante validação institucional
E
 iniciar o processo de registo ou 
de 
submissão junto da entidade competente.
Os endpoints indicados são exemplos conceptuais 
de
 especificação funcional e devem ser confirmados com cada entidade competente antes de qualquer implementação técnica ou
 de
 publicação como integração oficial.
Entidade
s
 Governamenta
is
APIEX
: 
Submissão directa do Formulário de Pedido de Autorização de Investimento Privado.
Autoridade Tributária (AT)
: 
Validação automática do NUIT e emissão do comprovativo de enquadramento nos incentivos do Código dos Benefícios Fiscais.
Banco de Moçambique (BM)
: 
Registo preliminar de intenção de entrada de capital estrangeiro para 
garantir
 
o
 repatriamento de lucros.
BAU:
 licenciamento de empresa
 
www
.
 
https://infopublica.tempo.co.mz/
,
Compra e venda de terrenos ou investimentos agricolas
Compra e venda de investimentos mineiros 
especificar o local onde o investimento irá ocorrer
D
eve exist
ir
 uma componente de monetização e controlo de comissões
 
Gerar casos de uso e histórias de utilizador
Criar uma matriz de rastreabilidade dos requisitos
Rever os requisitos para priorizar o MVP
Apresentar a versão final consolidada do documento
, 
Rever e melhorar as fichas dos 15 projectos âncora
, 
Transformar o plano de campanhas num cronograma operacional
Criar a tabela consolidada dos 15 projectos
Adicionar campos para novos projectos públicos e privados
Preparar a matriz de validação institucional das localizações
Com base na informação disponibilizada no site 
https://investemoz.tempo.co.mz/
 
(por que investir em Moçambique, Actividades económicas, oportunidades de negócios, áreas de investimento, reguladores),
 acrescente e torne mais rico o potencial de atrair investimentos.
Apresentar a tabela completa dos 12 RF-MONCriar um diagrama visual do fluxo financeiroGerar a matriz MIN com campos, validações e documentos
Apresentar um relatório das inconsistências corrigidasVerificar o índice, a numeração e as referências cruzadasValidar a versão final contra uma lista de controlo
Trazer a ideia de promover negócios com base em clusters usando o mesmo principio do rwanda (anexar o documento
 rwanda)
Gerar um relatório das alterações finaisVerificar referências às secções RF-AGR, RF-MIN e RF-MONPreparar uma versão executiva consolidada do documento
O modelo de investimentos baseado em clusters pode ser aplicado ao InvestMoz e seria uma evolução importante do portal.
 O documento do Rwanda demonstra que o sucesso não resultou apenas da publicação de projectos isolados, mas da organização coordenada de 
empresas, infra-estruturas, financiamento, instituições, competências, fornecedores, mercados e políticas públicas
 em torno de sectores prioritários. 
[Rwanda Com...Porter_OTF | PowerPoint]
1. Como aplicar o modelo de clusters no InvestMoz
O portal deve permitir três formas complementares de navegação:
Por oportunidade individual
projecto;
negócio existente;
procura de capital;
aquisição;
concessão;
fornecimento.
Por território
província;
distrito;
corredor;
parque industrial;
ZEE;
bacia agrícola;
zona turística.
Por cluster económico
visualizar toda a cadeia de valor;
identificar lacunas;
localizar projectos complementares;
encontrar fornecedores, compradores, financiadores e reguladores;
perceber onde o investimento produz maior impacto.
Assim, o portal deixaria de apresentar apenas uma lista de projectos e passaria a responder:
Onde investir?
Em que parte da cadeia de valor?
Que infra-estruturas já existem?
Que fornecedores e compradores estão disponíveis?
Que investimentos complementares ainda são necessários?
Que incentivos, licenças e riscos existem?
Quem deve participar no projecto?
2. Clusters recomendados para o portal
Cluster
Projectos e oportunidades relacionadas
Lacunas que o portal deve evidenciar
Agro-indústria e segurança alimentar
Arroz, regadio do Limpopo, bacia do Rio Maputo, armazenagem, processamento, logística e comercialização
Irrigação, sementes, mecanização, frio, silos, embalagem, certificação, financiamento e compradores
Mineração e transformação mineral
Exploração, processamento, laboratórios, certificação, logística, equipamentos e reabilitação
Conhecimento geológico, processamento local, energia, financiamento, tecnologia, competências e mercado
Energia e industrialização
Mphanda Nkuwa, Namialo–Metoro, parques industriais e grandes consumidores
Transmissão, subestações, geração complementar, manutenção, equipamentos e compra de energia
Logística e corredores
Nacala, Macuse–Moatize, Norte–Sul, portos, terminais e armazenagem
Última milha, terminais, intermodalidade, plataformas logísticas, digitalização e carga contratual
Turismo costeiro e economia azul
Vilanculos, Bazaruto, Crusse Jamali, hotelaria, marinas e aviação
Alojamento, formação, transporte, água, energia, serviços digitais, conservação e experiências locais
Têxtil, vestuário e algodão
Parque têxtil, produção de algodão, fiação, tecelagem, confecção e exportação
Qualidade, equipamentos, formação, certificação, logística, compradores e marcas
Tecnologia e serviços digitais
Fintech, govtech, centros de dados, formação, incubação e serviços empresariais
Capital de risco, competências, conectividade, investigação, clientes e internacionalização
Financiamento do investimento
Bancos, DFI, fundos climáticos, garantias, venture capital e crédito sectorial
Colateral, preparação de projectos, planos de negócio, instrumentos por fase e assistência técnica
3. Estrutura de uma página de cluster
Cada cluster deverá possuir uma página própria com:
visão e objectivos;
mapa dos territórios com maior potencial;
cadeia de valor;
empresas âncora;
projectos públicos e privados;
oportunidades complementares;
fornecedores locais;
compradores e mercados;
infra-estruturas disponíveis;
necessidades de financiamento;
competências e formação;
reguladores e licenças;
riscos e constrangimentos;
indicadores de desempenho;
plano de acção;
entidade coordenadora;
chamada para manifestação de interesse.
4. Funcionalidades tecnológicas necessárias
Inteligência territorial
O sistema deve cruzar:
localização dos projectos;
energia;
água;
transportes;
telecomunicações;
população activa;
fornecedores;
matérias-primas;
mercados;
riscos climáticos;
áreas protegidas;
licenças;
incentivos.
O investidor poderá comparar locais e receber uma recomendação explicável sobre onde o investimento apresenta melhores condições.
Motor de correspondência por cluster
O CRM deve relacionar automaticamente:
investidor;
projecto;
localização;
instrumento financeiro;
fornecedor;
comprador;
promotor;
regulador;
necessidade da cadeia de valor.
Exemplo: um investidor interessado em processamento de arroz poderá receber oportunidades de produção, regadio, silos, embalagem, transporte, energia e compra de produção na mesma região.
Índice de prontidão do cluster
Cada cluster deve apresentar uma avaliação de:
disponibilidade de projectos;
infra-estruturas;
licenciamento;
capacidade institucional;
fornecedores;
competências;
acesso a financiamento;
acesso a mercados;
riscos;
coordenação entre actores.
Gestão de programas
O documento do Rwanda mostra que cada cluster foi tratado como um programa com objectivos, acções, responsáveis, orçamento e acompanhamento. 
[Rwanda Com...Porter_OTF | PowerPoint]
O InvestMoz deverá permitir:
plano de acção por cluster;
programas e iniciativas;
instituição responsável;
parceiros;
orçamento estimado;
prazo;
indicador;
estado;
dependências;
constrangimentos;
decisão necessária.
5. Modelo de negócio
O modelo de clusters também melhora a monetização do portal:
dossiers sectoriais premium;
estudos de localização;
preparação de projectos;
missões empresariais;
eventos por cluster;
serviços de correspondência;
publicidade sectorial;
subscrições;
preparação de fornecedores;
assistência pós-investimento;
comissão de sucesso, quando juridicamente admissível.
A monetização deve incidir sobre 
serviços claramente contratados
, e não sobre o simples acesso à informação pública.
6. Governação recomendada
Cada cluster deverá possuir:
coordenador;
conselho público-privado;
entidades reguladoras;
empresas âncora;
instituições financeiras;
associações empresariais;
universidades e centros de formação;
parceiros de desenvolvimento;
equipa técnica da Tempo.
O portal funcionaria como plataforma de informação, coordenação, captação e monitor
amento
, mas a validação de políticas, licenças e decisões permaneceria com as entidades competentes.
7. Principal lição do Rwanda
A principal lição do documento não é apenas “criar clusters”. É adoptar um ciclo contínuo:
compreender o mercado;
consultar empresas e compradores;
identificar constrangimentos;
seleccionar sectores prioritários;
definir visão e metas;
criar projectos complementares;
atribuir responsáveis e orçamento;
apoiar empresas;
promover o cluster internacionalmente;
medir resultados e corrigir a estratégia.
Portanto, 
o modelo é aplicável e deve ser incorporado no InvestMoz como uma camada transversal de inteligência de investimento
. Os 15 projectos âncora já existentes podem funcionar como pontos de partida, mas devem ser ligados a cadeias de valor, fornecedores, financiamento, competências, infra-estruturas e mercados para orientar os investidores para os locais e actividades onde o investimento faz mais sentido.
Foram acrescentados:
16 requisitos funcionais RF-CLU-001 a RF-CLU-016
, com critérios de aceitação e prioridades MVP, Fase 2 e Fase 3;
matriz de priorização com critérios ponderados: 
alinhamento com o PII;
procura de investidores;
emprego e exportação;
maturidade dos projectos;
infra-estruturas e território;
conteúdo local;
capacidade institucional;
risco de execução;
priorização inicial dos clusters: 
agro-indústria e segurança alimentar;
energia e industrialização;
logística, corredores e exportação;
mineração e transformação mineral;
turismo costeiro e economia azul;
têxtil, vestuário e algodão;
tecnologia e serviços digitais;
financiamento do investimento como cluster transversal;
definição do 
MVP
, incluindo cadastro, páginas públicas, cadeias de valor, relações, formulários de captação, pesquisa, CRM, dashboard e administração;
separação clara do que ficará para as Fases 2 e 3;
indicadores de: 
prontidão;
carteira;
captação;
conversão;
financiamento;
conteúdo local;
constrangimentos;
qualidade dos dados;
impacto;
modelo de governação com: 
Comité Estratégico de Clusters;
conselhos público-privados;
coordenadores;
tutelas e reguladores;
equipas da Tempo;
secretariado de dados;
Jurídico, Conformidade e Finanças;
regras de decisão, segregação de funções, controlo de versões, conflitos de interesse e validação institucional.
O índice automático foi actualizado e o documento passou de 
80 para 86 páginas
.
Mostrar a matriz completa com notas por cluster
 
Detalhar os critérios Go/No-Go do MVP
 
Transformar o roadmap num plano de execução com responsáveis
Apresentar a matriz de rastreabilidade completa
 
Validar os critérios de aceitação do MVP
 
Rever a coerência das referências cruzadas
Conclusão
O desenho actual é suficientemente sólido para avançar para a 
arquitectura técnica detalhada e preparação do MVP
. Contudo, antes do desenvolvimento, devem ser concluídos cinco elementos críticos:
modelo físico de dados integrado;
OpenAPI para clusters, corredores, projectos e GIS;
backlog único com histórias e testes;
RACI e acordos de governação;
plano integrado de dados, migração, segurança, IA e operação.
Sem estes elementos, o conceito continua correcto, mas a implementação poderá ficar fragmentada entre portal, CRM, mapas e inteligência artificial.
Criar o modelo físico de dados integrado
Definir o backlog único com histórias e testes
Consolidar o plano integrado de implementação
Avaliação por componente
Componente
Estado no desenho actual
Observação
Promoção
Bem contemplada
O portal já prevê conteúdos “Porquê investir”, perfis sectoriais, clusters, corredores, projectos âncora, campanhas, dossiers, eventos e chamadas para manifestação de interesse.
Transacção assistida
Bem contemplada
Existem formulários, qualificação, correspondência, autorização bilateral, sala segura, diligência, negociação, CRM, facturação e controlo de comissões. A Tempo está correctamente posicionada como facilitadora.
Identidade digital
Parcialmente contemplada
O documento prevê verificação de utilizadores, organizações, representantes, autenticação multifactor e assinatura electrónica. Faltam requisitos funcionais próprios, modelo de dados, APIs, níveis de garantia de identidade e integração com provedores de assinatura.
Interoperabilidade
Bem contemplada tecnicamente
A arquitectura inclui OpenAPI 3.1, OAuth 2.0, webhooks, eventos, idempotência, APIs, integração com CRM, GIS, campanhas, financiamento e entidades externas. A execução dependerá de acordos institucionais e disponibilidade dos sistemas parceiros.
Acompanhamento pós-investimento
Parcialmente contemplado
A secção 5.5 cobre constrangimentos, reinvestimento, expansão, fornecedores e novos projectos. Contudo, falta um módulo técnico completo com estados, dados, SLA, APIs, indicadores e backlog próprios.
Inteligência de mercado
Bem contemplada
O desenho inclui actividades económicas, áreas de investimento, clusters, corredores, cadeias de valor, inteligência territorial, indicadores, CRM, IA supervisionada, monitoria de riscos e recomendação de oportunidades.
Experiência única
Parcialmente contemplada
Os componentes existem, mas continuam distribuídos entre portal, CRM, balcão único, clusters, corredores, GIS, sala segura e pós-investimento. Falta uma camada formal de orquestração da jornada.
Principal lacuna
Para constituir verdadeiramente 
uma única experiência
, o investidor deverá possuir:
uma única conta e identidade verificada;
um único perfil reutilizado em todos os módulos;
um painel consolidado;
uma caixa única de tarefas, mensagens e notificações;
uma carteira de projectos, corredores e clusters favoritos;
um único repositório documental;
acompanhamento dos procedimentos institucionais;
histórico completo das manifestações, reuniões e propostas;
estado da instalação e dos constrangimentos pós-investimento;
recomendações personalizadas de oportunidades, fornecedores e financiamento.
O que deve ser acrescentado
Recomendo formalizar um módulo transversal denominado 
“Experiência Integrada do Investidor”
, com requisitos próprios para:
identidade digital e representação de organizações
;
perfil único do investidor
;
orquestração da jornada ponta a ponta
;
painel único de processos, investimentos e tarefas
;
caixa documental e assinatura electrónica
;
balcão único e interoperabilidade institucional
;
acompanhamento pós-investimento
;
personalização e inteligência de mercado
;
consentimentos e reutilização controlada dos dados
;
indicadores da experiência completa
.
Conclusão
O desenho actual já 
dispõe
 
d
a maior parte das capacidades necessárias. A promoção, a transacção assistida, a interoperabilidade e a inteligência de mercado estão bem desenvolvidas. As principais lacunas são a 
formalização técnica da identidade digital
, o 
módulo completo de pós-investimento
 e uma 
camada transversal que una todos os serviços num único painel e numa única jornada do investidor
.
Rever os RF-EII e eliminar duplicaçõesValidar os indicadores e as fórmulas da jornadaConsolidar o roadmap e os critérios Go/No-Go do MVP
Formação t
é
cnica:
 
sugerir tipo de formação nos locais de investimento por área de conhecimento e tornar isso como oportunidade de investimento na área de educação 
Apresentar as alterações finais e as secções afectadas
, 
Validar o documento completo quanto a duplicações e referências cruzadas
, 
Preparar a versão final para implementação do MVP
Alterações finais
Criei a secção 
4.7. Baseline final para implementação do MVP
, com:
registo das alterações e secções afectadas;
escopo fechado do MVP;
funcionalidades incluídas e remetidas para fases posteriores;
checklist executiva de 
Go/No-Go
;
plano de arranque dos primeiros 30 dias;
pendências externas que exigem decisão ou validação formal.
Reordenei o backlog integrado para a sequência correcta:
E1 a E9
, colocando Integrações e Operação como E8 e Formação Técnica como E9.
Eliminei a duplicação entre:
4.6.2 — matriz inicial de competências
, agora apresentada como síntese;
4.6.6 — matriz completa
, mantida como referência detalhada.
Corrigi a referência textual da matriz completa de 
4.6.2 para 4.6.6
.
Removi parágrafos artificiais acumulados junto ao índice.
Restaurei o índice automático e marquei-o para actualização.
Validação realizada
Confirmei:
sequência e existência dos requisitos 
RF-CLU, RF-COR, RF-EII, RF-EDU, RF-CRM, RF-MON, RF-MIN, RF-AGR e RF-GEO
;
existência formal de 
RF-CRM-001 a RF-CRM-012
;
validade da referência 
RF-CRM-003–008
 na matriz de rastreabilidade;
ausência de referências a secções inexistentes;
coerência entre requisitos, MVP, indicadores, roadmaps e backlog;
alinhamento das prioridades das secções 4.2 a 4.7;
preservação dos valores, critérios, tabelas técnicas e estrutura existente.
Estado final
O documento está agora estruturado como 
baseline funcional e executiva do MVP
. A construção pode iniciar após cumprimento das pré-condições registadas na secção 4.7, especialmente:
nomeação dos responsáveis e órgãos de governação;
aprovação do orçamento e da equipa;
validação da carteira, mapas e fontes de dados;
aprovação da arquitectura, modelo físico e APIs internas;
confirmação dos clusters, corredores e oportunidades educativas do piloto;
validação jurídica, institucional, de segurança e privacidade;
congelamento do backlog Must dos épicos E1–E9.
O documento está finalizado como baseline funcional e executiva e pode avançar para a fase seguinte: arquitectura técnica detalhada, validação do legado e planeamento do MVP.
 O desenvolvimento deve iniciar 
após
 
a
 
conclusão d
as condições da secção 4.7: equipa, orçamento, RACI, dados do piloto, arquitectura, segurança e backlog Must.
Tecnologia recomendada
React: manter
React continua adequado para:
portal público;
painel do investidor;
CRM;
mapas e filtros;
formulários complexos;
dashboards;
E
xperiência bilingue e responsiva.
Recomendo actualizar o projecto para uma versão suportada do React, adoptar 
TypeScript
, uma biblioteca de componentes acessível, testes automatizados e uma camada clara de gestão de estado e 
de 
chamadas à API. A documentação oficial mantém a linha React 19 como actual. 
[react.dev]
, 
[react.dev]
Laravel: manter
Laravel também continua adequado como núcleo transaccional para:
API;
autenticação e autorização;
CRM;
workflows;
filas;
notificações;
auditoria;
integrações;
facturação;
webhooks;
serviços de IA.
A recomendação é actualizar para uma versão suportada. O Laravel 13 requer PHP 8.3 e tem actualizações de segurança previstas até Março de 2028; o próprio Laravel estabelece 18 meses de correcções e dois anos de actualizações de segurança por versão principal. 
[laravel.com]
Base de dados: principal decisão técnica
MySQL pode continuar a suportar o portal
, sobretudo se a versão actual estiver bem estruturada e se for adoptada uma edição LTS. O MySQL mantém uma linha LTS destinada a estabilidade operacional e suporte prolongado. 
[dev.mysql.com]
Contudo, o novo desenho depende fortemente de:
pontos, linhas e polígonos;
corredores e áreas de influência;
intersecções geográficas;
proximidade entre projectos e infra-estruturas;
comparação territorial;
camadas ambientais;
rotas e nós logísticos;
C
onsultas espaciais complexas.
Para estes requisitos, 
recomendo PostgreSQL com PostGIS como base principal
, porque oferece armazenamento, indexação e análise nativa de pontos, linhas, polígonos, raster e geometrias 3D, além de integração com ferramentas GIS. 
[postgis.net]
, 
[postgis.net]
Opções possíveis
Opção recomendada: React + Laravel + PostgreSQL/PostGIS
É a arquitectura mais coerente com o documento final:
React/TypeScript
 no frontend;
Laravel
 como API e orquestrador;
PostgreSQL/PostGIS
 para dados transaccionais e geoespaciais;
Redis para cache, sessões, filas e rate limiting;
armazenamento de objectos para dossiers e documentos;
motor de pesquisa dedicado apenas quando o volume justificar;
serviço de IA isolado por APIs, sem acesso directo e irrestrito à base de dados.
Vantagem:
 uma única fonte de verdade para CRM, projectos, clusters, corredores, relações e geografia.
Opção conservadora: manter MySQL e adicionar PostgreSQL/PostGIS
MySQL mantém os módulos actuais;
PostGIS recebe corredores, mapas e inteligência territorial;
Laravel integra as duas bases.
Vantagem:
 menor risco inicial de migração.
Desvantagem:
 aumenta 
a 
reconciliação,
 a
 duplicação, 
as 
integrações e 
o 
custo operacional. Deve ser considerada apenas como 
uma 
transição.
Opção mínima: manter integralmente MySQL
É viável para um MVP muito limitado, com mapas simples e pouca análise espacial. Não é a melhor opção para 
um
a visão completa d
os
 corredores, 
dos 
clusters e
 da
 recomendação territorial.
Recomendação final
Continuem com React e Laravel.
 Não recomendo reescrever a aplicação apenas por 
uma 
mudança tecnológica.
Para a base de dados, façam primeiro uma auditoria do MySQL actual e uma prova de conceito comparativa. A minha recomendação-base é:
React + TypeScript + Laravel actualizado + PostgreSQL/PostGIS, com migração incremental do MySQL.
Próxima fase
inventariar versões, código, tabelas, APIs e dívida técnica do portal actual;
verificar cobertura funcional reutilizável;
desenhar a arquitectura alvo;
executar uma prova de conceito de GIS, corredores e clusters em PostGIS;
definir a estratégia de migração MySQL → PostgreSQL;
congelar contratos OpenAPI;
criar o backlog técnico dos épicos E1–E9;
I
niciar o MVP apenas após o Go/No-Go técnico e institucional.
Criar o plano técnico da próxima faseAuditar o código, versões e base MySQL actuaisDefinir a prova de conceito com PostgreSQL e PostGIS
Mostrar a matriz completa de transição com todos os activos e ondas
 
Apresentar a checklist de aceite da Fase Zero com evidências e aprovadores
 
Detalhar o cronograma de migração, responsabilidades e marcos Go/No-Go
Automatizar o upgrade com base nos documentos, criar um modelo de dados unificado, scripts, telas e a relação entre todos os componentes (uso do Codex?) e acrescentar tudo no fim do documento para facilidade de visualização e importação para uso
Limites de utilização
O documento 
não deve ainda ser tratado como código pronto para produção
 nem como prova de que as integrações, dados ou serviços institucionais já existem.
Antes da construção, continuam necessárias as seguintes validações externas:
aprovação executiva e orçamento;
nomeação do Dono do Produto, comités e responsáveis;
validação jurídica e institucional;
confirmação da carteira piloto;
auditoria da aplicação React, Laravel e MySQL existente;
criação física dos ficheiros normativos de A.31;
validação do modelo PostgreSQL/PostGIS;
lint de SQL, YAML, JSON e CSV;
ensaios de migração e reversão;
testes de segurança, desempenho, acessibilidade, integração e recuperação;
confirmação das APIs e acordos com entidades externas;
decisão formal de Go/No-Go.
Ajustes finais recomendados
Antes de distribuir a versão para aprovação, recomendo uma última edição curta:
manter apenas 
um índice automático
 — o ficheiro actualmente contém dois índices consecutivos;
actualizar os campos do índice;
mudar o título 
“Relatório de validação técnica do Anexo A”
 para 
“Relatório histórico de validação técnica do Anexo A”
, porque os bloqueios nele descritos foram posteriormente resolvidos por A.31;
corrigir 
“correspondência automatizado avançado”
 para 
“correspondência automatizada avançada”
;
uniformizar “Roadmap” para 
“Roteiro”
 nos títulos 4.2.6 e 4.3.6;
substituir termos operacionais ingleses remanescentes quando não forem nomes técnicos;
reforçar que nenhum novo domínio funcional deverá ser desenvolvido em MySQL;
identificar a versão, data, aprovadores e estado do documento na capa ou ficha de controlo.
Conclusão
O documento está 
apto para aprovação, contratação da próxima fase e preparação técnica do MVP
.
A classificação recomendada é:
Documento funcional e técnico:
 aprovado;
Especificação normativa A.31:
 aprovada documentalmente;
Repositório e ficheiros físicos:
 pendentes;
Desenvolvimento e testes:
 pendentes de autorização;
Pré-produção:
 pendente;
Produção:
 não aprovada.
Portanto, ele já pode ser utilizado para iniciar formalmente a 
Fase Zero, a auditoria do legado, a constituição da equipa e a materialização do pacote normativo
, mas não deve autorizar directamente a entrada em produção.