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.