Especificação Prática para Implementação
Portal do Investidor 
REGRA ZERO. 
O portal não integra APIEX, AT, Banco de Moçambique, BRC ou qualquer sistema do Estado. Não pode ter API client, webhook, credencial, SSO, sincronização ou validação automática dirigida a essas entidades. Qualquer contacto externo é feito pelo facilitador por canal oficial e registado manualmente no portal.
Objectivo do
 
Portal
: publicar oportunidades e informação confiável, receber manifestações de 
interesse e pedidos de orientação e gerir internamente o atendimento, os documentos, os encaminhamentos manuais e os indicadores.
1. Decisões de produto e papéis
Papel
Pode fazer
Não pode fazer
Visitante
Pesquisar oportunidades, consultar guias/legislação e simular requisitos orientadores.
Ver dados reservados, anexos, pedidos ou contactos de outras pessoas.
Investidor / Promotor
Criar perfil, guardar oportunidade, enviar pedido, anexar documentos e acompanhar próprios pedidos.
Publicar oportunidade directamente ou ver dados de terceiros.
Facilitador
Triar, pedir complemento, enviar mensagens, agendar e registar encaminhamento/resposta externa.
Alterar legislação, parâmetros do simulador ou permissões administrativas.
Editor / Admin
Publicar conteúdos/oportunidades, gerir traduções, perfis, permissões, relatórios e auditoria.
Apagar trilha de auditoria ou assumir que informação externa foi validada automaticamente.
Estados internos únicos para pedidos: Rascunho -> Submetido -> Em triagem -> A aguardar informação -> Encaminhado manualmente -> Respondido -> Encerrado (ou Cancelado). O rótulo mostrado ao utilizador é sempre “estado no Portal do Investidor”.
Diagrama 1. Fluxo de atendimento interno e encaminhamento manual.
2. Requisitos funcionais 
2.1 Descoberta e conteúdo público
ID
Prioridade
Requisito implementável
Critério de aceitação
RF-01
Must
Página inicial: proposta de valor, sectores, oportunidades em destaque, 
Como
 começar, legislação/incentivos e contacto.
Áreas principais acessíveis em até dois cliques.
RF-02
Must
Pesquisa contextual em oportunidades, guias, legislação
.
Resultado apresenta tipo, título, resumo e ligação para detalhe.
RF-03
Must
Catálogo de oportunidades com filtros por sector, província, distrito, ZEE/ZFI, estágio, montante, promotor e modalidade.
Filtros são combináveis, paginados e podem ser limpos.
RF-04
Must
Ficha de oportunidade: código, sector, localização, promotor, estágio, montante, resumo, requisitos, documentos, fonte e actualização.
Publicação bloqueada se faltar qualquer campo obrigatório.
RF-05
Should
RF-06
Must
Páginas de sector, território e ZEE/ZFI com texto editorial e lista filtrável de oportunidades.
Cada página liga às fichas e preserva filtros relevantes.
RF-07
Must
Repositório documental com tipo, fonte, idioma, versão, data de revisão, validade e ficheiro.
Documento expirado não é público e é sinalizado no backoffice.
RF-08
Must
Guia “Como investir” por passos: requisito, documento, entidade competente, contacto/ligação oficial e pedir orientação.
Cada passo informa que a tramitação oficial ocorre fora do portal.
RF-09
Must
PT/EN para navegação, formulários, mensagens e conteúdos essenciais.
Não publicar rota EN sem tradução revista.
2.2 
Pedido
, 
conta
 e 
