Files
Investidor-V2/docs/investmoz/portfolio-journey.md
T
nala e65cb26901
tests / ci (push) Canceled after 0s
varias alteracoes
2026-10-06 14:50:12 +02:00

8.6 KiB
Raw Blame History

Carteira territorial e jornada do investidor

Entrega de 26/09/2026. Cobertura parcial de RF-COR-001/002/003/007/008/013 e RF-EII-004/005/007, articulada com RF-CLU e as matrizes documentais. Não representa conclusão integral destes requisitos.

Conteúdo importado

database/data/investment-portfolio.json transcreve as secções 4.3.4 (seis corredores), 4.5.2 (oito clusters), 6.1 e 6.6 (quinze projectos A01–A15) do documento de upgrade fornecido. Utilizada a extracção textual existente dos parágrafos 931–960, 1254–1285, 3432–3521 e 3741–3815. O DOCX estava aberto/bloqueado nesta sessão; não foi possível recalcular o hash do original. A extracção não foi usada como instrução operacional para executar os prompts contidos no documento.

As pontuações 91, 89, 88, 77, 74, 73 e 72 são valores propostos na fonte, não um cálculo de scoring nem recomendações personalizadas. Financiamento é habilitador transversal sem pontuação inventada. Valores monetários e metas permanecem no texto indicativo; não foram transformados em orçamento oficial. Não foram inventados mapas, coordenadas, entidades responsáveis ou autorizações.

InvestmentPortfolioSeeder cria cadastros e relações reutilizando projects, economic_clusters, development_corridors, cluster_projects, corridor_projects e corridor_clusters. Os IDs A01–A15 das matrizes determinam os vínculos a projectos. As correspondências sectoriais inequívocas dos corredores são mapeadas explicitamente; categorias genéricas não são transformadas automaticamente em novos clusters. O texto original de cada matriz permanece disponível para revisão.

Importação transaccional, serializada e reexecutável: preserva edições humanas; colisões de códigos com registos de outra origem ou eliminados interrompem a operação. O seeder cria rascunhos. O comando portfolio:import --approval="Referência da aprovação do proprietário" publica apenas fichas documentais sem alterações humanas; repetir não duplica publicações ou auditoria nem restaura fichas arquivadas. Sem --approval, apenas importa.

Aprovação e execução local — 26/09/2026

O proprietário aprovou expressamente nesta sessão a inserção e execução da carteira. Essa decisão substitui a exigência anterior de segundo gestor exclusivamente na carteira de investimento. Um gestor já autorizado pode aprovar a própria ficha, registando a decisão. A importação por consola conserva a autorização do proprietário, sem inventar uma conta ou identidade de revisor.

Aplicada 2026_09_26_140000_portfolio_owner_approval e executado portfolio:import --approval=.... Confirmados na base local: 15 projectos, 8 clusters, 6 corredores, 29 fichas publicadas, 17 relações corredor–projecto, 13 cluster–projecto e 20 corredor–cluster. Todos os quinze projectos pertencem a pelo menos um corredor. Os cadastros já existiam e foram conservados; foram publicadas as fichas e adicionados 29 eventos de auditoria.

Backup e restauro verificado de 74 tabelas: storage/app/private/portfolio-backup-20260926-162236/, com manifesto e reconciliação portfolio-verification.json. As únicas diferenças de contagem são 29 eventos de auditoria e uma migration. A fonte e os valores documentais permanecem identificados; publicar a carteira não declara execução física ou financiamento dos projectos.

Operação

  • /management/portfolio: pesquisar e filtrar a matriz, editar fichas, consultar relações e preparar publicação.
  • Publicação exige gestor autorizado e referência da decisão, ou aprovação expressa do proprietário na importação documental. Alterar uma ficha publicada retira-a imediatamente da consulta pública até nova aprovação. O sistema regista a decisão e não verifica por si a autenticidade de documentos institucionais.
  • /carteira: consulta pública exclusivamente de fichas publicadas cujas entidades não estejam eliminadas; navegação bidireccional corredor–projecto, corredor–cluster e cluster–projecto. Evidência interna e IDs dos revisores não são serializados publicamente.
  • /investidor: conta autenticada e email verificado, fichas guardadas, jornada única por utilizador/ficha, formulário com reutilização explícita do nome/email, papel, horizonte, mensagem, consentimento e protocolo.
  • Uma relação de origem directa, validada no servidor, acompanha a navegação e o pedido. Uma sequência arbitrária de múltiplos corredores/clusters ainda não é preservada integralmente.
  • Pedido, UUID de integração, evento da outbox e ligação à jornada ficam na mesma transacção. Uma jornada aceita uma manifestação: repetir o envio devolve o acompanhamento existente, sem criar outro pedido. Para rever o pedido após envio, o atendimento continua assistido; não existe edição pelo investidor.
  • Pedidos aparecem na gestão existente. A conversão para lead exige responsável e próxima acção e conserva o investidor associado à jornada. Não são atribuídos mandatos de organização nem identidades institucionais automaticamente.

O perfil individual é criado por ID de conta, sem tentar reconhecer identidades por coincidência de email. A associação a pessoas já existentes no CRM e a representação de organizações continuam a exigir reconciliação e gestão de mandatos. Não existe ligação automática a SuiteCRM; os eventos mantêm-se pendentes. O novo fluxo não agenda emails de notificação: o acompanhamento está no painel e na gestão de pedidos.

Validação e limites

Testes funcionais verificam reimportação, aprovação do proprietário, publicação pelo próprio gestor, rejeição de contas sem privilégios, preservação de edições, relações dos quinze projectos, privacidade de rascunhos, retirada ao editar, isolamento entre contas, consentimento, contexto, publicação/eliminação, não duplicação e identidade na conversão para CRM. Nesta alteração: 119 testes, 1.107 verificações, PHPStan, Pint, TypeScript e build aprovados. A verificação anterior em Edge cobriu corredor → âncora → painel → pedido → protocolo e largura móvel; não foi repetida visualmente nesta alteração. Fixtures permanecem apenas no PostgreSQL isolado.

Continuam pendentes: cadastro GIS e nós territoriais, CRUD das relações de corredores, dossier exportável, comparação, versionamento completo dos conteúdos, publicação de mapas autorizados, planos e riscos, indicadores, competências/educação, governação interinstitucional, perfis organizacionais, cofre documental, tarefas/mensagens no painel, balcão único, aftercare, IA supervisionada e sincronização real do CRM. O CRUD existente de projectos/clusters e cadeias de valor permanece disponível separadamente.

Migração e reversão

Migração aditiva 2026_09_25_130000_investment_portfolio_journeys. Não modifica as migrations históricas. O rollback recusa eliminar dossiers ou contas existentes; preservar dados e preparar reconciliação antes de reverter o esquema. Para suspender divulgação, guardar a ficha como rascunho. Não executar migrate:fresh na base local ou de produção.

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.