compras/docs/demonstracao-requisicoes-8039.md

Requisições internas na demonstração 8039 — execução autorizada

Extensão posterior: consultas/cotações/adjudicação, candidata 040fb0cb67a77d61, preserva este percurso e a origem de 100 MZN. Preparação/leitura do novo percurso estão disponíveis em 8039; adjudicação completa foi testada apenas nas cópias, por faltar composição de identidades autorizada na demonstração. O relato abaixo preserva a entrega anterior.

Actualização de leitura — limitação resolvida em 02/11/2026

A autorização posterior do proprietário permitiu corrigir exclusivamente a leitura no adaptador, sem direitos novos. A sucessora OPERATIONAL-CANDIDATE-166e397e3ca63f02 está aplicada em 8039; Consulta lê a requisição existente ID 1/100 MZN na listagem, detalhe e histórico, mantendo todas as recusas de escrita/aprovação. Foi ensaiada a reversão para a anterior e a reaplicação; 109 tabelas reconciliadas, uma reserva, versão 3, contas/direitos/configuração preservados e auditoria apenas acrescentada. Matriz, hashes e provas actuais. O relato da limitação abaixo é histórico, sucedido por esta correcção. Revisão visual e implantação real continuam separadas.

02/11/2026. A confirmação do proprietário foi executada apenas na demonstração existente. Não foi criada instalação 8041, base ou conta nova, nem executado GRANT/REVOKE SQL. A instalação real permanece adiada, com sgf_tempo_dev, configuração Tempo e pacote 0.1.1 preservados.

Local e configuração aplicada

• URL: http://127.0.0.1:8039; seleccionar a empresa/unidade sintéticas e o módulo Compras.
• Pasta: C:\laragon\data\sgf-tempo\run\modular-regression-2576427d1939\development-app.
• Base sgf_modules_dev_2576427d1939, cluster sgf_modular_regression_2576427d1939, porta 55439; contexto 1/1/1.
• Empresa Horizonte — Demonstração / Unidade Central — Demonstração; três contas sintéticas anteriores, mesmas credenciais e mesmos registos de utilizador.
• Centro ID 1 SINTETICO-REPRO, referência de política OPER; dotação ID 1: 10.000,00 MZN sintéticos, exercício 2026, operacional, inclui impostos; preparada por ID 1 e aprovada por ID 2.
• Política activa com orçamento obrigatório, limites de 10.000,00 e 20.000,00, impostos incluídos no cálculo; intervenientes Preparador e Revisor em OPER, conforme proposta aprovada. O montante disponível do exemplo só cobre o primeiro nível.
• Candidata OPERATIONAL-CANDIDATE-401ce31ae5f2dd20, manifesto a6478223e17a5430652f0fcbf31a44a931ae2a99cd90b151c98d2df5df43c10b; schema revisão 2 e código aplicado sem variante de compatibilidade. O ponteiro purchasing 0.1.1 continua preservado, inclusive na cópia.

Foram acrescentados exactamente os 14 direitos aprovados, 8 ao utilizador 1, 4 ao 2 e 2 ao 3, apenas no contexto 1/1/1. Prova com lista exacta e comparação dos direitos/contas anteriores. A inicialização extraordinária foi fechada após a outorga; administração posterior segue o catálogo nativo. Nenhum direito anterior foi retirado ou reescrito.

O servidor foi parado/reiniciado exclusivamente em 8039. A sessão local estava configurada como array, que perdia o estado entre pedidos depois desse arranque; passou a file no .env desta cópia, preservando autenticação e CSRF, sem alterar contas ou palavras-passe. Não houve compilação de caches nem mudança no .env real. A ligação proprietária isolada é limitação conhecida e não modelo de instalação cliente.

Verificação e limitação encontrada

Verificação HTTP focada e reconciliação final SQL somente de leitura:

• Login das três contas existentes; configuração/grants pelos mecanismos auditados existentes.
• Centro e dotação preparados pela API, com aprovação de dotação por outra identidade; autoaprovação recusada.
• Requisição ID 1 de 100,00 sintéticos, submetida por ID 1, aprovada por ID 2; consulta de origem/versões e três eventos pelo Preparador e Revisor.
• Repetição da submissão com a mesma chave devolveu a mesma requisição; reconciliação confirmou uma requisição e uma reserva, sem duplicação.
• Perfil Consulta recusado em criação de centro, preparação, configuração de política, submissão, decisão, aprovação de dotação e administração de acessos. Nenhuma mutação indevida criada.

Limitação funcional explicitamente detectada: purchasing_requisitions.view sozinho não autoriza uma terceira identidade a ler este registo; a regra actual restringe a consulta a requerente/configurador/decisores elegíveis. A Consulta abre a listagem mas recebe 404 no registo da outra pessoa. Não se concedeu aprovação/configuração para contornar isso nem se alterou a regra de visibilidade. A proposta de um perfil que consulte requisições de terceiros não fica demonstrada como concluída: requer decisão específica sobre visibilidade e eventual correcção do servidor. Esta limitação não impede o percurso Preparador → Revisor → consulta pelos intervenientes já autorizados.

As recusas ao Consulta podem ocorrer antes da autorização de operação, pela regra de visibilidade (404), e não apenas por 403. As provas anteriores de concorrência/restauro/caches e navegação não foram repetidas integralmente. Revisão visual permanece separada; nenhum navegador utilizado.

Recuperação preparada antes da primeira escrita

Pasta privada existente: C:\laragon\data\sgf-tempo\run\modular-regression-2576427d1939\private\requisitions-recovery.

• before.dump: backup custom integral só da base sintética, SHA-256 2eed6d9f775d8d5dc8c7b1606e230b8782c09a69098d31e659d9ad28a4d608fa; índice conferido por pg_restore. Não se declara novo ensaio integral de restauro deste dump; as provas anteriores de recuperação são reutilizadas.
• files/: cópias anteriores de todos os overlays, .env, configuração modular e ponteiro; baseline.json: identidade, grants anteriores e hash das contas; applied.json: ID a6478223e17a5430652f0fcb e journal de aplicação.
• Journal/backups nativos: development-app/storage/app/private/module-deployments. Preservar também os três novos ficheiros config/purchasing-{operational,internal,access}.php ao diagnosticar uma falha; não existiam antes.

Em falha, fechar apenas 8039. Reversão de código usa a CLI do bundle e o ID registado, sob manutenção/servidor parado; repor os ficheiros de configuração anteriores, incluindo .env, e retirar da composição os novos ficheiros apenas após os arquivar. Não voltar a criar contas ou apagar concessões para simular reversão. Código não reverte dados: recuperar o dump para base alternativa com procedimento DBA autorizado, reconciliar quaisquer operações posteriores ao backup e só então decidir a ligação da demonstração. Não sobrescrever a base activa, não usar comandos de paragem do cluster partilhado e não tocar na porta 55432.

Scripts específicos deste incremento: scripts/sgf-demo-8039.php e scripts/sgf-demo-8039-http.mjs. A preparação recusa sobrescrever a recuperação anterior. O runner HTTP é um registo operacional com chaves persistentes privadas; não o reaplicar cegamente após o fecho da inicialização. Não contém credenciais nem acede a contas reais.