facilitação
ID
Prioridade
Requisito implementável
Critério de aceitação
RF-10
Should
Conta por e-mail com confirmação, recuperação de palavra-passe e consentimentos.
Conta activa só após e-mail verificado; palavra-passe usa hash forte.
RF-11
Must
Formulário de manifestação de interesse/pedido de orientação com campos condicionais por perfil.
Gera código único, confirmação e estado Submetido.
RF-12
Should
Anexos com lista permitida de tipos/tamanhos, análise de segurança e controlo de acesso.
Ficheiro inválido é rejeitado com motivo; ficheiro privado não é público.
RF-13
Should
Área reservada: pedidos, pendências, mensagens, reuniões, documentos e histórico.
Utilizador vê exclusivamente registos da sua conta/organização.
RF-14
Should
RF-15
Must
Backoffice de triagem, atribuição de responsável, mensagens, estados e eventos.
Cada mudança de estado grava actor, data, nota e visibilidade.
RF-16
Must
Registo manual de contacto ou resposta recebida de entidade externa: fonte, data, evidência e nota.
Não há preenchimento automático; evento fica em auditoria.
RF-17
Must
Validação: obrigatórios, e-mail, telefone, montante/moeda, consentimento, NUIT informado, anexos e duplicados.
Erros claros junto ao campo; regra bloqueante impede submissão.
2.3 
Administração
 e 
evolução
ID
Prioridade
Requisito implementável
Critério de aceitação
RF-18
Must
Backoffice para criar, rever, aprovar, publicar, arquivar e versionar conteúdos, oportunidades, documentos.
Publicação regista autor, revisor, data, versão e motivo.
RF-19
Should
Simulador orientador por sector, território, investimento e ZEE/ZFI, baseado em regras internas versionadas.
Mostra parâmetros, versão, data e disclaimer; não emite decisão oficial.
RF-20
Should
Indicadores: oportunidades activas/actualizadas, pedidos por estado, tempo de resposta, sector e província.
Filtro por período e exportação CSV para perfil autorizado.
RF-21
Must
Auditoria de login, permissões, publicação, download restrito, estados e parâmetros.
Admin pode pesquisar; registo não pode ser alterado por utilizador comum.
RF-22
Could
Bolsa de parcerias e sala documental com correspondência assistida e permissões explícitas.
Partilha só depois de revisão do facilitador e autorização do titular.
3. Requisitos não funcionais
Área
Regra mínima
Como testar/aceitar
Segurança
TLS; RBAC; MFA para admins; sessões seguras; hash de palavras-passe; uploads privados; logs de auditoria.
Checklist OWASP sem vulnerabilidade crítica; teste de permissões por papel.
Privacidade
Recolher apenas dados necessários; consentimento; retenção; acesso por proprietário/organização.
Cada formulário apresenta finalidade e os pedidos de dados são auditáveis.
Acessibilidade
WCAG 2.2 AA nas jornadas públicas e formulários: teclado, foco, contraste, rótulos, erros e alt text.
Auditoria automatizada + teste manual de teclado/leitor de ecrã.
Desempenho
Páginas públicas LCP p75 <= 2,5 s; pesquisa p95 <= 2 s no volume inicial.
Web Vitals e teste de carga em homologação.
Disponibilidade
Meta 99,5% mensal; backup diário; RPO <= 24h; RTO <= 8h.
Simulação de restauro de backup antes do lançamento.
Compatibilidade
Chrome, Edge, Firefox, Safari actuais; telas a partir de 360 px.
Matriz de browsers e testes mobile concluídos.
Conteúdo
 legal
Fonte, revisor e data de validade obrigatórios para conteúdo jurídico/fiscal.
Job lista expirações; item expirado é despublicado ou bloqueado.
Não
 
