commit21
This commit is contained in:
@@ -2157,3 +2157,442 @@ A autorização não publica artigos nem define mínimos, quantidades, política
|
||||
Verificação posterior concluída por HTTP em8005: configuração activa27,11perfis,17vínculos,12contas, dois administradores permanentes e nenhuma perda de competências/contextos/preparação/departamento. Os cinco perfis sintéticos abriram os seus percursos: requisição, revisão do departamento, entrega, preparação da reposição e conferência da reposição. Procurement não recebeu conferência; Finanças não recebeu preparação; chefe/armazém não receberam preparação de requisição interna. Todos os cinco foram impedidos de entrar na administração de perfis. Cada perfil viu0tarefas na situação actual, e a consulta de tarefas de Pessoas continuou disponível à administração no seu contexto próprio. Sem comandos de negócio nesta verificação. Prova pilot-access-activation-http.json e log pilot-access-activation-http.txt; sem revisão visual completa.
|
||||
|
||||
Diagnóstico efectivo do piloto: intervenientes independentes prontos,1armazém,0artigos publicados com origem actual,0políticas internas aprovadas e0regras automáticas activas. Serviço periódico e recuperação técnica recentes/sem pendências. Warehouse/replenishment_scenario_ready continuamfalse pela ausência de catálogo/políticas; client_configuration_complete também permanecefalse porque o diagnóstico exige contexto interno explicitamente contratado, além dos perfis/administração, enquanto a avaliação conserva o âmbito sintético existente. Não alterar direitos comerciais por inferência nem declarar entrega de cliente. Próxima preparação funcional: catálogo e políticas/regras específicas por artigo/armazém, com responsáveis/centros e quantidades escolhidos na parametrização e conferidos independentemente. Esta autorização de perfis não fixa esses valores.
|
||||
|
||||
## 02/11/2026 — compatibilidade do núcleo financeiro com leitura paginada SGF
|
||||
|
||||
O SGF passou a usar uma janela documental de25/100 e dependências lidas em conjunto no núcleo canónico packages/payables; cálculo de posição, cadeia de decisões e caminhos de escrita preservados. O adaptador autónomo SGC e o seu pacote instalado não foram alterados/activados por arrasto. A prova nativa usou COMMON_PAYABLES_PATH apenas em cópias e bases QA próprias, não como dependência de servidor SGF remoto.
|
||||
|
||||
Foram conferidos21 casos afectados de histórico/decisões com144 asserções:20 válidos reutilizados da primeira execução e um caso de imutabilidade repetido isoladamente após envolver as violações SQL esperadas em savepoints. A correcção é apenas no teste PayableHistoryImportTest: o PostgreSQL deixava a transacção do teste abortada e a recusa posterior não era avaliada. Uma tentativa intermédia de retoma encontrou função residual do RefreshDatabase; não é prova válida. O launcher agora exige base QA nova para esta suite, preservando provas/bases anteriores.
|
||||
|
||||
Relatório SGF: C:/laragon/www/sgf-tempo/docs/SGF_PAYABLE_PAGED_READ_DELIVERY.md e docs/proofs/sgf-payable-paged-read-20261102.json desse repositório. Comparação financeira em1.000/5.000/10.000, páginas25/100, sem índices novos. Dados/configurações/acessos/demos SGC, pessoas e autoridade financeira real preservados. Sem publicação, migração real, activação de candidatas, pagamentos ou checkpoint. A adaptação paginada do leitor nativo continua trabalho separado; a compatibilidade do motor não significa que essa interface já foi entregue ao SGC.
|
||||
## 02/11/2026 — tarefas documentais, formais e de reposição integradas no SGC
|
||||
|
||||
As minhas tarefas passa a encaminhar a conclusão das respostas documentais pendentes do próprio analista e a conferência de admissão/recomendação formal. A elegibilidade é reutilizada nos formulários e nos comandos: regime e quórum adoptados, versão/base actual, competência, departamento, empresa, impedimentos e independência. Não se inventa um analista obrigatório nem se transforma uma resposta desfavorável já concluída em análise por terminar. Respostas anteriores do próprio analista são reutilizadas; decisão, evidência e histórico alheios não são copiados. Ligações focam a proposta/tentativa certa mesmo fora da primeira página, preservando a versão consultada e impedindo usar história como decisão actual. Acesso de manutenção não executa; o chefe com administração acumulada continua sujeito ao departamento no percurso documental.
|
||||
|
||||
Fornecimentos e reposição ganhou categoria própria nas tarefas de Compras: conferência de acordos, políticas e regras automáticas pelo responsável competente. A lista/formulário reutiliza SupplyPlanning/AutomaticPurchases; todos os participantes na preparação permanecem excluídos da aprovação, incluindo versões anteriores. Mantida a possibilidade preexistente de suspensão de regra automática por conferente autorizado, sem inventar uma nova segregação nessa acção. Alteração da origem impede aprovação silenciosa mas conserva a devolução permitida pelo motor. Preparações devolvidas mantêm o regime original, sem acrescentar uma etapa fictícia de submissão.
|
||||
|
||||
O foco por record_id/rule_id valida empresa e tipo e apresenta a versão actual com aviso quando a ligação ficou antiga. A fila paginada conserva todas as pendências, inclusive mais antigas do que os100registos do ecrã geral; essa listagem geral de fornecimentos continua limitada a100, não foi declarada integralmente paginada. Acções visíveis por registo seguem a competência efectiva e a independência do mesmo motor. Histórico Inertia cifrado e respostas privadas sem armazenamento; consultar tarefas não cria registos de negócio nem decide. Continuam distintos Pessoas e contratações, Compras autónomo e SGF.
|
||||
|
||||
Provas novas: formal156testes/2860asserções na regressão dirigida e11/383em PostgreSQL descartável; fornecimentos48/838na regressão dirigida e8/262em PostgreSQL descartável. Suites sobrepostas, não somar. Tipos, lint/build, análise PHP, formatação e18hashes de execução passaram. HTTP8005 abriu9componentes formais em3perfis e6páginas de fornecimentos/reposição em2perfis, com separação preparação/conferência e0pendências actuais. Decisões e cenários pendentes foram exercitados nas bases descartáveis. Provas formal-task-integration[-pg/-http].json e supply-task-integration[-pg/-http].json. Sem bateria geral/revisão visual completa/migração/contas/perfis/decisões de negócio persistentes ou alteração SGF.
|
||||
|
||||
### Proposta operacional do piloto, preparada sem aplicação
|
||||
|
||||
Leitura local confirmou ART-TEST «Artigo de stock fictício»,1cx livre/física, ARM-TEST, versão de movimento1 e catálogo ainda não publicado. Proposta concreta em docs/proofs/pilot-replenishment-proposal.json: publicar somente esse artigo como «Outro», categoria de ensaio; política interna/local com segurança0, mínimo1cx, alvo/máximo3cx, consumo previsto0, prazo1dia e conferência1dia, horizonte7dias, embalagem1cx e sem mínimo de encomenda; regra válida até09/11/2026, necessidade em5dias, requisitante sintético9 e centroOPS1. Estimativa artificial10MZN/cx, IVA16% existente:2cx,20MZN líquidos e23,20MZN comIVA. Estes números são inputs propostos do ensaio, não parâmetros comerciais aprovados nem cotação de fornecedor.
|
||||
|
||||
Simulação por scripts/pilot-replenishment-dry-run.php na cópia restaurada e descartável da avaliação actual: publicação por13, preparação por11, conferência independente por12, compra atribuída a9. Tarefas de política/regra/requisitante verificadas; aprovação da regra repetida e duas reavaliações produziram só1rascunho de2cx, sem submissão/etapas humanas automáticas, encomenda ou alteração do stock. Comparados hashes de contas/perfis/atribuições, aprovações, encomendas e movimentos na cópia. Contextos sintéticos existentes reproduzidos apenas na configuração de execução da cópia, sem concessão comercial persistente. A base e o dump privados foram eliminados no finally. Prova pilot-replenishment-dry-run.json vinculada ao hash da proposta. Tentativas iniciais de preparação falharam por localização dos binários/contexto da cópia; não são provas aprovadas e não executaram comandos na origem. A execução final aprovada inclui quantidade, totais, stock e ausência de duplicação. Não existe modo apply neste simulador.
|
||||
|
||||
Aplicar essa publicação/política/regra e criar o rascunho no piloto8005 depende de autorização específica dos valores propostos: a autorização anterior de acessos excluiu expressamente publicações, mínimos e decisões operacionais. Não reabrir a autorização dos perfis já aplicados na versão27. Não executar compra real, aprovar a compra, encomendar, receber, entregar ou tocar no SGF por consequência da proposta. Restante cobertura do workflow continua parcial, nomeadamente execução contratual e outras tarefas especializadas; este incremento não declara concluída toda a proposta Word.
|
||||
|
||||
## 02/11/2026 — reposição do piloto autorizada e aplicada; histórico ligado às tarefas
|
||||
|
||||
O proprietário autorizou expressamente a aplicação da proposta pilot-replenishment-proposal.json apenas no SGC8005 com as contas sintéticas existentes e pediu continuação autónoma do desenvolvimento. Autorização em pilot-replenishment-authorization.json, vinculada ao hash2db14db3dbde06d1bf18ff3e2ae81bb857e5570a2baeafb36b22969e10963e1c. A proposta original conserva o estado histórico de preparação; não voltar a pedir autorização nem reaplicar esta parametrização.
|
||||
|
||||
Aplicação atómica às18:55:41UTC: publicação ART-TEST/ARM-TEST por13; política interna/local preparada por11 e conferida por12, mínimo1/alvo3/máximo3cx; regra válida até09/11/2026, requisitante9/OPS1 e estimativa10MZN/IVA16%. Criado REQ-2026-000002,id2,rascunho2cx/23,20MZN. Sem submissão, aprovação da compra, encomenda ou alteração do stock1cx. Cópia privada antes da mudança em C:/laragon/data/sgf-tempo/backups/compras-pilot-replenishment-20261102-185536-c4396d/before.dump, SHA419b92072930553ef3f7b87bd08fc6e9bed1c48eb7ba1be97b50dd8977f12cd3; snapshot consistente e restauro conferido112tabelas,106tabelas fora do âmbito preservadas; restauro descartável eliminado. Provas pilot-replenishment-activation.json e pilot-replenishment-activation-http.json: origem reutilizada, tarefa do requisitante, separação preparação/conferência e saldo confirmados. Não foram criadas contas/perfis/grants nem alterado o SGF.
|
||||
|
||||
Histórico de consumo integrado na fila de fornecimentos/reposição. SupplyHistory::independentReviewer/canReview são reutilizados pelos comandos, formulários e tarefas; exige supply_history_review e independência de todos os preparadores. supply_review não concede conferência histórica por arrasto. Ligações record_id validam empresa/tipo e mostram versão actual com aviso quando a ligação ficou antiga. Pendências antigas conservadas na paginação completa das tarefas e no foco, mesmo fora do limite100 da listagem geral; esta listagem geral não foi declarada paginada. Periodicidade/fecho do histórico não são prazos de tarefa inventados. Consulta não escreve/decide; aprovação conserva confirmação humana de âmbito e revalida razão/cadastro/duplicação. Cadastro alterado permite devolver mas impede aprovação silenciosa. Nenhuma competência histórica foi acrescentada às contas do piloto.
|
||||
|
||||
O ensaio da próxima submissão encontrou actualização técnica existente ainda ausente na QA: 2026_11_01_000046_add_requisition_command_versions, distinta de create_workflow_notices com prefixo semelhante. Sem essa actualização, submissões com chave de operação terminavam503; não remover a guarda nem ocultar a falta. A cópia descartável foi actualizada e confirmou submissão/repetição sem duplicação. Instalada apenas essa migração técnica no piloto às19:04:40UTC, com nova cópia privada/restauro112tabelas,110tabelas protegidas e comparação integral das requisições excepto a nova coluna process_version=1. Cópia C:/laragon/data/sgf-tempo/backups/compras-pilot-replenishment-20261102-190433-e3f169/before.dump, SHAe32297ad0287eb648c7760ce5544c4681e0d35921a4fb5152e663ae49a9045c3. Criada tabela vazia de recibos e dois triggers de imutabilidade; nenhum comando de compra, mudança de estado, conta, grant ou regra foi executado por esta instalação. Prova pilot-command-receipts-installation.json. O diagnóstico passou a verificar tabela e coluna, impedindo declarar cenário pronto quando falta qualquer uma delas.
|
||||
|
||||
Provas desta continuação: regressão dirigida59testes/1030asserções; diagnóstico11/130; PostgreSQL final7/193,histórico e falta de estrutura,base removida. A primeira prova PostgreSQL5/181 é anterior e foi substituída pela execução alargada; suites sobrepostas,não somar. Tipos/lint/build/análise PHP/Pint/18hashes passaram. HTTP de histórico/administração e recusas dos perfis sem competência passaram;0análises históricas actuais. Diagnóstico8005 agora confirma warehouse_scenario_ready=true e replenishment_scenario_ready=true; client_configuration_complete=false preservado, pois não foi outorgado contexto comercial contratado. Provas history-task-integration[-pg/-http].json e logs respectivos. Sem bateria geral ou revisão visual completa.
|
||||
|
||||
Próximo passo operacional preparado, ainda não aplicado: pilot-submission-proposal.json propõe apenas submeter o mesmo rascunho por9, sem mudar2cx/23,20MZN e sem aprovar a compra. Ensaio final em cópia restaurada já com a estrutura instalada passou: estado pending, etapa department_head, único responsável actualmente elegível10 («Chefe de departamento — avaliação local»); tarefa recebida pelo chefe e removida da preparação do requisitante; mesma chave repetida sem duplicar passos. Todas as aprovações humanas permaneceram pendentes; artigos/valores/stock/ordens/acessos preservados. Cópia/base eliminadas. Prova pilot-submission-dry-run.json vinculada ao hash da proposta. A propriedade command_receipt_migration_tested_in_copy=false nessa prova final significa que a origem já tinha a estrutura instalada; o ensaio anterior instalou-a na cópia antes da aplicação técnica. Não interpretar como falta da migração no piloto. Pedir autorização apenas para esta submissão de negócio, excluída da autorização anterior; não para continuar implementação/testes correntes ou para reaplicar perfis/reposição já autorizados. Tarefas de sugestões, execução contratual e outros percursos especializados continuam cobertura por desenvolver.
|
||||
|
||||
## 02/11/2026 — consulta financeira nativa paginada, somente QA
|
||||
|
||||
Entregue NATIVE-PAYABLE-PAGED-READ-SIM-v1: adaptador sobre facturas, linhas, auditorias e pagamentos originais lidos conjuntamente por página; cálculo único no pacote comum, filtros/totais no servidor, factura específica conservada e leitura sem bloqueio de escrita. Tenant, contexto Compras, validade/manutenção e competências revalidados. Comandos usam fontes actuais. Configuração paged_read_enabled=false e pacote instalado preservados; QA usa explicitamente a fonte canónica. Pacote antigo com paginação recusa503. Sem activar piloto8005 ou SGF remoto obrigatório.
|
||||
|
||||
Provas:9testes novos/113asserções;26casos distintos afectados/183asserções (25válidos reutilizados e um alvo corrigido),18verificaçõesHTTP,PHPStan7 sem erros. Em10.000facturas: integral122.903,707ms/80.060consultas/62MiB; página25 75,117ms/76consultas/28MiB; página100 91,089ms/76consultas/28MiB. Uma factura de workflow com obrigação e três pagamentos, restantes cópias por reconhecer; não10.000dívidas. Sem índices novos. Leitor terminou antes da libertação do escritor, sem observar auditoria não confirmada. Original30MZN, stock/orçamento e estados preservados. Ver docs/financeiro-consulta-paginada.md e manifesto SGF docs/proofs/native-payable-paged-read-20261102.json.
|
||||
|
||||
Preservar provas válidas, seis registos protegidos, cache bloqueada, contas/configuração/piloto e trabalho alheio. Sem novas concessões/migrações/pagamentos/publicação/checkpoint. Revisão visual, pacote/activação, carga sustentada e capacidade de implantação continuam separadas. Os registos anteriores sobre paginação apenas SGF descrevem o estado histórico antes desta integração QA; não significam activação no destino. Eventuais índices exigem comparação separada em cópia sintética, sem aplicação por arrasto.
|
||||
|
||||
## 02/11/2026 — submissão autorizada e integração das sugestões de reposição
|
||||
|
||||
O proprietário respondeu «autorizo» à proposta exacta de submeter apenas REQ-2026-000002 pelo requisitante sintético9, sem alterar2cx/23,20MZN nem aprovar a compra. Autorização registada em pilot-submission-authorization.json, vinculada ao hash1be6f272b7df84605a0f1c5d72d75103ab31ab31475a6d791da9bb607503183f. Aplicada às19:20:53UTC: estado pending, etapa department_head, único responsável elegível10. Todas as decisões permanecem pendentes. Reserva orçamental canónica2320cêntimos, compromisso0; stock1cx, dados dos artigos, outras requisições, contas e perfis preservados. Não repetir a submissão nem voltar a solicitar esta autorização.
|
||||
|
||||
Aplicação pelo mesmo RequisitionWorkflow, sob bloqueio da empresa e controlo de versão, com recibo de comando. Antes de confirmar, backup consistente/restauro113tabelas e comparação de106tabelas protegidas; verificadas separadamente as demais requisições, entradas orçamentais anteriores e trabalhos de reposição de outros artigos/locais. Backup privado C:/laragon/data/sgf-tempo/backups/compras-pilot-replenishment-20261102-192049-fc98ad/before.dump, SHA9ea78c59e6d22160ad889e62b7d252b99085fb378af123a53a0173f66b1727ba; restauro descartável removido. Duas tentativas anteriores foram integralmente canceladas pelo verificador, que inicialmente não admitia os efeitos normais da submissão no orçamento e na fila de reposição. O verificador passou a conferir esses efeitos específicos, sem desactivar os controlos dos restantes dados. Só a aplicação final é prova de submissão. Artefactos pilot-submission-activation.json e pilot-submission-activation-http.json confirmam tarefa no chefe, desaparecimento da tarefa de rascunho, permissões e decisões pendentes. Sem nova migração, conta, grant, aprovação, encomenda, factura, pagamento ou alteração SGF neste incremento.
|
||||
|
||||
As sugestões manuais de reposição passaram a chegar às tarefas de conferência, conversão em rascunho e encerramento do acompanhamento. SupplySuggestions::canAct partilha a autoridade com o formulário; comandos continuam a recarregar actor e origens. A conferência exige independência de todos os preparadores. Converter exige supply_suggest_convert e competência de requisitante, e exclui quem conferiu. Valores, descritores e vínculos da sugestão aprovada são reutilizados; a compra continua rascunho e não recebe aprovação por conversão. Encerramento aparece apenas após rejeição da compra ou recepção completa pelos controlos existentes; não se fecha uma necessidade só por converter. Nenhuma competência especializada foi outorgada por consequência da integração.
|
||||
|
||||
Foco record_id valida empresa e tipo, mostra a última versão com aviso quando a ligação ficou antiga e conserva a história. Tarefas percorrem todas as fontes e usam paginação comum; a visão geral de sugestões mantém limite100. Não são inventados prazos, critérios favoráveis ou centros de custo. Fontes alteradas impedem aprovação/conversão silenciosa; devolução e manutenção/expiração mantêm os controlos anteriores. Consultar não decide nem cria tarefas num segundo motor.
|
||||
|
||||
Provas desta continuação:50testes/1024asserções na regressão dirigida e3/142em PostgreSQL descartável, base removida. Suites sobrepostas, não somar. Tipos, lint/build, PHPStan, Pint e18hashes passaram; HTTP de sugestões e tarefas confirmou administração em consulta e recusa dos perfis sem competências específicas. Sem sugestões manuais actuais no piloto; cenários de conferência/conversão/encerramento exercitados nas bases descartáveis. O encerramento novo foi testado pela rejeição da compra; o critério de recepção completa reutiliza ReceiptWorkflow e não constitui novo ensaio ponta a ponta de recebimento. Provas suggestion-task-integration[-pg/-http].json. Sem bateria geral/revisão visual completa ou implantação SGF; outros trabalhos concorrentes no repositório são preservados.
|
||||
|
||||
Próxima decisão operacional preparada, ainda não aplicada: pilot-approval-proposal.json propõe aprovação sintética por10 da mesma compra2cx/23,20MZN, conforme a única etapa congelada department_head. Prova pilot-approval-dry-run.json em cópia restaurada confirmou aprovação e repetição do comando sem duplicação, tarefa de consulta ao mercado no Procurement11, reserva2320/compromisso0 e preservação de contas/artigos/valores/stock/ordens. O compromisso orçamental pertence ao percurso posterior de emissão, não à aprovação da requisição; um pressuposto incorrecto inicial do ensaio foi corrigido antes da prova final, sem alterar o motor. A base/dump temporários foram eliminados. Aprovar a compra não está incluído na autorização de submissão e depende de autorização própria; selecção de fornecedor, adjudicação e encomenda não integram esta proposta. O estado pendente dos artefactos anteriores de submissão é histórico; não é motivo para pedir novamente o que já foi autorizado e aplicado. Desenvolvimento independente continua permitido; execução contratual e outras tarefas especializadas permanecem por consolidar.
|
||||
|
||||
## 02/11/2026 — aprovação sintética confirmada e tarefas de alternativas técnicas
|
||||
|
||||
O proprietário autorizou expressamente a aprovação de REQ-2026-000002 para consulta ao mercado, sem seleccionar fornecedor nem emitir encomenda. Autorização em pilot-approval-authorization.json, vinculada ao hashcf015e4110db66d4543fd14a5b8769b80bb6369a94d75026d12c04936923a1e7. Decisão registada uma única vez por10 às19:34:34UTC, estado approved, mantendo2cx/23,20MZN, reserva2320cêntimos e compromisso0. Procurement11 recebeu tarefa de completar consulta. Nenhum fornecedor foi seleccionado, nenhuma encomenda/factura/pagamento/movimento de stock foi criado, nem contas/grants/SGF alterados. Estados anteriores de aprovação pendente são históricos; não reaplicar ou pedir novamente autorização.
|
||||
|
||||
O aplicador verificou a tarefa como Procurement antes de terminar o callback pós-commit da decisão do chefe. Essa mudança de actor na ferramenta de verificação produziu403 depois de a aprovação já estar confirmada. A verificação posterior recusou repetir a decisão e identificou o único recibo imutável50990058-e957-4eb2-a5c6-271d3ea63bda e a auditoria. Corrigida a ferramenta para conservar o actor do comando até terminar o commit; não foi alterado o motor de aprovação nem contornada uma guarda funcional. Resultado confirmado por comparação com o restauro original anterior à decisão, sem replay do comando. Backup privado C:/laragon/data/sgf-tempo/backups/compras-pilot-replenishment-20261102-193430-6b25f8/before.dump, SHAe15b50b70e7b18fed3645223c319320b0b7137ea317efc27694abcafc665f313. Conferidas113tabelas restauradas e107tabelas protegidas, incluindo orçamento, stock, contas, itens e ordens; demais requisições preservadas. Restauro temporário removido. Provas pilot-approval-activation.json e pilot-approval-activation-http.json; approved_at vem da decisão e verified_at distingue a verificação posterior. Não descrever o erro posterior como reversão da aprovação nem executar novamente a decisão.
|
||||
|
||||
Alternativas técnicas integradas na categoria de fornecimentos/reposição das tarefas. SupplyCoordination::canReviewAlternative partilha a elegibilidade com os formulários; o comando revalida o actor e a independência de todos os preparadores. Exige supply_technical_review, sem herdar a competência de supply_review. Análise pendente ou origem alterada pode ser devolvida; a aprovação continua a exigir compatibilidade concluída, validade e especificações actuais pelos controlos anteriores. Aprovar uma análise não muda o sentido da relação, não torna um artigo incompatível elegível, não substitui automaticamente uma peça e não altera stock ou fornecedor. Catálogo dos perfis descreve a tarefa sem outorgar novos direitos.
|
||||
|
||||
Foco record_id na coordenação valida empresa/tipo e mantém acesso à última versão com aviso quando a ligação ficou antiga. Tarefas percorrem todas as pendências; a listagem geral continua limitada100. Acções técnicas por registo são projectadas pelo mesmo serviço; autor não vê autoaprovação. Reservas e entregas conservam as suas competências e escolhas existentes. Consulta não escreve nem decide. Sem criação de alternativas ou concessões técnicas nas contas do piloto.
|
||||
|
||||
Provas novas:55testes/1012asserções na regressão dirigida e3/110em PostgreSQL descartável,base removida. Suites sobrepostas,não somar. Tipos/lint/build/PHPStan/Pint/18hashes passaram. HTTP de alternativas confirmou administração em consulta e recusa dos perfis sem competência específica;0alternativas actuais. Cenários pendentes/independência/origem/manutenção/empresa exercitados apenas nas bases descartáveis. Provas alternative-task-integration[-pg/-http].json. Sem bateria geral ou revisão visual completa; preservar trabalhos concorrentes não relacionados.
|
||||
|
||||
Consulta actual do piloto tem1fornecedor elegível, enquanto a política de comparação já preservada exige3propostas. Proposta concreta pendente em pilot-market-proposal.json: criar2fornecedores inteiramente fictícios para o ensaio (NUITs de teste990000021/990000022,domínio example.test,sem documentos/identidade fiscal real confirmados), preparação por11 e activação independente por12, revisão até09/11/2026; registar3propostas fictícias reutilizando a linha aprovada2cx/IVA16%, preços unitários10/11/12MZN,totais23,20/25,52/27,84MZN,prazos2/3/4dias e validade09/11/2026. Não alterar a estimativa da requisição nem os mínimos de comparação. Sem comunicações externas, novas contas/grants, avaliação/seleção/adjudicação/encomenda ou SGF.
|
||||
|
||||
Ensaio em cópia restaurada da QA actual por pilot-replenishment-dry-run.php --market passou, usando SaveSupplierRequest/SupplierController para preparação e conferência e QuotationController para as propostas. Prova pilot-market-dry-run.json vinculada ao hash:2novos cadastros fictícios independentes,3propostas com totais previstos,0avaliações,nenhuma selecção/ordem e tabelas protegidas intactas; cadastro anterior preservado. Base/dump temporários removidos. Uma tentativa inicial usou nome incorrecto da tabela de avaliações no próprio verificador; corrigida para a relação canónica Quotation::evaluations e repetido o ensaio, sem alterar o motor ou a origem. Proposta não aplicada. A aprovação concedida abrangia a requisição; novos cadastros e condições comerciais artificiais do ensaio carecem de autorização própria. Esta pendência não bloqueia desenvolvimento técnico independente. Execução contratual e outras tarefas especializadas permanecem por consolidar.
|
||||
|
||||
## 02/11/2026 — consulta sintética aplicada e cadastro de fornecedores nas tarefas
|
||||
|
||||
O proprietário autorizou criar e validar dois fornecedores fictícios e registar as três propostas de teste, sem avaliar, seleccionar ou encomendar. Autorização em pilot-market-authorization.json vinculada ao hash99a4c5e4f0673cff8d1093768fedb1a95d389a0c497dacb7f60082f77057749d. Aplicação às19:56:43UTC em8005: fornecedores2/3 preparados por11 e activados independentemente por12, fornecedor existente1 reutilizado; propostas2/3/4 da REQ-2026-000002 com2cx,preços10/11/12MZN,IVA16%,totais23,20/25,52/27,84MZN. Estes são cadastros/identificadores/condições fictícios de ensaio, não identidades fiscais confirmadas, diligência real ou ofertas recebidas. Avaliações0, nenhuma selecção/adjudicação/encomenda/comunicação externa. Contas/perfis,requisição,stock1cx,reserva2320/compromisso0 eSGF preservados.
|
||||
|
||||
Aplicação atómica pelos mesmos controladores e validações do produto, usando o driver partilhado scripts/support/pilot-market-scenario.php também no ensaio descartável. O driver evita divergência entre simulação e aplicação, sem introduzir motor de negócio paralelo. Proposta ensaiada novamente após extracção do driver antes de aplicar. Snapshot consistente e restauro113tabelas conferidos;109tabelas protegidas e propostas/cadastro anteriores preservados. Cópia privada C:/laragon/data/sgf-tempo/backups/compras-pilot-replenishment-20261102-195637-0f5dde/before.dump, SHAeacc5f0f5525d1537944cf16509e8a14b4080c20944e9d60d03ec9b23fc30615; restauro descartável eliminado. Provas pilot-market-activation.json e pilot-market-activation-http.json confirmam três propostas e três tarefas de avaliação em cada perfil elegível Procurement/Finanças/chefe,sem qualquer avaliação executada. Não reaplicar ou solicitar de novo esta autorização; os estados pendentes no artefacto original são históricos.
|
||||
|
||||
Conferência de cadastro de fornecedor integrada nas tarefas de Compras/Fornecedores, reutilizando SupplierParticipation. Finanças mantém a competência existente, com independência do criador e do último editor; acumular Compras/Finanças não permite auto-conferência. Só fichas pending entram na fila; datas de revisão não foram transformadas em novas atribuições periódicas. Ligações abrem a ficha canónica e acção da versão actual; formulário antigo continua recusado pelo controlo de versão. Fichas activas/suspensas conservam as operações já permitidas por Finanças, sem serem tratadas como novas pendências. Impedimento ou revisão vencida continuam a bloquear activação, mas permitem a suspensão prevista. Nenhuma concessão ou cadastro adicional foi feito por consequência do desenvolvimento.
|
||||
|
||||
Preparação, edição e conferência recarregam o actor depois do bloqueio da empresa, antes da gravação; formulário/política/tarefa reutilizam a mesma autoridade. Função revogada após validar o formulário não é emprestada pela instância antiga de User. Acesso de manutenção consulta sem preparar/editar/decidir; leitura de documentos continua pelo Gate anterior. A ficha ligada às tarefas usa história Inertia cifrada e resposta privada sem armazenamento. DTO da tarefa não transporta NUIT,contactos,beneficiários ou documentos; consulta não escreve nem decide. Fila percorre todos os registos e pagina25, incluindo105fichas pendentes no ensaio.
|
||||
|
||||
Provas novas:94testes/1276asserções na regressão dirigida (manutenção/cotações/avaliação/banco/tarefas/rastreabilidade), mais teste isolado de actor revogado1/2 e teste da ficha privada1/66. PostgreSQL final5/153aprovados em base descartável removida; a primeira execução4/151 precede o caso adicional. Suites sobrepostas,não somar. Tipos/lint/build/PHPStan/Pint/18hashes passaram. A resposta privada foi acrescentada depois da regressão ampla e conferida pelo caso dirigido1/66,HTTP e análise estática do controlador; a regressão ampla não é declarada repetida. HTTP de três perfis confirmou fichas activas,competências e0pendências de cadastro actuais; requisitante sem consulta de fornecedores recebeu403. Artefactos supplier-task-integration[-pg/-http].json e logs respectivos. Sem nova migração,conta,grant,bateria geral,revisão visual completa ou alteração SGF; preservar trabalhos concorrentes alheios.
|
||||
|
||||
Próxima etapa operacional preparada e ainda não autorizada: pilot-evaluation-proposal.json. Propõe seis avaliações inteiramente fictícias das propostas2/3/4, por Finanças12 e chefe10, com5,00/10 iguais em qualidade,histórico e pagamento. Não representam mérito ou desempenho reais. Preço,prazos,pesos e mínimo de dois avaliadores qualificados provêm dos dados e política já preservados, sem os alterar. Ensaio em cópia restaurada da QA actual passou pelos controladores canónicos: seis registos,duplicação da mesma pessoa recusada,comparação pronta e tarefa de conferência humana no Procurement11. Nenhuma selecção/adjudicação/encomenda; cadastros/propostas/contas/stock/orçamento intactos. Base/dump temporários removidos. Prova pilot-evaluation-dry-run.json vinculada ao hash9c6f5004c81030e1ea482e6f5c2c2bf4ed24638886cd9dbe8446e09a2a6f73fa. Um erro inicial de imports no simulador foi corrigido antes da execução final aprovada, sem comando de negócio na origem. A autorização anterior excluiu expressamente avaliar: solicitar autorização própria apenas para estes seis dados sintéticos; não para desenvolvimento técnico corrente. Execução contratual e outras tarefas especializadas continuam por consolidar.
|
||||
|
||||
## 02/11/2026 — continuação independente: ocorrências físicas, estornos e controlo por lotes
|
||||
|
||||
O proprietário reiterou continuação do desenvolvimento e integração, sem autorizar as avaliações fictícias expressamente excluídas na etapa anterior. Prosseguido o trabalho técnico independente. Não repetir a mesma solicitação de avaliações a cada incremento nem transformar essa pendência operacional em bloqueio geral. O piloto mantém REQ-2026-000002 aprovada, três propostas e zero avaliações; nenhuma etapa já autorizada foi reaplicada.
|
||||
|
||||
Devoluções a fornecedores e abates físicos passaram a encaminhar conferência e execução nas tarefas do armazém. Estornos integrais de operação e de linha de recepção foram ligados à mesma fila. Os comandos continuam em InventoryDispositions, InventoryReversals e no escritor canónico StockWorkflow; não há outro movimento, aprovação, factura ou compensação financeira. InventoryReviewParticipation partilha somente elegibilidade: última versão, empresa, competência original, independência de todos os preparadores na decisão e execução por pessoa diferente de quem aprovou. O preparador pode continuar a executar quando o percurso anterior o permite e for diferente do conferente; não se inventa uma obrigação de três intervenientes. Funções/granularidade existentes preservadas, sem novas concessões.
|
||||
|
||||
Consultar ou aprovar não muda stock. Confirmar a execução física reutiliza origem, documento e aprovação; repetição do mesmo comando não duplica saída ou estorno. Correcções preservam documentos e movimentos originais e mantêm conferência financeira separada. Origem ou saldo inválidos continuam a impedir execução. A projecção executionSourceCurrent reutiliza basis dos motores: operador recebe tarefa bloqueada e não vê confirmação física nesse estado; conferentes independentes recebem a acção de devolução já prevista no percurso, sem qualquer devolução automática. Se a origem voltar a ser válida, o impedimento deixa de ser projectado. A projecção verifica a base corrente; o escritor conserva a última palavra e revalida as demais condições antes de movimentar.
|
||||
|
||||
Ligações record_id de ocorrência/estorno validam empresa e tipo, alcançam pendências antigas e mostram última versão com aviso quando o endereço ficou antigo. Actores recebem acções por registo do mesmo resolvedor usado pelos comandos. História Inertia cifrada e resposta privada/no-store. Fila comum completa e paginada25, com105pendências ensaiadas; as listagens gerais de ocorrências/estornos continuam limitadas100. Nenhuma tarefa persistida num segundo motor, prazo fictício ou preenchimento repetido da origem.
|
||||
|
||||
Configurações e revisões do controlo por lotes passaram a chegar à conferência independente inventory_lot_review. Preparação do próprio conferente ou de qualquer outro preparador anterior não pode ser activada por essa pessoa. O comando mantém validação do saldo, configuração activa e assinatura da identificação/disponibilidade. Revisão pendente conserva o controlo anterior em vigor, que permanece visível juntamente com a proposta no foco. Activar não cria movimento físico, não duplica repartição numa revisão e não liberta qualidade automaticamente; estado held continua dependente do percurso de qualidade. Não foram acrescentadas tarefas de identificação/hold/release nem presumidas obrigações de libertar material. Visão geral de configurações continua limitada100por consulta e histórico200; não declarar essa história exaustiva. Pendências usam varrimento completo e foco canónico.
|
||||
|
||||
Foi reproduzida uma pendência obsoleta: duas preparações paralelas e activação de uma delas deixavam a outra na fila, embora o comando já recusasse activá-la. canActivate agora compara a configuração em vigor com previous_setup_id da preparação, tal como a guarda existente; preparação ultrapassada mantém o seu registo histórico, sem tarefa executável. Reprovação esperada do teste inicial em lot-obsolete-reproduction.txt, seguida de correcção e seis casos aprovados em SQLite/PostgreSQL. Não se cancelou ou reescreveu a história nem se alterou a aprovação da configuração vencedora.
|
||||
|
||||
Evidência final:86testes/1244asserções na regressão consolidada de lotes/políticas/devoluções/estornos/requisições/tarefas/rastreabilidade; PostgreSQL10/441para correcções físicas. Após esse conjunto, o filtro final de preparação obsoleta foi verificado nos6casos dirigidos de lotes,6/199em SQLite e6/199em PostgreSQL; não declarar nova execução dos86casos depois dessa pequena correcção. Bases descartáveis removidas. Suites sobrepostas,não somar. Evidências intermédias70/770,75/999,82/1184e anteriores10/413ou5/179 são fases anteriores, não nova bateria geral. O primeiro teste de imutabilidade de operação comparava atributos ainda não hidratados e falhou por chaves nulas/ordem; passou a carregar o registo antes de ambas as comparações e as execuções aprovadas confirmam preservação exacta, sem alterar o motor. Uma falha de teste não é prova de escrita no piloto.
|
||||
|
||||
Tipos/lint/build/PHPStan/Pint e18hashes comuns passaram. HTTP em8005 confirmou as interfaces e recusas dos perfis sem competências: administração em consulta de ocorrências/estornos/lotes; armazém com execução nativa de correcções, sem preparação/conferência adicionais; demais perfis sem essas competências recusados. Não foram concedidas tarefas de lotes por arrasto do papel de armazém. Fontes pendentes/decisões/movimentos foram exercitados apenas nas bases descartáveis;0ocorrências,estornos e configurações de lotes no piloto. Provas inventory-task-integration[-pg/-http].json, lot-task-integration[-pg/-http].json e logs correspondentes. warehouse-task-pilot-status-http.json confirmou três propostas com evaluations=[] em todas, comparação ainda não pronta,requisição approved/23,20MZN e saldo físico1cx. Sem comando de negócio persistente, migração, nova conta/grant, contacto externo, selecção, encomenda, alteração SGF, bateria geral ou revisão visual completa nesta continuação.
|
||||
|
||||
Próxima continuidade: manter as seis avaliações fictícias dependentes da autorização própria já apresentada; continuar independentemente pelos restantes encaminhamentos nativos (por exemplo ocorrências de qualidade, esclarecimentos/medidas de fornecedores e execução contratual), confrontando capacidades com os respectivos motores. Não inferir contas, alçadas, responsáveis, notas favoráveis, documentos ou regras comerciais. Preservar outros trabalhos concorrentes no repositório e não declarar concluída toda a proposta funcional.
|
||||
|
||||
## 02/11/2026 — seis avaliações autorizadas e tarefas de medidas de melhoria
|
||||
|
||||
Autorização expressa do proprietário aplicada uma única vez em8005 às21:09:06UTC: seis avaliações fictícias das propostas2/3/4 de REQ-2026-000002,pelas contas existentes12(Finanças)e10(chefe de departamento),com5/10 em qualidade,histórico e pagamento. Registos1a6;comparação pronta e tarefa de conferência humana para Compras11. Sem seleccionar,adjudicar,encomendar ou comunicar externamente. Provas pilot-evaluation-authorization/activation/activation-http.json;proposta original preservada pelo SHA9c6f5004c81030e1ea482e6f5c2c2bf4ed24638886cd9dbe8446e09a2a6f73fa. Backup41c3d932c2d364da30841429267e2ebf3bf4ae79e416eaf54dda8603cb3def7d restaurado e conferido113tabelas,111protegidas;sem mudar contas/grants,stock,compromisso ou SGF. HTTP confirmou seis notas neutras,ausência das tarefas já cumpridas e requisição ainda approved/23,20MZN. Os estados pendentes/zero avaliações nas secções anteriores são históricos; não repetir estas operações.
|
||||
|
||||
Integração adicional: medidas de melhoria ligadas a avaliações de qualidade aprovadas passam a alimentar a lista de tarefas de Compras. Execução apenas para o responsável já designado;conferência apenas para pessoa independente de todos os contribuidores. Devolução devolve a pendência ao responsável;encerramento retira-a da lista. Reutilizados prazo,referência,versão,estado,evidência e ligação directa #medida-ID da página nativa,sem criar tabela de tarefas,motor de decisão,novos campos obrigatórios ou novas permissões. A lista percorre todos os pendentes em lotes,sem corte nos100registos;continua a usar paginação existente da caixa de tarefas. A fonte aprovada conserva-se imutável. Este acompanhamento de qualidade é distinto das seis avaliações de propostas autorizadas acima.
|
||||
|
||||
SupplierImprovementWorkflow.canAct partilhado por tarefas,página e comandos,com empresa,departamento,funções,conflitos e modo de manutenção revalidados. CanParticipate passou a recusar explicitamente manutenção e âmbito inadequado,também reutilizado nas respostas do fornecedor. Operador dos comandos continua actualizado dentro da transacção. Controller de avaliações passou a exigir utilizador interno autenticado,eliminando ambiguidade com conta de candidato. Sem alterações à sequência de aprovação,delegações ou regras de encerramento.
|
||||
|
||||
Validação final:52testes/819verificações aprovados(SupplierImprovement,SupplierEvaluation,SupplierResponse,SupplierImprovementReport,WorkflowTaskInbox),incluindo5cenários de encaminhamento;estes5também passaram isolados em SQLite57verificações e PostgreSQL descartável57verificações,com remoção da base confirmada. Não somar execuções sobrepostas. PHPStan0erros,Pint e18hashes de execução aprovados. HTTP com Compras,Finanças e chefe confirmou consulta cifrada e caixa de tarefas;as2avaliações de qualidade já existentes foram apenas consultadas,sem novas medidas de piloto. Provas supplier-improvement-task-integration-pg/http.json e logs supplier-improvement-task-*. Sem alteração frontend,novo build,bateria geral ou revisão visual completa nesta etapa.
|
||||
|
||||
Continuidade: desenvolver os restantes encaminhamentos nativos, incluindo contraditório e avaliações de qualidade em preparação/conferência,sem inferir decisões ou criar dados operacionais. Selecção de fornecedor/adjudicação/encomenda permanecem fora da autorização;isso não bloqueia desenvolvimento técnico independente. Preservar alterações concorrentes de contas a pagar e demais módulos.
|
||||
|
||||
## 02/11/2026 — encaminhamento de avaliações de qualidade e contraditório concluído nesta etapa
|
||||
|
||||
A pedido do proprietário para executar tarefas que aproximem a conclusão do produto, integrados dois percursos já existentes na caixa de tarefas de Compras: preparação/submissão e conferência das avaliações qualitativas de fornecedores; preparação/submissão e análise independente dos esclarecimentos/contraditórios. Estas avaliações qualitativas não são as seis avaliações das propostas do piloto. Não há criação automática de avaliação,declaração,nota,decisão ou prazo.
|
||||
|
||||
SupplierEvaluationWorkflow.canAct e SupplierResponseWorkflow.canAct partilham a elegibilidade entre comandos,detalhe e tarefas: empresa,departamento,função actual,conflitos e independência de todos os contribuidores. Rascunhos/devoluções são encaminhados apenas aos contribuidores ainda elegíveis; isso não restringe a edição colaborativa já admitida no motor. Revisão chega às pessoas elegíveis independentes;devolução devolve a tarefa à preparação;aprovação/conclusão retira-a. Cada tarefa aponta à versão corrente da avaliação ou à âncora nativa #contraditorio-ID,sem copiar argumentos,evidência ou conclusão para a lista. Versão integra a identidade da tarefa,sem tabela de pendências paralela. Fila percorre todos os registos em lotes e conserva paginação25,pesquisa e pendências antigas,com105casos de cada percurso exercitados. Consultas não escrevem auditoria nem decisões;aprovação anterior conserva-se imutável.
|
||||
|
||||
Acrescentada relação/âmbito autorizado SupplierResponse.evaluation/visibleTo,reutilizando a visibilidade da avaliação,sem migração. Preparação de avaliação bloqueia manutenção também no servidor;canPrepare alimenta canCreate e oculta o formulário nessas contas. Leitura continua disponível segundo os direitos existentes. Descrição das responsabilidades qualitativas acrescentada ao catálogo dos quatro papéis já admitidos pelo motor,sem concessão adicional. Texto da interface deixou de apresentar esclarecimentos/medidas já implementados como indisponíveis. Sem novos campos obrigatórios,sequência de aprovação ou perfis.
|
||||
|
||||
Validação final:76testes/1276verificações aprovados na regressão SupplierEvaluation,SupplierResponse,SupplierImprovement,SupplierImprovementReport,WorkflowTaskInbox e InternalRequisitionCandidate. Onze cenários novos passaram também em PostgreSQL descartável,180verificações,com remoção da base confirmada. Incluem ciclo completo,devolução,preparação colaborativa,segregação,empresa/departamento,conflitos,manutenção/vigência,revogação de função com instância antiga,paginação e imutabilidade. As execuções intermédias61/977,74/1254 e PG9/158 são anteriores e sobrepostas,não somar. PHPStan0erros,Pint,tipos,lint,build e18hashes comuns aprovados;diff dos ficheiros desta etapa sem erros de espaços.
|
||||
|
||||
HTTP em8005 confirmou a caixa de tarefas cifrada e a preparação disponível para os papéis operacionais existentes. Não existem actualmente tarefas qualitativas elegíveis nesses três perfis do piloto;por isso os percursos pendentes foram validados nas bases descartáveis,sem inventar novos registos no piloto. Confirmadas as seis avaliações de propostas anteriores e comparação pronta,sem seleccionar/adjudicar/encomendar. Provas supplier-quality-task-integration[-pg/-http].json e logs supplier-quality-task-*. Nenhuma migração,conta/grant,alteração SGF,contacto externo,bateria geral ou revisão visual completa executados nesta etapa.
|
||||
|
||||
Pendências de continuidade: encaminhamento de qualidade/identificação/libertação de lotes e execução dos fornecimentos;paginação das consultas gerais ainda limitadas100/históricos200;parametrização das regras opcionais de reservas;instalação comercial do serviço periódico e validações finais de capacidade/recuperação/ecrãs/impressão. Não declarar a aplicação inteira concluída nem confundir funções existentes sem ensaio completo com módulos inexistentes. Preservar alterações concorrentes de contas a pagar e demais módulos. As avaliações operacionais autorizadas já aplicadas não devem ser repetidas.
|
||||
|
||||
## 02/11/2026 — acompanhamento de fornecimentos e paginação da coordenação
|
||||
|
||||
Executado novo incremento de conclusão funcional a pedido do proprietário: reservas de necessidades e entregas confirmadas passam à caixa de tarefas de Fornecimentos/reposição pelas competências existentes supply_reserve/supply_delivery. A reserva tratada aqui é de planeamento,distinta da reserva física warehouse_reservations das requisições internas. A tarefa encaminha acompanhamento,actualização/cancelamento ou associação de uma saída efectiva já existente;não bloqueia stock físico,não recebe automaticamente,não repete movimentos,não selecciona fornecedor nem emite ordem. Prazo reutiliza needed_on/expected_on sem inferir prioridades ou expiração.
|
||||
|
||||
SupplyCoordination.canManage partilhado entre tarefas,página e comandos de coordenação: empresa,competência vigente,manutenção,última versão e estado actual. Tarefa de reserva só enquanto existe necessidade efectiva pendente;tarefa de entrega enquanto falta quantidade perante os recebimentos canónicos. Cancelamento encerra a pendência sem apagar a versão anterior. Estorno de saída torna a necessidade novamente pendente pelo cálculo nativo effectiveApplications,sem reabrir ou alterar o registo fulfilled histórico;uma nova saída autorizada pode satisfazer o saldo. Competência de acompanhamento não concede armazém,recepção ou autorização adicional. DTO de tarefa mínimo,liga ao foco/última versão existente e preserva o histórico,sem tabela paralela ou preenchimento repetido.
|
||||
|
||||
As consultas de coordenação alternativas/reservas/entregas deixaram o corte100:paginação25 com total,anterior/seguinte e parâmetro records_page validado. Foco record_id mantém acesso directo à versão actual,independentemente da página;nenhum formulário novo no foco. Fonte de ordem/requisição seleccionada no foco é consultada explicitamente para preservar a edição de origens antigas,sem depender dos últimos100documentos gerais. As listas gerais de escolha de origem/saídas ainda têm limites100;isso não equivale a todos os selectores/históricos paginados. Sem alterar os demais ecrãs de SupplyPlanning nem prometer paginação global concluída. Responsabilidades supply_reserve/supply_delivery descritas no catálogo dos perfis com as permissões existentes;texto da interface clarifica planeamento vs reserva física.
|
||||
|
||||
Validação final52testes/898verificações aprovados em SupplyCoordination,InventoryReversals,SupplyPlanning e WorkflowTaskInbox. Seis cenários de coordenação passaram também em PostgreSQL descartável107verificações,com base removida. Exercitados satisfação parcial/integral por saídas,recepção parcial/integral,cancelamento idempotente,estorno e nova satisfação,empresa,tipo de foco,manutenção/vigência,105pendências,paginação da caixa e consulta,foco antigo,consulta sem auditoria/movimento e preservação histórica. A primeira preparação dos105registos de teste omitia created_at ao replicar um modelo sem timestamps automáticos;corrigida apenas a fixture e reexecutadas as provas finais. A falha não corresponde a operação no piloto. PHPStan0erros,Pint,tipos,lint,build,diff e18hashes comuns aprovados. Não somar execuções intermédias ou os testes PG sobrepostos à regressão.
|
||||
|
||||
HTTP8005:administraçao consulta as três páginas com paginação,sem preparação operacional;armazém/Compras/Finanças sem competências específicas receberam403,conforme configuração actual preservada. Nenhuma tarefa nova de coordenação pendente nesses perfis:cenários operacionais exercitados só nas bases descartáveis. Não criar grants,previsões,reservas,recepções ou movimentos no piloto para forçar demonstração. Provas coordination-task-integration[-pg/-http].json e logs coordination-task-*. Sem migração,conta nova,contacto externo,alteração SGF,decisão comercial,bateria geral ou revisão visual completa.
|
||||
|
||||
Próximas lacunas:encaminhamento de identificação/retenção/libertação de lotes,paginação das restantes consultas gerais e selectores,instalação comercial resiliente do serviço periódico e validação final de capacidade/recuperação/ecrãs/impressão. Acompanhamento de acordos,execução contratual,importações e cobertura integral dos documentos base devem continuar confrontados com o código,sem declarar todos concluídos por esta integração. Preservar mudanças concorrentes de contas a pagar e demais módulos. As autorizações e avaliações de propostas anteriores continuam efectivas e não devem ser repetidas.
|
||||
|
||||
|
||||
## Ciclo contabilistico comum sintetico - entrega autorizada
|
||||
|
||||
Adaptador SGC e interface comum implementados: reconhecimento60, afectacao20/saldo40, contabilizacao, reversao/saldo60, par correctivo imutavel e fecho QA. Demo proprio http://127.0.0.1:8051/qa/ledger-demo com tres funcoes e base nova, sem efeitos de negocio iniciais. Ver docs/contabilidade-ciclo-sintetico.md e relatorio conjunto SGF. Provas nativas:23 controlos de contrato revertidos,61HTTP,10finais e28de preparacao; fontes/stock/orcamento externos preservados. Concessoes apenas QA, destino desactivado, sem alterar piloto8005 ou candidatas. Revisao visual, carga de implantacao, uso/fiscalidade reais e aceitacao separados; sem publicacao/checkpoint presumidos.
|
||||
|
||||
|
||||
## Composicao autonoma do nucleo financeiro - QA
|
||||
|
||||
Artefacto com25ficheiros de runtime, manifesto SHA256 fixado e verificacao antes do arranque, sem fallback quando alterado. FinanceBundle.configure e opt-in apenas em base/role nao elevada do cluster55439; sem root conserva composicao anterior e nao activa direitos/contabilidade. Demo nova8052, sem substituir8051/8005 ou pacote instalado. Provas:9contrato/escrita/replay,6integridade,4recusas no arranque e28preparacao do demo; PHPStan0erros nos2ficheiros novos. Ver SGF docs/COMMON_FINANCE_BUNDLE_DELIVERY.md. Sem dados/credenciais no artefacto, migracao no destino, publicacao ou checkpoint.
|
||||
|
||||
## 02/11/2026 — encaminhamento da identificação e qualidade dos lotes
|
||||
|
||||
Implementado acompanhamento na caixa de tarefas de Armazém sobre as configurações activas e o contexto canónico InventoryLots: identificação pendente para inventory_lot_prepare; conferência de lote retido elegível para inventory_lot_release independente dos contribuidores; conferência de retenção para inventory_lot_hold quando uma libertação anterior existe mas a validade actual é insuficiente. Não são atribuídas retenções a todos os lotes libertados saudáveis nem inventados prazos,prioridades,novos perfis ou decisões. O vencimento é lido pela data actual sem exigir movimento físico;criar/consultar tarefa não grava decisão nem aviso persistente.
|
||||
|
||||
canIdentify/canDecideLot partilham elegibilidade entre comandos nativos,interface e tarefas: empresa,competência vigente,manutenção,versão de identificação,saldo repartido conferido,quantidade positiva e independência/validade para libertar. Mantidas verificações finais de versão e state_version no comando sob bloqueio da empresa. Identificação de lote sem saldo continua possível no motor quando já era permitida;apenas não gera tarefa. A identificação corrigida invalida a libertação anterior conforme o motor existente,sem alterar a decisão histórica. A dispensa de quarentena na recepção continua dependente da configuração aprovada existente;as novas tarefas não impõem nova aprovação nesse percurso.
|
||||
|
||||
Novas ligações de foco lot_id+warehouse_id validam identidade inicial do lote,empresa,armazém,configuração activa e presença nesse local;abrem a identificação mais recente e a âncora estável lot-ARMAZEM-ID,mesmo com link antigo ou mais100pendências. Não misturar esse foco com record_id de configuração. Tipo numérico do identificador normalizado na resposta. Ligações antigas de configuração permanecem válidas;regra de exclusão corrigida para Rule::prohibitedIf suportada na versão instalada. Interface usa acções por lote da mesma autoridade;permite a retenção explícita de uma libertação já expirada,sem restaurar a disponibilidade pelo simples acesso. Descrições das tarefas de identificação,libertação e retenção acrescentadas aos perfis existentes,sem grants.
|
||||
|
||||
Validação funcional abrange identificação→conferência→libertação,contribuidores de recepção,expiração sem movimento e retenção explícita,correcção posterior/versão antiga,empresa e par de foco/manutenção/vigência,saldo não reconciliado,105lotes em100partições iniciais+5de recepção nativa,paginação da caixa,política aprovada de recepção e lotes sem saldo. O saldo não reconciliado é injectado na leitura no teste:os triggers recusaram correctamente a tentativa inicial de preparar uma repartição impossível,não foram desactivados ou contornados. Expectativas antigas passam a reconhecer tarefas distintas de conferência da configuração e qualidade do saldo activo,sem alterar o estado ou a aprovação do processo. A evidência final desta execução é registada a seguir após a conclusão da regressão.
|
||||
|
||||
No piloto8005 apenas consultas:administração continua só de leitura e os outros perfis sem competências específicas continuam403;nenhum lote/configuração/grant/decisão/movimento criado para demonstração. Prova HTTP lot-quality-task-integration-http.json. As validações operacionais permanecem nas bases descartáveis. Listagens gerais de configurações/histórico de lotes ainda conservam os limites anteriores100/200;foco e caixa paginada não equivalem a paginação integral desses históricos. Sem alteração SGF,selecção,adjudicação,encomenda ou contactos externos.
|
||||
|
||||
### Evidência final — qualidade de lotes, 02/11/2026
|
||||
|
||||
Regressão final aprovada:99testes/1578verificações em InventoryLots,InventoryLotPolicy,InventoryReversals,InventoryDispositions,WarehouseFulfilment e WorkflowTaskInbox. Oito cenários específicos passaram em PostgreSQL descartável106verificações,com remoção da base confirmada. Execuções intermédias falhadas e o ensaio8/105 são anteriores/não somar. Foram corrigidos o tipo numérico do foco,a regra de validação das ligações e as expectativas dos testes de configuração,que agora reconhecem também a tarefa separada de libertação do saldo existente. Nenhuma falha de teste foi apresentada como decisão operacional aplicada. O cenário de leitura não reconciliada injecta a condição no teste e conserva os triggers físicos efectivos.
|
||||
|
||||
Tipos,lint,build,Pint,PHPStan0erros,diff e18hashes comuns aprovados. O primeiro controlo de tipos detectou a âncora a usar warehouse_id fora de data;corrigido para a origem já usada na página e repetidos tipos/build. Provas lot-quality-task-integration[-pg/-http].json e logs lot-quality-task-*. Consulta HTTP com quatro perfis confirmou acesso de leitura administrativo,recusas operacionais sem competência e ausência de novas tarefas/lotes no piloto. As ligações e decisões com pendências foram testadas nas bases descartáveis. Não equivale a revisão visual completa,teste de carga,bateria geral de todos os módulos,aceitação real ou instalação SGF.
|
||||
|
||||
Próxima continuidade técnica:paginar as consultas gerais de configurações/histórico de lotes e as restantes consultas/seletores ainda limitados;consolidar o arranque e recuperação do serviço periódico para instalação comercial;confrontar a cobertura de acordos/importações/execução contratual com os documentos base;validar capacidade,recuperação,relatórios,impressões e percursos por perfil. As tarefas de identificação/libertação/retenção aqui descritas deixaram de ser uma lacuna de encaminhamento. Não criar automaticamente concessões ou decisões no piloto para as tornar visíveis. Preservar aprovações vigentes,os percursos distintos de Compras/Pessoas e alterações concorrentes. O desenvolvimento e a integração interna mantêm autorização;novas decisões operacionais continuam a exigir o seu âmbito próprio.
|
||||
|
||||
## 03/11/2026 — consultas de lotes paginadas, sem separar controlo activo da revisão
|
||||
|
||||
Retirados os limites fixos100configurações/200registos históricos da página /stock/lotes. As configurações paginam25identidades de controlo por página;para cada identidade são carregadas a última versão e a configuração activa. Assim a revisão pendente e o controlo em vigor não se separam na fronteira da página. A contagem corresponde a controlos, podendo existir até duas versões visíveis por controlo. O foco de configuração/lote mantém acesso directo sem paginação de controlos. A lista de lotes de cada contexto continua integral nesse detalhe,não é um paginador individual por lote.
|
||||
|
||||
Histórico paginado50registos,com total e navegação anterior/seguinte. controls_page/history_page independentes,validados e conservados nas ligações, juntamente com o foco. A segunda página do histórico abre o respectivo detalhe automaticamente. O histórico mantém o âmbito empresarial autorizado anterior;esta etapa não acrescenta pesquisa,filtros ou exportação. A leitura da página passou a transacção coerente e somente de leitura em PostgreSQL,sem bloqueio de escritor nem auditoria/movimento gerados em GET.
|
||||
|
||||
Validação final51testes/821verificações aprovados em InventoryLots,InventoryLotPolicy e WorkflowTaskInbox. Os três cenários novos passaram também em PostgreSQL descartável98verificações,com base removida. Cobrem210controlos/registos de histórico,alcance das páginas antigas,preservação de parâmetros,foco directo,par activo+revisão na fronteira,empresa,páginas inválidas e leitura sem alteração de dados. A expectativa antiga100registos foi ajustada para25por página com105no total e acesso à quinta página. Tipos,lint,build,Pint,PHPStan0erros,diff e18hashes comuns aprovados. Provas lot-pagination[-pg/-http].json e logs lot-pagination-*. HTTP confirmou paginação vazia administrativa e recusas403 dos perfis sem competências;nenhum novo dado/grant no piloto.
|
||||
|
||||
A regressão99/1578 e PG8/106 da etapa de qualidade imediatamente anterior continuam evidência própria dessa etapa,antes desta paginação;os51/821são a regressão final posterior da leitura alterada. Não somar provas sobrepostas nem declarar nova bateria integral dos módulos. Sem migração,aprovação de negócio,selecção,ordem,alteração SGF,contacto externo ou revisão visual completa.
|
||||
|
||||
Continuar pelos restantes selectores/consultas gerais ainda limitados,preparação comercial do serviço periódico e recuperação,confronto da execução contratual/acordos/importações com os documentos base e validação final de capacidade,relatórios,impressões e percursos. As consultas gerais de configurações/histórico de lotes e o encaminhamento de qualidade deixaram de estar pendentes. Preservar aprovações e separação dos módulos;novas competências ou decisões do piloto não são concedidas por inferência.
|
||||
|
||||
## 03/11/2026 — paginação de fornecimentos e preservação das origens escolhidas
|
||||
|
||||
Retirado o corte fixo100 das consultas de acordos,políticas/calendário,análises de consumo,sugestões e processos de importação. RecordPage partilhado apresenta25identidades/últimas versões,contagem,navegação anterior/seguinte e records_page validado. Record_id conserva foco directo na última versão,sem depender da página,nem reintroduzir dados das origens. Componente de paginação partilhado nas três páginas de fornecimentos,sem novo motor de tarefas ou permissões. Consultas de coordenação,que já tinham paginação,mantêm o percurso próprio existente. A página de fornecimentos passou a leitura coerente,somente de leitura em PostgreSQL;projecções e contagens usam o mesmo estado sem bloquear operações de stock.
|
||||
|
||||
As opções aprovadas de análise histórica/política passam a incluir as origens já usadas pelos registos visíveis,mesmo quando ficaram fora das100escolhas recentes. Só a última versão ainda aprovada é oferecida;uma suspensão remove a escolha e conserva a referência histórica no documento anterior. Nenhum GET altera snapshots,notas,pesos,aprovações,compras ou razão de stock. As100escolhas recentes continuam uma janela de apresentação,não uma promessa de selectores todos paginados. Acordos e catálogos ainda mantêm as capacidades/listas existentes. Não declarar toda a parametrização/escolha de origens concluída por esta etapa.
|
||||
|
||||
Preparação de importações ganhou pesquisa opcional da ordem pelo número ou parte do número,aplicada antes da janela100,com parâmetros de pesquisa vinculados e comparação sem distinguir maiúsculas. Mantém no conjunto a ordem actualmente seleccionada/as ordens dos processos visíveis. Só quem já pode preparar recebe as opções;selected_order_id é validado por empresa e os leitores não recebem o selector. A pesquisa actualiza apenas orders/orderSearch via Inertia,preserva dados do formulário,página de registos e posição;Enter na pesquisa não submete o processo. Continua a usar a ordem canónica e o comando nativo de importação,que impede duplicação e exige registo antes da primeira recepção.
|
||||
|
||||
Os testes incluem105registos por vista,quinta página/foco antigo,isolamento,páginas inválidas,vigência/manutenção,versões de importação,origens aprovadas fora da janela recente,retirada da opção quando suspensa,referências imutáveis,pesquisa/sem resultados/ordem seleccionada,entradas com apóstrofo,comprimento e empresa/leitura sem preparação. A primeira fixture de importação já tinha recepção completa e foi correctamente recusada pelo motor;substituída por uma fixture nova sem recepção,não se enfraqueceu essa regra. As expectativas antigas100registos passaram a25por página e contagens totais. Os resultados finais desta execução são registados após a conclusão das verificações.
|
||||
|
||||
Piloto8005 apenas consultado nos perfis existentes,sem grants,cadastros,importação,aprovação,selecção,ordem ou movimento novo. RootAGENTS recebeu noutro trabalho autorização do ciclo contabilístico sintético em8051;esse âmbito paralelo é preservado e não alterado por esta etapa,assim como o SGF real. Prova HTTP supply-pagination-http.json cobre as cinco vistas e acessos actuais;os cenários com volume e decisões de teste só nas bases descartáveis. Sem revisão visual completa,teste de carga ou nova execução geral de todos os módulos.
|
||||
|
||||
### Evidência final — consultas de fornecimentos e pesquisa de encomendas, 03/11/2026
|
||||
|
||||
Regressão final73testes/1378verificações aprovada em SupplyPagination,SupplyPlanning,SupplyHistory,SupplySuggestions,SupplyCoordination e SupplyTaskIntegration. Catorze cenários dirigidos passaram também em PostgreSQL descartável356verificações,com remoção da base confirmada. Incluem a suspensão posterior das origens:deixam de ser oferecidas para reutilização,mas os documentos preservam o identificador e os dados anteriores. As fases70/69aprovados,72/1329 e PG13/280ou307 são anteriores/sobrepostas,não somar nem declarar bateria geral. O único erro da preparação inicial de importação resultou de fixture já recebida;foi corrigida a fixture sem alterar a exigência nativa.
|
||||
|
||||
Pint,PHPStan0erros,lint,tipos,build,diff e18hashes comuns aprovados. O artefacto compilado confirmou que a pesquisa conserva records_page. HTTP com administração,Compras e Finanças confirmou as cinco vistas/paginação conforme os acessos actuais e que a pesquisa não concede opções de preparação ao leitor. Provas supply-pagination[-pg/-http].json e logs supply-pagination-*. As escolhas de processos antigos e os dados em volume foram ensaiados nas bases descartáveis. Nenhuma decisão/grant/cadastro/stock/SGF alterado por estes comandos de desenvolvimento;sem nova revisão visual completa,teste de carga ou aceitação real.
|
||||
|
||||
Próxima continuidade:demais selectores ainda limitados (por exemplo saídas efectivas para afectação de necessidades e novas escolhas de análises/políticas sem referência anterior),restantes consultas de ocorrências/estornos,preparação comercial do serviço periódico com recuperação e verificações de capacidade/relatórios/impressões. Confrontar acordos/importações/execução contratual com os documentos base antes de declarar a aplicação completa. A paginação principal de acordos,calendário,histórico,sugestões e importações e a pesquisa de ordens para importação deixaram de estar pendentes. Manter as decisões já autorizadas;não criar novas competências ou decisões no piloto por inferência. Preservar trabalhos paralelos,em particular o ciclo contabilístico autónomo e contas a pagar.
|
||||
|
||||
## 03/11/2026 — consultas de ocorrências e estornos consolidadas
|
||||
|
||||
Retirado o corte100processos em /stock/ocorrencias e /stock/estornos. InventoryCorrectionPage é uma projecção de leitura partilhada,sem novo motor ou permissões;os controladores mantêm a autoridade nativa e os comandos anteriores. Paginação25,contagem e filtros opcionais por referência/estado sobre as últimas versões. Pesquisa sem distinção de maiúsculas,parâmetros validados e conservados nas ligações. O foco directo ignora os filtros para apresentar a versão actual e o histórico integral desse processo,com as acções nativas de conferência/devolução/execução. Páginas em transacção coerente somente de leitura PostgreSQL,privadas e com história cifrada. Mantido o redireccionamento anterior para estornos quando só esse módulo está autorizado.
|
||||
|
||||
Componentes de paginação e filtros reutilizados;filtros recolhidos quando não usados,sem novos campos de negócio obrigatórios. As escolhas de recepções e operações passam a conservar as origens já seleccionadas dos processos visíveis,mesmo fora das200recentes. Origens efectivamente estornadas são excluídas antes de aplicar a janela de escolhas e não são reintroduzidas por estarem num documento anterior. Referências,snapshots,aceitação original e documentos continuam imutáveis;as quantidades e a execução dependem das verificações nativas actuais. A janela200de novas escolhas permanece;isto não constitui pesquisa/paginação universal de todas as origens.
|
||||
|
||||
Validação final55testes/1085verificações aprovados:InventoryCorrectionPagination,InventoryDispositions,InventoryReversals e WorkflowTaskInbox. Dez cenários específicos também aprovados em PostgreSQL descartável251verificações,com remoção da base confirmada. Cobertura:210processos por percurso,páginas antigas,filtros apenas sobre versão actual,foco antigo/histórico/acções independentes,empresa/tipo/páginas inválidas/manutenção/vigência,recepção e operação escolhidas fora das200recentes,estorno nativo e exclusão posterior das escolhas,consulta sem alterar stock,orçamento,auditoria ou decisões. As origens de volume foram criadas pelos comandos nativos em bases de teste;as correcções de teste usaram preparação,aprovação e execução independentes. Não somar provas sobrepostas nem declarar bateria geral.
|
||||
|
||||
Pint,PHPStan0erros,tipos,lint,build,diff e18hashes comuns aprovados. Provas inventory-pagination[-pg/-http].json e logs inventory-pagination-*. HTTP8005 confirmou administração em leitura,armazém com execução anterior sem preparação/conferência nova,Compras/Finanças sem essas competências403,paginação/filtros vazios e validação dos parâmetros. Nenhuma concessão,ocorrência,estorno ou movimento novo no piloto,nem alteração SGF/8051,contacto externo ou decisão comercial. Sem revisão visual completa ou teste de carga;preservadas alterações paralelas de contabilidade e contas a pagar.
|
||||
|
||||
Continuar pelos restantes selectores de origens ainda limitados,instalação comercial/recuperação do serviço periódico e validação de capacidade,relatórios,impressão e percursos por perfil. Consultas gerais de ocorrências/estornos deixam de ser uma lacuna de paginação;aprovações existentes não foram substituídas. Não reaplicar decisões ou autorizações anteriores nem declarar a aplicação inteira concluída por este incremento.
|
||||
03/11/2026 — Balancete/razão contabilístico QA implementado sobre núcleo comum, com datas explícitas, paginação25/100 e saldo acumulado entre páginas. Ver `docs/relatorios-contabilisticos-ensaio.md`;21 verificações de serviço,20 HTTP,8 de isolamento e pacote QA novo fixado por hash. Preservados piloto8005, pacote/demos anteriores e decisões; sem activação operacional, novos direitos reais ou publicação.
|
||||
|
||||
|
||||
## 03/11/2026 — autoridade das consultas partilhadas de correcções
|
||||
|
||||
InventoryCorrectionPage passou a obter o utilizador actual da base,confirmar a empresa e reutilizar as competências nativas dos módulos também nas chamadas internas. Consulta de processos exige uma capacidade de leitura/preparação/conferência/execução do percurso;escolhas de recepções exigem preparação de ocorrências ou estornos;escolhas de operações exigem preparação de estornos. A permissão de consulta não passa a conceder preparação. Revogação/vigência/manutenção são reavaliadas mesmo com uma instância de utilizador anteriormente carregada. Não se alteraram perfis,sequências,alçadas ou comandos de aprovação/execução.
|
||||
|
||||
Acrescentados quatro testes específicos de acesso para listas de origens e processos,com manutenção,expiração,leitor sem preparação e auditoria sem alterações. Regressão também cobre os cenários de paginação e correcções nativas anteriores. PHPStan sem erros e HTTP do piloto confirmado sem novos acessos ou decisões. Os resultados finais dos testes são registados após conclusão. Trabalho limitado à integração interna SGC;preservados SGF e o ciclo contabilístico paralelo.
|
||||
|
||||
Validação final desta etapa:14testes/263verificações aprovados em InventoryCorrectionAccess e InventoryCorrectionPagination;PHPStan0erros,Pint,diff e HTTP do piloto aprovados. Não houve alteração frontend,nova execução PostgreSQL,bateria geral ou revisão visual nesta etapa. Provas nos logs inventory-access-tests.txt/inventory-access-phpstan.txt e inventory-pagination-http.json;resultados PostgreSQL anteriores não são nova execução desta alteração.
|
||||
|
||||
## 03/11/2026 — pesquisa de saídas efectivas para necessidades planeadas
|
||||
|
||||
Acrescentada pesquisa opcional por referência na acção de associar saída de uma reserva de planeamento. A pesquisa filtra antes da janela100 e vincula-se à identidade da necessidade,artigo e armazém;identidades de necessidade e saída validadas por empresa/tipo. O servidor usa a última versão e a elegibilidade nativa canManage(fulfil),recusando necessidades encerradas/canceladas ou sem competência. Leitores não recebem operações de preparação. Saídas estornadas ficam excluídas mesmo quando selected_issue_id tenta conservá-las;origens de outro artigo/local também não entram no conjunto. Sem campos de negócio novos ou nova concessão de tarefas.
|
||||
|
||||
GET parcial actualiza operações,referência pesquisada e identidade de destino,preservando página,posicionamento,quantidade,justificação e selecção elegível. Enter no campo de pesquisa não submete a associação. Cada formulário mantém as próprias opções em memória,para uma pesquisa numa necessidade não apagar as escolhas de outra que esteja aberta. A saída escolhida fora dos resultados continua disponível apenas se pertence ao âmbito elegível. Continua a haver uma janela100 por pesquisa,sem alegar paginação universal do razão. Fonte e quantidade são novamente verificadas pelo comando nativo;associar não lança outra saída,não cria factura ou compra,não altera aprovações nem substitui a reserva física do armazém.
|
||||
|
||||
Validação final54testes/971verificações aprovados em SupplyCoordination,InventoryReversals,SupplyPlanning e WorkflowTaskInbox. Três cenários dirigidos passaram também em PostgreSQL descartável85verificações,base removida. Incluem saída com100movimentos posteriores,pesquisa sem distinguir maiúsculas,selecção sem resultados,reutilização sem duplicar movimento,artigo/armazém,estado corrente,leitor sem preparação,empresa,comprimento do filtro e saída estornada que não reaparece pela selecção. A regressão conserva os percursos nativos de correcção,necessidades e tarefas. Pint,PHPStan0erros,tipos,lint,build,diff e18hashes comuns aprovados.
|
||||
|
||||
HTTP8005 confirmou administração em leitura sem opções operacionais,recusas403 dos perfis sem acesso específico e validação do vínculo da pesquisa. Os casos positivos foram executados nas bases descartáveis;nenhum grant,reserva,associação,saída ou decisão novo no piloto. Provas reservation-source[-pg/-http].json e logs reservation-source-*. Sem migração,contactos externos,alteração SGF/8051,bateria geral ou revisão visual completa. Não somar execuções sobrepostas à regressão54.
|
||||
|
||||
Continuidade:restantes selectores de novas origens históricas/políticas e de recepções/operações,instalação comercial e recuperação do serviço periódico,verificações de capacidade,relatórios/impressões e cobertura dos percursos documentados. A pesquisa de saídas para associação à necessidade deixa de ser uma lacuna. Preservar os motores e aprovações existentes e os trabalhos paralelos de contabilidade/contas a pagar;novas decisões operacionais do piloto permanecem sujeitas ao respectivo âmbito de autorização.
|
||||
|
||||
## 03/11/2026 — pesquisa de análises aprovadas para políticas históricas
|
||||
|
||||
A preparação de políticas com previsão histórica ganhou pesquisa opcional por período,usando o artigo,armazém e finalidade já escolhidos. O filtro aplica-se antes da janela100 de origens recentes,permitindo localizar uma análise antiga por datas. Fontes limitadas às últimas versões aprovadas e à empresa;identidades,âmbito,datas e ordem dos limites são validados no servidor. A origem seleccionada continua incluída fora do período pesquisado apenas quando ainda aprovada e do mesmo âmbito. Suspensão exclui-a sem alterar a referência histórica dos documentos existentes.
|
||||
|
||||
GET parcial actualiza só as opções e a identidade do formulário,conservando dados,página e posição. Cada preparação/cópia mantém as próprias opções para uma pesquisa não apagar as escolhas de outra. Enter nos campos de pesquisa não submete a política. Não há novos campos de negócio obrigatórios,nem alteração da aprovação de análises/políticas. Qualidade,padrão,cobertura,assinatura do razão,actualidade e suspensão continuam a ser conferidos pelo motor nativo ao reutilizar a origem;encontrar uma opção não aprova a política nem altera a previsão de um documento já aprovado.
|
||||
|
||||
Validação final53testes/1011verificações aprovados em SupplyHistory,SupplyPlanning,SupplySuggestions e SupplyPagination. Dois cenários específicos passaram também em PostgreSQL descartável62verificações,base removida. Cobertura:período fora das100escolhas recentes,selecção preservada,finalidade diferente,suspensão,empresa,âmbito incompleto,datas invertidas e leitor sem preparação,sem auditoria ou movimento gerado pela consulta. Tipos,lint,build,Pint,PHPStan0erros,diff e18hashes comuns aprovados. Provas history-source[-pg/-http].json e logs history-source-*. Não somar execuções sobrepostas nem declarar bateria geral.
|
||||
|
||||
HTTP8005 confirmou pesquisa vinculada ao âmbito existente,preparação conforme o perfil e ausência de opções para quem só confere/consulta. Nenhuma análise,política,grant,decisão,stock,SGF ou ciclo contabilístico8051 alterado no piloto. Os casos positivos com períodos aprovados foram executados só em bases descartáveis. Sem revisão visual completa ou teste de carga. A janela100 de resultados por pesquisa permanece;isto não equivale a paginação universal de todos os selectores.
|
||||
|
||||
Continuar pelos restantes selectores de políticas e origens de correcções,preparação comercial/recuperação do serviço periódico e validação de capacidade,relatórios,impressões e percursos. Preservar motores,aprovações,perfis e trabalhos paralelos;novas decisões operacionais não são concedidas por inferência. A pesquisa de análises históricas para políticas deixa de ser uma lacuna de acesso às origens antigas.
|
||||
|
||||
## 03/11/2026 — pesquisa das políticas aprovadas para sugestões
|
||||
|
||||
Preparação de sugestões ganhou pesquisa opcional por código/descrição do artigo e nome do armazém registados no snapshot aprovado. Filtragem sem distinguir maiúsculas,antes da janela100;seleccionados elegíveis mantidos fora dos resultados,sem reintroduzir política suspensa ou de outra empresa. selected_policy_key validado por empresa/tipo,consulta de origens apenas para supply_suggest_prepare. Leitores/conferentes não recebem escolhas de preparação. A pesquisa não selecciona fornecedor,aprova política ou gera compra.
|
||||
|
||||
GET parcial actualiza só opções/texto/correlação do formulário,preservando página,posição,selecção e dados introduzidos. Cada preparação mantém as próprias opções para evitar interferência entre formulários;Enter na pesquisa não submete a sugestão. Origens aprovadas continuam sujeitas à basis nativa,à qualidade do histórico,à vigência,preço,tributação e revisão independente. Sem novos campos de negócio obrigatórios,sem alterar perfis,motores ou snapshots existentes. Janela100 de resultados por pesquisa permanece,não se declara paginação universal dos selectores.
|
||||
|
||||
Validação final55testes/1077verificações aprovados em SupplySuggestions,SupplyHistory,SupplyPlanning e SupplyPagination. Dois cenários dirigidos em PostgreSQL descartável66verificações,base removida. Incluem política antiga fora das100recentes,caso sem resultados,selecção preservada,suspensão,empresa,comprimento/entrada com apóstrofo e conferente sem preparação;consultas sem auditoria,stock ou requisição novos e documento aprovado imutável. Fonte de volume construída com100políticas de artigos distintos pelos comandos nativos nas bases de teste. Pint,PHPStan0erros,tipos,lint,build,diff e18hashes comuns aprovados.
|
||||
|
||||
HTTP8005 confirmou administração em leitura sem escolhas de preparação e recusas dos perfis sem acesso específico;cenários positivos só nas bases descartáveis. Provas policy-source[-pg/-http].json e logs policy-source-*. Sem grants,contas,sugestões,compras,movimentos ou decisões novos no piloto;SGF e demo contabilística8051 preservados. Sem nova bateria geral,revisão visual completa ou teste de carga. Não somar provas sobrepostas.
|
||||
|
||||
Continuar pelas novas escolhas de recepções/operações nos percursos de correcção e restantes origens ainda limitadas,instalação comercial/recuperação do serviço periódico,capacidade,relatórios,impressões e cobertura dos documentos base. A pesquisa das políticas para sugestões deixa de ser uma lacuna de acesso a origens antigas. Preservar aprovações e autorizações anteriores e alterações paralelas,não declarar a aplicação inteira concluída por este incremento.
|
||||
|
||||
## 03/11/2026 — pesquisa de novas origens de ocorrências e estornos
|
||||
|
||||
Formulários de preparação passaram a procurar recepções pelo número e operações pela referência. Filtro sem distinguir maiúsculas aplicado antes da janela200;mantém fontes elegíveis já seleccionadas e fontes dos processos visíveis. Operações/linhas estornadas,tipos sem correcção física ou fontes de outra empresa não são reintroduzidos pela selecção. Direitos de preparação verificados pelo serviço nativo existente,com utilizador actual;leitores continuam sem opções. Parâmetros e identidades validados por empresa.
|
||||
|
||||
Componente de pesquisa partilhado,opcional e recolhido,sem campos de negócio obrigatórios novos. GET parcial conserva dados,selecção elegível,página,filtros de processos e posição. Cada formulário mantém as suas opções para não interferir com outra preparação aberta. Enter não submete uma correcção. Seleccionar recepção continua a reutilizar artigo/armazém da origem;quantidades,saldo,unidades,lotes,independência e versão continuam a ser verificados nos comandos nativos. Nenhuma aprovação,saída ou correcção financeira executada pela pesquisa. Janela200por pesquisa continua;isto não é paginação universal das fontes.
|
||||
|
||||
Validação final60testes/1158verificações aprovados em InventoryCorrectionPagination,InventoryCorrectionAccess,InventoryDispositions,InventoryReversals e WorkflowTaskInbox. Três cenários dirigidos em PostgreSQL descartável98verificações,base removida. Cobrem origens com200registos posteriores,pesquisa directa no serviço sem seleccionados,selecção preservada,estorno nativo e exclusão posterior,empresa,comprimento/entrada com apóstrofo e leitura sem preparação;sem mutações durante consulta,sem reescrever a recepção ou operação original. Pint,PHPStan0erros,tipos,lint,build,diff e18hashes comuns aprovados. Mantidos no runner os tempos dos modos anteriores de coordenação e qualidade de lotes.
|
||||
|
||||
HTTP8005 confirmou os perfis existentes e ausência de novas escolhas operacionais para administração/armazém sem preparação;Compras/Finanças sem acesso específico403. Cenários positivos e decisões de correcção apenas em bases descartáveis. Provas correction-source[-pg/-http].json e logs correction-source-*. Sem grants,contas,correcções ou movimentos novos no piloto,sem alteração SGF/8051,contactos externos,bateria geral ou revisão visual completa. Não somar provas sobrepostas aos60testes.
|
||||
|
||||
Continuar pelos restantes selectores de encomendas/requisições de fornecimentos,preparação comercial/recuperação do serviço periódico,capacidade,relatórios,impressões e cobertura integral dos documentos base. A pesquisa de novas recepções/operações para correcções deixa de ser uma lacuna de acesso às fontes antigas. Preservar autorizações existentes e trabalhos paralelos,não declarar a aplicação inteira concluída por este incremento.
|
||||
|
||||
## 03/11/2026 — origens antigas no acompanhamento de fornecimentos
|
||||
|
||||
A preparação de reservas planeadas e confirmações de entrega permite procurar, pelo número, requisições aprovadas e encomendas emitidas antes da janela das 100 mais recentes. Mantém as linhas elegíveis já seleccionadas e as origens dos registos visíveis. Uma selecção explícita não reintroduz requisições em rascunho, encomendas não emitidas ou dados de outra empresa. A linha continua a fornecer os dados canónicos, sem repetir cadastros ou alterar aprovações.
|
||||
|
||||
Pesquisa opcional e recolhida, reutilizando o componente comum. Respostas parciais mantêm formulário, selecção, página e posição; cada preparação conserva as suas opções. Consultas não criam compras, recepções ou movimentos. Reservas planeadas e confirmações de entrega continuam distintas da reserva física e da recepção de stock. Mantém-se a janela de 100 fontes por pesquisa; não é paginação universal de selectores.
|
||||
|
||||
Validação: 49 testes/1.047 verificações na regressão de coordenação, planeamento, paginação e caixa de tarefas; 3 testes/89 verificações em PostgreSQL descartável, removido no final. Cobertura inclui origem fora das 100 mais recentes, pesquisa sem distinguir maiúsculas, selecção preservada, utilização nativa da linha, exclusão de rascunhos, isolamento por empresa, leitura sem preparação e consultas sem mutações. Pint, PHPStan sem erros, tipos, lint e build aprovados. HTTP no piloto confirmou administração em leitura e recusas dos perfis sem competência específica, sem conceder direitos.
|
||||
|
||||
Evidências: docs/proofs/supply-line-source.json, supply-line-source-pg.json e supply-line-source-http.json; logs supply-line-source-*. Nenhum comando de negócio no piloto, conta, grant, decisão de fornecedor ou alteração ao SGF. Sem nova bateria geral ou revisão visual completa. Não somar as provas sobrepostas. Permanecem a preparação comercial e recuperação do serviço periódico, capacidade, relatórios/impressões e conferência integral dos documentos base; este incremento não declara a aplicação concluída.
|
||||
|
||||
## 03/11/2026 — acompanhamento nativo da verificação periódica
|
||||
|
||||
sgc:replenishment-tick passou a gravar atomicamente o resultado técnico da própria execução em storage/framework/replenishment-command-status.json. Sucesso, trabalhos a recuperar e interrupção na descoberta/processamento ficam distinguíveis sem copiar pessoas, empresas, artigos, erros internos ou documentos. Falha ao escrever telemetria é reportada e avisada sem mascarar o resultado ou a excepção original. Limite inválido e composição não preparada não publicam sucesso.
|
||||
|
||||
ReplenishmentQueue.status lê a observação nativa também fora do ambiente de avaliação. O ficheiro antigo do auxiliar permanece como fallback apenas no piloto e apenas se não existir observação nativa; não pode substituir uma falha nativa por sucesso. Dados danificados não certificam execução. Conservam-se a janela de actualidade, verificação da instalação e consulta das pendências duráveis; uma passagem bem sucedida não oculta trabalhos a recuperar. Isto observa passagens e não garante que um serviço continue activo depois delas.
|
||||
|
||||
Validação final: 36 testes/406 verificações em ReplenishmentHeartbeat, WarehousePilotReadiness e AutomaticPurchases. Inclui sucesso, falha, excepção, limite inválido, ambiente comercial, prioridade sobre auxiliar, corrupção, obsolescência e recuperação existente. Ficheiros de teste isolados do piloto. Pint, PHPStan sem erros, diff e 18 hashes de execução aprovados. Prova docs/proofs/replenishment-heartbeat.json; logs replenishment-heartbeat-*. Não foi feita nova execução PostgreSQL, bateria geral ou revisão visual. Não há alteração de interface nesta etapa.
|
||||
|
||||
Sem migração, comando de negócio manual no piloto, conta/grant, decisão de compra ou alteração SGF/8051. Não instalado serviço de arranque Windows: instalação comercial, recuperação após reinício, capacidade, relatórios/impressões e cobertura integral dos documentos continuam pendentes. Preservar o auxiliar existente e as aprovações; este acompanhamento não aprova nem encomenda e não constitui aceitação comercial da aplicação.
|
||||
|
||||
## 03/11/2026 — exclusão local e recuperação do processo de reposição
|
||||
|
||||
O comando nativo de reposição passou a adquirir um bloqueio de processo comum antes da descoberta/processamento, incluindo chamadas pelo auxiliar, agendador e operador. Usa posse do sistema operativo sem prazo que possa expirar a meio do lote. Uma segunda chamada não processa trabalhos, não substitui a observação concluída e devolve insucesso para não publicar falso sucesso através do auxiliar. Libertação em sucesso, excepção e terminação do processo; o ficheiro de controlo persistente não é sinal de bloqueio e não deve ser apagado durante execução. Não substitui transacções/recibos/idempotência existentes nem cria competências humanas.
|
||||
|
||||
Regressão final 39 testes/425 verificações em ReplenishmentHeartbeat, WarehousePilotReadiness e AutomaticPurchases, mais 1 teste/5 verificações com processo PHP externo terminado pelo teste. Comprovadas recusa de concorrente, ausência de processamento/telemetria concorrente, libertação após erro e sucesso, destruição da instância e terminação externa sem apagar o ficheiro. Pint, PHPStan sem erros, diff e 18 hashes aprovados. Prova docs/proofs/replenishment-process-lock.json; logs replenishment-process-lock-* e replenishment-process-recovery-tests.txt. Sem nova execução PostgreSQL, bateria geral ou revisão visual; não somar estes resultados às regressões anteriores sobrepostas.
|
||||
|
||||
Preparado docs/operacao-reposicao.md com configuração de tarefa recorrente, identidade técnica escolhida na instalação, directório inicial, diagnóstico, recuperação e conferência após reinício. Nenhuma tarefa Windows foi instalada nem credenciais copiadas. Bloqueio validado localmente, não como exclusão distribuída entre servidores. Sem comando manual de negócio no piloto, contas/grants, aprovações, decisões de fornecedor, migração ou alteração SGF/8051. Continuam pendentes instalação/ensaio comercial após reinício, capacidade, relatórios/impressões e cobertura integral dos documentos base. Não declarar aplicação concluída ou aceite comercialmente por este incremento.
|
||||
|
||||
## 03/11/2026 — consulta filtrada do acompanhamento de fornecimentos
|
||||
|
||||
Reservas planeadas, confirmações de entrega e alternativas técnicas passaram a permitir pesquisa opcional por código/nome do artigo, nome do local, referência da necessidade ou número da encomenda existente, com filtro de estado próprio de cada percurso. A consulta aplica filtros depois de seleccionar a versão mais recente de cada chave e antes de paginar25. Não ressuscita versões antigas activas de processos cancelados. Pesquisa sem distinguir maiúsculas, parâmetros limitados/validados e condições agrupadas dentro do âmbito da empresa.
|
||||
|
||||
A interface mantém os filtros recolhidos quando vazios e não acrescenta campos de negócio obrigatórios. Nova filtragem reinicia a página; navegação conserva filtros. Pesquisas parciais de documentos/saídas continuam a preservar filtros, formulário e selecção. Ligação exacta de tarefa continua a apresentar a versão actual e histórico do processo, mesmo fora dos filtros. O estado é o registado; não deve ser confundido com pendência física calculada, especialmente nas reservas reabertas por estorno. Consultas não reservam/saem stock, recebem mercadoria ou alteram decisões.
|
||||
|
||||
Validação: 54 testes/1158 verificações em SupplyCoordination,SupplyPlanning,SupplyPagination e WorkflowTaskInbox; 5 testes/111 verificações em PostgreSQL descartável, removido. Abrange origem antiga após26registos, exclusão de estado anterior, histórico preservado, filtros na página seguinte, foco exacto, artigo/local/encomenda, entradas com apóstrofo, empresa e ausência de mutações. Pint, PHPStan sem erros, lint, tipos, build e18hashes aprovados. HTTP no piloto conferiu leitura administrativa, validação e recusas dos perfis sem acesso específico, sem grants. Provas coordination-filters[-pg/-http].json e logs coordination-filters-*.
|
||||
|
||||
Sem novas contas, decisões, comandos de negócio manuais no piloto ou alteração SGF/8051. Não houve revisão visual completa, ensaio de capacidade ou nova bateria geral; não somar provas sobrepostas. Continuam pendentes instalação/recuperação comercial após reinício, capacidade, relatórios/impressões e conferência integral dos documentos base. Este incremento melhora a consulta dos processos existentes; não declara novos relatórios ou conclusão integral da aplicação.
|
||||
|
||||
## 03/11/2026 — exportação integrada do acompanhamento de fornecimentos
|
||||
|
||||
Reservas planeadas, confirmações de entrega e alternativas técnicas passam a disponibilizar CSV a partir da responsabilidade da etapa. Exporta todos os resultados filtrados, sem limite da página25, ou apenas o processo em foco na sua versão actual. Reutiliza os mesmos direitos de leitura, filtros e consulta da página através de SupplyCoordinationRead, sem nova permissão ou segundo registo. Foco antigo resolve a chave e exporta a versão actual mesmo fora dos filtros, como a página; dados estrangeiros ou de outro tipo são recusados.
|
||||
|
||||
CSV inclui momento da consulta, filtros, chave/versão/estado registado, artigo/local preservados, referência/encomenda, quantidade/unidade/data, quantidade por satisfazer calculada pelos serviços nativos, substituto/aplicação/validade e ligação exacta ao processo. Alternativas não recebem quantidades pendentes inventadas. Quantidade por satisfazer deve ser interpretada com o estado: não reactiva canceladas e não é reserva física ou compromisso de compra. Textos iniciados por fórmulas, incluindo espaços/controlos anteriores, são exportados como texto; delimitadores/aspas seguem CSV. Resposta privada sem cache, processamento por lotes100, transacção de leitura consistente em PostgreSQL. Não exporta automaticamente todo o histórico ou evidências confidenciais adicionais.
|
||||
|
||||
Validação final58testes/1201verificações em SupplyCoordination,SupplyPlanning,SupplyPagination e WorkflowTaskInbox. Quatro testes/43verificações em PostgreSQL descartável, removido; cobrem todas as páginas, última versão, cancelamento, foco exacto, filtro, satisfação parcial, fórmula, empresa, manutenção/vigência e diferenças entre entrega/alternativa. Pint,PHPStan0erros,lint,tipos,build,diff e18hashes aprovados. HTTP no piloto confirmou exportações administrativas em leitura e recusas sem direitos específicos. Provas coordination-export[-pg/-http].json e logs coordination-export-*. Não somar regressões sobrepostas; não foi nova bateria geral, ensaio de capacidade ou revisão visual/impressão.
|
||||
|
||||
Sem migração, conta/grant, comando de negócio manual no piloto ou decisão de fornecedor; SGF/8051 preservados. Permanecem a instalação comercial/ensaio após reinício do serviço periódico, capacidade, outros relatórios/impressões e conferência integral dos documentos base. Não apresentar este CSV de acompanhamento como autorização, documento de saída ou comprovação da conclusão integral da aplicação.
|
||||
|
||||
## 03/11/2026 — prazos na caixa de tarefas integrada
|
||||
|
||||
As caixas de tarefas de Compras/Armazém/Fornecimentos/Finanças e Pessoas permitem consultar todos os prazos, ultrapassados, com vencimento hoje, futuros ou sem prazo registado. Classificação de leitura em WorkflowTaskInboxController a partir exclusivamente de due_on da projecção nativa e da data do servidor, apresentada explicitamente como referência. Não copia tarefas para tabela, inventa prazos ou altera aprovações/atribuições. Documentos antigos continuam primeiro; o prazo não concede competência nem define prioridade automática.
|
||||
|
||||
Contagens por prazo usam todas as tarefas autorizadas dentro do módulo e pesquisa, antes de filtrar prazo e paginar25. Cartões de módulos mantêm contagens globais anteriores. Formulário reinicia a página e paginação conserva filtros. Cada tarefa datada mostra a classificação, conservando ligação exacta à origem. A passagem do tempo actualiza a consulta sem novo movimento ou decisão; cancelamento nativo retira a tarefa sem reescrever histórico. Mantida projecção completa existente: este incremento não é ensaio ou optimização de capacidade.
|
||||
|
||||
Regressão final87testes/2431verificações em WorkflowTaskInbox,SupplyCoordination e PeopleHiring. Dois cenários dirigidos em PostgreSQL descartável114verificações,base removida: limites de hoje/amanhã/ontem/sem data,28pendências antes da paginação,escopo módulo/pesquisa,contagens,parâmetros,passagem de dia e cancelamento sem mutações de consulta. Pint,PHPStan0erros,lint,tipos,build,diff e18hashes aprovados. HTTP no piloto conferiu cinco opções de prazo nos quatro perfis sintéticos existentes e recusa de opção inválida. Provas task-deadlines[-pg/-http].json e logs task-deadlines-*.
|
||||
|
||||
Sem novos prazos configurados,contas/grants,decisões,comandos manuais de negócio no piloto,avisos externos ou alterações SGF/8051. Sem revisão visual completa,nova bateria geral ou ensaio de capacidade; não somar provas sobrepostas. Continuam pendentes instalação/ensaio comercial após reinício do serviço periódico,capacidade,outros relatórios/impressões e conferência integral dos documentos base. Esta consulta não aprova por silêncio nem constitui conclusão ou aceitação comercial integral do SGC.
|
||||
|
||||
## 03/11/2026 — consulta e leitura contextual dos avisos internos
|
||||
|
||||
Avisos de aprovação passam a ter pesquisa opcional pela referência da requisição, sem distinguir maiúsculas, sobre todos os avisos actualmente visíveis ao destinatário antes de paginar25. Mantidos filtros todos/por ler/intervenções/resultados e contador global de não lidos. Consulta usa transacção consistente somente de leitura em PostgreSQL, resposta privada sem cache e histórico Inertia encriptado. GET não cria nem lê avisos e não altera a elegibilidade nativa ou encaminhamento.
|
||||
|
||||
Marcar como lido conserva vista,pesquisa e página em redireccionamento local construído apenas com parâmetros validados. Contexto inválido é recusado antes da marcação. A página é limitada à última válida quando a leitura retira a última linha do filtro; pesquisa nova reinicia a página. Mantidos comando nativo,controlo de empresa/destinatário,verificação actual de acesso e auditoria idempotente. Ler não decide nem submete requisição e não altera orçamento,stock ou etapa de aprovação.
|
||||
|
||||
Regressão final24testes/757verificações em InternalRequisitionCandidate e WorkflowTaskInbox. Dois cenários dirigidos em PostgreSQL descartável142verificações,base removida. Cobertura de28avisos nativos,fonte antiga,pesquisa literal/entrada com apóstrofo,página/contexto preservados,contador global,consulta sem mutações,leitura repetida com uma auditoria e parâmetros inválidos sem leitura. Corrigidos no desenvolvimento a chamada encadeada do formulário e comparações do novo teste; só os resultados finais aprovados constituem esta prova. Pint,PHPStan0erros,lint,tipos finais,build,diff e18hashes aprovados. Artefacto compilado conferido sem chamada antiga encadeada. HTTP nos quatro perfis sintéticos existentes e quatro vistas,sem marcar avisos do piloto. Provas notice-consultation[-pg/-http].json e logs notice-consultation-*.
|
||||
|
||||
Sem migração,contas/grants,leituras ou decisões de negócio novas no piloto;SGF/8051 preservados. Sem revisão visual completa,bateria geral ou ensaio de capacidade. Não somar provas sobrepostas. Permanecem instalação/ensaio comercial após reinício do serviço periódico,capacidade,outros relatórios/impressões e confronto integral com os documentos base. A pesquisa/readaptação dos avisos não transforma avisos históricos em tarefas actuais nem constitui conclusão integral do produto.
|
||||
|
||||
## 03/11/2026 — confronto matriz/código/provas e pesquisa de acordos
|
||||
|
||||
Matriz histórica de compatibilidade confrontada com código e provas posteriores em docs/matriz-sgc-reconciliada.md. Acrescentada referência no início de compatibilidade.md,conservando o histórico e separando piloto8005/SGFreal0.1.1/QA. Reposição,relatórios de Pessoas e correcções físicas não devem continuar tratados como globalmente ausentes; capacidades comuns/devolução desligadas não são activadas pelo facto de terem código/provas. Lacunas confirmadas incluem MFA não activo em Fortify e propostas ainda gravadas em MZN; restantes itens sem encerramento comprovado ficam explicitamente como tal. Separados desenvolvimento,instalação/configuração,validação e decisões humanas. Prova documental matrix-reconciliation.json fixa hashes das fontes consultadas,sem declarar nova execução dos testes antigos ou cobertura integral.
|
||||
|
||||
Lacuna autorizada implementada: escolha de acordos no calendário deixava todos os acordos aprovados carregados integralmente e só filtrava artigo/local no navegador. Passou a pesquisa de referência/fornecedor no servidor,com âmbito artigo/armazém validado por empresa,100resultados recentes por pesquisa e preservação de fontes aprovadas utilizadas/seleccionadas. Suspensão e âmbito diferente não são contornados pela selecção. Mantido o conjunto de campos da resposta anterior,sem razões/auditoria adicionais. Validade,prazo conhecido,versão e aprovação da política continuam no motor nativo; a pesquisa não certifica elegibilidade contratual. Formulário conserva dados,página,foco e opções por preparação; pesquisa opcional recolhida,desactivada até escolher artigo/local,sem novos campos de negócio obrigatórios.
|
||||
|
||||
Regressão final62testes/1381verificações em SupplyPagination,SupplyPlanning,SupplyCoordination e WorkflowTaskInbox;2testes/66verificações em PostgreSQL descartável,base removida. Inclui acordo fora das100fontes recentes,selecção conservada,utilização nativa da origem,exclusão após suspensão,empresa/âmbito,parâmetros/entrada com apóstrofo e leitor sem escolhas. Corrigida a data de criação das cópias sintéticas na preparação do teste; só resultados finais aprovados constituem esta entrega. Pint,PHPStan0erros,lint,tipos,build,diff e18hashes aprovados. HTTP no piloto confirmou os acessos existentes e âmbito obrigatório. Provas agreement-source[-pg/-http].json e logs agreement-source-*.
|
||||
|
||||
Sem conta/grant,publicação de política,decisão comercial,comando manual de negócio no piloto ou alteração SGF/8051. Sem nova bateria geral,revisão visual ou ensaio de capacidade;não somar regressões sobrepostas. Próximas prioridades e limites estão na matriz reconciliada. Não declarar produto completo nem pedir nova autorização para decisões já autorizadas/aplicadas;seleccionar fornecedor/encomendar,activar capacidades ou instalar no destino continuam operações próprias.
|
||||
|
||||
## 03/11/2026 — base nativa de autenticação de dois factores
|
||||
|
||||
Confronto do código confirmou que a lacuna MFA ultrapassava configuração: User não usava TwoFactorAuthenticatable e o esquema não continha as três colunas mencionadas na documentação do modelo. Acrescentados trait/cast nativos e migração aditiva nullable para segredo cifrado,códigos de recuperação cifrados e confirmação. Não executada migração no piloto nem activada a feature. Nenhuma conta foi inscrita ou obrigatoriedade criada; roles/aprovações e política de acesso mantidas.
|
||||
|
||||
Ecrãs Inertia portugueses para desafio por aplicação autenticadora/código de recuperação e confirmação de palavra-passe,usando exclusivamente endpoints/acções do Fortify instalado. Histórico encriptado,resposta privada sem cache e nenhuma chave/código de recuperação em props. Campos do formulário limpos após erro/sucesso. Limitador nativo de5tentativas/minuto por identidade em desafio/IP,ligado à configuração Fortify sem activar MFA. O formulário de gestão de adesão/confirmação/recuperação/desactivação ainda tem de ser concluído antes de propor activação; isto é base técnica,não entrega comercial integral de MFA.
|
||||
|
||||
Regressão final25casos:23aprovados,2ignorados existentes por feature MFA desligada,426verificações. Os6cenários novos de base foram todos executados;6testes/60verificações em PostgreSQL descartável,base removida. Verificados segredo cifrado/omitido da serialização,feature desligada,conta confirmada em desafio,TOTP real do motor instalado,recuperação e recusa de reutilização sequencial,códigos inválidos/429,adesão não confirmada sem bloqueio de login e confirmação nativa da palavra-passe. Testes registam as rotas do próprio pacote apenas na aplicação descartável; corrigidas preparação do esquema e actualização dos nomes de rotas no teste antes dos resultados finais. Não é ensaio de recuperação concorrente,política obrigatória ou cobertura MFA completa de todas as rotas/composições.
|
||||
|
||||
Pint,PHPStan0erros,lint,tipos,build,diff e18hashes aprovados. HTTP nos perfis sintéticos de administração/armazém conferiu confirmação privada e desafio404 com MFA desligado,sem comandos de adesão ou mudança de palavra-passe. Provas mfa-foundation[-pg/-http].json e logs mfa-foundation-*. Sem SGF/8051,contas/grants,migração no piloto,decisões de compra,revisão visual completa,bateria geral ou aceitação comercial. A matriz reconciliada anterior conserva o seu instante/provas; agora há esta base técnica adicional,mas a pendência MFA não deve ser marcada como totalmente encerrada.
|
||||
|
||||
Próxima continuidade:concluir interface de adesão protegida por palavra-passe,confirmação explícita do autenticador,consulta/renovação de recuperação e desactivação nativas,testar percursos e só então preparar eventual activação com migração e recuperação verificáveis. Não transformar autorização genérica de desenvolvimento em inscrição/obrigatoriedade das contas existentes.
|
||||
|
||||
## 03/11/2026 — gestão voluntária MFA integrada na segurança da conta
|
||||
|
||||
Concluída interface de adesão/retoma por chave manual,confirmação TOTP,consulta/ocultação/renovação de recuperação e cancelamento/desactivação explícita. Usa endpoints/acções nativos Fortify e o titular autenticado,sem campos de identidade paralelos. Segurança da conta exige confirmação recente de palavra-passe apenas quando MFA está deliberadamente activo. Preparação não confirmada não activa login;GET da página não modifica a preparação. Segredos não entram em props/estado recordado;respostas MFA privadas sem cache e códigos excluídos dos dados conservados após erro. Envio usa cabeçalho X-XSRF-TOKEN do cookie cifrado. Quando expira a confirmação,nova operação é recusada e a interface encaminha para reabrir segurança e confirmar palavra-passe.
|
||||
|
||||
SGC_TWO_FACTOR_ENABLED documentado false em .env.example,configuração condicional com confirm/confirmPassword obrigatórios no mecanismo opcional. Não alterado .env,piloto ou SGF,nenhuma migração aplicada,conta inscrita,senha trocada ou grant. Obrigatoriedade por perfil e recuperação administrativa não foram introduzidas. Operação e limites em docs/mfa-adesao.md,com actualização da matriz reconciliada;não confundir código pronto com activação.
|
||||
|
||||
Regressão final29casos:28aprovados,1ignorado existente,505verificações em gestão/segurança/autenticação/baseMFA/caixa de tarefas. O cenário de segurança com feature activa deixou de ser ignorado e é testado explicitamente. PostgreSQL descartável4testes/68verificações,base removida:adesão,propriedades sem chaves,códigos renovados distintos,desactivação recusada sem senha recente,isolamento do titular,código inválido sem activação/oldinput e CSRF nativo efectivamente activo recusando419 sem token e aceitando o cookie cifrado no cabeçalho. Corrigidas inferência do titular web e asserção da bolsa de erros nativa antes dos resultados finais. Pint,PHPStan0erros,lint,tipos,build,diff e18hashes aprovados. HTTP somente de leitura confirmou página de segurança sem opções MFA e endpoints inexistentes no piloto desligado. Provas mfa-management[-pg/-http].json e logs mfa-management-*.
|
||||
|
||||
Sem revisão visual completa,ensaio de recuperação concorrente,bateria geral ou aceitação comercial;não somar provas sobrepostas à baseMFA anterior. Preparar operação concreta e salvaguarda/recuperação verificável antes de eventual pedido de activação;autorização de desenvolvimento não inscreve nem impõe MFA às contas existentes. Restantes lacunas da matriz e aprovações comerciais continuam separadas.
|
||||
|
||||
## 03/11/2026 — exportação por processo dos metadados de auditoria
|
||||
|
||||
Entregue CSV no painel Histórico da requisição,com metadados já visíveis:identidade,data,acção,utilizador e modo de execução. Página e exportação partilham RequisitionAuditTrail,sem segunda lista de eventos nem exportação do payload completo before/after. Consulta preserva empresa e Requisition.visibleTo,com actor web actual,manutenção/vigência verificadas antes de preparar e ao consumir a resposta. Não cria perfil de auditor global ou concede competências. Modo periódico conserva a atribuição técnica existente,sem inventar aprovação interactiva.
|
||||
|
||||
Exporta todos os eventos disponíveis por identidade em lotes100,resposta privada sem cache e transacção PostgreSQL consistente/somente de leitura. CSV com BOM,tratamento de aspas/delimitadores e textos de fórmula neutralizados. GET e exportação não geram auditoria/recibo de leitura nem alteram documentos,etapas,orçamento ou stock. Fonte original e eventos imutáveis preservados. Âmbito e pendências em docs/auditoria-metadados-requisicao.md e matriz reconciliada:exportação geral,retenção,certificação,protecção SQL administrativa,volume e histórico paginado no ecrã continuam fora deste incremento.
|
||||
|
||||
Regressão final35testes/1016verificações em InternalRequisitionCandidate,ProcurementReviewReport e WorkflowTaskInbox. PostgreSQL descartável2testes/139verificações,base removida. Testados105eventos adicionais ao evento nativo,sem corte na janela100,paridade com ecrã,ordem,exclusão de marcadores privados before/after,texto de fórmula,isolamento de requisitante/departamento/empresa,manutenção/vigência e comparação de registos antes/depois sem mutação. Corrigida referência ao identificador já desestruturado no componente antes da validação final de tipos/build. Pint,PHPStan0erros,lint,tipos,build,diff e18hashes aprovados. HTTP somente de leitura comparou detalhe/CSV da requisição sintética existente2 em quatro perfis e conferiu cabeçalhos/âmbito do conteúdo. Provas requisition-audit[-pg/-http].json e logs requisition-audit-*.
|
||||
|
||||
Sem migração,contas/grants,decisões ou comandos manuais de negócio no piloto;SGF/8051 preservados. MFA e respectiva migração continuam desligados/não aplicados como antes. Sem nova bateria geral,revisão visual/folha de cálculo ou ensaio de capacidade;não somar regressões sobrepostas. Não declarar auditoria geral ou aplicação integralmente concluídas por esta exportação de metadados.
|
||||
|
||||
## 03/11/2026 — histórico de requisições paginado e leitura coerente
|
||||
|
||||
Histórico do detalhe da requisição passou a paginar25eventos por audit_page,validado1..1000000,conservando todos os registos e a ordem dos mais antigos primeiro. Metadados de paginação separados da lista,sem duplicar o payload. Ligações Inertia pedem apenas audit/auditPagination,preservam estado e posição e incluem âncora do histórico;preparações/decisões abertas não são reiniciadas apenas por mudar a página. A navegação parcial não decide processos;os comandos continuam a revalidar competências,origens e versões no motor nativo.
|
||||
|
||||
Detalhe relê a requisição autorizada dentro de transacção consistente/somente de leitura em PostgreSQL,em vez de reutilizar apenas a fotografia do route binding obtida antes da transacção. Histórico Inertia encriptado. CSV existente continua integral e usa a projecção comum,sem herdar limite/página do ecrã. Sem novas competências,tabelas ou registos históricos.
|
||||
|
||||
Regressão final35testes/1044verificações em InternalRequisitionCandidate,ProcurementReviewReport e WorkflowTaskInbox. PostgreSQL descartável2testes/167verificações,base removida:105eventos sintéticos adicionais à criação nativa,primeira/segunda/última página de6linhas,contagem integral,parâmetros inválidos,CSV completo,conteúdos privados excluídos,âmbito e comparação de registos sem mutações. Pint,PHPStan0erros,lint,tipos,build,diff e18hashes aprovados. HTTP somente de leitura no piloto confirmou encryptHistory,resposta parcial sem a requisição completa,lista até25,contador,recusa de página inválida,CSV e perfis sem acesso. Provas audit-pagination[-pg/-http].json e logs audit-pagination-*. Provas anteriores de metadados preservadas,sem as reescrever ou somar números sobrepostos.
|
||||
|
||||
Sem migração,decisões,contas/grants,comandos manuais de negócio ou movimentos no piloto;SGF/8051 e activação MFA preservados. Matriz e documento de auditoria actualizados:paginação do histórico deixa de estar pendente,mas capacidade,visual/folha de cálculo,retenção,certificação e auditoria geral continuam sem encerramento por este incremento. Não houve bateria geral ou revisão visual completa e não foi declarada conclusão integral do SGC.
|
||||
|
||||
## 03/11/2026 — indicador de necessidades por aprovar ligado ao relatório e CSV
|
||||
|
||||
Relatórios de compras passaram a permitir attention=unapproved_needed,aberto directamente do indicador operacional ou pelo filtro opcional:estado draft/pending e data de necessidade anterior ao dia da consulta. Intersecta pesquisa,estado,departamento e período de criação existentes. Hoje/futuro e pedidos aprovados/rejeitados/cancelados não contam como necessidades por aprovar ultrapassadas. Data canónica apresentada na linha e acrescentada no fim do CSV,conservando as dez colunas anteriores. Não é prazo atribuído ao aprovador nem atraso comprovado do fornecedor e não cria tarefa/decisão por silêncio.
|
||||
|
||||
Consulta/indicadores capturam o mesmo instante na leitura consistente;lista25,contagens sobre todos os resultados e CSV integral. Ao consumir a exportação,revalidados titular web,empresa,manutenção e funções actuais,construindo novamente a consulta dentro da transacção própria de leitura. Projecção de ordens recebe esse mesmo titular explícito em vez de depender de request global. Mantidos dinheiro exacto,conteúdo privado,CSV protegido e competências nativas. Revogação após preparar a resposta é recusada antes de emitir linhas.
|
||||
|
||||
Regressão final29testes/726verificações em ProcurementReports,ProcurementReviewReport e WorkflowTaskInbox;PostgreSQL descartável2testes/71verificações,base removida. Testados27pedidos,duas páginas,CSV completo,hoje/futuro/estados fechados,parâmetros,passagem de dia,departamento e revogação no consumo do stream,sem mutações de consulta. Testes PostgreSQL confirmam fixtures apenas na base com nome guardado compras_receipts_test_<12hex> para exercitar a transacção própria;limpam schema temporário/funções entre casos,sem relaxar a salvaguarda da aplicação. Corrigida asserção da excepção encapsulada nativa do stream antes dos resultados finais. Pint,PHPStan0erros,lint,tipos,build,diff e18hashes aprovados. HTTP no piloto comparou contagem do indicador com lista/CSV nos perfis existentes. Provas needed-attention[-pg/-http].json e logs needed-attention-*.
|
||||
|
||||
Sem migração,contas/grants,comandos manuais de negócio,novas datas de aprovação,decisões ou movimentos no piloto;SGF/8051 e activação MFA preservados. Matriz e docs/relatorios-necessidades-por-aprovar.md actualizados. Sem bateria geral,revisão visual,impressão ou ensaio de capacidade;não somar provas sobrepostas nem declarar relatórios/aplicação integralmente concluídos.
|
||||
|
||||
## 03/11/2026 — contagens de aprovadas ligadas à consulta e exportação
|
||||
|
||||
Relatórios passaram a abrir indicadores de aprovadas sem propostas registadas e aprovadas sem ordem visível,por attention=approved_without_quotes/approved_without_order. Campo Acompanhamento reúne as duas opções e a necessidade ultrapassada por aprovar,sem novos dados obrigatórios. Indicadores conservam filtros e regressam à primeira página. Consulta usa predicados SQL antes da paginação25 e CSV integral. Registo de proposta e ordem visível passam a consultas auxiliares comuns usadas tanto nos predicados como nas projecções de contagem/ordem,sem segunda regra de elegibilidade ou cópia de documentos.
|
||||
|
||||
Mantidos acesso por empresa/departamento,actor explícito e controlo actual de competências/stream. Propostas expiradas continuam registadas para esta contagem;avaliação,elegibilidade,selecção e emissão permanecem nos motores/aprovações existentes. Os dois conjuntos sobrepõem-se e ausência de ordem visível não autoriza encomendar. Não foram criadas tarefas ou rascunhos pela leitura.
|
||||
|
||||
Regressão final31testes/840verificações em ProcurementReports,ProcurementReviewReport e WorkflowTaskInbox. PostgreSQL descartável2testes/114verificações,base removida. Testados27aprovados sem documentos,proposta expirada registada sem ordem,pendente excluído,duas páginas,CSV completo,intersecção de estados,empresa/departamento e ausência de mutações nas fontes/orçamento/stock/auditoria. Corrigida apenas a obtenção da proposta da fixture no novo teste antes dos resultados finais. Mantido o isolamento PostgreSQL com guardas e limpeza do esquema temporário. Pint,PHPStan0erros,lint,tipos,build,diff e18hashes aprovados. HTTP no piloto comparou cada indicador com a lista/CSV para os perfis existentes,sem decisões. Provas approved-attention[-pg/-http].json e logs approved-attention-*.
|
||||
|
||||
Matriz e docs/relatorios-aprovadas-sem-documentos.md actualizados. Sem migração,contas/grants,aprovações,escolha de fornecedor,emissão,movimentos ou comandos manuais de negócio no piloto;SGF/8051 e activação MFA preservados. Sem bateria geral,revisão visual,impressão ou capacidade;não somar provas sobrepostas nem declarar aplicação ou todos os relatórios completos.
|
||||
|
||||
## 03/11/2026 — verificação técnica de saúde da reposição sem executar compras
|
||||
|
||||
Entregue sgc:replenishment-health,com saída humana/--json e códigos0/1,sem descobrir origens,drenar fila,criar compras,aprovar ou actualizar heartbeat. Reutiliza observação e agregação de trabalhos de ReplenishmentQueue;consulta de consola sem identidade interactiva/sessão HTTP e transacção de leitura consistente em PostgreSQL quando própria. Resultado inclui somente instantes,motivos e contagens técnicas,não empresas/pessoas/artigos/erros privados. Falha de consulta produz indisponibilidade genérica e registo técnico.
|
||||
|
||||
Separação explícita entre agregação global técnica e consulta por empresa,conservando inclusive o âmbito vazio de utilizador sem empresa. Nova passagem nativa associa o resultado à instalação/composição/base por hash,sem guardar nomes,caminhos ou credenciais. Associação diferente é rejeitada;legado sem associação mantém compatibilidade de leitura na interface mas não permite sucesso no novo comando. A verificação de saúde não reescreve/actualiza a observação para simular execução. Resultado técnico não é certificação de configuração funcional,processo activo futuro,assinatura do servidor ou aceitação comercial.
|
||||
|
||||
Regressão final46testes/473verificações em ReplenishmentHealth,ReplenishmentHeartbeat,ReplenishmentProcessRecovery,WarehousePilotReadiness e AutomaticPurchases. PostgreSQL descartável6testes/43verificações,base removida. Cobrem leitura sem mutações de tabelas/telemetria,JSON/códigos de saída,passagem ausente/obsoleta/corrompida/falhada,pêndencias/falhas,duas empresas/sem empresa,composição diferente,recusa de identidade interactiva,excepção sem exposição e associação inválida/legada/correcta. Pint,PHPStan0erros,diff e18hashes aprovados. Sem alteração de frontend e sem alegar nova compilação ou revisão visual. HTTP só de leitura conferiu diagnóstico administrativo existente e recusa do perfil sem competência;comando de saúde executado apenas em bases descartáveis. Provas replenishment-health[-pg/-http].json e logs replenishment-health-*;provas históricas de heartbeat/processo preservadas,sem somar regressões sobrepostas.
|
||||
|
||||
Matriz e docs/operacao-reposicao.md actualizados. Sem migração,contas/grants,decisões,comandos manuais de negócio no piloto,monitor recorrente ou instalação Windows;SGF/8051 e activação MFA preservados. Operação comercial após reinício,capacidade e restantes pendências da matriz continuam separadas. Não transformar este comando de consulta em prova de instalação,monitor activado ou aplicação concluída.
|
||||
|
||||
## 03/11/2026 — entrega por bloco R1: recepção documental
|
||||
|
||||
Adoptado o plano docs/plano-entregas-sgc.md: construir blocos funcionais e validar em conjunto no fecho, mantendo verificações críticas dirigidas durante a implementação. R1 acrescenta evidências privadas à recepção confirmada, reutilizando origem e responsabilidades nativas, com repetição segura, integridade na descarga, auditoria e navegação para o processo. Não repete stock, aprovação ou recepção física.
|
||||
|
||||
Validação final: ReceiptDocumentBlockTest + ReceiptStockTest, 36 testes/271 verificações; PostgreSQL descartável 5/78, base removida. PHPStan sem erros, TypeScript, compilação de produção, Pint, diff e 18 hashes de execução conferidos. Prova docs/proofs/receipt-block.json e limites em docs/recepcao-documental.md. Sem revisão visual completa, carga ou instalação no piloto. Migração documental 2026_11_03_000002 pendente de autorização específica; não aplicar incidentalmente MFA. Sem novas contas, permissões ou decisões de negócio. R1 não declara todo o módulo Recepção concluído.
|
||||
|
||||
Reference in New Issue
Block a user