InvestMoz

1. Sumário executivo

O InvestMoz é uma plataforma digital que aproxima investidores, promotores e instituições. A experiência começa no portal público, onde se consultam sectores, oportunidades, negócios existentes, território, zonas e serviços. A partir daí, a pessoa pode manifestar interesse, iniciar uma simulação ou pedir apoio. Os percursos que exigem continuidade passam para a área autenticada, onde se mantêm perfil, rascunhos, candidaturas, anexos e comunicação.

Do lado institucional, os pedidos podem ser revistos e acompanhados por CRM local, tarefas, revisões e eventos. A plataforma também contém domínios de catálogo territorial, zonas de investimento, documentação, governação fiscal, educação e competências, assistência de terra, parcerias, balcão virtual e IA baseada em fontes.

O README descreve a base inicial de sectores, oportunidades e manifestações de interesse. Rotas, controladores, migrations e documentação de domínio mostram uma solução mais abrangente. O levantamento de casos detalhados tem 24 casos de uso; este relatório acrescenta cenários concretos, diagramas UML/ER e a leitura da frequência dos eventos.

2. O que o projecto faz

3. Actores e fronteiras de acesso

Os nomes acima são papéis funcionais consolidados. A autorização efectiva depende das policies, middleware, MFA, configuração e permissões em vigor.

4. Diagrama de casos de uso com actores

O diagrama destaca actores (“bonecos”) e os principais serviços que usam. As associações mostram interacções típicas; não indicam que todos os serviços estejam activos na mesma instalação.

Exemplo do percurso mais comum: visitante pesquisa → manifesta interesse → investidor cria/acompanha candidatura → gestão trata o pedido → revisão e decisão.

5. Casos de uso reais — jornadas ilustrativas

UC-A — Investidor encontra oportunidade e manifesta interesse

1. O visitante consulta sectores, filtra oportunidades por localização e abre o detalhe.
2. Escolhe “manifestar interesse”, informa contacto, modalidade e mensagem, e aceita o consentimento aplicável.
3. O sistema valida o alvo, regista o pedido e, quando configurado, um recibo/idempotência.
4. O investidor pode autenticar-se para guardar a oportunidade ou avançar para uma submissão.
5. Um gestor consulta o pedido, verifica consentimentos, atribui responsável, qualifica e cria tarefa de seguimento.
6. As alterações relevantes ficam no histórico; notificações e integrações só são consideradas entregues quando o disparo e o serviço estiverem confirmados.

Resultado: pedido rastreável ligado à oportunidade e encaminhado para tratamento. Entidades: Opportunity, Investor/User, InterestRequest, Consent, Lead, Task, AuditEvent.

UC-B — Proprietário submete um negócio para divulgação

1. O proprietário cria rascunho e informa modalidade, objectos, localização e documentos de suporte.
2. Submete o registo; o estado passa para revisão conforme o workflow aplicável.
3. O gestor analisa e pode aprovar, rejeitar ou pedir informação complementar.
4. O revisor documental confere original, hash, versão, scan e autorização de divulgação.
5. Só após as validações necessárias o conteúdo pode ser publicado ao público; publicação não altera a situação jurídica do documento.

Resultado: negócio com histórico e decisão rastreável. Estados documentados: draft → submitted → in_review → approved → published, com ramos needs_information, rejected, withdrawn, suspended e archived.

UC-C — Gestor territorial valida zona e relações

1. O gestor regista a zona e a referência/fonte pertinente.
2. Associa localização, operador, categoria, geometria e relações com projectos, clusters ou corredores.
3. As relações sem evidência verificada permanecem pendentes e identificadas.
4. Um revisor valida a evidência e as regras de publicação; alterações ficam versionadas.
5. A zona só aparece no portal conforme estado e autorização de divulgação.

UC-D — Utilizador guarda um rascunho e executa simulação

1. O utilizador preenche o formulário; os dados incompletos podem ser guardados como rascunho recuperável.
2. Quando solicita o cálculo, o sistema selecciona questionário e parâmetros elegíveis.
3. O job de simulação executa após a transacção e grava cenários, resultados, obrigações e fontes usadas.
4. O relatório pode ser consultado; o rascunho continua distinto do cálculo executado.

UC-E — Parceiros colaboram numa parceria ou serviço

Um actor cria uma proposta; outro manifesta interesse; após aceitação, os participantes podem colaborar numa sala, trocar mensagens/documentos e acompanhar marcos. O balcão virtual segue padrão semelhante para pedidos de serviço: registo, análise, pedido de documentos, eventos, revisão e resolução.

6. Diagrama de classes (visão lógica)

O diagrama apresenta as classes de domínio principais, atributos representativos e operações. É uma vista funcional; não reproduz todos os campos nem métodos Laravel.

A relação exacta Investor/User, a associação Submission/target e os vínculos Document/entidade podem ser opcionais ou implementados por tabelas polimórficas/de junção; confirme no schema antes de gerar código ou migrações.

7. Diagrama de relacionamento (ER simplificado)

N:M = muitos-para-muitos, normalmente resolvido por tabela de associação. Ligações genéricas de documentos/auditoria podem não ser FKs directas. Este mapa é uma vista funcional, não um substituto do ERD integral em docs/investmoz/erd.mmd e do dicionário de dados.

8. Eventos e frequência

Frequência configurada não é frequência observada. Não foram disponibilizados logs, contagens de eventos da base activa, filas, analytics nem tráfego HTTP. Assim, eventos por hora/dia/mês, sazonalidade, falhas e utilizadores activos permanecem indeterminados. Não se extrapolam estes valores a partir de testes, seeders, screenshots ou schema.

9. Inventário dos 24 casos de uso

Os pré-requisitos, fluxos alternativos e tabelas associadas por UC encontram-se no ficheiro casos-de-uso-aplicacao-actual.md.

10. Integridade, segurança e limitações

• Disponibilidade para consulta, situação jurídica/documental e uso em regra/cálculo são estados independentes.
• Respeitar autorização de divulgação e âmbito; relações sem evidência ficam pendentes.
• Preservar original, proveniência, ID exacto, edição/data, hash e histórico. Não confirmar autenticidade, vigência, direitos ou scan sem evidência.
• Importação não é publicação; publicação documental não activa cálculo fiscal; rascunho não é candidatura aprovada.
• Integração desenhada não significa sincronização activa. Cobertura e estado de cada domínio devem ser verificados nos respectivos relatórios de validação.
• Antes de alterações a dados activos, confirmar backup/restauro e acção autenticada. Testes e migrações usam exclusivamente base QA isolada.

11. Fontes de análise

• README.md do repositório;
• docs/investmoz/casos-de-uso-aplicacao-actual.md;
• docs/investmoz/erd.mmd, data-dictionary.csv e table-catalog.csv;
• rotas, controladores, modelos, jobs, comando de escalada e migrations;
• InvestMoz — Levantamento funcional, casos de uso e diagramas.docx, em Downloads.

O inventário cobriu 981 caminhos listados por rg --files, excluindo vendor e node_modules. Isso descreve o repositório acessível, não anexos externos, conteúdo de armazenamento privado ou base de dados de produção.