Files
SGF/docs/MODULE_ASSOCIATIONS_REVIEW.md
T
2026-11-02 20:29:34 +02:00

6.7 KiB

Conferência das associações pendentes de módulos

02/11/2026. Levantamento e proposta de tratamento após a aceitação técnica da navegação modular. Não executa decisões de associação, migrações, concessões ou implantação. Não substitui a revisão humana dos dados, a avaliação de volume ou a revisão visual.

Resultado conferido

Consultas PostgreSQL em transacção REPEATABLE READ, READ ONLY, com identidade física conferida, timeout de 15 segundos por instrução e rollback final. Sem autenticação HTTP, navegador ou escrita em dados. Os relatórios contêm identificadores e versões, sem nomes de pessoas/clientes, credenciais, descrições ou valores de documentos.

Destino Área Registos sem associação Identificadores / versão
SGF local, sgf_tempo_dev, porta 55432 Clientes 1 #1 / v1
Mesmo destino Serviços 2 #1 / v1; #2 / v1
Mesmo destino, unidade #1 Prestações em rascunho 1 #1 / v1
Mesmo destino, unidade #1 Rascunhos de facturação 1 #1 / v1
Demonstração 8039, base sgf_modules_dev_2576427d1939, porta 55439 Clientes 1 sintético #1 / v1

Todos pertencem ao contexto tenant #1 / empresa #1 do respectivo destino, que não torna as duas empresas ou os dois clientes no mesmo registo. As outras três áreas da demonstração estão vazias. Não há registos actualmente associados nem casos com todas as associações retiradas nestes dois inventários. A amostra de até 100 pendentes por área cobre integralmente os resultados encontrados.

«Nunca associado» significa ausência de eventos explícitos para o registo; não prova a idade, a intenção comercial ou o módulo correcto. Não se inferiu destino pelo nome da tabela, autor ou dependências. O âmbito deste inventário são as quatro áreas partilhadas de ModuleRecords::AREAS; não constitui inventário de toda a instalação nem de outras demonstrações.

Evidências: instalação local e demonstração. A consulta usa o último evento por empresa/área/registo/módulo, distinguindo ausência de associação de retirada explícita. Não é uma listagem operacional nem uma nova API pública.

Dependências confirmadas na instalação local

  • Prestação #1/v1 referencia cliente #1 e serviço #2.
  • Rascunho de facturação #1/v1 referencia cliente #1, serviço #2 e prestação de origem #1, fotografia de origem v1.
  • Serviço #1 não é referenciado pelos dois rascunhos inventariados. Isto não prova ausência de utilização noutras capacidades.

Estas referências definem uma ordem útil de conferência, sem propagar associações: cliente/serviço #2 → prestação → rascunho de facturação. O serviço #1 deve ser revisto separadamente. Não alterar fotografias, versões, origens, histórico ou responsabilidade financeira para tornar os registos visíveis.

Tratamento proposto

  1. Manter todos os seis registos sem associação e sinalizados enquanto não houver fundamento explícito para cada destino. O cliente sintético 8039 permanece exemplo de pendência; não o converter automaticamente num exemplo operacional.
  2. Preparar uma ficha por registo com destino físico, tenant/empresa/unidade, área, ID, versão consultada, dependências, finalidade pretendida, módulo(s) solicitado(s), responsável pela decisão e fundamento. Estado inicial: por decidir. Uma mesma ficha não decide as dependências nem outros destinos.
  3. A pessoa responsável pelo cadastro confirma a finalidade e as dependências. A autoridade com access.manage, consulta e edição originais, e acesso ao módulo de destino, regista a decisão pelo percurso existente Opções gerais → Associações de módulos. O sistema actual não impõe uma segunda aprovação: qualquer exigência futura de dupla decisão necessita de desenho próprio, não se declara entregue.
  4. Antes de aplicar, reler a versão e o âmbito. Versão alterada exige nova conferência; a API existente recusa a versão desactualizada com 409. A implementação actual serializa decisões por empresa; não se afirma aqui que substitui todos os controlos de concorrência sobre edições do registo.
  5. Registar cada associação autorizada como evento novo, com motivo, preservando o original. Conferir a visibilidade no módulo escolhido, os direitos originais e a ausência de exposição indevida noutros módulos/empresas/unidades. Não conceder direitos para fazer uma associação funcionar.
  6. Se o destino estiver errado, retirar por novo evento e fundamentar; nunca apagar auditoria. Uma retirada explícita deve continuar distinta de «nunca associado», para evitar reatribuição automática posterior.

Esta proposta não determina Comercial ou qualquer outro destino para os cinco registos locais. A autorização desta passagem é de conferência/proposta; nenhuma decisão foi executada.

Próximo incremento técnico delimitado

Propor uma fila administrativa de conferência com filtros por área, unidade e estado (sem eventos / associado / todas as ligações retiradas), paginação no servidor, ordenação estável e resumo das dependências por registo. Sem selecção de módulo por defeito, associação em lote, propagação de vínculos ou novos direitos. O inventário CLI agora disponível é apenas diagnóstico administrativo e não substitui essa fila.

A consulta administrativa actual carrega todos os registos autorizados e consulta o histórico por registo; é um padrão de consultas proporcional ao número de registos. Os volumes observados são pequenos e não validam escala. Antes de implantação, medir em base sintética separada o número de consultas, tempo, memória e plano de execução, incluindo histórico de retiradas/reposições. Só então propor tamanho de página, consulta conjunta de eventos e eventuais índices. Não aplicar índices ou schema por consequência deste levantamento.

Revisão visual e recargas das páginas autónomas permanecem pendentes, sem repetir a via de navegador bloqueada. As provas aceites da navegação são reutilizadas; não houve alteração de interface ou execução da suite destrutiva.

Repetição controlada do inventário

Pelo PHP 8.4.27 fixado para o projecto:

php scripts/module-associations-inventory.php installed
php scripts/module-associations-inventory.php demo

O script só aceita estes destinos fixos e recusa divergência de base/role/porta ou transacção que não seja de leitura. A sua execução pertence ao operador local autorizado; não expor como endpoint nem publicar relatórios de cliente. Não arranca/paralisa serviços, muda configuração ou percorre outras bases. Não foi criado checkpoint ou efectuada publicação nesta passagem.