integração
Não usar APIs/credenciais/webhooks de órgãos públicos.
Revisão de código e variáveis de ambiente confirma ausência.
Diagrama 2. Arquitectura interna permitida; sem ligações técnicas ao Estado.
4. Especificação técnica
Componente
Escolha recomendada
Contrato de implementação
Frontend
ReactJS
PT/EN; rotas públicas SEO; área reservada; backoffice; formulários acessíveis.
Backend 
interno
Laravel / PHP; API REST; OpenAPI; validação de requests
Prefixo /api/v1; policies e middleware por papel; sem clientes externos governamentais.
Dados
MySQL 8 + Eloquent migrations
Entidades versionadas; FK; índices para filtros/pesquisa; migrações em CI.
Ficheiros
Object storage privado S3 compatível
Upload por URL assinada; tipo/tamanho/checksum; URL temporária para download.
Jobs
Fila/scheduler
E-mail, lembrete de pedido, expiração editorial e agregação de métricas.
Operação
CI/CD + monitorização + backups
Ambientes dev/homologação/produção; logs estruturados; alertas e rollback.
4.1 Dados 
mínimos
Tabela
Campos essenciais
users
id, email, password_hash, name, locale, role, status, email_verified_at
organizations
id, type, legal_name, nuit_informed, country, province, owner_user_id, verification_status
opportunities
id, code, status, sector_id, province_id, promoter_org_id, maturity_level, investment_amount, currency, published_at
opportunity_translations
opportunity_id, locale, title, summary, description, requirements, updated_at
requests
id, type, requester_user_id, opportunity_id, internal_status, assigned_to, submitted_at, closed_at
request_events
id, request_id, event_type, actor_id, visibility, note, source, evidence_document_id, occurred_at
documents
id, owner_type, owner_id, storage_key, visibility, mime_type, size, checksum, uploaded_by
content_items
id, type, status, source_url, reviewed_by, reviewed_at, expires_at, version
audit_logs
id, actor_id, action, subject_type, subject_id, metadata, occurred_at
4.2 Endpoints internos essenciais
Rota
Operação
Autorização
GET /api/v1/opportunities
Lista e filtra oportunidades.
Público
GET /api/v1/opportunities/{code}
Obtém ficha pública.
Público
POST /api/v1/requests
Cria pedido ou manifestação.
Autenticado / fluxo público validado
GET /api/v1/me/requests
Lista pedidos próprios.
Dono
POST /api/v1/documents
Cria upload controlado.
Dono / facilitador
PATCH /api/v1/admin/requests/{id}/status
Actualiza estado interno.
Facilitador / admin
POST /api/v1/admin/opportunities
Cria ou publica oportunidade.
Editor / admin
POST /api/v1/simulations
Executa simulação orientadora versionada.
Público ou autenticado
5. Plano de implementação - 6 passos
Passo
Entregável prático
Critério de saída
1. Preparar
Taxonomias, campos obrigatórios, papéis, estados, matriz de conteúdos e fontes.
Product owner, jurídico/editorial e responsáveis sectoriais aprovam a matriz.
2. Fundação
Repositório, CI/CD, base de dados, layout PT/EN, login/admin, observabilidade e backups.
Ambientes funcionam; permissões e backup são testados.
3. Portal público
Página inicial, guia, repositório, pesquisa, catálogo, filtros e ficha de oportunidade.
Lote piloto publicado com todos os campos obrigatórios e conteúdo revisto.
4. Facilitação
Formulários, anexos, código de pedido, backoffice de triagem, mensagens e estados.
Jornada pedido -> triagem -> resposta interna funciona sem integração externa.
5. Decisão assistida
Comparação, simulador orientador, agenda e indicadores internos.
Parâmetros do simulador são versionados e disclaimers foram aprovados.
6. Lançar
Segurança, acessibilidade, carga, piloto, formação, SLAs e monitoria.
Homologação assinada, recuperação testada e equipa de suporte treinada.
6. Definition of Done por funcionalidade
Critérios de aceitação implementados e testados; teste negativo incluído para validações e permissões.
Interface PT e EN quando a funcionalidade é pública ou destinada ao investidor.
Auditoria adicionada a toda acção crítica; campos pessoais e documentos protegidos por papel e proprietário.
Acessível por teclado, responsiva e sem erros de contraste/rótulos nas jornadas previstas.
Documentação de operação actualizada: como publicar, triar, registar contacto externo manual e responder incidente.
Confirmação de que nenhum elemento cria integração técnica com entidades governamentais.
ORDEM RECOMENDADA. 
Começar com informação e oportunidades correctas (passos 1-3). Só depois abrir pedidos e anexos (passo 4). Evita digitalizar um fluxo de atendimento antes de existir conteúdo confiável e equipa preparada.