Fase 1 — núcleo privado do modelo canónico

28/09/2026. Continuação expressamente solicitada após a Fase 0. Estado: implementação parcial; Go condicionado para revisão técnica, No-Go para publicação/piloto real. Não se declara concluído todo o modelo solicitado. Fase 2 não iniciada.

Plano aplicado e modelo

Migration aditiva 2026_09_28_130000_existing_business_foundation.php, três modelos, ExistingBusinessPolicy, serviço ExistingBusinessDrafts e testes de integração. Reutiliza users, organizations, investment_items e documents, sem converter os registos existentes. Nenhuma API, ecrã, integração ou contrato anterior foi modificado. O serviço é interno; não há rota para submissão pública nesta fase.

erDiagram
    users ||--o{ existing_businesses : owns
    organizations o|--o{ existing_businesses : identifies
    investment_items o|--o| existing_businesses : maps
    existing_businesses ||--o{ existing_business_objects : describes
    existing_businesses ||--o{ existing_business_mandates : receives
    documents ||--o{ existing_business_mandates : evidences
    users ||--o{ existing_business_mandates : represents
    existing_businesses ||--o{ existing_business_revisions : versions

Dicionário implementado

Tabela	Campos e invariantes
existing_businesses	UUID, code único permanente, source_system/legacy_id conjuntamente nulos ou presentes e únicos, owner_user_id obrigatório, organization_id opcional, investment_item_id opcional e único, modality, status exclusivamente draft, classification internal/confidential/restricted, version_no positivo, payload cifrado, timestamps e deleted_at
existing_business_objects	UUID, business_id, kind distinguindo company/participation/asset/property/unit/improvement/agricultural_investment/land_right/contract/license/authorization/encumbrance/valuation/capital_request, classification confidential/restricted, verification_status exclusivamente pending, payload cifrado, timestamps
existing_business_mandates	UUID, business_id, representative_user_id, document_id, valid_from/valid_until coerentes, verification_status exclusivamente pending, payload cifrado, timestamps. Documento anexado não comprova legitimidade. Nenhum acesso é concedido pelo mandato pendente.
existing_business_revisions	UUID, business_id/version_no únicos, actor_id, action, reason cifrada, snapshot cifrado, SHA-256 do snapshot e created_at. Trigger rejeita UPDATE/DELETE.

Modalidades implementadas como vocabulário técnico, sem declarar admissibilidade: venda de empresa/participação, aumento de capital, investidor financeiro, parceiro estratégico, comprador, cessão, franchise, venda/arrendamento de activo, unidade, joint venture, sucessão, recuperação, expansão, internacionalização, imobiliário, investimento agrícola, direito fundiário e licenças mineira/florestal. As modalidades não fazem aprovação jurídica automática.

Payload do rascunho aceita apenas title, description, declared_reason, source_reference e valid_until. Todos permanecem privados e declarativos; podem estar incompletos. Não aceita identidade empresarial, mandato, valor, direito ou status arbitrários para os apresentar como verificados. Os modelos de objecto e mandato são suportes de persistência sem endpoints ou workflows ainda. Não os expor directamente antes de implementar validação por tipo e autorização por agregado.

Autorização, histórico e confidencialidade

Conta com email verificado pode criar rascunho. Só o proprietário verificado pode ler/alterar/arquivar pelo policy. Gestor genérico não ganha acesso aos dados reservados. Os privilégios de revisão, MFA e segregação em dois níveis serão introduzidos explicitamente no workflow; ainda não há papel privilegiado MNE.

O serviço bloqueia a linha, compara versão, grava alteração e revisão na mesma transacção. Motivo é obrigatório e cifrado. Arquivo usa soft delete e incrementa versão. Payload não participa na serialização normal do modelo. Nenhum log transporta o conteúdo. A constraint de status permite apenas draft: não há caminho de publicação até uma migration futura acompanhada do workflow aprovado.

Limite: serviços/models não substituem privilégios de administração da BD. O histórico implementado cobre alterações de rascunho feitas pelo serviço; objectos e mandatos ainda precisam dos seus próprios serviços e snapshots antes de disponibilizar edição. SHA-256 verifica integridade de conteúdo; não é assinatura jurídica.

Retenção e lacunas

Sem prazos inventados nem purga automática. Soft delete conserva evidências; duração, base legal, eliminação, litígio e gestão de chaves continuam pendentes da política. A não eliminação automática é uma precaução técnica temporária, não uma política de retenção homologada.

Faltam normalização detalhada de participações/valores/moedas, titularidade e cadeias documentais, emissor, área/unidades, contratos, ónus/restrições, transmissibilidade, relações territoriais, autorização editorial, consentimentos por finalidade, diligência, propostas e encerramento. Os payloads de objectos não são substituto final dessas entidades. Política/base legal, equipa nominal e carteira piloto continuam pendentes.

Testes e reversão

Suite completa após integração: 153 testes, 1597 verificações aprovadas (34741 ms). PHPStan e Pint aprovados. A primeira execução completa identificou a nova dependência do catálogo no teste de rollback das zonas; o teste foi actualizado para remover/recriar a migration MNE na ordem correcta. Não se usou CASCADE. Resultado final sem falhas.

Base isolada portal_services_test em localhost:55441, APP_ENV=testing. php vendor/bin/phpunit tests/Feature/ExistingBusinessFoundationTest.php --do-not-cache-result: 5 testes, 17 verificações aprovadas. Verifica cifragem e ocultação, proprietário versus outro gestor, email não verificado, versões desactualizadas, soft delete, histórico imutável, bloqueio de publicação e down/up vazio seguido de recusa de down com dados.

Migration executada apenas pelos testes na base isolada; não aplicada à base local da aplicação. Nenhum seeder ou dado real inserido. down() verifica as quatro tabelas antes de alterar qualquer uma, recusa dados, remove por dependência e não usa CASCADE nem DROP EXTENSION. Em ambiente com dados, manter o módulo inacessível e corrigir progressivamente; qualquer restauro exige backup verificado e reconciliação.

Rastreabilidade deste incremento

RF-MNE-001: negócio/proprietário/modalidades/modelo/policy/testes implementados parcialmente; legitimidade não comprovada. RF-MNE-002/003: distinção tipológica de objectos e estado pending, sem validação jurídica. RF-MNE-004: cifragem, versão, histórico e publicação bloqueada; dupla aprovação ainda não implementada. RF-MNE-007: referência documental de mandato, sem sala segura. RF-MNE-009: rollback vazio testado e protecção contra perda de dados; migração de anúncios reais não executada.

Próximo incremento da própria Fase 1: contratos tipados e normalização dos objectos/valores, associação de fontes e governação por agregado, sem abrir publicação. Fase 2 só após modelo e invariantes completos.

8.2 KiB Raw Blame History