compras/docs/desenvolvimento.md

Desenvolvimento do SGC

Consulta de fornecedores/cotações/adjudicação — entrega para revisão, 02/11/2026

Implementado núcleo partilhado Sourcing e adaptador/ecrãs SGF, reutilizando preços/descontos e pontuação existentes, defaults preservados de comparação, autenticação/contexto/permissões e reserva da origem. Candidata 040fb0cb67a77d61, ZIP SHA-256 dfb122bc4532ce730d500ddec0112fe4d93cb1197fa5aef21b576f4049e7312a; relatório/matriz/provas. Fonte aprovada ID 1/100 MZN/versão 3, reserva e consumo preservados; sem nova requisição ou efeito de pagamento. Schema aditivo com quatro tabelas e ledger sourcing R1; ledger base R2 preservado, catálogo explicitamente ampliado sem outorga automática.

Após a decisão do proprietário «Preparar sem criar outra conta» e autorização do mapa, concedidos somente três direitos em 1/1/1: prepare ao ID 1, evaluate/propose ao ID 2. Consulta sem acréscimos. Em 8039 ficam três fornecedores/cotações e uma avaliação elegível por cotação, sem proposta/confirmação por faltar o segundo avaliador e confirmador independente. Fluxo completo passou apenas nas cópias, com identidade/departamento de fixture; nenhum utilizador persistente criado. Testados replay, concorrência real/CAS/confirmações concorrentes, versão obsoleta, revogação, acesso indevido, falha transaccional, migração/replay/CLI, imutabilidade e recuperação de código separada de restauro de dados/schema. Refinamentos finais de código preservaram também os dados SS antes/depois. Provas anteriores aceites reutilizadas.

Pendências explícitas: composição de identidades, parametrização comercial/cadastro real, orçamento divergente, níveis acima do primeiro limite e restrição nativa de delegação. Não ampliar direitos ou mudar regras por arrasto. Próxima decisão é a revisão destas limitações, não iniciar encomendas/recepção/pagamentos. Tempo/sgf_tempo_dev/0.1.1 preservados; nenhuma publicação, contacto externo, conta 8041 ou GRANT/REVOKE SQL. Revisão visual separada.

Primeiro percurso de requisições fechado em 8039 — 02/11/2026

Autorizada e aplicada a correcção de leitura exclusivamente no adaptador SGF: view no contexto permitido já não exige autoria/aprovação/configuração. Nova candidata 166e397e3ca63f02 altera apenas Port.php face à 401ce31ae5f2dd20; hashes e provas de HTTP/actualização/reversão/reconciliação registados. Consulta lê listagem/detalhe/três eventos da requisição existente de 100 MZN, sem recriação/submissão; recusas de escrita, decisão, administração e contexto indevido mantidas. Reversão reproduziu a limitação antiga e reaplicação restituiu leitura; reserva única, versão 3, direitos/contas/configuração intactos. 109 tabelas reconciliadas na demonstração actual; auditoria anterior preservada com novos eventos de recusas. Sem schema/DCL ou implantação real. Próximo percurso escolhido: requisição aprovada → processo/consulta de fornecedores → cotações/comparação → adjudicação independente e histórico, ainda por incorporar. Não confundir com integração integral. Revisão visual separada; Tempo/sgf_tempo_dev em 0.1.1 preservados.

Execução autorizada na demonstração 8039 — 02/11/2026

Confirmados pasta/base/cluster/contexto e preparado backup privado antes da escrita. Habilitada candidata somente no desenvolvimento existente 8039/55439, com exactamente 14 direitos aprovados no contexto 1/1/1, centro SINTETICO-REPRO/OPER e dotação 10.000 MZN/2026 aprovada por ID 2 após preparação por ID 1. Requisição 1/100,00 submetida, retry sem reserva duplicada, aprovada por outra identidade e consultada pelos intervenientes. Contas/direitos anteriores preservados; bootstrap extraordinário fechado. Sessões desta cópia corrigidas de array para file. Entrega/provas/recuperação e limitação de consulta: view isolado não permite ao Consulta ler requisição alheia, recebe 404; não alterada a regra nem acrescentados direitos para contornar. Próxima decisão é definir esse âmbito de leitura. Nenhum GRANT/REVOKE, 8041, conta nova, publicação ou alteração da Tempo/sgf_tempo_dev; implantação real adiada, 0.1.1. Revisão visual separada e provas anteriores reutilizadas.

Proposta única de desenvolvimento isolado — próximo âmbito corrigido

Por indicação do proprietário, suspensa a proposta de instalação técnica desactivada no SGF real. Proposta concreta reutiliza desenvolvimento persistente 8039/55439, base sgf_modules_dev_2576427d1939, empresa/unidade e três identidades sintéticas existentes. Leitura READ ONLY confirmou a identidade e role proprietária e ausência de cb/ir; nenhum acesso alterado. Valores de centro/dotação/política são exclusivamente proposta sintética. Sem novo DCL, sem segundo administrador exigido para demonstração; regra de dois na entrega empresarial identificada. Confirmação pendente antes de habilitar/atribuir acessos; sgf_tempo_dev e Tempo intactos, pacote 0.1.1.

Candidata SGF corrigida — estado actual, 02/11/2026

Sucede ao inventário/bloqueantes históricos abaixo: OPERATIONAL-CANDIDATE-401ce31ae5f2dd20, schema revisão 2 com as duas dependências incluídas, centros/dotações por interface e catálogo administrativo compilado. 157 controlos aprovados, restauro de 103 tabelas, roles distintas e restritas, apenas dados sintéticos em bases removidas. Decisão/procedimento actualizado, matriz, prova e SQL proposto, não executado. SGF permanece 0.1.1, sem instalação, activação ou alteração de acessos/base. Próximo passo exige confirmação separada da operação concreta e SQL, backup/restauro real e configuração da empresa; detalhes do incremento no registo final deste documento.

Decisão de instalação: inventário real e bloqueantes — 02/11/2026

Pedido expresso: apresentar decisão concreta, sem instalar até confirmação. Reconferidos ZIP/hashes e planos read-only; inspeccionada a base efectiva sgf_tempo_dev/127.0.0.1:55432 por transacção READ ONLY. Resultado em proofs/sgf-installation-decision-inventory.json; decisão em decisao-instalacao-sgf.md. 87 tabelas existentes, nenhuma cb/ir/instalação, role runtime sgf_dev_app sem DDL; proprietário sgf_dev_owner identificado, sem credenciais consultadas. Baseline de concessões/pertenças/auditoria e ponteiro preservado. Sem backups, migrações, grants, aplicação de código ou controlo de serviços.

Recomendação fundamentada: não aprovar o ZIP actual como percurso operacional no destino. Além de ligação migradora e privilégios mínimos das novas tabelas/sequências (não incluídos no instalador para runtime separado), falta bootstrap operacional por interface dos centros/dotações; BudgetWorkspace depende de cb_ui_commands/cb_consumption_sources ausentes do contrato candidato. As provas sintéticas com role proprietária e cadastros preparados conservam o seu âmbito, não provam esse arranque vazio/least-privilege. Catálogo funcional está implementado na candidata, ainda não instalado; equipamentos/peças são fora do âmbito básico. Uma só concessão administrativa no destino, sem segundo administrador para entrega/activação. Não contornar com fixtures, SQL manual de negócio, permissões DDL no runtime ou orçamento desactivado por conveniência.

Matriz reconciliada com aceitação técnica expressa da navegação modular em 02/11; pendências visual/associações/volume separadas, sem repetir suites. Próxima acção técnica: resolver/ensaiar as lacunas de implantação e só então apresentar operação exacta para confirmação; não presumir instalação/activação pelo pedido de decisão. SGF continua 0.1.1 e candidata 5fae7cf7f99c42ba imutável.

Reconciliação do estado da navegação modular SGF — 02/11/2026

Na continuação após a candidata de updates, conferidos os documentos próprios do SGF MODULAR_NAVIGATION_DELIVERY, MODULAR_NAVIGATION_COMPLETION, MODULAR_NAVIGATION_VISUAL_REVIEW e proofs/modular-navigation-recheck-20261102.json. Existe resultado técnico documentado: seis módulos, 185 testes/3.220 asserções, suite focada de 8/90 e três perfis isolados, com retoma de integridade já registada no SGF. As referências anteriores de Compras a «sem resultado apresentado» são agora históricas e sucedidas por este registo e pela matriz actualizada. Não foram repetidas suites, comparação de 184 ficheiros ou provisionamento nesta leitura documental.

Revisão visual/recargas, reconciliação de associações antigas e volume/paginação mantêm pendências próprias; não confundir navegação implementada com processos comerciais completos ou aceitação. A interface chama à configuração geral «Opções gerais». Sem alteração de código/dados/permissões, navegador ou instalação de candidata; SGF 0.1.1 preservado. A decisão de instalar a candidata continua separada. Matriz reconciliada.

Transição versionada e caches Laravel nativos — 02/11/2026

CodeDeployment evoluiu para actualização de um bundle instalado sob o mesmo contrato: registo privado da versão seleccionada, plano ligado ao estado actual, arquivo do bundle anterior, reversão local exacta, recusa de reversão fora de ordem/replay antigo, novas tentativas sem sobrescrever journals e verificação de origem/conteúdo extra/schema/baseline. Diferenças em schema/catálogo/composição exigem plano próprio. Bundle antigo sem proveniência não é adoptado implicitamente. Ponteiro purchasing 0.1.1 continua separado e preservado.

Acção cache usa Artisan nativo (config:cache, route:cache, event:cache) pelo PHP fixado, arquiva/invalida caches antes de compilar e regista resultados parciais/hashes. Reversão de caches recompilados invalida-os para voltar a compilar na versão reposta; não reintroduz configuração compilada antiga. Retry de rollback não mexe nos caches reconstruídos da versão anterior. Caches posteriormente alterados são preservados por recusa de recuperação cega. Caches personalizados mantêm contrato separado.

Prova nova sgf-update-cache-delivery.json: 32 controlos aprovados, transição desde 10dce6cd57fa1f31, falha de troca, nova tentativa, caches nativos completos, compilação interrompida/cache inválido recuperados, CLI e reinícios de servidor PHP de teste. Verificados 503 de manutenção, 401 na rota em cache, 404 após retirar módulo e healthcheck 200. Sem suites anteriores repetidas, intervenção em serviços/bases/direitos públicos do destino ou publicação. Candidata OPERATIONAL-CANDIDATE-5fae7cf7f99c42ba e ZIP verificável registados na prova e na matriz/procedimento. Dependencies reutilizadas por hardlinks apenas de cópia anterior descartável, nunca do vendor real. SGF de destino permanece 0.1.1. Próxima acção é revisão da candidata/procedimento e decisão separada de instalação; não activar por consequência do desenvolvimento. Reorganização modular posterior continua com entrega própria pendente.

Aplicação e reversão do código em manutenção — 02/11/2026

Implementados CodeDeployment e scripts/sgf-code-deploy.php, com plan read-only, conferência de destino/manifesto/baseline, lock exclusivo, backups/journal duráveis, preparação/troca dos ficheiros e bundle, invalidação/restauro de caches padrão e recuperação de aplicação parcial. Exige manutenção de ficheiro e declaração --offline do operador; não termina/reinicia serviços, não abre manutenção, não activa configuração, não concede direitos e não abre base de dados. Recusa cache personalizado, ficheiros locais alterados e caches recriados; mantém estado para reconciliação em vez de sobrescrever. Primeiro baseline apenas; transição entre versões de bundle existente ainda pendente. Não confundir rename individual/journal com transacção multi-ficheiro: os serviços devem permanecer parados.

scripts/sgf-code-deploy-proof.php, executado pelo wrapper/PHP 8.4.27: 42 controlos novos aprovados, CLI real e quatro cópias descartáveis só de ficheiros, incluindo interrupção durante sobreposições/depois da troca do bundle, recuperação, rejeição de concorrência/alterações locais/cache divergente e ponteiro preservado. Prova, candidata OPERATIONAL-CANDIDATE-10dce6cd57fa1f31. Sem DB, browser, reinício de serviços ou repetição das suites aceites. Nenhum código/schema/concessão/ponteiro alterado no SGF de destino; permanece 0.1.1. Procedimento exacto e limites actualizados em transferencia-sgf.md. Próximo trabalho técnico: transição versionada do novo bundle e conferência dos caches nativos/gestor de serviços numa instalação isolada, sem aplicar no destino nem presumir activação.

Composição de arranque e prova HTTP isolada SGF — 02/11/2026

Implementados BootOverlay, Composition, RuntimeContext e entry point local do bundle. A sobreposição do provider nativo carrega classes e rotas do módulo; descoberta de Compras reconhece purchasing_requisitions.view. Middleware específico é acrescentado depois da sessão/autenticação/contexto nativos e confere opção, destino/schema/âmbito, módulos adquiridos e selecção/geração do contexto. Autoridade inicial mantém âmbito administrativo, sem exigir direito funcional ainda não atribuído. A CLI aceita/verifica o entry point bootstrap.php do bundle. Candidatas anteriores não foram reescritas.

Prova nova scripts/sgf-composition-proof.php: 27 controlos aprovados, usando cópia descartável do SGF com dependências próprias, sem .env/dados/documentos/sessões da instalação existente, PostgreSQL sgc_composition_<12hex>/role restrita e APP_ENV production. Provider, Composer, kernel, rotas, autenticação/CSRF e administração nativos; router de prova não regista rotas ou classes do módulo. Conferidos arranque efectivo da cópia, CLI plan, configuração inicial, delegação, contexto, percurso de requisição/reserva/aprovação independente/consulta e bloqueios por revogação, opção diferente, contexto antigo, módulo não adquirido/desactivado. Sem browser e sem suites anteriores repetidas. Prova, candidata OPERATIONAL-CANDIDATE-4b25f81932efd69d. Base/role removidas; fonte/código/schema/concessões e ponteiro 0.1.1 do SGF de destino preservados.

Próxima acção concreta: rotina de aplicação atómica das sobreposições e código, backup/reversão de ficheiros do host e gestão de caches/reinício. O ensaio HTTP usa caches não pré-compilados; não declarar a instalação operacional completa nem activar no destino sem decisão separada. A reorganização modular do SGF continua entrega distinta e sem resultado próprio apresentado. Matriz e limites actualizados em transferencia-sgf.md.

Composição orçamental e preparação de schema SGF — 01/11/2026

Continuação sem instalar/activar no destino: criada integrations/sgf/operational, com schema orçamental do contrato SGF existente, composição alternativa do mesmo BudgetAdapter/motor, verificação de destino/schema/âmbito e registo imutável sgc_installations. O preparador scripts/prepare-sgf-operational.php produz artefacto de revisão com sobreposições e suporte local, sem escrever na pasta SGF. scripts/sgf-internal-install.php oferece plan read-only e migrate de preparação do schema: confere hashes do host/manifesto/destino/backup, índice pg_restore, fundação e contrato de orçamento; DDL transaccional com lock e revisão/hashes/operador/role/backup. Não concede direitos, activa rotas ou troca o ponteiro. Sem down automático; schema parcial/incompatível é recusado. Fundação orçamental nova é criada vazia, sem fixtures.

Prova proofs/sgf-operational-delivery.json: 20 controlos novos aprovados, incluindo CLI, falha/rollback e retry, preservação de orçamento/direitos, esquema novo/existente/parcial/incompatível e reserva pelo mesmo motor fora do ambiente QA. Backup/restauro adicional em base descartável fora do prefixo QA com APP_ENV=production confirma o registo/schema, a reserva e a revogação. Bases e role removidas; nenhum teste aprovado anterior da requisição repetido. Candidata OPERATIONAL-CANDIDATE-29687a1c9bc0e0b5; IR e ACCESS anteriores preservadas. Ponteiro SGF permanece 0.1.1, sem schema/direitos/código instalado alterado, publicação ou contratações para terceiros.

Limites/próxima acção: aplicar controladamente as sobreposições e a composição de arranque/rotas numa cópia isolada e conferir a integração HTTP, incluindo o novo ecrã de autoridade. Preparação de schema não equivale a activação do módulo ou entrega comercial integral. Só depois propor eventual activação na instalação de destino, que continua a exigir decisão separada. A reorganização modular posterior mantém entrega própria pendente. Matriz e comandos actualizados em transferencia-sgf.md.

Preparação candidata do catálogo e da autoridade inicial SGF — 01/11/2026

Continuação do trabalho sobre os bloqueantes de instalação: implementados integrations/sgf/access/AccessOverlay.php, InitialAuthority.php, rotas/ecrã candidatos e scripts/prepare-sgf-access.php. O preparador lê o host e produz sobreposição com hashes, sem o alterar. Reutiliza administração, permissões, contexto e auditoria nativos. Corrigido na sobreposição o risco de novas unidades receberem todos os direitos quando se alarga o catálogo; continuam a receber só os dois direitos unitários anteriores. Revogação unitária confere e remove os direitos derivados atomicamente. Autoridade inicial nominativa, explícita e auditada por âmbito, sem perfil automático, só quando habilitada na composição; replay não reconstitui direitos revogados.

Prova nova scripts/sgf-access-proof.php: 24 controlos aprovados com PHP fixado do SGF/PostgreSQL descartável/role restrita, incluindo atribuição/revogação nativas, contexto antigo, direitos não escolhidos, falha de auditoria/rollback, repetição e renderização. Prova e artefacto. Nenhuma suite previamente aprovada da requisição repetida; nenhuma migração, concessão, rota ou ficheiro de código alterado no SGF instalado. Overlay ACCESS-CANDIDATE-a69f06e21747228a; candidata IR original preservada; ponteiro SGF 0.1.1 conferido inalterado. Não declarar instalação operacional concluída: faltam composição orçamental, instalador/schema rastreável, integração das rotas e prova HTTP do novo ecrã. Reorganização modular posterior continua com entrega própria pendente. Matriz/procedimento actualizados em transferencia-sgf.md.

Impacto das pendências de instalação SGF — conferência posterior, 01/11/2026

Classificação e procedimento acrescentados em transferencia-sgf.md, sem alterar código/candidata nem repetir os testes aprovados. Equipamentos/peças fora do recorte básico de consumíveis/serviços/outros. Bloqueiam a instalação operacional: catálogo administrativo e autoridade inicial auditada para os novos direitos, composição orçamental que ainda exige budget-testing/base QA, instalador rastreável de schema e registo operacional de arranque/rotas. O catálogo actual Permissions::UNIT não permite gerir os direitos da candidata; a outorga exige também posse prévia do direito. Concessões sintéticas não são solução de entrega.

Documentados os passos existentes e os ainda sem executor, backup integral, rollback de DDL, retirada de código sem apagar schema, retry de comando e restauro para nova base com reconciliação de operações e revogações. Não há hoje comando de instalação operacional completo; os ZIPs são de revisão e não devem ser extraídos sobre a raiz SGF. Ponteiro 0.1.1 e testes aceites preservados. Reorganização modular posterior do SGF continua sem resultado apresentado nesta entrega, separada da integração de requisições. Próxima acção: resolver os bloqueantes de entrega operacional antes de propor a instalação; sem activar por arrasto.

Candidata de requisições internas para o SGF — 01/11/2026

Implementado o percurso autorizado rascunho → submissão/reserva → aprovação independente → consulta num motor comum, com adaptadores autónomo e SGF. Reutilizados processos, orçamento, identidade e permissões existentes. Origem, versões, snapshots, histórico e recibos de comando são preservados; locks e transacções evitam duplicação em repetições concorrentes. Configuração explícita por empresa/unidade/departamento/centro, sem atribuição de direitos pelo selector ou pela política. Código e ecrãs candidatos em integrations/sgf/internal-requisitions; fonte comum em packages/purchasing.

SGF permanece 0.1.1, sem activar 0.1.2 ou a nova candidata, publicar, aplicar schema ao destino ou alterar direitos públicos. Candidata de revisão não instalável pelo updater actual: manifesto e arquivos. Migração 46 da origem e schema SGF ensaiados apenas em bases sintéticas isoladas. Provas de isolamento, acesso directo, revogação, concorrência em processos separados, falha após reserva, resposta perdida e recuperação em proofs/internal-requisitions-sgf.json. Backup/restauro de 22 tabelas confere dados/schema/constraints/triggers e consulta posterior, separadamente da reversão de código.

A regressão alargada identificou e permitiu corrigir respostas 403 por conflitos e consulta indevida de schema na navegação pública. Verificações finais e limites registados na matriz de transferência. Não foi usada a via de navegador bloqueada. Ecrãs verificados por HTTP, lógica de acções e compilação; revisão visual não realizada. Próximo passo: rever a candidata e preparar a instalação operacional compatível com schema e catálogo administrativo, mantendo qualquer activação dependente da decisão separada já exigida pelo proprietário. Equipamentos/peças, fornecedores e contratação para terceiros não foram incorporados neste incremento.

Resultado final da candidata IR-CANDIDATE-bfa807e2b3c4fae7: regressão SQLite 881 aprovados/2 ignorados/8.950 asserções; PostgreSQL autónomo 46 testes/339 asserções; SGF 43 controlos; modelo de ecrãs 23 controlos. PHPStan dirigido, tipos, lint e build aprovados. Resumo das verificações. Ponteiro SGF 0.1.1 conferido inalterado, sem migrações persistentes ou concessões no destino.

Conferência de independência, reversão e matriz antes de ampliar — 01/11/2026

Pedido posterior do proprietário: antes de ampliar, confirmar instalação cliente independente de Compras, delimitar rollback e classificar processos/adaptadores/ecrãs em transferido/parcialmente transferido/pendente. Matriz revista em transferencia-sgf.md, também reconciliada no documento SGF. Exclusão de contratações para terceiros no SGF mantida fora das pendências de implementação.

Confirmado: geração do pacote requer Compras/canal, coordenação da transferência local usa as duas pastas, mas instalação/execução cliente só usam o seu SGF, dependências locais, ZIP e SHA-256 aprovado. Acrescentado teste que torna indisponível a pasta de origem sintética e executa o loader/artefacto em processo separado, com todos os includes dentro da pasta cliente. Seis testes do mecanismo/29 asserções aprovados. Prova real SGF pelo wrapper/PHP 8.4.27: versão 0.1.1, cálculo de referência correcto, todo o PHP carregado dentro do host e nenhuma ligação à base. scripts/purchasing-client-check.php é uma prova read-only, sem arranque da aplicação ou consulta empresarial. Prova proofs/purchasing-client-independence.json.

Rollback comprovado cobre apenas código/ponteiro de pacote. Não reverte dados, schema, dependências, configurações ou permissões; a existência de pastas antigas não demonstra recuperação de futuras migrações. O contrato actual declara/impõe ausência de mudanças de schema/concessões e recusa pastas de migração/seed; não é sandbox para PHP arbitrário. Antes de módulos com persistência: propriedade das tabelas, autoria/versão, compatibilidade código/schema, aplicação idempotente, auditoria, backup/restauro ensaiados e estratégia de recuperação/reconciliação. Não activar down/restauro destrutivo por arrasto.

Antes da nova instrução, já se preparava extracção de descontos/pontuação para o pacote e adaptação das fachadas em Compras. Testes locais: 103 testes existentes/1 564 asserções e cinco de economia/17 asserções; análise PHP dirigida aprovada. Ao receber o pedido, interrompida a transferência antes da activação. O processo filho chegou a publicar a candidata 0.1.2, mas o SGF mantém 0.1.1; não houve migração, nova capacidade activa, nova permissão ou ecrã SGF. Testes SGF de capacidades ainda não instaladas foram retirados da suíte activa. Preparação e candidata conservadas e marcadas pendentes no SGF, sem declarar transferência por testes locais.

Próximo percurso proposto na matriz, ainda não iniciado: requisição interna completa até decisão independente/consulta, com a reserva orçamental do percurso existente, adaptadores e ecrãs. A escolha de sequência permanece para a revisão da matriz; não foi substituída por activação da preparação económica. Cinco artefactos do mecanismo/prova de cliente reconciliados por hashes entre origem e SGF. Sem publicação no domínio ou manipulação dos dados da demonstração.

Transferência para SGF e mecanismo de actualizações — 01/11/2026

O proprietário corrigiu expressamente a prioridade: transferir as capacidades de Compras para o SGF e criar o mecanismo que levará melhorias posteriores. A selecção de contexto anterior é fundamento de autorização, não a entrega principal. Implementado o primeiro pacote efectivamente executado no SGF e o percurso versionado de publicação/actualização, sem copiar bases, contas ou documentos. Detalhes, comandos e matriz de cobertura em transferencia-sgf.md.

A projecção de reposição foi extraída para packages/purchasing; a classe antiga é apenas fachada e o SGF carrega artefactos imutáveis dessa fonte. Confrontadas as diferenças de contexto, schema, frontend, PHP e Brick Math; não houve cópia de App/tabelas-base, fusão de identidades ou substituição de dependências. Núcleos financeiros comuns anteriores preservados. A transferência integral dos processos/ecrãs ainda não está concluída.

composer purchasing:transfer -- <SGF> <canal> verifica regressões, publica a fotografia provada, calcula nova versão patch apenas por alterações, confere integridade/versão instalada, prova a candidata com o PHP fixado pelo SGF e activa por ponteiro atómico sob lock. Retry sem alterações é no-op; deriva local de código, ZIP adulterado/incompleto, path traversal, versão repetida divergente e downgrade implícito são recusados. Versões anteriores e histórico conservados; rollback explícito só de código verificado. Contrato actual recusa alterações de schema e concessões, não abre bases e não executa seeds ou migrações. Artefactos de arranque do mecanismo têm fonte única e manifesto de hashes; runtime não depende da pasta vizinha.

Instaladas localmente 0.1.0 e 0.1.1 no SGF; a segunda melhoria é documental, sem alteração do algoritmo. Conferidos rollback real para 0.1.0, reactivação de 0.1.1 e repetição sem reinstalação. Verificação final do publisher: 86 testes/566 asserções em bases isoladas/sem base; SGF puro, pelo wrapper/PHP 8.4.27: dois testes/11 asserções. Provas da candidata em ambos os runtimes preservam consumo manual, média racional e lotes. Fachada/motor passaram análise PHP dirigida. Não se executou a suíte SGF que recria a base da demonstração; os testes deste incremento são Unit sem aplicação/base. Provas em proofs/purchasing-update-pipeline.json e proofs/purchasing-transfer.json.

Limites: pacote inicial contém o cálculo, não o workflow/persistência/UI de abastecimento nem os restantes processos. O mecanismo actualiza melhorias das capacidades já extraídas, não código ainda confinado aos módulos da aplicação. Prosseguir com extracção/adaptadores por percurso e contrato de migrações aditivas; não declarar toda a aplicação transferida. Clientes recebem instalação limpa e artefactos/configuração próprios; SGF exclui contratações para terceiros. Formalização/RH, catálogo remoto assinado e actualização operacional de módulos com schema permanecem pendentes. Sem publicação no domínio, dados empresariais, novas permissões ou contas por arrasto.

Contexto de trabalho — primeiro incremento implementado, 01/11/2026

Decisões finais. O SGC autónomo conserva as quatro opções previstas; o SGF exclui apenas contratações de pessoas/prestadores por conta de clientes. As contratações internas só podem reflectir-se em RH após formalização do contrato, respeitando a legislação laboral moçambicana; aprovação da selecção e contrato em rascunho não equivalem a formalização. O destino de RH já foi definido pelo proprietário mas não está implementado. Estas respostas resolvem as perguntas de alcance SGC/SGF registadas no fim deste documento. Não foi implementada nem certificada a formalização legal neste incremento.

Análise e reutilização. Reutilizados OrganizationAccess/User::hasFunctions, OrganizationConfiguration, versão global, lock da empresa, auditoria e menus existentes. Separados três eixos: limites comerciais da instalação por empresa (config/work_context.php), opções activadas pela empresa e permissões funcionais dos perfis associados aos contextos. A sessão guarda apenas escolha + utilizador + empresa; a disponibilidade é recalculada, incluindo revogações/expiração. A escolha não muda funções. Perfis de desenvolvimento preservados; a compatibilidade de desenvolvimento não autoriza clientes.

Implementado. Painel Inicial de escolha; selecção explícita entre duas opções e activação da única opção elegível ao escolher a área; ausência de opções sem dados de negócio. Contexto visível no shell; menus filtrados por destinos calculados no servidor além das permissões anteriores. Middleware nas rotas empresariais bloqueia outra área e opções sem percurso operacional. Perfis deixam de somar permissões de contextos diferentes nas operações de negócio. Parametrização dispõe de opções e associações de perfis, com versão/auditoria e aviso de efeito imediato sobre acesso, sem reescrever processos. Conta e administração autorizadas continuam acessíveis sem contexto.

Origem dos processos. Migração 45 adiciona política e associação de perfis, além de work_context_key em requisições/processos de Pessoas. Classificação inicial interna autorizada pelo proprietário. Scope nos dois modelos-raiz e protecção contra mudança no modelo e em SQL (SQLite/PostgreSQL); dados anteriores dos processos, decisões e snapshots preservados. O portal externo de candidatos conserva a autorização própria e não depende da escolha da sessão interna. Processos de terceiros ainda não podem ser executados; não declarar isolamento de todos os futuros percursos comerciais concluído.

Avaliação local. Em 8005, o catálogo completo é disponibilizado apenas após conferir ambiente local, base/role sintéticos e empresa através de EvaluationAccess; não altera perfis nem cria concessões comerciais para clientes. Fora dessa avaliação, SGC_PRODUCT_ENTITLEMENTS fornece os limites por ID de empresa, e SGC_PRODUCT_COMPOSITION=sgf retira contratações para terceiros. A empresa activa um subconjunto pela interface. Instalações existentes sem política preservam compatibilidade até configuração explícita; novas empresas começam com política vazia. O modo de compatibilidade não deve passar a entrega como configuração concluída.

Mudança com alterações. Protecção na navegação para o Painel Inicial, com Guardar/Descartar/Cancelar, erros de validação/rede sem trocar contexto e diálogo com foco gerido. Gravação automática limitada ao rascunho de requisição expressamente marcado, incluindo alterações programáticas às linhas; só muda depois do resultado desse formulário. Não submeter automaticamente decisões/aprovações para simular guardar. Outros formulários e várias edições simultâneas pedem conclusão pelas respectivas acções. Cobertura universal de formulários, histórico do navegador e ensaio visual da falha de gravação ainda pendentes.

RH. PeopleContractHandoff prepara apenas um envelope futuro, sem transporte, evento automático, empregado criado ou escrita em RH. Recusa selecção/rascunho, versões não persistidas e contexto de terceiros; exige estado de contrato formalizado. Esse estado ainda não é produzido pelo percurso actual. Não confundir esta fronteira técnica com módulo de RH, validação legal, fila transaccional ou integração operacional implementados.

Entrega/actualização. Instalação limpa por cliente; testes/avaliação ficam locais. sgc:delivery-check {tenant} é uma conferência sem escrita: requer produto, política, administração configurada, dois administradores permanentes e sinaliza registos empresariais a reconciliar. Não apaga dados nem substitui revisão dos cadastros/configurações, empacotamento ou rotina integral de actualizações. A migração é aditiva; actualizações não devem usar seeds de demonstração, reiniciar perfis nem alterar contextos de origem. A atribuição comercial está na configuração da instalação, ainda sem editor comercial de catálogo/contratos pela interface; catálogo por módulo/operação, distribuição SGF e actualizador comercial completo permanecem pendentes.

Verificações. Regressão geral: 860 testes, 858 aprovados, dois ignorados anteriores, 8 503 asserções. Bateria final dirigida: 66 testes/644 asserções. Contexto em PostgreSQL descartável: 12 testes/83 asserções; falha inicial por tentar relatório read-only dentro da transacção da fixture corrigida na prova, mantendo o controlo do relatório. Análise PHP dirigida sem erros, formatação dirigida e build aprovados. Análise PHP global encontrou problemas de tipagem web/candidate fora deste incremento; não declarar análise global limpa. Provas: proofs/work-context-pg.json, work-context-http.json e work-context-install.json.

Instalação e limites. Migração 45 aplicada só em 8005 pelo instalador existente com --contexts: backup/restauro conferidos, campos anteriores de 106 tabelas reconciliados, novas classificações internas conferidas, sem contas/grants alterados. HTTP real: áreas internas 200, área oposta 403, percursos de terceiros 409 com indicação explícita de pendência. Browser integrado indisponível (browser access host is unavailable); apresentação e diálogo não aceites visualmente. Venda ao cliente e contratações para terceiros permanecem opções identificadas, sem reutilização indevida dos percursos internos. Não publicado no domínio nem instalado no SGF neste incremento.

Próxima acção. Completar e conferir todos os formulários na mudança de contexto, os percursos de terceiros com seus dados/regras, catálogo comercial pela interface e actualização/distribuição. Formalização contratual e RH são incrementos próprios, com regras legais verificadas quando implementados. Não declarar os critérios originais integralmente satisfeitos por esta fundação.

Publicação do percurso de candidatos confirmada — 3b1ef20

Confirmado em produção o commit 3b1ef2031ce395d21d973d0e7a7ec6630f058db8, com serviço concluído com Result=success e ExecMainStatus=0. Inclui consulta pública paginada das oportunidades, escolha preservada na entrada e no registo/preparação do perfil e histórico paginado de comprovativos. Esta confirmação substitui as indicações históricas de incremento apenas local nas secções seguintes.

Mantidas as 44 migrações, sem novo delta de schema nesta publicação. Nginx validado, armazenamento privado partilhado persistente e escrita para o utilizador web conferidos. Navegação pública activa. Os 21 ecrãs públicos e sete percursos privados passaram na conferência HTTP. Não foram criadas candidaturas reais; a tabela de documentos continua vazia. Conferência visual dirigida e ensaio completo de candidatura no domínio permanecem pendentes. Prova proofs/candidate-flow-production.json.

Histórico completo de comprovativos do candidato, 30 de Outubro de 2026

A área autenticada deixa de limitar a lista aos 20 comprovativos mais recentes. Tem paginação própria, contagem apenas da conta e empresa autenticadas e título extraído da oportunidade preservada na submissão, sem procurar o título actual do processo ou enviar o snapshot completo. A paginação de comprovativos conserva a página de oportunidades e vice-versa, através apenas dos parâmetros numéricos validados. Perfis e comprovativos anteriores mantêm-se compatíveis. Não foram introduzidos estados de contratação, alterações documentais, novos acessos ou migrações.

Verificação dirigida SQLite: 29 testes/488 asserções nos módulos de perfil e submissões, incluindo 21 comprovativos próprios e um de outra conta, acesso à segunda página, título preservado e projecção sem dados adicionais. Onze testes frontend, tipos, PHPStan sem erros, Pint/lint dirigidos; restantes resultados finais na prova proofs/candidate-receipt-history.json. Apenas local, produção ainda em bf84575. Conferência visual continua pendente por indisponibilidade do conector.

Escolha preservada no registo e preparação do perfil, 30 de Outubro de 2026

A escolha pública segue agora tanto para a entrada como para o registo. Uma nova conta conserva uma referência à oportunidade na sessão, associada à identidade e empresa; não copia regras ou dados internos para essa referência. O perfil permite retomar o formulário depois de preparar os dados e confirmar o email, sem submissão automática. A criação da conta mantém o destino de preparação do perfil. Cada consulta reconfirma publicação, prazo e empresa; uma oportunidade retirada deixa de aparecer e produz informação genérica de indisponibilidade. Sessões com outra identidade/empresa ou referência incompleta não conservam o atalho. Sair ou concluir explicitamente a submissão remove a escolha. A confirmação de email e as restantes validações da candidatura são mantidas.

Validação final SQLite: 28 testes/457 asserções. PostgreSQL descartável: 68 testes/1484 asserções, incluindo o percurso registo → perfil → tentativa não confirmada recusada → submissão explícita após confirmação fictícia. Base descartável removida, sem contas, mensagens ou candidaturas reais no domínio. A verificação adicional de referência de sessão incompleta foi exercida em SQLite/análise estática. Compilação concluída com código zero; PHPStan sem erros, tipos, Pint/lint e frontend dirigidos registados na prova proofs/candidate-registration-selection.json. Sem novas migrações. Incremento apenas local, posterior a f5f5649; produção continua em bf84575. Conferência visual ainda pendente.

Oportunidade escolhida preservada na entrada, 30 de Outubro de 2026

O botão de entrada de cada oportunidade guarda a escolha no formulário de login e apresenta o título escolhido. Após autenticação válida, o servidor volta a conferir publicação, empresa e prazo e encaminha para o formulário dessa oportunidade. Não aceita URLs de retorno fornecidos pelo cliente. Um identificador inexistente, de outra empresa, retirado ou expirado encaminha para o perfil com mensagem genérica de indisponibilidade. A entrada não envia a candidatura, não modifica o perfil e não dispensa confirmação de email ou requisitos documentais. Criar uma nova conta mantém o percurso de preparação do perfil anteriormente existente.

Verificação dirigida final SQLite: 26 testes/400 asserções. PostgreSQL descartável: 66 testes/1426 asserções sobre os percursos de candidatos e Pessoas, incluindo os novos guardas de destino; a mensagem final de indisponibilidade foi adicionalmente conferida em SQLite e no frontend. Dez testes frontend, PHPStan sem erros, tipos, Pint e lint dirigidos. Sem novas migrações ou instalação no domínio; conferência visual continua pendente. Provas integrais da release bf84575 reutilizadas, sem repetição de toda a suíte. A compilação e prova final constam em proofs/candidate-opportunity-login.json.

Consulta de oportunidades antes do registo, 30 de Outubro de 2026

A entrada da área do candidato mostra oportunidades explicitamente publicadas, abertas e dentro do prazo, com título, tipo, data e descrição pública. Não expõe finalidade interna, regras, candidaturas, avaliações ou documentos. A consulta é paginada por empresa; a última versão da publicação controla a visibilidade, incluindo retirada. O fecho de novos registos mantém a consulta pública e a entrada das contas existentes. Preparar e enviar candidaturas continuam a exigir autenticação própria, perfil e confirmação de email conforme as regras já existentes.

A área autenticada reutiliza a mesma consulta e passa a ter paginação, em vez de omitir oportunidades depois das primeiras 20. Retirada a mensagem desactualizada de que o envio de documentos ainda não estava disponível. Não foram abertas inscrições, publicadas oportunidades ou criadas contas para testar no domínio.

Verificação dirigida: 24 testes PHP/374 asserções em perfil e submissões; PostgreSQL descartável: 64 testes/1401 asserções, incluindo Pessoas e formatos de documentos. Dez testes frontend dirigidos, tipos, PHPStan sem erros, Pint e lint dirigidos aprovados. As provas integrais aceites da entrega bf84575 são reutilizadas, sem alegar nova execução de toda a suíte. Conferência visual tentada novamente: conector devolveu native pipe indisponível e browser host indisponível. Este incremento continua local e não faz parte da release bf84575 activa no domínio. Provas proofs/candidate-public-opportunities.json e candidate-public-opportunities-pg.json.

Entrega em produção confirmada — bf84575, 30 de Outubro de 2026

O commit bf84575d10d9063c2224945e6d5627da826148a9 está em main e activo no domínio, na release 20261030-190744-bf84575d10d9-KyKKDI71. O serviço existente terminou com Result=success e ExecMainStatus=0. Esta confirmação actualiza as indicações históricas de instalação apenas local abaixo.

O instalador foi corrigido para exigir HTTP 200 em /dashboard: o anterior teste da raiz recebia o redireccionamento público esperado e provocava rollback. A validação e o rollback do instalador foram mantidos. Configuração anterior salvaguardada antes da correcção.

Delta reconciliado: 14 migrações, de 000028 a 000041, sem repetir as 30 já registadas. Backup fresco da base e armazenamento, restauro conferido e ensaio das migrações na cópia antes da transacção de produção. As 81 tabelas anteriores conservaram os seus dados nas colunas de origem; 18 novas tabelas conferidas vazias e schema final igual ao ensaio. Existem agora 44 migrações registadas. A migração 000028 acrescenta o parâmetro de IVA por empresa com valor inicial 16%, sem reescrever os valores e snapshots anteriores. Não foram criadas contas, abertas inscrições ou publicadas oportunidades automaticamente.

Armazenamento privado em storage partilhado persistente, com escrita conferida para www-data. Limites específicos do domínio: ficheiro 50M, pedido PHP e Nginx 104M, até 20 ficheiros; configuração Nginx validada e recarregada. Os 2M/8M ainda apresentados pelo PHP CLI são os limites do terminal e não os parâmetros específicos do domínio. PHP 8.4 dispõe de DOM/ZIP/fileinfo; PHP 8.5 CLI continua sem DOM/ZIP e não foi usado na instalação.

Conferência HTTP: 21 ecrãs públicos com componentes esperados, utilizador nulo e âmbito vazio; sete percursos privados protegidos. Prova proofs/candidate-documents-production.json. Conferência visual dirigida e ensaio com candidatura real no domínio continuam pendentes; não foram enviados ficheiros pessoais ou emails reais para os simular.

CV e documentos na candidatura electrónica, 30 de Outubro de 2026

Recepção de documentos integrada no mesmo envio da candidatura. A obrigatoriedade, formatos (PDF, DOCX, JPG e PNG) e limite por ficheiro vêm do formulário preservado na preparação do processo, sem procurar a versão actual da empresa. Recusados documentos desconhecidos, obrigatórios em falta, tamanho excessivo e divergência de extensão/MIME/conteúdo. DOCX exige estrutura Word/XML válida, sem declarações de entidades/DOCTYPE, macros ou executáveis conhecidos, com limites de entradas e expansão do arquivo. A conferência de formato não constitui antivírus, prova de autenticidade, validação do mérito ou aprovação documental.

Armazenamento privado separado, nomes físicos gerados e nome apresentado sanitizado. A candidatura conserva nome, tamanho, MIME e SHA-256, sem expor caminhos internos. Downloads separados para titular e equipa; conferem conta/sessão, empresa, processo e permissões actuais, registam consulta e verificam integridade dos bytes. Entrega como anexo, sem pré-visualização activa no portal. A tabela de documentos recebidos tem vínculo composto à submissão e protecção contra alteração/eliminação corrente. O comprovativo original não pode ser substituído por novo envio; mesmo identificador e mesmos ficheiros devolvem a submissão anterior, conteúdo diferente é recusado. Falha transaccional limpa os ficheiros gravados.

Limite técnico do conjunto por pedido configurável por CANDIDATE_DOCUMENTS_MAX_TOTAL_KB (inicialmente 102400 KB); limites específicos continuam na parametrização da empresa. Não existe ainda quota acumulada por candidato/empresa nem integração antivírus. Na entrega ao domínio, conferir extensões PHP DOM/ZIP/fileinfo, limites PHP/proxy e armazenamento persistente privado com backup/restauro; não activar uploads numa pasta efémera da release. Complementos, substituições e reabertura precisam de um percurso versionado próprio, sem alterar estes originais.

Migração aditiva 2026_10_30_000041_create_candidate_submission_documents instalada apenas na avaliação local 8005. Backup fresco de 501935 bytes e restauro verificados; conteúdos anteriores das 104 tabelas preservados e nova tabela vazia. Sem alterar contas/grants, repetir outras migrações ou instalar no domínio. Prova proofs/candidate-documents-install.json. PostgreSQL descartável: 62 testes/1323 asserções aprovados, incluindo perfis e Pessoas; base removida. Suíte integral: 745 testes PHP, 743 aprovados, dois anteriormente ignorados e 7619 asserções. Módulo final SQLite: 24 testes/298 asserções; frontend integral: 83 testes aprovados. Tipos, PHPStan sem erros, Pint, lint dirigido, compilação e diff conferidos. A prova proofs/candidate-documents.json regista o âmbito e hashes. Os testes de navegação pública passam a usar uma fixture sintética versionada em tests/Fixtures, deixando de depender de um ficheiro privado ignorado pelo Git. A conferência visual dirigida mantém-se pendente.

Disponibilidade geográfica múltipla do candidato, 30 de Outubro de 2026

O perfil permite manter o local principal e adicionar ou retirar outros locais, cada um com província, distrito e localidade. A morada continua separada. Entradas incompletas e locais repetidos (sem distinguir maiúsculas ou espaços exteriores) são recusados no servidor. Existe um limite técnico inicial de 20 locais adicionais por pedido, sem constituir uma política territorial ou uma classificação de candidatos. O cadastro territorial oficial continua pendente.

Cada gravação cria uma versão. Pedidos anteriores que omitem o novo campo preservam os locais adicionais já guardados; uma lista explicitamente vazia retira-os apenas da nova versão. No formulário de candidatura, o candidato pode escolher um local guardado para preencher o campo de disponibilidade, mantendo a possibilidade de o ajustar para aquela candidatura. A submissão preserva todos os locais da versão do perfil enviada. O comprovativo e a recepção interna mostram essa versão, sem consultar por arrasto o perfil actual. Não são criadas migrações, alteradas permissões ou executadas chamadas de IA.

Validação dirigida: 18 testes PHP/247 asserções nos módulos de perfil e submissões, incluindo conservação das versões, pedidos anteriores, rejeição de duplicados/incompletos e conservação da candidatura após alteração do perfil. Oito testes frontend, TypeScript, PHPStan sem erros, Pint, lint dirigido, compilação e verificação do diff aprovados. O comando global de formatação identificou três ficheiros JSON de histórico anteriores a este incremento; estes não foram alterados para o fazer passar. Conferência visual e PostgreSQL deste incremento ainda pendentes. Alteração apenas local, sem publicação no domínio. Próximo incremento funcional: anexos verificados para candidaturas, com requisitos e versões preservados, sem retirar exigências documentais existentes.

Consulta pública confirmada em produção, 30 de Outubro de 2026

Commit 2134aa084be2d7be0a3bcaba74cc5eae604e6663 integrado em main, enviado e instalado pelo processo existente. Activação de SGC_PUBLIC_NAVIGATION=true no .env partilhado, com backup fresco da configuração e cache Laravel. A primeira tentativa foi revertida: PHP 8.5 CLI sem DOM/mbstring/XML. Activação concluída com PHP 8.4.27; restantes definições da cache conferidas como inalteradas. Sem migrações ou alterações de dados de negócio.

Conferência HTTP anónima no domínio: raiz encaminha para dashboard, 21 ecrãs públicos com HTTP 200 e componentes esperados, utilizador nulo e âmbito de dados vazio; seis percursos privados encaminham para login. O proprietário confirmou que o acesso funciona. Isso confirma o acesso observado, sem equivaler à conferência visual completa de todos os percursos afectados. Prova técnica local em C:/laragon/worktrees/compras-public-delivery/storage/app/private/compras-production-http.json.

Triagem electrónica e aproveitamento na avaliação, 30 de Outubro de 2026

Recepção interna permite «Aceite para análise» ou «Não aceite para análise». Preparador com função e atribuição actuais, fora de manutenção, declara ausência de conflito e regista motivo interno e comunicação pública em campos separados. A decisão é preservada por inserção, com responsável/data/operação; repetição idêntica é idempotente e alteração posterior é recusada enquanto não existir percurso de revisão. Aceitar para análise não inclui a pessoa na base nem selecciona ou contrata.

Na aceitação, a candidatura interna herda nome/resumo/referência/data da submissão original, sem redigitação, sem usar o perfil actual e sem fundir registos por nome. Referência manual já existente exige reconciliação, em vez de associação automática. Vínculo composto por empresa/processo liga submissão, decisão e candidatura interna. A avaliação mantém a independência: created_by identifica quem fez a triagem/importação e as regras anteriores impedem essa pessoa de avaliar ou aprovar a própria intervenção. Matriz e relatório identificam referência electrónica e versão do perfil, sem carregar ou expor respostas adicionais por arrasto. O comprovativo original não muda; o titular recebe apenas estado, data e mensagem pública da decisão.

Dados efectivamente enviados podem ser consultados pelo preparador ou por avaliador com funções/atribuições de revisão e acesso a evidências/entrevistas. Só leitura não concede comandos de triagem ou publicação. A caixa de recepção permite filtrar pela submissão de origem. A tarefa de triagem aparece no painel; avaliação/selecção e fecho da recepção verificam pendências. Pode triar após o prazo candidaturas recebidas dentro dele; não se acrescentam candidaturas quando já existem avaliações no processo. Processos legados que chegaram à avaliação com pendências exigem decisão explícita, sem alterar conclusões anteriores por arrasto.

Migração 000040 instalada apenas em 8005, com backup/restauro fresco e conteúdos anteriores das 103 tabelas conferidos. Nova tabela vazia e dois índices de identidade por empresa/processo; nenhuma candidatura transferida automaticamente, conta/grant alterados ou migração anterior repetida. Provas proofs/candidate-triage-install.json, candidate-triage-pg.json, candidate-triage-http.json e candidate-triage.json. Suíte integral final: 730 testes, 728 aprovados, dois ignorados anteriores, 7 141 asserções. Módulo SQLite: 48 testes/1 153 asserções; PostgreSQL isolado: 53 testes/1 234 asserções; React: 59 testes. PHPStan sem erros; tipos/Pint/lint/build aprovados; 111 acessos de menu e 18 ficheiros de execução SHA-256 conferidos. Sem emails, IA ou publicação no domínio. Conferência visual continua pendente pela indisponibilidade já registada do conector. Anexos verificados, revisão/reabertura de triagem, complementos, inscrições espontâneas e fornecedores electrónicos continuam por desenvolver. A recepção que exige CV mantém essa exigência e não é publicada pelo percurso sem anexos.

Confirmação de email, recuperação e submissão electrónica de dados, 30 de Outubro de 2026

Implementados pedidos de confirmação do email e recuperação de acesso da conta externa. Ligações temporárias e de utilização única, apenas SHA-256 no repositório de tokens; segredo no fragmento do endereço e envio por POST, sem inclusão no query string, auditoria ou input antigo da sessão. Endereço construído com APP_URL configurado, não com o Host recebido. Recuperar password incrementa a versão das sessões e invalida as anteriores, mantendo a sessão interna independente. Confirmar email não verifica identidade nem constitui candidatura/decisão. Reenvio limitado e recuperação com mensagem genérica; erros de entrega invalidam o token e registam evento sem divulgar a ligação. Transportes log/array não emitem ligações secretas. SMTP/entrega real não configurados na avaliação e não foram enviados emails. Nos testes, Mail::fake e endereços fictícios.

Recepção electrónica de dados em Pessoas: preparador atribuído publica explicitamente uma oportunidade aberta, com descrição pública própria; não é divulgado o propósito interno, as notas ou as avaliações. A oportunidade usa o formulário preservado na preparação do processo, não a versão mais recente da empresa. Conta externa confirmada e perfil gravado permitem preencher respostas com dados do perfil (nome/contacto/resumo e província/distrito/localidade), submeter e obter referência/data/comprovativo. Respostas específicas não alteram o perfil. O comprovativo conserva formulário/publicação/perfil/respostas utilizados. Repetir a mesma operação devolve o mesmo comprovativo; outro conteúdo com a mesma operação ou segunda candidatura ao processo é recusado. Publicação retirada, prazo encerrado, perfil/publicação desactualizados e contactos não confirmados são conferidos no servidor.

Área do candidato lista até 20 oportunidades abertas e 20 comprovativos recentes da própria conta. Rota de recepção interna /pessoas/{process}/recebidas, ligada ao processo apenas para quem prepara, mostra candidaturas recebidas sem lhes atribuir aceitação para análise, inclusão em base, avaliação ou contratação. Não há inserção automática em people_applications nem fusão com o cadastro interno por nome. Triagem/aceitação e ligação à avaliação, revisões/complementos e inscrições espontâneas continuam pendentes. Fornecedores mantêm roteiro próprio, sem novos registos electrónicos neste incremento.

Este incremento recebe dados, sem ficheiros. Não publica pelo novo percurso formulários com anexos obrigatórios e não aceita documentos fictícios para contornar a exigência. Recepção de CV/documentos, armazenamento/verificação de conteúdo, quotas e versões de anexos continuam a implementar. A parametrização de campos/documentos já existente é preservada; não retirar requisitos obrigatórios para simular conclusão. Apenas oportunidades adequadas ao percurso sem anexos podem ser publicadas agora.

Migrações 000038 e 000039 apenas na avaliação 8005, com backup/restauro fresco e conteúdos anteriores das 100 tabelas conferidos. Três tabelas novas vazias, sem abrir portal/publicar oportunidade, criar candidato, confirmar conta ou redefinir password automaticamente. Nenhuma migração ou instalação no domínio. Provas proofs/candidate-submissions-install.json, candidate-submissions-pg.json, candidate-submissions-http.json e candidate-submissions.json. Suíte integral aceite: 724 testes, 722 aprovados, dois ignorados anteriores, 7 063 asserções. Após reforço das verificações de função/atribuição na publicação e caixa de recepção, módulo final repetido em SQLite e PostgreSQL: 14 testes/161 asserções em cada. React: 56 testes; tipos/lint/Pint/build aprovados, PHPStan sem erros, 111 acessos de menu e 18 ficheiros de execução SHA-256 conferidos. Template do email renderizado sem entrega. Conferência visual continua pendente. Próximo incremento: anexos verificados e triagem com aproveitamento da submissão na avaliação, preservando versões e independência; confirmar transporte/APP_URL antes de ensaio real de email. Prazos de tokens são parâmetros técnicos iniciais (30 minutos recuperação, 60 confirmação, 60 segundos entre pedidos), não prazos de candidatura ou conservação aprovados.

Área do candidato e perfil externo versionado, 30 de Outubro de 2026

Implementado novo incremento das candidaturas electrónicas: autenticação de candidatos com guard/provider/tabela próprios, distintos das contas da equipa; conta por empresa e email normalizado, password com hash, confirmação do aviso versionado e limitação de tentativas. O email e a identidade ainda não são verificados, facto apresentado na área. Não foram implementados recuperação de password, MFA externo, anexos ou submissão a oportunidades neste incremento.

Administração > Parametrização > Formulários > Configurar área externa do candidato. Aviso, abertura de novos registos, motivo e versões auditados. Por omissão não existe portal configurado; o endereço público responde 404 e não aceita registos. Fechar registos não apaga perfis nem impede a entrada dos titulares existentes. Confirmação de leitura do aviso não é autorização para bolsa/partilha, nem aprovação dos fundamentos e prazos propostos no Word.

Cada candidato consulta e actualiza somente o próprio perfil da empresa: nome, contacto, resumo e disponibilidade estruturada por província/distrito/localidade, distinta da morada. Cada gravação cria versão; versões anteriores e eventos são protegidos contra sobrescrita e eliminação corrente. Não há fusão por nome, importação do cadastro interno, partilha entre empresas ou acesso a avaliações internas. Integração das versões com futuras candidaturas ainda pendente. O perfil inicial pede os três níveis geográficos; cadastro territorial oficial e múltiplas disponibilidades continuam por implementar. Formulários por modalidade mantêm a parametrização própria anteriormente entregue.

Rotas externas /candidaturas/{company}, /entrar, /registar, /perfil e /sair, com CSRF, limitação de tentativas, cache privada e histórico Inertia cifrado/limpo nas mudanças de sessão. Props externas não incluem utilizador, permissões ou finanças da sessão interna, mesmo em browser com ambas as sessões. A sessão do candidato não autentica a equipa; a entrada automática de desenvolvimento continua limitada à avaliação local já existente.

Migração 000037 apenas em 8005: quatro tabelas vazias, sem abrir registos ou criar contas. Backup/restauro fresco e conteúdos das 96 tabelas anteriores conferidos. Vínculos compostos por empresa ligam conta, aviso e versões do perfil. Provas proofs/candidate-portal-install.json, candidate-portal-pg.json, candidate-portal-http.json e candidate-portal.json. Suíte integral: 715 testes, 713 aprovados, dois ignorados anteriores, 6 985 asserções; candidato: cinco testes/81 asserções; PostgreSQL isolado: 47 testes/1 163 asserções; React: 52 testes. Tipos/Pint/lint/build aprovados, PHPStan sem erros, 111 acessos de menu e 18 ficheiros de execução SHA-256 conferidos. Sem alterações no domínio, emails enviados ou chamadas IA. Conferência visual pendente pela indisponibilidade já registada do conector. Próximo incremento: verificação/recuperação de conta e candidaturas com documentos verificados, comprovativo e triagem interna, sem exposição das avaliações.

Candidaturas electrónicas e disponibilidade geográfica, 30 de Outubro de 2026

Proprietário concordou com a abordagem faseada após análise do Word «Gestão de candidatos e candidaturas electronicas». Implementado o primeiro incremento: Administração > Parametrização > Formulários de inscrições e candidaturas. Seis combinações independentes: recrutamento, prestadores individuais e fornecedores, com concurso ou espontâneas. Campos com identificador, designação, tipo e obrigatoriedade; documentos com formatos e limites configurados, sem adoptar automaticamente os valores propostos no Word. Todas as modalidades começam indisponíveis; guardar a intenção de recepção não abre um portal externo.

Versões somente por inserção, com autor/data/motivo, auditoria atómica e recusa de edição desactualizada. Histórico guarda definições completas. Novos processos de Pessoas conservam a definição vigente na preparação, dentro das regras imutáveis já existentes; os controlos SQL anteriores foram mantidos. Processos existentes não foram alterados. A intenção inicial de congelar na abertura foi corrigida durante os testes para respeitar a imutabilidade desde a criação.

Novo requisito do proprietário: disponibilidade geográfica em província, distrito e localidade, distinta da morada. Campo estruturado disponível no editor, previsto como obrigatório nas definições iniciais de pessoas, com obrigatoriedade parametrizável. Validador reutilizável exige os três níveis quando preenchido e rejeita respostas fora do formulário. Ainda não valida códigos ou hierarquias de um cadastro territorial oficial, não permite múltiplas disponibilidades e não aplica exclusão geográfica automática.

Migração 000036 instalada apenas em 8005, com backup/restauro fresco e conteúdos das 95 tabelas anteriores preservados. Nova tabela vazia, sem contas, permissões novas, importações ou alterações ao domínio. Provas em proofs/submission-forms-install.json, submission-forms-pg.json, submission-forms-http.json e submission-forms.json. Validação integral: 710 testes, 708 aprovados, dois ignorados anteriores, 6 904 asserções; módulo SQLite e PostgreSQL isolado: 44 testes/1 088 asserções em cada; React: 49 testes. PHPStan sem erros, tipos/Pint/lint/build aprovados, 111 acessos de menu nos seis perfis e 18 ficheiros de execução SHA-256 conferidos. HTTP do novo ecrã: administração 200, armazém sem competência 403. Conferência visual continua pendente pela limitação do conector já registada.

Próximo incremento: área autenticada do interessado e perfil reutilizável, depois candidaturas com anexos verificados e comprovativo, triagem, complementos e revisões. Separar «Aceite para análise» de «Incluído na base», mantendo notas internas reservadas e roteiros distintos para Pessoas e Compras. OCR, email automático e IA não integram este incremento; o percurso manual deve funcionar sem IA. Fundamentos/avisos e prazos de conservação propostos no Word não foram aprovados por arrasto nem activados.

Reutilização de artigos em Compras, 30 de Outubro de 2026

Catálogo baseado nos artigos existentes do armazém, com publicação explícita e auditada por administrador/armazém. Solicitantes seleccionam apenas artigos publicados da empresa, sem acesso a saldos. Descrição, unidade, categoria e tipo vêm do servidor; quantidade, preço e IVA são dados do pedido. Fonte/versão preservadas por linha e na ordem. Actualizações do cadastro não reescrevem pedidos existentes; selecção de nova versão é explícita. Recepção pré-preenche o artigo da ordem e rejeita outro ID, mantendo qualidade, quantidades e independência. Insumos/outros bens cobertos; equipamentos/peças seguem roteiro técnico, serviços continuam manuais.

Migração 000035 apenas na avaliação 8005, backup/restauro fresco conferido, 94 tabelas anteriores preservadas e catálogo vazio; sem contas/grants, ligação automática de históricos, IA ou instalação no domínio. Suíte integral: 703 totais, 701 aprovados, dois ignorados anteriores, 6 828 asserções. PostgreSQL isolado: 35 testes/252 asserções. React: 47 testes. Tipos/PHPStan/Pint/build aprovados; provas em proofs/requisition-catalogue.json e ficheiros associados. Conferência visual pendente por indisponibilidade já registada do conector; testes automáticos não a substituem.

Próxima lacuna: modelos de documentos versionados por empresa, variáveis preenchidas a partir de fontes autorizadas e termos específicos novos. Conferir associações e relatórios na matriz reutilizacao-dados.md; reconciliação histórica exige identidade/autorização, sem fusão por nome. Não declarar o requisito transversal integralmente concluído.

Registo único e cadastro reutilizável de Pessoas, 30 de Outubro de 2026

Requisito transversal registado em AGENTS.md. Primeira lacuna implementada: cadastro de nome/referência/perfil reutilizável, versão/auditoria, pesquisa e arquivo/reactivação. A recepção permite guardar a primeira pessoa no mesmo acto e seleccionar cadastro em candidaturas seguintes. Dados da pessoa vêm do servidor; resumo específico da candidatura não actualiza o cadastro. Snapshot imutável por candidatura e referência/versão no relatório. Mudanças posteriores não reescrevem avaliações/decisões. Mesma pessoa não duplica candidatura ligada no mesmo processo; nomes iguais não são fundidos.

Preparadores reutilizam os registos próprios; consulta/gestão partilhada têm capacidades explícitas parametrizáveis. Administração não lê cadastros alheios automaticamente. Reutilização não concede acesso a processos, entrevistas, finanças ou minutas. Novos comandos auditam em people_registry.*, fora do histórico people.* por processo. Aplicações e matriz antigas sem vínculo conservam a forma anterior. Sem migração automática de pessoas históricas.

Migração 000034 apenas em 8005, backup/restauro fresco e 93 tabelas anteriores reconciliadas; nova tabela vazia e candidaturas antigas sem ligação. Conta/grants/perfis existentes preservados. Contrato de menu: seis grupos, 111 acessos nos seis perfis legados, com visibilidade específica para permissões de cadastro. Provas em proofs/people-registry.json e instalação/PG associados. Suíte integral 698 totais/696 aprovados/dois ignorados anteriores, 6 739 asserções; módulo/PG 43 testes/1 124 asserções; React 44; tipos/PHPStan/lint/Pint/build. Conferência visual e domínio pendentes.

Matriz de cobertura em reutilizacao-dados.md: reutilização já existente em Compras e lacunas de catálogo genérico, modelos documentais, associações e reconciliação de históricos. Cadastro de Pessoas fecha este incremento, não toda a aplicação. Próxima prioridade: ligar a requisição genérica a uma fonte de artigos e preparar modelos versionados, pedindo só a informação nova de cada evento. Sem IA ou chamadas pagas neste incremento.

Garantia comercial do núcleo sem IA, 30 de Outubro de 2026

Confirmada orientação permanente em AGENTS.md: funcionalidades prometidas do SGC base continuam disponíveis sem adicional de IA, sem reclassificar o núcleo como função paga de IA. Indicadores, alertas e sínteses locais mantidos. Futuras integrações/consumo/cobrança não podem bloquear percursos normais por falta de chave, saldo, subscrição ou fornecedor; resultados incorporados nos processos permanecem preservados após cancelamento. Acesso continua dependente das permissões funcionais habituais.

Conferência dos controlos actuais: o fornecedor permanece em rascunho e as chamadas externas não intervêm no núcleo; ocultar síntese conserva relatório em Compras/Pessoas. Reutilizadas as provas proofs/ai-plan.json e os testes existentes de preservação do relatório em OrganizationConfigurationTest e PeopleHiringTest, sem repetir suítes por esta alteração documental. Sem mudanças de código, dados, preços ou chamadas externas. Não equivale a declarar implementadas as lacunas funcionais anteriormente registadas.

Plano de IA por empresa e pré-visualização autorizada, 30 de Outubro de 2026

Administração > Parametrização permite preparar fornecedor/modelo, percursos, categorias de factos e limites mensais/por pedido. Plano sempre em rascunho, com versão, motivo e auditoria transaccional; preserva as opções das sínteses e é preservado por mudanças dessas opções. Rejeita chaves, endpoints arbitrários, activação e identificadores de modelo com formato de segredo. JSON de política existente, sem migração, dados de negócio ou escolhas automaticamente gravadas na avaliação.

Relatórios de Compras/Pessoas mostram uma pré-visualização recolhida apenas das sínteses factuais já autorizadas/redigidas e filtrada pelo plano. Não acrescenta acesso a entrevistas, candidaturas, finanças ou outras empresas. Sem nomes/referências de pessoas, notas livres, dados bancários ou hashes de fontes no envelope. Percurso excluído, âmbito vazio e excesso de bytes são explícitos; sem truncagem silenciosa. Orçamentos/pedidos são planeados, não reservas ou contabilização efectiva: usage_checked=false e external_execution_enabled=false. Modelo guardado não equivale a compatibilidade validada.

Validação: 90 testes PHP dirigidos/1 469 asserções, 40 React/Inertia, PostgreSQL descartável um cenário/147 asserções, tipos/PHPStan/lint/Pint/build, runtime e percursos HTTP por seis perfis aprovados. Detalhes e próximo contrato de execução em plano-ia.md; provas proofs/ai-plan.json. A chamada fictícia anterior não foi repetida. Continuam por implementar credenciais/consumo/activação por empresa e avaliação ampliada antes de documentos reais. Visual e domínio pendentes. Provas integrais anteriores reutilizadas.

Ensaio real de IA concluído, 30 de Outubro de 2026

Chave fornecida pelo proprietário no .env; foram removidas duplicação da definição e atribuição embutida no valor, preservando as restantes definições e sem imprimir segredos. PHP sem CA configurada falhou com cURL 60; bundle das 53 raízes já confiadas pelo Windows foi aplicado apenas ao processo do ensaio, sem desactivar verificação TLS. Após rejeição 401 do valor inicialmente malformado, a chamada corrigida devolveu HTTP 200. Uma única geração bem-sucedida, sem repetição automática; falhas de transporte/autenticação documentadas separadamente.

Três afirmações e três fontes cobertas, conteúdo conferido contra o cenário: pedido pendente, comparação não pronta, ausência de ordem. Não foram inventadas aprovação, entrega ou pagamento. Reportados 204 tokens de entrada/81 de saída; custo textual teórico US$0,001380 às tarifas documentadas, sem verificar saldo ou débito efectivo dos créditos Pro. Prova proofs/ai-rehearsal-live.json; resultado fictício em ficheiro privado, chave/bundle fora do Git. Sem dados reais enviados, mudanças de processos, migrações ou activação de IA externa no portal. Ensaio autorizado concluído; não o repetir automaticamente. Próxima evolução: configuração/consumo/fornecedor por empresa e avaliação mais ampla antes de documentos reais. Visual e publicação mantêm-se pendentes.

Configuração das sínteses e avaliação local de IA, 30 de Outubro de 2026

Enquanto o proprietário organiza a credencial, Administração > Parametrização recebeu escolhas independentes para mostrar/ocultar as sínteses de Compras/Pessoas, por empresa, com revisão própria, versão optimista, motivo e auditoria transaccional. Valores iniciais conservam as duas disponíveis. Ocultar resumo mantém relatório, avaliações, decisões e permissões. A interface não aceita segredos nem activa processamento externo; a parametrização integral de IA continua por desenvolver.

Migração 000033 instalada apenas em 8005 após backup/restauro fresco conferido: 93 tabelas anteriores reconciliadas, excluindo apenas o novo campo nulo e o registo da própria migração. tenants.intelligence_policy nulo em todas as empresas, sem definir escolhas, alterar contas/atribuições ou aplicar outras migrações. Prova proofs/intelligence-policy-install.json.

SyntheticAiAssessment e sgc:ai-assess conferem resultados fictícios sem rede: pertença das fontes, fontes por citar, cobertura distinta e correspondência literal. Cobertura completa não certifica verdade semântica; revisão humana mantém-se necessária. O resultado da chamada autorizada futura inclui estas métricas. Fixture manual em tests/Fixtures/ai-synthetic-result.json avaliada localmente, explicitamente não uma saída de modelo. Nenhuma nova chamada paga ou documento real processado.

Validação: 82 testes PHP dirigidos/1 337 asserções, 33 React, PostgreSQL descartável um cenário/110 asserções, tipos/PHPStan/lint/build. Inclui rollback se auditoria falhar, versão antiga, rejeição de segredos/activação externa, alternância dos percursos preservando relatórios e acessos. Prova proofs/intelligence-policy.json; provas integrais anteriores reutilizadas. Visual e domínio pendentes. Autorização da única chamada fictícia paga mantém-se válida; aguardar a credencial sem nova confirmação.

Ensaio IA autorizado — execução aguarda credencial, 30 de Outubro de 2026

O proprietário autorizou a única chamada paga preparada depois de conhecer a estimativa de US$0,01–0,02. Foram verificadas apenas a presença e a activação da configuração, sem imprimir valores de segredos: ensaio desactivado, credencial específica ausente e nenhuma OPENAI_API_KEY disponível. Nenhum pedido externo executado. Configurar a chave no servidor e executar uma vez, preferindo activação restrita ao processo do comando, sem activar IA nos fluxos reais. A autorização já cobre essa chamada; não a solicitar novamente. Estado documentado em proofs/ai-rehearsal-authorization.json.

Adaptador de ensaio IA — cenário fictício e chamada real pendente, 30 de Outubro de 2026

Preparado sgc:ai-rehearsal: por defeito apresenta três factos fictícios sem rede/base. --live permite uma única chamada a OpenAI Responses com modelo inicial gpt-5.6-terra, schema estrito, fontes enumeradas, corpo limitado a 4 500 bytes, 1 000 tokens de saída e raciocínio none; sem ferramentas, redireccionamento ou repetição automática. Só usa o cenário incorporado: não aceita processo, ficheiro ou texto livre. Exige activação e credencial de servidor, não configuradas por este incremento. Nenhuma chamada real executada ou custo de API incorrido neste ensaio.

Valida formato e pertença das referências, rejeita resposta incompleta/recusa/JSON inválido, sem declarar verdade factual automaticamente. Resultado exige conferência humana; erros do comando não expõem payloads do fornecedor ou credencial. Não integra rotas, filas ou relatórios com chamadas externas. 15 testes/41 asserções HTTP simulado e PHPStan aprovados; descrição exacta em ensaio-ia.md, prova proofs/ai-rehearsal.json. Falta autorização para a primeira chamada paga e configuração segura da credencial; isto não impede o uso dos fluxos e sínteses locais.

Tentativa de conferência visual dirigida: conector Windows devolveu Computer Use native pipe is unavailable / os error 2; navegador integrado devolveu The browser access host is unavailable, sem superfícies disponíveis. Não houve interacção nem contorno da ferramenta. Visual continua pendente, sem prova de falha da aplicação. Percursos HTTP automáticos mantidos nas provas.

Síntese factual com fontes — base para assistência por IA, 30 de Outubro de 2026

O relatório individual de Compras inclui «Síntese com fontes»: estado do pedido, situação da comparação, versão/actualidade da qualificação, acta de abertura, ordem e recepções. Facturas/pagamentos só entram no âmbito financeiro autorizado. Cada ponto identifica o caminho do dado e liga à secção correspondente do relatório. O resumo usa exclusivamente a projecção autorizada de ProcurementReviewReport, sem consultas adicionais, cache persistente, documento enviado a terceiros ou escrita de negócio.

O método procurement_evidence_brief_v1 é uma síntese por regras, explicitamente identificada na interface, não um modelo de IA. Texto de documentos não é interpretado como instrução; não há selecção de fornecedor, aprovação, inferência de conformidade ou certificação automática. A ausência de documentos descreve esta consulta. Base documental antiga, ordem emitida, recepção registada e pagamento registado mantêm significados distintos. A síntese integra a impressão do relatório com os detalhes originais.

Uma referência SHA-256 por ponto e por síntese permite comparar a base usada: mudanças de evidências alteram-na; a hora da consulta e o nome do leitor não a alteram por si. Dados financeiros reservados não entram no resumo nem no cálculo dessa referência. A referência não é uma assinatura, decisão guardada ou substituto da evidência. Fontes são secções de registos estruturados; ainda não existe leitura semântica de anexos Word/PDF nem geração por fornecedor de IA. Este resultado constitui uma referência factual para avaliar essa integração futura.

Pessoas recebeu síntese própria com critérios, matriz actual ou selecção preservada, proposta pendente/devolvida/aprovada, minuta interna autorizada e acompanhamento dos esclarecimentos. Não classifica pessoas nem interpreta a minuta como assinatura/admissão. Usa projecções já redigidas pelo servidor e partilha apenas o componente visual com Compras. O detalhe de Pessoas passou a leitura transaccional; em PostgreSQL normal utiliza snapshot read-only/repeatable-read para manter consistência entre relatório, permissões e síntese.

Validação dirigida: relatórios de Compras 18 testes PHP/317 asserções e Pessoas 35/972; cenário PostgreSQL descartável de relatórios/sínteses dos dois domínios, isolamento e ausência de escritas de consulta: um teste/64 asserções; React/Inertia: 31 testes, incluindo os ecrãs reais e os destinos de fontes. Tipos, PHPStan, lint e build conferidos nas provas proofs/evidence-brief.json. Sem migrações ou mudanças de acessos. Visual e publicação continuam pendentes; provas integrais anteriores reutilizadas. Continuação: preparar configuração por organização e um ensaio de fornecedor de IA com corpus de teste e avaliação das respostas contra esta base, antes de activar processamento externo de documentos.

Compras — leitura operacional e catálogo de indicadores, 30 de Outubro de 2026

Retoma após a pausa: /relatorios inclui leitura operacional sobre todas as requisições autorizadas nos filtros actuais. Conta pedidos em aprovação, até cinco submissões pendentes mais antigas com ligação ao processo, antiguidade desconhecida quando falta data utilizável, pedidos ainda em preparação/aprovação cuja data de necessidade passou e aprovadas sem propostas registadas ou ordem visível. Mantém separados necessidade, prazo de entrega, proposta registada e proposta comparável. Não atribui automaticamente incumprimento nem decide o processo.

ProcurementOperationalInsights deriva os dados da mesma consulta autorizada e do mesmo snapshot read-only/repeatable-read do relatório; não usa apenas os 25 resultados da página. A lista de antiguidade é limitada a cinco enquanto percorre a consulta por lotes. Fonte e filtros preservados, histórico e contrato CSV anteriores sem alterações. Catálogo comum em indicadores-sgc.md, com definição, base e limite dos indicadores de Compras e Pessoas. Sem novas regras organizacionais, migrações, escritas de negócio, chamadas externas ou modelo ML activo. Próximo incremento de inteligência: ensaio de síntese documental com referências e dados de teste, conforme inteligencia-sgc.md.

Validação: nove testes de relatórios/197 asserções, 28 testes React, tipos, PHPStan, lint, Pint, build e percursos HTTP por seis perfis aprovados. Ensaio PostgreSQL descartável: um cenário/36 asserções sobre o relatório real, filtro, âmbito vazio, datas e ausência de escritas. O primeiro ensaio Pest foi incompatível com a transacção exterior de RefreshDatabase; o cenário independente confirmou o percurso sem essa transacção, mantendo a guarda original do relatório. Base descartável removida e avaliação original preservada. Provas e limites em proofs/procurement-intelligence.json. Publicação no domínio e conferência visual continuam pendentes; provas integrais anteriores reutilizadas, sem alegar nova avaliação de todo o portal.

Inteligência operacional e evolução para IA/ML, 30 de Outubro de 2026

O proprietário orientou que o SGC deve gerar inteligência usando machine learning e inteligência artificial. O roteiro em inteligencia-sgc.md distingue indicadores determinísticos, assistência documental com fontes e futuros modelos de previsão/anomalias. Prevê parametrização pela empresa, permissões aplicadas antes de recuperar documentos, histórico/versionamento, avaliação de qualidade, custos e funcionamento manual quando a IA estiver indisponível. Nenhum fornecedor, chave ou transmissão externa foi activado.

Primeiro incremento implementado em Pessoas: painel «Leitura operacional», calculado exclusivamente sobre a fila autorizada e filtrada, no mesmo snapshot. Mostra ocorrências vencidas e processos afectados separadamente, maior atraso em dias de calendário, cinco ocorrências mais antigas com ligação à origem, distribuição das tarefas pessoais, aprovações e tarefas sem prazo próprio. Ausência de prazo não implica incumprimento; não há notas, classificação de pessoas ou decisão automática. Método identificado como factual, sem alegar que existe ML treinado. Sem novas consultas de dados privados, alterações de schema, contas, permissões ou dados de negócio.

Testes dirigidos cobrem âmbito vazio, filtros/acesso administrativo sem participação, minimização de dados, contagem de várias ocorrências por processo, limite de cinco, ordenação e mudança de dia no fuso configurado. Módulo: 32 testes/856 asserções aprovados; React/Inertia: 26 testes aprovados; tipos, PHPStan, lint, Pint e build aprovados. A prova integral anterior é reutilizada, sem repetir toda a suíte. Provas finais em proofs/people-intelligence.json. A evolução planeada inclui indicadores de Compras, sínteses documentais com referências e só depois ensaios de ML com histórico adequado. Publicação e conferência visual continuam pendentes; o roteiro não equivale à disponibilização dessas funções futuras.

Pessoas — acompanhamento dos esclarecimentos, 30 de Outubro de 2026

Os esclarecimentos registados nas avaliações podem agora receber responsável e prazo, resposta com evidência declarada/observada/verificada, conferência independente, devolução para complemento e conclusão fundamentada. Uma evidência verificada exige referência; uma informação insuficiente continua distinta de um requisito não cumprido. Não há alteração automática de notas, exclusão de candidaturas ou envio de mensagens.

O registo original da avaliação permanece imutável. O acompanhamento tem versão, histórico de respostas/decisões, auditoria, protecção contra repetição e isolamento por empresa/processo. A pessoa responsável pode consultar e responder à questão atribuída sem ganhar acesso a todas as entrevistas. A conferência exige interveniente independente dos autores e responsáveis pela resposta. São permitidas respostas fora do prazo e reatribuição fundamentada, com conservação do histórico.

Atribuição, resposta e conferência surgem em «As minhas tarefas», separadas das aprovações formais; há alertas de prazo e inclusão no relatório imprimível conforme a autorização. Alterar apenas o prazo não invalida a proposta de selecção. Novas respostas, resultados e responsáveis relevantes exigem reconciliação antes de aprovar uma proposta pendente. Uma selecção já aprovada conserva a sua base; o acompanhamento posterior fica separado, inclusive depois da minuta.

Migração 000032 instalada apenas na avaliação local 8005: backup fresco com restauro verificado, 92 tabelas anteriores reconciliadas e nova tabela vazia. Sem criação de contas ou atribuições. Prova: proofs/people-clarifications-install.json. Validação: 652 testes PHP, 650 aprovados e dois ignorados anteriores, 6 142 asserções; módulo em PostgreSQL descartável 30 testes/836 asserções; React/Inertia 25 testes. Tipos, PHPStan, lint, Pint e build aprovados. Prova consolidada: proofs/people-clarifications.json.

Continua a faltar conferência visual dirigida e publicação no domínio; o hotfix de /consulta permanece sem publicação confirmada. Não equivale a implementação integral da proposta Word: métodos qualitativos, correcções de avaliações versionadas, formalização contratual, entregáveis/integração e encerramento continuam para evolução. Não houve alteração dos documentos originais nem comunicações externas.

Pessoas e contratações — painel pessoal e filas separadas, 30 de Outubro de 2026

O ecrã inicial de Pessoas apresenta entidade activa, actualização, contagens autorizadas, As minhas tarefas, Aprovações, alertas de prazo e processos filtráveis. Tarefas operacionais abrangem recepção/fecho, avaliação individual ainda necessária, preparação de selecção e minuta. Aprovações abrangem conferência de abertura e selecção/devolução, apenas para pessoas atribuídas e independentes. A mesma pessoa não recebe uma decisão que a regra de independência lhe impede de executar; o formulário também deixa de sugerir essas operações. As filas não conferem autoridade nova.

Cada item deriva do processo, candidaturas e atribuições existentes, com chave de acção própria e ligação ao processo original; avaliação abre com a candidatura indicada. Não se criaram tabelas, tarefas/aprovações paralelas ou cópias de contratações. Ao concluir ou devolver uma etapa, a fila é recalculada na consulta seguinte. Botão Actualizar mantém a consulta e os filtros; não se promete actualização em tempo real sem nova consulta. Quantidades de acções são distintas da quantidade de processos. A preparação de minuta não é tratada como contrato assinado nem encerramento do processo.

Pesquisa por título/referência PES, percurso, estado e período de criação é aplicada sobre a consulta já limitada por empresa e atribuição activa. Contagens abrangem todo o filtro, mesmo para além da página de 15 processos. Prazos de recepção vencidos aparecem em alertas separados; não foram inventados prazos de entrevistas/decisão ou tarefas de seguimento sem circuito implementado. Administração sem consulta atribuída continua apenas com as referências necessárias à configuração de equipa; os contadores de conteúdo permanecem a zero.

Corrigida também a projecção da listagem: anteriormente paginava o modelo integral; agora devolve apenas referência/id, título, percurso, estado e datas. Regras, condições financeiras, matriz de selecção, entrevistas e contrato não são enviados nessa listagem nem nas filas, mesmo quando a consulta individual exige redacção desses campos. No PostgreSQL, contagens, filas e paginação da consulta normal partilham transacção de leitura repetível/read-only. Não há alterações de schema, contas ou permissões por este incremento.

Verificação: 643 testes totais, 641 aprovados e dois ignorados anteriores, 5 859 asserções. Módulo e PostgreSQL descartável: 21 testes/562 asserções; React/Inertia: 23 testes. Tipos, PHPStan, lint dirigido, Pint e compilação aprovados. Testados percurso completo das filas, conclusão das acções, independência, prazos, revogação/expiração, filtros, contagem além da primeira página e ausência de campos privados nas listagens. Provas proofs/people-workdesk.json e proofs/people-workdesk-pg.json. Mantêm-se pendentes conferência visual dirigida e publicação no domínio; o hotfix React /consulta ainda não tem publicação confirmada.

Separação de Compras e Pessoas e controlo por processo — 30 de Outubro de 2026

Por orientação posterior do proprietário, Compras e Pessoas e contratações ficam separados, cada um com o seu roteiro. Esta decisão substitui a proposta do Word de colocar os serviços individuais dentro de Compras. Retirado o atalho transitório nesse grupo. Pessoas tem entradas próprias para processos/equipas, serviços individuais e recrutamento; ambas as listas filtram o mesmo repositório de pessoas pelo respectivo tipo, sem transferir candidaturas para aquisições. Fornecedores integra a secção própria de Compras, mantendo seis grupos horizontais, dropdowns e apresentação comum. Permissões e destinos são conferidos independentemente do grupo visual. Matriz actual: 110 acessos distribuídos pelos seis perfis de compatibilidade.

Implementado acesso nominativo por processo: consulta, preparação, avaliação, decisão, minuta, gestão de equipa, condições financeiras, entrevistas e consulta da minuta. Perfil da empresa e atribuição do processo são conferidos em conjunto; o papel de administrador, sozinho, não permite ler candidaturas. A administração pode organizar equipas por referência, tipo e estado, sem receber título/âmbito, candidatos, entrevistas ou condições do processo. Ao criar um processo, a pessoa assume explicitamente a sua preparação e gestão através desse acto; isso não dá acesso a processos alheios. A equipa pode ser atribuída imediatamente no próprio percurso, sem criar contas ou outorgar perfis de empresa automaticamente.

Atribuições têm motivo, versão separada da versão de negócio, prazo opcional, revogação e auditoria. Retirar todas as opções revoga a consulta, incluindo depois do prazo, sem obrigar a reactivar um acesso expirado. As listas só contam/processam atribuições activas de consulta; os filtros de serviços/recrutamento e a empresa são reaplicados. Avaliações revogadas deixam de qualificar a decisão pendente; selecções já aprovadas conservam a evidência histórica. Gestão de acessos continua possível após a minuta, sem alterar o registo terminal. Mantidas independência da abertura, avaliação e decisão e proibição de auto-aprovação.

Minimização no servidor: condições financeiras do anexo são retiradas da regra e da cópia da regra na selecção quando não autorizadas; entrevistas/evidências são retiradas das candidaturas e da matriz preservada; minuta não autorizada não é enviada ao cliente. Impressão usa a mesma projecção autorizada. Campos livres continuam a exigir recolha pertinente; isto não constitui classificação automática de dados sensíveis nem implementação completa de retenção.

Formulários próprios adicionados: Anexo A para função/vaga, Anexo C para necessidade de serviço, com campos aplicáveis e requisitos classificados como obrigatórios/desejáveis, verificação, equivalências e adaptações. Campos complementares não são tornados universalmente obrigatórios. Os critérios e o anexo são preservados na criação. Avaliações novas com anexo pedem tipo de evidência relatada/observada/comprovada e permitem esclarecimentos pendentes, formando a base do Anexo B. Processos anteriores sem anexo e evidências antigas mantêm o formato original; nenhuma nota é convertida em prova de ausência de requisito. Método de notas/ponderações ainda permanece e não substitui a futura parametrização de métodos qualitativos.

Migração 000031 apenas na avaliação 8005, após backup/restauro fresco e reconciliação das 90 tabelas anteriores. Acrescenta duas tabelas de atribuições/versionamento; preserva participantes históricos por actos efectivamente registados, sem conceder conteúdo a todos os administradores. Na avaliação não havia processos de pessoas: novas tabelas vazias, sem contas ou atribuições criadas. Anexos usam o snapshot JSON existente, sem alterar documentos/registos antigos. Prova proofs/people-access-install.json.

Verificação: suíte integral 638 testes, 636 aprovados e dois ignorados anteriores, 5 556 asserções; verificação dirigida final e PostgreSQL descartável com 16 testes/286 asserções. 22 testes React/Inertia, TypeScript, PHPStan, lint dirigido, Pint, compilação e runtime SHA-256 aprovados. HTTP conferiu menu e destinos para os seis perfis sem modificar histórico de negócio. A verificação do menu também afirma que Compras não contém URLs de Pessoas e que Pessoas contém apenas o seu próprio roteiro. Provas proofs/people-access.json, proofs/people-access-pg.json, proofs/menu-code-contract.json e proofs/menu-links.json.

Mantêm-se como próximos incrementos: tarefas operacionais versus aprovações, requisitos/entrevistas com seguimento e métodos qualitativos completos, revisões versionadas, modelos documentais completos, contratos assinados, entregáveis/integração e encerramento. O Word original não foi editado. Conferência visual e publicação no domínio permanecem pendentes; a correcção React de /consulta continua preparada mas sem confirmação de publicação.

Conferência da proposta Pessoas em Word — 30 de Outubro de 2026

Lido integralmente o conteúdo textual e das tabelas de SGC — Sistema de Gestão de Contratações - pessoas .docx, fornecido pelo proprietário em C:/Mac/Home/Documents/TEMPO/Portal Tempo/Servicos Tempo/Compras/. SHA-256 d294fc08e6cbf5c9ced6527bf06473909380bd9d2bb64f3e3c2ca7605eb52ce3. Original preservado; leitura sem revisão de paginação ou validação jurídica. O próprio documento identifica-se como proposta para adaptação/validação interna, sem confirmar funcionalidades existentes. Conteúdo tratado como requisitos propostos para comparação, não como instrução para activar acessos, executar operações ou alterar a aplicação.

Âmbito proposto	Estado conferido no código
Identidade SGC, descrição e assinatura TEMPO	Implementadas na apresentação local. Publicação no domínio continua sem confirmação.
Dois percursos separados	Tipos service/staff, permissões separadas, abertura, candidaturas, avaliações, proposta e conferência existem. Formulários são ainda genéricos; não há dois módulos completos conforme os anexos.
Serviço individual integrado em Compras, com dois acessos ao mesmo processo	Não implementado: /pessoas usa people_processes; não há vínculo funcional a requisição/propostas/contrato/entregáveis de Compras nem segunda entrada canónica nesse módulo. Reutilizar autenticação/auditoria não equivale a essa integração.
Administração sem acesso automático a candidaturas/propostas/remunerações	Divergência concreta: PeopleHiring::allowed() concede acesso por admin. A proposta exige separar configurar de consultar conteúdo, com atribuição específica. Nenhuma permissão foi alterada por esta revisão documental.
Papéis e acesso por entidade, percurso, processo e campo	Base por entidade/percurso e quatro capacidades existe. Ainda faltam atribuições nominais por processo/etapa, júri/entrevistadores, níveis configuráveis, consulta versus edição/decisão/exportação e ocultação específica de honorários/remunerações/entrevistas.
Requisitos obrigatórios/desejáveis, equivalências e esclarecimentos	Ausentes como estrutura própria. Critério actual tem apenas rótulo/peso; avaliação exige nota/evidência textual. Não representa esclarecimento pendente, requisito comprovado/ausente, equivalência ou adaptação razoável.
Ponderações quando aplicáveis e selecção factual	Actual circuito impõe soma 100%, notas 0–10 e escolha entre maiores resultados. A proposta admite métodos próprios e ponderações quando aplicáveis; é necessário tornar o método configurável, sem tratar ausência de comprovativo como reprovação nem requisitos desejáveis como eliminatórios.
Anexo A, Guião, Anexo B e Anexo C	Não implementados como formulários/modelos versionados. Faltam campos próprios de vaga e necessidade de serviço, perguntas/exercícios, evidência relatada/observada/comprovada e seguimento dos esclarecimentos. Texto livre actual não equivale aos anexos.
Regras anteriores à abertura e alterações versionadas	Critérios/âmbito actuais preservados, com abertura independente, versão de operação e auditoria. Ainda não há circuito de revisão/substituição de regras/documentos, correcção/reabertura e aprovação dessas alterações.
Tarefas, Aprovações e ecrã inicial	Ausentes como filas atribuídas e contagens separadas. A página actual lista processos autorizados e criação, sem painel de trabalho, pesquisa/filtros por percurso/estado/período, alertas ou selector autorizado de entidade.
Contrato, acompanhamento, relatório final e encerramento	Apenas minuta interna e consulta imprimível. Faltam formalização contratual, entregáveis/marcos/aceitação, integração/formação factual, pendências, relatório final e encerramento. Salários não implementados; classificação individual de desempenho pós-admissão não integra esta proposta.
Contas externas e dados pessoais	Não há criação automática de contas de candidatos/prestadores. Faltam recepção externa configurável, biblioteca/anexos, retenção, acesso por documento/campo, comunicações e exportação própria autorizada. Não afirmar conformidade jurídica com base nesta leitura.

Observação editorial: a introdução afirma que os critérios do dashboard ainda não foram disponibilizados, mas o documento contém uma proposta detalhada de ecrã inicial e critérios de aceitação. Convém distinguir os requisitos operacionais já descritos dos indicadores de negócio/metas ainda por definir.

Ordem técnica sugerida caso a proposta seja adoptada: primeiro separar configuração/acesso ao conteúdo e atribuições por processo; depois formular e versionar os anexos/métodos próprios; ligar o percurso de serviços a Compras com a mesma referência e histórico; criar filas distintas de tarefas/aprovações e painel com contagens autorizadas; completar contratos, acompanhamento, relatório final e encerramento. Não criar dois registos para a mesma contratação nem alargar a procuração de um administrador ao conteúdo por conveniência. A leitura não alterou código, base, políticas, contas ou o documento original; não foram repetidas provas automáticas de implementação por este trabalho ser documental.

Identidade adoptada — 30 de Outubro de 2026

Por decisão expressa do proprietário, o produto passa a SGC — Sistema de Gestão de Contratações, com a descrição Aquisições, serviços e pessoas e assinatura Uma solução TEMPO. A sigla SGC mantém-se; «Compras» permanece como nome funcional do respectivo módulo.

Identidade aplicada à página inicial, título HTML, entrada, cabeçalhos e rodapés de navegação/demonstração, identificação móvel, relatórios, actas e impressão de recomendações. README e orientação permanente alinhados. Os registos anteriores neste documento conservam a designação usada na respectiva data. Alteração de apresentação, sem migrações, renomear domínios/pastas/bases/cookies, mudar permissões ou reescrever dados históricos. Publicação no domínio e conferência visual continuam pendentes.

Verificação dirigida: 35 testes PHP/228 asserções e 21 testes de renderização React/Inertia aprovados, tipos, lint, Pint e compilação (saída 0) aprovados. Entrada HTTP local devolveu «Explorar SGC». Sem a designação anterior nos textos activos de apresentação pesquisados. Registo em proofs/sgc-brand.json.

Pessoas e contratação — primeiro incremento, 30 de Outubro de 2026

Implementados os percursos de prestador individual (service) e trabalhador para o quadro (staff) em Administração > Pessoas e contratação (/pessoas). Reutiliza autenticação, perfis/permissões configuráveis da empresa, revalidação do operador, bloqueio transaccional por empresa, versão optimista, auditoria e histórico. Não converte pessoas em fornecedores nem herda automaticamente critérios ou preços das compras.

O preparador define título, âmbito/perfil, prazo, critérios e pesos com soma 100%, e mínimo de avaliadores independentes. Abertura exige outra pessoa e declaração de ausência de conflito. Recepção interna regista nome, referência documental, resumo profissional e data; duplicados e recepção fora de prazo são recusados. Após o fecho, cada avaliador regista notas de 0 a 10 e evidências para todos os critérios. Preparador e registador da candidatura não a avaliam. Pontuação ponderada arredondada a centésimos, seguida da média das pontuações elegíveis. Direitos revogados/expirados antes da decisão deixam de qualificar a avaliação.

Todas as candidaturas precisam do mínimo de avaliações elegíveis antes da proposta de selecção. Não há vencedor automático em empate; escolha fundamentada entre os maiores resultados. A conferência permite aprovar ou devolver, por pessoa distinta do preparador, proponente, registadores e avaliadores. A base é novamente conferida antes de aprovar; devoluções conservam-se na auditoria. Após selecção aprovada, o preparador regista referência, início proposto e condições de uma minuta interna, explicitamente sem prova de assinatura, admissão efectiva ou contratação concluída. Consulta imprimível inclui âmbito, critérios, candidaturas, avaliações/evidências, fundamentação, minuta e histórico; a matriz aprovada mantém a base preservada.

Quatro capacidades separadas (people_service_prepare, people_service_review, people_staff_prepare, people_staff_review) podem ser atribuídas aos perfis definidos pela empresa. Administração existente conserva acesso; Finanças, Compras e restantes perfis não recebem acesso automático a candidaturas. Perfil apenas de serviços não vê recrutamento do quadro. Listas e comandos respeitam a empresa e o percurso; respostas sem cache e histórico Inertia cifrado. Não foram criadas contas/candidatos/perfis nem activadas atribuições automaticamente na avaliação. São necessárias pessoas distintas com permissões adequadas para completar preparação, avaliação e decisão.

Migração 000030 instalada apenas na avaliação 8005: três tabelas vazias (people_processes, people_applications, people_reviews), com protecção SQL de critérios/âmbito, evidências e minuta preservados. Backup fresco com restauro conferido; 87 tabelas anteriores reconciliadas sem alteração, sem mudar contas/grants ou repetir outras migrações. Prova proofs/people-hiring-install.json. Menu continua com seis grupos; 108 acessos por perfil na matriz, incluindo o novo acesso de Administração. Testes também conferem visibilidade por cada nova capacidade.

Validação: suíte integral de 633 testes, 631 aprovados e dois ignorados anteriores (5 438 asserções); módulo dirigido após ajuste de devolução com 11 testes/133 asserções, também aprovado em PostgreSQL descartável, base removida. Ao devolver, a candidatura deixa de estar marcada como seleccionada, mantendo a proposta anterior no histórico. 21 testes de renderização React/Inertia aprovados, incluindo os dois percursos e o hotfix de demonstração; TypeScript, PHPStan, lint dirigido, Pint, compilação e 18 ficheiros de execução por SHA-256 aprovados. HTTP conferiu os seis perfis e o novo acesso de Administração sem comandos de negócio. Prova consolidada proofs/people-hiring.json.

Limites deste incremento: recepção pela equipa, sem portal público de candidatos, upload de CV/anexos, comunicações automáticas ou importação de pessoas reais. Ainda faltam atribuição nominal de júri/entrevistadores por processo, versões de correcção/reabertura, arquivo/retenção de dados, modelos contratuais completos, conferência jurídica/assinatura e integração com admissão, compras/pagamentos ou salários. A minuta não autoriza execução financeira. Não declarar RH completo nem contratação legalmente concluída. Conferência visual dirigida e instalação no domínio permanecem pendentes; o hotfix React de /consulta continua separado e ainda sem publicação confirmada.

Correcção do erro React 31 em /consulta — 30 de Outubro de 2026

Endereço comunicado: https://compras.tempo.co.mz/consulta. Causa reproduzida com o adaptador Inertia React instalado: o layout global de preview/* devolvia uma função que tratava o argumento como ReactNode, mas recebia as propriedades completas da página, incluindo initialScreen e children. O React tentava apresentar esse objecto e lançava o erro 31. Substituído por PreviewLayout, componente estável que extrai e apresenta apenas children, mantendo SgcShell demo, visual e navegação.

Validação: teste de reprodução do padrão anterior, teste do componente corrigido e renderização das 16 páginas de demonstração através do Inertia real — 18 testes aprovados. TypeScript, lint dirigido e compilação aprovados (saída 0). Patch restrito aos dois ficheiros da correcção em storage/logs/preview-layout-hotfix.patch; os incrementos de parametrização em curso não fazem parte desse patch. Não exige migrações nem alterações de dados/autenticação. A compilação local completa contém também os incrementos em curso e não deve ser copiada isoladamente para um servidor com código anterior. Falta aplicar a correcção na revisão instalada, recompilar/publicar pelo processo existente e conferir o URL em produção. Sem confirmação de publicação ou aceitação visual.

Regras de comparação por empresa e por processo — 30 de Outubro de 2026

Administração > Parametrização permite definir o mínimo de propostas elegíveis de fornecedores distintos, o mínimo de avaliadores independentes por proposta e as ponderações de preço, qualidade, prazo, histórico e pagamento. Mínimos inteiros entre 1 e 100; ponderações inteiras de 0 a 100, com soma exactamente 100%. Alteração exige competência administrativa efectiva, motivo, versão actual e auditoria transaccional. Não modifica perfis ou atribuições de acesso.

Cada requisição criada pelo circuito passa a guardar a regra vigente da empresa no acto da criação, incluindo revisão, mínimos e ponderações. A edição de um rascunho não substitui essa regra; alterações administrativas aplicam-se apenas a requisições criadas depois de guardar. Uma revisão autorizada que gera uma nova requisição recebe a regra então vigente, mantendo o vínculo e o histórico da anterior. Processos existentes sem snapshot mantêm a compatibilidade anterior de três propostas/dois avaliadores; não herdam alterações da empresa. A configuração não foi activada automaticamente para a empresa de avaliação.

Cotações novas usam as ponderações do processo; a comparação confere a sua coerência, aplica os mínimos guardados e mantém exclusão de solicitantes/conflitos, isolamento da empresa, admissões aplicáveis e selecção fundamentada entre os candidatos de maior pontuação. A base de preço continua a ser o subtotal líquido sem IVA. Critérios qualitativos, funções elegíveis dos avaliadores e circuito de aprovações conservam o âmbito anterior; não se declara parametrização integral do produto. Snapshots malformados falham a validação em vez de presumir outra regra.

Regras visíveis na requisição, comparação, adjudicação e relatório de conferência; a ordem nova preserva a regra na emissão e mostra-a na consulta/impressão. Para processos com snapshot, a regra integra a impressão digital da comparação; alteração da base invalida a emissão com aprovação anterior. Processos antigos sem snapshot conservam a impressão digital anterior.

Migração 000029 aplicada exclusivamente à avaliação 8005, após backup fresco/restauro e reconciliação dos campos anteriores das 87 tabelas. Acrescenta duas colunas JSON nulas (tenants.comparison_policy, requisitions.comparison_policy), sem importar políticas ou alterar contas/dados anteriores. Conferida também a mesma impressão digital da comparação do processo existente antes/depois. Prova proofs/comparison-policy-install.json.

Validação: 622 testes totais, 620 aprovados e dois ignorados anteriores, 5 306 asserções; PostgreSQL descartável 45 testes/367 asserções, base removida. PHPStan sem erros, TypeScript, lint dirigido, Pint e compilação aprovados. Provas consolidadas em proofs/comparison-policy.json e proofs/comparison-policy-pg.json. Menu permanece com seis grupos e 107 acessos por perfil. Não instalado no domínio; conferência visual dirigida ainda pendente.

Comparação económica e agrupamento do menu — 30 de Outubro de 2026

Implementados os ajustes da folha principal como lógica da aplicação, sem importar valores de exemplo nem alterar o Excel do proprietário. Não se usaram os erros da folha oculta como prova de falha da folha principal.

• Administração > Parametrização: taxa inicial de IVA configurável por empresa, com motivo, versão e auditoria. Valor inicial de 16%, conforme taxa normal indicada pela Autoridade Tributária; o enquadramento pode exigir taxa diferente, mantida ajustável por artigo. A mudança afecta apenas novas linhas; nenhuma taxa de requisição/proposta anterior é recalculada. Cotações conservam o IVA da respectiva requisição.
• Cotações: desconto explícito por unidade, em percentagem ou MZN, antes do IVA. Preço líquido arredondado ao centavo por metade para cima, depois multiplicado pela quantidade; IVA calculado por linha sobre o subtotal líquido. O preço de origem, tipo/valor de desconto e preço líquido ficam preservados e conferidos no servidor. Não presume desconto global nem desconto posterior ao IVA.
• Propostas incompletas/preços vazios/zero e descontos que eliminem o preço líquido são recusados. Descontos incoerentes com os preços guardados excluem a proposta da comparação. Os motivos aparecem no detalhe. A lógica existente já identificava todos os empatados no topo: acrescentado aviso explícito, sem selecção automática. Mantida a adjudicação fundamentada entre candidatos de maior pontuação.
• Dados de desconto integram a base de abertura, a impressão digital da comparação, a matriz da adjudicação/ordem e os relatórios de conferência/impressão. A ordem usa o preço unitário líquido, mantendo compatibilidade dos cálculos de quantidades, recepção e valores. Propostas antigas sem desconto mantêm a base anterior; metadados nulos não alteram os hashes anteriores. Avaliações mostram a data de registo persistida, sem data volátil equivalente a TODAY().
• Menu horizontal reorganizado de oito para seis grupos: Compras; Fornecedores; Armazém e activos; Finanças; Administração; Relatórios. Compras reúne Requisições, Aprovações e Consultas/adjudicações em secções internas, também na navegação móvel. Mantidos visual dos dropdowns, pesquisa incluindo secções, destinos, filtros, permissões, destaque da página e os 107 acessos por perfil anteriormente conferidos.

Instalação exclusivamente na avaliação 8005: migração 000028, duas colunas (tenants.default_tax_rate, quotations.commercial_terms), backup fresco com restauro conferido e campos anteriores das 87 tabelas reconciliados. Nenhuma conta, autorização, taxa de processo existente ou outra migração alterada. Provas em proofs/economic-install.json, proofs/economic-pg.json e matrizes de menu existentes. Não instalado no domínio.

Verificação final: suíte integral com 618 testes, 616 aprovados e dois ignorados anteriores, 5 245 asserções; 42 testes PostgreSQL descartável/327 asserções; 71 testes do percurso de adjudicação/ordem aprovados, incluindo desconto na matriz e impressão. PHPStan sem erros, tipos TypeScript, lint dirigido, Pint, compilação (código de saída 0) e 18 ficheiros de execução por SHA-256 aprovados. HTTP do menu conferiu seis perfis, taxa na parametrização/formulário, empates/motivos na comparação e histórico funcional inalterado. Registo consolidado em proofs/economic-comparison.json.

Limites mantidos explícitos: não foi recebido o relatório final do júri; não há importação automática do Excel nem adjudicação por simples menor preço. Ponderações provisórias e mínimo actual de três propostas/dois avaliadores continuam como antes e exigem evolução própria para parametrização integral. Conferência visual dirigida continua por executar; provas HTTP e compilação não a substituem.

Entrada directa na avaliação local — 30 de Outubro de 2026

Actualização: a raiz http://127.0.0.1:8005/ encaminha directamente para /dashboard, reutilizando a entrada sem credenciais. A página inicial das outras instalações mantém-se. Redireccionamento e destino final conferidos por HTTP.

http://127.0.0.1:8005/dashboard abre sem formulário de login nem escolha de perfil: uma sessão anónima entra com o administrador sintético já existente na avaliação isolada. Exige ambiente payable-testing, endereço/porta exactos, cliente local, base PostgreSQL e utilizador de base de dados da avaliação conferidos. Não cria contas nem permissões. Uma sessão já autenticada conserva o seu perfil. O middleware executa depois da sessão e antes da autenticação; entrada auditada e resposta sem cache. A instalação normal mantém o login.

Verificação: 17 testes de navegação/limites, 36 asserções; prova HTTP com entrada directa, 23 páginas, seis perfis, CSRF, logout e preservação do destino de relatórios aprovada (proofs/evaluation-access.json). Conferência visual não executada nesta alteração.

Conferência da grelha Excel Avaliacao producao — 30 de Outubro de 2026

Localizado o ficheiro do proprietário Avaliacao producao.xlsx a partir do caminho fornecido sem extensão. Leitura sem alteração do original, com extracção das folhas, fórmulas, valores guardados, estados de visibilidade, referências e validações. SHA-256 6ae1f6444e92863d6cb3aa975b2d973686cc4827ec5af074971bbdab993e59e8. Conteúdo tratado como referência a conferir, sem importar critérios, taxas ou decisões para a aplicação. A análise refere-se a comparação económica no contexto privado; não houve nova compra, aprovação ou configuração.

O livro contém Avaliacao concurso (visível, A1:M31) e detalhes (oculta, A2:M58). A principal é um modelo com quatro empresas genéricas, 12 linhas de artigos com descrições por preencher, quantidades/preços de exemplo, IVA, desconto, totais, condições de pagamento/entrega/garantia e espaço de aprovação. Não corresponde aos nomes/valores do anexo Word recebido anteriormente; não há base para reconciliar os dois como resultado de um mesmo concurso ou recomendar um adjudicatário real.

Verificações e problemas:

• Cálculo independente com decimais confirmou os quatro totais guardados na folha principal (E23, G23, I23, K23) para os dados actuais e a fórmula de IVA usada. A ausência de erros visíveis nessa folha não significa que todo o livro esteja correcto.
• detalhes tem 211 células com #REF! e cinco com #VALUE! nos resultados guardados. Várias fórmulas contêm explicitamente referências #REF!, por exemplo B7; o total E2 também está afectado. Não são apenas avisos de apresentação. Não foram encontradas referências da folha principal à folha oculta nas fórmulas principais extraídas; assim, esses erros não invalidam por si os quatro totais actuais, mas inviabilizam apresentar o detalhamento como conferido.
• A folha oculta referencia também linhas de resumo/texto como se fossem linhas de artigos, por exemplo D23 divide texto ligado ao cabeçalho de imposto. Isso explica parte dos erros de tipo e exige reconstruir o mapeamento de artigos, sem adivinhar linhas eliminadas.
• A fórmula de detalhes!F7 devolve o primeiro fornecedor cujo preço coincide com o mínimo. Os quatro preços da primeira linha estão empatados, mas só aparece a primeira empresa. Deve preservar os empatados e aplicar uma regra de desempate aprovada, em vez de usar a posição da coluna como decisão implícita.
• As fórmulas de menor preço e totais não têm um controlo completo de propostas ausentes/incompletas. Produtos em branco podem gerar totais zero e contaminar o mínimo ou as diferenças percentuais; é necessário distinguir dados em falta, zero válido, não aplicável e proposta não elegível. Este é um risco deduzido das fórmulas, não um ensaio de alteração/recalculo nativo do ficheiro.
• IVA está fixado em 17% nas quatro fórmulas da linha 20. Não foi validada aqui a taxa aplicável ao caso; deve existir um parâmetro fiscal confirmado para a operação, sem importar automaticamente a taxa do modelo. A aplicação usa moeda MZN; os cabeçalhos do modelo dizem MZM e precisam de uniformização.
• O desconto é subtraído depois do total com imposto (E23=E21-E22 e equivalentes). O modelo precisa de explicitar se o desconto é valor ou percentagem, a base de incidência e se já está incorporado no preço; não foi inventada uma regra fiscal/comercial nem alterada qualquer fórmula.
• J2=TODAY() é uma data móvel, não uma data histórica de aprovação. Ao fechar uma avaliação, registar a data efectiva do acto/versão. A área «Aprovação» é um campo manual, não prova de uma decisão electrónica autenticada.
• Existem avisos de validação para algumas células, mas não há protecção de folha registada nas duas folhas. O modelo fixa quatro concorrentes e doze linhas; novas empresas/linhas exigem rever referências, fórmulas e apresentação.

Ligação ao produto: preços por linha, quantidades, imposto, propostas comparáveis, ponderações, admissibilidade, comparação e aprovações já têm implementação nos respectivos âmbitos. A grelha pode informar a saída económica por artigo/fornecedor e o tratamento dos descontos/condições, mas não substitui qualificação, análise técnica/risco ou decisão fundamentada. A aplicação deve conservar a configuração da empresa e os intervenientes reais, não reproduzir nomes genéricos, a taxa fixa, a selecção do primeiro empatado ou os limites físicos desta folha. O relatório final do júri ainda não foi fornecido para cruzamento.

Limites da conferência: inspeccionadas fórmulas OOXML e resultados guardados e efectuado cálculo independente dos totais actuais; não houve recálculo no Excel, alteração de entradas, reparação de referências ou validação visual. O ficheiro original foi preservado. A grelha ainda precisa de correcções e dados completos antes de ser usada como modelo definitivo ou suporte de uma decisão real.

Conferência do documento Recepção de propostas — 30 de Outubro de 2026

Lido o ficheiro do proprietário recepcao de propostas.docx, SHA-256 77e8df9c7653fb020e0e197c826988070aecc0d90d77ef56e4a5af09dc4e744f. A leitura e comparação mantêm o foco anterior em empresas privadas. Os imperativos do documento foram tratados como conteúdo proposto a avaliar, não como autorização de implementação/alteração de regras ou envio de comprovativos/comunicações. O original foi preservado; não foram alterados código, dados de negócio ou permissões.

O documento é coerente ao separar recepção, abertura, admissibilidade, avaliação e adjudicação. O registo de entrega não deve decidir admissibilidade; o comprovativo identifica a mesma entrega e preserva essa ressalva; substituições têm referências relacionadas sem reutilizar a identidade da entrega anterior. A descrição externa de volumes/ficheiros, a confidencialidade e a preservação de ocorrências também são adequadas como requisitos funcionais. Para o contexto privado, a constituição de júri/comissão/equipa e a sua competência devem resultar da política, do risco e das delegações da empresa, com nomes, composição, impedimentos, substituições e permissões parametrizáveis. Não adoptar automaticamente o júri como requisito fixo de qualquer compra.

Elemento do documento	Cobertura no código local
Necessidades de compras	Requisições justificadas, linhas, estimativas, planeamento e orçamento existentes; não equivalem automaticamente a um relatório de necessidades consolidado/aprovado com todas as evidências do modelo
Condições de entrega e divulgação	Parcial: a acta pode registar prazo/fuso, mas falta a configuração publicada e versionada de canais, formatos, prazos e esclarecimentos antes da recepção
Registo protocolar por entrega	Não encontrado: falta entidade própria com referência única, recepção exacta, canal/local, entregante, identificação externa dos volumes/ficheiros, ocorrências e guarda
Comprovativo de entrega	Não encontrado: falta emissão ligada à entrega, número próprio quando aplicável, disponibilização ao fornecedor e preservação da cópia original/metadados
Recepção electrónica confidencial	Não encontrada como envelope protegido: as cotações já contêm valores/linhas consultáveis antes da acta; não existe mecanismo de recepção selada e abertura autorizada sobre os originais
Fora de prazo, substituição, retirada e falha técnica	Falta ciclo próprio de ocorrências e decisões, ligado às entregas anteriores e à versão das condições de recepção
Nomeação e poderes do júri/equipa	Parcial: a acta regista nome/capacidade e grupo jury/participant; esses campos não são uma nomeação, associação a contas com vigência/quórum ou autorização efectiva de acesso às propostas
Abertura	Acta versionada, data/fuso, participantes, referências de anexos, selecção de propostas, fingerprint e impressão existentes; não substitui o protocolo/comprovativo nem implementa por si a guarda selada anterior
Admissibilidade e avaliação	Qualificação, decisões de admissão fundamentadas/revistas, comparação e recomendação existentes nos seus âmbitos; faltam as ligações à entrega protocolada e às ocorrências, e a prova de divulgação prévia/comum de critérios/esclarecimentos
Classificação e adjudicação	Comparação/classificação, recomendação, aprovações e ordem existentes; comunicação aos concorrentes e tratamento completo de reclamações do procedimento não encontrados. Contraditório da avaliação de desempenho é outro âmbito
Arquivo	Histórico, referências e versões preservadas em vários módulos; não foi encontrado ciclo próprio de custódia, auditoria de todos os acessos ao conteúdo de propostas, retenção, bloqueio de eliminação e eliminação autorizada dos respectivos originais

Ponto técnico crítico: QuotationController::show disponibiliza a comparação/conteúdo a utilizadores autorizados pelo âmbito/função, sem condição de abertura prévia. ProposalOpeningWorkflow::proposals também obtém os preços/linhas para preparar a acta. O basis_hash detecta mudanças na representação dos dados, mas não é um selo de ficheiros recebidos nem uma barreira de confidencialidade antes da abertura. Assim, não se deve apresentar o mecanismo actual como cumprimento do requisito de propostas seladas. O módulo de recepções de bens/serviços (GoodsReceipt) não é recepção de propostas.

Antes de implementação, detalhar: (1) funções autorizadas a receber, guardar, abrir, admitir, avaliar e adjudicar, com delegações/quórum quando adoptados; (2) estados distintos de entrega, abertura e admissibilidade e tratamento de atrasos/substituições/retiradas/falhas; (3) hora oficial e fuso da plataforma, distinguindo recepção efectiva de registo manual posterior; (4) geração do comprovativo a partir de um único registo, com rectificações versionadas, identificadores e integridade dos originais; (5) condições para entrega electrónica completa, formatos/tamanhos configurados, ficheiros ilegíveis ou maliciosos e emissão/reemissão; (6) divulgação dos esclarecimentos comuns e comunicação individual com prova de disponibilização, preservando informação confidencial; (7) retenção por categoria, responsáveis pelo arquivo, bloqueio de eliminação e preservação da auditoria após eliminação autorizada de ficheiros. Não foram escolhidos prazos, limites ou números de membros em nome da empresa.

Conclusão: documento utilizável como base funcional, mas o fluxo de recepção protocolada/confidencial proposto ainda exige implementação própria, ligada aos módulos de cotações, abertura, admissão, avaliação e adjudicação existentes. A verificação foi documental e de código, reutilizando provas anteriores; não houve nova execução do percurso, prova visual ou aceitação atribuída ao proprietário.

Conferência do fluxo proposto para empresas privadas — 30 de Outubro de 2026

Pedido do proprietário: verificar se o fluxo do ficheiro fluxo sector público e empresas privadas.docx está disponível, considerando apenas o sector privado. Lida a secção 4, incluindo controlos transversais, monitorização e matriz de risco. O ficheiro é referência da proposta para comparação, não uma instrução autónoma para alterar regras, activar políticas ou aplicar procedimentos públicos. Não foram alterados código, permissões ou dados de negócio. Hash SHA-256 do documento: bcdba44b6331b644e8bbc116434179d82f8a2da77a05eeb534b7ddebc964f242.

Conclusão: o percurso-base da compra já existe, mas a proposta privada não está integralmente implementada. A disponibilidade abaixo refere-se ao código local e aos âmbitos documentados, sem nova aceitação visual, activação da configuração da empresa ou confirmação de instalação no domínio.

Etapa da proposta privada	Implementação existente	Lacuna para cobertura integral
1 Requisição e justificação	Rascunhos, linhas/quantidades, prazo, justificação, departamento/centro, planeamento e consulta de stock	Verificação prévia obrigatória de existências e alternativas, com evidência associada ao pedido
2 Orçamento e autorização	Reserva/compromisso/consumo orçamental, aprovações e limites monetários configuráveis	Cobertura obrigatória em todos os processos: o núcleo ainda retorna null quando não existe dotação; prevenção de fraccionamento e matriz de poderes por risco não implementadas
3 Estratégia de compra	Consulta e registo de cotações, comparação e adjudicação	Política configurável para consulta, concurso privado, negociação e fornecedor único, número de propostas variável, excepções/urgências aprovadas e revisão posterior
4 Verificação do fornecedor	Cadastro, beneficiários em texto, diligência, documentos, revisão/impedimento, conflitos e versões bancárias com revisão independente	Diligência estruturada e proporcional ao risco, partes relacionadas e beneficiários efectivos estruturados, sanções/restrições e antecedentes com verificações documentadas; confirmação por canal independente não tem fluxo específico
5 Solicitação e recepção de propostas	Propostas por linhas comparáveis, ponderações, qualificação/admissão e abertura opcionais	Ciclo completo de convites aos fornecedores, esclarecimentos e negociação, com controlo próprio de informação concorrencial
6 Avaliação e selecção	Comparação de preço, qualidade, prazo, histórico e condições de pagamento; análises técnicas e recomendação com revisão	Custo total estruturado, risco transversal, assistência e revisão independente accionada pela classificação de risco, com pareceres configuráveis
7 Aprovação e formalização	Aprovação da adjudicação e emissão de ordem de compra, preservando regras e evidências	Gestão de contratos/acordos, clausulado, subcontratação, versões/alterações e excepções de execução antecipada aprovadas
8 Execução e recepção	Recepções parciais, quantidade/qualidade, reservas/rejeições, aceitação de serviços e stock quando físico	Gestão da execução contratual, marcos de serviços, alterações contratuais e respectivos aprovadores
9 Validação e pagamento	Conferência ordem–recepção aceite–factura; quantidades/preços/imposto, duplicados, conferência independente e registo de pagamentos externos	Adiantamentos e marcos contratuais, excepções/tolerâncias aprovadas e conclusão do percurso comercial comum de pagamentos, actualmente restrito ao ensaio
10 Encerramento e monitorização	Histórico/auditoria, relatórios, avaliações qualitativas, medidas de melhoria e contraditório do fornecedor	Encerramento formal do processo/contrato e indicadores consolidados de concentração, excepções, compras sem ordem, alterações contratuais e diligências pendentes

Divergências concretas: ProposalComparison::inspect exige pelo menos três propostas elegíveis de fornecedores distintos e duas avaliações elegíveis por proposta; PurchaseWorkflow::currentBasis bloqueia excepções sem política. Esses números permanecem fixos e não correspondem à quantidade definida por cada empresa/valor/risco na proposta. RequisitionWorkflow::submit determina as etapas por limites monetários e equipamento; ainda não resolve uma matriz geral de risco inicial/residual. BudgetControl::record permite continuar sem dotação configurada, retornando null. A existência do módulo orçamental, portanto, não prova cobertura obrigatória universal. SettlementHttp::guard restringe o percurso comum de pagamentos ao ambiente/base de ensaio; ordens/recepções e pagamentos externos conservam marcadores de desenvolvimento nas snapshots. A remoção de tais marcadores não substitui a conclusão funcional da entrega comercial.

Matriz de risco da proposta: não foi encontrado um processo estruturado com níveis baixo/moderado/elevado/crítico, factores e regra de prevalência do nível mais elevado, risco residual, mitigação e redução validadas independentemente, associação de pareceres Jurídico/Conformidade/comissões, suspensão/retoma e reavaliação após mudanças relevantes. Existem conflitos com bloqueios, criticidade/revisão técnica de equipamentos, controlos de investimento e revisões de fornecedor/banco, mas esses mecanismos não equivalem à matriz transversal proposta.

Controlos de integridade adicionais: declaração e afastamento por conflito, segregação e auditoria estão implementados em vários percursos; registos de ofertas/hospitalidade, canal confidencial de denúncia com tratamento próprio, gestão estruturada de partes relacionadas e revisão de excepções não foram encontrados. O contraditório do fornecedor não é um canal de denúncia. Os perfis próprios e limites da empresa já existem, mas as permissões ainda são agregadas por funções e o editor universal de etapas/condições permanece pendente.

Para alinhar o produto com a proposta, os blocos centrais são política de compra/concorrência/excepções parametrizável, matriz de risco com intervenientes e escalonamento, contratos/marcos/alterações e fecho do percurso comercial de pagamento/encerramento. Esta conferência não transforma as recomendações do documento em política aprovada e não incorpora regras da contratação pública. Foram reutilizadas as provas anteriores; não se repetiu a suíte nem se executaram compras/pagamentos para uma comparação de âmbito.

Administração, dois administradores e perfis da empresa — 30 de Outubro de 2026

Orientação do proprietário: Administração deve incluir parametrização; dois administradores serão definidos na configuração/entrega e poderão criar utilizadores e outorgar perfis/permissões escolhidos pela empresa. Substituir regras/perfis de desenvolvimento, conservando manutenção TEMPO. Implementado menu Administração → Parametrização da aplicação, /administracao/parametrizacao, com perfis de nomes próprios, combinação de permissões funcionais, múltiplos perfis por utilizador, criação de contas nominativas e atribuição/revogação justificada. Configuração versionada, isolada por empresa e auditada; alterações concorrentes antigas recusadas. Uma alteração não pode reduzir o conjunto a menos de dois administradores permanentes, incluindo por edição de perfil ou expiração de uma atribuição.

Novas empresas: a conta que configura a empresa e uma segunda pessoa identificada formam os dois administradores iniciais, com contas distintas e palavras-passe normais. Limites de aprovação e aplicação sobre valor com/sem imposto são expressamente preenchidos pela empresa, em valores decimais MZN convertidos exactamente para centavos; não entram como regras provisórias. O seeder normal deixa de criar Test User/test@example.com ou outra conta de exemplo. Os dois administradores iniciais recebem um perfil configurável da empresa. O campo antigo de perfil fica com marcador configured, sem autoridade própria; a validação usa as atribuições efectivas. O marcador não é um perfil concedível nem uma permissão funcional. Contas preparadas antes da activação não recebem poderes implícitos de desenvolvimento.

Empresas existentes: configuração em preparação conserva o funcionamento anterior até activação explícita, após definir as regras e associar pelo menos dois administradores. A página explica o efeito sobre utilizadores sem atribuições. Após activação, os perfis antigos deixam de autorizar; nomes/permissões dos perfis da empresa e respectivas vigências são a fonte efectiva. Não há comando de retorno silencioso ao modo anterior. Não foram apagadas contas, decisões, documentos ou referências históricas. Os processos já submetidos conservam as regras monetárias registadas; novos limites aplicam-se a novas submissões.

Integração transversal: verificações de perfil em controladores, políticas e serviços passam pela resolução comum OrganizationAccess/User::hasFunctions, incluindo revalidação transaccional de operadores, elegibilidade de aprovação, leitura por departamento, preparação/conferência, stock, equipamentos, bancos, facturas, pagamentos e relatórios. Menus e botões usam as permissões efectivas, incluindo múltiplos perfis; preparar requisições exige a respectiva função no modo configurado. Novas snapshots de qualificação/admissão/recomendação registam a designação do perfil da empresa; snapshots anteriores permanecem intactas. As permissões específicas/identidade de pessoa do núcleo financeiro comum continuam a ser conferidas pelo núcleo, com a autorização configurada como requisito adicional; não foram inventadas identidades financeiras ou concessões desse núcleo.

Manutenção TEMPO: implementada como atribuição a conta nominativa existente da empresa, autenticação normal, perfis sem administração, expiração obrigatória, revogação e auditoria das consultas. O modo temporário é somente diagnóstico/consulta; comandos de negócio e administração de acessos são recusados. Não existe rota secreta, conta global, palavra-passe universal ou autenticação contornada. O prazo termina no servidor; editar um perfil de manutenção para o transformar em administrador também é recusado. Esta é a concretização técnica do objectivo de manutenção referido como «backdoor», não uma confirmação de que foi criada uma entrada oculta. A entrega de credenciais de pessoas reais permanece no fluxo da empresa, sem palavras-passe nesta conversa.

Instalação local: somente migração aditiva 000027, com três tabelas de configuração inicialmente vazias, depois de backup fresco/restauro descartável por hashes iguais e preservação das 84 tabelas anteriores. Avaliação 8005 disponível, ainda sem activação da nova configuração, contas criadas ou permissões alteradas. As identidades dos dois administradores da entrega serão introduzidas na configuração; não foram inferidas de perfis sintéticos. A instalação habitual/domínio não foi migrada nem publicada. Provas e resultados finais em proofs/organization-configuration.json, organization-install.json, organization-pg.json, organization-access-http.json e menu-code-contract.json.

Verificação final: suíte integral com 603 testes: 601 aprovados, dois ignorados já existentes e 5 157 asserções, sem falhas; ensaio próprio de parametrização em PostgreSQL descartável com 13 testes/96 asserções, incluindo criação dos dois administradores, perfis efectivos, ausência de direitos implícitos antes da activação, mínimo de dois administradores, revogação/expiração da manutenção, isolamento, concorrência, rollback de auditoria, regras monetárias exactas e seeder sem contas sintéticas. A base descartável foi removida, sem alteração de privilégios do role reutilizado. PHPStan sem erros, TypeScript, lint/formatação dirigidos, Pint, build e git diff --check aprovados. Runtime: 18 ficheiros conferidos por SHA-256; pacotes fixados preservados. HTTP em 8005 conferiu os seis perfis de avaliação e a parametrização acessível apenas ao proprietário, sem retornar passwords e sem comandos de configuração. Menu: 107 entradas na matriz de compatibilidade e casos adicionais de permissões combinadas; catálogo: 23 páginas. Visual/impressão continuam sem execução nesta entrega.

Âmbito e evolução: esta entrega introduz a gestão efectiva de perfis por empresa e a configuração dos limites existentes. O catálogo inicial agrupa as funções operacionais actuais; o editor universal de etapas/condições, a decomposição das permissões por operação e a gestão das associações específicas do núcleo financeiro comum continuam incrementos próprios. Portanto não se declara toda a aplicação integralmente parametrizável. Fluxos de independência, integridade, histórico e isolamento continuam activos. Visual/impressão manual pendentes pela limitação do controlo de URL Windows já registada. A prioridade seguinte é ampliar a parametrização dos fluxos e das permissões mantendo esta fonte comum, em vez de voltar a listas de perfis dispersas.

Instrução permanente: aplicação integralmente parametrizável — 30 de Outubro de 2026

O proprietário determinou que os utilizadores possam definir quem é quem, quando usar cada função/regra e como fazer as associações em toda a aplicação. Registado em AGENTS.md e na continuidade como requisito transversal dos módulos existentes e futuros. A configuração deve permitir funções/cargos e designações próprias, capacidades/permissões, pessoas/equipas/unidades, múltiplas responsabilidades, delegações/substituições, encaminhamentos, etapas, prazos, condições/limites, vigência e ligações a processos/documentos/fornecedores/relatórios, pela interface e sem alterações de código por cliente. A competência de configurar também deve poder ser atribuída/delegada de forma autorizada, evitando dependência permanente de um único perfil fixo.

Conferência inicial do estado actual: PurchasingRole contém seis perfis fixos; CompanyController permite cadastrar departamentos, centros e pessoas escolhendo esse enum e restringe a configuração ao perfil Admin; SupplierEvaluationWorkflow::ROLES e os fluxos de medidas/contraditório reutilizam uma lista fixa de quatro perfis; os menus também declaram listas de perfis. A requisição já regista parâmetros empresariais numa snapshot, uma prática a preservar e generalizar. Portanto, a aplicação ainda não satisfaz a parametrização integral; a existência de alguns parâmetros de empresa não equivale ao requisito transversal agora definido.

Sequência de implementação actualizada: estabelecer catálogo comum de capacidades, funções/perfis configuráveis por empresa e associações de pessoas/unidades com vigência; fornecer gestão na interface e migrar os perfis actuais como configuração inicial compatível. Depois substituir gradualmente as verificações organizacionais fixas nos controladores/serviços, menus, formulários e relatórios pela mesma resolução de capacidades/âmbito. Parametrizar condições e encaminhamentos com versões, publicação/activação validada e simulação do efeito sobre processos novos/em curso. Preservar as versões aplicadas aos processos e as decisões históricas, validar falta de responsáveis, incompatibilidades e dependências, e manter isolamento, autorização e auditoria efectivos. Não remover verificações dispersas antes de existir a substituição comum testada.

Esta passagem regista a decisão e o levantamento inicial; não altera permissões, contas, processos, schema ou dados. Não declara já disponível um editor de perfis/fluxos. A base de parametrização passa à frente da extensão isolada do consolidado de contraditórios indicado no registo anterior; essas funcionalidades permanecem no âmbito do produto. Critério de entrega: a organização consegue configurar os seus intervenientes, responsabilidades, condições e associações pela interface, com aplicação coerente no servidor e nos percursos/relatórios, sem intervenção do programador para essas adaptações organizacionais.

Contraditório documentado do fornecedor — 30 de Outubro de 2026

Na revisão aprovada da avaliação, implementado o registo pela equipa dos documentos/argumentos recebidos: assunto, data de recepção, referência da origem e transcrição dos argumentos. Rascunhos recuperáveis, gravação idempotente e versionada, submissão para análise, devolução para completar e conclusão por pessoa independente de todos os editores/submetentes do registo. Recepção futura ou dados incompletos impedem a submissão, sem impedir guardar o rascunho. A conclusão fundamentada pode acolher, acolher parcialmente ou não acolher os argumentos; acolhimento exige seguimento documentado. Referência da resposta preparada é opcional. Não há envio automático, comunicação externa ou autenticação do fornecedor neste incremento; a equipa regista o recebido e prepara a comunicação.

Empresa/departamento, perfil recarregado e conflitos de fornecedor/processo são conferidos no servidor. Cada contraditório pertence à revisão exacta. Conteúdo anterior/posterior e decisões ficam no histórico próprio paginado, com autores e datas. Conclusões finais imutáveis no modelo e por trigger SQL; não há apagamento. O relatório individual inclui o contraditório como acompanhamento datado, sem reescrever a avaliação aprovada. Argumentos acolhidos não rectificam automaticamente avaliações, medidas, elegibilidade ou saldos; eventual rectificação usa o mecanismo existente de nova revisão. Fontes documentais são referências textuais; upload de anexos e prova de comunicação não estão incluídos.

Verificações: 39 testes/505 asserções, incluindo 11 novos do contraditório e regressões das avaliações, medidas e consolidado. Cobertos dados incompletos/futuros, idempotência/canonicalização, autores/editores impedidos de concluir, devolução/correcção, seguimento obrigatório, preservação das versões, concorrência, perfis/empresa/departamento, conflitos novos, metadados forjados, imutabilidade SQL e rollback de falha da auditoria. PHPStan sem erros, tipos, lint/formatação dirigidos, Pint, build e git diff --check aprovados. HTTP com dois perfis existentes na base PostgreSQL conferiu o ciclo completo e o relatório; teste SQL recusou UPDATE/DELETE da conclusão final em transacções revertidas. Menu permanece com 106 entradas/seis perfis. Provas proofs/supplier-responses-http.json, supplier-responses-pg.json, supplier-responses-install.json e supplier-responses.json.

Aplicada apenas a migração aditiva 000026 na avaliação persistente 8005, com backup fresco e restauro descartável por hashes iguais, preservando 83 tabelas anteriores e deixando a nova tabela inicialmente vazia. Exemplo fictício CTR-1 concluído na AVF-1, com argumentos parcialmente acolhidos, sem modificar essa avaliação. Nenhuma conta/concessão ou migração adicional; sem instalação habitual ou publicação no domínio. Visual/impressão manual continuam pendentes pela limitação do controlo de URL Windows anteriormente registada; sem nova aceitação visual presumida. Este incremento conclui o registo do contraditório proposto abaixo. Próxima evolução: consulta consolidada dos contraditórios por fornecedor/estado/recepção/conclusão, com ligação aos relatórios; anexos e registo da comunicação exigem o seu incremento próprio.

Consulta consolidada e CSV das medidas — 30 de Outubro de 2026

Entregue /relatorios/medidas-fornecedores, em Relatórios → Medidas de melhoria e por atalho nas avaliações. Filtros combináveis por fornecedor, responsável, estado, título e intervalo de prazo, mais «só prazos ultrapassados». Inclui medidas de revisões anteriores: uma rectificação da avaliação não faz desaparecer uma medida pendente. Resumo calculado sobre todos os resultados autorizados dos filtros, paginação de 25 medidas, ligações directas à medida na avaliação e no relatório individual e impressão explicitamente da página visível.

Exportação /relatorios/medidas-fornecedores.csv inclui todos os resultados dos mesmos filtros, independentemente da página, em lotes de 200. Conserva título/objectivo, fornecedor preservado na avaliação, revisão, responsável, prazo, estado, resultado/evidência, última conferência, versão e ligações. Textos que podem ser interpretados como fórmula são protegidos. Inclui filtros e data de referência; a flag de atraso exclui medidas encerradas e prazos da própria data de referência, sem inferir atraso histórico à data do encerramento. Sem cálculo de elegibilidade ou efeitos financeiros.

Consulta e CSV reutilizam o âmbito da avaliação por empresa/departamento e recarregam o perfil no servidor; opções de fornecedor/responsável derivam apenas de medidas visíveis. Leituras PostgreSQL usam transacção própria repeatable-read/read-only; data de referência única por leitura. Consulta conserva histórico Inertia cifrado e resposta privada sem cache. A listagem envia apenas campos do relatório, sem chaves de idempotência ou hashes internos. Nenhuma migração, nova conta/concessão ou comando de negócio; a avaliação local 8005 já disponibiliza o código e os assets.

Verificações: 36 testes/542 asserções, incluindo seis testes novos do consolidado e regressões de avaliações, medidas e relatórios. Exportação com 207 medidas conferida em dois lotes, filtros, limites de datas, versões anteriores, estados/atrasos, perfis actuais, isolamento por empresa/departamento, opções não expostas, texto CSV seguro e ausência de escritas sobre avaliação/fornecedor/auditoria. PHPStan sem erros, TypeScript, lint/formatação dirigidos, Pint, build e git diff --check aprovados. Prova HTTP na base de avaliação com seis perfis: quatro leitores autorizados e dois recusados; filtros/resumo/CSV e ligações conferidos. Contrato do menu actualizado para 106 entradas/seis perfis; catálogo de avaliação para 22 páginas, com acesso, CSRF e regresso sem credenciais conferidos. Provas em proofs/supplier-improvement-report-http.json, supplier-improvement-report.json, menu-code-contract.json e evaluation-access.json.

Visual/impressão manual continuam pendentes desde o encerramento do controlo da ferramenta por não conseguir confirmar o URL Windows; não se apresenta HTTP como prova visual. Não houve publicação no domínio. Esta entrega conclui a consulta consolidada proposta abaixo. Próximo âmbito funcional: registo do contraditório do fornecedor, com referências documentais e resposta fundamentada, preservando a avaliação original; a política quantitativa permanece por implementar.

Medidas de melhoria das avaliações — 30 de Outubro de 2026

Implementado o acompanhamento na própria avaliação e no relatório: medidas associadas à revisão aprovada, objectivo, responsável interno autorizado e prazo; progresso e referência de evidência registados pelo responsável; pedido de encerramento, devolução/correcção e encerramento independente fundamentado. Autor, editores do plano e todos os responsáveis anteriores ficam excluídos do encerramento. Transferências de responsabilidade e alterações do prazo exigem justificação; o histórico conserva os valores anteriores e posteriores. O prazo ultrapassado é um aviso, sem encerramento ou penalização automática. Não há pontuação, suspensão, alteração de elegibilidade ou operação financeira.

Reutilizados os quatro perfis existentes autorizados a consultar fornecedores, isolamento de empresa/departamento, recarga do perfil e conflitos de fornecedor/processo. Operações versionadas, criação idempotente e auditoria atómica. Medidas encerradas imutáveis no modelo e por trigger SQL; não existe apagamento. Acompanhamento aparece como anexo datado no relatório, sem alterar o conteúdo da avaliação aprovada. As medidas pertencem à revisão exacta; não são copiadas ou encerradas automaticamente ao rectificar a avaliação. Histórico paginado próprio, com decisões e alterações justificadas.

Verificações: 72 testes/768 asserções, abrangendo medidas, avaliações, conflitos e relatórios; PHPStan sem erros, TypeScript, lint/formatação dirigidos, Pint e build aprovados. Ensaio HTTP com três perfis na avaliação real conferiu repetição idempotente, evidência em falta recusada, auto-encerramento/encerramento pelo autor recusados, devolução, reagendamento, versão antiga recusada, correcção, encerramento independente e relatório. PostgreSQL recusou UPDATE/DELETE da medida encerrada em transacções revertidas, preservando a linha. Provas em proofs/supplier-improvements-http.json, supplier-improvements-pg.json e supplier-improvements-install.json.

Aplicada somente a migração aditiva 000025 na avaliação persistente 8005, com backup fresco/restauro descartável e hashes iguais, preservando 82 tabelas anteriores; nova tabela inicialmente vazia. O exemplo QA MM-1 ficou encerrado na AVF-1, sem modificar essa avaliação. Sem contas/concessões novas, migração habitual ou publicação no domínio. A tentativa de conferência visual foi encerrada pela ferramenta por não conseguir confirmar o URL do navegador Windows com confiança suficiente para aplicar a política; não foram tentadas vias alternativas de controlo. Visual e impressão continuam pendentes, sem invalidar os ensaios HTTP nem equivaler a falha do portal. O estado anterior de formatação global fora do incremento permanece documentado abaixo.

Este incremento conclui o acompanhamento proposto no registo anterior. Próximo passo funcional: visão consolidada de medidas por fornecedor, responsável, prazo e estado, ligada aos relatórios, reutilizando estes registos; contraditório do fornecedor e política quantitativa continuam por desenvolver.

Avaliações qualitativas de fornecedores — 30 de Outubro de 2026

Implementado /fornecedores/avaliacoes: criação e recuperação de rascunhos, filtros, âmbito/período, ordens autorizadas, critérios com justificação/evidência, ocorrências críticas e conclusão. Ciclo rascunho → revisão → devolução/correcção ou aprovação independente. Todos os editores e o submetente ficam excluídos da aprovação dessa revisão; perfis e conflitos são reconferidos no servidor. Empresa e departamento restringem as consultas. Reutilizados os quatro perfis existentes de fornecedores, sem contas ou concessões novas. O departamento deriva das ordens seleccionadas; avaliações de vários departamentos ficam no âmbito empresarial.

Gravação idempotente, versões contra sobreposição concorrente e auditoria atómica com conteúdo anterior/posterior. Aprovações imutáveis também por trigger SQL; rectificação cria revisão ligada, conservando o relatório aprovado. Relatório imprimível, estado explícito e histórico paginado. A proposta quantitativa continua apenas proposta: sem pesos, pontuação/classificação automática ou alteração da elegibilidade. Medidas de melhoria e contraditório do fornecedor continuam para incremento próprio.

Verificações: 61 testes/655 asserções (avaliações, conflitos e relatórios), PHPStan sem erros, TypeScript, Pint dirigido, lint dos novos ecrãs e build aprovados. Contrato do menu: 102 entradas/seis perfis; acesso: 21 páginas/seis perfis. HTTP no PostgreSQL local conferiu criação, submissão, auto-aprovação recusada, devolução, correcção, versão desactualizada recusada, aprovação independente, relatório e revisão posterior. Provas em proofs/supplier-evaluations-http.json, supplier-evaluations-install.json e supplier-evaluations-pg.json. Ensaio retomado após corrigir expectativas do script sobre redireccionamentos Inertia, conservando o mesmo exemplo QA e o histórico.

Aplicada apenas a migração aditiva 000024 na avaliação 8005, após backup fresco e restauro descartável com conteúdos/hashes iguais. Preservadas as 81 tabelas anteriores; nova tabela inicialmente vazia. Sem contas, concessões ou migrações adicionais. AVF-1 é exemplo fictício aprovado; AVF-2 é rascunho de rectificação; nenhuma operação financeira. Instalação habitual e domínio não migrados/publicados. Visual/impressão manual por executar. O npm run check global acusa formatação anterior fora deste incremento; não foi declarado aprovado nem foram reformatados ficheiros alheios por arrasto.

Esta entrega substitui a indicação abaixo de que a avaliação era apenas proposta. Próximo incremento: medidas de melhoria com responsáveis, prazos, evidências e encerramento independente, antes de converter a proposta quantitativa em política operacional.

Entrada sem credenciais ao abrir links da avaliação — 30 de Outubro de 2026

O utilizador encontrou o formulário de credenciais ao abrir directamente /relatorios sem sessão. Corrigido o encaminhamento dos hóspedes no host local de avaliação: o link protegido e /login conduzem a /avaliar; após escolher o perfil existente, a entrada preserva o destino e os filtros antes de regenerar a sessão. A navegação de regresso só aceita caminhos locais ou URLs da mesma origem/porta; destinos externos, esquemas estranhos, caracteres de controlo e ciclos de login são recusados em favor do painel. As guardas de base/role QA, CSRF, perfis permitidos e isolamento foram preservadas. A instalação habitual continua a usar a autenticação própria.

Incluídos Relatórios no catálogo da avaliação (21 páginas) e testes de navegação/âmbito. Aprovações: 23 testes Feature/172 asserções (15 casos de navegação e oito dos relatórios), PHPStan e Pint dirigidos; prova HTTP repetível na avaliação real com 21 páginas, seis perfis, regresso ao relatório com filtros, CSRF/identificadores inválidos recusados e logout. scripts/evaluation-access-check.mjs e docs/proofs/evaluation-access.json actualizados. O ensaio usou uma sessão de teste própria, sem encerrar a sessão do navegador do utilizador e sem comandos de negócio. Sem redefinição de credenciais ou instalação no domínio.

Compatibilização do menu e fluxo até aos relatórios — 30 de Outubro de 2026

Pedido do proprietário: continuar a aplicação, ligar funções do menu ao código necessário e optimizar os percursos até à geração de relatórios. Reutilizados os controllers, políticas, processo e relatório de conferência existentes. Inventário por grupo e lacunas concretas em menus-benchmark-20261029.md; prova repetível de 102 entradas/6 perfis em scripts/menu-code-check.mjs e proofs/menu-code-contract.json. A avaliação de fornecedores foi identificada como proposta de UI, não processo persistente; mantém-se explicitamente por desenvolver.

Implementação: grupo «Relatórios» com /relatorios, controller próprio e página Inertia, com filtro por número, estado da requisição, intervalo de criação e departamento autorizado; resumo de todos os resultados e paginação de 25 linhas. Exportação CSV em /relatorios/compras.csv aplica os mesmos filtros e âmbito, percorre lotes de 200, inclui metadados/filtros e valores monetários em centavos inteiros sem conversão para float. Textos potencialmente interpretáveis como fórmula são protegidos. O valor estimado não é apresentado como adjudicação, dívida ou pagamento. Leituras PostgreSQL usam snapshot repeatable-read/read-only, conforme o relatório existente; essa cláusula não equivale a novo ensaio de concorrência PostgreSQL nesta passagem.

Percurso entregue: menu → central/filtros → requisição e acompanhamento do processo → relatório de conferência/impressão já existente → regresso à central. O relatório individual passou a incluir recepções e links; facturas e registos de pagamento só aparecem aos perfis financeiros anteriormente autorizados. Estados e montantes são os factos guardados, sem recalcular saldos ou inferir liquidação. O relatório não carrega/exibe referências privadas ou snapshots bancários. Corrigida a descrição de tipo da data já convertida pelo modelo GoodsReceipt, sem mudança do cast/schema.

Verificações: 14 testes Feature/223 asserções em SQLite em memória; oito casos novos da central/ampliação e seis regressões do relatório existente. Incluem intervalo com dia final completo/data final isolada, 207 registos exportados em vários lotes, pesquisa, resumos, isolamento empresa/departamento, perfis revogados, hóspedes, filtros inválidos, inteiro monetário acima da precisão segura do JavaScript, CSV, ligações ao processo/relatório, recepção/factura/pagamento e saldos/auditoria preservados. TypeScript, lint/formatação dirigidos, Pint, PHPStan dos novos/alterados PHP, build e diff-check aprovados; módulo React novo e avaliação 8005 responderam HTTP200. Manifesto dos 18 ficheiros de execução continua íntegro. Conferência visual/impressão manual pendente, sem declarar um PDF gerado/ensaiado ou publicação.

Ficheiros principais: ProcurementReportController, ProcurementReviewReport, GoodsReceipt (tipo), rotas, procurement-navigation, páginas reports/procurement e purchases/review-report, ProcurementReportsTest e menu-code-check. Sem migrações, seeds, novas contas/direitos, escritas de negócio ou activação remota. Preservadas as alterações locais anteriores de empacotamento. Próximo incremento: ciclo persistente de avaliação de fornecedores, desde planeamento/rascunho até revisão, histórico e relatório, com critérios e evidências explícitos; demais lacunas mantidas no inventário. Fonte de partida 0235c76; alterações desta entrega permanecem locais.

Orientação comercial e remoção de dependência local — 30 de Outubro de 2026

O proprietário determinou a remoção/correcção dos bloqueios ao desenvolvimento, testes, ajustes e disponibilização, considerando a comercialização do produto. Orientação registada no início de orientacoes-continuidade.md e em AGENTS.md, prevalecendo sobre adiamentos genéricos históricos. Dependências reais devem ser identificadas e resolvidas; a pendência visual não suspende o desenvolvimento e os testes. Controlos funcionais de isolamento, aprovação independente, integridade e auditoria conservados.

Bloqueio concreto removido: o provider dependia de ../sgf-tempo/packages quando faltavam os núcleos locais; em produção o fallback não existia e o Compras não era distribuível autonomamente. Incluídos 18 ficheiros de execução dos núcleos de orçamento/obrigações, byte a byte iguais à origem comum, com manifesto SHA-256. Incluídos os templates usados pelo workspace. Não foram copiados seeds, bases, credenciais ou ensaios de provisão. O provider usa agora os pacotes instalados/configurados em todos os ambientes, sem procurar a pasta vizinha. Os artefactos fixados não são uma segunda implementação financeira; actualizações vêm da origem comum com renovação do manifesto.

composer run runtime:check verifica versão, bootstraps, existência e hashes; integrado em ci:check. Git preserva os bytes dos artefactos e inclui-os nas exportações; os formatadores não reescrevem estes pacotes fixados. Configurações de paths continuam disponíveis para outras formas de instalação. Fonte local de partida 0235c76 (checkpoint do proprietário observado durante o trabalho), com as alterações desta entrega ainda locais.

Verificações aprovadas: 18 hashes iguais à origem; bootstrap com APP_ENV=production confirma por reflexão que BudgetControl e Payables foram carregados de compras/packages; 64 testes dirigidos de orçamento, reforços, integração de obrigações, importação histórica e decisões, com 277 asserções, em SQLite em memória. PHPStan do provider, Pint dirigido, sintaxe PHP, Composer validate e diff-check aprovados. Avaliação 8005 continua HTTP200. Não houve migrações, alterações de contas/permissões/dados, pagamentos ou instalação no domínio.

Dependências concretas seguintes: o arranque de avaliação ainda reutiliza o perfil/router local já existente; alguns pagamentos têm implementação e referências exclusivamente sintéticas e necessitam do percurso comercial, schema e configuração correspondentes; o instalador/acesso do domínio Compras não foi identificado e o nome com www continua por reconciliar. Estes pontos são trabalho técnico a executar, não novas aprovações organizacionais nem proibição genérica de desenvolvimento. Não confundir a remoção do caminho externo com entrega integral dos pagamentos reais ou publicação já executada.

Paridade com o domínio pedida pela Tempo — 30 de Outubro de 2026

Requisito expresso: a versão vista localmente deve corresponder à de www.compras.tempo.co.mz, incluindo menus, dropdowns, visual e processos. A avaliação local passa a ser a referência da apresentação entregue; a aceitação exige conferir a mesma revisão e os assets, com diferenças de configuração/activação documentadas. Preservar dados e acessos de cada ambiente; não publicar os perfis sintéticos sem palavra-passe por consequência desta orientação.

Conferência apenas de leitura: a pasta local está em main 4654268, com as alterações de arranque e menu desta sessão ainda não enviadas/instaladas. Os documentos existentes distinguem pagamentos/afectações sintéticos em 8005/8006 da instalação habitual; SupplierPayables confirma guardas de ambiente/base para esses recortes. Logo, não há prova de equivalência funcional integral por partilhar os componentes React. O domínio com www não resolveu no DNS deste computador; o domínio sem www respondeu HTTP200 a curl (outra ferramenta recebeu HTTP403), sem inspecção autenticada ou identificação segura da revisão instalada. A pesquisa nos ficheiros consultados não identificou o instalador/acesso do servidor de Compras. Nenhuma publicação, alteração de DNS, flags remotas, contas ou dados foi feita.

Para concluir a entrega equivalente: identificar o processo e acesso de instalação de Compras; comparar a revisão/schema/configuração/permissões e o âmbito dos fluxos hoje restritos à avaliação; preparar a candidata com as alterações locais; preservar o destino com backup/restauro antes da instalação; conferir assets/menus e percursos afectados no domínio. Resolver também o acesso ao nome www. A orientação está registada, mas a instalação e a paridade remota continuam pendentes.

Menu horizontal com dropdowns — 30 de Outubro de 2026

Pedido expresso: colocar o menu na horizontal, mantendo dropdowns e o visual. SgcWorkspaceShell passa a apresentar os grupos no topo em ecrãs grandes, com os componentes dropdown já existentes. Mantidos fundo escuro, identidade SGC, cores, ícones, destaque do destino activo, grupos, ordem, destinos e filtros por perfil. A pesquisa continua a filtrar as opções; os destinos de página completa conservam esse comportamento. A área de conteúdo deixa de reservar espaço para o menu lateral. Em ecrãs pequenos mantém-se o painel móvel; Aparência e Página inicial continuam acessíveis.

Verificações dirigidas: TypeScript, lint do componente, formatação e git diff --check aprovados; módulo actualizado servido pelo Vite com HTTP200. Sem alterações de backend, processos ou permissões. Não foram repetidos testes de negócio por esta alteração de apresentação. Conferência visual do navegador não executada nesta passagem: o conector devolveu «The browser access host is unavailable». A alteração está disponível na avaliação 8005 com o Vite activo; não representa aceitação visual dos restantes processos.

Entrada de desenvolvimento na avaliação persistente — 30 de Outubro de 2026

Pedido expresso: durante o desenvolvimento, mostrar a versão de avaliação com os menus organizados e os processos avançados, não a instalação habitual sem acesso do utilizador. A comparação confirmou que os menus/processos estavam preservados no código; a diferença era a entrada 8015 versus a avaliação existente em 8005.

composer run dev passa a executar scripts/dev-evaluation.php: confere a configuração QA existente, reutiliza a avaliação em 8005 ou retoma apenas esse servidor com o router existente, e inicia/reutiliza o Vite de Compras. Entrada apresentada: http://127.0.0.1:8005/avaliar, com «Entrar como proprietário» e os perfis existentes. O APP_URL do processo Vite é 8005, sem alterar o .env. Não inicia a fila habitual; não provisiona bases, aplica migrações, executa seeds, cria contas ou altera permissões. A instalação habitual permanece disponível explicitamente como composer run dev:standard.

Verificações: sintaxe PHP, Pint dirigido, composer validate --no-check-publish e git diff --check aprovados. --check reconheceu a avaliação existente; arranque completo pelo Composer aprovado, reutilizando o servidor 8005 e iniciando o Vite em 127.0.0.1:5173. /avaliar e /@vite/client responderam HTTP200; terminal indica APP_URL8005. A sessão habitual iniciada nesta assistência foi terminada; nenhum processo alheio foi terminado e o servidor de avaliação existente foi preservado. O caminho de arranque com 8005 parado está implementado, mas não foi ensaiado interrompendo o servidor persistente do utilizador.

Ficheiros: composer.json, scripts/dev-evaluation.php, README e orientações de continuidade. Sem alterações aos módulos funcionais, dados, credenciais ou ambiente do SGF. Esta conferência de arranque não substitui a avaliação visual e operacional dos processos.

Reforço da integração de obrigações — 29 de Outubro de 2026

Continuação do ensaio COMMON-PAYABLE-SOURCE-SIM-v1, descrito em entrega comum. ExternalPaymentWorkflow passa a revalidar o principal canónico dentro das transacções de registo e conferência, depois dos bloqueios da empresa e da factura, antes de aceitar repetições ou gravar decisões. Evita confiar apenas na consulta anterior à espera pelo bloqueio. Preserva as alterações existentes.

Acrescentado teste em ExternalPaymentTest.php: mesmo com instância de origem configurada, as quatro rotas de consulta/preparação/validação recusam acesso fora da base isolada e o pagamento legado continua funcional. Testes de pagamentos: 34 aprovados, 113 asserções. PHPStan sem erros e Pint dos dois ficheiros alterados aprovado. Este teste não simula concorrência PostgreSQL. Regressão completa executada: 499 aprovados, 2 ignorados, 4 147 asserções. Os dois ignorados correspondem à cobertura MFA já pendente na configuração.

Sem migrações, seeds, alterações de contas ou dados reais, novos pagamentos operacionais, commit, push ou publicação. Revisão visual e aceitação do ensaio continuam pendentes; este reforço não activa obrigações em produção.

Estado consolidado após abertura e actas — 28 de Outubro de 2026

Referência: commit 07e775c e validação técnica. O resultado mais recente registado é 443 testes aprovados, 2 ignorados, 3.431 asserções. Os dois ignorados dependem de MFA activado. PHPStan, Pint, TypeScript e compilação passaram no incremento de abertura. Estes resultados são os documentados na evidência; não foram novamente executados nesta actualização documental. As secções seguintes são históricas e os seus resultados e pendências não substituem este estado.

• Revisão/cancelamento de adjudicações sem ordem emitida entregue em /revisao-compras: política datada por empresa, duas aprovações administrativas distintas do proponente e decisão independente de Finanças para o pedido de Compras. Sem política publicada não há activação automática. Pedido pendente bloqueia emissão; aprovação preserva o histórico e liberta apenas reserva não comprometida. Ordens emitidas ou compromissos impedem o circuito. Após cancelamento aprovado, o solicitante original elegível pode criar um único rascunho ligado, sujeito a novas validações e aprovações.
• Visão única em /requisicoes/{requisition}/processo: etapas, responsáveis, decisões, documentos e eventos filtrados por perfil e empresa, com ligações aos processos revistos. Consulta não cria aprovações ou certifica execução.
• Planeamento em /planeamento: itens por empresa, marcos livres, responsáveis, datas previstas/realizadas, ligação posterior a requisição e histórico de alterações com controlo de versão. Não reserva orçamento.
• Abertura em /requisicoes/{requisition}/abertura: sessões opcionais, propostas copiadas no servidor, actas imutáveis por versão e impressão autenticada. Correcções exigem fundamento; não certifica assinaturas ou impõe concurso/júri obrigatório a todas as empresas.
• Migrações 000015, 000016 e 000017 constam como aplicadas nos relatórios, após backups privados e restauros verificados. Evidências de concorrência: seis cenários de revisão, quatro de planeamento e quatro de abertura, executados em bases PostgreSQL exclusivas e eliminadas no final. Não são testes de carga nem uma nova execução de toda a bateria anterior.

Pendências actuais: cancelamento de ordens emitidas, estornos, notas de crédito, devoluções, agregação por projecto/fraccionamento, publicação de concursos, propostas seladas, qualificação por etapas e novos métodos de avaliação. Revisão visual pública, autenticada e de impressão permanece pendente por indisponibilidade do navegador. Orçamento, facturas, pagamentos externos e regras de investimento têm implementação documentada; isso não equivale à validação operacional integral das regras de cada empresa.

Esta consolidação altera apenas documentação; não aplica migrações, cria políticas, executa testes ou altera contas, configuração e dados de negócio.

Histórico: revisão transversal de autorização e validação

Corrigidas verificações de perfil que aconteciam antes de esperar pelo bloqueio da empresa: o operador é agora recarregado e bloqueado na transacção nos módulos de facturas, banco, armazém, requisições e compras. Departamento/centro de custo também são revalidados. Dotação não aprovada deixou de mostrar verba disponível. Corrigido um teste indevidamente ignorado com MFA desligado e traduzidos os textos da página de segurança. Configuração de fontes alinhada com a dependência opcional ausente, sem mudança de fonte ou instalação de pacotes.

Suite: 407 aprovados, 2 ignorados, 2.964 asserções. Os dois ignorados são de MFA activado, que continua desligado. 32 cenários concorrentes PostgreSQL aprovados, incluindo revogação real de perfil enquanto dois pedidos aguardam bloqueio: ambos responderam 403, sem movimentos. Bases temporárias eliminadas. Sem migrações ou alterações de contas/dados de negócio reais nesta revisão.

Detalhes das correcções, evidências e pendências estão em validação técnica. Revisão visual e validação operacional integral permanecem pendentes. Funcionalidades não implementadas, incluindo revisão/cancelamento, não foram tratadas como se já existissem.

Regras de investimento por empresa

Implementadas em /regras-investimento, sem montantes predefinidos ou regras criadas na base real. Administração propõe tecto, base com/sem IVA, vigência, âmbito e fundamento. Dois administradores distintos do proponente aprovam a versão. Finanças e Procurement consultam; outros perfis não configuram. Proponente e validadores mantêm elegibilidade até à publicação. Decisões e parâmetros são preservados; correcção exige nova versão.

Nesta etapa, a empresa escolhe explicitamente um tecto absoluto em MZN sobre o total do processo que contenha equipamento. O limite é inclusivo e a base de IVA é independente dos escalões gerais. Não se presume aprovação adicional, agregação por projecto, câmbio ou limite ilimitado. Zero explícito é um tecto zero, não ausência de limite. Não existe detecção automática de fraccionamento; este incremento não certifica o controlo global desse requisito.

Vigência e integração

Uma proposta pendente/rejeitada não substitui a regra aprovada. Nova versão aprovada passa a ser aplicável a partir da sua data inicial. Depois de uma versão mais recente entrar em vigor, a sua expiração bloqueia o fluxo; não ressuscita uma regra anterior mais permissiva. As aprovações administrativas publicadas são históricas; mudanças posteriores de perfil não reescrevem a regra.

Adjudicação, aprovação do valor final e emissão verificam regra aplicável, tecto, validação técnica e reserva em dotação de investimento aprovada do centro/exercício. Finanças é obrigatória para equipamento tanto na estimativa como no novo ciclo do valor final, para qualquer valor. A versão, os parâmetros, os dois validadores, a base técnica e a dotação ficam congelados na adjudicação. Mudança de regra/base antes da emissão bloqueia o reaproveitamento das aprovações. Ordens já emitidas mantêm a regra congelada e emissão repetida devolve a mesma ordem.

Orçamentos distinguem despesa corrente de investimento. Registos anteriores receberam operating; não foram convertidos em investimento. A interface exige classificação explícita para novas dotações; chamadas anteriores sem esse campo continuam limitadas a despesa corrente. Mantém-se uma dotação por centro/ano: para separar classes no mesmo ano, a empresa usa centros distintos. A dotação aprovada e a sua classificação não são reescritas por reforços. Não se atribui reserva de investimento retroactivamente a processos anteriores sem reserva.

Recepções de equipamento emitido passam a admitir entrada física aceite, com armazém/artigo/unidade explícitos. Não criam automaticamente uma máquina no cadastro, não capitalizam activos nem inventam compatibilidades. A área/linha do pedido e a regra aplicada ficam no snapshot da ordem, no detalhe e na impressão.

Verificações e aplicação

Suite completa: 393 testes aprovados, 3 ignorados, 2.886 asserções. Os 70 testes de regras de investimento e adjudicação passaram, incluindo 15 de governação e oito novos cenários integrados de equipamento: duas assinaturas, isolamento, vigência, ausência de retrocesso após expiração, tecto inclusivo, bases de IVA, Finanças obrigatória, dotação/validação técnica, alteração de regra, emissão, recepção física e preservação da ordem após nova publicação. PHPStan, Pint, TypeScript, compilação e formatação/lint frontend aprovados.

Três cenários concorrentes PostgreSQL aprovados: assinaturas distintas, mesma assinatura repetida e propostas de versões concorrentes. Dois processos e duas ligações independentes observados simultaneamente à espera de bloqueios por cenário. Estados e contagens conferidos; base temporária eliminada. São testes de serviço, não de carga ou de todos os fluxos concorrentes de emissão. Evidência.

Migração 000014 aplicada no lote 15 após backup custom PostgreSQL 17 de 250.983 bytes e restauro verificado das 46 tabelas anteriores numa base temporária, depois eliminada. Dump e manifesto partilharam snapshot consistente. A verificação antes/depois projectou as colunas anteriores, preservando dados de negócio e restrições enquanto eram acrescentadas classificação e snapshot. .env, contas e credenciais preservados. Tabelas de regras e decisões vazias, sem políticas fictícias, sementes ou limites definidos para empresas reais. Backup e manifesto privados, fora do Git. Evidência sem dados privados.

Limitações e continuidade

/consulta/investimento é demonstração fictícia, sem consultas/gravações de negócio. Revisão visual pública, autenticada e de impressão permanece pendente; o navegador está indisponível. Testes HTTP/Inertia e compilação não a substituem. Também não há validação operacional integral ou autorização de compras reais.

Empresas devem criar as dotações e regras efectivamente decididas pelos seus responsáveis. Sem regra vigente e reserva apropriada, equipamento permanece bloqueado. Circuitos acima do tecto, agregação por projecto, classificação automática de investimento e detecção de fraccionamento não foram implementados. Próximo incremento: revisão/cancelamento controlado de processos afectados por mudanças de base, com política explícita, histórico e novas aprovações; não reutilizar decisões antigas nem alterar ordens emitidas directamente.

Reforços orçamentais por empresa

Implementadas propostas de reforço em /orcamentos, por dotação existente de empresa/centro de custo/exercício. Administração ou Finanças propõe referência interna, montante positivo e fundamento; outra pessoa destes perfis aprova ou rejeita, fundamentando. Perfis do operador e do proponente são recarregados em transacção. O autor não aprova o próprio reforço.

A dotação inicial aprovada não é alterada. Dotação acumulada = valor inicial mais reforços aprovados. Disponível = acumulada menos reservas, compromissos remanescentes e consumos. Pendentes e rejeitados não aumentam o saldo; a aprovação permite novas reservas apenas dentro do disponível actualizado. Reforçar não altera consumo ou compromissos anteriores, base de IVA, moeda, centro, exercício ou regras de aprovação de compras. Montantes são definidos pela própria empresa, sem valores financeiros predefinidos para clientes.

Referência normalizada única por empresa, permitindo referências iguais noutras empresas. Repetição idêntica da proposta ou da aprovação não duplica a verba. Decisões finais e dados do reforço não admitem reescrita ou eliminação pelos modelos. Falha na auditoria reverte integralmente proposta ou decisão. Só dotações aprovadas do exercício actual recebem reforços. Há o mesmo limite técnico de representação monetária das requisições, não um limite empresarial ou autorização comercial. Aprovações históricas não são revogadas automaticamente por mudanças posteriores de perfil; correcções exigem fluxo próprio, ainda ausente.

Verificação e aplicação

370 testes aprovados, 3 ignorados, 2.704 asserções na suite completa. Inclui 23 testes de reforços, 74 asserções: perfis, independência, exactidão, idempotência, bases preservadas, isolamento, valores por empresa, ano encerrado, auditoria e rollback, inputs manipulados e disponibilidade para reservas. PHPStan, Pint, TypeScript e compilação aprovados.

Três cenários concorrentes PostgreSQL aprovados: mesma aprovação repetida, reforços distintos aprovados em simultâneo e aprovação concorrente com reserva. Duas ligações independentes em processos PHP observadas simultaneamente à espera de bloqueios por cenário. Conferidos dotação acumulada, saldo reservado, ausência de excesso e preservação do valor inicial. Base temporária eliminada. São transacções de serviço, não teste HTTP ou de carga. Evidência.

Migração 000013 aplicada no lote 14, após backup custom PostgreSQL 17 de 245.514 bytes e restauro verificado das 45 tabelas anteriores numa base temporária, depois eliminada. Dump e manifesto partilharam snapshot consistente. Registos de negócio, restrições e .env preservados. Tabela de reforços vazia: sem seeds, verbas fictícias, contas novas ou alterações de credenciais na base real. Backup/manifesto privados, fora do Git. Evidência sem dados privados.

/consulta/reforcos contém somente exemplos fictícios; não consulta dotações ou utilizadores e não grava dados. O navegador voltou a reportar The browser access host is unavailable: revisão visual pública, autenticada e de impressão continua pendente. Não constitui validação operacional integral.

Próximo passo e limitações

Próximo incremento: regras de investimento configuráveis por empresa e aprovadas independentemente. Não inventar montantes comuns aos clientes, semântica de limites ou dispensa de aprovações. Enquanto não houver regra própria aprovada, equipamentos continuam bloqueados para adjudicação/emissão. Reduções, transferências de dotações, estornos de reforços e passagem de saldos entre exercícios não foram implementados; exigem fluxos e decisões próprios.

Registo e conferência de pagamentos externos

Implementado /pagamentos, por empresa. Finanças regista pagamentos já efectuados fora do SGC, com factura validada, montante explícito, data efectiva, referência externa e evidência. Outra pessoa de Finanças confirma ou rejeita a conferência. O sistema não executa transferências, remessas ou ordens bancárias.

• Apenas os registos confirmados abatem a dívida da factura. Liquidação parcial ou total é calculada a partir desse histórico; não reescreve a factura validada. Pendentes/rejeitados não abatem o saldo. A confirmação não lança novamente consumo ou compromisso orçamental: o orçamento foi consumido na factura.
• Montante deve ser positivo e caber no saldo confirmado ainda pendente. Duas confirmações concorrentes não podem exceder a factura. Referência normalizada única por empresa; repetição idêntica pelo autor devolve o registo existente, enquanto dados diferentes para a mesma referência são recusados.
• Registo e confirmação revalidam factura, fornecedor, conflitos, moeda e versão bancária mais recente com duas validações elegíveis. Versão alterada, fornecedor suspenso, perda de perfil ou conflito posterior bloqueiam confirmação. Registos históricos já confirmados não são reescritos por mudanças posteriores.
• Uma operação externa corresponde a uma factura nesta etapa. Datas entre exercícios, câmbio, adiantamentos, estornos, reembolsos, anulação de confirmados e repartição da mesma operação por várias facturas não estão implementados. Uma referência de evidência não é upload de comprovativo nem verificação bancária.
• Referência externa, evidência, fundamento e snapshot bancário são cifrados. Snapshot preserva versão, conta e validadores do momento do registo; não é exposto na listagem. Administração consulta metadados; Finanças consulta referências/evidência com auditoria. Outros perfis não acedem ao módulo. Auditoria contém IDs, montantes e estados, sem referências externas nem números bancários. Histórico Inertia cifrado, resposta sem cache e dados sensíveis excluídos de input antigo de sessão. Preservar a chave de aplicação no restauro.
• Modelos impedem edição do registo e eliminação. Decisão final é imutável; falha na auditoria reverte registo ou confirmação. Protecção contra SQL administrativo directo continua dependente das permissões da base de dados.
• /consulta/pagamentos contém apenas exemplos fictícios. Valores operacionais vêm das facturas da própria empresa e do montante introduzido; não há valores financeiros predefinidos para clientes. Moeda suportada nesta etapa: MZN, coincidente com a conta; sem autorização implícita para conversões.

Verificação e migração

Suite completa actual: 347 aprovados, 3 ignorados, 2.630 asserções. PHPStan, Pint, TypeScript, compilação e formatação/lint frontend aprovados. O serviço recarrega o perfil do operador depois do bloqueio da empresa e bloqueia os registos dos validadores bancários durante a conferência.

33 testes específicos aprovados, 107 asserções: liquidação parcial/total, limites, idempotência, versões bancárias, perfis, conflitos, moedas, isolamento, cifragem, privacidade, input não guardado, ausência de consumo duplicado, auditoria e rollback. Três cenários concorrentes PostgreSQL aprovados com duas ligações independentes observadas simultaneamente à espera de bloqueios: excesso, mesma confirmação e pagamentos complementares. Saldos e manutenção do consumo orçamental conferidos; base temporária eliminada. São testes de serviço, não de carga ou HTTP. Evidência.

Migração 000012 aplicada no lote 13, após backup custom PostgreSQL 17 de 239.843 bytes e restauro verificado das 44 tabelas anteriores numa base temporária, depois eliminada. Snapshot consistente para dump e manifesto. Registos de negócio, restrições e .env preservados. Tabela de pagamentos externos vazia; sem seeds, contas novas, alterações de credenciais ou pagamentos fictícios na base real. Backup e manifesto privados, fora do Git. Evidência sem dados privados.

Pendências e próximo incremento

O navegador continua indisponível (The browser access host is unavailable). Revisão visual pública, autenticada e de impressão permanece pendente. Este incremento não constitui integração bancária, confirmação bancária automática ou validação operacional integral do orçamento. Documentos continuam de desenvolvimento. Próximo incremento: reforços orçamentais auditados, propostos e aprovados por pessoas distintas, com valores definidos por cada empresa. Regras de investimento também continuam por definir por cliente; equipamento permanece bloqueado.

Dados bancários de fornecedores com dupla validação

Implementado no mesmo projecto, com dados isolados por empresa/fornecedor. Procurement propõe uma versão completa; duas pessoas distintas de Finanças, ambas diferentes do autor, conferem e aprovam. Uma aprovação mantém o estado pendente; repetir a mesma decisão não conta outra vez. Rejeição impede novas aprovações nessa versão. Correcções exigem nova versão, sem reescrever o passado.

A versão mais recente substitui a anterior para disponibilidade futura, mesmo quando pendente ou rejeitada. Propostas com referência anterior desactualizada e decisões sobre versões substituídas são recusadas. Reavaliação do estado considera fornecedor activo/revisão válida/impedimentos, perfil actual dos validadores e conflitos de interesses. Mudança de perfil do autor não permite auto-aprovação. Futuro pagamento deve revalidar tudo na própria transacção, sem confiar no estado mostrado anteriormente no ecrã.

Identificador da conta, titular, referência de evidência e fundamentos são cifrados com a chave Laravel existente. Modelos ocultam esses campos na serialização geral. Procurement e Finanças acedem aos dados actuais com auditoria de leitura; Administração recebe apenas estado e metadados. Outros perfis não acedem. A auditoria contém referências/versões, não números ou titulares de conta. Resposta privada sem armazenamento em cache e histórico Inertia cifrado. Campos sensíveis não são guardados em input antigo da sessão; o campo reason é também excluído globalmente para impedir cópias de fundamentos bancários em validações falhadas. Preservar a chave de aplicação nas operações de recuperação: um backup de dados cifrados não substitui a guarda dessa chave.

Ficha: /fornecedores/{supplier}/dados-bancarios, ligada à ficha existente. Exemplo público: /consulta/dados-bancarios, sem contas ou consultas de negócio. Banco, titular, conta, país e moeda são fornecidos pela própria empresa. Não existem contas, bancos ou valores financeiros predefinidos por cliente.

Verificação, concorrência e migração

Suite completa: 314 testes aprovados, 3 ignorados e 2.523 asserções. Inclui 16 testes bancários e 74 asserções: independência, duas pessoas, versões, rejeição, conflitos posteriores, mudanças de perfil, isolamento, cifragem, resposta restrita, cache, auditoria, rollback e input sensível não guardado na sessão. PHPStan, Pint, TypeScript, compilação e frontend aprovados.

Três cenários concorrentes PostgreSQL aprovados: duas aprovações distintas, mesma aprovação repetida e versões concorrentes. Duas ligações independentes em processos PHP, observadas simultaneamente à espera de bloqueios por cenário. Conferidos estados, versões e contagens de decisões; base temporária eliminada. São testes de serviço, não de carga ou HTTP. Evidência.

Migração 000011 aplicada no lote 12 após backup custom PostgreSQL 17 de 230.372 bytes e restauro verificado das 42 tabelas anteriores numa base temporária, depois eliminada. Dump e manifesto partilharam snapshot consistente. Dados de negócio, restrições e .env preservados; novas tabelas vazias. Sem contas bancárias fictícias na base real, seeds, recriação de utilizadores ou alteração de credenciais. Backup e manifesto privados, fora do Git. Evidência sem dados privados.

Limitações e roteiro

O identificador é texto normalizado com validação genérica de formato; não há consulta bancária, verificação de titularidade, validação nacional de IBAN/NIB ou confirmação automática da evidência. A declaração de conferência é humana. Uma conta actual por fornecedor; múltiplas contas simultâneas, cancelamento e levantamento de rejeição não foram implementados. Não existem pagamentos, transferências, ficheiros de remessa, integração bancária ou envio externo.

Nova tentativa de navegador devolveu The browser access host is unavailable. Revisão visual pública, autenticada e de impressão continua pendente. Validação operacional integral do orçamento também permanece pendente. Próxima etapa: registo e conferência de pagamentos externos sobre facturas validadas, com revalidação da versão bancária no momento da operação; não confundir esse futuro registo com execução de transferências bancárias.

Facturas, conferência e consumo orçamental

Implementado /facturas: Administração consulta; Finanças regista e outra pessoa de Finanças valida. Número normalizado único por empresa/fornecedor. Conferência exacta de quantidade, unidade, preço, IVA e totais com a ordem congelada e a recepção aceite ainda não facturada. Serviços também exigem aceitação. Diferenças impedem registo/validação, sem correcção automática do documento.

Facturação parcial com arredondamento acumulado por linha para preservar os centavos e IVA da ordem. Validação revalida quantidades e conflitos dentro da transacção com bloqueio da empresa; repetição não duplica lançamentos. Sem compromisso aprovado do exercício actual, a factura permanece pendente. Na validação, a parcela facturada converte compromisso em consumo. O disponível desconta reservas, compromisso remanescente e consumo, sem duplicar despesa ou libertar saldo ao facturar. Falha de auditoria reverte toda a operação.

Cada documento, orçamento e configuração pertence à empresa correspondente. A base com/sem IVA é a escolhida pela empresa; não existem dotações globais. Autores de facturas integram os intervenientes auditados do processo. Facturas, linhas e consumos não admitem reescrita/eliminação pelos modelos. /consulta/facturas apresenta somente exemplos fictícios, sem consultar ou gravar dados de negócio; os valores não são configurações predefinidas.

Verificação e aplicação

22 testes de facturas aprovados, 82 asserções: independência, isolamento, valores, duplicação, concorrência lógica de pendentes, auditoria/rollback, compromisso obrigatório, serviços, consumo e arredondamento parcial de IVA. Suite completa actual: 298 aprovados, 3 ignorados e 2.449 asserções. PHPStan, Pint, TypeScript, compilação e verificação frontend aprovados. Três cenários concorrentes PostgreSQL aprovados: excesso de facturação, mesma validação e facturas complementares. Duas ligações em processos PHP independentes, observadas simultaneamente à espera de bloqueios, por cenário. Saldos, consumo e número de facturas validadas confirmados. Base temporária eliminada. São testes de serviço, não HTTP ou carga. Evidência.

Migração 000010 aplicada no lote 11 após backup custom PostgreSQL de 216.008 bytes e restauro verificado de 39 tabelas numa base temporária, depois eliminada. Dump e manifesto partilharam um snapshot consistente. Registos de negócio, restrições anteriores e .env preservados. Novas tabelas de facturas, linhas e consumos vazias; sem seeds, contas novas ou alteração de credenciais. Backup e manifesto privados, fora do Git. Evidência sem dados privados.

Limitações e próximo passo

Pagamentos, dados bancários com dupla validação, reforços, notas de crédito, anexos de factura, adiantamentos, compras sem ordem e operações cambiais não estão implementados. Facturas entre exercícios ou sem compromisso ficam bloqueadas. Conferência alterada por outra factura bloqueia a validação; ainda não existe correcção/substituição do registo pendente.

Nova tentativa de acesso ao navegador: The browser access host is unavailable. Revisão visual pública, autenticada e de impressão continua pendente. Não constitui validação operacional integral do orçamento nem autorização de compras/pagamentos reais. Próximo passo: dados bancários com dupla validação, antes de pagamentos; reforços e regras de investimento configuráveis por empresa. Equipamento continua bloqueado para adjudicação/emissão sem regra própria.

Aplicação e validação PostgreSQL do orçamento

• Migração 000009 aplicada à base actual no lote 10, sem migrações pendentes. Backup custom PostgreSQL 17 de 206.615 bytes em armazenamento privado; manifesto privado com hashes e instruções de recuperação. O dump e o manifesto partilharam um snapshot consistente. Restauro verificado em base temporária: 37 tabelas coincidiram em contagens e hashes. Base de restauro eliminada.
• Registos de negócio anteriores e restrições preservados; .env inalterado. Nenhuma conta, dotação ou movimento financeiro foi criado na base real. As tabelas budgets e budget_entries permanecem vazias. Sessões, caches e filas não integram a comparação de negócio, pois podem variar com os acessos. Evidência sem dados privados.
• Cinco cenários concorrentes PostgreSQL aprovados: excesso de reservas, mesma reserva, mesmo compromisso, mesma libertação e excesso na adjudicação. Duas transacções de serviço em processos PHP e ligações independentes por cenário, observadas simultaneamente à espera de bloqueios. Saldos exactos e ausência de duplicações confirmados. Base exclusiva de teste eliminada. Isto não é teste HTTP, de carga ou de todos os fluxos financeiros. Evidência.
• Reforçada a autorização no serviço: autor autenticado, empresa do processo, transacção obrigatória e bloqueio da empresa. Dotação já aprovada não admite reescrita nem eliminação pelo modelo. Corrigida a legenda da dotação para respeitar a base com/sem IVA escolhida pela empresa.
• 14 testes de orçamento aprovados, 40 asserções, incluindo submissão real sem saldo e rollback, submissão/reserva seguida de rejeição/libertação, isolamento no serviço e imutabilidade da dotação aprovada.
• Suite completa concluída: 275 aprovados, 3 ignorados e 2.364 asserções; inclui os 13 casos de orçamento existentes no início dessa execução. O caso adicional de imutabilidade foi validado depois no conjunto de 14 acima. PHPStan, Pint, TypeScript, compilação e formatação/lint frontend aprovados.
• / e /consulta/equipamentos responderam HTTP 200; /orcamentos sem sessão respondeu 302 para login. Nova tentativa de acesso ao navegador devolveu The browser access host is unavailable. Revisão visual pública, autenticada e de impressão permanece pendente.

Cada empresa mantém dotações e base de IVA próprias; não existem valores monetários de orçamento comuns a todos os clientes. Centros sem dotação continuam no circuito de desenvolvimento sem controlo orçamental. Facturas, consumo validado, reforços, pagamentos e regras próprias de investimento não estão implementados. A validação operacional integral do orçamento permanece pendente, embora as reservas e compromissos tenham sido testados e a migração esteja aplicada.

Histórico do primeiro incremento de orçamento

Primeiro incremento de orçamento por empresa

Implementados cadastro de dotação anual por empresa/centro de custo, montantes explícitos em centavos MZN e escolha obrigatória da base com/sem IVA. Preparação e aprovação por pessoas distintas de Administração/Finanças. Sem valores de dotação predefinidos. A configuração pertence exclusivamente à empresa actual.

Reservas na submissão, ajuste na adjudicação, libertação na rejeição e conversão em compromisso na emissão reutilizam a transacção e o bloqueio por empresa. Movimentos imutáveis, idempotência por processo/operação e auditoria transaccional. Dotação pendente ou insuficiente bloqueia operações no centro/exercício configurado. Centros sem dotação preservam o fluxo anterior de desenvolvimento, explicitamente sem controlo orçamental. Não há activação global implícita para todos os clientes. O snapshot mantém budget_checked=false, acrescentando a referência ao controlo efectuado; não constitui validação financeira completa ou autorização de compra real.

Interface em /orcamentos, restrita a Administração e Finanças. Não existem reforços, edição de dotações, facturas, pagamentos ou migração financeira de processos anteriores. Os limites de investimento continuam por definir por empresa; equipamentos permanecem bloqueados para adjudicação/emissão.

Migração aditiva 000009 preparada e testada apenas em SQLite isolado; não aplicada à base real. Exige backup/restauro verificado antes da aplicação. Não foram alteradas contas, configurações, credenciais ou dados de negócio. Dez testes novos passaram, com 27 asserções; PHPStan e TypeScript aprovados. Revisão visual e concorrência PostgreSQL deste módulo continuam pendentes. O orçamento continua sem validação operacional.

Validação das pendências após consolidação

Recolhido o resultado final da nova execução dirigida: 87 testes aprovados, 1.163 asserções, abrangendo equipamentos/peças, adjudicação/ordens e navegação. Não substitui o resultado da suite completa consolidada de 262 aprovados e 3 ignorados. Onze migrações confirmadas aplicadas, sem pendentes. Seis entradas públicas responderam HTTP 200; quatro rotas protegidas responderam 302 para login.

O acesso ao navegador continua indisponível (The browser access host is unavailable). A revisão visual pública, autenticada e de impressão não foi concluída. O utilizador confirmou que as regras financeiras estão por definir. Foi preparada uma proposta de regras para decisão empresarial, sem activar orçamento, facturas ou desbloquear investimentos. O orçamento continua sem validação. Corrigido o mapa de compatibilidade que ainda descrevia equipamentos como não iniciados.

Revisão e consolidação — 28 de Outubro de 2026

• Recolhido o resultado final da execução da suite: 262 testes aprovados, 3 ignorados e 2.327 asserções, em 71,928 segundos. Os testes usam SQLite em memória; esta revisão não repetiu os ensaios PostgreSQL históricos.
• PHPStan e Pint aprovados. TypeScript e compilação de produção aprovados. Corrigida a formatação da evidência JSON da migração 000008.
• Confirmada no código a marca Sistema de Gestão de Compras (SGC) na página inicial e SGC no logótipo, demonstração, painel, títulos e impressão. A configuração existente e o cookie de sessão foram preservados.
• Revistos os diffs da integração e os controlos de perfis, isolamento, validação técnica, recepção e movimentos. Actualizados README e continuidade para distinguir funcionalidades entregues de instruções históricas.
• Revisão visual não concluída: o controlo do computador foi interrompido porque não conseguiu determinar com confiança o URL actual do navegador. Não foi validado o aspecto dos ecrãs públicos, autenticados ou da impressão. A compilação e os testes não substituem essa revisão.

Incremento de equipamentos e peças — 28 de Outubro de 2026

Implementado no mesmo projecto C:\laragon\www\compras, porta 8015, após consulta de procurement.docx (2.2, 2.3, 3.0, RF-AF-07/08, RNF-17/18, 6.6 e decisões de 10.0), documentação e módulos existentes. Preservadas as alterações locais, incluindo a actualização paralela da marca visível para SGC. Não foram alterados outros projectos nem recriadas contas.

Entregue

• /equipamentos: cadastro de código, descrição, área/linha, departamento, série, estado, criticidade e artigo de stock opcional. Fichas de equipamento e peças podem ser actualizadas com versão obrigatória para impedir sobrescrita de uma ficha entretanto alterada. Cada criação/alteração gera auditoria com antes/depois. Não há eliminação pela interface.
• Criticidade configurada explicitamente por Administração: código, nome, critério escrito e indicação expressa de ser crítica ou não. Sem categorias, critérios, escalões ou valores de mínimo predefinidos. Os critérios são de acréscimo; criar outra categoria preserva o significado da anterior. Esta configuração não altera limites financeiros ou regras de aprovação. RF-AF-08 não foi dispensado: não foi disponibilizada edição de limites financeiros sem dupla aprovação administrativa.
• Cada peça reutiliza exactamente um artigo de stock, sem saldo separado. Referência, descrição e unidade vêm desse artigo; o artigo de uma peça existente não pode ser substituído. Mínimo explícito em milésimos, incluindo zero, e alerta visual quando a soma dos movimentos desse artigo nos armazéns da empresa fica abaixo do mínimo. Não é um mínimo por máquina/armazém. Estar abaixo do mínimo alerta, sem inventar uma proibição de consumo.
• Associações peça/equipamento dentro da empresa, permitindo a mesma peça em várias máquinas sem duplicar existências. Associações são de acréscimo e únicas por par; não há remoção destrutiva. Administração, Procurement e Armazém mantêm o cadastro; só Administração define categorias. Finanças consulta; chefes consultam os equipamentos, associações e saídas do seu departamento. As opções de requisição também respeitam o departamento. Só Armazém continua a executar movimentos.
• Nas saídas de artigos cadastrados como peça, o servidor exige equipamento de destino associado. A operação e o movimento guardam identificadores e snapshots de equipamento/peça no momento da saída. Alterar depois nome, mínimo ou criticidade não reescreve o movimento. Para outros artigos, equipamento de destino é opcional. Operações anteriores mantêm associações nulas, sem atribuições retroactivas inventadas.
• Requisições distinguem equipment e spare_part. Equipamento novo exige área/linha de produção. Peça exige cadastro, equipamento associado do departamento e unidade igual à do artigo. Peça crítica urgente exige início da paragem, registado explicitamente em UTC. Continua o circuito normal de três cotações; não foi criada dispensa automática por urgência.
• Validação técnica de equipamento na versão do rascunho, pelo responsável da área representado pelo perfil Chefe do departamento, distinto do solicitante. Aprovar ou rejeitar exige fundamento e fica num registo imutável, com hash da base, autor e snapshot. Pedido alterado invalida o aproveitamento da decisão, sem a apagar; formulário de decisão sobre versão antiga é recusado. Confirma-se novamente a elegibilidade e conflitos do revisor antes da submissão e das aprovações. Uma rejeição não permite submeter. Finanças integra o ciclo de aprovação de equipamento para qualquer valor, além dos escalões existentes. A validação técnica não substitui a aprovação financeira.
• Adjudicação e emissão de equipamento continuam bloqueadas porque o limite próprio de investimento e a sua regra de aplicação não foram definidos pela empresa. Não se inventou um valor nem se interpretou um limite indefinido como tecto ou autorização irrestrita. Nem validação técnica nem aprovação de Finanças removem este impedimento. As mensagens e ecrãs explicam o motivo.
• Peças com associações válidas seguem os escalões normais e o fluxo existente de cotações, adjudicação e ordens. A ordem congela os destinos e contexto de peça/equipamento; a recepção exige o artigo de stock autorizado e transmite os identificadores aos movimentos. A recepção não consome a peça na máquina: o consumo continua a exigir uma saída própria. O ensaio completo de compra, recepção e saída foi realizado apenas em fixtures isoladas.
• /consulta/equipamentos: equipamentos, peça crítica, alerta de mínimo, associações, histórico de saída e formulários fictícios de simulação. Não consulta nem grava dados de negócio. As novas opções de navegação preservam as entradas públicas e autenticadas anteriores.

Verificação e aplicação da migração

• 262 testes aprovados, 3 ignorados, 2.327 asserções na suite completa SQLite em memória. Inclui 28 casos de equipamentos/peças e um caso integrado adicional no conjunto de adjudicação/ordens: perfis, autoria, isolamento, associações, critérios/mínimos explícitos, versões, rastreabilidade congelada, validação técnica, rejeição, alteração de base, Finanças em qualquer valor, investimento bloqueado, início de paragem, rollback de auditoria e recepção/saída de peças.
• PHPStan, Pint, TypeScript e compilação de produção aprovados. Formatação/lint frontend e git diff --check verificados no fecho. Os resultados anteriores de outras entregas permanecem como histórico abaixo.
• Sete cenários simultâneos PostgreSQL isolados aprovados, incluindo o novo spare_part_issue: duas saídas para o equipamento associado disputam o saldo; uma confirma e outra é recusada por falta de stock. Os seis cenários anteriores também passaram com o novo esquema. Duas ligações independentes foram observadas simultaneamente à espera de bloqueio por cenário. A base temporária foi eliminada. Não é teste de carga nem validação de concorrência de todas as alterações do cadastro/decisões técnicas. Evidência actualizada.
• Migração 2026_10_28_000008_create_equipment_and_spare_parts aplicada à base actual compras_dev, lote 9. Todas as onze migrações executadas, sem pendentes. SQL revisto: apenas cria cinco tabelas novas e acrescenta colunas opcionais e chaves estrangeiras às tabelas existentes; não elimina, recria ou converte dados anteriores. down() recusa reversão destrutiva para preservar associações e decisões.
• Antes da aplicação: backup custom PostgreSQL 17 em storage/app/private/backups/equipment-000008-20261028-113652-8b46ef/, 177.950 bytes, SHA-256 3ff9f9a0f16975465ff008ff6ffaf34d9798d36e37fa946e44c6de39e62d6fdb. Dump consistente, manifesto privado com hashes/contagens, cópia de ambiente e RECUPERACAO.txt. Restaurado com sucesso numa base nova compras_restore_check_*; as 32 tabelas coincidiram em contagens e hashes. Base de verificação eliminada. Não havia documentos de fornecedor para copiar. O backup é privado, fora de public/ e do Git; não publicar o seu conteúdo.
• Comparação imediatamente antes/depois da migração: todos os registos e colunas anteriores das 32 tabelas, e todas as restrições anteriores do esquema público, preservados. Mantêm-se 1 utilizador, 1 empresa, 1 departamento, 1 centro de custo e 1 registo de auditoria. A única nova linha foi a migração. As cinco tabelas novas e os movimentos/operações de stock permanecem vazios. Sem seeds ou movimentos fictícios na base real. Evidência sem credenciais.
• .env inalterado, SHA-256 C9EE71EDBF3B4D303203DC851B9A15A9B687DEA1E83DD06B7B04B23054CA5BC5. Conta, credenciais, configurações e porta preservadas. Os acessos HTTP normais podem criar/actualizar sessões; não são movimentos de negócio.
• /consulta/equipamentos respondeu HTTP 200; /equipamentos sem sessão redireccionou para login (302). Revisão visual pública e autenticada continuam pendentes: nova descoberta do navegador devolveu The browser access host is unavailable. Não foi possível inspeccionar a sessão existente nem validar visualmente os ecrãs. Testes HTTP/Inertia e compilação não são apresentados como revisão visual.

Limitações e decisões ainda necessárias

O orçamento ainda não é validado; os documentos de desenvolvimento não autorizam compras reais. O limite próprio de investimento, a sua aplicação e eventuais escalões/documentos próprios para peças críticas precisam de decisão empresarial antes de desbloquear os caminhos correspondentes. Não há configuração fictícia de limite com semântica presumida. Regras de urgência/fornecedor único em escalão superior continuam sem excepção implementada; pedidos urgentes não dispensam os controlos normais.

Os critérios e mínimos têm de ser registados pelos perfis autorizados com base nas decisões da empresa. Não há classificação automática por texto ou correspondência automática de descrições de compras a artigos; a associação é explícita. O cadastro não cria entradas de stock, não capitaliza activos e não comprova a aquisição de um equipamento existente. Não há remoção/revisão de compatibilidades, reconciliação automática do legado, manutenção preventiva, notificações externas de mínimo, configuração de períodos de reposição/consumo anómalo ou relatório completo dos indicadores financeiros/paragens de 6.6. O alerta de mínimo é consultado no ecrã de equipamentos. Não foi acrescentada uma separação entre revisor técnico e aprovador departamental que a especificação não exige; mantêm-se a exclusão do solicitante e a segregação entre pessoas nas etapas financeiras existentes.

Actualização da marca — 28 de Outubro de 2026

Nome visível actualizado para Sistema de Gestão de Compras (SGC) no início, entrada, navegação, demonstração, títulos e impressão. A documentação foi alinhada. Preservados os identificadores técnicos, incluindo procuraflow_session, a conta, porta 8015, base de dados, APP_KEY e .env. Esta alteração não aplica migrações nem modifica dados de negócio. Revisão visual continua pendente.

Verificação desta correcção: 13 testes dirigidos aprovados, 185 asserções; frontend sem erros de lint, TypeScript e compilação aprovados; git diff --check aprovado. Pesquisa das fontes e documentação não encontrou a marca antiga em textos visíveis; só permanece o identificador técnico de sessão. SHA-256 do .env inalterado.

Fecho da entrega de stock: migração aplicada — 28 de Outubro de 2026

A migração 2026_10_28_000007_create_stock_operations foi aplicada à base actual compras_dev, lote 8, após autorização expressa para concluir a entrega. migrate:status confirma todas as dez migrações executadas, sem pendentes. Não se avançou para equipamentos. As alterações locais sem commit foram preservadas.

• Revisão do PHP, do SQL de migrate --pretend e do esquema real: cria apenas a nova tabela stock_operations; acrescenta stock_operation_id opcional e respectivas restrições; torna opcional goods_receipt_item_id. No PostgreSQL, quantity_milli já era bigint assinado e permanece desse tipo, sem conversão estreitante. As cláusulas geradas de remoção de default/identity/comentário para essas duas colunas não removem metadados existentes: ambos já eram nulos/ausentes. A chave primária e a sua sequência não são alteradas. Todas as chaves estrangeiras e a unicidade da linha de recepção foram confirmadas após a aplicação. Não houve DROP/TRUNCATE/DELETE de tabelas ou registos existentes, nem recriação de tabelas. A restrição NOT NULL da recepção é relaxada para permitir os novos movimentos. A reversão down() continua bloqueada para preservar histórico.
• Backup recuperável preparado e ensaiado antes da aplicação, em storage/app/private/backups/stock-000007-20261028-111943-4deef2/. database.dump, formato custom PostgreSQL 17, 169.365 bytes; SHA-256 5df038437e94870e80d1fab61e7d53223043b4167ded71eb52703db1c4d47942. O dump usa um snapshot exportado consistente. A pasta privada contém também manifest.json, cópia do ambiente original e RECUPERACAO.txt; está excluída do Git e fora de public/. Não publicar o seu conteúdo. Não existiam documentos de fornecedor para copiar.
• O dump foi restaurado com pg_restore --exit-on-error numa base nova e exclusiva compras_restore_check_*. Contagens e hashes SHA-256 dos registos das 31 tabelas coincidiram com a origem. A base de verificação foi eliminada; nenhuma restauração foi executada sobre a base actual. O dump inclui esquema, dados, sequências e ownership/ACL; as roles globais são as existentes no servidor. As instruções locais explicam a recuperação numa base nova, sem --clean e sem reversão destrutiva da base actual.
• Imediatamente antes e depois da migração, comparação de todas as linhas e colunas anteriores das 31 tabelas: preservação integral, incluindo utilizador, credenciais, empresa, equipa, auditoria, sessões e configuração persistida. A única linha adicional nesse momento foi o registo da migração, passando de 9 para 10. Mantiveram-se 1 utilizador, 1 empresa, 1 departamento, 1 centro de custo e 1 entrada de auditoria. Requisições, fornecedores, ordens, recepções, artigos e armazéns mantiveram zero registos; stock_movements e a nova stock_operations continuam com zero movimentos/operações. Não houve seeds ou dados fictícios. Os acessos HTTP subsequentes podem criar/actualizar sessões normais; não são movimentos de negócio.
• .env original inalterado, SHA-256 C9EE71EDBF3B4D303203DC851B9A15A9B687DEA1E83DD06B7B04B23054CA5BC5. Não se alteraram contas, credenciais, porta 8015 ou outros projectos. A aplicação usou apenas a migração 000007, com limites de espera de bloqueio e execução no processo de manutenção.
• /consulta/operacoes-stock respondeu HTTP 200. A rota operacional mantém redireccionamento para login quando não há sessão no cliente HTTP. Revisão visual pública e autenticada continuam pendentes: nesta tentativa, a descoberta do navegador devolveu The browser access host is unavailable, sem acesso às abas ou à sessão autenticada. Não foi apresentada a resposta HTTP como revisão visual. Não se efectuou login nem se alteraram credenciais.

Evidência sem credenciais em stock-migracao-000007.json. O manifesto privado conserva os hashes e contagens por tabela. Os resultados anteriores de 233 testes, análise estática e seis cenários PostgreSQL continuam documentados abaixo; não foram repetidos nesta aplicação, que não alterou código funcional. A entrega está disponível no esquema actual, sujeita às permissões existentes; a aceitação visual permanece pendente.

O orçamento continua sem validação. Permanecem por decidir periodicidade, tolerâncias, investigação/resolução de divergências e eventual aprovação de ajustes. Equipamentos não foram iniciados.

Implementação de saídas, transferências e inventários — 28 de Outubro de 2026

Consultadas as secções 2.2, 4.0, RF-AF-11, 5.3, RNF-18 e decisões da secção 10.0 de procurement.docx, README, compatibilidade e orientações de continuidade. Implementação no mesmo Laravel, porta 8015, sobre o catálogo, armazéns, movimentos e auditoria existentes. As alterações locais anteriores permanecem sem commit; recepção não foi reimplementada. As secções seguintes conservam o histórico das entregas anteriores.

• /stock/operacoes: saídas com destino, responsável da mesma empresa, documento único e fundamento obrigatório; transferências entre armazéns distintos da mesma empresa com débito e crédito atómicos. O saldo continua a ser a soma exacta dos movimentos em milésimos, agora com sinais. A listagem de stock apresenta os sinais, referências e ligações adequados para todos os movimentos.
• Inventários por artigo/armazém: contagem física, incluindo zero, saldo teórico, versão do histórico e diferença preservados. A contagem não altera existências. Um ajuste separado exige fundamento e contagem compatível ainda não ajustada, e lança exactamente a diferença. Divergência zero não gera movimento. Movimentos posteriores, incluindo recepções, invalidam a contagem para ajuste; o operador deve actualizar e repetir a contagem física. Formulários de contagem sobre uma versão antiga também são recusados.
• Apenas Recepção / Armazém executa estas operações, conforme a especificação; Administração, Procurement e Finanças consultam na própria empresa. Administração não substitui o perfil operacional. Autor real e responsável indicado ficam separados no snapshot. Não foi criada aprovação por Finanças, dupla contagem obrigatória ou proibição de o operador ser responsável: essas regras não constam da especificação para estes movimentos. As segregações de requisição/aprovação, emissão/recepção e recepção/pagamento dos módulos existentes mantêm-se.
• Bloqueio inicial da empresa partilhado com recepções, transacção única, unicidade de referência por empresa, chave idempotente com comparação de conteúdo e unicidade da contagem ajustada. Repetições idênticas devolvem o mesmo registo; referência repetida com nova chave ou chave com conteúdo diferente são recusadas. Falhar o crédito da transferência ou a auditoria reverte também o débito e a operação. Os modelos impedem edição/eliminação do histórico; SQL administrativo continua dependente das permissões da base.
• Migração aditiva 2026_10_28_000007_create_stock_operations: nova tabela de operações, ligação opcional ao movimento, recepção opcional para novos tipos e quantidades assinadas. Conserva linhas existentes e as restrições de unicidade de recepção. Inicialmente testada apenas em bases isoladas; aplicada posteriormente à base actual, lote 8, após backup com recuperação ensaiada, conforme o fecho acima. A reversão destrutiva é explicitamente bloqueada para não converter movimentos negativos em quantidades sem sinal.
• /consulta/operacoes-stock: exemplos fictícios de saída, transferência, contagem e ajuste, formulário com alternância entre operações e simulação sem escrita ou leitura de negócio. Reutiliza a interface operacional. Ligação nos menus de armazém e na listagem de stock.

Verificação efectuada neste incremento

• Suite completa: 233 testes aprovados, 3 ignorados, 2.163 asserções, SQLite em memória. Os 25 testes novos cobrem quantidades exactas, falta de saldo, idempotência incluindo formulários, referências repetidas, transferências, ajustes positivos/negativos/zero, contagens desactualizadas, perfis, recursos e consultas entre empresas, imutabilidade, demonstração e rollback de auditoria e da segunda metade da transferência.
• PHPStan, Pint e TypeScript aprovados; compilação de produção aprovada. npm run check aprovado em todos os ficheiros verificados, sem avisos ou erros; git diff --check sem erros. A formatação da evidência anterior de recepção foi normalizada, preservando o seu conteúdo.
• Seis cenários simultâneos em PostgreSQL isolado aprovados: excesso de saídas, mesma saída, mesma transferência, transferências opostas, mesmo ajuste e contagem desactualizada. Dois processos PHP independentes por cenário executam o kernel HTTP com duas ligações observadas simultaneamente à espera de bloqueio. Validam saldos e integridade das duas pernas das transferências. Isto não é teste de carga ou ensaio TCP. Evidência: stock-concorrencia-postgresql.json; execução: php tests/Concurrency/run-stock.php.
• O ensaio reutiliza fixtures protegidas pelo prefixo compras_receipts_test_*, verifica a base e o alias de esquema antes de migrar, cria uma base exclusiva e elimina-a no final. A primeira tentativa revelou interferência entre dois aliases do processo de preparação; foi cancelada apenas a consulta nessa base temporária, que foi eliminada. A preparação usa agora um único alias, mantendo processos independentes para a concorrência. Outra tentativa identificou reutilização indevida da chave da contagem na fixture de ajuste; corrigida antes da execução aprovada. Nenhum destes resultados incompletos é apresentado como aprovação.
• HTTP 200 em http://127.0.0.1:8015/consulta/operacoes-stock. Testes Inertia confirmam propriedades públicas sem identidade nem dados de negócio. Revisão visual pública não concluída: a skill computer-use foi tentada, mas o serviço interrompeu o controlo por não conseguir determinar o URL do navegador com confiança. Revisão visual autenticada continua separadamente pendente; não foram pedidas nem alteradas credenciais.
• Sem seeds, migrações ou fixtures na base real. Contagem de utilizadores reais inalterada durante o ensaio. .env conserva SHA-256 C9EE71EDBF3B4D303203DC851B9A15A9B687DEA1E83DD06B7B04B23054CA5BC5; conta, configuração e outros projectos preservados.

Limitações e decisões necessárias

O orçamento ainda não é validado. A interface mantém o aviso de desenvolvimento, sem autorizar compras reais. A migração 000007 já está aplicada; a revisão visual autenticada permanece pendente.

A empresa deve definir periodicidade de inventários, tolerâncias, quem investiga e resolve divergências e eventual circuito de aprovação dos ajustes. O ajuste aqui regista uma correcção fundamentada por Armazém; não equivale a aprovação financeira nem ao encerramento de uma investigação. Todas as diferenças são mostradas sem tolerância presumida. Não há aprovação automática por escalão, alertas de consumo anómalo com limites inventados, mínimos, reposição, equipamento/peça associado, conversões, devoluções, cancelamento ou edição de movimentos. O destino da saída é texto obrigatório; não valida uma requisição/equipamento nem substitui os futuros alertas RNF-18 para saídas sem essas ligações. Inventários são contagens pontuais por artigo/local, sem sessões de contagem em lote ou congelamento do armazém. Referências distintas e chaves distintas representam operações distintas; não há deduplicação heurística de documentos externos. Bloqueios serializam escritas por empresa; desempenho e carga não foram medidos.

Incremento actual: recepção, stock e navegação

Implementado em 28 de Outubro de 2026, consultando procurement.docx, o mapa de compatibilidade e as orientações de continuidade. Os incrementos anteriores abaixo ficam como registo histórico; os seus números de testes e pendências descrevem a data respectiva.

• Página inicial própria em /, com acesso à demonstração e à entrada. A navegação autenticada está agrupada por área e perfil. A consulta pública passou a ter endereços por módulo, incluindo /consulta/recepcoes e /consulta/stock, preservando a página ao actualizar e navegar para trás. Os exemplos são fictícios, sem consultas a dados de negócio ou gravações.
• Recepções parciais e totais de ordens emitidas, quantidades recebidas, aceites, rejeitadas e pendentes por linha. Conferência conforme, com reservas ou não conforme; divergências exigem fundamento. O estado é derivado das recepções, sem reescrever a ordem congelada.
• Apenas Armazém confirma; o emitente da ordem fica impedido mesmo após mudar de perfil. ConflictGuard revalida a participação e os intervenientes anteriores. Consultas respeitam empresa, perfil e, para chefes, departamento; o formulário de Armazém não expõe os valores financeiros da ordem.
• Quantidades exactas em milésimos, sem aritmética de ponto flutuante. O recebido acumulado, incluindo rejeitados, não ultrapassa a quantidade autorizada. Uma rejeição não autoriza automaticamente uma substituição: esta política permanece por definir. O ecrã distingue falta de entrega de falta de aceitação.
• Catálogo de artigos e armazéns por empresa. Só as quantidades físicas aceites originam entradas, com unidade compatível e ligação única à linha da recepção. Serviços não movimentam stock. Existências calculadas a partir dos movimentos, com pesquisa e histórico.
• Transacções, bloqueios, chave de confirmação e unicidade da guia por ordem evitam duplicações. Repetir uma confirmação idêntica devolve o registo existente; alterar o conteúdo da mesma chave é bloqueado. Falhar a auditoria reverte toda a operação. Não existem rotas de edição/eliminação do histórico; os modelos também recusam essas alterações. A protecção contra SQL administrativo directo depende das permissões da base de dados.
• A migração aditiva 2026_10_28_000006_create_receipts_and_stock está aplicada. Conta, configuração e módulos anteriores preservados; .env mantém o SHA-256 C9EE71EDBF3B4D303203DC851B9A15A9B687DEA1E83DD06B7B04B23054CA5BC5. Não foram executados seeds na base real, recriadas contas ou alterados SGF Tempo/Investmoz.

Resultados verificados

• Suite Laravel: 208 passaram, 3 ignorados, 2.038 asserções, em SQLite em memória. Inclui permissões, isolamento, segregação, limites, qualidade, repetição, auditoria e navegação pública.
• PHPStan sem erros; Pint, verificação/formatação frontend, TypeScript e compilação aprovados. /, /consulta/recepcoes e /consulta/stock responderam HTTP 200 na porta 8015.
• Quatro cenários de concorrência real PostgreSQL passaram: excesso acumulado, repetição da mesma confirmação, quantidades complementares e guia repetida. Processos PHP independentes executaram pedidos pelo kernel HTTP Laravel, com duas ligações simultaneamente à espera de bloqueio em cada cenário. Não se trata de teste de carga TCP. Evidência: recepcao-concorrencia-postgresql.json.
• A base temporária foi criada com nome exclusivo compras_receipts_test_*, verificada antes das migrações e eliminada no final. Fixtures recusam bases de negócio. Uma primeira execução detectou uma ligação Schema em cache e falhou por tabela já existente; o isolamento foi corrigido para ambas as ligações e verificado antes de migrar, sem recriar tabelas existentes. A contagem de utilizadores reais permaneceu igual.

Limitações e próximo passo

O orçamento ainda não é validado. Ordens e recepções continuam identificadas como desenvolvimento e não autorizam compras reais.

Revisão visual pública, autenticada e de impressão continua pendente: o serviço de controlo do navegador está indisponível. Os quatro cenários de concorrência de recepção foram efectivamente realizados; concorrência dos outros módulos e testes de carga permanecem pendentes.

Não foram implementados saídas, transferências, inventários, mínimos, devoluções/substituições, conversões de unidade ou anexos da recepção. Equipamentos e peças continuam dependentes das regras técnicas aprovadas. Próximo incremento funcional: orçamento e facturas, após definição das respectivas regras; completar os controlos de stock conforme prioridade da empresa. Não foram inventadas tolerâncias, excepções ou autorizações de substituição.

Incremento actual de adjudicação e ordens de compra

Implementado em 28 de Outubro de 2026 no projecto Laravel existente, segundo a secção «Próximo incremento após RF-AF-01» das orientações. O RF-AF-01, os fornecedores e os documentos privados foram reutilizados e preservados. Não foram recriadas contas, executados seeds ou alterados o SGF Tempo, o Investmoz ou a configuração local.

Selecção e revalidação

• Procurement regista a adjudicação a partir da página de comparação de cotações. Exige justificação escrita e data/local de entrega. O solicitante não selecciona a sua própria compra; Administração consulta, sem substituir os perfis operacionais.
• ProposalComparison unifica a matriz da interface e a decisão no servidor. Recalcula preços, prazos e notas com aritmética racional; arredonda a pontuação final a duas casas decimais. Quantidades, preços e IVA são verificados em precisão decimal e centavos. Linhas devem corresponder à requisição, e os totais têm de conferir com as linhas. A entrega suporta apenas MZN.
• Requer três fornecedores distintos com propostas elegíveis, válidas e comparáveis; cada proposta elegível precisa de duas avaliações elegíveis. Os avaliadores têm de continuar na mesma empresa e num perfil operacional permitido, respeitar o departamento quando são chefes, ser distintos e não ser o solicitante. Uma declaração de ausência não substitui a verificação de conflitos.
• Escolha limitada ao topo da pontuação. Empates permitem seleccionar uma das propostas empatadas, sempre com fundamento escrito. Dispensa de cotações, escolha abaixo do topo e outros caminhos de excepção permanecem bloqueados sem política aprovada; parâmetros enviados pelo navegador não dispensam estas regras.
• Cada operação decisiva revalida o ConflictGuard, incluindo solicitante, aprovadores, autores de cotações, avaliadores e agora autor/aprovadores da adjudicação. Novas declarações continuam a bloquear operações sem apagar o histórico.
• A selecção fecha o registo de novas propostas e avaliações desse processo. A matriz de decisão e a sua impressão digital são guardadas. Alterações aos valores, avaliações, ponderações ou elegibilidade da matriz impedem a utilização das aprovações para emitir sobre uma base diferente.

Escalões e ciclo de aprovação do valor final

• Os limites e a base com/sem IVA vêm do snapshot guardado na requisição; não se substituem pela configuração actual da empresa. Processos sem snapshot válido ou histórico completo de aprovação da estimativa são bloqueados.
• A adjudicação abre explicitamente um novo ciclo de aprovações para o valor final, mesmo quando fica no mesmo escalão. As decisões da estimativa são preservadas e não são reaproveitadas. O topo do primeiro escalão é inclusivo, tal como o segundo; ultrapassagens acrescentam Procurement e Finanças, conforme as regras guardadas.
• As etapas são sequenciais. Solicitante e autor da adjudicação não aprovam o ciclo; cada etapa é decidida por uma pessoa distinta. A rejeição exige fundamento. Antes de emitir, verifica-se novamente se os aprovadores finais continuam elegíveis e sem conflito.
• Equipamento e peças com tipos ainda não suportados são bloqueados, sem presumir aprovação técnica ou limites próprios. Não existem excepções automáticas para urgência, fornecedor único ou valores acima de limites sem política definida.

Ordem emitida e consulta

• Ordem única por requisição e adjudicação, com referências OC-ANO-ID, transacção e unicidade na base de dados. Repetir a emissão devolve a ordem existente sem novas linhas, novo número, nova auditoria ou alteração dos dados congelados. Podem existir intervalos na sequência de identificadores.
• A ordem congela na emissão linhas, quantidades/unidades, preços, IVA, totais, moeda, fornecedor/contactos, empresa, departamento, centro de custo, referência/condições da proposta, entrega, fundamento, emitente, matriz revalidada e aprovações. A matriz guardada na adjudicação continua separada como histórico da escolha. Alterações posteriores às fichas e propostas não reescrevem a ordem.
• Listagem, detalhe, emitente, histórico e versão HTML para impressão ou gravação em PDF pelo navegador. A impressão escapa o conteúdo fornecido pelos utilizadores. Não há geração de PDF no servidor ou envio por email.
• Administração, Procurement e Finanças consultam na própria empresa; chefes apenas processos do seu departamento. Solicitantes e armazém não recebem acesso aos documentos financeiros nesta etapa.
• Todas as ordens exibem Documento de desenvolvimento. Não autoriza compras reais. O snapshot guarda development_only=true e budget_checked=false. O orçamento ainda não é verificado, tanto na interface como na impressão. Não foram criadas ordens reais neste incremento.
• Falhar a auditoria reverte a adjudicação e as suas etapas, ou a emissão e as suas linhas. Os modelos das ordens e linhas impedem edição/eliminação; a protecção contra SQL administrativo continua dependente das permissões operacionais.

Verificação e preservação

• Suite completa Laravel: 165 passaram, 3 ignorados, 1.662 asserções. Os 46 testes específicos de adjudicação/ordens passaram; a suite inclui também os testes anteriores de RF-AF-01/fornecedores/anexos e os três testes de pré-visualização pública acrescentados em paralelo. Os testes usam SQLite em memória, não a base de negócio.
• Cobertura: acesso por perfil e departamento; isolamento de empresas; valores/IVA e quantidades fraccionárias; fronteiras de 25.000 e 150.000 MZN; base com/sem IVA guardada; novo ciclo de aprovação; empates; excepções bloqueadas; conflitos/suspensão/expiração após avaliação ou selecção; elegibilidade de avaliadores/aprovadores; integridade das linhas; prevenção de repetição com unicidade/idempotência; snapshots; impressão com escape de HTML; rollback se falhar a auditoria.
• PHPStan aprovado, sem erros; Pint aprovado em todos os ficheiros PHP; verificação frontend sem avisos ou erros; TypeScript aprovado; compilação aprovada; git diff --check sem erros.
• Migração aditiva 2026_10_28_000005_create_purchase_awards_and_orders aplicada no PostgreSQL local após os testes. Contagens antes/depois iguais: 1 utilizador, 1 empresa e 0 requisições, fornecedores, cotações, avaliações, documentos e declarações de conflito. Novas tabelas de adjudicações, aprovações finais, ordens e linhas vazias. Não foram criados registos sintéticos na base real.
• O SHA-256 do .env manteve-se igual antes e depois. Não houve seeds, alterações de credenciais ou configuração, nem reinicialização de dados.
• As rotas de ordens/adjudicação estão registadas. O acesso sem autenticação a /ordens redireccionou para a entrada SGC em 8015, com HTTP 200. As páginas autenticadas e o conteúdo da impressão foram verificados em testes HTTP/Inertia, não visualmente.

Foram detectadas alterações paralelas na pré-visualização pública, na entrada e nas respectivas rotas/testes; foram preservadas e incluídas na verificação final, sem as apresentar como parte desta implementação. As alterações funcionais deste incremento permanecem limitadas à adjudicação/ordens e à integração necessária com os módulos anteriores.

Limitações e próximo passo

Revisão visual autenticada, revisão visual da impressão/PDF e concorrência real em PostgreSQL continuam pendentes. Não foram realizados testes de carga. O código usa bloqueio por empresa e bloqueios dos registos de comparação/fornecedores/utilizadores dentro da transacção; isso não constitui validação de concorrência real.

Ainda não existe cancelamento/reabertura de adjudicações, alteração da data de entrega depois da selecção ou substituição de uma ordem emitida. Se a base aprovada mudar, faltar elegibilidade ou a data de entrega passar, o sistema impede a emissão; não assume uma autorização de correcção. As políticas e o fluxo de revisão/cancelamento devem ser definidos antes de ampliar esses caminhos.

Permanecem pendentes orçamento, multimoeda, dados bancários com dupla validação, aprovações técnicas de equipamentos/peças e as políticas comerciais em aberto. Próximo incremento: recepção parcial e conferência de qualidade com segregação do emitente, seguido de equipamentos, peças e stock. Não avançar para compras ou pagamentos reais.

Ficheiros deste incremento

Migração 2026_10_28_000005; modelos PurchaseAward, PurchaseAwardApproval, PurchaseOrder, PurchaseOrderItem e trait de imutabilidade; serviços ProposalComparison e PurchaseWorkflow; controlador PurchaseController; integração em ConflictGuard e QuotationController; casts decimais de QuotationItem e ProposalEvaluation; rotas autenticadas e menu; tipos purchase.ts, páginas purchases/award, purchases/index, purchases/show, ligação da comparação e vista purchases/print.blade.php; testes PurchaseAwardOrderTest; documentação.

Entrega anterior RF-AF-01

Os registos abaixo conservam os resultados anteriores. A indicação de adjudicação e ordens como próximo passo nessas entregas fica substituída pelo incremento acima.

Incremento actual RF-AF-01 de 28 de Outubro de 2026

Implementado

Declarações pessoais de conflito de interesses na base Laravel e React existente, sem avançar para adjudicação ou ordens. Fornecedores, anexos privados, contas e configuração anteriores foram preservados. O SGF Tempo e o Investmoz não foram alterados.

• Interface em português em Conflitos de interesses, disponível para todos os perfis com empresa configurada. Cada utilizador declara exclusivamente em nome próprio. O servidor fixa autor, empresa e data/hora do registo.
• Âmbitos: fornecedor em todos os processos; processo independentemente do fornecedor; fornecedor num processo específico. São guardados fundamento, data de conhecimento da situação e data/hora de cada declaração ou correcção.
• Administração e Finanças consultam as declarações da sua empresa para controlo. Procurement, chefes, solicitantes e armazém consultam apenas as próprias. Nenhum perfil altera declarações alheias. As opções de fornecedores mostram só identificador e nome; as opções de processos respeitam a visibilidade do perfil e departamento.
• As correcções pessoais acrescentam um registo ligado ao anterior e à declaração inicial. Só corrigem fundamento e data de conhecimento; autor, empresa, âmbito e situação declarada não são alteráveis. Correcções de uma versão já corrigida são recusadas. O histórico completo é consultável e gera auditoria com antes/depois.
• Uma declaração de ausência não anula uma declaração de conflito, mesmo posterior ou noutro âmbito sobreposto. Não há caducidade, prazo anual ou autorização para retirada implementados. A data de conhecimento é descritiva e não adia o impedimento. Periodicidade, validade e levantamento dependem de decisão da empresa, sem valores presumidos.

Impedimentos no servidor

• A requisição sem fornecedor continua a poder ser criada, editada, submetida e aprovada quando há apenas conflito com um fornecedor ainda não associado. Um conflito pessoal específico do processo, já conhecido, impede a participação nesse processo.
• Ao associar um fornecedor através de uma cotação, o servidor verifica o operador actual, solicitante, aprovadores anteriores, autores de propostas, avaliadores anteriores e autores de acções de participação no histórico de auditoria. As verificações usam os utilizadores históricos, independentemente do perfil actual. O registo da própria declaração não é tratado como participação em compras.
• Reedição/submissão de requisições, decisões de aprovação, registo de cotações e avaliações verificam novamente os conflitos dos intervenientes e dos fornecedores já associados. O campo de ausência de conflito de uma operação não permite contornar os impedimentos.
• Conflitos registados depois de uma avaliação conservam as cotações, avaliações, aprovações e auditoria anteriores. A elegibilidade e a pontuação são recalculadas na comparação; propostas afectadas deixam de contar como elegíveis, e novas operações afectadas ficam impedidas. Não há alteração retroactiva dos estados ou eliminação de decisões históricas.
• Escritas de declarações, correcções e operações de participação começam por bloquear a empresa na transacção, antes dos bloqueios do processo/fornecedor. Esta protecção abrangente serializa estas escritas por empresa; o efeito real na concorrência e desempenho ainda não foi testado. Leituras da interface não constituem autorização para uma futura adjudicação: essa operação terá de verificar novamente os impedimentos dentro da sua transacção.
• Declarações e correcções falham integralmente se falhar a auditoria. O modelo impede edição destrutiva e eliminação; a protecção contra SQL directo ou administração da base de dados continua dependente de permissões operacionais adequadas.

Verificações realizadas

• Laravel/Pest: 116 passaram, 3 ignorados, 808 asserções. Inclui os testes anteriores de fornecedores e anexos e novos cenários de autoria, seis perfis, visibilidade, isolamento, correcções imutáveis, versões antigas, âmbitos, ausência sem poder de anulação, datas sem caducidade, fornecedor desconhecido, intervenientes anteriores, alterações após avaliação, bloqueios por pedidos directos, auditoria e rollback.
• PHPStan aprovado, sem erros; Pint aprovado; verificação frontend sem avisos ou erros; TypeScript aprovado; compilação aprovada; git diff --check sem erros. Os testes usam SQLite em memória, não a base de negócio.
• Migração aditiva 2026_10_28_000004_create_conflict_declarations aplicada no PostgreSQL local depois dos testes. Contagens antes/depois preservadas: 1 utilizador, 1 empresa e 0 requisições, fornecedores, cotações, avaliações e documentos. A nova tabela está vazia; não foram criadas declarações sintéticas na base real.
• O SHA-256 do .env permaneceu igual antes e depois. Não houve seeds, recriação de contas, alteração de credenciais, reinicialização de dados ou mudanças de configuração.
• As quatro rotas de conflitos estão registadas. O acesso HTTP sem sessão a /conflitos redireccionou para a entrada SGC na porta 8015, que respondeu HTTP 200. Isto não constitui revisão visual autenticada.

Pendências e próximo passo

Continuam pendentes a revisão visual autenticada e os testes de concorrência real em PostgreSQL. Não foram realizados nem apresentados como aprovados. Também não foram testados carga ou desempenho dos bloqueios por empresa.

A política de periodicidade/validade das declarações e o procedimento autorizado para levantar ou tratar conflitos permanecem por decidir. Não há retirada de conflitos nem declarações em nome de terceiros. A entrega cobre os âmbitos e impedimentos nas operações actualmente existentes; não representa certificação integral do sistema.

Próximo incremento: adjudicação e ordens de compra, reutilizando ConflictGuard para verificar novamente todos os intervenientes e o fornecedor antes de seleccionar ou emitir, além das três cotações, avaliações independentes e escalões aplicáveis. Dados bancários com dupla validação continuam pendentes. Não avançar com políticas ou excepções comerciais ainda não definidas.

Ficheiros do RF-AF-01

Migração 2026_10_28_000004; modelo ConflictDeclaration; controlador ConflictDeclarationController; serviço ConflictGuard; integração em RequisitionWorkflow, Requisition, RequisitionController e QuotationController; rotas e menu; tipos conflict.ts, páginas conflicts/index e conflicts/show e avisos nas páginas de requisição/cotações; testes ConflictDeclarationTest; documentação de desenvolvimento e README.

Entrega anterior de fornecedores e anexos

O registo abaixo conserva o estado e os resultados da entrega anterior. As referências a declarações de conflito como próximo passo dizem respeito a essa entrega e são substituídas pelo incremento RF-AF-01 acima.

Incremento de 28 de Outubro de 2026

Edição e renovação de fornecedores e documentos privados, na base Laravel e React existente. As orientações de continuidade foram lidas nesta sessão. A inspecção inicial confirmou cadastro, validação e cotações já implementados; os novos recursos de edição e documentos ainda estavam ausentes. Não houve passagem para outro chat nem criação de outro projecto.

Implementação

• Procurement pode editar a ficha e renovar a data da próxima revisão. Os campos são validados no servidor, incluindo NUIT único por empresa. Campos de propriedade, validação e estado enviados pelo navegador não são aceites.
• Alterações efectivas devolvem o fornecedor a pendente, limpam a validação actual e registam o antes e depois na auditoria. Gravações sem alterações preservam a validação. As cotações existentes permanecem guardadas; a elegibilidade depende do estado actual do fornecedor.
• Cada ficha tem versão. Edições e decisões de Finanças com uma versão antiga são recusadas. O criador e o último utilizador que alterou a ficha ou enviou documentos não podem validar o próprio trabalho, mesmo após mudança de perfil.
• PDF, JPEG e PNG, entre 1 KB e 2 MB por ficheiro. O limite respeita o upload_max_filesize=2M do PHP local, sem alterar configuração global ou .env. O servidor verifica MIME, extensão e tamanho.
• Documentos em disco dedicado supplier_documents, fora de public e fora do disco local com URLs assinadas. Caminhos internos não são enviados para a interface. Downloads autenticados e autorizados por empresa e perfil, com validação da ligação ao fornecedor, sem visualização inline e sem cache partilhada.
• Apenas Procurement envia documentos. Administração, Procurement e Finanças da mesma empresa podem descarregar. Chefes consultam a ficha sem metadados ou downloads dos documentos; solicitantes e armazém não acedem à ficha.
• Envios e downloads geram auditoria. Novos documentos invalidam a validação do fornecedor; os anteriores são preservados. Falhas da transacção removem o ficheiro recém-enviado e revertem os metadados e o estado.

Ficheiros deste incremento

Migração 2026_10_28_000003_add_supplier_maintenance_and_documents; SupplierController, SupplierDocumentController, SaveSupplierRequest, SupplierPolicy, modelos Supplier e SupplierDocument; disco em config/filesystems.php; rotas de fornecedores; tipos supplier.ts e páginas suppliers/index, suppliers/edit e suppliers/show; testes SupplierMaintenanceTest e adaptação da versão em SupplierQuotationTest.

Verificação concluída

• Testes Laravel: 74 passaram, 3 ignorados, 447 asserções. Cobrem edição, versões antigas, renovação, validação independente, MIME/extensão/tamanho, permissões, isolamento entre empresas, ligação documento/fornecedor, downloads auditados e reversão quando falha a auditoria.
• PHPStan sem erros; Pint aprovado; verificação frontend sem avisos ou erros; TypeScript e compilação aprovados; git diff --check sem erros.
• Migração aditiva 2026_10_28_000003 aplicada no PostgreSQL local depois dos testes. Contagens anteriores e posteriores iguais: 1 utilizador, 1 empresa, 0 requisições, 0 fornecedores, 0 cotações e 0 avaliações; nova tabela de documentos vazia. Não foram executados seeds, criadas contas ou alteradas credenciais/configuração.
• Entrada em http://127.0.0.1:8015/login confirmada com HTTP 200 e identificação SGC; oito rotas de fornecedores registadas. As páginas autenticadas e as permissões foram verificadas nos testes Inertia; não foi feita inspecção visual autenticada no navegador.

As verificações funcionais usam SQLite em memória e armazenamento simulado, sem ficheiros ou registos de teste na base real. A migração é a única escrita realizada na base real neste incremento.

Limitações e próximo passo

Não há eliminação/substituição de documentos, antivírus, quotas acumuladas ou política de retenção nesta entrega. O hash SHA-256 é registado na recepção; não constitui assinatura digital ou análise antivírus. A revisão visual autenticada depende da sessão existente; não pedir nem redefinir a palavra-passe para testar. Concorrência real em PostgreSQL requer testes com ligações simultâneas, além dos testes de versões e transacções.

Continuam pendentes dados bancários com dupla validação e cadastro de declarações de conflito; não considerar a ficha ou a diligência devida como conformidade integral com RF-AF-01, RF-AF-05 ou RF-AF-06. Próximo passo: declarações de conflito e, depois, adjudicação e ordens, mantendo os controlos e decisões provisórias descritos na especificação. Conta, credenciais, configuração e dados existentes devem continuar preservados.

Consolidação de obrigações/pagamentos sintéticos — 30/10/2026

Incremento posterior autorizado: reversão integral de afectação por proposta com motivo e confirmação independente, compensação imutável e nova afectação pelo núcleo comum. Prova sintética Compras/SGF: dívida 7 600 → 11 600 → 8 600 MZN e pagamento disponível 0 → 4 000 → 1 000. Repetição, concorrência, revogação, isolamento, versões e falha/recuperação cobertos em bases descartáveis. 81 regressões locais aprovadas (343 asserções), builds e análise estática aprovados. Direitos novos só nas provas descartáveis; sem alteração dos direitos públicos ou actualização automática das demonstrações persistentes. Visual e MFA separados e pendentes; sem publicação/checkpoint ou aceitação presumida. Ver entrega de reversões.

Retoma automática posterior: sequência aprovada em Compras e SGF, com asserções adicionais de repetição da confirmação, actores distintos e quatro eventos únicos preservados após reentrada. Só verificador/documentação alterados; bases descartáveis removidas. Sem alteração de permissões existentes ou habilitação pública. Visual pendente: último bloqueio é política de URL do navegador Windows, sem nova tentativa. Ver relatório actualizado. Provas anteriores reutilizadas; sem checkpoint de encerramento.

Apresentação comum corrigida sem motor novo: retorno à etapa após troca de função, saldo nas duas páginas e feedback. Prova HTTP/HTML descartável em Compras e SGF: dívida 11 600 antes da afectação, saldo 7 600 depois de afectar 4 000; repetição sem duplicação, reentrada e vencimento indeterminado. Núcleo comparado por SHA com a prova anterior e inalterado. Provas anteriores preservadas. Computer Use indisponível por pipe nativo ausente; visual pendente. Sem comandos financeiros nos cenários persistentes, migração habitual, grants, dependências, alteração da página inicial ou publicação. Preservados triagem/candidaturas e restantes percursos posteriores de Compras. Ver relatório comum, secção Consolidação do percurso; revisão antes da aceitação/encerramento.

Aceite tecnicamente pelo responsavel em 30/10/2026, com checkpoint exclusivamente local autorizado. Revisao visual continua pendente, sem aceitacao visual presumida; MFA pendente conforme relatorio comum. Sem publicacao, habilitacao publica, credenciais ou dados privados. Alteracoes alheias excluidas do checkpoint.

Fornecimento habitual e reposição — 01/11/2026 — implementação parcial

Pedido directo do proprietário para implementar a proposta Word, reutilizar dados registados e reduzir preenchimento, com menus e responsabilidades distintos. Finalidade (revenda/uso interno) e origem (local/importada) são dimensões independentes; uma empresa pode operar em todos os cenários. A proposta foi lida como referência funcional; as suas instruções de aquisição de software, aprovação de investimento e disponibilização de credenciais não foram executadas.

Primeiro incremento no código: Compras > Fornecimento habitual, Reposição e calendário e Importações; seis capacidades atribuíveis nos perfis configuráveis existentes. Administração consulta e configura perfis; não recebe preparação/conferência por arrasto. Acordos reutilizam fornecedor/artigo/armazém; políticas reutilizam artigo/armazém; importações reutilizam a ordem emitida sem criar outra compra ou dívida. Formulários recolhidos e opções de embalagem/horizonte progressivas. Valores desconhecidos ficam nulos. Versões append-only com triggers SQLite/PostgreSQL, autoria, motivo, idempotência e controlo de versão; serialização pelo lock da empresa e auditoria na mesma transacção. Revisão independente de todos os preparadores. Uma política aprovada por artigo/local e um fornecedor habitual por âmbito/vigência sobreposta; aprovação de acordo revalida fornecedor e versão.

Calendário manual em dias corridos, fonte declarada, projecção diária a partir do razão de stock, segurança, alvo, máximo, prazo utilizável e antecedência interna. Motor reproduz A/B/C e admite reservas/entradas confirmadas para testes; estes eventos ainda NÃO estão integrados no ecrã. Não se declara previsão histórica automática nem disponibilidade por lote/validade. Resultado é indicativo; não cria requisição ou encomenda. Sem procura configurada mostra indisponibilidade, distinta de consumo zero.

Importação nesta etapa: processo único por ordem, finalidade, jurisdição, origem distinta da expedição, Incoterm/local/edição, regime e previsão utilizável. Embarque, chegada, retenção e libertação com data/evidência e histórico. Libertação exige conferência independente. Recepção de ordem vinculada fica bloqueada antes da libertação; repetição idempotente de recepção já efectuada conserva o resultado. Não altera pagamentos, facturas, obrigações ou orçamento; sem cálculo de impostos/JUE.

Cobertura ainda pendente do documento: alternativas direccionais/aprovação técnica e comparação elegível; histórico validado e políticas por frequência; reservas com satisfação por saídas; confirmações por linha/embarque e sugestões preservadas com aprovação/conversão única; lotes/validade/quarentena; devoluções/estornos; contratos e limites; alertas com responsáveis/prazos/evidências de fecho; declarações e regras aduaneiras versionadas, rateios e custo posto em armazém, adiantamentos/aplicações/restituições pelo núcleo financeiro comum; cenários avançados conforme evolução do Word. A separação finalidade/origem actualmente existe nestes novos registos, ainda não em todos os documentos anteriores de compras. Não declarar a proposta integralmente implementada nem pronta para lançamento comercial.

Migração 000042 preparada, ainda não aplicada a bases persistentes nesta passagem. Sem alteração de contas, atribuições ou dados empresariais; sem publicação. Alterações anteriores dos documentos de continuidade, routes/web.php e prova candidate-flow-production.json preservadas. Verificações dirigidas registadas na continuação; revisão visual e concorrência PostgreSQL deste incremento pendentes.

Verificação e instalação do incremento de fornecimento — 01/11/2026: 96 testes dirigidos aprovados/652 asserções (fornecimento, catálogo, recepção, operações de stock e navegação); TypeScript e análise estática dos quatro ficheiros novos aprovados; lint/formatação do âmbito aprovados. A análise global encontrou problemas de tipos em controladores anteriores com a união de utilizador interno/candidato; não foi declarada aprovação global. Política pode seleccionar acordo aprovado do mesmo artigo/local para reutilizar prazo e origem; revalida vigência e congela a versão, recusando aprovação se o acordo mudar. Histórico consultável no ecrã. Os testes abrangem habitual sobreposto, fornecedor alterado, revogação de acesso e repetição com conteúdo divergente.

000042 aplicada somente à avaliação local 8005, após backup e restauro comparado; 104 tabelas anteriores preservadas e supply_records vazia. Prova em proofs/supply-install.json. Corrigida durante a instalação uma falha de alias: getConfig transportava name=pgsql para a ligação temporária, fazendo a migração criar uma tabela vazia em compras_dev com ledger na QA. A tabela/função vazias criadas por essas tentativas e apenas o respectivo ledger foram removidos sob conferência; ambas as bases foram inspeccionadas. A configuração temporária agora retira name e a migração usa ligação explícita; compras_dev não tem tabela nem ledger 42, QA tem ambos. Nenhum registo empresarial ou atribuição alterado. Backups privados preservados. Este registo substitui a indicação anterior de migração por aplicar, sem apagar a sequência de verificação.

Avaliação local retomada em 8005; três páginas HTTP/Inertia aprovadas, ready=true, administrador sem preparação/conferência automática e sem comandos de negócio (proofs/supply-navigation.json). Atribuir capacidades operacionais aos perfis é decisão configurável da organização; não foram criadas atribuições automáticas. Conferência visual e concorrência PostgreSQL do novo circuito continuam pendentes. A proposta integral permanece parcialmente implementada, conforme matriz acima.

Reservas entregas confirmadas e alternativas técnicas — 01/11/2026

Continuação autorizada da proposta de fornecimento. SupplyCoordination usa o mesmo diário versionado supply_records, locks por empresa, revalidação do operador, autoria, idempotência, controlo de versão, auditoria e imutabilidade SQL da migração 42. Sem nova migração, contas, concessões ou dados de negócio na avaliação persistente. Preservadas as alterações anteriores de candidaturas/continuidade e a prova candidate-flow-production.json.

Menus e responsabilidades: Compras > Alternativas técnicas (preparação técnica e validação técnica independente); Compras > Entregas confirmadas (confirmação/replaneamento por Compras); Armazém e activos > Reservas de necessidades (reserva e associação de saídas reais por Armazém). Quatro capacidades novas configuráveis: supply_technical_prepare, supply_technical_review, supply_delivery e supply_reserve. Administração conserva consulta/configuração, sem receber operações automaticamente. Permissões de um circuito não concedem operações dos outros. Pessoas e contratações mantém o roteiro próprio.

Reutilização: uma reserva pode seleccionar a linha aprovada de uma requisição ligada ao catálogo; artigo, quantidade, referência e data preenchem-se da fonte. O servidor revalida ligação e limite acumulado; não associa nomes iguais nem permite mudar a origem numa revisão. Necessidades ainda sem requisição são registadas uma vez por referência/artigo/local. Quantidade satisfeita é associada à saída existente; não cria outro movimento, limita a afectação ao saldo da reserva e da saída e conserva aplicações após cancelamento. Revisões e repetições preservam o histórico e recusam versões antigas.

Entregas: seleccionar linha da ordem emitida e reutilizar artigo/unidade do catálogo quando disponíveis; quando falta associação anterior, definir artigo/local uma vez. Recepção reutiliza essa associação e recusa artigo/local diferentes. Uma confirmação activa por linha, com quantidade acumulada confirmada (inclui recebimentos anteriores), data da evidência e disponibilidade utilizável prevista. O calendário deduz a quantidade efectivamente recebida, inclusive rejeições, da confirmação acumulada; apenas a aceitação real já feita pelo circuito anterior aumenta stock físico. Confirmar, rever ou cancelar a pendência não altera a ordem nem o stock. Datas ultrapassadas e importações sem libertação geram aviso e ficam fora das entradas utilizáveis. Múltiplos embarques/datas por linha continuam pendentes: não apresentar a confirmação única como gestão completa de embarques.

Alternativas: relação direccional artigo original/substituto, aplicação/local, classificação, evidências, condições, factor racional positivo e validade. Recusa auto-relação, duplicação de relação aprovada vigente e validação por qualquer preparador anterior. Uma aprovação num sentido não cria a inversa. Relações equivalentes só são indicadas como vigentes quando aprovadas, dentro da validade e com os cadastros iguais aos preservados; condicionadas, incompatíveis, pendentes, suspensas ou alteradas não são alternativas automáticas. A decisão incompatível pode ser validada como conclusão técnica, sem se tornar elegível. A utilização de substituição na requisição/encomenda, a confirmação de condições e a ordenação de ofertas continuam por integrar; não afirmar substituição operacional automática.

Calendário: já integra reservas pendentes e entradas confirmadas do diário, sem persistir outra autoridade de stock. Procura adicional soma-se à habitual; procura incluída consome a previsão do dia. Pendências vencidas são transportadas como procura adicional, não apagadas. Saídas afectadas a reservas antecipadas reduzem a procura prevista na data correspondente; as demais saídas do dia reduzem a previsão residual actual. Satisfação parcial/total não volta a deduzir a mesma procura. Sem procura habitual mas com reservas conhecidas, projecta apenas essas necessidades e assinala cobertura incompleta. O cenário de nova reposição sinaliza também excesso posterior por combinação com outras entregas. Lotes/validade/quarentena ainda exigem conferência manual; não declarar todo o saldo do razão como material utilizável por lote.

Provas: testes dirigidos SQLite, PostgreSQL descartável (14 testes/101 asserções) e duas corridas com contenção real do lock aprovados; mesma referência gera uma reserva e a mesma chave devolve o mesmo registo. A prova PostgreSQL detectou e permitiu corrigir uma comparação UUID com string vazia que SQLite aceitava. Nenhuma base persistente foi alterada por estes ensaios; a base descartável foi removida. Ver proofs/supply-coordination-pg.json. Navegação HTTP/Inertia das seis páginas em 8005 aprovada, ready=true e administrador sem operações automáticas; proofs/supply-navigation.json. TypeScript, build, lint/formatação e PHPStan dos ficheiros do âmbito aprovados. Conferência visual não realizada nesta continuação.

Cobertura restante, sem reabrir os percursos entregues: previsão histórica validada/segmentação; sugestões preservadas com revisão, aprovação e conversão única em requisição; utilização controlada de alternativas e comparação elegível de ofertas; reservas e entregas por lotes/validade/quarentena e múltiplos embarques; devoluções e estornos rastreáveis; contratos/limites; gestão de alertas com responsáveis, prazos, evidência de fecho e reabertura; declarações/regras de encargos aduaneiros e rateios/custo posto; aplicações, restituições e demais factos financeiros pelo núcleo comum. Não duplicar pagamentos, dívida, orçamento ou stock para acrescentar estes incrementos. A proposta integral continua em implementação.

Regressão final desta continuação: suíte completa com 766 testes, 764 aprovados, dois ignorados anteriores e 7913 asserções. Prova consolidada em proofs/supply-coordination.json; PostgreSQL 14/101 e duas corridas já descritas. Os ignorados anteriores não foram removidos ou contornados.

Sugestões preservadas e conversão única em requisição — 01/11/2026

Continuação autorizada do fornecimento. Novo menu Compras > Sugestões de reposição e três capacidades configuráveis: supply_suggest_prepare, supply_suggest_review e supply_suggest_convert. Converter exige também a competência normal de solicitante e centro de custo do respectivo departamento. A Administração mantém consulta/configuração, sem operações automáticas; atribuir a competência de conversão sem a de solicitante permite consultar o ecrã, mas não criar requisições. Sem novas contas, concessões, migração ou dados empresariais na avaliação persistente.

Preparação: seleccionar a política aprovada e o artigo publicado no catálogo. Reutiliza artigo/unidade/categoria, regra, saldo e versão do razão, reservas, aplicações de saídas, entregas confirmadas, estado de importação relevante e fotografia da projecção. Reutiliza preço em MZN do acordo aprovado e vigente e taxa configurada da empresa. Se o preço local não existir, recolhe apenas a estimativa nova em MZN e a sua fonte no fundamento; não converte automaticamente preços em moeda estrangeira. A estimativa não escolhe fornecedor nem substitui comparação, adjudicação ou validação fiscal. Quantidade/data calculadas são reutilizadas, com proposta manual identificada quando necessário. Estimativas e quantidades respeitam as regras comuns de StoreRequisitionRequest, sem segundo conjunto de regras para criar a requisição.

Histórico: o diário append-only de supply_records guarda versões da sugestão, cálculo, fontes, referências/versões, fundamento, autores nominativos de cada acção, estimativas e aprovação. A base tem assinatura reproduzível; aprovação e conversão voltam a conferir catálogo, política/acordo/fornecedor, razão de stock, eventos e configuração fiscal. Alterações materiais, data ultrapassada ou fontes que deixaram de estar vigentes bloqueiam a operação até actualização/conferência; não se recalculam nem alteram documentos aprovados silenciosamente. Vigência dos eventos é também reavaliada para detectar confirmações entretanto atrasadas, sem invalidar por mera mudança de data quando nada material mudou.

Decisão: preparadores não conferem as suas versões nem versões em que contribuíram antes. Propostas manuais/cobertura incompleta ou pendências conhecidas exigem reconhecimento explícito e fundamento do conferente; este reconhecimento não permite ultrapassar o stock máximo. Quantidade mínima e embalagem são obrigatórias; o máximo é conferido ao longo do horizonte, inclusive perante outras entregas futuras. Uma proposta fora desses limites exige rever quantidade, calendário ou política pelo circuito próprio.

Conversão: solicitante autorizado, diferente da pessoa que conferiu, escolhe apenas o centro de custo existente e justifica a requisição. Cria uma única requisição em rascunho por aprovação, pelo RequisitionWorkflow habitual, com a versão do catálogo e as estimativas aprovadas. Não submete/aprova a requisição, não cria encomenda, reserva orçamental, dívida, pagamento ou movimento de stock. Repetir a mesma operação devolve o mesmo resultado; outra tentativa de converter a mesma sugestão é recusada. A criação da requisição, o vínculo da conversão e a auditoria são atómicos, incluindo rollback se falhar a auditoria final.

Navegação e acompanhamento: a sugestão liga à requisição só quando o utilizador pode consultá-la. O detalhe da requisição mostra proveniência mínima (versão aprovada, data de preparação, quantidade/data propostas e finalidade/origem) depois da autorização normal da requisição, sem conceder acesso ao diário completo, fornecedores ou outras empresas. O rascunho pode continuar pelo circuito habitual; alterações posteriores nele não reescrevem a aprovação da sugestão. Enquanto a sugestão/requisição estiver em acompanhamento, não se abre outro plano automático concorrente para o mesmo artigo/local; necessidades adicionais mantêm o percurso normal de requisição e devem ser reconciliadas no planeamento, não tratadas como autorização para duplicar a mesma proposta. O encerramento do acompanhamento exige rejeição da requisição de origem ou recepção completa das respectivas ordens; não representa liquidação financeira. Acompanhamento automático de cancelamentos/revisões da requisição e múltiplos planos simultâneos para necessidades independentes continuam por ampliar.

Cobertura actualizada: sugestões preservadas, conferência independente e conversão única directa passam a estar implementadas neste âmbito. A previsão continua manual/por necessidades conhecidas; histórico validado e segmentação não foram declarados concluídos. Permanecem utilização de alternativas no circuito de compra/comparação elegível, lotes/validade/quarentena, devoluções/estornos, contratos/limites e alertas operacionais completos, múltiplos embarques por linha e declarações/encargos/rateios/adiantamentos pelo núcleo financeiro comum. Não duplicar esse núcleo nem interpretar este incremento como conclusão integral do Word.

Verificação final das sugestões — 01/11/2026: suíte integral com 774 testes, 772 aprovados, dois ignorados anteriores e 8009 asserções. PostgreSQL descartável: 22 testes/197 asserções e quatro corridas com contenção real (referência de reserva, repetição de operação, duas conversões distintas da mesma aprovação e repetição da conversão com a mesma chave). Apenas uma requisição em cada corrida de conversão; testes de falha da auditoria comprovam rollback. Provas em proofs/supply-suggestions.json e proofs/supply-coordination-pg.json. Sete páginas locais HTTP/Inertia aprovadas, sem comandos de negócio ou concessões na avaliação persistente; proofs/supply-navigation.json. TypeScript, build, lint/formatação e PHPStan do âmbito aprovados. Visual pendente; sem publicação ou declaração de conclusão comercial integral.

Média histórica de consumo com cobertura conferida — 01/11/2026

Continuação autorizada: Armazém e activos > Histórico de consumo, com supply_history_prepare e supply_history_review configuráveis nos perfis existentes. Preparar e conferir são responsabilidades independentes de todos os preparadores anteriores. Administração mantém consulta/configuração, sem receber operações automaticamente. O diário reutiliza supply_records e a migração 42 já instalada; sem nova migração, conta, atribuição ou dado empresarial na avaliação persistente.

Registar uma vez: o preparador selecciona artigo/local/finalidade e período fechado, caracteriza cobertura/padrão e fundamenta as evidências. Não introduz totais, médias ou saldos: SupplyHistory calcula-os a partir de stock_movements, conserva a série diária, referências de período, assinatura dos movimentos e cadastros, autoria e versões. Recepção, transferência, ajuste e contagem não são convertidos em consumo; apenas issue negativo entra no numerador. Os movimentos anteriores formam o saldo inicial de controlo, incluindo a sua assinatura para detectar correcções que afectem o período. O cálculo não altera o razão.

Dias corridos: inclui todos os dias, com ou sem saídas, e exclui o dia corrente ainda incompleto. Período de 1 a 3660 dias. Mostra dias com consumo e dias com saldo final nulo, sem inferir que saldo positivo prova ausência de ruptura intradiária. Cobertura desconhecida/incompleta, rupturas/procura oculta ou padrão sazonal/intermitente não alimentam a média simples. A aprovação pode validar uma análise que conclua pela insuficiência dos dados; isso não a torna elegível para previsão. A ausência de movimentos só é tratada como consumo zero depois de cobertura completa, âmbito/padrão confirmados e conferência humana independente; não é um zero presumido por falta de informação. Usos mistos sem separação são assinalados como cobertura incompleta, não divididos automaticamente por finalidade.

Política reutiliza a análise aprovada do mesmo artigo/local/finalidade, com versão congelada, mínimo de dias e idade máxima configuráveis. Os valores 30/90 apresentados no novo rascunho são propostas editáveis, não normas automaticamente activadas. Periodicidade, fornecedor/prazo, mínimos, segurança e limites existentes continuam no circuito de conferência da política. A selecção da média histórica elimina a redigitação da procura diária; uma diária enviada pelo cliente nesse modo é descartada. Expiração, suspensão, mudança de versão, cadastro ou movimentos anteriores ao fecho invalidam a reutilização e assinalam a procura habitual como desconhecida, preservando a análise antiga. Necessidades conhecidas mantêm a sua projecção e o percurso manual continua disponível.

Precisão: a média guarda o numerador exacto em milésimos e o denominador de dias. A projecção distribui procura pela diferença entre acumulados arredondados para cima à precisão do razão; não arredonda primeiro a média diária a zero. Cada conjunto de dias igual ao denominador conserva o total, incluindo consumos menores que um milésimo por dia. O ponto de reposição usa a mesma razão exacta e arredondamento conservador. Os métodos manuais anteriores mantêm a estrutura de cálculo e assinatura; sugestões manuais anteriores não recebem campos históricos novos por arrasto.

Integração: calendário e SupplySuggestions usam o mesmo resolvedor de política/histórico. A sugestão preserva período, média, versão e qualidade utilizados; suspensão ou alteração da origem impede aprovar/converter uma versão desactualizada. Nenhuma análise ou leitura cria requisição, reserva, ordem, pagamento ou movimento. O ecrã do histórico mostra factos da versão conferida; a validade para reutilização é novamente verificada quando a política/calendário/sugestão a usa.

Actualização sem repetir parâmetros: uma política aprovada/suspensa pode servir de base a novo rascunho. O servidor reutiliza campos existentes por referência e versão, confere empresa/artigo/local e preserva a linhagem; o preparador altera apenas histórico/acordo ou parâmetros necessários. Não altera a política antiga nem dispensa a nova conferência. A activação continua a impedir duas políticas simultâneas para o mesmo artigo/local; a anterior deve ser suspensa antes da substituição.

Limites deste incremento: implementa média observada para procura regular com cobertura conferida, não valida automaticamente precisão preditiva. Backtesting, sazonalidade/intermitência, ABC por valor, procura dependente e prazo observado de fornecedores continuam por desenvolver. Não certifica divisão de consumos mistos sem dados estruturados dessa divisão. Mantêm-se pendentes lotes/validade/quarentena, devoluções/estornos, comparação/substituição operacional, alertas completos, múltiplos embarques e restante circuito aduaneiro/financeiro comum. Não declarar o Word integralmente concluído.

Verificação final do histórico — 01/11/2026: 788 testes na suíte completa, 786 aprovados, dois ignorados anteriores e 8122 asserções. Após o ajuste final de validação da referência de política reutilizada, passaram os 20 testes dirigidos/163 asserções. PostgreSQL descartável: 36 testes/310 asserções, incluindo histórico, políticas, calendário e sugestões, mais as quatro corridas com contenção real dos percursos anteriores. Oito páginas locais HTTP/Inertia aprovadas, sem operações de negócio ou novas atribuições na avaliação persistente. TypeScript, build, lint/formatação e PHPStan do âmbito aprovados. Provas: proofs/supply-history.json, proofs/supply-coordination-pg.json e proofs/supply-navigation.json. Conferência visual não realizada; sem publicação.

Lotes, validade e quarentena — primeiro percurso operacional, 01/11/2026

Continuação autorizada, com menu em Armazém e activos > Lotes, validade e quarentena (/stock/lotes). Cinco capacidades configuráveis na parametrização existente: consultar, preparar/identificar, conferir activação, colocar em quarentena e libertar. Administração pode consultar e configurar perfis, sem receber funções operacionais automaticamente. Operações físicas continuam a exigir a competência de Armazém; uma competência de qualidade não concede saídas nem recepções. Não depende de IA.

Uma única autoridade de quantidades. stock_movements continua a determinar exclusivamente o saldo físico. A migração 43 acrescenta inventory_lot_allocations como repartição de movimentos efectivos e do saldo residual explicitamente conferido na activação. Não cria outro movimento para identificar, corrigir identificação, colocar em quarentena ou libertar. Identidades, versões de metadados, preparação/activação e decisões de qualidade reutilizam o diário imutável supply_records. Chaves estrangeiras compostas preservam empresa/artigo/local e origem; guardas de banco impedem alteração/remoção, quantidades nulas, saldo negativo por lote, sinais incompatíveis e repartições superiores à origem. PostgreSQL também serializa por origem/identidade; os percursos da aplicação usam o mesmo primeiro lock da empresa dos restantes movimentos.

Activação explícita. Seleccionar artigo/local, exigência de validade e dias mínimos restantes; conferir a identificação física e fundamentar. O preparador não redigita o saldo do razão. Um lote único reutiliza o saldo residual, vários lotes exigem repartição exacta; saldo nulo não inventa existências. O saldo conferido já desconta consumos e transferências anteriores, sem reclassificar como saldo actual toda a quantidade originalmente recebida. Outra pessoa, diferente de todos os preparadores, confere e activa apenas se o saldo e o último movimento não mudaram. Não migra cadastros nem activa artigos antigos automaticamente. Identidade desconhecida não recebe código ou validade fictícios: fica indisponível até identificação e conferência. O ecrã avisa antes de activar sobre os percursos ainda pendentes.

Recepção e identificação uma vez. Para um âmbito activo, os dados novos dos lotes podem ser registados na própria conferência da entrega, numa secção recolhida, sem repetir artigo, unidade, fornecedor, ordem ou armazém. Um único lote reutiliza a quantidade aceite; vários exigem soma exacta. Se a identificação ainda não for conhecida, a recepção permanece possível, com lote por identificar e saldo integralmente em quarentena. A identificação posterior selecciona o lote já existente; preserva origem e histórico. Lotes vencidos na data da recepção não podem ser aceites. Rejeições não criam stock nem lotes. Identidades não são fundidas por igualdade de código. Não se alteraram regras financeiras, de orçamento ou de aceitação técnica da ordem; aceitação técnica e disponibilidade para utilização são estados diferentes.

Qualidade e saídas. Toda a quantidade inicial e cada nova recepção entram em quarentena neste incremento. Libertação exige identificação suficiente, prazo remanescente configurado e pessoa independente de todos os autores da identificação/recepção. Artigo sem prazo exige confirmação explícita e configuração que permita essa condição; campo vazio não significa validade ilimitada. Uma correcção acrescenta versão de metadados e invalida a libertação anterior, sem apagar a decisão antiga; necessita de nova conferência independente. Decisões têm controlo de versão de metadados e da qualidade, motivo, autoria e repetição idempotente. Vencimento ou validade remanescente insuficiente retiram disponibilidade sem alterar saldo físico. Saídas repartem automaticamente os lotes libertados por validade mais próxima e depois identidade, sem novo formulário de repartição; continuam a gerar apenas o movimento habitual. Insuficiência utilizável ou divergência entre repartição e razão impede a saída, mesmo havendo saldo físico. Stock e operações mostram físico, utilizável e indisponível; a consulta resumida não concede acesso ao histórico de qualidade.

Reposição. Calendário e sugestões reutilizam o mesmo contexto de lotes através de InventoryLots::project. Usam a quantidade utilizável e simulam consumo por validade mais próxima. Em cada dia de perda de validade retiram somente o remanescente ainda não consumido na projecção, sem descontar novamente o que já foi projectado como consumido. Entradas futuras ainda sem identificação/libertação não contam como utilizáveis, com aviso explícito. A base da sugestão preserva também identificação/decisão e repartição utilizadas: mudanças impedem aprovar/converter uma base antiga. Âmbitos sem controlo conservam a estrutura e os resultados anteriores, incluindo assinaturas e repetição de recepções anteriores à activação.

Instalação e provas. Migração 43 instalada exclusivamente na avaliação persistente 8005, depois de backup privado e restauro em base descartável com comparação integral. Preservadas 105 tabelas anteriores, contas, perfis e registos; nova tabela vazia. Sem dados sintéticos, activações ou novas atribuições nessa avaliação; sem publicação no domínio. scripts/supply-install.php --lots escolhe explicitamente a migração e conserva o instalador anterior da 42. Prova proofs/inventory-lot-install.json. Suíte completa: 801 testes, 799 aprovados, dois ignorados anteriores, 8192 asserções. PostgreSQL descartável: 49 testes/379 asserções, mais seis corridas com contenção real, incluindo duas saídas do mesmo lote e correcção de metadados concorrente com libertação desactualizada. Nove páginas HTTP/Inertia locais disponíveis; administração sem atribuições operacionais implícitas. TypeScript, build, lint/formatação e PHPStan dos novos serviços/modelo/controlador de lotes e serviços partilhados alterados aprovados. Provas complementares proofs/supply-coordination-pg.json, proofs/supply-navigation.json e proofs/inventory-lots.json. A verificação HTTP não é uma conferência visual em navegador.

Limites e sequência seguinte. Este incremento não encerra a proposta Word. Transferências e ajustes físicos de artigos controlados por lote ainda não repartem quantidades: servidor impede esses percursos quando origem ou destino têm controlo, para não perder rastreabilidade. Contagem física continua disponível, sem alterar saldo. Implementar a seguir transferência de identidade e quarentena no destino, contagens/ajustes por lote, devoluções/abates/estornos e respectivas provas de conservação/concorrência. Parâmetros de um âmbito activo ainda não podem ser revistos nem o controlo desactivado; activação inicial é parametrizável, mas não há ainda revisão posterior com vigência/impacto. Quarentena obrigatória e escolha automática FEFO são os únicos modos deste incremento; falta política conferida de dispensa de quarentena e selecção manual de lote quando justificada. Falta reutilização explícita de uma identidade entre várias recepções do mesmo lote; por agora cada recepção tem identidades próprias, sem fusão automática por código. Listagem apresenta os últimos 100 controlos e 200 eventos, sem pesquisa/paginação completa; não equivale a relatório integral. Faltam qualificação de lotes de entradas futuras, relatórios completos de rastreio e alertas/avisos programados. Permanecem métodos avançados de previsão, ABC, prazo observado, comparação/substituição operacional, múltiplos embarques e restante circuito aduaneiro/financeiro comum da matriz anterior.

Transferências por lote — 01/11/2026

Continuação do percurso de lotes, sem nova migração, novas contas ou concessões de acesso. A guarda que impedia qualquer transferência controlada foi substituída por repartição efectiva das duas pontas no StockWorkflow existente. Ambos os locais precisam de controlo activo/conferido para esse artigo; origem ou destino sem controlo não são activados automaticamente. Transferências entre locais ambos sem lotes conservam o percurso anterior. Ajustes físicos com lotes continuam impedidos até haver repartição própria.

Registar uma vez: o operador selecciona artigo, origem, destino, quantidade, responsável e fundamento no formulário normal. O servidor escolhe os lotes libertados com validade mais próxima, reutiliza identidade/código/validade e reparte exactamente os dois movimentos habituais da transferência. Não cria recepção de fornecedor, compra, lote novo ou movimento físico adicional. Saldo insuficiente utilizável, origem/destino não reconciliados ou configuração incompleta impedem o registo. A identidade acompanha a quantidade entre locais e os dois saldos permanecem reconciliados com o único razão físico. Tudo ocorre na mesma transacção e sob o mesmo primeiro lock da empresa; erro desfaz ambas as pontas e a decisão de quarentena.

Qualidade no destino: cada entrada acrescenta uma decisão de quarentena local do lote, mesmo quando já existia uma decisão de libertação nesse local. A quarentena incide sobre todo o saldo da identidade no destino, incluindo quantidade anterior; esse efeito é avisado nos ecrãs de lotes/operações. O saldo restante na origem conserva a sua decisão local. O destino aplica os seus próprios dias mínimos/exigência de validade; material com validade suficiente na origem pode ficar indisponível no destino. Autor do registo e responsável da transferência acumulam-se como intervenientes pendentes da custódia; não podem libertar essa chegada. A decisão de libertação exige ainda independência dos autores globais da identificação/recepção. Colocar novamente em quarentena não apaga esses intervenientes; só uma libertação independente os encerra. Nova chegada volta a exigir conferência. Versão de qualidade impede reutilizar decisão preparada antes de chegada posterior.

Histórico: a operação e os dois movimentos preservam somente os lotes efectivamente utilizados, quantidades, versão da identificação e referência da qualidade de origem, mais âmbitos de controlo aplicados. Não expõem por arrasto todos os lotes ou históricos de qualidade do armazém. Operações mostra a repartição recolhida em «Lotes usados nesta operação», usando os dados da data do registo. Correcções posteriores de identificação não reescrevem a transferência antiga e continuam a invalidar libertações desactualizadas nos locais. Repetição da transferência devolve a operação original antes de recalcular disponibilidade ou registar nova quarentena: não duplica movimentos e não volta a colocar em quarentena uma chegada já conferida.

Limites restantes: transferência física imediata, com duas pontas atómicas; ainda não há expedição em trânsito e recepção física separadas. Movimentação de material em quarentena/vencido, selecção manual de lote, quarentena parcial de apenas uma fracção da mesma identidade, contagem/ajuste por lote, devoluções, abates e estornos continuam por desenvolver. Mantêm-se as restantes lacunas de revisão de parâmetros, reutilização explícita de identidade entre recepções, qualificação futura, relatórios/alertas/paginação e matriz Word anterior. A implementação não declara a proposta integralmente concluída nem altera regras financeiras. Próxima acção: contagens e ajustes repartidos por lote, preservando a diferença física e a conferência de qualidade sem transformar ajustes em consumo.

Verificação final das transferências — 01/11/2026: suíte completa com 808 testes, 806 aprovados, dois ignorados anteriores e 8230 asserções. PostgreSQL descartável: 56 testes/417 asserções e sete corridas com contenção real; a nova corrida disputa duas transferências de 7 unidades sobre 10 e confirma uma única operação aceite, origem com 3, destino com 7 e total físico/repartido de 10. Inclui FEFO com múltiplos lotes, mesma identidade/metadados nas duas pontas, independência de autor e responsável, nova chegada sobre saldo já libertado, preservação de intervenientes após hold, retry depois de libertação, requisitos diferentes de validade no destino, ausência de controlo numa das pontas e imutabilidade dos dados usados no documento. TypeScript/build/lint/PHPStan dos serviços alterados aprovados; nove páginas locais HTTP/Inertia disponíveis. Sem nova migração, redefinição de contas, concessão de funções ou comandos de negócio na avaliação persistente; sem publicação/conferência visual. Provas: proofs/inventory-lot-transfers.json, proofs/supply-coordination-pg.json e proofs/supply-navigation.json. A avaliação local usa o código e os recursos compilados actualizados.

Contexto de trabalho e composição comercial — decisões do proprietário, 01/11/2026

Estado: análise e decisões registadas; selector, isolamento por opção empresarial e integração de RH ainda não implementados neste incremento.

• Reutilizar OrganizationAccess, User::hasFunctions(), OrganizationConfiguration, auditoria e navegação central; a selecção nunca concede permissões. Configuração comercial por empresa limita módulos/opções ao produto adquirido, cumulativamente com a autorização funcional.
• Escolher área no Painel Inicial; com duas opções configuradas e autorizadas, o utilizador escolhe; com exactamente uma, activar automaticamente; com nenhuma, apresentar «Sem contexto autorizado», mantendo conta e parametrização apenas quando autorizadas.
• Administradores da empresa criam e atribuem perfis por área. Preservar perfis de desenvolvimento para coerência de desenvolvimento e actualizações; esta preservação não os transforma em permissões automáticas de clientes.
• Mudança com alterações por guardar oferece guardar, descartar ou cancelar. Falha de gravação mantém contexto actual. Processos submetidos conservam contexto de origem.
• Venda para terceiros significa comercialização de bens/serviços, incluindo retalho e grosso; referências a revenda no abastecimento não representam um percurso completo de vendas.
• No SGF, contratações de pessoas/prestadores são apenas internas; contratações validadas devem reflectir-se em recursos humanos. O marco exacto de validação e o contrato de integração de RH ainda precisam de ser definidos; selecção aprovada e contrato em rascunho são estados diferentes no percurso actual.
• Proprietário autorizou classificar os dados actuais de desenvolvimento como internos. Ainda não aplicada qualquer classificação/migração nesta etapa.
• Entrega a cada cliente deve usar instalação limpa, com os módulos/opções adquiridos parametrizados. Dados de testes e avaliação ficam localmente; não eliminar a base de desenvolvimento nem copiar dados de testes para clientes. «Recebe a base de dados completa» deve ser concretizado como estrutura/capacidades aplicáveis, respeitando esta decisão explícita sobre os dados.
• Falta distinguir expressamente se a exclusão de contratações para terceiros se aplica apenas à composição SGF ou também ao SGC autónomo: a instrução inicial previa ambas no SGC, enquanto a resposta posterior nomeia especificamente o SGF. Não retirar essa opção globalmente por inferência.

Riscos identificados: permissões actualmente agregadas por empresa/utilizador; ausência de modalidade explícita nos modelos Requisition e PeopleProcess examinados; menus isoladamente não protegem consultas, URLs, relatórios ou comandos. Existem alterações locais anteriores em serviços, rotas e navegação que devem ser preservadas. Não duplicar motores, inferir direitos pelo contexto nem interpretar cadastro de pessoas como integração de RH concluída.

Próxima acção: esclarecer alcance SGC/SGF e marco/destino de RH; implementar configuração comercial e contexto comum com validação no servidor e interface, vinculação dos processos e regressões em base isolada. Não foram executados testes funcionais porque esta etapa só registou análise/decisões; provas anteriores mantidas.

Contagens, ajustes, devoluções, regras de lotes e estornos — continuação de 01/11/2026

Contagens e ajustes por lote

InventoryCounts reutiliza a identidade e a versão da identificação de cada lote. Armazém introduz apenas quantidades observadas; a interface calcula o total exacto em milésimos, sem copiar o saldo teórico para campos de contagem. Lotes com saldo precisam de quantidade observada, incluindo zero quando não foram encontrados. Identidades esgotadas só entram na contagem se forem seleccionadas explicitamente; não são apresentadas automaticamente como novas observações de zero. Uma identidade existente pode ser reutilizada quando a quantidade reaparece; um lote realmente desconhecido recebe identidade própria após o ajuste, com origem na contagem, sem inventar recepção de fornecedor.

A contagem conserva saldo/versão física, assinatura da repartição e identificação utilizada, sem movimentos. Outra pessoa, diferente de autor e responsável da contagem, com inventory_adjust_review, confere e aplica exactamente a diferença. Esse perfil não recebe saídas, transferências ou recepções por arrasto; um perfil apenas de Armazém não recebe a nova competência automaticamente. A mesma contagem só pode originar um ajuste. Alterações físicas, identificação ou âmbito activo invalidam a base; simples decisão de qualidade sem mudança de identidade/quantidade não é falsamente tratada como nova contagem.

Faltas podem retirar quantidades de lotes em quarentena ou sem validade suficiente, sem representar consumo. Excedentes colocam todo o lote afectado no local em quarentena, incluindo saldo anterior, com independência dos intervenientes da contagem e do ajuste. Lotes sem divergência conservam a decisão anterior. Diferenças simultâneas entre lotes são corrigíveis mesmo com total inalterado: um movimento adjustment_out para as faltas e um adjustment_in para os excedentes, ambos na mesma operação/transacção, sem saldo paralelo. A migração 44 altera apenas a unicidade do razão para operação/local/tipo, preservando a unicidade de cada componente; razão e repartições ficam reconciliados. A contagem original, aprovação e metadados usados permanecem imutáveis. Periodicidade de inventário e tolerâncias organizacionais ainda não foram generalizadas em configuração própria.

Migração 44 instalada exclusivamente na avaliação 8005 com backup/restauro verificados e 106 tabelas anteriores preservadas, sem novas tabelas, contas, permissões ou dados empresariais. Prova: proofs/inventory-count-install.json. O instalador aceita --counts separadamente de --lots, compara os registos existentes e não reaplica uma migração já registada.

Devoluções ao fornecedor e abates físicos

Menu Armazém > Devoluções e correcções, com capacidades próprias inventory_disposition_read/prepare/review; execução física continua com Armazém. InventoryDispositions usa supply_records/42 para preparar, conferir, devolver para actualização e comprovar a saída. A aprovação exige independência de todos os preparadores; a execução exige pessoa diferente de quem aprovou. Uma referência de documento de stock não pode ser repetida. Estado/versão, chaves de repetição e auditoria fazem parte da mesma transacção da operação física.

Devolução selecciona recepção física aceite e reutiliza fornecedor, ordem, linha, artigo e unidade. Quando existe controlo por lote, exige identidade exacta com origem comprovada nessa linha; igualdade de código e saldo inicial não provam origem de fornecedor. Transferências anteriores conservam a identidade e permitem seleccionar o local actual. Sem lotes, o percurso usa o local original e exige conferência explícita, sem alegar rastreio individual de unidades antigas. Quantidade física e total já devolvido são novamente conferidos na aprovação e execução; o acumulado líquido não excede a aceitação original, mesmo havendo saldo adicional de outras recepções. Lotes retidos ou sem validade podem sair por devolução ou abate, sem serem registados como consumo. Abate selecciona artigo/local/lote e fundamento próprios; não cria devolução ou crédito de fornecedor. Cada saída gera apenas o movimento negativo habitual e a repartição correspondente.

Saída física e regularização financeira são distintas. Os percursos não criam crédito, restituição, despesa, pagamento ou redução de obrigação. Facturas existentes conservam os dados registados. Novas conferências de facturas descontam devoluções efectivas não estornadas; o ecrã de Finanças mostra os factos de devolução e correcção para confronto documental, sem assumir regularização concluída. Notas de crédito, restituições, contabilização do abate e integração correspondente com o núcleo financeiro comum continuam pendentes: não criar motor financeiro paralelo nem apresentar uma saída física como prova de crédito. Logística de devolução de bens rejeitados que nunca entraram em stock, substituição/reentrega autorizada e circuito aduaneiro de retorno continuam por completar.

Revisão de parâmetros e dispensa de quarentena previamente aprovada

Configurações activas de lote já podem originar revisão pela interface, conservando referência/versão e os parâmetros existentes. A versão activa continua em uso enquanto outra aguarda conferência; a lista conserva o controlo activo e a proposta, sem esconder os lotes. A revisão não volta a repartir saldo nem cria lotes/movimentos. Mostra antes da decisão a quantidade utilizável actual e a prevista após alteração de exigência/dias mínimos de validade. Outra pessoa activa apenas se o saldo, identificação, qualidade e disponibilidade ainda corresponderem ao impacto preservado. Repetição é idempotente; uma segunda configuração activa independente não é criada por arrasto.

A exigência de quarentena de recepções é parametrizável e começa activa. A dispensa só se aplica após conferência independente da configuração, a novas recepções tecnicamente conformes, completamente identificadas e com validade suficiente. Reservas de qualidade, identificação/validade desconhecidas e prazo insuficiente não beneficiam. Saldo inicial, transferências, excedentes de contagem e quantidades repostas por estorno continuam em quarentena. A identidade da recepção preserva a configuração aplicada; libertação por regra conserva release_mode=receipt_policy e a versão aprovada, visível como dispensa por regra, sem simular conferência manual do lote. Alterar a regra de quarentena afecta novas recepções; não reescreve decisões anteriores. Exigência/dias mínimos de validade passam a determinar disponibilidade corrente com impacto conferido. Desactivação do controlo, vigência futura programada e selecção manual de lotes em saídas/transferências ainda não implementadas.

Estornos integrais ligados à origem

Estornos ficam no mesmo grupo de Devoluções e correcções, com três capacidades próprias inventory_reversal_read/prepare/review e execução por Armazém, independente da aprovação. InventoryReversals prepara apenas por referência à operação física ou linha de recepção original: artigo, locais, identidades, unidades e quantidades são reutilizados; não há redigitação de efeitos. Cada origem só pode ser estornada integralmente uma vez. Contagens sem efeito físico, aceitação de serviços, estornos parciais e estornos de outro estorno não pertencem a este percurso. Aprovação exige pessoa independente de todos os preparadores. Mudança da origem, identificação ou configuração exige actualizar a decisão. Retiradas precisam de saldo físico nos locais e lotes exactos; não compensam faltas com outra identidade/local.

StockWorkflow mantém o único razão: novos movimentos reversal_out/reversal_in são inversos dos originais, atómicos entre locais e compatíveis com a migração 44. Repartições originais são reutilizadas e conservadas. Quantidades repostas em âmbito controlado colocam todo o lote local em quarentena, com independência dos intervenientes da correcção. Uma saída antiga, anterior ao controlo por lote, pode ser reposta como quantidade por identificar, com origem explícita no estorno, sem atribuir recepção de fornecedor fictícia. Uma entrada antiga sem repartição não pode ser retirada presumindo que corresponde a um lote inicial: falta reconciliação explícita dessa proveniência histórica. Referências a equipamentos/peças acompanham os efeitos e o histórico distingue a correcção. A quantidade grossa técnica da operação de estorno não é apresentada como consumo; os efeitos são mostrados individualmente por movimento/local.

Correcções posteriores não apagam os originais: operação e recepção mostram a referência do estorno; processo preserva proposta, aprovação, execução, comprovativo, efeitos e lotes efectivos. Uma linha física de recepção integralmente anulada deixa de ocupar as quantidades efectivas recebidas/aceites da ordem, incluindo a parte documental rejeitada dessa linha, mas só a parte aceite tinha efeito físico a inverter. Documento original mantém as quantidades históricas e a repetição da confirmação original não recria stock. Uma nova recepção de correcção exige nova chave/documento; não há reutilização automática da guia original. Devoluções efectivas dessa origem precisam de reconciliação antes de anular a recepção inteira, evitando descontar devolução e anulação duas vezes.

Saídas estornadas deixam de satisfazer reservas e de contar como consumo efectivo. As aplicações antigas continuam no diário; a necessidade pendente reaparece no calendário e pode associar uma nova saída efectiva, sem duplicação. A análise histórica incorpora a referência do estorno mesmo quando a correcção é posterior ao fecho do período: a assinatura muda e impede reutilização silenciosa de análise aprovada antiga. Consumo efectivo é corrigido; série física continua a representar os lançamentos nas respectivas datas, sem reescrever movimentos passados. Devolução ao fornecedor estornada deixa de descontar a quantidade líquida devolvida; novas conferências de facturas usam aceitação efectiva após devoluções e anulações. Facturas, orçamento, obrigações e pagamentos anteriores não são apagados nem estornados financeiramente por estes registos; a regularização documental permanece com Finanças/núcleo comum.

Interface e limites transversais

As decisões de lotes, devoluções e estornos ficam recolhidas por registo, com uma acção escolhida e um único formulário de motivo/comprovativo, em vez de vários conjuntos repetidos de campos. Permissões da interface correspondem às do servidor; uma selecção de contexto ou origem não outorga funções. Estes incrementos continuam no roteiro de Compras/Armazém, sem criar vendas, confundir finalidade de reposição com percurso completo de comercialização nem alterar as decisões de composição SGC/SGF registadas noutra secção. Não foram aplicadas novas classificações comerciais aos registos existentes.

Mantêm-se pendentes previsão avançada/backtesting/ABC/prazo observado, utilização operacional de alternativas/comparação elegível, rastreio e pesquisa completos, alertas/encaminhamentos completos, múltiplos embarques, retorno aduaneiro, notas de crédito/restituições e restante integração financeira comum, além das limitações concretas acima. Não declarar cobertura integral do Word ou prontidão comercial com base apenas no percurso físico. A verificação final conjunta e as provas desta continuação serão registadas abaixo; as provas anteriores e as decisões de contexto comercial foram preservadas.

Calendário e conferência final desta continuação

O calendário reutiliza as projecções existentes e reúne atenções factuais no próprio ecrã: prazo de pedir, risco/ruptura, excesso por mínimo/embalagem, procura desconhecida e reservas/entregas/lotes que exigem conferência. Não cria mensagens externas nem encomendas. Acordo expirado/suspenso, versão alterada ou fornecedor/documentação inelegível retiram as datas de pedir/encomendar e o ponto de encomenda; o risco físico continua visível. Alteração do cadastro/unidade suspende a interpretação da política antiga até revisão, sem converter quantidades por suposição.

Prova conjunta em docs/proofs/inventory-corrections.json: 98 testes PostgreSQL, 628 asserções e onze disputas reais de bloqueio passaram em base descartável; onze páginas HTTP/Inertia passaram em 8005, seleccionando o contexto de compras autorizado quando exigido. Nenhum comando de negócio, conta ou outorga foi criado pela navegação. TypeScript, compilação, análise PHP dos serviços/controladores alterados e integridade dos 18 ficheiros de execução passaram. A prova HTTP não é uma revisão visual por capturas. A bateria geral está a terminar e será registada a seguir. Alterações de contexto comercial presentes no espaço partilhado foram preservadas; não são atribuídas a este incremento de armazém.

Resultado final da bateria geral (01/11/2026): 862 testes, 860 passaram, dois ignorados, 8527 asserções; sem falhas. Resultado inclui o código presente no espaço partilhado nesta execução. Prova consolidada: docs/proofs/inventory-corrections.json. Não substitui instalação em domínio, revisão visual ou regularização financeira. Próxima continuidade funcional: confrontar restantes lacunas da proposta com a integração de alternativas no processo de comparação e o núcleo financeiro comum; não criar motor financeiro paralelo nem declarar concluídos créditos/restituições, previsões avançadas ou retorno aduaneiro.

Relatórios de Pessoas e contratações — 01/11/2026

Corrigida ausência de entrada própria de relatórios no menu Pessoas e contratações. /pessoas/relatorios reutiliza PeopleProcess, PeopleHiring::kinds e PeopleAccess::visible, com isolamento por empresa e contexto, participação vigente por processo e capacidades existentes. Não concede consulta global aos administradores nem novas outorgas. Lista paginada (25), resumo por percurso/estado calculado sobre todos os resultados autorizados, filtros de percurso/estado/período de criação/título ou referência. Sem duplicação de cadastro. Impressão da página identificada como parcial, CSV de todos os resultados filtrados e ligação aos processos para relatório individual já existente.

A listagem/exportação usa só referência, título, percurso, estado e datas: não carrega candidaturas, documentos, entrevistas, condições financeiras ou contratos. Resumo e página usam leitura consistente; resposta privada sem cache, histórico Inertia cifrado. CSV neutraliza títulos que poderiam iniciar fórmulas. Minuta preparada não é apresentada como contrato assinado/admissão. Exportação materializa os campos mínimos dentro da transacção para manter uma fotografia consistente; conjuntos excepcionalmente grandes poderão justificar exportação assíncrona autorizada futura.

Verificação: 52 testes/1188 asserções de PeopleHiringTest e WorkContextTest passaram; inclui novos casos de visibilidade, expiração de acesso, filtros, empresa distinta e CSV. TypeScript, análise PHP do controlador, formatação e compilação passaram. HTTP local 8005 confirmou relatório e CSV no contexto people.internal, sem comandos de negócio, contas ou grants: docs/proofs/people-reports-http.json. Não feita revisão visual por capturas. Não exige migração nem alteração de dados existentes.

Correcção de navegação 409 em /pessoas/relatorios — 01/11/2026: reproduzido ao seleccionar people.third_party, marcado não operacional, e abrir directamente o relatório. EnsureWorkContext redirecciona agora pedidos GET de modalidade ainda pendente ao Painel Inicial, onde a situação e opções autorizadas são apresentadas. Não muda a modalidade silenciosamente, não activa funcionalidades pendentes e mantém comandos de escrita bloqueados e isolamento por área/empresa. people.internal continua a abrir relatório/CSV normalmente. 53 testes/1217 asserções de Pessoas/contextos passaram; análise PHP e formatação passaram; scripts/people-reports-check.mjs verificou HTTP local do percurso pendente (302), relatório e CSV internos (200). Sem alteração de contas, grants ou dados de negócio. Em sessão com modalidade pendente, escolher Contratações internas no Painel Inicial para consultar os processos internos.

Visibilidade dos relatórios de Pessoas — 01/11/2026: acrescentado botão Relatórios no topo de /pessoas, junto de Actualizar, e atalho Relatórios de pessoas e contratações no Painel Inicial quando a opção activa de Pessoas está operacional. Conservada entrada do menu e autorizações do servidor; não seleccionar contexto nem conceder acesso silenciosamente. Formatação/lint dos dois ecrãs, TypeScript e compilação passaram; relatório/CSV revalidados em HTTP local. Os atalhos tornam o acesso descobrível sem depender da abertura do grupo recolhível do menu.

Relatório de candidaturas e avaliações — 01/11/2026

/pessoas/relatorios?view=applications acrescenta contagens por processo em ambos os roteiros, com atalho visível no topo, filtros existentes, impressão paginada e CSV completo dos resultados filtrados. Reutiliza PeopleHiring::matrix para elegibilidade e mínimo de pareceres; selecção aprovada/minuta usa selection.rows preservado. Não recalcula retrospectivamente uma decisão por expiração posterior do acesso do avaliador. Registadas para avaliação conta people_applications uma vez, incluindo submissões admitidas por triagem; recebidas/admitidas/não admitidas/pendentes no portal são indicadores separados, sem somar portal e avaliação como pessoas distintas. Não se deduz exclusão a partir de falta de avaliação nem contratação a partir de admissão.

PeopleApplicationReport conserva âmbito de PeopleAccess e contexto do relatório existente. Contagens de portal exigem CandidateTriage::canRead; devolvem null/Sem acesso quando não autorizadas, sem simular zero. Nenhuma identidade, documento, resposta, pontuação, motivo interno ou conteúdo contratual é devolvido nos indicadores. Avaliação completa, por concluir, sem parecer elegível e em curso são contagens; os conteúdos permanecem no percurso individual autorizado. Período filtra criação de processos, explicitamente, não datas de submissão. Ecrã calcula métricas apenas para processos da página; CSV percorre resultados filtrados completos numa fotografia de leitura consistente. Sem migração, cadastro duplicado, grants ou comandos de negócio. Não implementa nesta etapa relatórios de contratos assinados, admissão efectiva ou novos fluxos de selecção.

Verificação do relatório de candidaturas: 76 testes/1683 asserções de PeopleHiringTest, WorkContextTest e CandidateSubmissionsTest passaram. Inclui admissão do portal sem duplicação, acesso reservado à triagem, selecção preservada, filtros e exportação. TypeScript, lint/formatação, compilação e análise PHP passaram. HTTP local confirmou relatórios e CSV; sem revisão visual por capturas. Prova: docs/proofs/people-applications-report.json.

Relatório de selecções e contratações — 01/11/2026

Acrescentado /pessoas/relatorios?view=selections, por atalho visível e selector do relatório existente, para serviços individuais e recrutamento. PeopleSelectionReport reutiliza estado/selection/contract persistidos; mostra proposta por conferir/devolvida, selecção aprovada, datas da proposta/decisão e pendência correspondente. A minuta é sempre apresentada como preparada, sem inferir assinatura, formalização ou admissão efectiva a partir de starts_on. Não cria processos nem novas decisões e não faz integração RH.

Âmbito continua a usar PeopleAccess::visible, permissões por percurso e contexto. Referência, preparação e início previsto da minuta exigem contract ou contract_view; caso contrário mostram Sem acesso. Não devolve termos, fundamentos, identidades de candidatos, pontuações nem conteúdos financeiros. Impressão segue a página; CSV inclui todos os resultados filtrados, com as mesmas restrições e neutralização de fórmulas também nas referências contratuais. Período refere criação dos processos; datas de proposta/decisão são campos factuais, não novos filtros. Resumo por estado mantém âmbito completo, detalhe apenas página actual; CSV mantém leitura consistente.

Verificações: 78 testes/1839 asserções de PeopleHiringTest, WorkContextTest e CandidateSubmissionsTest passaram. Novos casos cobrem ambos os roteiros, devolução, reapresentação, aprovação, minuta, metadados contratuais reservados, CSV e expiração da participação. TypeScript, lint/formatação, compilação e análise PHP passaram. scripts/people-reports-check.mjs confirmou em HTTP local os três relatórios e respectivas exportações. Sem migração, grants, alteração de dados de negócio ou revisão visual por capturas. Próxima continuidade proposta: relatório de prazos e responsabilidades, reutilizando a mesa de trabalho existente; formalização/assinatura/admissão continuam fora deste incremento.

Relatório de prazos e responsabilidades — 01/11/2026

Acrescentado /pessoas/relatorios?view=deadlines, com atalho e selector na página de relatórios, impressão e CSV. PeopleDeadlineReport deriva exclusivamente de PeopleWorkdesk::build no âmbito autorizado e filtrado do utilizador. Não duplica regras de atribuição, independência ou tarefas, nem cria prazos, intervenientes ou notificações. Tarefas/conferências representam a intervenção autorizada do próprio utilizador; alertas do processo não atribuem culpa nem responsabilidade pessoal. Não é uma listagem de toda a equipa ou de toda a sua carga de trabalho.

Atraso em dias de calendário usa a data da consulta no fuso da aplicação; prazo de hoje resulta zero, prazo desconhecido mantém null/Não determinável. Não interpreta ausência de prazo como tarefa em dia. O mesmo processo pode ter várias ocorrências (tarefas/alertas), explicitamente. Contadores/detalhe no ecrã referem processos da página; CSV percorre todos os processos filtrados. O resumo existente por estado continua a referir todos os processos filtrados. Datas de filtro são criação de processos, não vencimentos de tarefas. Conteúdos reservados de esclarecimentos, entrevistas, avaliações e contratos não são incluídos; referências e ligações conduzem ao percurso individual autorizado. Respostas privadas sem cache e leitura consistente existentes preservadas. Sem migração, dados de negócio/grants alterados ou integração RH.

Verificações: 80 testes/1903 asserções em PeopleHiringTest, WorkContextTest e CandidateSubmissionsTest passaram. Cobrem intervenção própria/alerta, atraso, prazo ausente e expiração de acesso, além dos relatórios anteriores. TypeScript, lint/formatação, compilação e análise PHP passaram. HTTP local verificou quatro vistas e quatro CSV, em scripts/people-reports-check.mjs, sem comandos de negócio; prova docs/proofs/people-deadlines-report.json e people-reports-http.json. Sem revisão visual por capturas. Relatórios da equipa completa, atribuição de novos prazos e formalização contratual não são prometidos por este incremento; ampliar exigiria percurso próprio e autorização funcional correspondente.

Prazos: filtros, totais completos e paginação por ocorrência — 01/11/2026

Relatório deadlines evoluiu com filtro opcional deadline_window: todos, vencidos, hoje, futuros e sem prazo. Datas comparadas no dia local da consulta; prazo de hoje não é atraso, ausência de prazo permanece desconhecida. Filtros de percurso, estado, pesquisa e criação dos processos continuam aplicados antes de obter a mesa de trabalho autorizada. O filtro de prazo actua sobre ocorrências derivadas, sem alterar tarefas nem criar datas.

Reconcilia a limitação anterior: totais agora abrangem TODAS as ocorrências filtradas, e não só os processos da página. Apresenta número de processos considerados, processos com ocorrências e total destas, sem confundir ocorrências com pessoas/processos. Lista própria de 25 ocorrências por página (deadline_page), ordenada por maior atraso e data, CSV completo independente da página seleccionada; exportação inclui filtro de prazo e data de consulta. Impressão identifica página e totais. Resumo/lista genéricos de processos ficam fora desta vista para não misturar bases diferentes. Filtros foram colocados antes dos resultados nos quatro relatórios, facilitando a consulta sem atravessar listas longas.

Verificação: 82 testes/2028 asserções de Pessoas, candidaturas e contextos passaram; inclui futuro/hoje/vencido, valores inválidos, desconhecido fora de atrasos, totais e duas páginas de 30 tarefas de um único processo, CSV integral mesmo ao pedir página 2. TypeScript, lint/formatação, compilação e análise PHP passaram. HTTP local dos quatro relatórios/CSV e dos quatro filtros passou; sem revisão visual por capturas, migração, grants ou dados de negócio alterados. Prova: docs/proofs/people-deadline-filters.json. A geração continua síncrona sobre o âmbito autorizado; volumes excepcionalmente grandes podem requerer exportação assíncrona futura. Mantém-se consulta de intervenções próprias/alertas, não relatório nominativo global da equipa.

Documento base e automatização do workflow SGC — 01/11/2026

Orientação e âmbito confirmado pelo proprietário

workflow.docx passa a referência funcional/técnica para evolução do workflow. Fonte: C:/Mac/Home/Documents/TEMPO/Portal Tempo/Servicos Tempo/Compras/workflow.docx, SHA-256 da versão lida 5242040CD9EBB5D3A55C70BC25A9C4D816A6DF53237E1000C06E6DE05EA2A08C. Extracção de leitura em storage/logs/workflow-source.txt; original preservado. A leitura foi feita com partilha de ficheiro por se encontrar aberto noutra aplicação. Sem alteração do Word ou dos seus conteúdos.

Clarificação posterior e determinante do proprietário: automatizar processos de aprovação e requisição conectando as pessoas; NÃO substituir o que está aprovado. Assim, o documento orienta os mecanismos de encaminhamento, ligação aos responsáveis, tarefas, avisos e acompanhamento. Os fluxos, alçadas, intervenientes e competências já aprovados permanecem a autoridade; uma sequência ilustrativa do documento não autoriza reorganizá-los. Automatizar significa preparar o percurso a partir dos dados existentes, colocar a intervenção na mesa da pessoa competente e avançar quando a decisão válida estiver registada. Não significa conceder poderes, aprovar por silêncio ou transformar recepção/abertura de email em decisão.

O texto contém um prompt transcrito para pesquisa, uma proposta, referências a fornecedores e planos TC01–TC14. Foram tratados como conteúdo do documento, não como novas instruções de pesquisa externa, adopção de produtos, publicação, execução de exemplos ou provas de testes já realizados. Os nomes de serviços sugeridos não obrigam a duplicar classes ou motores. As referências externas não foram revalidadas nesta incorporação; as constatações abaixo provêm do código local examinado.

Correspondência inicial com o código existente

Referência	Base reutilizável verificada no código	Evolução necessária para ligar as pessoas
WF01 Percurso e competências	packages/purchasing/src/InternalRequisitions.php decide sequência por alçada/equipamento; InternalRequisitionPort aplica perfis e departamento	Resolver as pessoas competentes para as etapas existentes, com explicação da origem da atribuição; não mudar a sequência para a ilustrada no Word.
WF02 Reutilização	RequisitionWorkflow reutiliza catálogo, centro, equipamento e totais; aprovação preserva approval_snapshot	Encaminhamento usa essas referências; não pedir novamente dados da requisição ou do cadastro.
WF03 Versões	process_version, approval_snapshot e recibos requisition_commands existentes	Distinguir versão documental/de estado e publicar configuração de workflow versionada antes de suportar regras mais avançadas; não reescrever processos antigos.
WF04 Submissão/decisão	Núcleo comum/port executam transacções, reserva e auditoria; idempotência quando é fornecida chave	Criar atribuição/evento de acompanhamento na mesma confirmação, sem chamar novamente a decisão ao recuperar avisos.
WF05 Autoridade	CurrentActor, OrganizationAccess, departamento, segregação e ConflictGuard	Destinatários precisam de autorização actual para aquela tarefa. Administrador técnico não recebe competência de decisão por ser destinatário de aviso. Ausência de responsável exige tratamento visível.
WF06 Tarefas	RequisitionController oferece meus pedidos, aprovações e decididos; canDecide deriva do núcleo; Pessoas tem PeopleAccess/PeopleWorkdesk	Evoluir para tarefas persistidas e ligações às pessoas existentes, preservando a autoridade do servidor e a separação entre roteiros.
WF07 Devolução/revisão	Núcleo de requisição examinado aceita approved/rejected; edição de draft; outros domínios têm revisões próprias	Devolução para correcção, retirada e nova submissão não estão demonstradas como ciclo completo da requisição neste núcleo. Qualquer adição deve preservar versões/decisões e tratar ordem emitida pelo percurso específico.
WF08 Paralelismo	Requisição actual é sequencial; Pessoas tem avaliações independentes e decisão própria	Não converter a sequência aprovada em paralelo automaticamente. Só acrescentar paralelismo onde a política aplicável o exigir, com tarefas distintas e conclusão única.
WF09 Delegação	Perfis, participações com prazo e funções existentes	Não equivalem a delegação aprovada com representado/representante. Falta percurso específico de âmbito, validade, autorização e revogação coordenada.
WF10 Prazos	Pessoas reutiliza prazos existentes, atraso factual e desconhecido sem inventar datas	Configurar calendários úteis, prazos por etapa e escalonamento antes de os calcular; não substituir dias de calendário já apresentados por dias úteis silenciosamente.
WF11 Avisos	Núcleos de decisão/auditoria existentes; não foi demonstrada caixa de saída transaccional completa do workflow	Implementar eventos persistidos, notificações internas por destinatário e recuperação; email depende de canal configurado. Falha de aviso não desfaz decisão nem a repete.
WF12 Recuperação de entrega	Proposta distingue PENDING, PROCESSING, ACCEPTED, UNKNOWN e restantes estados	Conservar evento/chave/tentativas, revalidar acesso e tratar incerteza antes de reenviar. Não prometer email único ou leitura sem comprovativo do canal.
WF13 Finanças e execução	BudgetWorkflow, PurchaseWorkflow, ReceiptWorkflow e InvoiceWorkflow próprios	Ligar estados de acompanhamento por referência, sem criar outro saldo, dívida, pagamento ou processo de compras. Aprovação de requisição não é autorização de pagamento.
WF14 Pessoas	PeopleHiring, PeopleAccess, tarefas e quatro relatórios já existentes	Reutilizar componentes comuns de ligação/tarefas, conservando candidatos, critérios, equipas e decisões no roteiro próprio. Não converter candidatura numa requisição.
WF15 Provas	Testes locais de requisição/núcleo comum e outras provas já guardadas	Mapear TC01–TC14 para implementações efectivas e executar disputas reais em PostgreSQL quando o mecanismo existir. Não marcar casos futuros como passados.

Sequência de aplicação compatível com o aprovado

1. Inventariar etapas e responsabilidades aprovadas e relacioná-las com perfis, funções, departamentos, centros e equipas actuais. Identificar responsáveis ausentes/ambíguos sem criar novas contas ou conceder poderes por omissão.
2. Acrescentar atribuições e mesa de tarefas sobre o núcleo existente, com versão de origem, prazo quando configurado, responsável e ligação directa à intervenção autorizada. Manter consultas sem efeitos de negócio.
3. Acrescentar avisos internos e eventos de saída duráveis; confirmar tarefa/decisão/estado/auditoria atomicamente. Não enviar mensagens externas nesta etapa sem configuração e autorização próprias.
4. Acrescentar lembretes, substituições/delegações e escalonamento conforme as regras aprovadas, depois de suportados os respectivos mecanismos de configuração e testes. Nenhuma ausência de resposta aprova automaticamente.
5. Completar devoluções/revisões e configuração versionada onde faltarem, sem substituir os percursos estáveis ou activar P1/P2 como se já existissem.

Limites/alçadas, moedas, responsáveis nominativos, feriados, tempos de concessão/tentativas e canais são configuração da organização; exemplos do Word não os fixam. Persistência histórica, isolamento empresa/contexto, papéis distintos, núcleo independente de IA e implementação única dos motores mantêm-se. Instalações existentes conservam o percurso aplicado; qualquer migração de instâncias exige mecanismo explícito e auditável, sem arrastar dados de avaliação para clientes.

Verificação desta incorporação

Leitura e confronto de RequisitionWorkflow, InternalRequisitionPort, núcleo InternalRequisitions, OrganizationConfiguration, PeopleWorkdesk e relatórios existentes. Quatro testes/34 asserções de InternalRequisitionCandidateTest passaram; 18 ficheiros dos núcleos distribuídos conferidos por SHA-256. Esta prova cobre a regressão dirigida existente, não implementa nem certifica todos os requisitos do Word/TC01–TC14. Nesta etapa só foi registada a base e a correspondência; não foram alterados estados, sequência de aprovação, base persistente, contas ou outorgas. Próxima implementação: ligar responsáveis e tarefas às etapas existentes, começando pelo diagnóstico de elegibilidade de encaminhamento.

Tarefas dos perfis e ligação às pessoas da etapa actual — 01/11/2026

Por orientação expressa do proprietário, a definição dos perfis deve indicar as tarefas exercidas para associação ao workflow. WorkflowTasks acrescenta catálogo de tarefas ligado às chaves de OrganizationAccess::PERMISSIONS, sem segunda fonte de concessão. Parametrização apresenta Tarefas e permissões do perfil, descrição das intervenções e resumo imediato das seleccionadas; guardar continua a usar o perfil/versionamento/auditoria/contextos existentes. Cada permissão mantém a abrangência anterior: as descrições não criam ainda selecção independente de cada subacção de uma capacidade abrangente. Todos os códigos de permissão existentes têm correspondência, com descrição específica para requisições e Pessoas e descrição funcional existente para os restantes.

ApprovalRouting consulta a etapa pendente real da requisição e identifica pessoas da mesma empresa para as quais Requisition::canDecide devolve autorização, excluindo manutenção. Reutiliza função, departamento, independência do requisitante/aprovadores anteriores, conflitos e acessos/contexto correntes. Devolve apenas id/nome, função, etapa, chave funcional da tarefa e instante da consulta. O detalhe da requisição apresenta Quem pode tratar a etapa actual e avisa quando não existe pessoa elegível. Vários elegíveis constituem fila actual, não atribuição exclusiva; não escolhe arbitrariamente uma pessoa. Perfil administrativo não implica aprovação. Processo não pendente não mantém uma fila activa. Consultar não grava tarefas, decisões, eventos de aviso ou auditoria de negócio.

Não muda sequência, etapas, alçadas, núcleo comum, reservas ou outorgas. O motor continua a revalidar ao decidir; esta consulta não é prova de autorização futura. Não foi criada nesta etapa atribuição persistida, tomada exclusiva, delegação ou envio de avisos. Próxima evolução: tarefas/avisos internos duráveis sobre esta ligação, preservando o executor efectivo e decisão do núcleo. Capacidades abrangentes ainda precisam de evolução coordenada no núcleo caso se pretenda seleccionar subacções separadamente; não simular separação só por texto/formulário.

Verificações: 40 testes/403 asserções de InternalRequisitionCandidateTest, OrganizationConfigurationTest e WorkContextTest passaram. Novos casos cobrem elegibilidade, departamento, outra empresa, revogação de função, administrador sem poderes adicionais, ausência de alterações ao processo/auditoria e catálogo completo nas parametrizações. TypeScript, lint/formatação, compilação, análise PHP dos serviços e integridade dos 18 ficheiros de execução passaram. HTTP local conferiu catálogo e detalhe de requisição existente: proofs/approval-routing-http.json. Sem migração, alteração de dados persistentes/grants ou revisão visual por capturas. Prova consolidada: proofs/approval-routing.json.

Avisos internos ligados às etapas de aprovação — 01/11/2026

Migração 46 acrescenta workflow_notices com origem na requisição/etapa, destinatário, referência, função, criação e leitura; unicidade por etapa/destinatário. InternalRequisitionPort chama WorkflowNotices::capture após submissão/decisão, dentro da transacção do núcleo existente. Elegibilidade usa ApprovalRouting e canDecide, sem mudar funções, sequência, alçadas ou criar aprovações. A repetição idêntica recupera o recibo do núcleo sem recriar avisos. Se a persistência do aviso falhar, decisão/submissão, reserva, auditoria e recibo da operação são revertidos juntos. Sem migração instalada, instalações existentes mantêm o percurso e a página informa instalação pendente; não bloqueia decisões por ausência de um adicional ainda não instalado.

GET /requisicoes/avisos mostra apenas avisos do destinatário na empresa/contexto actual, com etapa ainda pendente e autorização actual. Fila paginada, por ler e ligação ao processo. Etapa concluída, conflito, participação anterior incompatível ou acesso revogado retiram o aviso da lista activa sem apagar a origem. Marcar como lido é POST autenticado, com bloqueio da empresa, revalidação, auditoria e efeito idempotente; não decide, reserva, avança ou altera a requisição. Manutenção não recebe nem consulta fila operacional. Administrador não recebe avisos financeiros por ser administrador. Nenhum email, chamada externa ou confirmação de leitura de canal foi enviado/inferido.

Este incremento é entrega interna na própria base, não executor externo/outbox de email. Não inclui garantias de entrega a canais externos, delegação, tomada exclusiva, agendamento, lembretes, reencaminhamento de instâncias antigas nem notificações de decisão ao requisitante. Perfis alterados depois da criação podem retirar acesso imediatamente; novos destinatários em etapas já abertas continuam a consultar Pendentes para mim, mas ainda não recebem aviso retroactivo. Dados e avisos anteriores conservados; não existe varredura de negócio em GET para os recriar.

Instalação local 8005 efectuada por scripts/supply-install.php --notices, com identidade do destino conferida, backup privado e restauro em base descartável verificado; 106 tabelas existentes preservadas, nova tabela vazia e sem contas/grants/dados sintéticos. Proofs/workflow-notices-install.json. Domínio não instalado. Verificação dirigida passou 42 testes/455 asserções de requisição/configuração/contextos; análise PHP, formatação e 18 ficheiros dos núcleos conferidos. HTTP local confirmou página pronta. Verificação geral e PostgreSQL estão a ser concluídos e serão registados a seguir; não confundir com execução dos TC01–TC14 completos.

Resultado final dos avisos internos: bateria geral 891 testes, 889 passaram, dois ignorados, 9236 asserções; sem falhas. PostgreSQL descartável: 21 testes/244 asserções de InternalRequisitionCandidateTest e WorkContextTest passaram, com base removida no finally. Tipos, compilação final, lint, análise PHP e HTTP local passaram. Prova consolidada: docs/proofs/workflow-notices.json.

A tentativa de incluir OrganizationConfigurationTest inteiro no executor PostgreSQL revelou um teste existente de relatório que usa a transacção externa de RefreshDatabase, incompatível com a exigência já existente de transacção própria de leitura de ProcurementReviewReport. O erro foi diagnosticado explicitamente; não se alterou a guarda do relatório nem se marcou esse caso como passado em PostgreSQL. Organização está coberta pela bateria geral habitual; o executor PG deste incremento foi limitado aos dois ficheiros que verificam requisição/avisos/contexto, sem novos testes ignorados. Isto não demonstra execução da matriz concorrente TC01–TC14 completa. Próxima evolução: reencaminhamento controlado quando mudam perfis/destinatários de etapas já abertas e avisos de resultado ao requisitante, sem repetição da decisão.

Avisos de resultado ao requisitante — 01/11/2026

WorkflowNotices::outcome reutiliza workflow_notices da migração46 para avisar o requisitante quando a requisição termina approved/rejected. Destinatário vem da origem, função/decisão vêm da etapa efectivamente concluída e a unicidade etapa/destinatário já existente impede duplicação. O requisitante nunca integra a fila decisora da própria requisição, pelo que os avisos de resultado são distinguíveis das intervenções pendentes sem alterar os registos antigos ou acrescentar outro motor. Gravação ocorre no port da decisão, na mesma transacção do núcleo e antes da confirmação final; falha do aviso reverte decisão, auditoria, recibo e efeitos orçamentais. Repetir uma operação já confirmada recupera o recibo, sem recriar o aviso.

Página /requisicoes/avisos passa a separar intervenções pendentes, resultados dos meus pedidos e por ler. Entrada de menu disponível também ao requisitante, sempre sujeita ao contexto e acesso no servidor. Resultados permanecem visíveis ao autor com acesso actual mesmo após terminar a intervenção de aprovação; avisos de tarefas terminadas continuam fora da fila. Cada resultado apresenta o facto aprovado/rejeitado e o estado actual separadamente, incluindo eventual cancelamento posterior, sem apresentar o facto histórico como estado vigente. Comentários, fundamentos internos, montantes e conteúdos de terceiros não são copiados para o aviso; ligação leva ao processo autorizado.

Consulta/leitura revalida destinatário, empresa, contexto, permissões actuais e exclusão de manutenção; outro interveniente não pode ler ou marcar aviso do requisitante. Ler continua sem efeito de aprovação ou pagamento. Sem email, novo schema/migração, retroactividade de decisões antigas, grants, contas ou dados sintéticos. Reencaminhamento de perfis alterados, lembretes, delegação e envio externo continuam fora desta etapa.

Verificações: 45 testes/573 asserções de requisição/configuração/contextos passaram; PostgreSQL descartável24 testes/362 asserções de requisição/contextos passaram. Casos novos cobrem approved/rejected, duplicação, leitura idempotente, outro destinatário, estado posterior distinto do resultado e reversão integral por falha de persistência. TypeScript, lint/formatação, compilação, análise PHP e integridade18 ficheiros de núcleo passaram. HTTP local confirmou as três vistas de avisos e dados de parametrização/encaminhamento sem criar decisões. Prova docs/proofs/workflow-outcomes.json. Sem revisão visual por capturas; bateria geral anterior permanece prova de base, não se atribuem os seus números a uma nova execução desta etapa.

Actualização controlada do encaminhamento — 01/11/2026

Acrescentada acção recolhida Actualizar encaminhamento no detalhe da requisição pendente, disponível a Administração/Compras com acesso efectivo e fora de manutenção. Exige motivo, etapa esperada, process_version e chave da operação. Não permite escolher destinatário livremente: WorkflowNotices::refresh reutiliza ApprovalRouting::current/canDecide e cria apenas avisos ainda inexistentes para os elegíveis actuais. Não altera o percurso, competências, etapa, orçamento, versão da requisição ou decisões. Não envia email e não cria delegação/atribuição exclusiva.

Comando POST /requisicoes/{id}/encaminhamento bloqueia empresa, revalida o operador e bloqueia a requisição; guarda a auditoria workflow.routing_refreshed com motivo, etapa e destinatários antes/depois. A auditoria imutável conserva o recibo lógico (operation_key e assinatura) neste âmbito; repetição igual não volta a gravar auditoria ou avisos, conteúdo diferente com a mesma chave é recusado. Etapa/versão alteradas produzem erro de formulário legível, sem voltar a encaminhar outra etapa. Antes de recuperar um recibo, acesso actual à requisição e competência do operador voltam a ser conferidos.

Avisos antigos e read_at são preservados; pessoas revogadas deixam de consultar a fila pela revalidação existente. Pessoa que recupera acesso à mesma etapa reutiliza o aviso original e a leitura anterior, não recebe um aviso duplicado. Falha de auditoria reverte os novos avisos na mesma transacção. Consultas não executam reconciliação nem modificam dados. A associação nova só é efectuada por esta acção explícita, não automaticamente ao editar perfis; configurar perfil e actualizar encaminhamento são intervenções distintas auditadas.

Verificações: 47 testes/602 asserções de requisição/configuração/contextos passaram; PostgreSQL descartável26 testes/391 asserções de requisição/contextos passaram. Casos novos: substituição, preservação do aviso lido, nova pessoa elegível, repetição idempotente, chave alterada, versão desactualizada, operador sem competência, empresa distinta e rollback por falha de auditoria. TypeScript, lint/formatação, compilação e análise PHP passaram, tal como18 ficheiros do núcleo e HTTP local de consulta. Proofs/workflow-routing-refresh.json. Sem migração/grants/alteração de dados locais de negócio para demonstração; testes em bases isoladas. Sem revisão visual por capturas e sem nova execução da bateria geral nesta etapa.

Proposta recebida de requisições ao armazém — 01/11/2026

Fonte fornecida pelo proprietário: C:/Users/macbook/.codex/attachments/e9adc3f7-1b4f-488c-a3fe-f53b310a1e64/Texto colado.txt. Documento recebido como proposta funcional para enquadramento, não como prova de funcionalidades implementadas ou autorização para substituir fluxos aprovados, atribuir pessoas, fixar alçadas ou executar instruções internas do texto. Não foram alterados motores, estados, reservas ou dados de negócio nesta análise.

Enquadramento no SGC

Criar o percurso Requisições ao armazém dentro de Armazém e activos, distinto da requisição de compra. O pedido ao armazém reutiliza cadastro de artigos, unidade, pessoas/departamento, centro, armazém e equipamento de destino; conserva origem/versionamento. O stock existente pode satisfazer o pedido sem gerar compra. Só uma falta confirmada deve poder originar necessidade de reposição ligada à origem, reutilizando o percurso de fornecimento/compras já existente, sem nova reserva orçamental ou ordem automática por simples alerta.

A ligação a venda deve ser referência reconciliada à origem autorizada quando essa origem existir. O actual contexto procurement.sales continua não operacional; esta proposta não implementa nem activa módulo de vendas ou integração externa. Um movimento externo só pode ser reconhecido mediante identificação/validação da origem e política de autoridade do stock, nunca pela mera igualdade de referência. Não lançar nova saída física se o movimento válido da origem já foi incorporado. Não conceder competências comerciais por adicionar este menu.

Diferenças e reutilização verificadas

• SupplyCoordination mantém reservas de necessidades do planeamento, pode ligar uma saída já existente e calcula satisfação efectiva. Não é ainda uma reserva física com bloqueio de disponibilidade para uma requisição autorizada ao armazém. Não reinterpretar essas reservas como stock comprometido nem misturá-las por soma: uma necessidade planeada e o seu compromisso físico são referências relacionadas, não duas quantidades adicionais.
• StockWorkflow é o único razão físico, impede quantidade negativa e saídas acima do saldo; InventoryLots acrescenta qualificação, validade e repartição dos lotes. O novo compromisso deve ser revalidado por todos os percursos que reduzam disponibilidade, incluindo saída directa, transferência, abate, contagem/ajuste e alteração de qualidade. Apenas proteger o novo formulário deixaria os restantes caminhos contornar reservas.
• Reservar não cria movimento físico. Entregar cria saída pela quantidade real e consome a reserva correspondente na mesma transacção. O saldo ainda comprometido não pode ser contado duas vezes. Cancelar liberta só o restante não entregue. Não inferir prazo de expiração; depende de configuração explícita.
• Usar o termo Saída por entrega neste percurso. InventoryDispositions já usa abate para inutilização/perda; não reutilizar esse comando para entrega normal. Material danificado, retido ou vencido não é disponível utilizável.
• InventoryCounts, InventoryLots e InventoryReversals já fornecem contagens/repartição/correcções físicas. Não bastam para declarar pronta a nova devolução do destinatário: a devolução deve ter recepção/qualidade e vínculo à saída de atendimento, sem reabrir o compromisso automaticamente. Preservar a semântica histórica de correcções de necessidades do planeamento, hoje distinta.
• Perfis/workflow devem explicitar tarefas de solicitar, decidir, conferir tecnicamente quando aplicável, preparar, entregar, confirmar recepção e regularizar; pessoas existentes recebem as funções pela parametrização, sem auto-aprovação nem contas/outorgas automáticas. Reutilizar tarefas/avisos comuns sem confundir o pedido de compra com o pedido ao armazém.

Requisitos de implementação e aceitação a conservar

1. Pedido e linhas com referência única, origem, versões, destino e unidades do cadastro; percurso rascunho/submissão/decisão/autorização/preparação/parciais/entrega/encerramento e rejeição/cancelamento, condicionado à matriz que a organização definir. Não activar uma nova matriz com os papéis ilustrativos do documento como se já fossem outorgas reais.
2. Compromisso por linha/artigo/armazém, com quantidade autorizada, entregue, libertada e restante; disponibilidade utilizável menos compromissos activos, sempre na mesma unidade. Política explícita quando uma mudança de qualidade ou contagem reduzir o disponível abaixo do comprometido: identificar divergência/necessidades, sem libertar ou ajustar fisicamente por suposição.
3. Confirmar reserva e entrega sob disciplina comum de bloqueios, versões, idempotência e auditoria. Para vários artigos, confirmar o conjunto integral ou parcial expressamente autorizado; não produzir sucesso parcial acidental. Definir ordem global compatível com o bloqueio de empresa e motores existentes.
4. Entregas parciais dentro do autorizado, identificação de destinatário/entregador e recepção distinta; responsabilidades de uso/devolução quando aplicáveis. Alteração de itens/quantidades/destino após autorização exige nova avaliação, sem reescrever a decisão antiga.
5. Mínimos e alertas reutilizam parametrização artigo/armazém onde aplicável, com responsável e tratamento rastreável. Não geram compra, saída ou alçada automática. Os actuais mínimos/projecções não provam encaminhamento operacional concluído de uma ruptura.
6. Reconciliação de compromissos com fotografia consistente, detecção de órfãos/duplicações/expiração/entregas já consumidas, ocorrência e correcção independente, idempotente e auditada. Sem apagar histórico, libertar por antiguidade presumida ou converter diferença reservada em ajuste físico.
7. Conservar CA-01–CA-09, cenários de venda/interno/parcial/cancelamento/devolução/duplicação e reconciliação como plano de aceitação. Testes concorrentes em PostgreSQL descartável com sobreposição real; não declarar esses critérios passados com base nas provas de lotes/stock ou dos avisos anteriores.

Sequência proposta para o desenvolvimento

Primeiro consolidar contrato de dados e responsabilidades com os cadastros/configurações existentes; depois pedido/autorização e compromisso físico; em seguida entrega parcial atómica no único StockWorkflow; por fim confirmação de recepção, devolução, reconciliação, alertas e integrações dependentes. Não disponibilizar compromisso físico enquanto os outros caminhos de saída puderem ignorá-lo. Séries, lotes, validade e integrações são requisito de arranque nos âmbitos que deles dependam, mesmo que classificados P2 no documento. Limites, calendários, expiração, alçadas e origem autoritativa de vendas continuam a ser configuração organizacional, não valores inventados pelo desenvolvimento.

Esta incorporação é análise/documentação. Nenhum novo percurso foi activado, e não foram executados testes funcionais por não haver alterações de aplicação nesta etapa. Próxima acção concreta, se avançar esta proposta: especificar o vínculo entre necessidade planeada, pedido ao armazém e compromisso físico antes de alterar o motor de disponibilidade.

Disponibilidade para requisições ao armazém e regra de compra — 01/11/2026

/stock/disponibilidade acrescenta consulta por armazém e pesquisa de artigos, paginada, sobre o único StockWorkflow e InventoryLots. Mostra físico, utilizável pelos controlos activos, retido/indisponível, necessidades planeadas e mínimo aprovado. Os saldos são obtidos na mesma transacção de leitura consistente; quantidade/unidade não são convertidas. Sem controlo por lote essa limitação é visível; repartição divergente mantém utilizável/retido por determinar. Necessidades planeadas não são subtraídas como compromisso físico: este continua null/não implementado, nunca zero presumido. Mínimo só é reutilizado de política aprovada com cadastro preservado compatível; procura ou política desconhecida não se inventam.

Acesso reutiliza as competências já autorizadas para consulta de stock e acrescenta capacidade warehouse_availability_read, configurável e sem outorga automática. Necessidades/mínimos de planeamento exigem essa capacidade ou leitura/reserva de fornecimento/admin; outros leitores de stock não recebem acesso a planeamento por arrasto. Empresa/contexto e armazém validam no servidor. A consulta não cria reserva, pedido, compra, movimento ou aviso. Menu Disponibilidade para requisições em Armazém e activos. Sem migração ou alteração dos processos existentes.

O proprietário clarificou durante esta etapa: inexistência de stock ou atingir mínimo DEVE despoletar requisição de compra. Orientação incorporada em AGENTS.md. A geração automática ainda não está implementada nesta consulta, que o diz expressamente. Deverá partir de política/necessidade autorizada por artigo/armazém, determinar quantidade/reposição, requisitante e centro de custo a partir de configuração, evitar duplicação com reposição efectiva em curso e criar a requisição ligada à origem para seguir aprovações normais. Não converter uma alerta de leitura numa compra por si só; executar a geração por comando/transição/agendamento autorizado com idempotência e revalidação. Antes de gerar, conferir pedidos/ordens em curso e saldo utilizável; um pedido antigo cancelado ou insuficiente não pode suprimir reposição indefinidamente. Não inventar preços, quantidades, alçadas ou identidade do requisitante.

Verificações desta consulta: 16 testes/123 asserções de WarehouseAvailabilityTest, SupplyCoordinationTest e InventoryLotPolicyTest passaram; inclui saldo físico10 versus necessidade planeada20 sem subtracção, mínimo atingido, leitura sem movimento, armazém de outra empresa e acesso reservado. TypeScript, lint/formatação, compilação e análise PHP passaram. Sem revisão visual por capturas. Esta prova não certifica geração automática, reserva física nem CA01–09 da proposta de requisições ao armazém. Próxima implementação: configuração e geração idempotente da requisição de compra a partir da necessidade, em conjunto com o contrato do pedido ao armazém e do compromisso físico.

Destino obrigatório da requisição ao armazém — clarificação do proprietário, 01/11/2026: explicitar onde será usado. Uso interno identifica destino/unidade/local/finalidade; material para equipamento exige equipment_id proveniente do cadastro autorizado e compatibilidade quando aplicável; venda exige ligação à factura de venda e respectivas linhas/quantidades. Documentos e equipamentos devem ser seleccionados/referenciados, sem reintroduzir cadastro ou inferir identidade por nome. A linha deve conservar o destino aplicado, permitindo destinos distintos por linha se o pedido reunir usos diferentes; a interface só pede dados do destino aplicável. Eventual falta e requisição de compra resultante conservam o vínculo à necessidade/destino original, sem copiar a requisição inteira como se fosse nova necessidade independente.

Facturas hoje tratadas por InvoiceWorkflow são de fornecedor: não as reutilizar como factura de venda por igualdade do termo. O actual percurso comercial/vendas continua não operacional; a referência de venda requer origem autorizada e reconciliação de artigos/quantidades/movimentos antes de disponibilizar esse cenário. Ligação a factura não pode duplicar saída já efectuada noutro sistema. Esta clarificação foi registada como requisito e não foi apresentada como campo/pedido ao armazém já implementado. A consulta de disponibilidade entregue nesta etapa continua sem criar pedidos ou movimentos.

Registo inicial de requisições ao armazém com destino — 01/11/2026

Implementado /stock/requisicoes com rascunhos próprios, listagem autorizada e consulta dos dados preservados. Nova tabela warehouse_requests (migração47) regista origem interna, armazém, requisitante/departamento, centro de custo, prioridade, local/finalidade e linhas com snapshot de artigo/unidade/quantidade. Número de apresentação RA-id único. Equipment destino seleccionado do cadastro do departamento quando use=equipment; peças cadastradas passam por EquipmentWorkflow::linkedPart. Em uso interno, as linhas herdam o local comum indicado; a associação a equipamento permanece explícita por linha. Quantidade positiva com três casas decimais, sem conversão de unidade e sem preços artificiais.

WarehouseRequests::draft bloqueia empresa, revalida identidade/permissões, valida centros do departamento e fontes da empresa, guarda snapshot e auditoria atomicamente. Operação única por empresa/autor/chave; repetição idêntica recupera documento, conteúdo diferente é recusado. Mudanças futuras do catálogo não reescrevem o snapshot. Modelo não admite update/delete pela aplicação; edição/versionamento de rascunhos ainda não oferecidos nesta etapa. Registo não altera stock, reservas, orçamento, requisições de compra ou estado de aprovação. Ainda não existem comandos de submissão/autorização/entrega deste percurso; a interface esclarece esse limite.

Tarefas configuráveis novas warehouse_request_prepare e warehouse_request_read, visíveis no catálogo de perfis. Preparador consulta os seus documentos; consulta da empresa exige read/admin, sem concessão automática de preparação ao administrador. Manutenção não cria rascunhos. Dados de artigos/centros/equipamentos para preparação só são enviados ao preparador autorizado. Contexto/empresa preservados, respostas sem cache e histórico Inertia cifrado. A selecção de origem de venda/factura de venda continua indisponível: o SGC actual não oferece fonte comercial autoritativa operacional e facturas de fornecedor não a substituem. Não aceitar uma referência inventada como ligação validada.

Stock mínimo/inexistente continua requisito de geração de compra a implementar por configuração/origem autorizada, sem compras em GET e sem novos poderes. Reserva física, autorização, entrega, parciais, compra por falta, factura de venda, edição versionada e reconciliação não estão concluídos por este registo inicial; não apresentar rascunho como pedido autorizado ou compromisso de stock.

Instalação em8005 via supply-install.php --warehouse-drafts, com backup/restauro verificados,107 tabelas existentes preservadas, tabela nova vazia, sem contas/outorgas/dados sintéticos. Prova proofs/warehouse-drafts-install.json; domínio não instalado. Testes:81/809 asserções (rascunhos, disponibilidade, equipamentos, requisições, configuração e contextos) passaram; PostgreSQL descartável6/66 passaram. Tipos, lint/formatação, compilação e análise PHP passaram. HTTP local confirmou página instalada e administrador sem preparação automática. Sem revisão visual por capturas; proofs/warehouse-drafts.json. Próxima acção: editar/versionar rascunhos e implementar submissão/autorização configurada, antes do compromisso físico e entrega.

Decisão confirmada do proprietário — documento de saída interno e venda no SGF (01/11/2026): uso interno não tem factura. A requisição autorizada é o documento de saída do armazém; só a entrega física confirmada gera o movimento pela quantidade efectivamente entregue. Preparação/aprovação não abatem stock, e entrega parcial conserva saldo pendente. A opção de venda a terceiros será incorporada no SGF, que já dispõe de facturação, gestão de stock e contabilidade; nessa composição a requisição associa-se à factura de venda e reutiliza os mecanismos do SGF, sem duplicar movimentos ou motores. Esta decisão esclarece o âmbito comercial da proposta anterior e substitui qualquer interpretação de exigir factura no uso interno ou de criar facturação de vendas autónoma no SGC. Não remove por inferência compras/importações para revenda; trata do atendimento de vendas e documento de saída. Orientação incorporada em AGENTS.md; nesta confirmação não houve alteração de código, dados ou instalação e não foram necessários novos testes.

Autorização e entrega de requisições internas sem factura — 01/11/2026

Implementado percurso derivado de eventos: rascunho → submetida → autorizada → parcialmente entregue/entregue → encerrada com recepção confirmada; rejeição a partir da submissão. O documento original WarehouseRequest continua preservado; eventos imutáveis WarehouseRequestEvent guardam actor nominativo, versão, motivo, dados usados e data. Não se reescreve o rascunho nem se cria factura. Documento /stock/requisicoes/{id}, imprimível com destino/equipamento, quantidades pedidas/entregues/pendentes, decisões, lotes através da operação de stock referida, entregador, destinatário e confirmações. RA-id e cada evento de entrega referenciam as operações físicas correspondentes.

Tarefas configuráveis novas warehouse_request_review (departamento) e warehouse_request_deliver (em conjunto com warehouse). Não houve outorgas automáticas. Requisitante submete e confirma recepção das entregas; não autoriza nem entrega o próprio pedido. A decisão exige responsável independente do mesmo departamento; quem autorizou não pode entregar. Leitura por tarefa/empresa/contexto é aplicada no servidor e nos menus; administração apenas lê se não tiver a tarefa operacional atribuída. Os avisos do workflow de requisição de compra não foram estendidos automaticamente a este novo domínio.

O requisitante aceita ou não entregas parciais na submissão, e o autorizador só pode permiti-las quando foram aceites. Autorização integral confere saldo utilizável agregado por artigo/armazém; autorização parcial preserva a disponibilidade conferida e admite necessidade ainda por atender. Artigos/unidades/equipamentos usados são revalidados por comparação com a origem preservada; alterações incompatíveis exigem novo rascunho conferido. A configuração actual usa uma decisão departamental independente, sem inventar alçadas/limites monetários ou matriz técnica adicional; evolução desses critérios deve ser configurada e revista.

Entrega regista apenas as quantidades efectivas positivas dentro do saldo autorizado de cada linha. Sem autorização para parcial, exige todas as quantidades pendentes. Usa StockWorkflow::record(kind=issue), o único razão existente, com validação de peças/equipamento e repartição/qualificação de lotes vigente. Não há novo motor de stock nem efeitos orçamentais/facturação. Disponibilidade é revalidada imediatamente na saída; falta/quarentena/validade ou erro numa linha revertem o conjunto completo. A transacção engloba operações físicas, evento do documento e auditoria; idempotência empresa/actor/chave e versão impedem repetição e entrega de uma página desactualizada. Confirmar recepção exige o requisitante e uma entrega concreta ainda não confirmada; não lança novo movimento físico. Entregas são registadas no instante real da operação, sem opção de retrodatação nesta etapa.

Limites explícitos: autorização NÃO reserva fisicamente stock exclusivo; outros movimentos podem alterar disponibilidade até à entrega. Não se promete compromisso físico nem cobertura dos CA01–09 de reservas. Totais entregues são factos históricos de saídas registadas; devolução/correcção deve continuar ligada ao movimento original e não autoriza redespacho automático do saldo. Cancelamento/versão de pedido já submetido, expiração, destinatário alternativo, conciliação de reservas, tarefas/avisos deste novo percurso e geração automática de compra por falta/mínimo continuam pendentes. O requisito de compra permanece em AGENTS.md e a interface informa que ainda não é executado; não foi simulado por consulta/alerta. Venda/facturação mantêm composição SGF. A requisição interna é o documento de saída, sem factura.

Instalação da migração48 apenas em8005 via --warehouse-events: backup e restauro verificados,108 tabelas existentes preservadas, nova tabela vazia e sem contas/grants/dados sintéticos. proofs/warehouse-fulfilment-install.json. Regressão dirigida passou85 testes/495 asserções; PostgreSQL descartável12 testes/122 asserções, mais duas disputas reais de bloqueio (mesma chave e chaves diferentes para a mesma entrega), passaram sem movimento duplicado. Tipos, lint/formatação, compilação, análise PHP,18 ficheiros dos núcleos e HTTP de consulta passaram. Bateria geral a concluir, resultado será acrescentado. Sem revisão visual por capturas; não declarar matriz integral da proposta concluída.

Verificação final da autorização/entrega: bateria geral908 testes/906 passaram/2ignorados/9508 asserções, sem falhas. PostgreSQL12/122 e2disputas reais já descritos; prova consolidada docs/proofs/warehouse-fulfilment.json. O acesso operacional exige atribuição explícita das tarefas warehouse_request_prepare/review/deliver e, para entregar, warehouse. Sem atribuições automáticas. Não se confundem estes resultados com reserva exclusiva ou geração automática de compras, que continuam pendentes.

02/11/2026 — Reserva física e reposição automática parametrizada

Este incremento substitui as pendências de reserva exclusiva e geração de compra descritas no registo anterior de autorização/entrega; não substitui decisões, requisições, políticas ou provas históricas.

A migração49 acrescenta warehouse_reservations, diário imutável com vínculo à requisição, linha, autorização, operador e comando. Autorizar reserva material utilizável livre, sem lançar saída. Na autorização parcial só se reserva a parte disponível. A entrega consome exactamente a sua reserva e lança o movimento no StockWorkflow, na mesma transacção do evento e auditoria. Cancelar o saldo exige revisão departamental independente do requisitante e liberta só a reserva ainda não consumida; entregas e recepções anteriores são conservadas. Actualizar reserva permite comprometer material que entretanto entrou, dentro da autorização e do saldo original. Pedidos autorizados antes desta instalação exigem esta actualização explícita, sem reserva retroactiva silenciosa.

O único StockWorkflow protege compromissos também nas saídas avulsas, transferências, correcções aprovadas, devoluções/abates e estornos que reduzam material utilizável. Quarentena, validade e retenções de qualidade continuam independentes: podem tornar material reservado indisponível, mas a entrega é impedida e o défice aparece na disponibilidade. Uma devolução ou estorno físico não reabre automaticamente a requisição nem recria reserva consumida. Reservas de SupplyCoordination continuam a ser planeamento e não são somadas como compromissos físicos.

Novo menu Armazém e activos > Reposição automática, /stock/reposicao. A regra reutiliza a política aprovada do artigo/armazém: mínimo, alvo, máximo e múltiplo de embalagem. Requisitante, centro de custo, prazo pretendido e vigência são parametrizados uma vez; reutiliza preço em MZN do acordo e imposto da empresa quando disponíveis, permitindo estimativas fundamentadas. Peças publicadas no catálogo reutilizam a peça cadastrada e exigem equipamento compatível no departamento do requisitante; uma origem com destino técnico diferente fica pendente para reconciliação. Equipamento novo e serviços mantêm os seus percursos próprios. Não se assume destino, pessoa, preço, conversão de unidade, taxa cambial ou competência ausentes.

A preparação usa supply_prepare e a activação/suspensão usa supply_review. Todos os preparadores da regra ficam impedidos de a activar. Alterar a regra exige nova activação e aplica-se às gerações futuras. O catálogo de tarefas dos perfis explicita estas responsabilidades. Sem grants ou contas adicionais. A regra activa permite somente preparar um novo rascunho pelo motor InternalRequisitions/RequisitionWorkflow em nome do requisitante parametrizado: revalida competência vigente no contexto interno e centro/departamento, conserva o executor autenticado na auditoria e não muda a autenticação para fingir acção pessoal do requisitante. A configuração não permite submeter, aprovar, reservar orçamento, adjudicar, encomendar ou lançar saída automaticamente.

Após confirmação das alterações de stock, lotes, pedidos ou requisições de compra associadas, a avaliação corre sob o mesmo bloqueio de empresa. Considera stock utilizável menos compromisso físico, saldo ainda não reservado dos pedidos e reposição efectiva já em curso. Calcula a quantidade com aritmética inteira e regras aprovadas; embalagens que excedam o máximo ficam pendentes. Reutiliza compras automáticas anteriores, sugestões convertidas e entregas confirmadas ligadas ao local, sem contar duas vezes a mesma ordem. Recebimentos aceites efectivos, incluindo estornos, reduzem a cobertura pendente. Rascunhos alterados de artigo/repartidos exigem reconciliação. Uma compra rejeitada não é recriada pela mesma regra: exige revisão e activação de nova versão. Compras manuais sem vínculo autorizado a este artigo/armazém não têm o destino inferido a partir do nome.

As necessidades e regras usam versões imutáveis de supply_records, sem outra estrutura paralela. A requisição gerada conserva ligação à necessidade e mostra as requisições ao armazém de origem, local de utilização e equipamento; versões posteriores não reescrevem essa origem. Sem configuração válida, regista necessidade pendente e motivo. GET apenas consulta. Reavaliar é uma intervenção explícita de preparação/revisão. Uso interno continua sem factura; venda e integração de facturação pertencem à composição SGF.

Instalação49 aplicada exclusivamente à avaliação8005, com backup/restauro conferidos e109 tabelas existentes preservadas; nova tabela vazia, sem contas, permissões ou dados sintéticos. Prova: docs/proofs/warehouse-reservations-install.json. A avaliação existente foi retomada porque a porta estava desligada, sem provisionar outra base ou redefinir contas.

Verificações: bateria geral920 testes,918 passaram,2 anteriormente ignorados,9620 asserções, sem falhas; storage/logs/warehouse-reservations-full.txt. PostgreSQL descartável24 testes/232 asserções e três disputas reais de bloqueio passaram: repetição da mesma entrega, comandos diferentes da mesma entrega, activação concorrente da regra com um só rascunho. Prova em warehouse-drafts-pg.json. Compilação, tipos, lint/formatação, análise PHP e integridade dos18 ficheiros dos núcleos passaram; acesso HTTP à página de reposição confirmado como administrador com consulta, sem preparação/revisão ou comandos de negócio. Prova consolidada em warehouse-replenishment.json. Sem revisão visual por capturas e sem declarar todos os CA01–09 cumpridos.

Limites e continuidade: preenchimento de reservas após reposição é explícito pelo revisor; não foi criada política automática de prioridade entre pedidos concorrentes. Avaliação automática é posterior à confirmação das alterações, com bloqueio/idempotência e reavaliação pela interface; ainda não existe fila durável com recuperação automática de interrupção entre confirmação física e avaliação, nem varrimento agendado para passagem do tempo/validade sem qualquer evento. Necessidades podem ser reavaliadas pela tarefa autorizada. Prazos de expiração de reservas, revisão de pedidos já submetidos, avisos próprios do percurso de armazém e composição comercial SGF continuam a exigir incrementos específicos; nenhuma alçada ou canal foi inventado.

02/11/2026 — candidata SGF corrigida, exclusivamente isolada

Preparada OPERATIONAL-CANDIDATE-401ce31ae5f2dd20: schema revisão 2 inclui as duas dependências cb_ui_commands/cb_consumption_sources (16 tabelas novas); preparação autorizada de centros/dotações pela interface, catálogo administrativo integrado no frontend compilado e plano SQL mínimo separado da ligação migradora. Nenhum dado sintético distribuído. Decisão e procedimento, matriz, prova, SQL proposto, não executado.

157 controlos passaram na reprodução do schema actual de 87 tabelas, com owner/runtime restritos distintos: migração/falha, percurso básico/independência/reserva, catálogo/navegação, revogação/contexto, permissões SQL e actualização/reversão. Restauro em segunda base reconcilia 103 tabelas, schema/triggers e origem/decisão/reserva; apenas dados sintéticos, bases/roles removidas. Provas anteriores válidas reutilizadas. ZIP SHA-256 59dbdc64c4d9f14dfb4025a6177b829d136a4e2cb633ca036b10b5ae3197e703.

SGF permanece 0.1.1; nenhuma instalação, concessão/revogação, mudança de base/configuração ou publicação. Pendências: confirmação separada da operação e SQL, backup/restauro real na janela aprovada, configuração real e dois administradores para activação. Equipamentos/peças fora do âmbito; navegação modular com aceitação técnica anterior reconciliada. Preservado trabalho local alheio ao incremento.

02/11/2026 ? candidata SGF utiliz?vel, ainda n?o instalada

Conclu?das depend?ncias or?amentais de interface, administra??o pelo cat?logo nativo e prepara??o de centros/dota??es. Candidata 401ce31ae5f2dd20, schema revis?o 2; 157 controlos integrados + 17 React/render/assets + 54 deployment. Restauro efectivo de 103 tabelas e actualiza??o/recupera??o de c?digo sobre dados sint?ticos verificados. Ver docs/transferencia-sgf.md e a proposta revista no SGF. N?o executar a proposta antiga 5FAE. SGF continua 0.1.1, sem tocar em sgf_tempo_dev ou conceder direitos; instala??o/configura??o e mapa SQL s? para decis?o posterior. Preservar trabalho paralelo; equipamento/pe?as fora, revis?o visual/associa??es antigas/volume-pagina??o pendentes.

Avaliação do estado do SGC — 02/11/2026

Avaliação de código, registos de implementação, provas existentes e acesso HTTP; sem alteração de regras ou dados operacionais. Diagnóstico: base funcional ampla, adequada a piloto controlado após configuração, ainda em consolidação para entrega comercial. Compras, Pessoas/relatórios e armazém têm percursos implementados; parametrização integral, automatização resiliente, avisos de armazém e composição comercial não devem ser declarados concluídos.

Verificação executada nesta avaliação:33 testes dirigidos passaram,314 asserções (AutomaticPurchases, WarehouseFulfilment, WarehouseAvailability e WorkContext);18 ficheiros comuns conferidos por SHA-256. HTTP confirmou reposição/avisos e relatórios de Pessoas com CSV na avaliação8005. A bateria geral920/918 passaram/2ignorados/9620 asserções é prova anterior reutilizada, não nova execução integral nesta avaliação. Não houve auditoria visual completa, teste de carga ou confirmação de paridade com produção.

Prioridades identificadas por leitura do código: AutomaticPurchases::signal usa afterCommit sem fila durável; interrupção entre confirmação física e avaliação pode exigir reavaliação explícita. Não existe varrimento agendado de validade/mínimo sem evento. AutomaticPurchaseController limita regras/necessidades/histórico a100 registos sem paginação, podendo omitir pendências mais antigas; avaliação percorre pedidos/históricos sob bloqueio de empresa, pelo que capacidade com volume não está demonstrada. Sequência de papéis de aprovação permanece parcialmente definida no código, apesar de limites e permissões configuráveis. Completar avisos/prioridades/expiração de reservas e validar tarefas/ecrãs/impressão com utilizadores antes da entrega. Integrações SGF em demonstração/candidata não equivalem a instalação no SGF real; a documentação própria conserva os respectivos limites e autorizações.

Piloto controlado SGC — reposição resiliente e paginação — 02/11/2026

Prioridade confirmada pelo proprietário: consolidar Compras autónomo para piloto, começando pela recuperação de reposição após interrupções, verificação periódica de mínimos/validade e paginação; depois acompanhamento das reservas e validação com utilizadores. O incremento não altera a instalação real SGF0.1.1, não instala candidatas SGF e não cria a identidade sintética adicional cuja proposta continua sem autorização. Os33testes/314verificações e918aprovados/2ignorados da avaliação anterior continuam provas históricas, sem serem apresentados como execução nova ou revisão visual completa.

Migração50: replenishment_work, um trabalho durável por empresa/artigo/armazém, com geração do sinal, geração processada, responsável da origem, próxima execução, tentativas e erro técnico sanitizado. O sinal é inserido/actualizado na mesma transacção das alterações físicas/documentais; rollback da alteração também reverte o sinal. Sinais repetidos são acumulados no mesmo trabalho e a avaliação lê os dados actuais. A criação do rascunho pelo motor existente, origem imutável e confirmação de processamento são atómicas, sob bloqueio de empresa e trabalho. Interrupção antes da confirmação reverte tudo; interrupção após confirmação física mas antes da avaliação deixa trabalho recuperável. Não há reserva de identidade humana, concessão de competências, aprovação por tempo decorrido ou novo motor financeiro.

ReplenishmentRun é um âmbito restrito a CLI, sem sessão/utilizador autenticado, composição SGC e empresa do trabalho persistido. Não modifica a autenticação nem cria conta técnica. A auditoria identifica scheduled_replenishment, trabalho/empresa e pessoa responsável pelo sinal/regra como atribuição de origem, não como autora de uma intervenção interactiva. O histórico no detalhe da requisição distingue execução periódica. CurrentActor mantém a validação normal de todos os comandos humanos; só o novo rascunho de reposição sob regra aprovada pode usar o âmbito restrito. Requisitante, centro, política, catálogo, destino técnico e contexto continuam revalidados. Contexto empresarial desligado ou produto fora da composição SGC impede execução. Autoridade de origem pode mudar enquanto um recuperador espera: o responsável é novamente conferido no trabalho sob o bloqueio da empresa.

sgc:replenishment-tick descobre pares de políticas/regras/necessidades e origens de armazém já existentes, recuperando também a janela anterior à instalação, e processa trabalhos vencidos por lotes. O agendamento Laravel está declarado a cada minuto; cada trabalho tem próxima verificação persistida, por defeito5minutos, configurável em SGC_REPLENISHMENT_SCAN_MINUTES. É uma cadência técnica, não prazo de aprovação. Falhas técnicas mantêm o sinal e voltam a tentar com espera limitada; situações funcionais sem configuração válida permanecem necessidades pendentes visíveis e voltam a ser conferidas. Não é preciso um novo movimento físico para detectar validade de lote/regra ou stock mínimo. A elegibilidade de qualidade continua independente e nunca se liberta lote para satisfazer uma reserva.

/stock/reposicao pagina separadamente regras, necessidades, histórico e trabalhos técnicos pendentes/interrompidos. Necessidades pendentes aparecem primeiro, com filtro de estado; os registos antigos deixaram de desaparecer pelo limite fixo100. Os trabalhos sem necessidade apresentada ainda são visíveis por artigo/armazém, motivo sanitizado e próxima tentativa. Reavaliar agora exige supply_prepare ou supply_review; administrador só de consulta não executa a acção. Links preservam parâmetros e o servidor filtra empresa, permissões e contexto. GET não cria compras. A interface mostra intervalo, contadores e data/resultado da última passagem conhecida do serviço, sem afirmar serviço activo a partir da mera instalação.

Instalação50 apenas na avaliação8005: backup/restauro verificados,110 tabelas anteriores preservadas, nova tabela inicialmente vazia, sem contas, grants ou dados sintéticos adicionados. Depois, o serviço descobre e acompanha apenas origens já existentes. Prova replenishment-recovery-install.json. scripts/replenishment-evaluation.php valida a configuração/base isolada existente e mantém verificação periódica com exclusão local, executando processos CLI frescos e estado técnico sem segredos. Arrancado oculto nesta sessão e observado em passagens sucessivas; integrado no arranque de desenvolvimento existente. Não é um serviço Windows instalado para arranque após reinício. Retomar composer run dev ou o auxiliar guardado depois de reiniciar o ambiente; em instalação comercial, preparar o agendador da instalação na respectiva janela autorizada.

Novas provas, separadas das anteriores: regressão alargada198testes/1579asserções passou; verificação final da reposição18testes/155asserções passou; PostgreSQL descartável33testes/310asserções e4disputas reais passaram, incluindo saída física confirmada seguida de término controlado do processo no início do callback e dois recuperadores concorrentes, com um único rascunho e sem humano autenticado. Também provados rollback de rascunho/checkpoint, rollback de sinal físico, validade sem movimentos, paginação de105pendências antigas, isolamento entre empresas, impossibilidade de usar âmbito de background numa sessão e bloqueio na composição SGF. Tipos, lint/formatação, compilação, análise PHP dos componentes alterados,18hashes e HTTP com paginação/estado recente do serviço passaram. Logs replenishment-pilot-regression.txt e replenishment-pilot-final-tests.txt; provas replenishment-pilot-pg.json, replenishment-pilot-http.json e consolidada replenishment-pilot.json. Não foi repetida a bateria geral anterior nem efectuada revisão visual completa ou aceitação por pessoas reais.

Roteiro preparado para aceitação do piloto — ainda não executado com utilizadores

Usar contas e competências existentes, nominativas e autorizadas pela empresa; não criar identidades para ultrapassar independência. Identificar previamente quem requisita, quem autoriza e quem entrega. O requisitante confirma recepção. Esta distribuição do SGC autónomo não concede novas identidades/competências no SGF.

Caso	Acção do participante	Resultado a conferir
Pedido interno	Requisitante selecciona artigo, centro e local/equipamento aplicável	Origem reutilizada; sem factura e sem saída/reserva no rascunho
Autorização	Outro responsável decide; aceita parcial apenas se o requisitante a tiver aceite	Reserva só do material utilizável livre; decisão e autoria preservadas
Entrega parcial	Armazém, distinto de requisitante e autorizador, confirma quantidade real	Só a quantidade entregue sai; reserva restante e pendência ficam visíveis
Recepção	Requisitante confirma uma entrega concreta	Não há segunda saída física
Cancelamento de saldo	Responsável competente fundamenta o cancelamento	Liberta só o restante; entregas/recepções anteriores preservadas
Falta/mínimo	Necessidade numa regra já activada por responsável independente	Um rascunho para o requisitante configurado; nenhuma aprovação automática
Recuperação	Conferir trabalhos interrompidos e repetição de reavaliação	Um rascunho associado; erro/pendência visível e tentativa seguinte registada
Validade	Conferir lote/regra que deixa de ser válido	Sem saída de lote indisponível; nova avaliação sem movimento; pendência fundamentada
Pendências antigas	Filtrar e percorrer páginas	Conseguir localizar o pedido antigo sem conhecer o seu ID

Continuidade: completar acompanhamento próprio das reservas (avisos/tarefas, prioridades e expiração expressamente parametrizadas), executar este roteiro com utilizadores existentes e registar observações por percurso. Não declarar aceitação humana, desempenho em grande volume ou cobertura comercial SGF com base nestes testes técnicos.

Acompanhamento das reservas e validação sintética — 02/11/2026

Clarificação posterior do proprietário: nesta fase não criar pessoas reais; continuar a desenvolver e validar com contas sintéticas, tendo em vista a comercialização após o desenvolvimento. Orientação incorporada em AGENTS.md. A consulta de utilizadores da empresa na avaliação8005 confirmou contas sintéticas já existentes; não foram criadas contas, alterados perfis ou concedidas competências nesse ambiente. A validação funcional adicional usa actores/perfis sintéticos explícitos em bases descartáveis. Não confundir estes ensaios com aceitação por utilizadores reais, configuração de uma empresa cliente ou autorização da identidade adicional proposta no SGF. SGF real permanece fora deste incremento, em0.1.1.

Novo WarehouseWorkdesk, exclusivamente de leitura, sobre WarehouseRequest, WarehouseRequestEvent e warehouse_reservations existentes. /stock/requisicoes reúne tarefas por competência efectiva: autorizar, acompanhar reservas abertas, entregas pendentes e recepções por confirmar, além da consulta do âmbito permitido. Não cria uma segunda lista de concessões ou outro workflow. Tarefas desaparecem/reaparecem com o estado e a autoridade actuais; requisição própria não é autorizada pelo seu autor, e quem autorizou não se torna entregador do mesmo pedido. Revogação/vigência de perfil e departamento/contexto continuam aplicáveis. Administração só de consulta não recebe tarefas operacionais por consultar o painel.

Filtros por tarefa, estado, armazém, referência RA-id, requisitante ou local são aplicados no servidor antes da paginação. Contagens abrangem todo o conjunto autorizado, sem depender da página ou dos últimos100registos; ordem de registo, mais antigos primeiro, não é uma prioridade automática de afectação de stock. A projecção SQL de estados deriva dos eventos e quantidades preservadas, sem escrever saldos/estados paralelos. Foi confrontada com WarehouseFulfilment::progress nos estados rascunho, submetida, autorizada, parcial, entregue, encerrada, rejeitada e cancelada, em SQLite e PostgreSQL. As decisões/movimentos continuam a usar os comandos e o único StockWorkflow existentes.

Cada pedido apresenta saldo reservado/sem reserva e avisos de acompanhamento. Lotes não reconciliados, défice global de material utilizável comprometido, alteração da origem/destino e saldo ainda sem reserva ficam explícitos, sem divulgar novas quantidades globais a quem só consulta o seu documento. A indicação de prontidão é momentânea, não uma garantia de saída: o servidor revalida versão, origem, reserva, qualidade e disponibilidade no registo efectivo. O formulário de entrega só é apresentado com material reservado elegível no momento da consulta; não se liberta qualidade nem se autoriza entrega para satisfazer o aviso.

O detalhe mostra pessoas actualmente elegíveis para requisição/recepção, autorização/reserva e entrega, reutilizando perfis e âmbito reais do servidor. Ausência de pessoa elegível é visível e exige parametrização explícita, sem nome ou tarefa presumidos. Esta informação actual não reescreve autores históricos e fica fora da impressão do documento de saída. A confirmação de recepção pendente continua como tarefa mesmo depois de cancelar o saldo não entregue; confirmar não lança outra saída. Pedidos fechados/cancelados não são reabertos por mera consulta ou estorno físico.

O formulário de nova requisição ficou recolhido até ser solicitado e abre em caso de erro, para deixar o acompanhamento visível sem acrescentar campos obrigatórios ao percurso. O catálogo de tarefas nos perfis explicita preparação/confirmação e entrega independente, usando as permissões existentes. Lista e detalhe usam leitura coerente em transacção PostgreSQL read-only/repeatable-read; consultas não geram compras, avisos persistentes ou movimentos. Este incremento acrescenta avisos visíveis no acompanhamento, não envio externo nem notificações com estado de leitura. Não foram inventadas prioridades organizacionais, prazos de expiração ou libertações automáticas de reserva.

Validação NOVA com contas sintéticas:111testes/1008asserções na regressão dirigida;18testes/326asserções na verificação final de pedidos; PostgreSQL descartável38testes/517asserções e3disputas reais reutilizando os cenários de entrega/compra, sem duplicação. Cobertura específica inclui percurso completo parcial/recepção, cancelamento com recepção ainda pendente, ausência/revogação de entregador elegível, separação de funções, filtros antes da paginação, pesquisa de pedido antigo, âmbito empresarial/departamental/armazém e impedimento de saída de lote retido. Tipos, lint/formatação, compilação, análise PHP,18hashes e HTTP de consulta passaram. Provas separadas: warehouse-workdesk.json, warehouse-workdesk-pg.json, warehouse-workdesk-http.json; logs warehouse-workdesk-regression.txt e warehouse-workdesk-final.txt. Sem migração, dados sintéticos adicionados à avaliação persistente, concessões ou instalação SGF; sem nova execução da bateria geral anterior e sem declarar revisão visual completa.

Continuidade: continuar validação sintética e consolidar cenários de acompanhamento antes da comercialização. Se forem acrescentadas prioridades, prazos de expiração ou notificações persistentes, preparar configuração explícita e revisão independente dos efeitos; não usar o tempo decorrido para aprovar, entregar ou libertar material por inferência. A configuração funcional das contas da avaliação deve continuar explícita e separada dos perfis ensaiados em bases descartáveis.

Preparação do piloto e ensaio sintético integrado — 02/11/2026

Adicionado /stock/piloto, menu Armazém e activos > Preparação do piloto, reservado a administração. WarehousePilotReadiness é diagnóstico somente de leitura, em transacção coerente PostgreSQL read-only/repeatable-read. Apresenta componentes instalados, tarefas e independência, existência de centro no departamento, catálogo publicado com origem actual, regras activas e fontes válidas, execução periódica observada, trabalhos a recuperar e configuração própria da empresa. Mostra contas cadastradas e pessoas com tarefas elegíveis, com ligações à parametrização existente. Não cria contas, atribui perfis, activa regras, lança movimentos ou aprova compras.

O diagnóstico distingue condições básicas para ensaio de armazém, reposição periódica e configuração de cliente. Há verificação de três intervenientes distintos, requisitante/autorizador do mesmo departamento e centro de custo compatível; distribuir os três rótulos por apenas duas pessoas não basta. Administração permanente segue a regra existente de dois administradores nominativos, fora de manutenção e sem prazo. Compatibilidade com papéis de desenvolvimento e contexto de avaliação não são certificados como configuração de cliente concluída. Falta de stock não é tratada como erro de configuração, pois é precisamente um cenário a ensaiar.

AutomaticPurchases::inspectRule reutiliza a validação de requisitante/centro e as mesmas fontes/políticas/catálogo/acordo/destino técnico da geração, mais os limites de preço/imposto do formulário canónico. A parte comum de validação do requisitante foi separada da aquisição de locks, preservando-os nos comandos e permitindo inspecção sem escrita. Não executa o comando de geração nem substitui autenticação para obter um resultado. Regra expirada, origem alterada, perfil revogado e centro incompatível deixam de contar como válidos. Regras/fontes mudadas continuam a exigir revisão explícita, sem actualizar os documentos históricos.

Estado do serviço periódico centralizado em ReplenishmentQueue::status e reutilizado na reposição e no diagnóstico. Telemetria opcional inexistente/danificada não bloqueia a consulta; registo antigo ou de futuro não prova serviço activo. Uma passagem recente com resultado favorável não oculta sinais técnicos por processar nem trabalhos em recuperação: esses impedem o indicador de reposição pronta. Necessidades funcionais sem configuração continuam no acompanhamento de reposição. Não foi acrescentado prazo de aprovação ou expiração de reserva; a recência é apenas observação técnica do serviço.

Ensaio integrado novo em WarehousePilotJourneyTest: três actores sintéticos, artigo publicado, política e parametrização com conferência independente; pedido interno125unidades com120utilizáveis, reserva parcial120 e um rascunho canónico de reposição108 conforme embalagem/alvo do ensaio. Entrega100, confirmação, entrada108 numa ordem já emitida usada como origem física independente, reforço autorizado de reserva5, entrega final25 e recepção encerram o pedido. Saldo físico final103, reserva0, sem factura de saída interna e sem segundo rascunho. A requisição automática continua rascunho, com zero etapas decididas e sem reserva orçamental automática. Este ensaio não apresenta a chegada da ordem preexistente como execução/aprovação do novo rascunho de compra: a preservação do circuito financeiro é parte da verificação.

Testes do diagnóstico cobrem leitura sem alteração de dados/perfis/auditoria, administração exclusiva, isolamento empresarial, combinação de papéis insuficiente, cadastro desactualizado, regra expirada/requisitante sem competência, telemetria antiga/corrompida e passagem recente que não esconde recuperação pendente. As alterações de ambiente/ficheiro necessárias ao teste de telemetria ficam em armazenamento temporário próprio, restaurado no final; não substituem o estado do serviço da avaliação persistente.

Provas NOVAS: regressão53testes/705asserções; final diagnóstico+percurso8testes/142asserções; PostgreSQL descartável46testes/659asserções e3disputas reais preservando entrega e rascunho únicos. Tipos, lint/formatação, compilação, análise PHP dos componentes alterados,18hashes e HTTP passaram. Provas warehouse-pilot-readiness.json, -pg.json e -http.json; logs warehouse-pilot-readiness-regression.txt e -final.txt. Suites sobrepostas não devem ser somadas. Não houve bateria geral anterior repetida, migração, alteração de concessões/contas persistentes, criação de pessoas reais, instalação SGF ou revisão visual completa.

Observação da avaliação8005 nesta conferência:12contas sintéticas cadastradas; instalação e passagem recente do serviço conferidas, recuperação técnica sem sinais de erro na consulta; tarefas/independência, catálogo, parametrização de reposição e configuração própria de cliente ainda apresentam pendências. O diagnóstico conserva esses resultados em vez de dar a avaliação por pronta ou preencher configurações de forma presumida. SGF real continua fora deste incremento, em0.1.1, sem autorização inferida para a identidade adicional.

Diagnóstico do piloto exportável — 02/11/2026

/stock/piloto passa a oferecer exportação CSV das conferências e opção de impressão pelo navegador. A exportação em /stock/piloto.csv exige a mesma administração autenticada da consulta, lê o mesmo WarehousePilotReadiness em transacção coerente/read-only e inclui data, âmbito SGC autónomo, conferência, resultado, observação e ligação à configuração. Não exporta o cadastro de contas nem executa os passos do roteiro. Cada exportação reflecte a sua própria data de leitura, podendo diferir de uma página anteriormente aberta; não é aprovação, activação, certificado de entrega ou arquivo imutável do servidor.

CSV UTF-8, separado por ponto e vírgula, com resposta privada/no-store e tratamento de texto que possa ser interpretado como fórmula por leitores de folhas de cálculo. As verificações incluem recusa a leitor operacional sem administração, ausência de alteração de utilizadores/perfis/auditoria/stock/requisições e neutralização de campos semelhantes a fórmulas. A opção de impressão foi acrescentada à interface, sem declarar revisão visual de impressão.

Provas NOVAS:10testes/161asserções passaram no diagnóstico/percurso e exportação, tipos/lint/build/análise PHP e18hashes passaram; CSV conferido no HTTP da avaliação8005. Logs pilot-export-tests.txt e pilot-export-build.txt; provas pilot-export.json e pilot-export-http.json. Sem migração, contas, pessoas reais, concessões, configurações financeiras ou instalação SGF. As pendências de preparação já identificadas continuam explícitas; o relatório permite revê-las sem preenchimento presumido. Evidências anteriores e ausência de nova bateria geral/revisão visual completa preservadas.

Interface reutilizável de entregas do armazém — 02/11/2026

Implementado WarehouseExchange e GET /stock/integracao/entregas, na aplicação SGC autónoma. É uma interface de leitura dos eventos imutáveis existentes, sem tabelas novas, cópias de stock, concessões ou comandos empresariais. Contrato de dados versionado em integrations/contracts/warehouse-fulfilment-v1.json. O serviço pode ser reutilizado na composição autenticada; a rota usa a sessão, verificação e configuração de empresa/contexto já existentes. Não é uma API pública nem autenticação técnica entre servidores.

Publica apenas deliver e receive: entregas físicas efectivas e confirmações do requisitante. Reserva, autorização e cancelamento de saldo não são publicados como saídas. Cada entrega transporta RA, empresa, versão do evento, data UTC, interveniente, armazém, centro, requisitante e destino originais. Nas linhas reutiliza artigo/unidade, quantidade inteira em milésimos, utilização, equipamento e stock_operation_id do único motor StockWorkflow. A confirmação referencia a chave da entrega e não repete linhas/movimento. Alterações posteriores ao cadastro não reescrevem estes dados. A requisição interna continua documento de saída sem factura.

Leitura incremental: limit entre1e100 (por defeito50), cursor opaco devolvido em next_cursor e has_more. Sem cursor, começa nos eventos antigos visíveis; mesmo no fim devolve cursor para futuras consultas. O cursor é cifrado/autenticado, ligado à empresa, conta, contexto, departamento e competências efectivas; mudança desse âmbito exige reiniciar leitura. Cada página revalida acesso e filtra antes de limitar; isolamento empresarial/departamental e leitura coerente PostgreSQL preservados. Não guardar cursor como autorização nem o transportar entre instalações/contas. Os comandos existentes serializam eventos por empresa, antes de se avançar por ID; não há outro escritor de eventos neste módulo.

Contrato de consumo: guardar os factos recebidos e o próximo cursor na mesma transacção do consumidor, avançando só depois de os aceitar. Uma repetição deve reutilizar a idempotency_key, com unicidade por ligação à instalação de origem + tenant_id + chave. A chave não é global entre instalações independentes. payload_sha256 identifica o conteúdo produzido (JSON dos campos precedentes, na ordem emitida, sem espaços/escapes de Unicode ou barras); igualdade serve para conferir replays. Mesma chave com conteúdo diferente exige reconciliação, não sobrescrita silenciosa. O resumo não autentica um canal externo. Campos adicionais compatíveis podem ser ignorados; alteração incompatível exige outra versão de contrato.

Âmbito preciso: estes são factos históricos de entrega/recepção, não sincronização de saldos nem instruções para lançar outra saída. Estornos físicos mantêm o percurso StockWorkflow e não apagam entregas antigas; não interpretar este feed isolado como espelho do stock actual. Não inclui autorizações completas, reservas actuais, catálogo integral, factura de venda, contabilidade ou contratos de Pessoas/RH. Conector remoto, credenciais técnicas, confirmação durável do consumidor e instalação no SGF são incrementos próprios, ainda não implementados por esta interface. Preservar a candidata e o SGF real0.1.1 sem inferir instalação/autorização da identidade adicional.

Validação NOVA:41testes/523asserções na regressão dirigida (Exchange, Fulfilment, Requests e WorkContext); subconjunto novo10testes/83asserções também em PostgreSQL descartável, sem disputas novas ou ensaio de carga. Cobertura de repetição estável, paginação/novas consultas, alteração posterior de cadastro/equipamento, reserva sem saída, cancelamento com recepção posterior, acesso revogado, cursor adulterado/de outra conta/âmbito, limites, isolamento e consulta sem alterar diários/perfis/auditoria. Formatação e análise PHP dirigidas passaram;18hashes comuns preservados. HTTP8005 confirmou consulta, cursor e limite, com zero factos na primeira página da avaliação actual; os factos sintéticos foram exercitados apenas nas bases de testes. Provas warehouse-exchange.json, warehouse-exchange-pg.json e warehouse-exchange-http.json; logs warehouse-exchange-regression.txt e warehouse-exchange-pg.txt. Contrato JSON analisado sem erro de sintaxe; não foi usado validador externo de JSON Schema. Sem mudanças de interface visual, build novo, execução geral ou revisão visual completa. Não foram criadas contas, alterados perfis persistentes ou instalados módulos no SGF.

Receptor durável e leitura por lotes para integração — 02/11/2026

Acrescentado packages/integration, independente de Laravel/SGF e sem dependências financeiras adicionais: WarehouseFeed valida o contrato v1 de entregas; WarehouseInbox mantém recepção deduplicada e checkpoint numa só transacção PDO; WarehousePull coordena consulta por lotes e retoma pelo cursor guardado. Carregamento explícito por bootstrap.php; exemplo de ligação em packages/README.md. Este incremento prepara a parte destinatária da integração; não instala o módulo no SGC persistente/SGF e não implementa transporte remoto, credenciais técnicas ou projecções de negócio no host.

O host configura explicitamente instalação de origem, empresa de origem, empresa local e geração do leitor. Não equiparar IDs de empresas entre sistemas, nem aceitar estes vínculos de um pedido não autorizado. A chave deduplicada inclui origem+empresa de origem+empresa local+evento; leitores distintos nesse mesmo âmbito partilham factos e têm checkpoints separados. Mudança de conta/perfis/contexto na origem pode exigir uma nova geração de leitura, preservando a anterior e reutilizando factos já recebidos; isto é uma chave técnica de acompanhamento, não criação de outra identidade humana/sintética. Permissões, instalação e configuração do host continuam a exigir o respectivo percurso autorizado.

WarehouseInbox::schema fornece duas definições de tabela para migração explícita do destinatário: sgc_exchange_streams e sgc_exchange_facts. Construção, consulta e recepção não criam schema. Compatibilidade ensaiada com PDO SQLite e PostgreSQL em modo de excepções. O receptor recusa transacção exterior activa para não confirmar falsamente um cursor antes do commit do dono dessa transacção. Não há down, remoção de factos, restauro, grants, seeds ou migrações executadas em instalações persistentes neste incremento. O adaptador não substitui o plano de instalação, endurecimento de privilégios e auditoria de acesso do host.

A página completa é validada antes da escrita: versão, empresa, identidade do evento, ordem crescente, acção, intervenientes, documento interno, destino, quantidades inteiras positivas, equipamento condicional e hash do conteúdo original. Metadados adicionais compatíveis são preservados. Entrega/recepção mantêm os snapshots e vínculos de StockWorkflow; não lançam outra saída, compra, aprovação ou factura. Recepção exige entrega original já recebida, com a mesma requisição/snapshot; duas confirmações diferentes da mesma entrega são impedidas. Os factos são históricos e não representam saldo actual ou estorno implícito.

Na recepção, bloquear o checkpoint e conferir versão/cursor solicitado; guardar factos e cursor atomicamente. Retry exacto da última página após confirmação perdida é reconhecido sem nova inserção. Páginas antigas, disputa de versão, mesma identidade com hash diferente e confirmação sem origem não fazem avançar a leitura. Falha numa linha posterior reverte também os factos anteriores dessa página. Duas streams que recebem o mesmo evento reutilizam o facto pela chave comum. As operações de aceitação usam apenas SQL parametrizado e âmbitos explícitos. O hash identifica conteúdo do produtor e não autentica um remetente externo.

WarehousePull recebe do host uma função de consulta já autenticada, sem escolher URLs ou credenciais. Cada consulta usa checkpoint actual; limites técnicos de páginas/linhas são validados antes de chamar o transporte. Interrupção ou erro numa página conserva as anteriores já aceites; uma execução seguinte retoma a página pendente. has_more=true quando o lote atinge o limite conserva a continuação explícita. Sem agendador, chamadas externas ou associação a contas reais activados. A projecção funcional/confirmacão de consumo pelo sistema de destino continua separada do diário de recepção agora implementado.

Correcção complementar na origem WarehouseExchange: cursor contém fingerprint ordenado das competências em vez de toda a lista, mantendo o vínculo de autoridade e um tamanho limitado mesmo com o catálogo completo de permissões. Cursors anteriores ao refinamento exigem reinício de leitura; os factos/chaves v1 mantêm-se. Não confundir invalidar um cursor técnico com alterar uma requisição ou conceder competências.

Validação NOVA:56testes/628asserções na regressão dirigida (receptor, feed, requisições, entrega e contexto);25testes/188asserções do subconjunto em PostgreSQL descartável. Dois executores com contenção real disputaram a mesma página e páginas diferentes: um facto e um único avanço de checkpoint, com retry reconhecido ou conflito explícito. Processo terminado após commit e antes de devolver confirmação foi retomado por outro processo sem duplicar facto/avanço. Testes incluem falha a meio da página, origem/empresa local distintas, confirmação sem entrega ou repetida, hash adulterado/conflitante, versão/cursor antigos, transporte indisponível, limites de lotes, metadados e preservação dos movimentos originais. Ensaio integrado consome JSON real da rota de entregas para o receptor, em base de testes. Não somar suites sobrepostas.

Formatação e análise PHP dirigidas passaram;18hashes financeiros comuns preservados. Consulta HTTP8005/cursor/limites passou, ainda com zero factos na primeira página local. Provas warehouse-inbox.json e warehouse-inbox-pg.json, HTTP em warehouse-exchange-http.json; logs warehouse-inbox-regression.txt e warehouse-inbox-pg.txt. Nenhuma bateria geral, build frontend ou revisão visual completa novos. Toda a instalação de tabelas de recepção e criação de intervenientes destes ensaios foi descartável. Sem migração, contas/perfis/grants persistentes, instalação ou identidade adicional no SGF. SGF real continua0.1.1; preservar candidatas/trabalho paralelo. Próximo recorte: transporte/configuração autenticados no host e reconciliação/projecção autorizada dos vínculos, sem duplicar o motor de stock ou presumir entrega comercial completa.

Transporte HTTP autenticado do armazém — 02/11/2026

Implementado WarehouseHttpSource em packages/integration e diagnóstico WarehouseTransportFailure. O módulo destinatário já pode executar consulta HTTP real por WarehousePull com uma sessão existente e autorizada na origem. Consulta fixa GET /stock/integracao/entregas, sem endpoints/credenciais na página recebida. O host fornece origem HTTPS, empresa e fornecedor de Cookie por canal protegido. Não foi criado outro utilizador, token permanente ou motor de autenticação; conta, perfis, isolamento, contexto e verificação da origem continuam a cargo do percurso já aprovado. O cliente não faz login/POST/seleção silenciosa de contexto nem altera aprovações.

Origem validada sem userinfo/query/fragmento ou travessia; query de cursor/limite codificada. Não seguir redireccionamentos impede reencaminhar a sessão para outro destino ou aceitar página de login como dados. HTTPS verifica certificado e hostname. HTTP exige opção explícita e endereço literal127.0.0.1/[::1], com proxy desligado só nesse percurso local; não existe opção de desactivar verificação TLS. Limites técnicos no construtor:15s totais/5s ligação/8MiB por defeito, com corte da resposta descomprimida; não são regras organizacionais. Credenciais consultadas por pedido, protegidas na depuração/parâmetros sensíveis, sem persistência ou apresentação em erros.

Aceitar apenas HTTP200/application-json/contrato v1 da empresa esperada, com validação do produtor. Erros estruturados e sanitizados distinguem sessão, competência, redireccionamento, cursor, indisponibilidade, timeout, tamanho e conteúdo. Não incluem corpo remoto, cookie ou cadeia original de excepções. retryable identifica falhas técnicas mas não executa tentativas automáticas. Invalidar/expirar a sessão, recusar âmbito ou devolver cursor antigo conserva checkpoint/factos; retoma/renovação continua explícita. Falha na rede não aprova, entrega ou movimenta stock.

Novos testes usam um servidor HTTP descartável em porta aleatória127.0.0.1, sem Laravel/contas reais, ligado a receptor SQLite ou PostgreSQL descartável. Cobrem leitura autenticada/paginada real, parâmetros codificados, consulta repetida do fornecedor de sessão, limites antes de credenciais, origens inseguras/ambíguas,401/419/403/302/409/422/429/503/404, HTML/JSON inválido, outra empresa, hash alterado, credencial indisponível/injecção de cabeçalhos, resposta excessiva, timeout e ligação recusada sem avançar o checkpoint.

Provas NOVAS75testes/746asserções na regressão dirigida;44testes/306asserções no subconjunto PostgreSQL descartável com2contenções reais e interrupção após commit antes da confirmação preservadas. Suites sobrepostas: não somar. Formatação/análise PHP dirigidas e18hashes comuns passaram. Cliente nativo PHP/cURL ensaiado também contra8005 com sessão sintética existente: consulta e roundtrip do cursor passaram; leitura sem sessão válida foi recusada. O receptor dessa prova foi exclusivamente SQLite em memória; a primeira página persistente tinha0factos, sem criar entregas para alimentar o ensaio. Sessão passada por stdin privado ao filho oculto, sem argumento, ficheiro de credencial ou conteúdo secreto nas provas. Código de prova usa só a origem local fixa.

Provas warehouse-http-source.json, warehouse-http-source-pg.json e warehouse-http-source-http.json; logs warehouse-http-source-regression.txt/warehouse-http-source-pg.txt. Sem build frontend, execução geral, revisão visual completa ou ensaio de certificados TLS de um host comercial. Nenhum schema de recepção, serviço permanente ou credencial técnica instalados em aplicações persistentes, e nenhum grant/conta/perfil alterados. SGF real mantém0.1.1 e a identidade adicional sem autorização. Preservar candidatas/trabalho paralelo.

A lacuna histórica de transporte foi parcialmente resolvida com o cliente HTTP de sessão existente, não com API técnica permanente: faltam configuração administrativa da ligação no host, armazenamento/renovação protegidos, autenticação técnica restrita se necessária, agendamento e reconciliação/projecção autorizada dos vínculos no destino. Não apresentar ensaio local/cliente preparado como integração activa comercial, nem usar os factos recebidos para duplicar o motor de stock/facturação/contabilidade. A configuração comercial pela interface continua pendente neste recorte.

Integração funcional entre módulos do SGC — 02/11/2026

O proprietário esclareceu que a integração desta etapa é entre os módulos do próprio SGC. Orientação registada em AGENTS.md; não é instalação/ligação ao SGF nem pedido para criar acessos externos. Este incremento usa directamente os motores e documentos internos, sem exportar/importar dados para ligar módulos do mesmo produto, criar chaves técnicas, novas tabelas, pessoas ou concessões.

Implementado InternalSupplyTrace: a requisição ao armazém liga à necessidade de reposição, à requisição de compra canónica, à etapa humana pendente, às encomendas e aos recebimentos já associados. A compra oferece ligação de regresso à requisição ao armazém quando o utilizador tem competência para a consultar. Os caminhos existentes são reutilizados; nenhum formulário duplicado, novo motor ou documento empresarial paralelo foi introduzido. O destino, equipamento e origem preservados nos registos existentes continuam a ser a referência, sem reescrever decisões/versões anteriores.

No detalhe do armazém, painel Reposição e compras associadas mostra artigo/unidade, saldo do pedido ainda sem reserva, referência da necessidade capturada e da situação actualmente registada para esse artigo/armazém. Mostra estados de compra, tarefa de aprovação pendente, encomendas e quantidades aceites efectivas neste destino, assinalando estornos pelo motor InventoryReversals existente. Uma entrada física não é apresentada como reserva/entrega já decidida; o autorizador elegível tem atalho para abrir o mesmo formulário de actualização de reserva, com as mesmas verificações e razão obrigatória. A impressão da requisição de saída não inclui o acompanhamento operacional adicional. O uso interno continua sem factura.

A reposição é partilhada por artigo/armazém: a ligação não atribui uma compra exclusiva nem promete que uma entrada esteja livre, utilizável ou automaticamente afectada ao pedido. A qualidade, validade, disponibilidade, reserva, autorização e entrega mantêm WarehouseWorkdesk/WarehouseFulfilment/WarehouseReservations/StockWorkflow como autoridade. Uma compra rascunho ainda exige conferência/submissão e as aprovações vigentes; não foi criada uma passagem automática por etapas.

A associação histórica usa a última versão da necessidade que efectivamente mencionou a requisição ao armazém; a situação actual da mesma necessidade é consultada separadamente. Uma compra futura do mesmo artigo, criada depois de desaparecer esta origem, não é retrospectivamente atribuída ao pedido antigo. SQL de selecção/grouping é aplicado na base, antes de materializar os registos, sem um limite global100 que esconda origens antigas. Implementações SQLite/PostgreSQL ensaiadas. Nada é associado por igualdade de nome ou por destino presumido.

Permissões por módulo mantidas: compra só surge quando Requisition::visibleTo permite consultar o respectivo processo; caso contrário aparece indicação genérica de acesso restrito, sem IDs/números privados, valores ou campos financeiros. Ligações a encomendas respeitam os papéis de consulta desse percurso. WarehouseWorkdesk::canView centraliza o mesmo acesso ao detalhe de armazém, incluindo empresa, proprietário, departamento, competências e acumulação necessária à entrega. A ligação inversa não concede consulta de armazém a quem apenas tem Compras. O detalhe continua numa transacção de leitura coerente PostgreSQL, sem comandos/avisos novos por GET.

Validação NOVA:52testes/668asserções na regressão dirigida (novo rastreio, piloto integrado, atendimento, compra automática e contexto);7testes/105asserções em PostgreSQL descartável no subconjunto novo+piloto. Não somar suites sobrepostas. Os6testes novos exercitam necessidade real a partir de pedido125 com stock120, criação de rascunho canónico, submissão e etapa humana ainda pendente, ligação de ida/volta, leitura sem alterar diários/aprovações/reservas/orçamento, ausência de permissão de compra, outra empresa e preservação da origem perante versões futuras sem esse pedido. O piloto integrado anterior foi executado nesta suite PostgreSQL: entrega parcial, entrada física em ordem já emitida, reforço de reserva e conclusão, sem aprovar o novo rascunho.

Teste documental separado de projecção usa a ordem/recepção já emitidas do fixture (120unidades) e referência sintética da necessidade para verificar as quantidades mostradas; a classificação de estorno é fornecida pelo serviço simulado de InventoryReversals. Não representa adjudicação/emissão real do novo rascunho, associação manual disponível na interface ou novo ensaio completo do motor de estornos. O agregado PDO PostgreSQL foi normalizado apenas na asserção de quantidade da base, preservando a tipagem inteira do relatório.

Tipos, lint/formatação, build, análise PHP dirigida e18hashes comuns conferidos. HTTP8005 confirmou a consulta do armazém, sem criar pedidos para produzir evidência:0detalhes existentes disponíveis nessa primeira página. Os detalhes/ligações foram exercitados com dados sintéticos apenas nas bases descartáveis. Sem revisão visual completa ou nova bateria geral. Provas internal-supply-integration.json, internal-supply-integration-pg.json e internal-supply-integration-http.json; logs internal-supply-integration-regression.txt, internal-supply-integration-pg.txt e internal-supply-integration-build.txt. Nenhuma migração, perfil, conta ou dado empresarial persistente alterados; SGF0.1.1 preservado. Este percurso de acompanhamento está ligado, mas não declara todas as funcionalidades/propostas ou a configuração comercial integralmente concluídas.

Tarefas integradas por perfil, equipa e área do SGC — 02/11/2026

Implementado WorkflowTaskInbox e As minhas tarefas nos menus de Requisições (/requisicoes/tarefas) e Pessoas e contratações (/pessoas/tarefas). São projecções do trabalho actual, sem outra máquina de workflow, tabela de tarefas, cópia de documentos, credenciais ou outorga de competências. Compras/armazém e Pessoas mantêm rotas, filtros e contextos separados. As ligações levam aos formulários originais, que continuam a revalidar versão, pessoa, competência, independência, conflito e demais condições da intervenção.

Cobertura deste incremento: rascunhos próprios que o utilizador pode conferir/submeter, etapas de requisição de compra em que Requisition::canDecide autoriza a decisão, decisões de armazém, reservas com falta ou conferência necessária, entregas e confirmações individuais de recepção. A lista de Pessoas reutiliza PeopleWorkdesk e PeopleAccess, incluindo a equipa, tipo de processo, intervenção e prazo efectivamente registados. Outras tarefas de consulta ao mercado, adjudicação, facturas/pagamentos e fases ainda por desenvolver continuam nos seus percursos próprios; esta lista não declara coberto todo o catálogo funcional da aplicação.

O armazém reutiliza WarehouseWorkdesk::forView/progress/health: não atribui a decisão ao requisitante, não atribui entrega ao autorizador e exige as duas competências de entrega/armazém existentes. Uma reserva completa sem problema deixa de gerar tarefa de conferência; uma falta ou origem/qualidade a conferir mantém a atenção. Entrega impedida continua visível como bloqueada e abre o pedido para consulta, sem recomendar lançamento físico. Cada entrega não confirmada gera a sua própria ligação de recepção, mesmo após cancelar só o saldo não entregue. Identificadores HTML das confirmações passaram a incluir o evento, evitando âncoras repetidas em entregas parciais. A confirmação real elimina apenas a tarefa correspondente, sem outra saída ou factura.

Administração de consulta e manutenção temporária não recebem competências operacionais por abrir a página. Perfil expirado, alteração de competência, âmbito departamental, empresa e contexto continuam a ser conferidos. Em Pessoas, atribuição global de função não substitui a equipa/autorização do processo; retirar a vigência da equipa retira a tarefa visível. Minutas continuam minutas e não foram tratadas como contratos formalizados/execução RH. Abrir a tarefa não marca um aviso como lido, não toma a decisão e não cria prazos, prioridades ou destinatários presumidos. Os avisos/resultados existentes permanecem no seu percurso de leitura.

As consultas percorrem o âmbito autorizado em lotes de100, aplicam as verificações dos motores existentes e só depois filtram/paginam25tarefas. Não há corte global100 que faça desaparecer pendências antigas. Ordenação de apresentação pela data de origem, com desempate natural dos identificadores, sem definir prioridade de atendimento/alocação; ausência de data não recebe uma data fictícia. Contagens por módulo cobrem o âmbito inteiro e são separadas do resultado filtrado. Pesquisa aceita referência ou tarefa. A resposta é privada/no-store, com leitura coerente PostgreSQL; auditoria de consulta de manutenção já existente não é substituída. Não existem notificações externas, subscrições ou automatismo de decisão neste incremento.

Validação NOVA:60testes/925asserções na regressão dirigida;15testes/362asserções no subconjunto PostgreSQL descartável (8novos, rastreio interno e piloto integrado). Suites sobrepostas, não somar. Os8testes novos percorrem rascunho/submissão/etapa humana, autorização/entregas parciais/cancelamento de saldo/confirmações individuais, reserva em falta e entrega impedida por origem alterada,30rascunhos com paginação/pesquisa e retenção do mais antigo, leitura sem alterar diários/decisões/stock, retirada de competência, equipas de Pessoas e abertura independente com a declaração de conflito exigida, manutenção, empresa e contexto. Actores adicionais e dados de ensaio apenas em bases descartáveis.

Tipos, lint/formatação, build, análise PHP dirigida e18hashes comuns passaram. HTTP8005 confirmou as duas rotas por selecção do contexto autorizado, com a conta administrativa sintética existente e0tarefas em cada área; isso demonstra acesso/estrutura, não atribuição de tarefas operacionais ao administrador ou percurso visual com pendências. Os percursos com tarefas foram ensaiados nas bases de testes. Sem revisão visual completa, nova bateria geral, novas disputas concorrentes, migração, contas/perfis/grants ou dados empresariais persistentes. SGF real0.1.1 preservado e fora do âmbito pedido. Provas workflow-task-inbox.json, workflow-task-inbox-pg.json e workflow-task-inbox-http.json; logs workflow-task-inbox-tests.txt, workflow-task-inbox-regression.txt, workflow-task-inbox-pg.txt e workflow-task-inbox-build.txt.

02/11/2026 — integração interna de facturas, pagamentos e tarefas financeiras

InvoiceWorkflow reutiliza unidade, preço e IVA das linhas preservadas na encomenda quando o pedido traz apenas a referência da linha e a quantidade. Valores explicitamente enviados continuam sujeitos à coincidência exacta; quantidades continuam limitadas pela recepção aceite, devoluções, estornos e facturas já validadas. A interface apresenta esses dados sem os pedir novamente nem os transmitir como nova fonte. Número/data e totais do documento do fornecedor permanecem necessários à conferência independente. A validação mantém a reconstituição das linhas históricas, arredondamento acumulado, conflitos e consumo único no núcleo orçamental.

As minhas tarefas inclui o módulo Finanças: facturas pendentes e registos de pagamento externo pendentes, apenas para conferente financeiro independente e actualmente elegível. InvoiceWorkflow::reviewerEligible e ExternalPaymentWorkflow::reviewerEligible são projecções dos mesmos requisitos funcionais; os comandos continuam a revalidar os factos dentro da transacção. A lista não decide, não lê avisos nem revela referências externas, evidências ou dados bancários. O catálogo de tarefas dos perfis explica esta intervenção dentro da competência financeira existente; não cria uma segunda concessão nem torna as subacções seleccionáveis de forma independente.

Pagamentos importados continuam dependentes da activação própria e de pa_access/validate. Desactivação, conflito de origem ou ausência dessa competência retiram a tarefa sem converter o saldo para um cálculo paralelo. Uma nova revisão bancária não esconde a possibilidade de rejeitar fundamentadamente um registo pendente; a confirmação exige novamente a versão bancária aprovada, saldo, elegibilidade e evidência. Manutenção temporária pode consultar nos limites existentes, sem receber formulários de execução ou referências reservadas do pagamento e sem intervir nas decisões.

As páginas /facturas e /pagamentos aceitam focos autorizados por documento; /facturas também por encomenda e /pagamentos por factura. As listas são paginadas com os filtros preservados. A factura validada abre os pagamentos da sua origem; o percurso da compra abre as facturas da encomenda e cada factura/registo externo concreto. Focos de outra empresa são recusados. O circuito reaproveita documentos existentes, sem transferências bancárias, nova dívida, nova saída interna, aprovação automática ou fusão com Pessoas/SGF.

Verificações novas: 81 testes/800 asserções na regressão de FinanceIntegrationTest, PaymentIntegrationTest, InvoiceTest, ExternalPaymentTest, PurchaseProcessTest e WorkflowTaskInboxTest; 23 testes/357 asserções em PayablePaymentDecisionTest e InternalRequisitionCandidateTest. O teste antigo de activação do ensaio foi ajustado para reconhecer o PostgreSQL descartável explicitamente permitido; a ausência de concessões específicas continua a recusar todos os endpoints financeiros próprios. A versão corrigida desse teste passou também isoladamente em SQLite (1/6). Tipos, lint/formatação, build, análise PHP dirigida e 18 hashes comuns conferidos. HTTP8005 com Administração e Finanças sintéticos existentes confirmou facturas, pagamentos e tarefas financeiras: 1 factura visível, 0 pagamentos e 0 tarefas financeiras em cada perfil. A consulta de pagamentos conserva a auditoria de acesso existente. Os cenários com decisões e pendências ficaram nas bases descartáveis; não houve migração, criação de contas/perfis/grants ou decisão empresarial persistente. Não há revisão visual completa, nova bateria geral ou certificação comercial integral. A prova PostgreSQL é registada abaixo após conclusão; suites sobrepostas não devem ser somadas. SGF real 0.1.1 e trabalho paralelo preservados.

Prova PostgreSQL concluída:83 testes/623 asserções aprovados, incluindo decisões importadas e a correcção da expectativa de activação; base descartável removida. A primeira tentativa excedeu120s; o modo financeiro passou a permitir300s. Nova execução identificou e corrigiu o pressuposto antigo de ambiente do teste; execução final integral aprovada em112,485s. Provas finance-integration.json, finance-integration-pg.json e finance-integration-http.json; logs finance-integration-tests.txt, finance-integration-authority-tests.txt e finance-integration-pg.txt. Não contar as tentativas interrompida/reprovada como aprovações nem somar suites sobrepostas.

02/11/2026 — adjudicação e conferência da emissão na lista de tarefas

WorkflowTaskInbox acrescenta decisões de adjudicação e conferência para emissão da ordem na categoria Compras. A elegibilidade da decisão vem de PurchaseWorkflow::canDecide, incluindo a etapa efectivamente pendente, departamento, independência, competências actuais e conflitos. A verificação do cancelamento pendente foi centralizada no mesmo motor; o congelamento deixa de ser apenas uma guarda do comando/controlador. A emissão usa PurchaseWorkflow::canIssue tanto na lista como no formulário e considera adjudicação aprovada, função de Compras, manutenção, âmbito de leitura, cancelamento, ordem já existente e conflitos de participação.

A tarefa de emissão pede conferência: não garante que a matriz/proposta ainda permita emitir. O comando continua a revalidar a base, propostas válidas, regras preservadas, aprovações finais, entrega, investimento, admissão/recomendação e orçamento dentro da transacção. Proposta expirada após aprovação mantém a necessidade de conferência, mas impede criar a ordem. Emitir efectivamente retira a tarefa; a consulta não emite nem altera orçamento/histórico. A data de entrega não foi convertida em prazo de decisão, nem foi inventada prioridade ou atribuição exclusiva. Registar a selecção, decidir e emitir recusam manutenção também no serviço; o controlador usa explicitamente o utilizador interno autenticado.

As descrições de tarefas dos perfis explicam as intervenções de adjudicação/emissão nas competências existentes. Sem nova concessão, etapa de aprovação, tabela, migração ou notificação persistente da adjudicação. O encaminhamento é uma projecção actual e conserva o percurso original. O perfil de consulta administrativo não recebe tarefas de execução. Uma atribuição expirada sem outra competência válida continua a impedir acesso à aplicação (403), por decisão do middleware existente; o teste foi corrigido para esperar esse bloqueio, sem o enfraquecer.

Quatro novos testes percorrem a selecção real com três propostas e avaliações, três etapas finais (departamento/Compras/Finanças), emissão efectiva e desaparecimento da tarefa, cancelamento pendente e rejeição que retoma a etapa, consulta sem mudar adjudicação/orçamento/auditoria, manutenção/expiração e proposta expirada que impede emissão. PostgreSQL descartável:4 testes/217 asserções aprovados, base removida. HTTP8005 com os três perfis sintéticos já existentes confirmou a lista no contexto autorizado; cada um viu0tarefas de Compras e0tarefas de adjudicação. Isso não substitui os percursos com pendências das bases descartáveis, nem representa revisão visual. Tipos/lint/build/análise PHP e18hashes comuns conferidos; regressão integral dirigida registada após conclusão abaixo. Sem contas/perfis/grants, decisões empresariais ou instalação SGF persistentes. Continuam por ligar à lista as intervenções de consulta ao mercado, avaliação documental/formal e execução contratual; não declarar estas fases cobertas apenas pela ligação da adjudicação.

Regressão final da adjudicação:98 testes/2070 asserções aprovados (PurchaseAwardOrderTest, WorkflowTaskInboxTest e InternalRequisitionCandidateTest). A primeira tentativa falhou somente na expectativa de acesso após expiração; o teste corrigido passou isoladamente1/32 e a suite integral foi repetida e aprovada. PostgreSQL4/217. Provas award-task-integration[-pg/-http].json e logs award-task-integration-tests.txt, award-task-integration-pg.txt, award-task-revocation-test.txt, award-task-integration-build.txt. Não somar suites financeiras/adjudicação sobrepostas nem declarar bateria geral reexecutada.

02/11/2026 — consulta ao mercado e avaliações ligadas às tarefas

QuotationParticipation centraliza a autoridade de preparação e avaliação anteriormente concentrada no controlador. Formulário, tarefas e comandos consultam as mesmas condições de empresa, departamento/visibilidade, estado aprovado, encerramento pela adjudicação, manutenção, independência do requisitante, conflitos, validade/elegibilidade do fornecedor e avaliação pessoal já registada. O comando recarrega a competência do interveniente depois do bloqueio da empresa, sem confiar num utilizador de sessão desactualizado. Cálculo de preços, descontos, IVA, mínimos, ponderações e avaliação mantêm os motores existentes. A comparação continua a decidir quais as avaliações qualificadas; perder competência não apaga nem substitui a avaliação histórica.

As tarefas de Compras passam a distinguir propostas em falta face ao mínimo preservado, avaliações pessoais ainda possíveis enquanto o mínimo de conferentes qualificados está incompleto, impedimentos da comparação e resultado pronto para conferência dos requisitos de adjudicação. Mínimos não são fixados novamente nem atribuídos por pessoa. Avaliação opcional continua possível no formulário após satisfação do mínimo, sem ser apresentada como pendência obrigatória. O resultado pronto encaminha para o formulário original, sem prometer que todos os requisitos formais de adjudicação estejam preenchidos ou efectuar selecção. Uma adjudicação existente fecha a consulta mesmo se rejeitada; não reabre etapas nem apaga histórico. Não são criados avisos persistentes, decisões automáticas, alçadas ou prazos novos.

Ligações quotation_id abrem a proposta concreta e prepare=1 abre a preparação existente, reutilizando as linhas da requisição; origem inválida/outra requisição recusada. Formulários usam elegibilidade por proposta no servidor, e a preparação desaparece se a competência se perder. História Inertia protegida e resposta privada sem cache. A lista é ordenada/paginada no âmbito completo e conserva consultas antigas.

Provas novas:169 testes/2924 asserções na regressão dirigida de SupplierQuotationTest, PurchaseAwardOrderTest, WorkflowTaskInboxTest, ConflictDeclarationTest, FinanceIntegrationTest e PaymentIntegrationTest. PostgreSQL descartável11/353 (inclui passagem real da comparação à adjudicação e encerramento), base removida. A primeira tentativa dirigida revelou um pressuposto errado da fixture: a mudança de função tinha sido ignorada pelo preenchimento permitido do modelo. O teste passou a fazer a mudança explícita e a suite integral foi aprovada. Inclui mínimos preservados mesmo após alteração da configuração geral, tarefas exactas, expiração, conflitos declarados, perda de competência, manutenção, departamento/empresa,30consultas/paginação/pesquisa, leitura sem efeito e avaliações históricas preservadas. Tipos/lint/build/análise PHP/18hashes passaram. HTTP8005 com os três perfis existentes viu0tarefas de consulta em cada perfil; pendências ensaiadas nas bases descartáveis. Provas quotation-task-integration[-pg/-http].json e logs quotation-task-integration-tests.txt, quotation-task-integration-pg.txt e quotation-task-integration-build.txt. Sem migração/contas/grants/decisões persistentes, revisão visual completa, bateria geral ou alteração SGF0.1.1. Suites sobrepostas não se somam.

02/11/2026 — diagnóstico da activação dos perfis e ligação às tarefas

Administração → Parametrização mostra por pessoa as competências actuais e dos perfis guardados, acrescentadas/retiradas, preparação implícita de requisição no modo antigo, contextos efectivamente contratados/configurados/funcionais, manutenção, tarefas do catálogo e administração permanente. É uma consulta, não concede acessos nem confirma decisões. OrganizationActivationPreview reutiliza configuredPermissions/configuredMaintenanceOnly de OrganizationAccess, configuredAvailable de WorkContext e permanentAdministrators de OrganizationConfiguration; estas extracções também são usadas no percurso efectivo, evitando outra interpretação de concessões. As regras existentes de activação continuam: confirmação explícita, versão actual, dois administradores permanentes e regras não provisórias. Não é imposta uma condição nova de atribuir todos os utilizadores, nem se activam módulos pendentes por constarem dos contextos.

A consulta administrativa usa transacção de leitura consistente, privada e com história protegida. Selecção de contexto, competências específicas do financeiro, segregação por processo e limitações de manutenção continuam a aplicar-se depois da configuração; o catálogo explica tarefas potenciais, não decisões já atribuídas em processos. Provas:6/101 nos testes novos; regressão dirigida89/1394 incluindo configuração, contextos, cotações, tarefas e integração financeira; PostgreSQL19/215 com os testes novos e WorkContextTest, base removida. Tipos/lint/build/análise PHP/18hashes passaram. Provas organization-activation-preview[-pg/-http].json e logs organization-preview-tests.txt, organization-preview-regression.txt, organization-preview-pg.txt, organization-preview-build.txt. Não somar suites sobrepostas, nem declarar bateria geral/revisão visual novas.

O diagnóstico HTTP8005 encontrou12contas sintéticas, configuração inactiva versão1,0perfis/atribuições,0administradores permanentes configurados e regras provisórias. A projecção dos perfis vazios retiraria acesso aos12; a activação directa já é impedida pela regra existente de dois administradores. Nenhum perfil/atribuição/regra foi alterado nesta avaliação.

Proposta concreta pendente de autorização — perfis do piloto sintético local

Destino exclusivo: SGC em http://127.0.0.1:8005,12contas sintéticas já cadastradas, nenhuma conta nova. Preparada a partir do diagnóstico de02/11/2026 às17:20:38UTC, versão1; origem e hash em docs/proofs/pilot-access-proposal.json. O ficheiro é proposta pendente, não instalador nem configuração por defeito de clientes. scripts/prepare-pilot-access-proposal.php só lê o diagnóstico e escreve a proposta; não inicia a aplicação nem liga à base.

Preservar as funções e os contextos actuais das12contas, tornando explícita nos perfis a competência requester que actualmente é implícita no modo antigo. Criar seis perfis base de compatibilidade e cinco perfis de tarefas do piloto (11no total), com atribuições permanentes somente às contas sintéticas existentes. Manter a administração actual das contas6 («Obrigações — consulta») e8 («Proprietário — avaliação local»); não conceder administração a outras contas. Preservar separadamente pa_access, identidades, documentos, aprovações, regras capturadas nos processos e vínculos actuais. As opções de terceiros já existentes conservam o seu estado funcional limitado; a proposta não implementa nem abre os percursos transferidos ao SGF.

Conta existente	Tarefa adicional proposta	Competência funcional
9 — Solicitante — avaliação local	Preparar/submeter requisição interna e confirmar recepção própria	warehouse_request_prepare
10 — Chefe de departamento — avaliação local	Autorizar/recusar requisição interna do departamento e acompanhar reservas	warehouse_request_review
13 — Recepção / Armazém — avaliação local	Confirmar entrega física, independente do requisitante e autorizador	warehouse_request_deliver, com warehouse já existente
11 — Procurement — avaliação local	Preparar políticas e parametrização da reposição	supply_prepare
12 — Finanças — avaliação local	Conferir a parametrização preparada por outra pessoa	supply_review

Confirmar para este piloto sintético as alçadas actualmente apresentadas (25.000,00MZN e150.000,00MZN, IVA incluído), sem mudar os seus valores, passando-as de provisórias a expressamente configuradas. Preservar o IVA predefinido16% e os mínimos/ponderações de comparação existentes. Activar os perfis depois da sua conferência pelos motores existentes e registar todos os comandos/versionamento na auditoria. Não publicar artigos, criar movimentos, definir quantidades mínimas/reposição, executar compras/aprovações ou alterar o SGF por esta autorização. Responsável/centro de custo de futuras regras automáticas continuam na parametrização específica de cada artigo/armazém.

A proposta está a ser validada apenas por reprodução descartável: criação dos perfis/atribuições, confirmação das mesmas alçadas e contextos, diagnóstico e activação explícita no ensaio, comparação antes/depois de funções, preparação, departamento e contextos dos12utilizadores. A aplicação no ambiente8005 depende de autorização expressa para esta substituição da autoridade de acesso e confirmação das alçadas, conforme AGENTS.md, Administração e entrega. O desenvolvimento de código e os ensaios já autorizados prosseguiram sem esse efeito persistente.

Ensaio final da proposta aprovado:1 teste/156 asserções em SQLite em memória e1/156 em PostgreSQL descartável, base removida. Executou os comandos reais de criação de11perfis,12atribuições, regras/contextos e activação apenas na simulação. Confirmou12utilizadores, nenhuma perda de competências/contextos/preparação/âmbito departamental, dois administradores permanentes, acréscimos exactamente iguais aos cinco propostos e nenhum processo/ordem/factura/grant pa_access criado. Provas pilot-access-proposal-dry-run.json e pilot-access-proposal-pg.json; logs pilot-access-proposal-tests.txt e pilot-access-proposal-pg.txt. A configuração8005 permanece inactiva e a proposta pendente de autorização; o ensaio não é autorização nem aplicação. Resumos das integrações em quotation-task-integration.json e organization-activation-preview.json.

02/11/2026 — devolução nativa de excedente, isolada

Implementado NATIVE-WAREHOUSE-UNUSED-RETURN-SIM-v1: entrega interna autorizada/recebida → declaração individual de não utilização pelo destinatário original → recepção física por armazém independente. Prévia, confirmação, retirada e recusa, versões/contextos/permissões revalidados, decisões append-only, auditoria e escritor único inventory-return 0.1.0. Reutiliza AutomaticPurchases para sinalizar uma vez dentro da transacção; não aprova, encomenda ou altera políticas. Interface e histórico paginado com leitura conjunta de preparadores. Direitos warehouse_return_read/prepare/confirm apenas configuráveis e atribuídos a QA isolada; feature desactivada por defeito, sem grants/activação no piloto ou reais.

Provas consolidadas 36 testes distintos/544 asserções (19 nativos/440, reversões afectadas16/81, observador SGF1/23), sem somar repetições: recepção10, entrega5, devolução3, saldo8 e três movimentos. Bloqueio real da empresa observado: repetição após libertação não duplica; disputa por capacidade409; HTTP423 sem efeitos e recuperação explícita; falha transaccional/artefacto503 recuperam; retirada/confirmação mutuamente exclusivas. Tipos, PHPStan dirigido, bundle e renderização do histórico passaram. Build privado qualificado passou sem React Compiler opcional/fontes remotas; não valida build optimizado predefinido ou revisão visual.

Ver docs/warehouse-unused-return.md e C:/laragon/www/sgf-tempo/docs/NATIVE_WAREHOUSE_RETURN_DELIVERY.md, com relatório/hash de provas. O SGC funciona sem ligação SGF; observação SGF foi só QA e não composição operacional instalada. A previsão existente mantém saídas brutas: devolução muda saldo/hash, não deduz da média. Consumo líquido temporal é evolução separada. Preservados dados/demos/acessos/cache/seis associações/checkpoints/trabalho alheio. Sem publicação, checkpoint, activação de candidatas ou uso real.

02/11/2026 — AUTORIZADO E APLICADO: perfis do piloto sintético local

O proprietário respondeu «autorizo» à pergunta de activação da distribuição concreta acima, exclusivamente na avaliação SGC8005. Autorização registada em docs/proofs/pilot-access-authorization.json, vinculada ao hashff45883f1a0e1e3ab228f8bc4e6c03a66e9a5953b04af44b2e26cd6b74b60a44. A proposta original não foi reescrita: o seu estado pendente é histórico; a autorização/aplicação actuais têm provas próprias. Esta entrada substitui a pendência de autorização anterior para este âmbito exacto.

scripts/apply-pilot-access-proposal.php conferiu a identidade do destino local, o hash da proposta ensaiada, a autorização específica, versão1,12utilizadores e respectivas identidades/funções/departamentos/contextos, ausência de perfis/atribuições e as mesmas alçadas. Preflight passou sem alterar dados. A aplicação usou OrganizationConfiguration e os resolvedores efectivos, com o administrador existente8;11perfis,12comandos de atribuição (17vínculos), confirmação das mesmas regras/contextos e activação foram executados numa transacção consistente, sob bloqueio da empresa. Qualquer divergência anterior ao commit cancelaria a transacção. Não houve migração, alteração de código do núcleo comum, criação de contas ou decisão operacional.

Às17:52:30UTC de02/11/2026 a configuração foi confirmada na versão27. Mantidos os administradores6/8 e as tarefas adicionais autorizadas9/10/13/11/12. As competências/contextos, preparação de compra e âmbito departamental dos12utilizadores foram comparados antes/depois e preservados, com acréscimos exactamente iguais aos da proposta. As alçadas25.000/150.000MZN comIVA passaram a explicitamente configuradas para estes ensaios, sem alterar os valores ou IVA16%. Requisições, aprovações, orçamentos, documentos, stock e concessões financeiras pa_access foram preservados.

Cópia privada guardada em C:/laragon/data/sgf-tempo/backups/compras-pilot-access-20261102-175214-d26e4c/before.dump, SHA-256afa964b52ea6c552466360a2ebc2523126f37ccf0a3aecd21f822a0767d35d75. pg_dump usou o snapshot exportado da mesma transacção; restauro de controlo descartável conferiu112tabelas antes de aplicar e foi removido. Após os comandos,107tabelas fora da configuração/auditoria/Tenant coincidiram integralmente com a origem; os restantes campos de Tenant também foram conferidos, permitindo apenas rules_provisional, work_context_policy e updated_at. Prova pilot-access-activation.json e log pilot-access-activation.txt. Sintaxe, formatação do aplicador e18hashes comuns conferidos. As provas anteriores de testes descartáveis não são declaradas reexecutadas por esta aplicação.

A autorização não publica artigos nem define mínimos, quantidades, políticas ou regras automáticas de artigo/armazém. Essas parametrizações permanecem no seu percurso próprio, com conferência independente; não foram criados movimentos, requisições, encomendas, facturas ou pagamentos por esta aplicação. SGF real0.1.1 e a proposta não autorizada de identidade adicional nesse ambiente permanecem fora do âmbito. A verificação HTTP posterior dos cinco perfis e do diagnóstico é registada abaixo após conclusão; nenhuma revisão visual completa foi declarada.

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.

03/11/2026 — instalação R1 autorizada e bloco R2 entregue

O proprietário autorizou instalar documentos da recepção no piloto e continuar os blocos seguintes. Aplicada exclusivamente a migração documental000002; cópia restaurada/conferida em113tabelas,112tabelas de negócio preservadas e base de restauro removida. Armazenamento privado conferido,sem novos documentos de negócio,contas,grants ou decisões. MFA não activado. Provas receipt-block-installation[-http].json; não repetir a instalação ou solicitar novamente esta autorização.

R2 acrescenta impressão A4/guardar PDF pelo navegador,sem campos adicionais: confirmação original,quantidades,qualidade,referências de estornos executados e anexos consultáveis comSHA256,sem incorporar ficheiros privados. Consulta actual claramente distinguida do original,nativepolicy/tenant e resposta privada semcache. Não substitui assinatura digital,saldo efectivo ou aceitação visual. Bateria integrada39testes/295verificações;PostgreSQL3/24 descartável;PHPStan,TypeScript,compilação,Pint,diff e18hashes aprovados. HTTP porAdmin,Armazém,Compras,sem comandos de negócio. Provas receipt-print[-pg/-http].json; docs/recepcao-impressao.md. Sem migração adicional,alteração de aprovações/adjudicação/encomenda/SGF. Restantes blocos da matriz continuam pendentes; não confundir esta entrega com conclusão comercial integral.

03/11/2026 — A1: documento individual de entrega interna

Acrescentado documento imprimível por entrega,sem duplicar a impressão conjunta já existente. Reutiliza a requisição como documento de saída sem factura;inclui só as quantidades desse evento,artigo/unidade,destino/equipamento,centro de custo,responsáveis,autorização anterior e operação de stock. Confirmação actual do requisitante identificada ou pendente;original não é apresentado como saldo actual e devoluções/correcções conservam processos próprios.

Acesso nativo por requisição/empresa,acção deliver obrigatória,resposta privada semcache e texto escapado. Nenhum comando de negócio na emissão. Bateria integrada20testes/363verificações;PostgreSQL descartável2/37,base removida. PHPStan,TypeScript,compilação,Pint,formataçãofrontend,diff e18hashes aprovados. HTTP conferiu índicesAdmin/Armazém,ambos sem requisições internas;documentos positivos exercitados apenas nas bases descartáveis. Sem nova migração,grants,contas,entregas,facturas,decisões no piloto ou mudançaSGF. Prova docs/proofs/warehouse-delivery-print.json e variantes;docs/armazem-documento-entrega.md. Restantes conversões,activação de devoluções e aceitação operacional continuam separadas na matriz.

03/11/2026 — O1: integridade operacional dos documentos da recepção

Entregue sgc:receipt-documents-check,consulta técnica global de consola sem identidade interactiva. Cruza registos/empresa/recepção e armazenamento privado,detecta referências inválidas,ausência,divergência de tamanho/SHA256 e ficheiros sem registo,recentes ou de pelo menos1hora. Não interpreta idade como autorização de eliminação,não repara/apaga/nem altera auditoria ou aprovações. Saída só agregada e erros genéricos,limite independente de registos/ficheiros com incompletude explícita;sem cursor/capacidade geral certificada nem snapshot conjunto base/ficheiros.

Validação final14testes/135verificações integradas com upload,descarga e impressão;PostgreSQL descartável6/33,base removida. Duas empresas,sem mutações,inválidos/ausentes/alterados/sem referência,limites,estrutura/armazenamento indisponíveis e privacidade/recusa interactiva cobertos. PHPStan sem erros,Pint,diff e18hashes conferidos. Sem novo frontend,compilação,revisão visual,monitor recorrente,migração,comando no piloto,contas/grants,decisão de negócio ou alteraçãoSGF. Provas receipt-document-health[-pg].json e docs/operacao-documentos-recepcao.md. Retenção,limpeza autorizada,backup/restauro conjunto,serviço,reinício/capacidade e demais blocos mantêm estado próprio.

03/11/2026 — S1: integração de MFA com as entradas de avaliação

Quando MFA activo,o middleware SGC impede atalhos /avaliar e /demo,autoentrada do proprietário e navegação pública de desenvolvimento como alternativa à autenticação;login por palavra-passe e desafio Fortify nativo permanecem. MFA desligado conserva o piloto. Sem modificar o código do alojamentoSGF ou decisões/contas/grants.

Regressão36testes/230verificações;PostgreSQL descartável8/61,base removida;PHPStan,Pint,diff e18hashes aprovados. EntradasHTTP e desafio comCSRF;identidade autenticada testada directamente no middleware. Sem novo frontend,compilação ou revisão visual. Provas mfa-evaluation-boundary[-pg].json. ConsultaHTTP confirma piloto desligado,sem inscrições.

Preparada proposta concreta de instalar exclusivamente migração000001,três camposMFA anuláveis,vazios. Cópia consistente restaurada114tabelas;ensaio preservou112tabelas protegidas e colunas existentes de12contas,sem inscrições;base removida. Provas mfa-pilot-schema-preparation/proposal.json e docs/proposta-instalacao-mfa-piloto.md. Instalação real continua PENDENTE DE AUTORIZAÇÃO;activação e eventuais credenciais/recuperação exigem plano e autorização próprios. Não activar MFA nas contas sintéticas dependentes de atalhos sem preparar acesso e recuperação,ou aplicar uma migração geral por inferência.

03/11/2026 — estrutura MFA instalada e blocoP1 Pessoas entregue

Autorização específica do proprietário aplicada só à migraçãoMFA000001,três campos vazios. Nova cópia consistente restaurada114tabelas,112tabelas protegidas e colunas antigas de12contas preservadas,sem inscrições,palavras-passe,perfis ou aprovações alterados. Provas mfa-pilot-schema-authorization/installation.json;consultaHTTP confirma capacidade desligada. Não repetir instalação ou solicitar novamente autorização;activação/credenciais/recuperação permanecem fora do recorte.

P1 acrescenta dossiêJSON de preparação,schema sgc.people.process-dossier.v1,com versão e dados reutilizados do processo e matriz. Projecção única entre página/descarga,com acessos separados ao financeiro,entrevistas e minuta e autorização nativa por processo/empresa/validade. Sem anexos copiados,auditoria integral,comandos,envioRH ou formalização;fronteira PeopleContractHandoff continua a recusar minutas. Downloadprivado semcache;não é arquivo assinado e acesso revogado não elimina cópia já descarregada.

Validação final56testes/1684verificações dePeopleHiring/PeopleRegistry;PostgreSQL3/72,base descartável removida. PHPStan,Pint,formataçãofrontend,TypeScript,compilação,diff e18hashes aprovados. HTTP confirmouPessoas sem processos visíveis nessa conta;dossiês positivos apenas em bases descartáveis. Sem dados/decisões/grants dePessoas no piloto,nova migração paraP1,revisão visual completa ou mudançaSGF. Prova people-dossier[-pg/-http].json e docs/pessoas-dossie-preparacao.md. Matriz actualizada;formalização contratual e restantes blocos conservam critérios próprios.

03/11/2026 — D1: metadados de auditoria dos módulos

Consulta paginada25eventos pela ordem de registo e CSV de todos os resultados filtrados,com mesma pesquisa/âmbito por empresa e apenasid,data,acção,user_id. Competência audit_metadata_read nova,não atribuída automaticamente nem aAdmin,navegação condicionada e configurável pelos percursos nativos. Sem before/after,anexos,dados privados ou links que contornem acesso a processos;sem mutações por consulta. Filtros opcionais deacção/utilizador/datas,CSV emlotes100 com protecção de fórmulas,privacidade e snapshot de leitura. Não é exportação integral/retenção/protecção contraSQLadmin.

Validação41testes/410verificações comOrganização/Contexto;PostgreSQL7/85,base descartável removida;PHPStan,Pint,formataçãofrontend,TypeScript,compilação,diff e18hashes aprovados. HTTP recusaAdmin/Armazém no piloto sem a nova competência;MFA continua desligado. Sem migração,grants ou comandos de negócio no piloto. Provas audit-metadata[-pg/-http].json e docs/auditoria-metadados.md.

Preparada proposta concreta audit-access-proposal.json,documentada em docs/proposta-acesso-auditoria-piloto.md:perfil sóaudit_metadata_read emprocurement.internal,acrescido apenas a6/8,conservando perfil7 e competências existentes. Ensaio nativo emcópia restaurada114tabelas,permissões preservadas e tabelas protegidas intactas;base removida,nenhumgrantreal. Versão actual27,proposta30 por3comandos auditados;atribuições6/8 são reemitidas pelo motor com novo fundamento/IDs,estado anterior conservado nohistórico. PENDENTE DE AUTORIZAÇÃO por novo acesso a metadados de todos os módulos daempresa;sem palavras-passe,contas,MFA,aprovações,decisões ouSGF. Não activar por inferência de continuação genérica.

03/11/2026 — E1: Equipamentos ligados a Compras e Armazém

A continuação genérica do proprietário manteve a proposta D1 pendente;nenhum novo acesso deAuditoria foi atribuído. MFA permanece desligado e aprovações preservadas.

Ficha por equipamento reutiliza dados existentes e separa requisições de compra visíveis de operações físicas. Listas independentes15/página pela ordem de registo,sem preços ou snapshots integrais. Âmbito nativo por função/empresa/departamento e visibilidade própria deRequisition.visibleTo. Quantidade pedida não equivale a recepção/saída;estornos conservam documento próprio,sem saldo ou consumo líquido inventado. Entrada pela ficha existente deEquipamentos e ligação ao processo de compra autorizado. Tipagem do actorweb explicitada no controlador,sem conceder funções adicionais.

Validação48testes/571verificações Equipamentos+WarehouseFulfilment;PostgreSQL4/99,base removida. Entrega interna nativa reutiliza operação única,sem duplicação;isolamento,restrições de compras,leitura sem mutação e páginas independentes16/16 cobertos. PHPStan,Pint,formataçãofrontend,TypeScript,compilação,diff e18hashes aprovados. HTTP apenas equipamentos existentes,sem comandos de negócio;sem migração,grants,contas,decisões ou alteraçãoSGF. Provas equipment-integration[-pg/-http].json e docs/equipamentos-acompanhamento.md. Revisão visual,capacidade,projecto/fraccionamento e restantes módulos mantêm critérios próprios.

03/11/2026 — C2: cancelamento de ordens implementado,sem activação

Autorização específica do proprietário aplicada exclusivamente ao desenvolvimento do âmbito proposto. Política própria com publicação pelo motor reutilizado,duas validações administrativas independentes,Compras solicita eFinanças decide com exclusão do requisitante,autor da adjudicação,emissor e autor do pedido. Vigência,roles actuais,empresa,conflitos,base da ordem ecompromisso revalidados. Pendência suspende execução mesmo seflag for desligado. Recepção,facturação,reemissão e fontes deimportação/entrega integradas;selecções operacionais excluem ordens suspensas/canceladas. Tarefas depolítica,decisão e novo rascunho comligações focadas e autoridade nativa,sem novosgrants.

Original emitido,snapshot,linhas eaprovações conservados;estadooperacional derivado,requisição marcada cancelada apenas naaprovação. Capacidade financeira aditiva,pinSHA próprio,no livro canónico,sem alterar os18artefactos instalados:reversão única do compromisso original integralmente disponível,sem recalcular moeda/IVA,sem bancos,reembolsos ou apagamentos. SóMZN. Rejeição preserva compromisso;rollback conjunto verificado. Requisitante original prepara umrascunho ligado sem copiar decisões,propostas,validadores ou reserva,repetição semduplicação.

Regressão159testes/2014verificações dospercursos afectados;fecho dirigido43/284 após ligações finais. Baterias sobrepostas,não somar. PostgreSQL descartável12/91 e3ensaios concorrentes com espera real no bloqueio daempresa:pedido/recepção nasduasordens e duplaaprovação com um só lançamento. Bases removidas. PHPStan0erros,Pint,formataçãofrontend,TypeScript,compilação,diff,18hashes originais ehash novo aprovados. Semrevisão visual completa,carga oulibertação comercial.

Piloto inspeccionado sóemleitura:estrutura000003 ausente,zero políticas/cancelamentos,camposMFA vazios,zero perfisAuditMetadata eacessos27. HTTPAdmin/Compras/Finanças:circuito503desligado,ordens consultáveis,sem comandos de negócio. MFA continua desligado;Auditoria6/8 continua pendente. Semcontas,palavras-passe,grants,aprovações,migração oucancelamento nopiloto;SGF não alterado. Provas issued-order-cancellation[-pg/-http/-pilot/-authorization].json;docs/cancelamento-ordens-emitidas.md.

Preparada instalação APENAS de3tabelas vazias,semactivar:ordem de migração exacta000003,hash eproposta issued-order-schema-proposal.json;ensaio emrestauro114tabelas,113tabelas protegidas intactas,newtablesvazias,um só registo de migração,base removida. Backup/hashes em issued-order-schema-preparation.json. PENDENTE DE AUTORIZAÇÃO PARA APLICAÇÃO NO PILOTO;docs/proposta-instalacao-cancelamento-ordens.md. Não aplicar migração geral,publicar política,conceder acessos ou cancelar por inferência desta entrega.

03/11/2026 — G1: divisão administrativa comum preparada e integrada

Fonte cartografia_moz.xlsx fornecida pelo proprietário, identificada por hash, apenas lida. Catálogo derivado reproduzível conserva as 20.407 linhas, oito colunas originais e zeros iniciais. Origem INE conforme indicação do proprietário; edição não confirmada. Há 9.678 referências seleccionáveis e 10.729 pendentes: 48 grupos de códigos repetidos, 9 nomes vazios, 8.610 linhas sem pai imediato, 377 com pai ambíguo e 1.688 com ancestral inconsistente (diagnósticos sobrepostos). Não fundir, apagar, inventar nomes ou mapear por semelhança. As 8.585 ausências da análise inicial eram percursos distintos, não linhas.

Serviço comum, API autenticada e selector progressivo paginado integrados na sede da empresa e criação/edição de fornecedores. Descrição na ficha e filtro territorial com descendentes confirmados, sempre no âmbito da empresa. Campo opcional, sem substituir morada ou pressupor país para fichas sem classificação. Manutenção, administrador actual, versão nativa do fornecedor, revisão independente por Finanças, auditoria e rollback preservados. Clientes não têm cadastro autónomo neste SGC; não criar facturação/SGF. Outros cadastros e disponibilidades em texto continuam preservados, sem conversão automática.

Fecho: 58 testes/591 verificações integradas e PostgreSQL descartável 12/83, com bases removidas. Baterias sobrepostas, não somar. PHPStan zero erros, TypeScript, lint/formatação frontend, Pint e compilação aprovados. Fonte original intacta e reprodução determinística conferidas. Sem revisão visual completa ou aceitação comercial.

Piloto inspeccionado em transacção só de leitura: ambas as colunas ausentes, migração000004 não aplicada, opção geográfica desligada, acessos versão27 e zero inscrições MFA. Sem comandos de negócio, alterações de aprovação, contas, grants, ordens, políticas ou SGF. Provas administrative-geography[-source/-pg/-pilot].json. Instalação de duas colunas JSON anuláveis e activação só da selecção opcional dependem de autorização em docs/proposta-instalacao-geografia.md; não executar migração geral nem classificar fichas existentes. MFA desligado; propostas de cancelamento e Auditoria6/8 continuam pendentes.

03/11/2026 — G1 instalado/activo com autorização; G2 revisão cartográfica entregue

O proprietário autorizou instalar os dois campos vazios e activar a selecção geográfica no piloto, preservando moradas, aprovações e MFA desligado. Autorização literal e hashes em administrative-geography-installation-authorization.json. Aplicada apenas migração000004: backup consistente restaurado e114tabelas conferidas,111tabelas protegidas intactas, todas as colunas anteriores de empresas/fornecedores preservadas e referências novasNULL. Base de restauro removida. Activação apenas SGC_GEOGRAPHY_ENABLED=true na configuração privada8005, demais opções preservadas; por defeito a capacidade continua desligada noutros ambientes. Provas installation/activation/pilot/http separadas. Não repetir instalação nem pedir novamente autorização. Estado pendente da proposta/preparação original é histórico; ficheiros originais preservados por hash.

HTTP comAdmin/Compras/Finanças confirmou campos e catálogo disponíveis, fichas existentes sem classificação e segurança MFA desligada. Não foram submetidas localizações, aprovações ou decisões de negócio. Versão de acessos27. Propostas de cancelamento e Auditoria6/8 continuam pendentes; nenhuma política/grant/conta/ordem/SGF alterada.

G2 acrescenta consulta administrativa de10.729pendências,50por página, filtros por diagnóstico e designação/ID, códigos/linhas originais e CSV de todos os resultados filtrados. Administração actual revalidada; outros perfis recusados, respostas privadas sem cache. Projecção de fonte comum, sem dados de empresas/clientes/fornecedores no relatório. Não há comandos de correcção ou invenção de localidades. CSV neutraliza fórmulas apenas na representação exportada; importar códigos como texto nas folhas de cálculo. Catálogo original e hashes preservados.

Validação G2:17testes/150verificações e PostgreSQL descartável17/150, baterias sobrepostas (não somar), base removida. PHPStan zero erros, Pint, lint/formatação, TypeScript e compilação aprovados. HTTPAdmin conferiu pesquisa e exportação;Compras recusado. Prova administrative-geography-review.json. Sem revisão visual completa, certificação da edição ou resolução humana das inconsistências.

03/11/2026 — G3: geografia operacional em armazéns e equipamentos

Reutilizados catálogo/IDs/edição e selector comum na criação/edição dos dois cadastros, sem converter áreas, copiar localidades ou pressupor classificação. Armazém altera apenas referência geográfica por comparação com o valor anterior, sem auditoria duplicada quando igual; equipamento conserva comando e versão nativos. Utilizador/competência actuais revalidados após bloqueio da empresa, manutenção recusada e auditoria transaccional. Guard web explícito no Stock evita confundir contas de candidatos com operadores.

Filtros territoriais incluem descendentes confirmados e conservam âmbito de empresa/departamento. Em Stock, os armazéns seleccionados limitam movimentos e saldos derivados. Em Equipamentos, limitam activos, associações/peças, artigos associados e histórico. Ficha mostra localização actual, sem reescrever requisições, aprovações, validações ou snapshots de movimentos. Omitir conserva referência; retirar explicitamente remove só a classificação.

Validação integrada67testes/481verificações de OperationalGeography,EquipmentSpareParts eStockOperations; fecho14/149 com suspensão independente, revogação de competência, manutenção e falha de auditoria; PostgreSQL descartável14/149, base removida. Baterias sobrepostas, não somar. PHPStan zero erros, Pint, lint/formatação, TypeScript, compilação e diff aprovados. Fonte/hash intactos, sem revisão visual completa.

Nova opção SGC_OPERATIONAL_GEOGRAPHY_ENABLED desligada por defeito e no piloto. Suspensão não afecta geografia já activa da sede/fornecedores. Migração000005 acrescenta só warehouses/equipment.geography_reference anulável. Preparação em backup/restauro114tabelas,111protegidas e colunas anteriores dos dois cadastros intactas,novos camposNULL,cópia removida. Apenas cópia recebeu migração; piloto inalterado. HTTPAdmin/Armazém/Compras/Finanças confirmou stock/equipamentos consultáveis,novos controlos ocultos e catálogo anterior disponível. MFA desligado,acessos27;sem comandos de negócio,aprovações,grants,políticas,ordens ouSGF.

Provas operational-geography[-pg/-http/-pilot].json e operational-geography-schema-preparation/proposal.json; docs/geografia-operacional-sgc.md. Instalação dos dois campos vazios e activação apenas da opção operacional dependem de autorização específica em docs/proposta-instalacao-geografia-operacional.md. Não aplicar migração geral, reutilizar autorização de G1 para G3 ou classificar cadastros por inferência. Outras propostas pendentes continuam separadas.

03/11/2026 — G4: geografia na disponibilidade principal do candidato

Integração sem migração, reutilizando JSON versionado do perfil, catálogo e selector comum. Escolha explícita até à localidade completa, botão de aplicação antes de guardar e designações canónicas resolvidas no servidor. availability_reference fica separado do objecto de três campos availability, mantendo compatibilidade dos formulários publicados. Nomes constituem fotografia da fonte na versão do perfil, sem segundo preenchimento. Disponibilidades adicionais continuam manuais; limite e duplicados nativos conservados.

API específica de candidato exige conta da empresa e versão de sessão actual, sem converter conta interna em candidato; paginação50,limite60/minuto,respostas privadas sem cache,sem dados de pessoas. Texto livre existente não recebe referências por semelhança. Pedidos antigos conservam referência conhecida apenas com textos inalterados; mudança manual elimina ligação na nova versão e remoção explícita conserva o texto indicado. Versões anteriores intactas. Desligar catálogo mantém perfil manual e referências históricas. Preparação da candidatura reutiliza disponibilidade nativa; snapshot/repetição de submissão conservam a versão mesmo após nova edição do perfil. Não há decisões automáticas de triagem ou aprovação.

Validação51testes/679verificações de CandidateGeography,CandidatePortal,CandidateSubmissions eAdministrativeGeography;PostgreSQL32/496,base descartável removida,baterias sobrepostas (não somar). PHPStan zero erros,Pint,lint/formatação,TypeScript e compilação aprovados. Provas candidate-geography[-pg/-http/-pilot].json e docs/geografia-candidatos-sgc.md. Fonte/hash intactos;sem revisão visual completa.

Piloto inspeccionado só em leitura:zero portais configurados,contas e versões de perfil de candidatos;nenhuma inscrição ou identidade criada para demonstrar G4. HTTP recusa visitantes e sessões apenas internas;catálogo interno actual disponível após selecção do contexto nativo. Percursos positivos apenas nas bases descartáveis. Geografia da sede/fornecedores continua activa;G3 ainda sem colunas/activação e aguarda autorização específica. Acessos27,MFA desligado;sem migrações,perfis,aprovações,políticas,ordens ouSGF alterados. Não abrir portal/criar candidato ou instalar G3 por inferência desta continuação.

03/11/2026 — G5: cartografia nas disponibilidades adicionais

Estendido o selector e o resolvedor de G4 aos até 20 locais adicionais do candidato, sem migração. Objectos de localização mantêm os três campos antigos; referências ficam em lista separada e alinhada no JSON da versão, com null para entrada manual. Servidor valida fonte/ID/localidade completa e resolve nomes; limite, duplicados entre todos os locais, motivo, versão e sessão continuam nativos. Não criar localidades nem inferir códigos a partir de textos livres.

Remover uma linha remove a referência correspondente. Chaves estáveis de interface impedem que estado de selecção migre para outra linha após remoção; não são dados de negócio. Os pedidos antigos que omitem dados conservam-nos; ao reordenar locais sem referências, só são reutilizadas associações já conhecidas para os mesmos textos exactos. Texto modificado passa a manual; referências null e listas vazias permitem remoção explícita. Fonte desligada preserva histórico e pedidos antigos inalterados.

Formulários publicados conservam o formato de três campos, reutilizando os locais do perfil. Snapshot da candidatura guarda a versão com referências adicionais; retirada posterior no perfil não altera a submissão e repetição conserva o mesmo recibo. Não há triagem, aprovação ou selecção territorial automática. Mantida a recarga nativa após gravação, sem actualizar a versão de uma edição local por uma consulta concorrente.

Validação integrada: 46 testes/649 verificações de CandidateGeography, CandidatePortal e CandidateSubmissions; PostgreSQL descartável 39/549, base removida. Baterias sobrepostas, não somar. PHPStan zero erros, Pint, lint/formatação, TypeScript e compilação aprovados. Provas candidate-additional-geography[-pg/-http/-pilot].json; docs/geografia-disponibilidades-adicionais-sgc.md. Fonte/hash preservados; sem revisão visual completa.

Piloto consultado só em leitura: zero portais, contas e perfis de candidatos; sem criação de identidades ou abertura de inscrições para demonstrar G5. HTTP recusa visitantes e sessões apenas internas; catálogo de operadores preservado. Percursos positivos só descartáveis. Geografia da sede/fornecedores continua activa, G3 aguarda autorização e permanece sem estrutura/activação. Acessos versão27, MFA desligado; sem alterações de stock, aprovações, políticas, permissões, ordens ou SGF.

03/11/2026 — G6: consulta territorial de candidaturas recebidas

Filtro opcional na caixa de Pessoas por referências principal e adicionais do snapshot submetido, incluindo descendentes do território escolhido. Não consulta o perfil actual nem associa códigos a nomes manuais. Referências de outra edição e listas adicionais ausentes/antigas são tratadas sem remapear dados; retirar filtro conserva a caixa completa. SQL JSON parametrizado em SQLite/PostgreSQL; restantes motores mantêm caixa sem este filtro.

Autorização nativa CandidateTriage.canRead, empresa/processo, utilizador e competências actuais e vigência mantidos. Novo catálogo por processo no contexto Pessoas, sem exigir entrada em Compras ou conceder acesso ao catálogo operacional desse contexto. Resultados em ordem de recepção, vinte por página; paginação conserva filtros e foco submission. Ramo principal/adicionais agrupado dentro do âmbito de empresa/processo. Pendências de triagem continuam globais ao processo; nenhuma decisão, pontuação, selecção ou aprovação automática. Auditoria nativa de consulta conservada, sem exportação pessoal nova.

Validação integrada 45 testes/682 verificações de CandidateSubmissions e WorkContext; PostgreSQL descartável 8/135, base removida; baterias sobrepostas, não somar. Inclui principal/adicionais, nomes manuais iguais sem associação, perfil actual divergente, vinte+uma candidaturas/paginação, foco, isolamento, revogação, contexto, suspensão e outras edições. Fixtures respeitam chaves estrangeiras e não alteram submissões imutáveis existentes. PHPStan zero erros, Pint, lint/formatação, TypeScript, compilação e diff aprovados. Fonte/hash preservados; sem revisão visual completa.

Provas candidate-territory[-pg/-http/-pilot].json; docs/territorio-candidaturas-recebidas-sgc.md. HTTP do piloto confirmou Pessoas acessível, processo inexistente404 e catálogo de Compras403 no contexto Pessoas, sem caixas visíveis nessa conta. Percursos positivos de filtro só em bases descartáveis. Zero portais/contas/perfis de candidatos no piloto, acessos27, MFA desligado. Sem processos, migrações, classificações, permissões, triagem, aprovações, políticas, ordens ou SGF alterados. Geografia da sede/fornecedores continua activa; G3 permanece sem estrutura/activação e aguarda autorização própria.

03/11/2026 — G7: disponibilidade recebida na ficha e dossiê de Pessoas

ReceivedCandidateAvailability reutiliza a origem electrónica da triagem aceite por empresa/processo, acrescentando received_availability apenas à projecção de leitura PeopleProcessProjection. Página e dossiê partilham o campo e a redacção. Revalida utilizador actual e CandidateTriage.canRead; consultar ou avaliar o processo, por si só, não concede as fontes. Whitelist: referência de submissão, versão, disponibilidade principal/adicionais e respectivas referências; sem email, telefone, documentos, respostas ou conta de candidato.

Usa a fotografia da submissão e confere a versão registada na triagem. Não consulta perfil actual nem resolve nomes no catálogo novo. Texto manual mantém-se sem código inventado; desligar catálogo conserva o histórico. Candidatura interna manual sem origem e submissão recusada não recebem localização por inferência. Consulta em lote, sem novas gravações de cadastros ou triagem.

O campo NÃO integra PeopleHiring.matrix nem as linhas congeladas da selecção. Critérios, pontuações, contribuintes, selecção e aprovações preservados. Testes confirmaram equivalência página/dossiê, leitor sem fontes, revogação de âmbito e identidade actual, isolamento entre processos, referência principal/adicionais/manual, perfil posteriormente alterado, catálogo desligado, base de decisão intacta e tabelas de negócio/auditoria inalteradas pela consulta.

Validação integrada: 89 testes/2237 verificações de CandidateSubmissions e PeopleHiring; PostgreSQL descartável 7/97, base removida; baterias sobrepostas, não somar. PHPStan zero erros, Pint, lint/formatação, TypeScript, compilação e diff aprovados. Fonte/hash intactos. Provas received-availability[-pg/-http/-pilot].json e docs/disponibilidade-recebida-processo-sgc.md. Sem revisão visual completa ou aceitação empresarial.

Piloto consultado só em leitura, sem processos visíveis para comparar positivamente nessa conta e zero portais/contas/perfis de candidato; os casos positivos de disponibilidade electrónica ocorreram apenas em bases descartáveis. Acessos versão27, MFA desligado; sem migração, conta, perfil, aprovação, triagem, política, ordem ou SGF alterados. Geografia da sede/fornecedores continua activa e G3 permanece pendente da autorização própria, sem instalar estrutura ou activar a opção operacional por inferência.

G8 — 03/11/2026: relatório de medidas de melhoria segmentado pelo território actual da ficha do fornecedor, partilhando SupplierGeography com o cadastro. Totais, paginação e CSV respeitam os mesmos filtros e acessos. Sem migração, alteração de snapshots, decisões, perfis ou aprovações. MFA desligado; G3 operacional continua pendente. Documentação: docs/territorio-melhorias-fornecedores-sgc.md; prova: docs/proofs/supplier-territory.json. Validação dirigida SQLite: 50 testes/700 verificações; sem nova execução PostgreSQL ou revisão visual completa.

A2 — 03/11/2026: reprodução dedicada da requisição interna, reutilizando snapshot e WarehouseFulfilment.progress. Separação de pedido/reserva/entrega/saldo/cancelamento, histórico de autorização e recepção, ligações aos documentos individuais A1. Mesmos acessos da ficha, sem mutações ou factura. Sem migração; aprovações preservadas e MFA desligado. Docs/armazem-requisicao-impressao.md; provas warehouse-request-print.json e warehouse-request-print-pg.json. Não declara revisão visual ou aceitação comercial.

Validação A2: bateria conjunta WarehouseFulfilmentTest + WarehouseRequestsTest aprovada, 23 testes/408 verificações; PostgreSQL descartável 3 testes/45 verificações, base removida. PHPStan, tipos, formatação, rotas e compilação aprovados. Sem revisão visual completa. Contagens não aditivas às provas anteriores.

A3 — 03/11/2026: CSV integral de acompanhamento das requisições internas, com filtros aplicados e âmbito partilhado com a lista. Uma linha por artigo/unidade; quantidades e estados reutilizam progress nativo. Paginação não limita a exportação; protecção de células de folha de cálculo. Sem novas aprovações, campos, migrações ou movimentos; MFA desligado. Docs/armazem-requisicoes-exportacao.md; provas warehouse-request-export.json e warehouse-request-export-pg.json. Sem teste de carga ou revisão visual completa.

Validação A3: WarehouseFulfilmentTest + WarehouseRequestsTest, 26 testes/437 verificações aprovados. PostgreSQL descartável, 3 testes/29 verificações aprovados e base removida. PHPStan, tipos, formatação e diff aprovados. Contagens não aditivas às provas anteriores.

O2 — 03/11/2026: diagnóstico integrado de reposição e integridade documental pelo comando sgc:operations-check. Reutiliza verificadores nativos, consulta global só em consola sem identidade/sessão, saída agregada sem detalhes privados e continuação em falha parcial. Estado incompleto/indisponível nunca equivale a sucesso. Não instala serviços, recupera compras, corrige ficheiros ou grava telemetria. Sem migrações ou interface nova; aprovações preservadas e MFA desligado. Docs/operacao-diagnostico-integrado.md; provas operational-health.json e operational-health-pg.json. Instalação recorrente, restauro, capacidade e aceitação mantêm-se pendentes.

Validação O2: 17 testes/112 verificações aprovados em OperationalHealthTest, ReplenishmentHealthTest e ReceiptDocumentHealthTest; PostgreSQL descartável 5 testes/36 verificações aprovados e base removida. Contagens não aditivas às provas anteriores. Interface inalterada, sem repetição da compilação nesta etapa.

E2 — 03/11/2026: ficha de equipamento reúne também requisições internas ao armazém ainda pendentes, por ID nas linhas preservadas, sem associação por texto. Projecção só das linhas do equipamento, estado/reserva/entrega/saldo nativos, ligações aos processos e paginação independente de15. Acesso ao equipamento não concede acesso ao armazém; empresa/departamento/capacidades mantidos. Sem novos registos, movimentos, migração ou aprovações; MFA desligado. Docs/equipamentos-requisicoes-internas.md; provas equipment-warehouse.json e equipment-warehouse-pg.json. SQLite57testes/737verificações e PostgreSQL4/107 aprovados, sem somar a provas históricas; não declara revisão visual/carga. G3 continua pendente.