compras/docs/orientacoes-continuidade.md

# Continuidade do desenvolvimento do SGC

**Último estado — sourcing preparado, demonstração parcial:** candidata **040fb0cb67a77d61**, manifesto `040fb0cb67a77d618011bc7ab365c53d3d4b1a787c4c0c0a2d54f315b3658e58`, [entrega/provas/recuperação](consultas-adjudicacao-sgf.md). Em 8039/55439/1:1:1 há fornecedores, três cotações e um avaliador por cotação; o fluxo completo foi confirmado **só nas cópias isoladas**. Proprietário recusou quarta conta e autorizou exactamente prepare ao ID 1, evaluate/propose ao ID 2; não conceder confirm, aprovação ao requerente ou escrita ao Consulta para completar o cenário. Requisição 1/100 MZN/versão 3 e reserva única intactas. Não declarar integração integral ou adjudicação concluída na demonstração.

Schema sourcing R1 é extensão auditada do ledger base R2. Código e schema/dados recuperam-se separadamente; simples rollback ao 166 não permite reabrir com o catálogo alterado. Backup privado antes da extensão em `private/sourcing-recovery/before.dump`, hash `cb9d55db5fee08cb36e3af4c962556b465be9e14071b5c3505c834d2ef4d7bcd`; journals nativos e prova de restauro das cópias preservados. Não usar down/truncate na demonstração nem executar plano SQL real. Valores diferentes da reserva e níveis superiores de aprovação estão bloqueados/sinalizados, não contornados. Implantação real/Tempo mantêm 0.1.1. Encomendas/recepção/pagamentos/contactos externos e revisão visual continuam separados; não repetir browser bloqueado ou suites aceites sem mudança relevante.

**Último estado — leitura Consulta corrigida e primeiro percurso fechado em 8039:** sucessora `OPERATIONAL-CANDIDATE-166e397e3ca63f02`, ZIP SHA-256 `620660d76329c800f3c6b18a521c03ccdadce09502d2a7744e1e91b77560f785`, manifesto `166e397e3ca63f02d3dc57651c8eecf50e1fc314410c78e05386b518d3a661de`. [Matriz/provas](transferencia-sgf.md). Não conceder direitos adicionais para leitura; Port::authorize permite somente view em registo já isolado. Requisição 1/100 MZN/versão 3 e reserva única preservadas; actualização→reversão→reaplicação conferidas, sem schema novo. A limitação 404 descrita historicamente abaixo foi resolvida. Próximo percurso escolhido: da requisição aprovada até cotações/comparação/adjudicação independente; mapear antes de implementar. Não declarar integração integral. Implantação real permanece adiada em 0.1.1, revisão visual separada. Recuperação desta correcção em `private/read-correction-recovery`; ID final de aplicação `3afbba5e3ed60b853d62b869`. Nenhum novo direito, conta ou DCL SQL.

**Último estado — demonstração autorizada e habilitada:** 8039/55439/base sgf_modules_dev_2576427d1939/contexto 1/1/1. Aplicados exactamente os 14 direitos aprovados; centro/dotação 10.000 MZN/2026 sintéticos; percurso e reserva única conferidos, independente ID 2 aprova preparação ID 1. [Entrega, provas e recuperação](demonstracao-requisicoes-8039.md). Não reexecutar bootstrap (fechado) nem provisionadores destrutivos. Nenhuma conta ou DCL SQL criada; preservada instalação real em 0.1.1. **Pendência concreta:** perfil Consulta tem view mas regra actual oculta requisições de terceiros (404); decidir âmbito de leitura antes de alterar regra/direitos, sem conceder aprovação/configuração como contorno. Sessão desta cópia agora file; owner/runtime mantido como limitação de demonstração. Revisão visual e implantação real continuam separadas. Registos de proposta pendente abaixo são históricos, sucedidos pela confirmação e execução exclusivamente sintéticas.

**Última orientação: não avançar com a instalação desactivada no destino real.** Próximo passo é a confirmação da [proposta única de ambiente sintético](proposta-desenvolvimento-sgf.md), reutilizando a instância existente 8039/55439, não criar outra. Nenhuma alteração funcional/SQL autorizada por esta proposta; não executar GRANT/REVOKE do plano real. Preservar `sgf_tempo_dev`, configuração Tempo e 0.1.1. Os registos de implantação real abaixo ficam adiados; valores sintéticos e contas existentes estão discriminados na proposta, sem obrigação de segundo administrador para esta demonstração.

**Estado actual — candidata corrigida, 02/11/2026:** os bloqueantes históricos de duas tabelas, preparação de centros/dotações e separação SQL foram resolvidos/ensaiados na candidata `OPERATIONAL-CANDIDATE-401ce31ae5f2dd20`. [Decisão actualizada](decisao-instalacao-sgf.md) e [prova de 157 controlos/restauro de 103 tabelas](proofs/sgf-corrected-delivery.json) prevalecem sobre o estado anterior abaixo. **Não instalar, activar nem executar GRANT/REVOKE sem confirmação separada**; SGF mantém 0.1.1. Proposta SQL concreta em `docs/proofs/sgf-corrected-sql-plan.json`, nunca aplicada no destino. Backup/restauro de dados reais e configuração nominativa continuam por realizar na janela autorizada. Não repetir suites aceites nem navegador bloqueado. Ver também o registo detalhado no final deste documento.

**Decisão de instalação sem execução — 02/11/2026:** proprietário escolheu decidir, não instalar. [Decisão](decisao-instalacao-sgf.md) e [inventário read-only](proofs/sgf-installation-decision-inventory.json): destino C:/laragon/www/sgf-tempo, PostgreSQL sgf_tempo_dev/127.0.0.1:55432, PHP 8.4.27, 87 tabelas, runtime sgf_dev_app sem DDL, cb/ir ausentes. Candidata 5fae7cf7f99c42ba/ZIP/hashes e ambos os plans conferidos sem aplicar. Não recomendar percurso operacional antes de fechar ligação migradora/DCL mínima e bootstrap de centros/dotações: interface selecciona fontes existentes e BudgetWorkspace depende de duas tabelas não entregues nesse schema. Catálogo funcional pronto em candidata não equivale a direitos runtime/admin já configurados; equipamento/peças não bloqueiam o recorte básico. Há só uma concessão administrativa da empresa, pendente regra de dois na entrega/activação. Navegação modular tecnicamente aceite em 02/11, separada de pendências visuais/associações/volume e da instalação de Compras. Sem repetir suites, criar backup, migrar, outorgar, parar/reiniciar serviço ou activar. Manter SGF 0.1.1. A decisão não autoriza executar a operação antes de confirmação nem ocultar as lacunas com fixtures/SQL de negócio.

**Reconciliação da entrega modular — 02/11/2026:** documentos próprios do SGF agora conferidos registam entrega técnica de navegação modular e conclusão de regressão/perfis (185/3.220, focados 8/90, três perfis sintéticos), com recheck de integridade datado de 02/11. As referências históricas seguintes a «sem resultado apresentado» ficam sucedidas por esta evidência e pela matriz: não reimplementar nem repetir suites por causa delas. Revisão visual, recargas, associações antigas e volume/paginação continuam separados. Esta retoma fez leitura/reconciliação documental, sem nova execução dos resultados reportados. Candidata de requisições não instalada, SGF permanece 0.1.1. Instalação continua a exigir decisão separada; esta reconciliação não a presume.

**Transição de bundles/caches nativos — 02/11/2026:** candidata `OPERATIONAL-CANDIDATE-5fae7cf7f99c42ba`, ZIP e hashes em [proofs/sgf-update-cache-delivery.json](proofs/sgf-update-cache-delivery.json). 32 controlos novos aprovados, sem suites anteriores repetidas: actualização com proveniência, arquivo/reposição do bundle anterior, falha/recuperação, ordem de reversão, nova tentativa com histórico, Artisan config/route/event cache nativos, compilação interrompida e cache inválido, CLI e reinícios efectivos de servidor isolado. `current.json` privado da implantação não é o ponteiro purchasing, que continua 0.1.1. Não adoptar bundle desconhecido nem migrar schema por arrasto. Acção cache exige manutenção/--offline; após rollback, voltar a compilar para a versão reposta e reiniciar os serviços próprios. Caches personalizados e gestores de serviços de cada cliente continuam a exigir procedimento compatível. Nenhuma aplicação no destino/publicação/concessão real. Próxima acção: revisão e decisão separada de instalação, não nova autorização por etapa técnica nem activação presumida. Reorganização modular permanece distinta e pendente.

**Aplicação/reversão do código — 02/11/2026:** `CodeDeployment` e `sgf-code-deploy.php` preparados para primeira instalação com manutenção/serviços parados, journal/backups, lock, verificação de hashes/baseline e restauro de código/caches padrão. 42 controlos novos aprovados via PHP fixado, sem DB/serviços/browser/suites antigas; [prova](proofs/sgf-code-deploy-delivery.json). Candidata `OPERATIONAL-CANDIDATE-10dce6cd57fa1f31`. Não activa configuração nem retira manutenção/reinicia serviços. Recusa caches personalizados e recuperação sobre alterações locais/caches posteriores. Não implementa ainda transição sobre bundle existente: não inferir updates integrais do novo percurso. Preservados SGF de destino 0.1.1 e artefactos anteriores. Próximo incremento: transição versionada e caches nativos/gestão de serviços em isolamento; nenhuma instalação ou activação no destino sem decisão separada. Reorganização modular permanece distinta e pendente.

**Arranque e HTTP SGF — 02/11/2026:** candidata `OPERATIONAL-CANDIDATE-4b25f81932efd69d` integra bundle/rotas pelo provider nativo e associa `purchasing_requisitions.view` à descoberta de Compras. Novo middleware mantém contexto/opção/âmbito/schema, módulo adquirido/seleccionado e geração de contexto; autoridade inicial administrativa permanece sem outorga automática. 27 controlos novos HTTP aprovados em instalação com código e dependências copiados, APP_ENV production, base/role próprias removidas; sem repetir suites aceites ou usar browser. [Prova](proofs/sgf-composition-delivery.json). Nenhuma aplicação no destino, ponteiro 0.1.1 e candidatas antigas preservados. Pendência seguinte: aplicação atómica/reversão das sobreposições/código e caches/reinício, antes de propor activação. Não declarar instalação comercial concluída nem confundir esta integração com reorganização modular posterior, que mantém entrega própria pendente.

**Composição operacional/preparação de schema — 01/11/2026:** candidata `OPERATIONAL-CANDIDATE-29687a1c9bc0e0b5`, sem instalação no SGF. `scripts/prepare-sgf-operational.php` prepara artefacto; `scripts/sgf-internal-install.php` distingue plan read-only e migrate transaccional de schema, com destino/manifesto/backup conferidos, contrato orçamental e journal imutável. Mesmo motor e permissões, novo ramo operacional por destino/schema/âmbito explicitamente habilitados, sem obrigar nome de base QA ou ambiente de ensaio. 20 controlos novos + restauro em production/base não-QA aprovados em [proofs/sgf-operational-delivery.json](proofs/sgf-operational-delivery.json), sem repetir suites aceites. Não confundir preparação de schema com activação: não alterou código/provider/rotas/concessões/dados no SGF instalado; ponteiro 0.1.1 e candidatas anteriores preservados. Próximo passo é composição de arranque/rotas e prova HTTP numa cópia isolada. Não executar migrate no destino, activar 0.1.2/outra versão ou publicar sem a decisão separada. Reorganização modular mantém-se distinta e sem resultado próprio apresentado.

**Preparação de acessos SGF — 01/11/2026:** criada sobreposição candidata de catálogo/gestão de permissões e atribuição inicial nominativa/auditada, com rotas/ecrã separados, sem alterações no host instalado. `scripts/prepare-sgf-access.php` produz hashes antes/depois e recusa divergências; não é instalador. 24 controlos novos PostgreSQL aprovados em [proofs/sgf-access-delivery.json](proofs/sgf-access-delivery.json), sem repetir suites aceites. Preservados os direitos anteriores na criação de unidades; nova autoridade inicial exige acção explícita de administrador autorizado e âmbito habilitado, nunca outorga automática. SGF mantém 0.1.1, candidata IR imutável e rotas não activadas. Próximo trabalho: composição orçamental operacional, instalador de schema/arranque, integração HTTP da preparação e pacote SGF específico; continuar sem instalar/publicar por arrasto. Reorganização modular não se confunde com este incremento e continua sem resultado próprio apresentado.

**Classificação posterior à candidata — 01/11/2026:** equipamentos/peças são fora do âmbito do percurso básico entregue; catálogo administrativo/autoridade inicial de permissões, composição orçamental operacional e instalador/arranque rastreáveis são bloqueantes para instalar o percurso numa empresa. A guarda QA actual bloqueia inclusive consulta/configuração fora do ensaio. Não resolver com grants SQL, ambiente QA numa base real ou extracção do ZIP sobre a raiz SGF. Procedimento exacto do que existe, etapas sem executor e recuperação por falha registados em [transferencia-sgf.md](transferencia-sgf.md). Nenhum teste aprovado repetido, nenhuma mudança de código/candidata/destino. SGF mantém-se 0.1.1. A reorganização modular pedida depois é entrega distinta e permanece sem resultado apresentado; não a marcar concluída por esta integração.

**Candidata de requisições internas — 01/11/2026:** implementado motor partilhado e adaptadores Compras/SGF para rascunho, submissão/reserva existente, aprovação por outra identidade e consulta/histórico. Contexto `procurement.internal`, isolamento por empresa/unidade, permissões renovadas, snapshots/versionamento, chaves de operação e locks no servidor. Configuração e escolha de contexto não atribuem direitos. Compras autónomo preservado; migração 46 ainda não aplicada à base persistente. Provas sintéticas isoladas incluem concorrência, revogação, falha transaccional, resposta perdida, migração falhada/compatibilidade e restauro de dados/schema com consulta posterior. Ver [matriz, limites e recuperação](transferencia-sgf.md), [artefactos](proofs/internal-requisitions-candidate.json) e [prova SGF](proofs/internal-requisitions-sgf.json).

**Não activar:** SGF permanece 0.1.1. Não instalar 0.1.2, nova candidata, schema ou concessões no destino sem a decisão separada pedida pelo proprietário. Não publicar. Artefactos desta entrega são para revisão; updater actual recusa-os porque o seu contrato permanece só código. Rotas candidatas carregam apenas no bootstrap explícito de teste; sem alteração do menu público/instalado. Preparação operacional de migrações e catálogo privado administrativo pendente. Equipamentos/peças SGF e fornecedores continuam fora deste recorte; contratações para terceiros continuam excluídas do SGF. Não reabrir a via de navegador bloqueada nem declarar revisão visual feita. Os estados históricos seguintes conservam as respectivas provas e são sucedidos por este incremento.

**Conferência antes de ampliar — 01/11/2026:** pedido posterior do proprietário restringe o próximo passo à confirmação de instalação independente, alcance do rollback e matriz transferido/parcial/pendente por processo/adaptador/ecrã. Matriz completa revista em [transferencia-sgf.md](transferencia-sgf.md), cópia reconciliada no SGF. Cliente não precisa de checkout/serviço/base de Compras; teste de origem sintética indisponível e prova real SGF com todos os includes dentro do host aprovados (mecanismo 6 testes/29 asserções, PHP SGF 8.4.27, sem base). Rollback é **só código/ponteiro**, não dados/schema; migrações futuras precisam de compatibilidade, autoria/versão, aplicação idempotente/auditada e backup/restauro/recuperação ensaiados. Prova `purchasing-client-independence.json`. SGF continua em `0.1.1`: extracção económica já em preparação foi interrompida antes de activar; candidata `0.1.2` existe no canal, **não instalada**. Preparação local passou 103 testes existentes e cinco de economia, sem constituir prova SGF. Não executar nova transferência por consequência desta revisão. Matriz propõe requisição interna até aprovação/consulta como próximo percurso completo, incluindo reserva existente, adaptadores e ecrãs, aguardando escolha de sequência na revisão. Contratações para terceiros continuam excluídas do SGF. Sem dados, concessões ou domínio alterados.

**Prioridade expressa — transferência Compras → SGF e updates, 01/11/2026:** proprietário esclareceu que este é o foco, acima do selector de contexto. Primeiro pacote realmente transferido: projecção de reposição, fonte única `packages/purchasing`, fachada antiga e versão instalada no SGF sem dependência do checkout de Compras. Mecanismo `composer purchasing:transfer -- <SGF> <canal>`: regressões, fotografia imutável, versão patch por mudanças, SHA-256/caminhos/inteireza, prova candidata no PHP do host, instalação imutável/ponteiro atómico/lock, histórico e rollback explícito de código. Versões `0.1.0 → 0.1.1`, rollback e reactivação reais locais aprovados; retry sem reinstalação. Final 86 testes/566 asserções no publisher, SGF Unit sem base 2/11 e análise PHP dirigida aprovados. Não executar reset da demonstração SGF; não houve migração/seed/conta/concessão ou dependência alterada. Contrato actual recusa pacotes com schema/permissões; canal deve ser de confiança (hash não é assinatura). Mecanismo actualiza apenas capacidades já extraídas: transferência integral de requisições, fornecedores, inventário operacional, aprovações/ecrãs e Pessoas internas ainda pendente. Conservar todas as funcionalidades SGC e excluir Pessoas para terceiros no SGF. Próximo trabalho é extracção/adaptação por percurso e migrações ensaiadas, não expandir novamente o selector. Ver [transferencia-sgf.md](transferencia-sgf.md) e provas `purchasing-*.json`. Sem publicação no domínio.

**Retoma — contexto de trabalho, 01/11/2026:** primeiro incremento em código e 8005. Separados produto contratado/configuração empresarial/permissões; escolha em `/dashboard`, sessão vinculada a utilizador+empresa, auto-opção única ao escolher área, nenhuma opção sem dados de negócio, contexto visível, menus e middleware no servidor. Perfis associados explicitamente aos contextos, sem somar funções de outras opções. Migração 45: origem interna das requisições/processos de Pessoas (autorizada), scope e imutabilidade SQLite/PostgreSQL; backup/restauro e campos anteriores de 106 tabelas preservados. Avaliação local com catálogo completo só após conferência da base/role/empresa sintéticos; clientes usam limites comerciais por empresa + subconjunto activado pela interface. Novas empresas começam sem opções; compatibilidade de existentes exige configuração explícita antes de entrega. SGC mantém quatro opções; composição SGF exclui contratações para terceiros. Venda e contratações para terceiros ainda sem percurso operacional neste incremento, bloqueadas em vez de usar dados internos. Guardar/descartar/cancelar na ida ao painel: gravação integrada ao rascunho de requisição; outros formulários, múltiplas edições e histórico do navegador ainda exigem cobertura/conferência. RH só após formalização, nunca selecção/rascunho; envelope futuro sem envio, sem formalização legal ou módulo RH implementados. `sgc:delivery-check` confere sem apagar; clientes recebem base limpa, avaliação fica local. Catálogo comercial por módulo e editor dos limites adquiridos, distribuição SGF e actualizador integral pendentes. Provas contexto PG 12/83, dirigida final 66/644, regressão geral 858 aprovados/2 ignorados/8 503 asserções, análise PHP dirigida/build aprovados. PHPStan global com problemas web/candidate; visual indisponível porque browser host não respondeu. Sem publicação no domínio. Ver secção inicial de desenvolvimento para limites e próxima acção; não declarar pedido integralmente concluído.

**Retoma — triagem e avaliação, 30/10/2026:** decisão explícita de preparador atribuído em `/pessoas/{process}/recebidas/{submission}/triagem`, com ausência de conflito, motivo reservado e mensagem pública distintos. «Aceite para análise» cria candidatura interna a partir dos dados congelados, sem usar o perfil actual, associar por nome ou incluir automaticamente em base. «Não aceite para análise» não cria candidatura interna. Decisão/operação preservadas, retries idênticos idempotentes, revisão/reabertura ainda pendentes. Actor importador fica em `created_by`, mantendo independência na avaliação/aprovação; fonte electrónica e versão do perfil identificadas na matriz/relatório. Titular só recebe estado/data/mensagem pública, sem motivo interno ou ID interno. Preparadores e avaliadores expressamente autorizados a evidências/entrevistas consultam fontes; só preparador com função/atribuição actuais decide/publica. Painel oferece triagem antes de avaliar; fecho/avaliação/selecção verificam pendências. Não admitir novas candidaturas após começar a avaliação; não fundir referências manuais coincidentes. Migração 40 apenas 8005: backup/restauro e 103 tabelas antigas preservadas, tabela nova vazia, sem transferências automáticas, contas/grants, emails, IA ou domínio. Provas `proofs/candidate-triage*.json`. Próximo incremento: anexos verificados e complementos/revisões, depois modalidades espontâneas/fornecedores. Visual pendente; não declarar portal integralmente concluído.

**Retoma — acesso e submissões electrónicas, 30/10/2026:** confirmação de email e recuperação implementadas, Mail::fake nos ensaios, transporte real indisponível e nenhum email enviado. Tokens SHA-256, segredo em fragmento/POST, expiração/utilização única, auditoria, invalidade após reenvio e revogação de sessões por versão na recuperação. Ler estado actual da conta ao autorizar, inclusive depois de locks, para não aceitar sessões antigas. Email confirmado não significa identidade validada. Sem token em logs ou flash. APP_URL configurado é a origem das ligações; não usar Host do pedido. Nova publicação explícita por preparador de Pessoas, formulário congelado do processo, candidatura de dados/comprovativo e consulta restrita pelo titular/preparador. Não divulgar propósito interno, critérios internos, selecção ou notas. Antes de consultar PeopleProcess no canal externo, retirar apenas o scope global de tenant e aplicar tenant explícito da rota/conta, além da publicação/prazo; nunca depender da sessão interna no mesmo browser. Não inserir candidato externo automaticamente em users/people_registry/people_applications. Recepção não é aceitação para análise, inclusão na base ou selecção. Formulários com anexos obrigatórios não podem publicar neste percurso enquanto não existir recepção/verificação de ficheiros; não retirar esses requisitos para contornar. Próximo: anexos verificados, triagem e ligação à avaliação sem redigitação, complementos/revisões e modalidades espontâneas/fornecedores. Migrações 38/39 locais 8005, backup/restauro, 100 tabelas anteriores preservadas, três novas vazias. Sem portal aberto, candidato criado, email real, IA, domínio ou aceitação visual. Provas `proofs/candidate-submissions*.json`.

**Retoma — área externa do candidato, 30/10/2026:** implementado guard `candidate` e tabelas próprias, configuração de portal por empresa (aviso versionado/novos registos), entrada/saída, perfil próprio com versões preservadas e disponibilidade província/distrito/localidade. Contas externas não são utilizadores internos; não mudar o guard por omissão, reutilizar `User` ou expor props internas nas rotas `candidaturas/*`. Candidatos não recebem acesso a avaliações. Sem portal configurado: 404; fechado a novos registos: titulares mantêm entrada/perfil. Reconhecimento do aviso não autoriza bolsa/partilha. Email/identidade ainda não verificados e recuperação/MFA externo pendentes; apresentação de candidaturas/anexos também pendente. Não declarar a área pronta para utilização comercial integral. Migração 000037 apenas 8005, backup/restauro e 96 tabelas anteriores preservados, quatro tabelas novas vazias, nenhum portal aberto ou candidato criado automaticamente. Provas `proofs/candidate-portal*.json`. Próximo: verificação/recuperação de conta, ligação de submissão e documentos verificados/comprovativo/triagem, preservando versões e configuração por modalidade. Sem emails, IA, domínio ou aceitação visual neste incremento.

**Retoma — candidaturas electrónicas, 30/10/2026:** proprietário aprovou a abordagem faseada proposta na análise do Word e pediu disponibilidade por província, distrito e localidade. Primeiro incremento implementado: `/administracao/candidaturas/formularios`, ligado à Parametrização, seis modalidades separadas por roteiro/tipo e com/sem concurso. Campos/documentos parametrizáveis, histórico completo por inserção, auditoria e concorrência. Novos processos de Pessoas congelam a versão do formulário na criação, mantendo as protecções SQL anteriores; não alterar regras de processos já existentes. «Prevista para recepção» é intenção configurada, não portal aberto. Sem registos criados automaticamente. Disponibilidade geográfica é um campo estruturado distinto da morada, inicialmente obrigatório nos modelos ainda não guardados de pessoas; validador exige os três níveis quando preenchido. Falta cadastro territorial oficial/múltiplas localizações e integração na área do interessado. Migração 000036 local 8005, backup/restauro fresco, 95 tabelas anteriores preservadas, nova tabela vazia. Provas `proofs/submission-forms*.json`. Próximo: identidade externa/perfil, candidatura e anexos verificados/comprovativo, triagem/complementos/revisões. Estados «Aceite para análise» e «Incluído na base» separados no futuro circuito. Não expor notas internas, fundir pessoas por nome ou reutilizar perfis entre empresas sem autorização. Não adoptar prazos/consentimentos/limites do Word como aprovados; ainda não activados. Sem novas chamadas IA, publicação no domínio ou aceitação visual.

## 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.

**Registar uma vez/reutilizar — Pessoas, 30/10/2026:** implementado cadastro próprio/partilhado por permissões, nome/referência/perfil, versão/auditoria/arquivo. Primeira candidatura pode guardar perfil no mesmo acto; seguintes seleccionam fonte autorizada. Nome e snapshot vêm do servidor; dados específicos da candidatura não reescrevem cadastro. Snapshot e referência/versão preservados por processo, actualizações/arquivo não alteram histórico; sem duplicar pessoa ligada no mesmo processo ou fundir nomes. Preparador consulta próprios, capacidades `people_registry_read/manage` dão âmbito partilhado; administrador não recebe leitura alheia automática, cadastro não dá acesso aos processos. Migração 000034 apenas em 8005: backup/restauro e 93 tabelas antigas preservados, nova tabela vazia, duas colunas nulas em candidaturas antigas, sem pessoas/grants/importação. Provas `people-registry.json`, `people-registry-install.json`, `people-registry-pg.json`. PHP integral 698/696 aprovados/dois ignorados, 6 739 asserções; módulo/PG 43/1124; React 44; menu seis grupos/111 acessos. Visual/domínio pendentes. Matriz `reutilizacao-dados.md`: requisito global ainda não concluído; próximos catálogo genérico de artigos, modelos documentais e reconciliação assistida de históricos. Não depende de IA; nenhuma chamada paga repetida.

**Garantia comercial sem IA, 30/10/2026:** proprietário confirmou que as funcionalidades prometidas têm de permanecer disponíveis. Requisito permanente em `AGENTS.md`: SGC base independente do adicional de IA; sem chave/crédito/subscrição/fornecedor não bloqueiam os percursos normais ou relatórios. Indicadores/alertas/sínteses locais fazem parte do núcleo. Preservar documentos, decisões e resultados incorporados após cancelar IA; não mover funções aprovadas do núcleo para o adicional. Aplicar nas futuras integrações, reservas, limites e cobrança, mantendo permissões e auditoria. Conferidos controlos/testes existentes e reutilizada prova `ai-plan.json`; alteração documental, sem novas chamadas/dados/código. Pendências funcionais continuam pendentes, sem alegar conclusão integral.

**Plano IA por empresa, 30/10/2026:** Administração prepara fornecedor/modelo, percursos, categorias de factos, orçamento e pedidos mensais e limites por pedido; sempre rascunho, versão/motivo/auditoria, preservando escolhas locais. Relatórios pré-visualizam factos já autorizados, filtrados por plano/actor, sem nomes, referências pessoais, notas livres, dados bancários ou hashes; âmbito vazio/excluído e excesso de bytes explícitos. Sem chamadas pagas, migrações ou escolhas gravadas automaticamente na avaliação. Orçamentos são planeados: ainda sem ledger/reservas/credenciais por empresa ou execução, `external_execution_enabled=false`, `usage_checked=false`. Modelo proposto ainda exige validar compatibilidade. Documento `plano-ia.md`, prova `ai-plan.json`. Próximo passo: contrato de consumo/reserva atómica, transporte/credencial por organização, revalidação de fontes/política/acessos e activação explícita. Não repetir o ensaio fictício concluído; visual/publicação pendentes.

**Ensaio IA concluído, 30/10/2026:** proprietário configurou a chave; corrigidas apenas duplicação/atribuição embutida no `.env`, sem divulgar segredo. CA de raízes confiadas do Windows aplicada apenas ao processo PHP, mantendo verificação TLS. Histórico: falha TLS, 401 por chave malformada e uma geração HTTP 200; sem repetição automática. Três factos fictícios preservados, fontes completas e conteúdo conferido; 204 tokens entrada/81 saída, custo textual teórico US$0,001380, débito de créditos Pro não consultado. `proofs/ai-rehearsal-live.json` e `ensaio-ia.md` substituem o estado histórico de espera por credencial. Autorização de uma geração consumida; não repetir por arrasto. Serviço externo continua desactivado nos fluxos reais. Sem dados reais ou alterações de negócio. Próximo passo: configuração de fornecedor/consumo por empresa e avaliação ampliada; visual/domínio pendentes.

**Sínteses configuráveis e avaliação sem API, 30/10/2026:** Administração > Parametrização permite escolher sínteses locais de Compras/Pessoas separadamente por empresa, com revisão, versão, motivo e auditoria. Ocultar resumo não retira relatório ou permissões. Sem segredos/activação externa nesta interface. Migração 000033 apenas em 8005, backup/restauro e 93 tabelas conferidos, novo campo de política nulo em todas as empresas, sem alterar contas/grants. Prova `intelligence-policy-install.json`. `sgc:ai-assess` e métricas do ensaio futuro medem cobertura/fontes/correspondência literal, sem certificar verdade semântica ou usar rede. Fixture manual sintética avaliada, não saída de IA. PHP 82/1337, React 33, PostgreSQL um cenário/110 asserções, tipos/PHPStan/lint/build nas provas `intelligence-policy.json`. Provas integrais reutilizadas. Chamada paga continua autorizada e não executada; aguardar credencial sem pedir nova autorização. Configuração de fornecedor/documentos reais/consumo por empresa ainda pendente, assim como visual e domínio.

**Ensaio IA autorizado — credencial em falta, 30/10/2026:** o proprietário respondeu «pode sim» após a estimativa de US$0,01–0,02 para a chamada preparada. Autorização válida para uma única chamada paga à OpenAI, modelo `gpt-5.6-terra`, três factos fictícios e saída até 1 000 tokens. Verificação local revelou ensaio desactivado e ausência de credencial específica e `OPENAI_API_KEY` disponível; nenhum pedido enviado. Falta configurar `SGC_AI_REHEARSAL_API_KEY` no servidor, sem a transmitir nesta conversa. Não pedir nova autorização para a mesma chamada. Preferir activação apenas no processo do comando, mantendo o serviço externo desactivado no portal. Prova `proofs/ai-rehearsal-authorization.json`; o estado «autorização pendente» nos registos anteriores é histórico e foi superado por esta decisão.

**Ensaio IA preparado, 30/10/2026:** `sgc:ai-rehearsal` pré-visualiza três factos fictícios sem rede/base. Adaptador OpenAI Responses testado por HTTP simulado: 15/41, PHPStan aprovado. Uma chamada manual `--live`, modelo inicial `gpt-5.6-terra`, entrada até 4 500 bytes, saída até 1 000 tokens, schema/fontes validados, sem ferramentas, repetição ou redireccionamento. Sem dados reais, IDs de processo, anexos ou texto livre; não ligado a rotas/filas/relatórios. Chamada real ainda não executada; falta autorização para serviço externo pago e credencial no servidor, sem a enviar na conversa. Rever `ensaio-ia.md` e `proofs/ai-rehearsal.json`. Validade de citação não é garantia de verdade; revisão humana obrigatória no ensaio. Parametrização de IA por empresa e activação sobre documentos reais ainda não implementadas. Conferência visual tentada: pipe nativo Windows indisponível (`os error 2`) e browser host indisponível; sem superfícies, sem contorno e sem demonstrar falha do portal. Não confundir com pendência de publicação.

**Síntese com fontes, 30/10/2026:** relatórios individuais de Compras e Pessoas ganharam sínteses factuais próprias, com secções de origem, caminhos dos dados e SHA-256 da base. Projecções já autorizadas/redigidas, sem queries adicionais/cache/transmissão/escrita. Finanças reservadas fora do texto e hash. Compras distingue estado/qualificação actual ou antiga/acta/ordem/recepções/pagamentos, sem recomendação de vencedor nem aprovação. Pessoas distingue matriz actual/base de selecção preservada, proposta pendente/devolvida/aprovada, minuta interna e esclarecimentos posteriores; não classifica pessoas ou presume assinatura/admissão. Detalhe de Pessoas agora usa leitura transaccional e snapshot read-only/repeatable-read em PostgreSQL normal. Método por regras identificado; não alegar IA generativa, ML ou leitura de anexos activos. Referência não equivale a assinatura ou decisão persistida. Provas `proofs/evidence-brief.json`: PHP Compras 18/317 e Pessoas 35/972, PostgreSQL um cenário/64 asserções, React 31, tipos/PHPStan/lint/build. Visual e domínio pendentes; provas integrais reutilizadas. Próxima evolução de inteligência: configuração por organização e ensaio de fornecedor com corpus sintético/avaliação, preservando fontes e permissões antes de qualquer activação externa. Orientação do proprietário: prosseguir nas etapas autorizadas sem confirmação corrente; pedir autorização apenas quando concretamente necessária.

**Retoma — inteligência de Compras, 30/10/2026:** leitura operacional em `/relatorios`, sobre todo o filtro autorizado e mesmo snapshot: aprovação pendente, cinco submissões mais antigas com origem, antiguidade desconhecida, data de necessidade ultrapassada antes de aprovação e aprovadas sem propostas/ordem visível. Data de necessidade não é prazo de entrega; contagem de propostas não mede comparabilidade; ausência não prova incumprimento. CSV preservado, sem migrações, permissões novas ou escritas de negócio. Catálogo `indicadores-sgc.md` define os dois domínios; roteiro actualizado em `inteligencia-sgc.md`. Provas dirigidas `proofs/procurement-intelligence.json`; reutilizar provas integrais anteriores. Próximo passo de inteligência: ensaio de síntese documental com referências e dados de teste. IA/ML ainda sem fornecedor/modelo activo. Visual e publicação pendentes; lacunas funcionais anteriores de Pessoas e hotfix `/consulta` continuam registados.

**Inteligência no SGC, 30/10/2026:** requisito do proprietário para usar machine learning e IA. Roteiro `inteligencia-sgc.md`: indicadores explicáveis → assistência documental com fontes → previsão de prazos/anomalias sobre histórico validado, configuração por empresa e avaliação antes de activação. Primeiro incremento local: «Leitura operacional» em Pessoas, derivada apenas do painel autorizado/filtrado e mesmo snapshot: atrasos, processos afectados, cinco ocorrências mais antigas com origem, distribuição de tarefas, aprovações e ausência de prazos sem presumir incumprimento. Sem ML treinado, fornecedor externo, decisões sobre candidatos ou mudanças de schema/dados/acessos. Provas em `proofs/people-intelligence.json`. Próximo passo: indicadores de Compras e catálogo comum de definições; depois ensaio de sínteses com fontes, preservando os roteiros separados. As pendências funcionais anteriores de Pessoas mantêm-se. Visual e domínio pendentes.

**Esclarecimentos de Pessoas, 30/10/2026:** acompanhamento separado da avaliação original: responsável/prazo, resposta com tipo de evidência e referência obrigatória se verificada, conferência independente, devolução, conclusão fundamentada e dispensa justificada. Versão, idempotência, auditoria e histórico imutável após conclusão; acesso limitado à questão atribuída quando não há permissão geral de entrevistas. Atrasos e reatribuição suportados. Integração em tarefas operacionais, alertas e relatório, sem confundir com aprovação formal, sem mensagens externas nem efeitos automáticos nas notas/elegibilidade. Alterar só prazo não invalida selecção; mudanças substantivas são reconciliadas antes de aprovar selecção pendente. Decisões já aprovadas e avaliações originais preservadas, mesmo com acompanhamento depois da minuta. Migração 000032 apenas em 8005, backup/restauro e 92 tabelas anteriores conferidos, nova tabela vazia, sem contas/atribuições novas. PHP 652 totais/650 aprovados/dois ignorados anteriores, 6 142 asserções; módulo PostgreSQL 30/836; React 25; tipos/PHPStan/lint/Pint/build aprovados. Provas `people-clarifications.json`, `people-clarifications-pg.json` e `people-clarifications-install.json`. Visual e publicação pendentes, incluindo hotfix `/consulta`. Próximas lacunas: métodos qualitativos, correcções versionadas, formalização, acompanhamento de execução e encerramento. Não declarar a proposta Word integralmente implementada.

**Painel de Pessoas e filas pessoais, 30/10/2026:** entidade, contagens autorizadas, filtros por título/referência, percurso, estado e criação; As minhas tarefas separada de Aprovações, alertas de recepção vencida e Actualizar. Filas derivam de processos/atribuições originais, sem tabelas/cópias e sem autoridade adicional. Operações concluídas saem na consulta seguinte; independência, prazo e revogação reaplicados. Contagens sobre todo o filtro, não só 15 registos. Listagem agora projecta apenas campos mínimos, sem regras, finanças, entrevistas, selecção ou contrato; corrigida a exposição do modelo integral na listagem anterior. PostgreSQL normal usa snapshot read-only/repeatable-read. Minuta não equivale a encerramento. Sem migrações/grants. Suíte 643 totais/641 aprovados/dois ignorados anteriores, 5 859 asserções; módulo e PostgreSQL 21/562; React 23; tipos/PHPStan/lint/Pint/build aprovados. Provas `people-workdesk.json` e `people-workdesk-pg.json`. Visual e publicação continuam pendentes.

**Provas do incremento actual:** 638 testes totais/636 aprovados/dois ignorados anteriores, 5 556 asserções; módulo final e PostgreSQL 16/286; React/Inertia 22. Tipos, PHPStan, lint, Pint, build, runtime e HTTP aprovados; menu separado com seis grupos/110 acessos por perfil. Prova consolidada `proofs/people-access.json`. Mantêm-se pendentes visual e publicação.

**Orientação actual e implementação, 30/10/2026:** separar Compras de **Pessoas e contratações**, mantendo apresentação e mecanismos comuns, mas roteiros/dados distintos. Pessoas tem processos/equipas, serviços individuais e recrutamento; não há ligação de serviços individuais dentro de Compras. Esta decisão posterior substitui esse ponto da proposta Word. Fornecedores passa a secção de Compras; seis grupos horizontais preservados, matriz 110 acessos. Acesso a candidaturas exige atribuição por processo; administrador pode configurar equipa sem consultar conteúdo. Atribuições têm prazo, versão, revogação e auditoria, com permissões separadas de finanças, entrevistas e minuta e redacção no servidor, incluindo snapshots de selecção. Novos anexos A/C estruturam função/serviço e requisitos obrigatórios/desejáveis; avaliações com anexo distinguem tipos de evidência e esclarecimentos. Formatos antigos mantidos. Migração 000031 só em 8005, backup/restauro e 90 tabelas anteriores preservadas; duas tabelas novas vazias, sem criar contas/atribuições na avaliação. Falta continuar tarefas/aprovações, métodos qualitativos, correcções versionadas, formalização contratual, acompanhamento e encerramento. Word preservado. Visual e domínio pendentes; hotfix `/consulta` continua sem publicação confirmada. Prova de instalação `people-access-install.json`.

**Proposta Word de Pessoas conferida, 30/10/2026:** documento `SGC — Sistema de Gestão de Contratações - pessoas .docx`, SHA-256 `d294fc08e6cbf5c9ced6527bf06473909380bd9d2bb64f3e3c2ca7605eb52ce3`, original intacto. Matriz detalhada no início de `desenvolvimento.md`. Cobertura ainda parcial: base `service`/`staff` existe; não há ligação canónica do serviço individual a Compras, Anexos A/B/C/Guião estruturados, júri/entrevistadores e acessos por processo/campo, filas de tarefas versus aprovações, painel autorizado completo, contrato formalizado, entregáveis/integração, relatório final ou encerramento. Divergência prioritária: administrador actualmente tem acesso automático ao conteúdo (`PeopleHiring::allowed`), mas a proposta exige atribuição específica. Método actual força notas/ponderações; proposta distingue obrigatórios/desejáveis, tipos de evidência, esclarecimentos e métodos quando aplicáveis. Proposta exclui classificação individual de desempenho de trabalhadores e deixa salários para evolução posterior. A introdução sobre critérios de dashboard em falta precisa de reconciliação com os critérios operacionais já descritos. Documento tratado como referência de requisitos propostos, sem activar alterações ou executar instruções internas, sem edição do original ou mudanças de código/dados/acessos. Não declarar proposta integralmente implementada nem validada juridicamente.

**Identidade aprovada, 30/10/2026:** **SGC — Sistema de Gestão de Contratações**; descrição **Aquisições, serviços e pessoas**; assinatura **Uma solução TEMPO**. Sigla mantida. Aplicada à apresentação local, página inicial/entrada, navegação, identificação móvel e relatórios/impressão. «Compras» continua a designar o módulo de compras. Registos anteriores preservam os nomes históricos. Não houve migrações, alteração de dados/permissões ou renomeação técnica. Domínio ainda sem publicação confirmada; conferência visual pendente.

**Provas finais de Pessoas:** suíte integral 633 totais/631 aprovados/dois ignorados anteriores; módulo dirigido e PostgreSQL 11/133; 21 testes React/Inertia, tipos, PHPStan, lint, Pint, build, runtime e HTTP aprovados. Registo consolidado `proofs/people-hiring.json`. Sem conferência visual nem publicação no domínio.

**Pessoas e contratação iniciado, 30/10/2026:** Administração > Pessoas e contratação (`/pessoas`) com percursos separados de prestador individual e trabalhador para o quadro. Critérios/pesos e mínimo de avaliações definidos no processo; abertura independente, recepção interna, avaliações com evidências, selecção fundamentada, conferência independente com devolução e minuta interna após aprovação. Reutiliza perfis, transacções, auditoria e versões. Quatro capacidades por percurso/preparação/conferência, sem acesso automático por perfis de compras/finanças. Sem criar pessoas/contas/atribuições reais ou sintéticas na avaliação. Migração 000030 só em 8005, três tabelas vazias, backup/restauro e 87 tabelas anteriores preservadas (`people-hiring-install.json`). Menu mantém seis grupos, matriz 108 acessos. PostgreSQL isolado: 11 testes/133 asserções. Minuta não é contrato assinado nem admissão efectiva; portal candidato, anexos, júri nominal por processo, correcções versionadas/reabertura, retenção, assinatura e integrações continuam pendentes. Conferência visual e domínio ainda pendentes. Hotfix React `/consulta` continua sem publicação confirmada.

**Erro React 31 em produção (/consulta):** causa reproduzida e corrigida localmente no layout de `preview/*`: componente `PreviewLayout` extrai `children`, em vez de apresentar o objecto de propriedades. 18 testes React/Inertia (incluindo 16 ecrãs), tipos, lint e build aprovados. Patch restrito em `storage/logs/preview-layout-hotfix.patch`, sem migrações/dados. Ainda falta instalação na revisão do servidor e conferência de `https://compras.tempo.co.mz/consulta`; não publicar a compilação local completa sobre código anterior, pois contém outros incrementos. Não há confirmação de publicação.

**Regras de comparação parametrizáveis, 30/10/2026:** Administração define mínimos de propostas/avaliadores independentes e cinco ponderações com soma 100%, com motivo/versão/auditoria. Novas requisições guardam a regra na criação; rascunhos existentes não são reconfigurados ao editar. Processos antigos sem snapshot continuam em compatibilidade 3/2; mudar a empresa não altera as suas comparações. Regras visíveis até à consulta/impressão da ordem e abrangidas pelo hash de novos processos. Preço continua subtotal líquido sem IVA; perfis elegíveis dos avaliadores e critérios não se tornaram um editor genérico. Migração 000029 só na avaliação 8005 com backup/restauro, campos anteriores das 87 tabelas e hash da comparação existente preservados. Empresa de avaliação continua sem política nova definida automaticamente. Suíte 622 totais/620 aprovados/dois ignorados anteriores, 5 306 asserções; PostgreSQL 45/367; PHPStan/tipos/lint/Pint/build aprovados. Provas `comparison-policy.json`, `comparison-policy-install.json`, `comparison-policy-pg.json`. Sem instalação no domínio; conferência visual permanece pendente.

**Provas finais deste incremento:** 618 testes totais, 616 aprovados/dois ignorados anteriores, 5 245 asserções; PostgreSQL descartável 42/327; adjudicação/ordem 71 aprovados. PHPStan, TypeScript, lint dirigido, Pint, build e runtime SHA-256 aprovados. Prova consolidada `proofs/economic-comparison.json`; conferência visual permanece pendente.

**Comparação económica e menu, 30/10/2026:** avaliação 8005 com IVA inicial configurável na Administração (16% inicial, ajustável por artigo, sem reescrever taxas antigas), descontos unitários explícitos por percentagem/MZN antes do IVA e evidência até à ordem/relatórios. Preços vazios/zero e descontos inválidos recusados; aviso de empate sem escolher automaticamente; motivos de inelegibilidade e data persistida das avaliações visíveis. Valores do Excel não importados. Migração 000028 aplicada apenas à avaliação após backup/restauro e reconciliação dos campos anteriores das 87 tabelas. Menu horizontal com seis grupos relacionados, secções internas em Compras e visual dos dropdowns preservado; 107 acessos por seis perfis conferidos. Provas `economic-install.json`, `economic-pg.json`, `menu-code-contract.json`, `menu-links.json`. Não instalado no domínio; conferência visual pendente. Relatório final do júri ainda em falta; ponderações e mínimos de propostas/avaliadores mantêm os limites anteriores, não declarar parametrização integral concluída.

**Raiz da avaliação local:** `http://127.0.0.1:8005/` encaminha directamente para `/dashboard`, sem escolha de perfil nem login para sessões anónimas. Usa a entrada local já existente.

**Entrada local sem login, 30/10/2026:** usar `http://127.0.0.1:8005/dashboard`. Sessões anónimas entram com o administrador sintético existente, após conferir ambiente/endereço/porta e identidade da base isolada. Sessões existentes mantêm o perfil; não concede administração a um perfil já seleccionado. Login normal preservado noutras instalações. 17 testes/36 asserções e prova HTTP aprovados; sem criação de contas, migrações ou instalação no domínio. `/avaliar` continua disponível para mudar de perfil.

**Excel de avaliação localizado e conferido, 30/10/2026:** `Avaliacao producao.xlsx`, duas folhas; principal com quatro empresas/dados de exemplo e `detalhes` oculta com 211 `#REF!` e cinco `#VALUE!`. Totais actuais da principal reconciliados por cálculo decimal independente, mas há referências destruídas e mapeamento de linhas errado na oculta, selecção do primeiro fornecedor em empates, risco de falta de dados virar zero/mínimo, IVA fixo de 17%, desconto com base não explicitada, data `TODAY()` e dimensão fixa. Não declarar resultados finais/júri ou modelo integralmente validado. Análise detalhada no início de `desenvolvimento.md`. Original intacto; sem recálculo no Excel, reparação ou importação de taxas/regras. Ainda falta o relatório final do júri para cruzamento. Não confundir esta grelha económica genérica com o anexo Word anterior de qualificação de um concurso específico.

**Documento Recepção de propostas conferido, 30/10/2026:** referência do proprietário lida e comparada no contexto privado; matriz no início de `desenvolvimento.md`. Documento coerente ao separar entrega/comprovativo de abertura/admissibilidade/avaliação/adjudicação. Aplicação já tem cotações, acta versionada/fuso/participantes, admissão, comparação/recomendação/aprovação; faltam protocolo por entrega, comprovativo, originais recebidos em guarda confidencial até abertura, nomeação/poderes efectivos de equipa, ocorrências/substituições/retiradas e ciclo de arquivo/comunicação. Campos de participantes na acta não equivalem a nomeação; fingerprint dos dados não equivale a envelope selado. Cotações são consultáveis antes da acta, portanto não declarar recepção electrónica selada implementada. Júri/equipa deve ser configurável pela empresa, sem imposição automática a todas as compras. Documento tratado como proposta de referência, sem execução das suas instruções, alteração de regras/dados ou envio de mensagens.

**Conferência da proposta privada, 30/10/2026:** comparado o ficheiro do proprietário `fluxo sector público e empresas privadas.docx`, somente secção 4/controlos/matriz de risco das privadas. Matriz detalhada no início de `desenvolvimento.md`. Resultado: percurso-base existente, cobertura integral ainda parcial. Lacunas centrais: estratégia e excepções parametrizáveis; três propostas/dois avaliadores ainda fixos; orçamento sem dotação pode retornar `null`; matriz geral baixo/moderado/elevado/crítico e risco residual não implementada; contratos/marcos/alterações/encerramento incompletos; percurso comum de pagamentos ainda em ensaio; ofertas/hospitalidade e denúncia confidencial sem módulo. Não confundir criticidade de equipamento com risco geral nem contraditório do fornecedor com denúncia. A proposta foi tratada como referência de comparação, sem aplicar regras públicas ou activar políticas/alterar dados. Não declarar a proposta integralmente disponível nem pronta no domínio com base em ecrãs ou totais de testes.

**Resultados da parametrização, 30/10/2026:** suíte integral 603 testes, 601 aprovados, dois ignorados anteriores, 5 157 asserções; parametrização PostgreSQL descartável 13 testes/96 asserções, com base removida; PHPStan/tipos/lint dirigido/Pint/build/runtime/HTTP aprovados. Menu 107 entradas e catálogo 23 páginas. Provas em `proofs/organization-configuration.json` e documentos associados. As tabelas de configuração da avaliação continuam sem activação/perfis/atribuições; nenhum administrador real ou conta TEMPO foi inventado/criado nessa base. Os dois administradores são definidos no formulário de configuração/entrega. Antes da activação, contas com marcador `configured` não herdam permissões de desenvolvimento; depois dela usam apenas os perfis atribuídos. Marcadores históricos e contas existentes conservam-se sem constituir autoridade de acesso no modo configurado.

**Administração parametrizável e entrega com dois administradores, 30/10/2026:** `/administracao/parametrizacao` no menu, perfis com nomes próprios e permissões funcionais combináveis, criação de utilizadores, atribuição/revogação justificada, versão/auditoria e mínimo de dois administradores permanentes. Novas empresas exigem as duas pessoas e limites de aprovação expressamente definidos; seeder sem contas de exemplo. Marcador interno `configured` não concede direitos; depois da activação os perfis antigos deixam de autorizar. Resolução comum aplicada aos serviços/políticas/controladores, menus e botões; preservar regras e referências históricas. Empresas existentes mantêm preparação até activação explícita, com efeito explicado sobre pessoas não associadas. O proprietário pediu manutenção TEMPO («backdoor»); concretizada como acesso nominativo autenticado, temporário, revogável e auditado de diagnóstico/consulta, sem conta global/entrada oculta ou comandos de negócio. Migração 000027 apenas em 8005, backup/restauro verificado e 84 tabelas preservadas; três tabelas novas vazias. Configuração da avaliação não activada e contas/permissões existentes não alteradas. Ver resultados em `proofs/organization-configuration.json` e provas associadas. Não declarar parametrização integral: catálogo ainda agregado por funções, editor universal de fluxos/permissões por operação e associações financeiras específicas continuam por desenvolver. Visual e publicação pendentes. Esta orientação passa à frente do consolidado do contraditório indicado nos estados anteriores.

**Instrução permanente de parametrização integral — proprietário, 30/10/2026:** toda a aplicação deve permitir aos utilizadores autorizados definir quem é quem, quando cada função/regra deve ser usada e como associar pessoas, funções, unidades, processos e documentos. Abrange perfis/permissões e nomes configuráveis, responsabilidades, múltiplas funções, delegações/substituições, etapas, condições, limites, prazos, vigência, aprovações, menus e relatórios. Configuração pela interface, sem adaptação de código por organização; servidor e interface devem usar a mesma fonte de capacidades/regras. Versão, vigência, auditoria e efeito explícito em processos novos/em curso, preservando decisões concluídas, isolamento e integridade. Orientação consolidada em `AGENTS.md`. **Ainda não implementada integralmente:** existem seis perfis em enum e listas fixas de autorização, inclusive nos módulos recentes; estes são configuração inicial a migrar, não limite definitivo do produto. A prioridade transversal passa a ser a base comum de funções/capacidades e associações configuráveis, com migração compatível das regras actuais, antes de multiplicar novas listas fixas. Entregas e provas anteriores continuam preservadas; o pedido não concede automaticamente novas permissões nas bases existentes.

**Contraditório registado e analisado, 30/10/2026:** revisão aprovada → documentos/argumentos recebidos → rascunho → análise → devolução/correcção ou conclusão independente. Acolhimento total/parcial exige seguimento; conclusão fundamentada imutável, com histórico e anexo datado no relatório, preservando a avaliação. Entrada pela equipa com referências documentais; sem envio externo, portal autenticado do fornecedor ou upload de anexos neste incremento. Reutilizados âmbito, perfis, conflitos, versões e auditoria atómica. 39 testes/505 asserções, PHPStan/tipos/lint/Pint/build, HTTP e triggers PostgreSQL aprovados; provas `proofs/supplier-responses*.json`. Migração 000026 só em 8005 após backup/restauro fresco verificado, 83 tabelas anteriores preservadas; exemplo QA CTR-1 concluído na AVF-1. Sem instalação habitual/publicação, efeitos fiscais/financeiros ou mudança automática da elegibilidade. Visual/impressão permanecem pendentes pela limitação do controlo de URL já registada. Substitui a pendência do registo do contraditório abaixo. Próxima evolução: consolidado por fornecedor/estado/recepção/conclusão e relatório; anexos e comunicação permanecem incrementos próprios.

**Consolidado de medidas entregue, 30/10/2026:** Relatórios → Medidas de melhoria, `/relatorios/medidas-fornecedores`, com filtros por fornecedor/responsável/estado/título/prazo/atraso, resumo de todos os resultados, paginação e ligações à medida na avaliação/relatório. CSV completo dos filtros em lotes de 200, texto seguro para folhas de cálculo; inclui revisões anteriores, sem esconder pendentes ao rectificar avaliações. Leituras PostgreSQL em snapshot read-only, com âmbito de empresa/departamento e perfil recarregado. Sem migrações, contas/concessões, alterações de negócio ou publicação. Disponível em 8005. 36 testes/542 asserções, PHPStan/tipos/lint/Pint/build e HTTP de seis perfis aprovados; menu 106 entradas e catálogo 22 páginas conferidos. Ver `proofs/supplier-improvement-report*.json`. Visual/impressão manual continuam pendentes pela limitação do controlo de URL Windows já registada. Substitui a pendência de consolidado abaixo. Próximo âmbito: contraditório documentado do fornecedor e resposta fundamentada, sem substituir a avaliação aprovada; política quantitativa por implementar.

**Medidas de melhoria entregues, 30/10/2026:** a avaliação aprovada permite registar medidas com responsável/prazo, execução/evidência, pedido de encerramento, devolução/correcção e encerramento independente. Transferências/reagendamentos justificados e histórico; autor/editores/responsáveis não encerram a própria medida. Encerramentos imutáveis também em SQL. Relatório inclui acompanhamento datado sem modificar a avaliação aprovada; sem efeitos automáticos na elegibilidade/finanças. Migração 000025 instalada apenas em 8005 após backup/restauro verificado e preservação de 82 tabelas. Exemplo QA MM-1 encerrado na AVF-1. 72 testes/768 asserções, PHPStan, tipos, lint/Pint/build, HTTP com três perfis e protecções PostgreSQL aprovados. Provas `proofs/supplier-improvements-*.json`. Visual/impressão pendentes: a ferramenta terminou o controlo por não conseguir confirmar o URL Windows para aplicação da política; sem contorno dessa limitação. Sem publicação no domínio ou migração habitual. Substitui a pendência de medidas abaixo. Próximo incremento: consulta consolidada por fornecedor/responsável/prazo/estado e relatório; contraditório e política quantitativa continuam por implementar.

**Avaliação de fornecedores implementada, 30/10/2026:** `/fornecedores/avaliacoes` guarda rascunhos, critérios/evidências e conclusão; submissão, devolução/correcção, aprovação independente de todos os editores, versões, histórico e relatório imprimível. Aprovação imutável; rectificação por revisão ligada. Conflitos e âmbito por empresa/departamento mantidos. Sem pontuação, pesos ou alteração automática de elegibilidade. 61 testes/655 asserções, PHPStan, tipos, lint dirigido e build aprovados; HTTP e triggers PostgreSQL conferidos. Migração 000024 aplicada apenas na avaliação 8005, com backup/restauro verificado e 81 tabelas anteriores preservadas. AVF-1 é exemplo fictício aprovado; AVF-2 é rascunho de rectificação. Ver `desenvolvimento.md` e `proofs/supplier-evaluations-*.json`. Sem publicação no domínio ou migração habitual; visual/impressão manual pendentes. Substitui a lacuna de persistência indicada abaixo. Próximo incremento: medidas de melhoria, responsáveis/prazos/evidências e encerramento independente; não activar pontuações provisórias.

**Acesso directo na avaliação corrigido, 30/10/2026:** links protegidos em 8005, incluindo `/relatorios`, conduzem a `/avaliar` quando não existe sessão; `/login` desse host também usa a entrada sem palavra-passe. Após escolher o proprietário/perfil, regressa ao caminho e filtros guardados. Destinos externos e ciclos de login não são aceites. Mantidas as guardas de host/base/role QA e CSRF; a autenticação da instalação habitual não foi alterada. 23 testes/172 asserções, PHPStan/Pint e prova HTTP das 21 páginas/seis perfis aprovados. Disponibilizar este percurso ao utilizador, sem lhe pedir credenciais da instalação habitual.

**Menu → operação → relatórios, 30/10/2026:** pedido do proprietário para compatibilizar as funções do menu com o código e optimizar os fluxos até à geração dos relatórios. Inventário actualizado em `menus-benchmark-20261029.md`, com 102 entradas/6 perfis conferidas por contrato de rotas/destaque. Entregue central «Relatórios de compras» em `/relatorios`, filtros por criação/estado/departamento/número, resumo paginado e CSV completo dos filtros, com ligações ao processo e relatório individual. Relatório individual ampliado com recepções e, no âmbito financeiro autorizado, facturas e pagamentos externos preservados, sem dados bancários nem cálculo de saldo. 14 testes/223 asserções, tipos, lint, Pint, PHPStan e build aprovados; provas em `proofs/procurement-reports.json`. Próxima lacuna concreta: Avaliação de fornecedores ainda é proposta de interface, sem persistência/revisão/histórico operacional; implementar esse ciclo até ao respectivo relatório. Não declarar todos os módulos concluídos apenas por as ligações do menu abrirem. Alterações locais, sem instalação no domínio; visual/impressão manual continuam por executar, sem bloquear os incrementos seguintes.

**Orientação permanente do proprietário — 30/10/2026:** a aplicação é destinada à comercialização; remover/corrigir os bloqueios que impedem desenvolvimento normal, testes, ajustes e disponibilização. Não exigir de novo autorização por etapas já abrangidas pelo pedido, nem usar pendência genérica de visual/aceitação como bloqueio do código e dos testes. Distinguir limitação técnica de regra funcional aprovada, identificar a sua origem e executar a solução concreta. Preservar dados, contas e os controlos funcionais de integridade/isolamento/aprovação/auditoria. Esta orientação prevalece sobre adiamentos genéricos dos registos históricos; não transforma capacidades ainda sintéticas em operação comercial por mera remoção de guardas. Regras locais consolidadas em `AGENTS.md`.

**Paridade de versão local/domínio — decisão da Tempo, 30/10/2026:** a versão acompanhada pelo utilizador durante o desenvolvimento é a referência para `www.compras.tempo.co.mz`: mesmos menus horizontais/dropdowns, visual e implementação dos processos. Não apresentar uma interface antiga como entrega equivalente. Conferir revisão, assets, flags e dependências de cada percurso antes de declarar paridade; dados, identidades e permissões existentes de cada ambiente devem ser preservados. O acesso sem palavra-passe e os perfis sintéticos da avaliação local não foram autorizados no domínio por este pedido. Pagamentos e outros recortes limitados à avaliação exigem reconciliação explícita do âmbito, não mera cópia de flags ou de dados QA. As alterações locais desta sessão ainda não foram enviadas/instaladas e não há confirmação de paridade no servidor. Na leitura de 30/10, o nome com `www` não resolveu por DNS; o endereço sem `www` respondeu a curl, mas isso não confirma a revisão ou os percursos autenticados. O processo/acesso de instalação de Compras não está identificado nos ficheiros de entrega consultados; não reutilizar por inferência o instalador do InvesteMoz.

**Entrada de desenvolvimento definida pela Tempo, 30/10/2026:** o utilizador quer acompanhar a avaliação persistente com menus organizados e processos avançados em **http://127.0.0.1:8005/avaliar**, com «Entrar como proprietário» e os perfis existentes. `composer run dev` usa agora essa avaliação e o Vite; não inicia a instalação habitual em 8015 nem a respectiva fila. Não voltar a apresentar 8015 como entrada normal de desenvolvimento. O arranque reutiliza os dados/configuração QA já existentes, sem provisionamento, migrações, seeds, alteração de contas ou reinício do SGF. A instalação habitual mantém-se separada e só arranca explicitamente com `composer run dev:standard`. Implementação em `scripts/dev-evaluation.php`; verificações e limites no registo de 30/10 em `desenvolvimento.md`.

**Pagamentos e afectações sintéticos, 29/10/2026:** percurso comum disponível apenas nas demonstrações isoladas 8005/8006, com preparação, confirmação independente e afectação explícita. Prova nas duas composições e preservação por hashes aprovadas; revisão visual/manual pendente. Sem migração habitual, utilização real ou novos pagamentos sobre importações históricas. Ver [relatório do núcleo comum](../../sgf-tempo/docs/SUPPLIER_SETTLEMENT_DELIVERY.md).

**Conferência posterior dos pendentes implementada, 29/10/2026:** confirmação/rejeição ligada ao núcleo comum com decisão imutável, saldo único e escrita original atómica. Provas SQLite e PostgreSQL descartável, incluindo dois pedidos simultâneos e reversão de falha, aprovadas. Ver [entrega](conferencia-pendentes-importados.md). Migração 000023 e opção de conferência preparadas, ainda não aplicadas/activadas em `compras_dev` ou 8005; importação local anterior preservada. Substitui a pendência de desenvolver esta conferência, sem novos pagamentos/transferências.

**Aplicação/activação histórica local concluída, 29/10/2026:** após «continue», 000022 aplicada em `compras_dev`, lote 23, e flag histórica activada, após backup/restauro das 72 tabelas. Registos/restrições preservados, duas tabelas novas vazias e dois triggers verificados. Activação auditada sem novas contas/concessões ou alteração de identidade; zero facturas/pagamentos/obrigações e nenhuma incorporação automática. Ver `historico-migracao-000022.json`, `historico-activacao-local.json` e [relatório](passagem-historico-pagamentos.md). Demo 8005 permanece sem esta migração/activação, confirmada em leitura; restantes demos e público preservados. Substitui apenas as indicações históricas de aplicação/activação pendentes abaixo. Novos pagamentos e decisão de pendentes depois da passagem continuam incremento próprio.

**Verificação final do histórico:** regressão geral com 517 aprovados, 2 ignorados e 4 337 asserções; últimos reforços de identidade cobertos por 11 testes específicos/64 asserções. PHPStan/Pint aprovados. PostgreSQL histórico (concorrência, falha/retoma, imutabilidade) e regressão anterior nas duas composições aprovados; bases descartáveis removidas. 000022/flag histórica permanecem por aplicar/activar na base local. Conta, três concessões anteriores e dados locais preservados. Ver [entrega do histórico](passagem-historico-pagamentos.md).

**Passagem de pagamentos históricos implementada em testes, 29/10/2026:** [âmbito, arquitectura e provas](passagem-historico-pagamentos.md), `PAYABLE-HISTORY-IMPORT-v1`. Principal bruto preservado, confirmados deduzidos uma vez, pendentes/rejeitados conservados sem abatimento; fotografia preparada e validada por pessoa distinta, conflito em alterações e responsabilidade única do saldo. Fonte comum; migração 000022 preparada, flag histórica desligada por omissão, sem aplicação às bases habituais/demos ou novas concessões. Prova PostgreSQL com concorrência, falha/retoma, imutabilidade e originais preservados aprovada (`proofs/payable-history-pg.json`). Novos pagamentos/confirmação de pendentes após passagem, reconciliação e contabilidade continuam separados.

**Ligações conferidas após o novo menu:** 94 entradas em seis perfis e 12 ligações internas do processo, filtro pessoal/estado, factura → obrigação/regresso e histórico conservado. Prova em `proofs/menu-links.json`, repetível por `scripts/menu-links-check.mjs`. Corrigido o destaque do relatório (cotações) e adjudicação (ordens); ambas as páginas já abriam correctamente. Build actualizado aprovado. Inspecção visual nova indisponível por falha da ligação de controlo do navegador; não declarar nova revisão visual. Sem alterações de negócio, migração ou concessões. Retomar depois a transição dos pagamentos históricos.

**Menus renovados a partir do benchmark, 29/10/2026:** [entrega e continuação](menus-benchmark-20261029.md). Layout autenticado real `SgcShell` com menu lateral, pesquisa, secções por tarefa e adaptação móvel; consultas públicas preservadas. Novos conjuntos de requisições pessoais, aprovações elegíveis e decisões efectivas, sem alargar direitos. 44 testes/539 asserções, build, TypeScript, lint, PHPStan e verificação visual desktop/móvel aprovados. Sem novas migrações, concessões ou operações de negócio. Próximo trabalho: retomar transição do histórico de pagamentos factura → obrigação. Formulário completo do benchmark, contratos, catálogo, moedas e relatórios continuam incrementos próprios; não os declarar entregues por aparecerem no benchmark.

**Activação local posterior, 29/10/2026:** `compras_dev` activada com identidade persistente e três direitos auditados para a conta administrativa existente #1/empresa #1, após novo backup/restauro das 72 tabelas. Sem nova conta, mudança de palavra-passe/perfil, facturas/pagamentos/obrigações ou importação automática. Ver `obrigacoes-activacao-local.json` e [relatório](integracao-factura-obrigacao.md). Menu Finanças com ligação condicional pelo servidor; build/TypeScript/PHPStan e 39 testes dirigidos/152 asserções aprovados. Arranque extra de 8015 recusado pela revisão automática; demonstração 8005 preservada e disponível. Substitui a indicação histórica de activação desligada abaixo. Pagamentos históricos e utilização real continuam fora desta activação.

**Aplicação expressamente autorizada e concluída, 29/10/2026:** pedido «aplique» executado apenas para 000021 em `compras_dev`, lote 22. Backup privado/restauro comparado antes da aplicação; preservadas as 65 tabelas anteriores, registos, restrições e `.env`. Sete tabelas novas vazias e seis triggers append-only verificados. Ver `obrigacoes-migracao-000021.json` e [relatório](integracao-factura-obrigacao.md). A activação permanece desligada; nenhuma conta/concessão, incorporação de facturas ou obrigação automática. Demos e servidor público preservados. Este registo substitui apenas a indicação histórica de 000021 por aplicar, abaixo.

**Verificação final deste incremento:** regressão completa com 503 aprovados, 2 ignorados e 4 167 asserções; prova PostgreSQL nos dois hosts aprovada e ambientes descartáveis removidos; PHPStan aprovado. Não aplicar 000021 à instalação habitual por inferência, nem importar facturas com liquidações anteriores sem transição própria. A avaliação local continua disponível e preservada.

**Esquema de aplicação preparado, 29/10/2026:** migração 000021 usa `PayablesSchema` único no pacote comum (QA e aplicação), com histórico append-only; opt-in `COMMON_PAYABLES_ENABLED` desligado por omissão e identidade persistente da instalação. Não aplicada às bases habituais ou demos persistentes; sem novas concessões reais. Facturas com pagamentos preservam percurso/saldo anterior e recusam incorporação automática. Reconhecimento único, saldo, permissões, identidade e imutabilidade: 60 testes dirigidos/215 asserções aprovados. Ver [relatório](integracao-factura-obrigacao.md). A interface continua ensaio; transporte do histórico de pagamentos continua pendente.

**Continuação durante avaliação, 29/10/2026:** [ligação por factura e conferência da integração](integracao-factura-obrigacao.md). Cada factura elegível abre a sua origem/propostas/obrigação/histórico no núcleo comum, com regresso às facturas; filtro por empresa e identidade canónica. Sem reconhecimento ou pagamentos por navegação. Build e 56 testes dirigidos/195 asserções aprovados; prova HTTP da factura existente conserva histórico. A integração na instalação habitual e a transição de facturas com pagamentos continuam delimitadas no relatório, sem aplicação real automática.

**Acesso local de avaliação, 29/10/2026:** pedido do proprietário para retomar Compras e disponibilizar acesso semelhante ao SGF. Entrada http://127.0.0.1:8005/avaliar, proprietário administrativo e seis perfis sintéticos sem palavra-passe, ligação persistente acima da aplicação e directório de 20 páginas. Implementação em `routes/evaluation.php`, apenas no host QA local e base/role verificadas; contas reais/porta 8015 preservadas. Resultado HTTP em `proofs/evaluation-access.json`. Não remove segregação dos processos nem declara aceitação visual ou demonstração completa de todos os percursos. SSH e publicação adiados. Incremento funcional mais recente continua a obrigação comum de fornecedor abaixo; não avançar automaticamente para pagamentos/cancelamento de ordens sem delimitar o respectivo âmbito.

**Implementação sintética de obrigações, 29/10/2026:** [entrega nas duas composições](../../sgf-tempo/docs/SUPPLIER_PAYABLE_DELIVERY.md). Reutiliza `InvoiceWorkflow`/origem conferida; principal comum de 11 600 MZN com vencimento/dias nulos. `outstanding()` delega para o principal canónico apenas na origem QA reconhecida e recusa história/versão incompatível; pagamentos desse cenário ficam bloqueados. Fora do ensaio mantém-se o percurso anterior. Sem migração ou concessão real, novos pagamentos, stock/orçamento adicional ou lançamentos. Preservar avaliação orçamental em paralelo; aceitação/visual/checkpoint continuam separados.

**Regras comuns de produto, 29/10/2026:** referência nas [oito regras SGF/Compras](../../sgf-tempo/docs/SUPPLIER_PAYABLE_SCOPE.md#14-orientação-comum-de-produto-da-tempo--29102026). Documento, obrigação, liquidação, confirmação, reconciliação e contabilidade são factos distintos; núcleo único preserva origem, idempotência e histórico. Vencimento desconhecido gera pendência sem inventar data/apagar principal. Afectações parciais, excessos não afectados, correcções e cobrança configurada orientam a evolução, mas o incremento actual é apenas obrigação a fornecedor. Sem implementação ou alargamento a pagamentos/cobranças nesta actualização documental.

**Especificação completada em 29/10/2026, apenas documental:** [matriz e proposta de obrigações](../../sgf-tempo/docs/SUPPLIER_PAYABLE_SCOPE.md), secções 9–13. Inclui estados/funções, vencimento desconhecido, unicidade por origem independentemente da chave de pedido, transição preservando pagamentos confirmados/pendentes e exemplo 1 160,00 MZN para confirmação. Sem implementação, migração, alteração de pagamentos ou avaliação orçamental. A dívida implícita existente não desaparece por falta de vencimento; nenhum segundo saldo será tratado como autoridade.

**Ligação seguinte, 29/10/2026 — delimitação:** [factura conferida → obrigação a pagar](../../sgf-tempo/docs/SUPPLIER_PAYABLE_SCOPE.md). Reutilizar factura/fornecedor/valores/decisão existentes e preservar o saldo implícito de `ExternalPaymentWorkflow::outstanding`, sem segunda base de dívida. Falta vencimento estruturado e referência explícita da revisão de origem; não inventar versão nativa ou interpretar condições textuais como data. Apenas conferência/desenho nesta passagem; sem novo pagamento, stock, lançamento ou alterações às bases reais. Orçamento entregue e avaliação da equipa continuam independentes.

**Aceitação técnica de 29/10/2026:** a Tempo aceitou a extracção `COMMON-BUDGET-SYNTHETIC-v1` e autorizou checkpoint exclusivamente local nos dois repositórios, sem uso real/push/publicação. Ver [aceitação](../../sgf-tempo/docs/COMMON_BUDGET_ACCEPTANCE.md). Revisão visual Compras pendente; SGF apenas adaptador QA sem interface deste percurso; dois testes MFA ignorados continuam pendentes. Esta aceitação substitui apenas a pendência de encerramento técnico abaixo. Próximo passo: percurso sintético integrado SGF, sem bloquear desenvolvimento pela automação do navegador.

**Execução posterior em 29/10/2026:** `COMMON-BUDGET-SYNTHETIC-v1` implementado, com fonte única no pacote SGF, adaptadores locais e duas bases descartáveis. Ver [relatório técnico](../../sgf-tempo/docs/COMMON_BUDGET_DELIVERY.md). Conservar as alterações e os percursos; sem aceitação presumida, checkpoint de encerramento, migração/concessões/dados reais, publicação ou push. Não avançar para obrigações/pagamentos/contabilidade por arrasto.

## Orientação de produto confirmada — 29/10/2026

Decisão expressa da Tempo: um módulo de Compras, um núcleo financeiro comum e duas composições comerciais — ERP SGF com Compras e Compras autónomo com as capacidades comuns necessárias. O cliente de Compras não precisa de adoptar a facturação de vendas SGF nem de um SGF remoto. Esta orientação substitui a proposta de duas aplicações ligadas por conector remoto; as referências históricas à independência do SGF não impedem o núcleo comum. Preservar todos os percursos, dados, contas, decisões, versões, testes e alterações posteriores; não copiar o motor para manter duas implementações.

O desenho de referência está em [Compras e núcleo financeiro comum](../../sgf-tempo/docs/PURCHASING_COMMON_CORE_PLAN.md), no projecto SGF. Inclui mapa de preservação, capacidades existentes/em falta, responsabilidade única pelos efeitos e transição. Primeiro incremento delimitado: `COMMON-BUDGET-SYNTHETIC-v1`, extracção do controlo orçamental existente e prova nos dois hosts sintéticos, sem dependência de Sales. Nesta passagem só documentação; reestruturação segue esse plano. Pessoas reais/concessões empresariais pertencem à implantação, não são dependências para construir/testar. Não executar seeds ou migrações reais por consequência desta orientação.

Para o estado funcional actual, consultar `docs/validacao-tecnica.md`, que já descreve recomendação e migração 000020; o resumo abaixo até 000017 é anterior. A orientação arquitectural não reabre aceitações nem declara novas provas realizadas.

## Orientação actual após abertura e actas — 28 de Outubro de 2026

Referência consolidada: `07e775c`; consultar primeiro
`docs/validacao-tecnica.md` e o estado actual de `docs/desenvolvimento.md`.
Já estão entregues revisão/cancelamento de adjudicações sem ordem emitida,
visão única do processo, planeamento e sessões opcionais de abertura com actas
imutáveis por versão. Não reiniciar estes módulos. Resultados mais recentes
registados: 443 aprovados, 2 ignorados e 3.431 asserções; migrações até 000017
reportadas aplicadas com recuperação verificada. Esta leitura não é uma nova
execução de testes ou confirmação ao vivo das migrações.

O cancelamento entregue exige política publicada da empresa e decisão
independente; não abrange ordens emitidas ou compromissos. A revisão cria um
novo rascunho ligado e não reutiliza decisões ou reservas. Não desbloquear
cancelamento de ordens, estornos ou devoluções sem regras aprovadas. A visão
única, o plano e as actas não constituem autorização financeira ou certificação
de execução, concurso ou assinatura.

Próximo trabalho: concluir as revisões visuais disponíveis e definir com a
empresa o próximo âmbito pendente antes de o implementar. Permanecem pendentes
cancelamento de ordens emitidas, estornos/notas de crédito/devoluções,
agregação/fraccionamento e funcionalidades de concurso ainda não suportadas.
Não presumir políticas universais a partir dos exemplos locais. Preservar
conta, dados, configuração, porta 8015 e alterações locais; sem seeds reais.

**Todas as orientações abaixo são históricas.** Ordens antigas de iniciar
revisão/cancelamento, planeamento ou abertura ficam ultrapassadas pelo estado
acima. Orçamento, facturas e investimento já têm implementação; a validação
operacional integral e a revisão visual pública/autenticada/impressão continuam
pendentes. Não confundir ausência dessa validação com ausência dos módulos.

## Histórico: próxima etapa após regras de investimento

Regras próprias por empresa, duas aprovações administrativas e integração com
equipamento já implementadas; migração 000014 aplicada, lote 15. Não repetir
as etapas históricas abaixo. Sem valores predefinidos ou regras fictícias na
base real. Cada empresa decide os seus parâmetros e dotações de investimento.
Prosseguir com revisão/cancelamento controlado de processos afectados por
mudanças de base, com política explícita, rastreabilidade e novas aprovações.
Não reescrever ordens emitidas ou reutilizar implicitamente aprovações antigas.
Agregação por projecto/fraccionamento e circuitos acima do tecto não estão
suportados. Revisão visual e validação operacional integral continuam pendentes.

## Próxima etapa após reforços

Reforços por empresa/centro/exercício já estão implementados e migrados
(000013, lote 14). Não repetir as orientações históricas abaixo. Prosseguir
com regras de investimento configuráveis por empresa, com decisões e valores
explícitos, versionamento e aprovação independente. Não presumir um valor ou
interpretar limite ausente como autorização. Até existir regra própria aprovada,
preservar o bloqueio de adjudicação/emissão de equipamento. Revisão visual e
validação operacional integral continuam pendentes. Consultar o relatório actual.

## Próxima etapa após pagamentos externos

Registo e conferência independente de pagamentos externos já implementados,
com migração 000012 aplicada. Não repetir as etapas históricas abaixo.
Prosseguir com reforços orçamentais por empresa/centro/exercício, sem reescrever
a dotação inicial, com proposta e aprovação por pessoas distintas e auditoria.
Valores definidos por cada empresa. Não implementar transferências bancárias
ou desbloquear investimento sem regra própria aprovada. Revisão visual e
validação operacional integral continuam pendentes; consultar o relatório actual.

## Próxima etapa após dados bancários

Versões bancárias por empresa/fornecedor, cifragem e duas validações distintas
de Finanças já estão implementadas; migração 000011 aplicada. Não repetir as
orientações históricas abaixo. Prosseguir com registo de pagamentos externos
sobre facturas validadas, revalidando a versão bancária actual, os dois
validadores, elegibilidade, conflitos, empresa e saldo em transacção.
Não executar transferências bancárias. Sem valores financeiros comuns aos
clientes. Revisão visual e validação operacional integral continuam pendentes.
Consultar `docs/desenvolvimento.md` para resultados e limitações actuais.

## Próximo incremento após facturas

Orçamento e facturas já foram implementados e migrados, incluindo conferência
com recepções e consumo. Não repetir as instruções históricas abaixo.
Prosseguir com dados bancários de fornecedores com dupla validação antes de
pagamentos; reforços e regras de investimento ficam em etapas próprias.
Preservar isolamento por empresa e valores configurados por cada cliente.
Não inventar limites de investimento ou tratar os valores fictícios da
demonstração como configuração. Revisão visual pública, autenticada e de
impressão continua pendente por indisponibilidade do navegador. Consultar
`docs/desenvolvimento.md` para resultados e limitações actuais.

## Estado actual após equipamentos e peças

Recepção, stock, saídas, transferências, contagens, ajustes, equipamentos,
peças e validação técnica já estão implementados. As instruções anteriores
abaixo são históricas e não devem originar implementação duplicada.
O relatório actual está em `docs/desenvolvimento.md`. A revisão visual pública,
autenticada e de impressão continua pendente por indisponibilidade do controlo
do navegador. Antes de avançar para orçamento e facturas, definir as regras
empresariais correspondentes. Preservar as contas e os dados existentes.

## Próximo incremento após adjudicação e ordens

O utilizador já recebeu o relatório de adjudicação e ordens (165 testes
reportados como aprovados). Não repetir essa implementação. As secções
anteriores de adjudicação abaixo ficam como histórico.

Continuar com recepção e stock segundo procurement.docx: recepções parciais e
totais, conferência de qualidade, divergências, quantidades pendentes e movimentos
auditados. Aplicar segregação do emitente, permissões e isolamento por empresa;
impedir duplicação e quantidades superiores às autorizadas. Não inventar
políticas comerciais, tolerâncias ou autorizações de excepção.

Validar concorrência PostgreSQL em ambiente de teste separado, sem recriar a
base real. Actualizar a consulta livre com exemplos fictícios dos novos ecrãs.
Preservar conta, dados, configuração e módulos concluídos. Manter explícita a
ausência de validação orçamental e a restrição a documentos de desenvolvimento.
Actualizar o relatório e o mapa de compatibilidade, que ainda apresenta ordens
como ausentes. Se este incremento já estiver iniciado, continuar sem duplicação.

## Entrada livre para revisão visual

A pedido do utilizador, `/` abre agora `/consulta`, com exemplos fictícios sem
login. Consultar `docs/consulta-livre.md`. Preservar esta entrada e a ligação no
login; manter as rotas e os dados reais protegidos. Esta demonstração é uma
ferramenta de revisão visual e não substitui os módulos operacionais abaixo.

## Próximo incremento após RF-AF-01

O relatório RF-AF-01 está actualizado e a migração 000004 foi confirmada aplicada.
As orientações antigas sobre implementar conflitos ficam como histórico; não
refazer o módulo. Avançar para adjudicação e ordens de compra no mesmo Laravel.

Reutilizar ConflictGuard, auditoria, perfis, isolamento por empresa e cálculos
em centavos. A operação deve revalidar dentro da transacção todos os
intervenientes, conflitos, fornecedor activo/revisão válida, validade das
propostas, três fornecedores distintos e pelo menos dois avaliadores elegíveis
por proposta. Não confiar no indicador de prontidão mostrado anteriormente.

Escolher a proposta de maior pontuação com justificação escrita. Empates devem
permitir escolha fundamentada entre as propostas empatadas. Não inventar
autorização para dispensar cotações ou escolher fora da maior pontuação:
enquanto a política de escalão superior/excepções estiver indefinida, bloquear
esses caminhos e explicar o motivo ao utilizador.

Conferir os escalões com o valor adjudicado e a base com/sem IVA guardada no
processo. Se exigir aprovações adicionais, impedir a emissão até essas etapas
serem decididas por pessoas elegíveis e distintas. Preservar decisões históricas;
não reutilizar implicitamente uma aprovação de um escalão inferior. Respeitar os
requisitos adicionais de equipamento previstos no documento; se ainda não
suportados, bloquear a emissão para esse tipo em vez de autorizar por omissão.

Criar ordem numerada com linhas, quantidades, preços, IVA, fornecedor, moeda,
condições de pagamento, data/local de entrega, justificação e matriz de avaliação
congelados no momento da emissão. Alterar depois a ficha do fornecedor ou a
proposta não pode reescrever a ordem emitida. Impedir emissão duplicada, inclusive
por repetição do pedido; usar restrição de unicidade e transacção. Não permitir
modificar directamente montantes/estado da ordem pelo navegador.

Entregar listagem, detalhe e impressão/PDF com acesso autenticado e por empresa,
incluindo emitente e histórico. Não enviar a ordem por email nem autorizar
compras reais. Se o orçamento ainda não estiver implementado, assinalar essa
limitação; não apresentar uma validação orçamental inexistente.

Testar permissões, isolamento, valores e IVA, fronteiras de escalões, empate,
excepções bloqueadas, conflitos ou suspensão depois da avaliação, validade,
duas avaliações, duplicação/idempotência, snapshot e rollback de auditoria.
Manter revisão visual autenticada e concorrência PostgreSQL como pendentes até
verificação efectiva. Actualizar docs/desenvolvimento.md com resultados,
migração aditiva, preservação de dados e limitações. Começar a implementação,
sem se limitar a confirmar a leitura das orientações.

## Próximo incremento após fornecedores e anexos

A entrega de edição/renovação e documentos privados foi reportada como concluída.
O acompanhamento confirmou o relatório actualizado e a aplicação da migração
000003 no PostgreSQL. A revisão visual autenticada e testes de concorrência real
continuam pendentes e não devem ser apresentados como aprovados.

Avançar agora com declarações de conflito de interesses (RF-AF-01), antes da
adjudicação. Reutilizar utilizadores, fornecedores, empresas e auditoria existentes.
Implementar declaração pessoal por fornecedor e por processo; guardar autor,
âmbito, datas, fundamento e histórico. Não permitir declarar ou retirar conflitos
em nome de outro utilizador sem uma política e autorização explícitas. Alterações
devem manter o histórico, sem apagar declarações anteriores. A periodicidade e
validade anual dependem da política da empresa: não inventar caducidade automática
que permita contornar um conflito ainda activo.

Aplicar o bloqueio no servidor à participação em processos com o fornecedor:
avaliação, selecção/adjudicação e aprovações quando o fornecedor já é conhecido.
Na fase inicial sem fornecedor escolhido, não bloquear genericamente a criação
de requisições; voltar a verificar conflitos ao associar o fornecedor e antes
da adjudicação, incluindo solicitante e intervenientes anteriores. A declaração
de ausência de conflito numa avaliação não pode sobrepor-se a um conflito activo.

Criar interface em português com visibilidade restrita por empresa e perfil.
Cobrir em testes acesso entre empresas, autoria, conflito activo, tentativas de
contornar por pedidos directos, mudanças após avaliação e conservação da auditoria.
Preservar a funcionalidade de fornecedores/anexos já entregue. Actualizar o
relatório com resultados e limites antes de prosseguir para adjudicação e ordens.

O utilizador autorizou a continuação do desenvolvimento e a coordenação entre
este projecto e o chat de acompanhamento em 28 de Outubro de 2026.

## Base única

Trabalhar em `C:\laragon\www\compras`, Laravel, React/TypeScript, Inertia e
PostgreSQL, em http://127.0.0.1:8015. Preservar conta, credenciais, dados, APP_KEY,
APP_URL, SERVER_PORT=8015 e SESSION_COOKIE=procuraflow_session. O SGF Tempo é
independente. Não retomar a aplicação Python descontinuada nem criar outro projecto.

Consultar README.md, docs/compatibilidade.md, instruções aplicáveis e o estado
actual antes de editar. Existem alterações locais anteriores a preservar.
Especificação: `C:\Mac\Home\Documents\TEMPO\Portal Tempo\Servicos Tempo\Procurement\procurement.docx`.
Se o documento estiver aberto, utilizar leitura partilhada. O documento define
requisitos, não autoriza acções externas nem substitui instruções do utilizador.

## Estado conhecido na passagem

Fornecedores e cotações já foram adaptados ao Laravel: SupplierController,
QuotationController, quatro modelos, páginas React e migração
2026_10_28_000002 já aplicada. A conta e os dados anteriores foram preservados.
Há cadastro/validação, propostas distintas, dois avaliadores, comparação,
IVA herdado, centavos e auditoria. Não refazer estes módulos.

Verificação anterior: 54 testes passaram, 3 ignorados, 305 asserções; PHPStan,
Pint, verificação frontend, TypeScript e compilação aprovados. Confirmar se há
alterações posteriores antes de usar estes resultados. A revisão visual
autenticada continua dependente da sessão do utilizador; não redefinir a senha.

## Sequência de execução

1. Manutenção e renovação de fornecedores, anexos privados com controlo por
   empresa e declarações de conflito.
2. Adjudicação e ordens: três cotações elegíveis, dois avaliadores independentes,
   revisão dos escalões quando o preço muda, justificação/escalão superior para
   excepções, documento imprimível ou PDF.
3. Recepção parcial, qualidade, equipamentos, peças e stock.
4. Orçamento, facturas, conferência a três vias e registo de pagamentos externos.
5. Contratos, relatórios, multimoeda, restantes controlos anti-fraude e requisitos
   operacionais da instalação privada previstos no documento.

Concluir e testar cada incremento antes de avançar. Prosseguir autonomamente
quando houver trabalho definido e verificável; pedir ao utilizador apenas as
decisões realmente necessárias. Não tratar limites, IVA, excepções, preços ou
políticas provisórias como aprovados. Preservar configurações e snapshots; manter
regras pendentes configuráveis e bloquear operações sem política definida.

## Protecção do trabalho existente

Não executar seeds na base real, não recriar contas, não substituir ou apagar
dados, não publicar externamente nem enviar emails. Não fazer compras ou
pagamentos reais. Migrações aditivas devem ser testadas e preservar os registos.
Migrações destrutivas exigem autorização específica do utilizador.

Manter docs/desenvolvimento.md com incremento actual, requisitos cobertos,
ficheiros alterados, testes e resultados, limitações, decisões pendentes e próximo
passo. O acompanhamento consultará esse relatório, sem editar código em paralelo.
Verificar permissões, isolamento, segregação, cálculos e auditoria, além de
PHPStan, Pint, tipos e compilação. Não anunciar como concluído o que não foi
implementado ou verificado.

## Coordenação

Chat executor: “Criar sistema de compras”, identificador
`01a18181-1611-7a33-9d79-abd981f42bfe`, host local.
Na primeira tentativa de passagem, o envio falhou porque o chat já tinha uma
sessão de escrita activa. Este ficheiro não prova que o executor o tenha lido.
O acompanhamento deve tentar entregar a orientação quando o chat estiver
disponível e registar o resultado, sem interromper nem duplicar o executor.

## 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. Núcleo único e históricos preservados; novo schema QA aplicado apenas nas bases descartáveis. As demonstrações persistentes não foram actualizadas; revisão local descartável disponível pelo runner documentado com --reversals --review. Sem direitos públicos, bancos, contabilidade, reversão parcial ou publicação. Visual/MFA pendentes e aceitação deste incremento não presumida. Ver [entrega de reversões](../../sgf-tempo/docs/SUPPLIER_ALLOCATION_REVERSAL_DELIVERY.md).

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](../../sgf-tempo/docs/SUPPLIER_SETTLEMENT_CONSOLIDATION_20261030.md). 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](../../sgf-tempo/docs/SUPPLIER_SETTLEMENT_DELIVERY.md), 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/reposição — 01/11/2026, parcial:** proprietário pediu implementação do Word com reutilização de dados, preenchimento progressivo e funções claras para revenda/uso interno, ambos com compra local/importada. Código novo em SupplyPlanning/ReplenishmentProjection e /compras/fornecimento: acordos/políticas versionados, aprovação independente, três entradas no menu Compras e seis capacidades na parametrização. Importação ligada à ordem existente com marcos comprovados e bloqueio de recepção antes da libertação. Calendário apenas manual em dias corridos; motor A/B/C testado, mas reservas/entregas ainda não integradas no ecrã. Migração 42 preparada, não aplicada; nenhuma conta/atribuição alterada ou publicação. Documento integral NÃO concluído: matriz de cobertura e restantes incrementos no fim de desenvolvimento.md. Prosseguir com alternativas direccionais e reservas/entradas por linha, depois sugestões versionadas/conversão única e importação financeira pelo núcleo comum. Preservar alterações de candidaturas anteriores e não assumir nomes antigos do produto/menus como actuais.

**Fornecimento — instalação posterior, 01/11/2026:** 000042 instalada apenas na avaliação 8005, backup/restauro comparado e 104 tabelas preservadas, tabela nova vazia. Corrigido alias de conexão na instalação; compras_dev conferida sem tabela/ledger novos. Provas supply-install.json e supply-navigation.json, três páginas HTTP/Inertia disponíveis. 96 testes dirigidos/652 asserções, tipos e PHPStan do âmbito aprovados. Política reutiliza prazo/origem e versão de acordo aprovado. Sem atribuições automáticas, dados de negócio ou publicação. Substitui apenas a indicação anterior de migração por aplicar; restante proposta continua pendente na matriz. Próxima execução deve continuar a implementação, sem interpretar este incremento como conclusão do Word.

**Reservas/entregas/alternativas — 01/11/2026:** continuação entregue no código e na avaliação local sem nova migração. SupplyCoordination reutiliza supply_records/42; quatro capacidades próprias para reservas, confirmações, preparação técnica e validação técnica. Reservas em Armazém e activos, entregas e alternativas em Compras. Seleccionar fontes existentes (linha aprovada/catalogada, ordem emitida ou saída real); preenchimento da fonte pelo servidor, limites, versões e aprovação técnica independente de todos os preparadores. Recepção reutiliza artigo/local da confirmação. Calendário já inclui reservas pendentes, confirmações ainda por receber e saídas efectivas, sem duplicar consumo nas saídas antecipadas. Previsão habitual desconhecida mantém necessidades conhecidas com cobertura incompleta. Relações técnicas são direccionais e elegibilidade consulta validade/cadastro; utilização em compras e condições ainda por integrar. Confirmação única por linha, ainda sem múltiplos embarques. Provas PostgreSQL 14/101 e duas corridas com contenção real, seis páginas HTTP, tipos/build/lint/PHPStan do âmbito aprovados. Sem novas atribuições ou comandos de negócio na avaliação persistente; visual pendente. Matriz restante no fim de desenvolvimento.md: histórico validado, sugestões/conversão única, comparação elegível/substituições, lotes/devoluções/estornos, alertas e importação completa pelo núcleo financeiro comum. Estes pontos continuam autorizados; não pedir nova autorização técnica corrente nem declarar o Word integralmente concluído.

**Regressão final de fornecimento:** 764 aprovados, dois ignorados anteriores e 7913 asserções; proofs/supply-coordination.json. Restante âmbito permanece na matriz, sem aceitação comercial integral presumida.

**Sugestões e conversão — 01/11/2026:** menu Compras > Sugestões de reposição; três capacidades próprias (preparar, conferir, converter) na parametrização. SupplySuggestions reutiliza supply_records/42, catálogo e RequisitionWorkflow/StoreRequisitionRequest. Preserva cálculo e fontes, valida base actual antes de decidir/converter, autoria nominal, independência de todos os preparadores e pessoa que conferiu diferente do autor da requisição. Preço MZN do acordo e IVA configurado reutilizados; ausência de preço local exige estimativa fundamentada, sem câmbio inventado. Mínimo/embalagem e máximo no horizonte conferidos. Conversão cria apenas um rascunho, com centro de custo próprio, sem efeitos de compra/stock/orçamento/dívida/pagamento. Repetições idempotentes, vínculo e auditoria atómicos; proveniência mínima visível no detalhe da requisição autorizada. Evita plano automático concorrente enquanto o artigo/local estiver em acompanhamento; encerramento directo após rejeição ou recepção completa. Cancelamentos/revisões de origem e múltiplas necessidades independentes ainda não acompanhados automaticamente. Sem migração, novas concessões/contas ou publicação. A proposta integral continua em implementação; restantes pontos e limitações no fim de desenvolvimento.md.

**Provas finais das sugestões:** 772 aprovados/dois ignorados anteriores e 8009 asserções; PostgreSQL 22/197 e quatro corridas com contenção real, incluindo conversão única e retry. Tipos/build/lint/PHPStan do âmbito e sete páginas HTTP locais aprovados. proofs/supply-suggestions.json conserva resumo e hashes das fontes. Visual/publicação pendentes; não reabrir este incremento como se as sugestões e a conversão directa ainda não existissem.

**Histórico de consumo — 01/11/2026:** novo menu em Armazém e activos, capacidades próprias de preparação/conferência, diário append-only existente/42 sem nova migração. SupplyHistory calcula por artigo/local/período fechado a partir do razão, inclui dias sem consumo e exclui transferências/ajustes/recepções. Cobertura e finalidade/padrão confirmados por outra pessoa; ausência de dados não é consumo zero presumido. Política selecciona versão aprovada e define mínimo de dias/idade máxima; média exacta por numerador/denominador alimenta calendário e sugestões sem arredondar consumo pequeno a zero. Suspensão, alterações e antiguidade invalidam a reutilização sem reescrever o histórico, mantendo manual/necessidades conhecidas. Política pode originar novo rascunho reutilizando campos por referência, com nova conferência e uma única activa. Sem contas/grants ou dados de negócio na avaliação persistente. Média regular observada entregue; backtesting, métodos sazonais/intermitentes, ABC e prazo observado ainda pendentes. Restantes lacunas da proposta conservadas na matriz de desenvolvimento.md, sem presumir conclusão comercial integral.

**Provas finais do histórico:** 786 aprovados/dois ignorados anteriores e 8122 asserções na suíte completa; 20/163 dirigidos após validação final. PostgreSQL 36/310 e quatro corridas de regressão com contenção real; oito páginas HTTP locais, tipos/build/lint/PHPStan do âmbito aprovados. proofs/supply-history.json conserva resultados e hashes. Visual/publicação pendentes. Não tratar média histórica regular e reutilização de políticas como funcionalidades ainda ausentes; métodos avançados e restantes lacunas mantêm-se na matriz.

**Lotes/validade/quarentena — 01/11/2026:** primeiro percurso operacional em Armazém e activos > Lotes, validade e quarentena. Cinco competências próprias na parametrização; sem concessões automáticas. `InventoryLots` reutiliza o diário imutável/42 para preparação de âmbito, metadados e qualidade; migração 43 acrescenta apenas repartições de movimentos/saldo residual, mantendo `stock_movements` como única autoridade física. Activação por artigo/local exige conferência independente e saldo/versão actuais. Identificação única ou repartição exacta; sem identidade/validade confirmadas, material indisponível. Recepção permite registar lotes em secção opcional, reutiliza quantidade aceite quando lote único e conserva origens; entra em quarentena. Libertação independente de todos os autores da identificação/recepção, motivo/versões/idempotência; correcção invalida libertação anterior sem apagar decisões. Saídas automáticas por validade mais próxima, apenas utilizáveis, uma única saída física. Stock/operações mostram utilizável e indisponível sem conceder acesso adicional ao histórico. Calendário/sugestões reutilizam contexto e descontam apenas remanescente projectado que perde validade; entradas futuras sem qualificação não contam como utilizáveis, com aviso. Âmbitos sem lotes e retries de recepções antigas conservam compatibilidade.

**Instalação/provas de lotes:** 43 instalada apenas na avaliação 8005, backup/restauro verificados, 105 tabelas preservadas e nova tabela vazia, sem contas/grants/activação/dados empresariais novos. 799 aprovados/dois ignorados anteriores e 8192 asserções na suíte completa; PostgreSQL 49/379 e seis corridas com contenção real (incluem dupla saída e identificação/libertação concorrentes). Nove páginas HTTP/Inertia, tipos/build/lint/PHPStan do âmbito aprovados; sem conferência visual ou publicação. proofs/inventory-lot-install.json, inventory-lots.json, supply-coordination-pg.json e supply-navigation.json. Não repetir a instalação 43 nem recriar tabelas: o instalador detecta ledger existente.

**Próxima implementação autorizada:** completar transferências entre âmbitos com lotes, quarentena no destino, contagem/ajuste por lote e devoluções/abates/estornos com conservação exacta e independência. Neste momento transferências/ajustes com artigo controlado em qualquer ponta são impedidos pelo servidor, com motivo visível antes da activação; contagem permanece sem efeito físico. Não retirar esta guarda sem implementar repartição das duas pontas/ajuste. Falta revisão de parâmetros activos, política conferida de dispensa de quarentena e selecção manual de lote, reutilização explícita de identidade entre recepções, qualificação futura, relatórios/alertas e paginação completa (100 controlos/200 eventos actuais). Restantes lacunas Word mantêm-se na matriz de desenvolvimento.md; lotes iniciais/recepção/saída/qualidade não equivalem a cobertura integral da proposta. Continuar sem pedir nova autorização para trabalho técnico corrente já solicitado.

**Transferências por lote — 01/11/2026:** StockWorkflow já reparte origem e destino da transferência normal, com os dois movimentos habituais e a mesma identidade de lote. Ambos os âmbitos têm de estar activos e reconciliados; saída automática por validade mais próxima, apenas libertados/utilizáveis. Substitui a indicação anterior de transferências totalmente pendentes; ajustes por lote continuam pendentes e protegidos. Nova chegada coloca todo o saldo da identidade no destino em quarentena, incluindo quantidades anteriores, com aviso nos ecrãs; origem conserva decisão local. Autor e responsável da transferência integram a independência pendente da custódia, além de autores da identificação; hold posterior não elimina intervenientes e nova libertação tem controlo de versão. Parâmetros de validade do destino são aplicados independentemente. Operação/movimentos congelam somente os lotes utilizados e as versões aplicadas; detalhe visível no histórico normal. Retry não duplica movimentos nem reabre quarentena depois de conferência. Sem nova migração/grants/dados empresariais na avaliação. Transferência ainda imediata, sem expedição em trânsito/recepção física separadas; não movimenta lotes indisponíveis. Seguir com contagem/ajuste por lote e depois devoluções/abates/estornos, mantendo conservação, qualidade e restantes lacunas da matriz. Não declarar o Word completo.

**Provas finais das transferências:** 806 aprovados/dois ignorados anteriores e 8230 asserções; PostgreSQL 56/417 e sete corridas com contenção real, incluindo dupla transferência do mesmo lote com conservação das duas pontas. Tipos/build/lint/PHPStan dos serviços alterados e nove páginas HTTP/Inertia locais aprovados. proofs/inventory-lot-transfers.json conserva resultados e hashes. Avaliação 8005 actualizada pelo código/recursos compilados, sem nova migração, novas atribuições ou dados de negócio. Conferência visual/publicação não realizadas. A próxima lacuna operacional é contagem/ajuste por lote; não tratar transferências imediatas entre âmbitos activos como ainda ausentes.

## 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.

**Continuação de armazém — 01/11/2026, contagens/ajustes/devoluções/regras/estornos:** contagens físicas por lote reutilizam cadastro e calculam total; inventory_adjust_review confere/aplica por pessoa diferente de autor/responsável. Diferenças mistas, inclusive total inalterado, usam adjustment_out/in atómicos; excedentes ficam em quarentena. Migração 44 instalada só em 8005, backup/restauro verificados, 106 tabelas preservadas, sem novas tabelas/grants/dados de negócio; proofs/inventory-count-install.json. Devoluções e abates têm preparação/conferência próprias e execução por Armazém diferente do aprovador; reutilizam origem e mantêm limite físico/aceitação, incluindo lotes retidos/vencidos sem contar como consumo. Novas facturas descontam devoluções líquidas; documentos anteriores e núcleo financeiro permanecem preservados, com factos para conferência em Finanças.

**Parâmetros de lotes já revistos pela interface:** versão activa continua durante proposta de revisão; aprovação independente revalida saldo/qualidade/identificação e impacto quantitativo. Não repartir saldo novamente. Dispensa de quarentena só após configuração aprovada e apenas para recepções futuras conformes/identificadas/válidas; versão aplicada e modo por regra ficam preservados/visíveis. Saldo inicial, transferências, excedentes e estornos positivos continuam retidos. Falta desactivação, vigência programada e selecção manual de lotes em saídas/transferências.

**Estornos físicos já implementados:** capacidades inventory_reversal_read/prepare/review, execução por Armazém independente da decisão. Integral e único por operação física/linha de recepção, com dados reutilizados e original preservado. reversal_in/out e repartições inversas usam StockWorkflow, sem novo razão. Reposição controlada exige qualidade independente; saída antiga sem lote reposta fica por identificar. Não inferir correspondência de entrada antiga com lote inicial. Reservas reabrem quantidade efectiva e análises históricas corrigem consumo/assinatura mesmo com estorno posterior ao período; séries físicas mantêm datas de lançamento. Recepção anulada deixa de ocupar quantidades efectivas; retry da original não recria stock. Devolução estornada deixa de descontar devolvido líquido. Não confundir com crédito, restituição ou estorno financeiro: falta regularização no núcleo comum, sem motor paralelo. UI mostra decisões recolhidas, uma acção/formulário por registo. Mantêm-se restantes lacunas na matriz e decisões de composição comercial anteriores; não declarar Word integralmente concluído. Verificação final conjunta será acrescentada após os testes, sem substituir provas anteriores.

**Calendário/conferência desta continuação:** atenções factuais no calendário existente; acordo/fornecedor desactualizado retira prazos derivados, cadastro/unidade alterado exige rever política. Prova conjunta em proofs/inventory-corrections.json: PostgreSQL 98 testes/628 asserções e onze disputas reais passaram; onze páginas locais passaram com contexto de compras autorizado, sem comandos de negócio/grants. Tipos, compilação, análise PHP e 18 ficheiros comuns conferidos. Sem revisão visual por capturas. Bateria geral ainda em execução; resultado será acrescentado sem substituir provas anteriores.

**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 (01/11/2026):** menu próprio em /pessoas/relatorios, resumo por percurso/estado, filtros, paginação, impressão desta página e CSV completo dos resultados filtrados; ligação ao relatório individual existente. Reutiliza permissões por percurso e participação vigente no processo, empresa/contexto; admin não recebe acesso global. Sem dados privados de candidatos/entrevistas/contratos/finanças na listagem. 52 testes/1188 asserções, tipos, análise PHP, compilação e duas verificações HTTP locais passaram; prova proofs/people-reports-http.json. Sem migração/grants. CSV materializa campos mínimos para fotografia consistente; considerar exportação assíncrona para conjuntos muito grandes. Sem revisão visual por capturas.

**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 candidaturas/avaliações (01/11/2026):** disponível por atalho em /pessoas/relatorios?view=applications; contagens por processo, filtros/CSV/impressão existentes. Reutiliza matrix e, após aprovação, selection.rows preservado; portal separado de candidaturas registadas para evitar duplicação. Triagem só com canRead, sem acesso representado por null. Sem dados pessoais/evidências nos indicadores e sem grants/migração. Período refere criação do processo. Restam relatórios de selecções/contratações e prazos/responsabilidades propostos; não inferir contrato assinado a partir de minuta.

**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.

**Selecções e contratações (01/11/2026):** relatório em /pessoas/relatorios?view=selections, com proposta/devolução/aprovação, datas, pendência e metadados da minuta apenas com contract/contract_view. Não inclui termos/fundamentos/candidatos/finanças e não infere assinatura/admissão. Filtros, impressão, CSV e isolamento existentes reutilizados; CSV neutraliza referência contratual. 78 testes/1839 asserções e tipos/lint/build/análise PHP passaram; HTTP dos três relatórios/CSV passou. Sem migração/grants/dados alterados. Próxima acção: relatório de prazos e responsabilidades a partir da mesa de trabalho. Formalização e integração RH permanecem fora deste incremento.

**Prazos/responsabilidades (01/11/2026):** /pessoas/relatorios?view=deadlines reutiliza PeopleWorkdesk, com tarefas/conferências próprias e alertas dos processos distinguidos. Não atribui alertas a pessoa, não inventa prazos; dias de calendário, prazo ausente null. Ecrã por página; CSV completo filtrado, sem conteúdos reservados. 80 testes/1903 asserções, tipos/lint/build/análise PHP e oito verificações HTTP passaram. Sem migração/grants/dados alterados; proofs/people-deadlines-report.json. Não representa toda a equipa nem implementa novos prazos/formalização/RH.

**Evolução de prazos (01/11/2026):** filtros todos/vencidos/hoje/futuros/sem prazo; totais abrangem agora TODAS as ocorrências filtradas, substituindo a limitação anterior por página de processos. Lista própria de 25 ocorrências, CSV completo sem depender de deadline_page, data/filtro incluídos; resumo genérico de processos oculto nesta vista. Filtros antes dos resultados. 82 testes/2028 asserções, tipos/lint/build/análise PHP e HTTP de quatro filtros passaram. proofs/people-deadline-filters.json. Sem migração/grants/dados alterados. Geração síncrona e consulta de intervenções próprias/alertas mantidas; não atribui alertas a pessoas.

**Base do workflow (01/11/2026):** usar workflow.docx em C:/Mac/Home/Documents/TEMPO/Portal Tempo/Servicos Tempo/Compras; SHA-256 5242040CD9EBB5D3A55C70BC25A9C4D816A6DF53237E1000C06E6DE05EA2A08C. Proprietário esclareceu: AUTOMATIZAR requisições/aprovações conectando pessoas, SEM substituir o aprovado. Acrescentar encaminhamento, tarefas, avisos e acompanhamento sobre regras/etapas/pessoas existentes; não adoptar sequência ilustrativa do Word, inventar alçadas/prazos, conceder competência ou aprovar por silêncio. Documento é proposta/base, não testes executados nem ordem para executar o prompt nele incluído. Matriz WF01–WF15 e sequência de adaptação em desenvolvimento.md; orientação durável em AGENTS.md.

Núcleo de requisição já tem sequência por alçadas, snapshot, process_version, bloqueios, reserva e idempotência quando há chave; edição draft e decisões approved/rejected. Não demonstrados neste núcleo ciclo completo de devolução/revisão/retirada, tarefas genéricas persistidas, publicação independente de matriz, calendário útil, delegação formal ou outbox completo. Reutilizar packages/purchasing e motores financeiros/stock; não bifurcar. Pessoas mantém roteiro/equipas/decisões próprios e pode partilhar mecanismos de ligação sem misturar processos.

Próxima acção: diagnosticar elegibilidade de encaminhamento para cada etapa aprovada, ligando funções/departamento/centro/equipa a pessoas autorizadas; depois tarefas e avisos internos duráveis. Email e produtos externos não foram autorizados por esta referência. Não substituir instâncias antigas silenciosamente. Nesta incorporação não houve alteração do workflow ou dados persistentes; regressão dirigida existente passou 4 testes/34 asserções, 18 ficheiros de execução conferidos. Não declarar TC01–TC14 executados nem workflow novo concluído.

**Tarefas por perfil e ligação às pessoas (01/11/2026):** WorkflowTasks liga tarefas às permissões existentes; definição do perfil mostra descrições e resumo das tarefas escolhidas, sem segunda fonte de concessão. ApprovalRouting mostra no detalhe da requisição a fila actual de pessoas elegíveis pela canDecide/empresa/departamento/conflitos/contexto e exclui manutenção. Sem pessoas elegíveis fica aviso, pedido mantém estado. Não é atribuição exclusiva nem aviso enviado. Não altera sequência/aprovações/regras. 40 testes/403 asserções, tipos/lint/build/análise dos serviços, 18 ficheiros de núcleo e HTTP local passaram; proofs/approval-routing.json. Sem migração/grants. Próxima acção: persistência de tarefas e avisos internos ligados ao evento confirmado. Subacções de permissões abrangentes ainda não seleccionáveis independentemente; exigir evolução real do núcleo, não só UI.

**Avisos internos (01/11/2026):** migration46 workflow_notices instalada só em8005, backup/restauro e106 tabelas preservados; proofs/workflow-notices-install.json. Port do núcleo cria aviso único por etapa/destinatário com submissão/decisão na mesma transacção, sem alterar núcleo distribuído/regras. /requisicoes/avisos, filtro por ler, paginação e ligação ao pedido; ler não aprova, auditado/idempotente. Revalida destinatário/empresa/contexto/canDecide; avisos obsoletos deixam lista activa mas ficam guardados. Sem email/outbox externo, retroactividade, lembretes, delegação ou tomada exclusiva. Acessos novos em etapa já aberta ainda dependem de Pendentes para mim.42 testes/455 asserções dirigidos passaram; geral/PG a concluir. Não declarar TC01–TC14 completos.

**Verificação final dos avisos:** geral891 testes/889 passaram/2ignorados/9236 asserções; PG21 testes/244 asserções de requisição/contextos passaram; tipos/build/lint/análise/HTTP passaram. proofs/workflow-notices.json. Teste de relatório de OrganizationConfigurationTest usa transacção externa incompatível com guarda PG de leitura própria; não alterado nem certificado em PG, coberto na bateria habitual. Próximo: reencaminhamento controlado de etapas já abertas e aviso de resultado ao requisitante; sem novo motor/decisão repetida.

**Resultados ao requisitante (01/11/2026):** WorkflowNotices::outcome cria aviso final approved/rejected na tabela46 existente, atómico com decisão/auditoria/orçamento e único por etapa/destinatário. /requisicoes/avisos separa tarefas/resultados/porler; menu inclui requisitante. Resultado histórico e estadoactual distintos; só destinatário com acesso actual consulta/lê, sem conteúdo reservado. Sem migração/email/grants/retroactividade.45 testes/573 asserções e PG24/362 passaram; tipos/lint/build/análise/HTTP e18 ficheiros de núcleo passaram. proofs/workflow-outcomes.json. Próximo: reencaminhamento controlado de etapas abertas após mudança de perfis, sem duplicar decisão nem conceder competências.

**Actualizar encaminhamento (01/11/2026):** acção recolhida em requisição pendente para admin/Compras fora de manutenção. Motivo+versão+etapa+chave; cria só avisos em falta a elegíveis actuais, sem escolher destinatários arbitrários ou mudar decisões/competências/etapas. Recibo lógico na auditoria imutável, idempotência sob bloqueio, falha de auditoria reverte avisos; leitura anterior e avisos antigos preservados. Perfil alterado não desencadeia esta acção automaticamente.47 testes/602 asserções e PG26/391, tipos/lint/build/análise e18 ficheiros comuns passaram; proofs/workflow-routing-refresh.json. Sem migração/email/grants. Pendências: lembretes/calendários configurados, delegação formal e automatização de reconciliação com âmbito explícito após alteração de perfis.

**Proposta recebida de requisições ao armazém (01/11/2026):** fonte attachment e9adc3f7-1b4f-488c-a3fe-f53b310a1e64/Texto colado.txt. Enquadramento em desenvolvimento.md; não activada nem confundida com fluxo aprovado. Pedido ao armazém separado de compra, reutiliza origens/cadastros; reservas actuais SupplyCoordination são planeamento, não bloqueio físico. Novo compromisso exige integrar TODOS os caminhos que reduzem disponibilidade no único StockWorkflow, saída parcial+consumo da reserva atómicos, libertação só do restante, reconciliação autorizada. Termo saída por entrega distinto de abate por inutilização. Não activar vendas/integrações nem matriz ilustrativa automaticamente; sem inventar alçadas/prazos. CA01–09 são plano, não provas passadas. Nesta análise só documentação, sem testes de aplicação ou dados alterados. Próxima acção: vínculo necessidade planeada→pedido armazém→compromisso físico e responsabilidades/configuração antes de alterar disponibilidade.

**Disponibilidade para requisições (01/11/2026):** /stock/disponibilidade, menu Armazém e activos, reutiliza StockWorkflow/InventoryLots e políticas/necessidades de SupplyPlanning. Físico/utilizável/retido/planeado separados, compromisso físico desconhecido explícito; sem movimentos/reservas/compras em GET. Nova capacidade warehouse_availability_read configurável sem grants.16 testes/123 asserções, tipos/lint/build/análise passaram. Proprietário determinou compra por inexistência/mínimo (AGENTS.md); geração ainda NÃO implementada, UI explícita. Próximo: configuração da origem/requisitante/centro/quantidade e comando de geração idempotente sem duplicar reposição em curso, preservando aprovações; não inventar dados nem activar vendas por inferência.

**Destino do pedido — proprietário01/11/2026:** explicitar onde será usado; equipamento seleccionado do cadastro quando aplicável; venda ligada a FACTURA DE VENDA/linhas. Facturas actuais de fornecedor não servem de origem comercial. Condicionar campos ao destino, preservar referência/versão e transmitir vínculo à compra por falta. Não duplicar abate da origem externa nem activar vendas por inferência. Requisito incorporado em AGENTS.md; pedido/campos ainda por implementar, consulta de disponibilidade não os substitui.

**Rascunhos ao armazém (01/11/2026):** /stock/requisicoes, migração47 instalada apenas8005, backup/restauro107 tabelas preservadas. Snapshot interno local/finalidade/centro/requisitante/artigos; equipamento por linha do cadastrodept, peças com vínculo validado. Tarefas warehouse_request_prepare/read semgrants; próprio vs consultaempresa separados. Idempotente, auditoriaatómica, sem stock/orçamento/compra ou autorização. Venda/factura de venda indisponível até fonte comercial válida; não associar factura de fornecedor.81testes/809asserções e PG6/66, tipos/lint/build/análise/HTTP passaram; proofs/warehouse-drafts.json. Sem edição/submissão/autorização/reserva/entrega ainda; próxima: edição versionada e configuração/submissão/autorização. Geração automática de compra por falta/mínimo permanece requisito a executar com origem/requisitante/centro/quantidade configurados.

**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/entrega interna sem factura (01/11/2026):** migração48 eventos instalada só8005 com backup/restauro108 tabelas preservadas. /stock/requisicoes/{id} imprime requisição e entregas; submit, authorize/reject, deliver parcial/integral e receive. Tarefas review departamental independente e deliver+warehouse semgrants; requisitante não aprova/entrega, aprovador não entrega. Parcial aceite na submissão e autorizado. Cada entrega chama StockWorkflow issue; evento/auditoria/movimentos atómicos, repetição/versão controladas; recepção não movimenta stock.85testes/495asserções e PG12/122+2disputas reais passaram; geral a concluir. Reserva exclusiva e compra automática ainda NÃO implementadas, UI explícita. Não declarar CA01–09/totalidade proposta. Cancelamento, versão, delegação, avisos novos e destinatário alternativo pendentes. proofs/warehouse-fulfilment-install.json.

**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 e reposição parametrizada concluídas neste incremento:** migração49 instalada só na avaliação8005, diário warehouse_reservations imutável;109 tabelas preservadas por backup/restauro conferidos. Autorização reserva stock utilizável livre; entrega consome a reserva e o StockWorkflow atomicamente; revisor pode actualizar reserva ou cancelar apenas o saldo. Saídas, transferências, correcções, devoluções/abates e estornos protegem os compromissos. Retenção/validade pode criar défice, que impede a entrega; não remover controles de qualidade para satisfazer a reserva. Autorizações antigas precisam de actualização explícita da reserva.

/stock/reposicao no menu Armazém e activos: supply_prepare prepara regra por artigo/armazém, supply_review activa/suspende com independência de todos os preparadores. Requisitante e centro são parametrizados conforme autorização expressa do proprietário, sem pessoas/valores fictícios. Política/catálogo/acordo/tributação reutilizados; peças exigem equipamento compatível. Gera só rascunho canónico, com executor real auditado e requisitante designado, sem impersonação, submissão, aprovação, orçamento, encomenda ou factura automática. Origem/local/equipamento visíveis na requisição gerada. Necessidade pendente quando falta configuração, fonte válida, destino ou estimativa. Reposição ligada em curso evita duplicação; rejeição não se recria pela mesma regra. Preservar as aprovações e o motor comum; não voltar a tratar compromisso físico como reserva planeada.

Provas: geral920/918 passaram/2 antigos ignorados/9620 asserções; PG24/232 mais3disputas reais (incluindo activação concorrente com um rascunho); tipos/lint/build/análise PHP/18 hashes e HTTP de consulta passaram. docs/proofs/warehouse-replenishment.json e warehouse-reservations-install.json. A porta8005 estava desligada e foi retomada com a configuração/base existentes. Sem dados sintéticos/grants e sem prova visual por capturas. Estes resultados substituem a pendência histórica de reserva/compra automática; não significam que toda a proposta esteja concluída.

Próximos incrementos concretos: avisos/tarefas do próprio armazém; fila durável e recuperação de sinal após interrupção, com varrimento de validade/mínimo sem evento; prioridades e prazos de expiração parametrizados; reserva após nova entrada continua a exigir intervenção explícita do revisor. Não introduzir prioridades, datas ou destinatários presumidos. Vendas e facturação continuam reservadas à composição SGF.
# Continuidade — candidata SGF corrigida em 02/11/2026

**Não instalar nem activar por continuidade implícita.** Proprietário autorizou apenas preparação isolada; SGF destino `C:\laragon\www\sgf-tempo`, base `sgf_tempo_dev` em `127.0.0.1:55432`, mantém pacote 0.1.1. Candidata actual `OPERATIONAL-CANDIDATE-401ce31ae5f2dd20`, ZIP SHA-256 `59dbdc64c4d9f14dfb4025a6177b829d136a4e2cb633ca036b10b5ae3197e703`; [decisão actualizada](decisao-instalacao-sgf.md) prevalece sobre os bloqueantes históricos.

Resolvidos na candidata: duas tabelas UI (migração revisão 2, 16 novas), preparação de centros/dotações por API/interface e catálogo administrativo/frontend. 157 controlos aprovados numa reprodução de estrutura actual com roles distintas; recuperação de 103 tabelas conferida. Não repetir suites aceites sem motivo novo. Proposta SQL em `docs/proofs/sgf-corrected-sql-plan.json` exige confirmação antes de qualquer GRANT/REVOKE real; instalador nunca a executa. Usar ligação migradora temporária, runtime sem CREATE/ownership; não colocar segredos no bundle/.env persistente.

Próximo passo: decisão explícita de instalação técnica desactivada com pacote/hashes e SQL concretos. Na janela aprovada, backup/restauro dos dados reais em base nova, planos reconferidos, migração e código/caches com procedimentos de recuperação distintos; não usar `sgf.ps1 stop` (pára cluster partilhado). Configuração real/dotações e dois administradores continuam requisitos para activação; fixtures nunca vão para cliente. Sem publicação, alteração de direitos públicos funcionais ou contratação para terceiros. Preservar alterações locais em curso e a aceitação própria da navegação modular.



### 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 geral de02/11/2026:** base funcional ampla, em consolidação para piloto/configuração e posterior entrega comercial. Revalidados33 testes/314 asserções,18 hashes e HTTP de reposição/avisos/relatórios de Pessoas/CSV. A geral918 aprovados é evidência anterior, não repetida nesta avaliação. Prioridade: recuperação durável da reposição após falhas e varrimento agendado; depois paginação das listas actualmente limitadas a100, avaliação de volume e parametrização das etapas ainda fixas. Completar tarefas/avisos de armazém e aceitação por perfis/impressão. Sem revisão visual completa ou certificação de produção. Não confundir candidata/demonstração SGF com instalação real, nem declarar a proposta integralmente concluída.

**Consolidação para piloto — reposição,02/11/2026:** prioridades1–3 implementadas. Migração50 replenishment_work instalada só8005, backup/restauro110tabelas preservadas, sem contas/grants. Sinal durável atómico com alteração física; rascunho/origem/checkpoint atómicos; recuperação após interrupção e dois trabalhadores concorrentes não duplicam compra. ReplenishmentRun restringe execução a CLI/empresa/trabalho/SGC, sem login ou conta sintética; auditoria identifica execução periódica e atribuição do responsável de origem. Revalida regra/requisitante/centro/contexto/destino e mantém todas as aprovações.

sgc:replenishment-tick descobre origens existentes e reavalia trabalhos vencidos; agendador por minuto, intervalo técnico persistido por trabalho por defeito5minutos. Validade/mínimo não dependem de novo movimento. Auxiliar scripts/replenishment-evaluation.php ligado à base de avaliação existente e observado em passagens sucessivas, integrado no arranque dev; não instalou serviço de arranque Windows nem alterou produção. Depois de reinício, retomar desenvolvimento/auxiliar; não provisionar outra base.

/stock/reposicao: paginação independente de regras/necessidades/histórico/trabalhos interrompidos, filtro, pendências primeiro, indicação da última passagem conhecida e recuperação explícita só para supply_prepare/review. Actualizar não cria aprovações; admin de consulta não recupera. Sem revisão visual completa. Acompanhamento adicional das reservas e validação com utilizadores existentes são a fase seguinte; roteiro preparado em desenvolvimento.md, ainda não executado por pessoas reais.

Provas NOVAS: regressão198/1579, final reposição18/155, PG33/310+4disputas, tipos/lint/build/análise/18hashes/HTTP passaram; docs/proofs/replenishment-pilot.json e replenishment-recovery-install.json. Não somar suites sobrepostas nem apresentar33/314 e918+2 históricos como execução nova. SGF real continua0.1.1; candidatura/transferência e identidade adicional mantêm as autorizações próprias, sem instalação nem criação neste incremento. Preservar trabalho paralelo no repositório.

**02/11/2026 — acompanhamento de reservas concluído neste incremento:** /stock/requisicoes tem tarefas por perfil (autorizar/reservas/entregas/recepções), pesquisa/filtros antes da paginação e contagens completas do âmbito. WarehouseWorkdesk é projecção de leitura dos diários existentes; estados conferidos contra progress(), sem outro motor ou concessão paralela. Detalhe mostra saldo sem reserva, qualidade/origem a conferir e pessoas elegíveis actuais; falta de responsável fica visível, sem atribuição automática. Entrega continua independente, com reserva/stock revalidados. Recepção permanece pendente após cancelar só o saldo; consulta/recepção não lançam saída.

Proprietário esclareceu: desenvolvimento/validação seguem com contas sintéticas, sem pessoas reais nesta fase. AGENTS.md actualizado. A avaliação persistente mantém contas/perfis/competências existentes; ensaios com actores/perfis suplementares só em bases descartáveis. Não voltar a exigir participantes reais para prosseguir nesta etapa. Isto não autoriza a identidade adicional do SGF nem instala candidatas no destino0.1.1.

Provas NOVAS: regressão111/1008, final18/326, PG38/517+3disputas, tipos/lint/build/análise/18hashes e HTTP passaram. docs/proofs/warehouse-workdesk.json e ficheiros -pg/-http. Sem migração ou concessões; sem bateria geral repetida, aceitação real ou revisão visual completa. Próximos incrementos mantêm validação sintética e qualquer expiração/prioridade/notificação persistente depende de configuração explícita dos efeitos. Preservar o trabalho paralelo e a separação Compras autónomo/SGF.

**02/11/2026 — diagnóstico e ensaio integrado do piloto:** /stock/piloto é consulta administrativa, sem efeitos operacionais, com sete conferências e contas/tarefas elegíveis. Verifica independência real de três intervenientes, centro/âmbito, catálogo actual, regras activas/fontes, serviço recente e trabalhos pendentes; distingue condições de ensaio de configuração comercial concluída. Reutiliza inspectRule/validação canónica sem locks de escrita. Telemetria partilhada via ReplenishmentQueue::status não aceita registo antigo/danificado como confirmação de serviço.

Ensaio sintético integrado percorreu pedido125/reserva120/entrega100, entrada física108 de ordem já emitida, reforço autorizado5, entrega25 e recepção: pedido encerrado, stock103, reserva0, uma requisição automática ainda rascunho, sem factura interna, aprovação ou orçamento automáticos. Não confundir origem física preexistente com execução do novo rascunho. Só bases descartáveis, sem pessoas reais ou novas concessões na avaliação.

Provas NOVAS53/705, final8/142, PG46/659+3disputas, tipos/lint/build/análise/18hashes/HTTP; docs/proofs/warehouse-pilot-readiness.json e respectivos -pg/-http. Na avaliação8005:12contas existentes; instalação/serviço conferidos, mas tarefas, catálogo, regras de reposição e configuração própria ainda a preparar. Não declarar cliente/piloto integralmente pronto nem activar perfis/valores por inferência. SGF real0.1.1 e proposta da identidade adicional continuam separados, sem instalação/autorização nova. Evidências anteriores e ausência de revisão visual completa preservadas.

**02/11/2026 — diagnóstico exportável:** /stock/piloto.csv exporta as conferências datadas em UTF-8/CSV, só para administração, usando a mesma inspecção read-only. Não exporta contas nem activa configurações. Interface inclui imprimir, ainda sem revisão visual de impressão.10testes/161asserções, tipos/lint/build/análise/18hashes e HTTP passaram; docs/proofs/pilot-export.json. Manter as configurações pendentes explícitas e a validação sintética; não apresentar exportação como aprovação ou aceitação comercial. SGF e contas/perfis persistentes preservados.

**02/11/2026 — ligação de entregas do armazém para integração:** WarehouseExchange, GET /stock/integracao/entregas e contrato integrations/contracts/warehouse-fulfilment-v1.json. Só leitura autenticada dos factos deliver/receive já registados; reutiliza RA, destino, equipamento, intervenientes e stock_operation_id, sem nova saída ou factura. Cursor incremental cifrado liga empresa/conta/contexto/departamento/competências; mudar âmbito exige reiniciar. Paginação preserva eventos antigos e permite novas consultas depois do fim. Consumidor deve persistir factos+cursor atomicamente e deduplicar por instalação de origem/empresa/idempotency_key; hash divergente exige reconciliação. Não usar feed como saldo actual ou réplica do motor de stock; estornos continuam no percurso próprio.

Provas NOVAS41/523 na regressão dirigida e10/83 do subconjunto novo em PostgreSQL descartável; formatação/análise PHP/18hashes/HTTP passaram. Provas warehouse-exchange[-pg/-http].json. Avaliação8005 devolveu zero factos na primeira página; percursos com entregas/equipamento foram sintéticos em testes. Sem contas/grants/migrações, build ou revisão visual nova, nem instalação SGF (real0.1.1 preservado). Não somar suites sobrepostas nem confundir com a bateria geral histórica. Próxima ligação deve consumir o contrato e reutilizar os motores/fontes existentes; autenticação técnica remota e confirmação persistente do consumidor ainda não fazem parte deste incremento. Contratos de Pessoas continuam com formalização/RH próprios; não exportar rascunhos como contratos formalizados. Ver desenvolvimento.md para contrato e limites exactos.

**02/11/2026 — receptor durável de entregas preparado:** packages/integration (WarehouseFeed/WarehouseInbox/WarehousePull), carregável sem Laravel. Duas definições de tabela para migração explícita do destinatário; nenhum schema instalado em aplicações persistentes. Origem+empresa de origem+empresa local+evento deduplicam factos; geração de leitor mantém checkpoint próprio. Recepção e cursor confirmados atomicamente, com versão/cursor de comparação. Retry exacto após commit sem confirmação é reconhecido; conflito/alteração de conteúdo/página antiga não avança. Recepção exige entrega original reconciliada, sem outra saída, factura ou aprovação.

Leitura por lotes reutiliza consulta autenticada fornecida pelo host; falha preserva páginas anteriores e execução posterior retoma. Não há transporte remoto, credenciais técnicas, agendador ou projecção funcional do destinatário activados. Mudança de âmbito na origem pode usar nova geração técnica de leitor preservando factos/checkpoint anterior, sem criar outra conta. Exemplo e limites em packages/README.md e desenvolvimento.md. Cursor da origem agora resume permissões por hash para caber mesmo com perfil completo; os antigos exigem reinício de leitura, sem alterar eventos/chaves.

Provas NOVAS56/628 na regressão dirigida;25/188 em PostgreSQL descartável, duas contenções reais (mesma página/páginas diferentes) e processo terminado após commit antes da confirmação, retomado sem duplicar. Formatação/análise PHP/18hashes/HTTP passaram. warehouse-inbox.json, warehouse-inbox-pg.json e warehouse-exchange-http.json; logs warehouse-inbox-regression.txt/warehouse-inbox-pg.txt. Suites sobrepostas, sem bateria geral/build/revisão visual nova. Preservados dados/perfis persistentes e SGF real0.1.1; identidade adicional continua sem autorização. Próximo recorte é transporte/configuração do host e reconciliação autorizada de vínculos, preservando o motor único e distinguindo diário recebido de projecção de stock/contabilidade e de instalação efectiva.

**02/11/2026 — consulta HTTP autenticada implementada:** WarehouseHttpSource/WarehouseTransportFailure ligam WarehousePull ao endpoint fixo da origem através de sessão já autorizada. Não fazem login, contexto, contas ou grants. Origem HTTPS, Cookie por fornecedor protegido, query codificada, sem redirects e com verificação TLS/limites de tempo/tamanho; HTTP só em loopback explícito para desenvolvimento. Erros sanitizados distinguem expiração/âmbito/cursor/falha técnica e preservam o checkpoint. Não gravar cookies ou colocar credenciais em URLs/argumentos/logs.

Provas NOVAS75/746 na regressão dirigida;44/306 em PostgreSQL descartável +2contenções reais e saída de processo após commit/antes de confirmação; formatação/análise PHP/18hashes passaram. Prova nativa cURL contra8005 reutilizou sessão sintética existente por stdin privado e receptor SQLite em memória: cursor válido e consulta sem sessão recusada,0factos na primeira página. warehouse-http-source[-pg/-http].json e logs respectivos; sem dados ou direitos empresariais persistentes alterados. Sem build/bateria geral/revisão visual/TLS comercial novo.

Transporte de sessão preparado, não API técnica permanente nem integração comercial activada. Próximas lacunas: configuração administrativa/armazenamento e renovação protegidos no host, eventual autenticação técnica restrita, agendamento e reconciliação/projecção autorizada no destinatário. Não duplicar motores ou inferir implantação. SGF real0.1.1 e identidade adicional continuam sob as autorizações existentes, sem instalação/conta nova. Documentação de ligação e limites em packages/README.md/desenvolvimento.md.

**02/11/2026 — integração desta etapa é interna ao SGC, conforme resposta expressa do proprietário:** AGENTS.md actualizado. Priorizar as ligações funcionais e a reutilização entre módulos, sem pressupor instalação/integração com SGF ou novos acessos externos. InternalSupplyTrace integra no detalhe do armazém necessidade→compra→aprovação pendente→encomendas→recebimentos, com ligação inversa da compra ao pedido permitido. Sem novas tabelas/formulários/credenciais ou cópia de documentos; impressão interna preservada, sem factura.

Última versão que mencionou a origem define as compras historicamente ligadas; a situação actual do artigo/armazém é separada. Não atribuir compras futuras ao pedido já fora dessa origem. Reposição partilhada não equivale a afectação exclusiva nem a stock livre/utilizável. Entradas/estornos são lidos das fontes actuais; actualização de reserva é intervenção explícita no formulário existente, por pessoa elegível. WarehouseWorkdesk::canView centraliza acesso ao detalhe e às ligações; processos de compra invisíveis não revelam referências/valores. Aprovações, qualidade, stock e perfis mantêm os motores existentes.

Provas NOVAS52/668 na regressão dirigida e7/105 em PostgreSQL descartável, incluindo piloto parcial/entrada de ordem preexistente/reserva/conclusão. Não somar suites sobrepostas. Teste documental de encomenda/recepção e estorno simulado verifica a projecção; não declarar que o novo rascunho percorreu adjudicação/encomenda ou que o motor de estornos foi integralmente reexecutado. Tipos/lint/build/análise PHP/18hashes e HTTP conferidos;0pedidos persistentes disponíveis para inspecção do detalhe em8005, com detalhes exercitados nas bases de testes. Sem revisão visual completa/bateria geral/migração/contas/grants/dados empresariais persistentes novos. Provas internal-supply-integration[-pg/-http].json e logs respectivos. SGF real0.1.1 e trabalho paralelo preservados. Continuar a cobertura interna por percursos concretos, sem apresentar o conjunto de propostas como concluído.

**02/11/2026 — listas de tarefas ligam os módulos internos:** /requisicoes/tarefas reúne rascunhos/aprovações de compra e decisões/reservas/entregas/confirmações de armazém; /pessoas/tarefas reutiliza PeopleWorkdesk e a equipa atribuída, mantendo a área separada. Novas entradas As minhas tarefas. WorkflowTaskInbox delega a autoridade aos motores actuais e abre os formulários originais; não cria outro workflow, tabela, prazo, pessoa ou concessão. Consulta não decide nem marca avisos como lidos. Facturas/consulta/adjudicação e fases ainda não cobertas conservam os seus percursos; não declarar o catálogo inteiro concluído.

Entrega bloqueada permanece como atenção; cada recepção tem tarefa/âncora própria, incluindo após cancelamento apenas do saldo. Confirmar uma entrega retira só a sua tarefa, sem novo movimento. Autorizar próprio pedido/entregar o que se autorizou continuam impedidos; administração de consulta/manutenção não recebem tarefas de execução. Empresa, departamento, contexto, competência e vigência de equipa continuam efectivos. Ordenação/paginação sobre o âmbito autorizado completo, sem corte global100 nem prioridade organizacional inventada.

Provas NOVAS60/925 na regressão dirigida;15/362 em PostgreSQL descartável, incluindo8testes novos. Tipos/lint/build/análise PHP/18hashes/HTTP passaram. A conta sintética administrativa da avaliação8005 viu0tarefas em cada área; pendências e intervenções reais do ensaio apenas nas bases descartáveis. workflow-task-inbox[-pg/-http].json e logs respectivos. Não somar suites sobrepostas, nem contar a bateria geral/contenções anteriores como repetidas. Sem revisão visual completa/migração/contas/grants/dados empresariais persistentes; SGF0.1.1 e trabalho paralelo preservados. Continuar pelas funcionalidades internas em falta, usando fontes/motores existentes e mantendo Compras/Pessoas separados.

**02/11/2026 — Finanças integrada no percurso interno:** a factura reutiliza as linhas congeladas da encomenda (unidade/preço/IVA); só referências, quantidades e novos dados do documento são introduzidos. Totais independentes, limites de recepção/devoluções/estornos, arredondamento, conflitos e validação por outra pessoa permanecem nos motores existentes. As minhas tarefas acrescenta Finanças para facturas e conferências de pagamentos externos; projecções de elegibilidade comuns às listas/formulários, decisões revalidadas no servidor. Catálogo de tarefas dos perfis actualizado dentro da competência financeira existente, sem concessões novas ou granularidade fictícia.

Focos por factura/encomenda e pagamento/factura preservam contexto e paginação; compra → encomenda → factura → registo externo usa documentos originais e ligações concretas. Empresa, independência, manutenção e conflitos continuam efectivos. Tarefa não revela referências/evidências/contas e não produz decisão. Revisão de pendentes importados continua sujeita a activação e competência específica pa_access/validate; não há saldo alternativo quando o núcleo está indisponível. Mudança bancária permite rejeitar, mas confirmação continua bloqueada até nova conferência válida. Não há transferência bancária, segunda dívida, factura de saída interna ou ligação nova ao SGF.

Provas novas: regressão 81/800; autoridade/integração financeira e catálogo 23/357; teste corrigido de activação isolado em SQLite 1/6. Tipos/lint/build/análise PHP/18 hashes e seis consultas HTTP8005 passaram. Facturas visíveis 1, pagamentos/tarefas 0 nas contas administrativas/financeiras existentes; pendências e decisões exercitadas só nas bases descartáveis. Prova PostgreSQL e artefactos de resumo acrescentados após conclusão abaixo. Sem bateria geral/revisão visual completa/migração/contas/grants/decisões persistentes; SGF real0.1.1 preservado. Consulta de pagamentos conserva auditoria de acesso. Continuar pelas fases internas ainda não representadas na lista de tarefas (consulta ao mercado, avaliações/adjudicação e execução contratual), sem substituir os motores ou confundir cobertura parcial com produto concluído. O piloto persistente continua dependente de parametrização explícita; não inventar responsáveis, artigos publicados, mínimos ou centros de custo.

Prova PostgreSQL final:83/623 aprovados, base descartável removida. Após limite120s e correcção do pressuposto de ambiente num teste antigo, execução integral aprovada com limite300s; não contar tentativas anteriores como aprovações. Artefactos finance-integration[-pg/-http].json e logs correspondentes. Continuar para consulta ao mercado/adjudicação usando as autoridades existentes.

**02/11/2026 — adjudicação/emissão ligada às tarefas:** PurchaseWorkflow::canDecide é a fonte da etapa final actual, incluindo congelamento por cancelamento pendente e exclusão da manutenção. canIssue partilhado por formulário/lista projecta elegibilidade para conferir a emissão após aprovação, sem prometer base válida ou executar a ordem. O comando revalida matriz/propostas, aprovações, conflitos, regras, datas e orçamento; proposta expirada mantém conferência pendente mas impede emitir. Após emissão real a tarefa desaparece. Catálogo dos perfis explica adjudicação/emissão sem concessão nova. Atribuição expirada sem outro acesso continua a produzir403, não uma lista vazia autorizada.

Quatro testes novos em PostgreSQL descartável (4/217) passaram: selecção real com três propostas/avaliações, três etapas e emissão, cancelamento/rejeição, leitura sem efeito, manutenção/expiração e validade da proposta. Base removida. Tipos/lint/build/análise PHP/18hashes e HTTP dos três perfis existentes passaram;0tarefas locais de Compras/adjudicação em todos. Provas award-task-integration-pg.json, award-task-integration-http.json e logs respectivos; resumo/regressão final abaixo. Sem revisão visual/bateria geral/migração/contas/grants/decisões persistentes/alteração SGF0.1.1. A projecção não cria avisos persistentes da adjudicação. Próxima cobertura interna: tarefas da consulta ao mercado e avaliações, extraindo/reutilizando a autoridade actual antes de acrescentar linhas à lista; depois execução contratual. Não copiar guardas para um segundo workflow nem inventar responsabilidades, prazos ou regras de cliente.

Regressão final aprovada:98/2070 (adjudicação/ordens, tarefas e requisições internas), com expectativa de expiração corrigida e repetição integral. Provas award-task-integration[-pg/-http].json; PostgreSQL4/217, teste isolado1/32. Suites sobrepostas, não somar. Não houve revisão visual completa nem execução da bateria geral.

**02/11/2026 — consulta ao mercado integrada:** QuotationParticipation é autoridade comum a formulário/tarefas/comandos; competências recarregadas sob bloqueio da empresa. Pendências: propostas em falta pelos mínimos preservados, avaliações elegíveis enquanto falta o mínimo qualificado, impedimentos da comparação e conferência do resultado na adjudicação. Não seleccionar/aprovar automaticamente nem reabrir consulta encerrada por adjudicação rejeitada. Proposta exacta por quotation_id, preparação existente por prepare=1; origem validada e história/cache protegidos. Avaliações históricas não são substituídas quando o avaliador perde competência; a comparação reavalia qualificação. Sem prazos/pessoas/minímos inventados.169/2924 na regressão dirigida;11/353 em PostgreSQL descartável. Tipos/lint/build/análise PHP/18hashes/HTTP passaram;0tarefas locais nos três perfis. Provas quotation-task-integration[-pg/-http].json. Sem novas contas/grants/decisões persistentes/bateria geral/revisão visual/alteração SGF0.1.1.

**Diagnóstico antes de activar perfis:** OrganizationActivationPreview na Parametrização compara competências actuais/perfis, preparação implícita, contextos, manutenção, tarefas e administradores. Reutiliza os mesmos resolvedores de OrganizationAccess/WorkContext e o contador de administradores do comando real; consulta consistente sem concessões/activação.6/101 novos,89/1394 regressão dirigida,19/215 PostgreSQL descartável e HTTP8005 passaram. Tipos/lint/build/análise PHP/18hashes conferidos. Provas organization-activation-preview[-pg/-http].json. Suites sobrepostas: não somar.

**Próximo passo concreto sujeito a autorização:** diagnóstico local8005 versão1 tem12contas sintéticas,0perfis/atribuições,0administradores permanentes configurados e alçadas provisórias. Activação directa não é permitida pelos controlos existentes. Proposta pendente em docs/proofs/pilot-access-proposal.json e secção final de desenvolvimento.md: preservar funções/contextos/preparação implícita das12contas,11perfis (6base+5tarefas), manter administradores6/8; tarefas adicionais9requisitar,10autorizar,13entregar,11preparar reposição,12conferir reposição. Confirmar somente no piloto as mesmas alçadas25.000/150.000MZN comIVA, sem alterar valores; preservar IVA16%, processos/histórico/pa_access e SGF. Não criar pessoas reais/contas novas, publicar artigos, definir mínimos ou executar negócio. Substituição da autoridade de acesso requer escolha explícita e auditada (AGENTS.md). Proposta preparada sem aplicação, ensaio exclusivamente descartável em PilotAccessProposalTest; resultados finais anexados abaixo. Antes de aplicar após eventual autorização, conferir novamente a origem/versão e preservar os dados; nenhuma autorização do SGF decorre daqui.

Proposta concreta ensaiada e pronta para decisão:SQLite1/156 ePostgreSQL1/156 aprovados, com os mesmos comandos do produto e sem aplicação local.11perfis/12atribuições, dois administradores existentes e cinco tarefas adicionais, sem perdas ou mudança de âmbito/pa_access/processos. Provas pilot-access-proposal-dry-run.json e pilot-access-proposal-pg.json. A proposta e a activação8005 continuam pendentes de autorização expressa; não confundir a simulação com mudança persistente. Próxima intervenção dependente: confirmar a autorização do proprietário e verificar novamente versão/origem antes de aplicar a distribuição concreta. Outras funcionalidades não ficam declaradas concluídas por este pedido de autorização.

## 02/11/2026 — continuidade da devolução de excedente

Percurso nativo implementado e ensaiado em base própria; ver docs/warehouse-unused-return.md. Manter stock_returns.enabled=false fora da QA e competências warehouse_return_* sem concessões por arrasto. Reutilizar entrega e recepção originais, confirmação independente, escritor único e auditoria; não acrescentar devolução ao formulário genérico nem confundir declaração de excedente com consumo técnico SGF. Provas válidas consolidadas36/544, sem necessidade de repetir suites inalteradas. Consulta conjunta da história51/páginas25 usa3SELECTs centrais; não é ensaio de carga.

Continuam separadas implantação/composição operacional, revisão visual, carga de escrita e eventual regra de previsão líquida. A média histórica actual é por saídas brutas; devolução altera saldo e hash, preservando a convenção. Não reescrever históricos aprovados nem inventar atribuição temporal. Sem lotes/reservas/equipamento/peças/qualidade ou correcção de devolução confirmada neste recorte. Preservar os dados, cache, seis associações, demonstrações e trabalho em curso; não activar piloto/candidatas ou conceder direitos por consequência destes testes.

**02/11/2026 — autorizado e aplicado o piloto de acessos:** proprietário respondeu «autorizo» à proposta exacta para SGC8005. Não voltar a pedir autorização para esta distribuição nem reaplicar o instalador. Proposta original mantém o hash/estado histórico de preparação; autorização e estado efectivo estão em pilot-access-authorization.json e pilot-access-activation.json. Configuração passou de1para27:11perfis/17vínculos em12contas existentes; administradores6/8, tarefas9requisitar/10autorizar/13entregar/11preparar reposição/12conferir reposição. Preservadas competências/contextos/preparação/âmbito anteriores. Mesmas alçadas25.000/150.000MZN comIVA confirmadas só para o piloto; IVA16% e snapshots históricos intactos.

Aplicação atómica por OrganizationConfiguration, sob bloqueio da empresa e revalidação da origem/versão/hash autorizado. Backup privado antes da mudança, snapshot consistente e restauro verificado112tabelas;107tabelas protegidas e demais campos de Tenant preservados, incluindo contas/pa_access/processos/aprovações/orçamento/stock. Restore descartável removido. Prova pilot-access-activation.json e logs correspondentes. Não houve migração/contas novas/decisão operacional/publicação de artigos/mínimos/políticas/regras automáticas ou mudança SGF0.1.1. Perfis sintéticos não são defaults de entrega comercial; a empresa continua a definir os seus próprios intervenientes. Verificação HTTP posterior e pendências reais do piloto são anexadas após conclusão abaixo, sem declarar nova bateria geral ou revisão visual.

**Verificação final da activação8005:** pilot-access-activation-http.json confirmou versão27,12contas,11perfis/17vínculos,2administradores e todos os acessos/contextos anteriores. Cinco perfis abriram os percursos próprios e não obtiveram administração; preparação/conferência da reposição e requisição/revisão/entrega ficaram separados. Tarefas0na situação actual; Pessoas continua separado e acessível à administração no contexto próprio. Só consultas, sem nova operação de negócio/revisão visual/bateria geral.

O piloto ainda não tem artigos publicados (0), políticas internas aprovadas (0) ou regras automáticas activas (0); existe1armazém e os intervenientes independentes estão prontos. Serviço periódico/recuperação recentes e sem pendências. O indicador de configuração de cliente mantémfalse pelo requisito de contexto contratado explicitamente, distinto do âmbito sintético preservado; não acrescentar direitos comerciais por inferência. Próxima etapa: parametrizar catálogo e regras específicas sem inventar quantidades/mínimos ou responsáveis. Manter esta separação entre acesso já autorizado/aplicado e configuração operacional/comercial ainda por concluir.

## 02/11/2026 — testes PostgreSQL e leitura financeira comum

Ao esperar uma violação de trigger em testes PostgreSQL, usar DB::transaction/savepoint para conter a falha antes da asserção seguinte. Não mascarar uma transacção abortada como a recusa funcional pretendida. O modo financial-read-affected do runner SGF exige base QA nova por execução, pois usa RefreshDatabase; não retomar sobre uma base com provas conservadas nem reparar funções/tabelas por arrasto.21 casos/144 asserções de histórico/decisões foram consolidados, preservando o diagnóstico intermédio e seleccionando só os casos aprovados.

A consulta financeira paginada foi ligada ao adaptador SGF, não ao adaptador autónomo SGC. Reutiliza o cálculo/cadeia de decisões existentes com dados de leitura em lote, sem snapshots de consulta nos comandos. Não copiar um segundo saldo ou activar pacotes/acessos no SGC por consequência da prova SGF. Permanecem separados origem histórica viva/cutover, revisão visual e implantação; ver o relatório SGF_PAYABLE_PAGED_READ_DELIVERY.md.
## 02/11/2026 — continuidade das tarefas formais e de fornecimentos

Admissão/recomendação e respostas documentais próprias pendentes integradas nas tarefas com autoridades partilhadas pelos comandos/formulários. Preservar política/quórum adoptados, bases/versões, empresa, departamento, manutenção, conflitos e independência. Não inventar analistas obrigatórios nem repetir respostas alheias; uma avaliação concluída desfavorável não é pendência de preenchimento. Focos exactos conservam a história e não tornam uma tentativa antiga executável.

Fornecimentos/reposição tem categoria própria nas tarefas. Conferência de acordos/políticas/regras exige competência e aprovação independente de todos os preparadores anteriores. Suspensão de regra automática conserva a autoridade original; devolução da política continua possível quando a origem mudou. Formulários apresentam acções por elegibilidade canónica. Foco de ligação antiga mostra a última versão com aviso. Fila completa e paginada, sem corte100; listagem geral de fornecimentos continua limitada100. Consultar não decide nem persiste tarefas num segundo motor. Pessoas e SGF mantêm os seus limites.

Provas aprovadas formal156/2860+PostgreSQL11/383; fornecimentos48/838+PostgreSQL8/262; suites sobrepostas, não somar. Tipos/lint/build/análise PHP/formatação/18hashes e HTTP8005 passaram. Nenhuma nova bateria geral/revisão visual completa/migração/conta/grant/decisão operacional persistente. Provas formal-task-integration[-pg/-http].json e supply-task-integration[-pg/-http].json.

Proposta operacional pendente em pilot-replenishment-proposal.json: artigo fictício existente ART-TEST/ARM-TEST com1cx, publicar catálogo, mínimo1/alvo3/máximo3cx, estimativa artificial10MZN eIVA16%, regra até09/11/2026; requisitante9/OPS1, preparação11, conferência12, publicação13. Simulador exclusivo de cópia restaurada descartável confirmou1rascunho de2cx/23,20MZN, sem duplicação após repetir aprovação e reavaliar duas vezes, sem submissão/aprovações da compra nem movimento. Contas/grants/ordens/aprovações/stock preservados na cópia; contexto sintético reproduzido apenas em runtime. Cópia/base eliminadas; prova pilot-replenishment-dry-run.json vinculada ao hash. O simulador não aplica no piloto.

Solicitar autorização apenas para a aplicação concreta dessa publicação/política/regra e criação do rascunho sintético, conforme exclusão expressa na autorização anterior de acessos (AGENTS.md). Não pedir novamente distribuição dos perfis27. Antes de eventual aplicação, conferir hash, validade, stock livre/movimentos, versão do catálogo e acessos; se houver mudança, rever a proposta sem forçar valores antigos. Não há autorização por inferência para SGF, contexto comercial, aprovação/ordem/entrega ou contas novas. Execução contratual e restantes tarefas especializadas não estão declaradas completas.

## 02/11/2026 — reposição aplicada, tarefas históricas e instalação de comandos

Proposta de reposição foi expressamente autorizada e aplicada em8005. Publicação13/preparação11/conferência12/requisitante9/OPS1,ART-TEST/ARM-TEST,mínimo1/alvo3/máximo3cx,estimativa10MZN/IVA16%,regra até09/11/2026. REQ-2026-000002,id2,rascunho2cx/23,20MZN; stock1cx intacto. Não reaplicar nem reabrir autorização. Artefactos originais pendentes são história; estado efectivo em pilot-replenishment-authorization/activation/activation-http.json. Backup consistente/restauro112tabelas,106tabelas protegidas conferidas; cópia privada preservada,restauro descartável eliminado. Sem contas/grants/aprovação da compra/ordens/SGF.

Histórico de consumo ligado às tarefas com competência própria supply_history_review e autoridade partilhada de SupplyHistory. Conferência independente de todos os preparadores; origem alterada bloqueia aprovação mas permite devolução; confirmação humana de âmbito permanece. Foco record_id valida tipo/empresa e mostra versão actual com aviso. A fila não perde pendências após100; o ecrã geral mantém limite100. Não atribuir histórico ao perfil supply_review por inferência nem criar análises no piloto por consequência dos testes. Provas59/1030 regressão,11/130 diagnóstico,7/193 PostgreSQL; suites sobrepostas,não somar. Tipos/lint/build/análise PHP/Pint/18hashes/HTTP passaram. Sem revisão visual completa ou bateria geral.

Foi detectada e instalada a migração técnica de recibos/versões 2026_11_01_000046_add_requisition_command_versions, que faltava na QA apesar de create_workflow_notices ter prefixo semelhante. Antes da instalação, comprovada na cópia; instalação guardada/atómica com novo backup/restauro112tabelas,110tabelas protegidas e requisições preservadas excepto process_version inicial1. Tabela nova vazia e2triggers,sem submeter/aprovar compra. Prova pilot-command-receipts-installation.json. Diagnóstico agora exige tabela/coluna; HTTP actualwarehouse/replenishment_scenario_ready=true eclient_configuration_complete=false. Não declarar entrega comercial ou outorgar contexto contratado. Não repetir a instalação.

Próximo passo de negócio pendente de autorização específica: submeter apenasREQ-2026-000002 por9,sem mudar2cx/23,20MZN nem aprovar. Proposta pilot-submission-proposal.json; cópia restaurada final em pilot-submission-dry-run.json confirmou encaminhamento ao chefe10, todas as aprovações pendentes, repetição idempotente e preservação de artigos/valores/stock/ordens/acessos. Base/dump temporários removidos. A prova final não precisou instalar migração porque esta já estava na origem; o ensaio anterior de instalação ocorreu antes da aplicação técnica. Não executar submissão por inferência da autorização de publicação/política/regra. Continuar funcionalidades correntes sem pedir confirmação técnica; sugestões de reposição e execução contratual continuam lacunas distintas.

## 02/11/2026 — consulta financeira nativa paginada, somente QA

Entregue NATIVE-PAYABLE-PAGED-READ-SIM-v1: adaptador sobre facturas, linhas, auditorias e pagamentos originais lidos conjuntamente por página; cálculo único no pacote comum, filtros/totais no servidor, factura específica conservada e leitura sem bloqueio de escrita. Tenant, contexto Compras, validade/manutenção e competências revalidados. Comandos usam fontes actuais. Configuração paged_read_enabled=false e pacote instalado preservados; QA usa explicitamente a fonte canónica. Pacote antigo com paginação recusa503. Sem activar piloto8005 ou SGF remoto obrigatório.

Provas:9testes novos/113asserções;26casos distintos afectados/183asserções (25válidos reutilizados e um alvo corrigido),18verificaçõesHTTP,PHPStan7 sem erros. Em10.000facturas: integral122.903,707ms/80.060consultas/62MiB; página25 75,117ms/76consultas/28MiB; página100 91,089ms/76consultas/28MiB. Uma factura de workflow com obrigação e três pagamentos, restantes cópias por reconhecer; não10.000dívidas. Sem índices novos. Leitor terminou antes da libertação do escritor, sem observar auditoria não confirmada. Original30MZN, stock/orçamento e estados preservados. Ver docs/financeiro-consulta-paginada.md e manifesto SGF docs/proofs/native-payable-paged-read-20261102.json.

Preservar provas válidas, seis registos protegidos, cache bloqueada, contas/configuração/piloto e trabalho alheio. Sem novas concessões/migrações/pagamentos/publicação/checkpoint. Revisão visual, pacote/activação, carga sustentada e capacidade de implantação continuam separadas. Os registos anteriores sobre paginação apenas SGF descrevem o estado histórico antes desta integração QA; não significam activação no destino. Eventuais índices exigem comparação separada em cópia sintética, sem aplicação por arrasto.

## 02/11/2026 — submissão aplicada e sugestões ligadas às tarefas

Submissão de REQ-2026-000002 autorizada por «autorizo» e aplicada às19:20:53UTC por9. Estado pending, único responsável da etapa actual10,2cx/23,20MZN preservados, reserva canónica2320cêntimos/compromisso0 e stock1cx. Provas pilot-submission-authorization/activation/activation-http.json; backup/restauro113tabelas e106tabelas protegidas, restantes requisições/orçamentos/âmbitos da fila conferidos. Duas tentativas anteriores reverteram integralmente pelo verificador antes de reconhecer a reserva e sinalização normais da submissão. Não repetir nem reabrir esta autorização. A compra continua sem aprovação, encomenda ou movimento; SGF e contas/grants preservados.

Sugestões manuais agora encaminham conferência independente, conversão por requisitante diferente do conferente e encerramento após rejeição ou recepção completa. Reutilizam SupplySuggestions, dados aprovados e ReceiptWorkflow; não duplicar motores ou conceder competências por arrasto. Foco record_id valida empresa/tipo e apresenta versão actual com aviso. Fila completa/paginada; visão geral ainda limitada100. Aprovação/conversão revalidam fontes; consultar não decide. Não criar sugestões/grants no piloto por consequência dos testes.

Provas novas50/1024na regressão dirigida,3/142PostgreSQL descartável; tipos/lint/build/PHPStan/Pint/18hashes/HTTP passaram. Suites sobrepostas,não somar. Sem nova bateria geral/revisão visual completa/migração. Encerramento novo testado pela rejeição; critério de recepção completa reaproveitado,sem novo percurso completo de recebimento. Artefactos suggestion-task-integration[-pg/-http].json.

Próxima decisão pendente: pilot-approval-proposal.json propõe apenas aprovar a mesma requisição por10, conforme etapa existente, abrindo consulta ao mercado pelo Procurement11. Cópia descartável em pilot-approval-dry-run.json confirmou repetição idempotente, estado approved, tarefa de consulta, reserva2320/compromisso0 e preservação de contas/artigos/valores/stock/ordens. A aprovação da requisição não converte reserva em compromisso; esse pressuposto inicial de teste foi corrigido antes da prova final, sem alterar o motor. Não executar aprovação por inferência da autorização de submissão; não seleccionar fornecedor, adjudicar, encomendar ou entregar. Continuar desenvolvimento/testes correntes sem confirmação técnica, preservando trabalhos de outras sessões.

## 02/11/2026 — aprovação aplicada, alternativas técnicas e cenário de consulta preparado

REQ-2026-000002 aprovada sinteticamente por10 às19:34:34UTC mediante autorização expressa; estado approved,2cx/23,20MZN,reserva2320/compromisso0,stock1cx intacto. Tarefa de consulta no Procurement11. Não reaplicar nem pedir novamente esta autorização. Sem selecção/adjudicação/encomenda ou novas contas/grants/SGF. Provas pilot-approval-authorization/activation/activation-http.json. Uma troca de actor na ferramenta antes do callback pós-commit gerou403 após a decisão estar confirmada; a rotina foi corrigida e o recibo único50990058-e957-4eb2-a5c6-271d3ea63bda foi verificado sem replay. Restauro original113tabelas,107tabelas protegidas e demais requisições conferidos; backup privado preservado e restauro temporário removido. Não confundir falha de verificação pós-commit com decisão revertida. approved_at identifica a decisão; verified_at a conferência posterior.

Alternativas técnicas encaminhadas nas tarefas e formulário pela autoridade partilhada SupplyCoordination. Exige supply_technical_review e independência de todos os preparadores; supply_review não concede essa função. Compatibilidade pendente/origem alterada não são aprovadas silenciosamente; devolução preservada. Validade,sentido,aplicação e especificações continuam no motor. Aprovar análise não substitui artigo,selecciona fornecedor ou movimenta stock. Foco record_id valida empresa/tipo e mostra versão actual com aviso. Fila completa/paginada; listagem geral mantém limite100. Sem concessões ou alternativas persistentes por consequência do desenvolvimento.

Provas55/1012na regressão dirigida e3/110PostgreSQL descartável,mais tipos/lint/build/PHPStan/Pint/18hashes/HTTP. Suites sobrepostas,não somar.0alternativas no piloto; pendências e decisões testadas só em bases descartáveis. Sem revisão visual completa/nova bateria geral. Artefactos alternative-task-integration[-pg/-http].json; preservar trabalho paralelo alheio.

Próximo cenário operacional preparado e ainda não autorizado: pilot-market-proposal.json. A consulta tem apenas1fornecedor elegível e mínimo3propostas já preservado. Propõe2cadastros fictícios adicionais (NUITs de ensaio990000021/990000022,example.test),preparação11/activação12,mais3propostas inteiramente artificiais de2cx,preços10/11/12MZN,IVA16%,totais23,20/25,52/27,84MZN,prazos2/3/4dias,validez09/11/2026. Sem alterar requisição,mínimos ou perfis; sem contactos externos,avaliações,selecção,adjudicação,ordem ou SGF. Não apresentar os identificadores/condições como identidades verificadas ou ofertas reais.

Prova pilot-market-dry-run.json em cópia restaurada passou pelas validações/controladores canónicos,com cadastro anterior e tabelas protegidas intactos,0avaliações e nenhuma selecção/encomenda. Base/dump temporários removidos. O erro inicial de nome de tabela no verificador foi corrigido para a relação de avaliações canónica; só a repetição final é prova aprovada. Pedir autorização para estes novos cadastros e valores fictícios; não os criar por inferência da aprovação da requisição. Desenvolvimento técnico independente continua autorizado; execução contratual e restantes tarefas especializadas não estão declaradas concluídas.

## 02/11/2026 — consulta aplicada, cadastros encaminhados e avaliação preparada

Cenário de consulta expressamente autorizado e aplicado em8005 às19:56:43UTC: dois fornecedores fictícios2/3 preparados11/validados12,existente1 reutilizado,três propostas2/3/4 com totais23,20/25,52/27,84MZN. Avaliações0; sem selecção,ordem ou comunicação externa. Requisição/stock1cx/reserva2320/compromisso0/contas/grants/SGF preservados. Provas pilot-market-authorization/activation/activation-http.json,backup/restauro113tabelas,109tabelas protegidas. Driver comum scripts/support/pilot-market-scenario.php ensaiado após extracção e usado na aplicação,sempre com validações/controladores nativos. Não reaplicar ou pedir novamente autorização. Os cadastros e NUITs são fictícios,não validação fiscal/diligência comercial real.

Cadastros pending agora chegam às tarefas por SupplierParticipation,com Finanças independente do criador/último editor e controlo de versão. Preparação/edição/conferência usam actor actual sob bloqueio da empresa; manutenção não executa e papel revogado após validação não persiste pela instância antiga. Formulário/política/tarefas partilham autoridade. Activação de ficha impedida/vencida continua bloqueada; suspensão permitida pelo percurso anterior. Fichas activas/suspensas não são novas pendências. Não criar atribuições periódicas por inferência. Ficha privada/no-store,história cifrada; DTO sem dados fiscais/contactos/beneficiários/documentos. Fila completa/paginada e foco canónico,sem segundo motor.

Provas94/1276regressão dirigida,1/2actor revogado,1/66ficha privada e5/153PostgreSQL descartável. Primeira prova4/151anterior ao caso adicional; não somar suites sobrepostas. Tipos/lint/build/PHPStan/Pint/18hashes/HTTP passaram. Privacidade da ficha foi confirmada por caso dirigido/HTTP/análise estática após a regressão ampla,sem declarar repetição dessa regressão.0pendências actuais de cadastro,nenhuma nova conta/grant/migração/decisão por consequência do desenvolvimento; sem revisão visual completa/bateria geral. Artefactos supplier-task-integration[-pg/-http].json.

Próxima proposta pendente: pilot-evaluation-proposal.json,seis avaliações fictícias por12e10 das propostas2/3/4,notas neutras5/10 em qualidade/histórico/pagamento. Reutilizar preço,prazo,pesos e mínimo de dois avaliadores já preservados. Cópia restaurada em pilot-evaluation-dry-run.json confirmou seis registos,duplicação recusada,comparação pronta e tarefa de conferência humana,sem seleccionar/adjudicar/encomendar ou alterar contas/cadastros/propostas/stock/orçamento. Base/dump removidos. Corrigido import inicialmente ausente no simulador; só execução final é prova aprovada. Não persistir avaliações por inferência: a autorização de consulta excluiu expressamente avaliar. Continuar desenvolvimento/testes correntes sem confirmação técnica,consolidando restantes percursos em separado.

## 02/11/2026 — tarefas do armazém consolidadas sem executar operações no piloto

Continuação técnica não autorizou as seis avaliações pendentes. Não repetir essa solicitação por cada incremento nem bloquear desenvolvimento independente; nenhuma etapa operacional anterior foi reaplicada. QA mantém três propostas sem avaliações, requisição aprovada23,20MZN e stock1cx, confirmado em warehouse-task-pilot-status-http.json.

Integradas tarefas de conferência/execução de devolução,abate e estorno integral de operação/recepção. Reutilizar InventoryDispositions/InventoryReversals/StockWorkflow; InventoryReviewParticipation partilha só elegibilidade, sem outro workflow/escritor. Decisão independente de todos os preparadores; execução por pessoa diferente do conferente, conservando a eventual execução pelo preparador permitida no motor anterior. Aprovar/consultar não movimenta. Repetição não duplica físico; originais preservados; correcção financeira permanece separada. executionSourceCurrent usa basis nativo: origem/saldo inválido bloqueia confirmação no ecrã, mantém tarefa do operador e encaminha conferente para devolução autorizada, sem decisão automática. O escritor revalida as condições finais.

Foco record_id valida empresa/tipo e mostra última versão com aviso; fila completa/paginada25,além do limite100das visões gerais. Actores/formulário/tarefas usam a mesma autoridade. Respostas privadas/no-store,história cifrada; sem novas competências, nomes, prazos ou campos repetidos da origem.

Lotes: encaminhamento apenas da conferência de configuração/revisão inventory_lot_review. Manter controlo anterior em vigor durante preparação pendente e preservar verificações de saldo/stamp/origem. Activar não movimenta/liberta qualidade nem duplica repartição na revisão. Não foram criadas tarefas de hold/release/identificação ou nova regra de qualidade. Preparações paralelas ultrapassadas por controlo activo não aparecem executáveis; registo histórico permanece. Reprodução inicialmente falhou, correcção aplicada só na elegibilidade segundo previous_setup_id nativo. Visão geral ainda limitada100por consulta,histórico200; foco/fila não significam histórico integral.

Provas consolidadas86/1244na regressão e10/441PostgreSQL de correcções. Filtro final de configuração obsoleta testado depois por6/199SQLite e6/199PostgreSQL, sem declarar repetição dos86após essa pequena mudança. Bases removidas,suites sobrepostas,não somar. Corrigido no teste o pressuposto de comparação de atributos antes de hidratar; originais continuam imutáveis. Tipos/lint/build/PHPStan/Pint/18hashes/HTTP passaram; sem bateria geral/revisão visual completa. Artefactos inventory-task-integration[-pg/-http].json e lot-task-integration[-pg/-http].json.

Somente consultas no piloto8005:0ocorrências/estornos/configurações de lotes,nenhuma nova conta/grant/migração/movimento/avaliação/seleção/ordem/SGF. Administração consulta; armazém conserva execução nativa de correcções,sem outorga adicional de preparação/conferência/lotes. Continuar demais encaminhamentos nativos e consolidação sem inventar regras ou declarar toda a proposta concluída. As avaliações do piloto mantêm autorização pendente própria; preservar trabalhos de outras sessões.

## 02/11/2026 — seis avaliações autorizadas e tarefas de medidas de melhoria

Autorização expressa do proprietário aplicada uma única vez em8005 às21:09:06UTC: seis avaliações fictícias das propostas2/3/4 de REQ-2026-000002,pelas contas existentes12(Finanças)e10(chefe de departamento),com5/10 em qualidade,histórico e pagamento. Registos1a6;comparação pronta e tarefa de conferência humana para Compras11. Sem seleccionar,adjudicar,encomendar ou comunicar externamente. Provas pilot-evaluation-authorization/activation/activation-http.json;proposta original preservada pelo SHA9c6f5004c81030e1ea482e6f5c2c2bf4ed24638886cd9dbe8446e09a2a6f73fa. Backup41c3d932c2d364da30841429267e2ebf3bf4ae79e416eaf54dda8603cb3def7d restaurado e conferido113tabelas,111protegidas;sem mudar contas/grants,stock,compromisso ou SGF. HTTP confirmou seis notas neutras,ausência das tarefas já cumpridas e requisição ainda approved/23,20MZN. Os estados pendentes/zero avaliações nas secções anteriores são históricos; não repetir estas operações.

Integração adicional: medidas de melhoria ligadas a avaliações de qualidade aprovadas passam a alimentar a lista de tarefas de Compras. Execução apenas para o responsável já designado;conferência apenas para pessoa independente de todos os contribuidores. Devolução devolve a pendência ao responsável;encerramento retira-a da lista. Reutilizados prazo,referência,versão,estado,evidência e ligação directa #medida-ID da página nativa,sem criar tabela de tarefas,motor de decisão,novos campos obrigatórios ou novas permissões. A lista percorre todos os pendentes em lotes,sem corte nos100registos;continua a usar paginação existente da caixa de tarefas. A fonte aprovada conserva-se imutável. Este acompanhamento de qualidade é distinto das seis avaliações de propostas autorizadas acima.

SupplierImprovementWorkflow.canAct partilhado por tarefas,página e comandos,com empresa,departamento,funções,conflitos e modo de manutenção revalidados. CanParticipate passou a recusar explicitamente manutenção e âmbito inadequado,também reutilizado nas respostas do fornecedor. Operador dos comandos continua actualizado dentro da transacção. Controller de avaliações passou a exigir utilizador interno autenticado,eliminando ambiguidade com conta de candidato. Sem alterações à sequência de aprovação,delegações ou regras de encerramento.

Validação final:52testes/819verificações aprovados(SupplierImprovement,SupplierEvaluation,SupplierResponse,SupplierImprovementReport,WorkflowTaskInbox),incluindo5cenários de encaminhamento;estes5também passaram isolados em SQLite57verificações e PostgreSQL descartável57verificações,com remoção da base confirmada. Não somar execuções sobrepostas. PHPStan0erros,Pint e18hashes de execução aprovados. HTTP com Compras,Finanças e chefe confirmou consulta cifrada e caixa de tarefas;as2avaliações de qualidade já existentes foram apenas consultadas,sem novas medidas de piloto. Provas supplier-improvement-task-integration-pg/http.json e logs supplier-improvement-task-*. Sem alteração frontend,novo build,bateria geral ou revisão visual completa nesta etapa.

Continuidade: desenvolver os restantes encaminhamentos nativos, incluindo contraditório e avaliações de qualidade em preparação/conferência,sem inferir decisões ou criar dados operacionais. Selecção de fornecedor/adjudicação/encomenda permanecem fora da autorização;isso não bloqueia desenvolvimento técnico independente. Preservar alterações concorrentes de contas a pagar e demais módulos.

## 02/11/2026 — encaminhamento de avaliações de qualidade e contraditório concluído nesta etapa

A pedido do proprietário para executar tarefas que aproximem a conclusão do produto, integrados dois percursos já existentes na caixa de tarefas de Compras: preparação/submissão e conferência das avaliações qualitativas de fornecedores; preparação/submissão e análise independente dos esclarecimentos/contraditórios. Estas avaliações qualitativas não são as seis avaliações das propostas do piloto. Não há criação automática de avaliação,declaração,nota,decisão ou prazo.

SupplierEvaluationWorkflow.canAct e SupplierResponseWorkflow.canAct partilham a elegibilidade entre comandos,detalhe e tarefas: empresa,departamento,função actual,conflitos e independência de todos os contribuidores. Rascunhos/devoluções são encaminhados apenas aos contribuidores ainda elegíveis; isso não restringe a edição colaborativa já admitida no motor. Revisão chega às pessoas elegíveis independentes;devolução devolve a tarefa à preparação;aprovação/conclusão retira-a. Cada tarefa aponta à versão corrente da avaliação ou à âncora nativa #contraditorio-ID,sem copiar argumentos,evidência ou conclusão para a lista. Versão integra a identidade da tarefa,sem tabela de pendências paralela. Fila percorre todos os registos em lotes e conserva paginação25,pesquisa e pendências antigas,com105casos de cada percurso exercitados. Consultas não escrevem auditoria nem decisões;aprovação anterior conserva-se imutável.

Acrescentada relação/âmbito autorizado SupplierResponse.evaluation/visibleTo,reutilizando a visibilidade da avaliação,sem migração. Preparação de avaliação bloqueia manutenção também no servidor;canPrepare alimenta canCreate e oculta o formulário nessas contas. Leitura continua disponível segundo os direitos existentes. Descrição das responsabilidades qualitativas acrescentada ao catálogo dos quatro papéis já admitidos pelo motor,sem concessão adicional. Texto da interface deixou de apresentar esclarecimentos/medidas já implementados como indisponíveis. Sem novos campos obrigatórios,sequência de aprovação ou perfis.

Validação final:76testes/1276verificações aprovados na regressão SupplierEvaluation,SupplierResponse,SupplierImprovement,SupplierImprovementReport,WorkflowTaskInbox e InternalRequisitionCandidate. Onze cenários novos passaram também em PostgreSQL descartável,180verificações,com remoção da base confirmada. Incluem ciclo completo,devolução,preparação colaborativa,segregação,empresa/departamento,conflitos,manutenção/vigência,revogação de função com instância antiga,paginação e imutabilidade. As execuções intermédias61/977,74/1254 e PG9/158 são anteriores e sobrepostas,não somar. PHPStan0erros,Pint,tipos,lint,build e18hashes comuns aprovados;diff dos ficheiros desta etapa sem erros de espaços.

HTTP em8005 confirmou a caixa de tarefas cifrada e a preparação disponível para os papéis operacionais existentes. Não existem actualmente tarefas qualitativas elegíveis nesses três perfis do piloto;por isso os percursos pendentes foram validados nas bases descartáveis,sem inventar novos registos no piloto. Confirmadas as seis avaliações de propostas anteriores e comparação pronta,sem seleccionar/adjudicar/encomendar. Provas supplier-quality-task-integration[-pg/-http].json e logs supplier-quality-task-*. Nenhuma migração,conta/grant,alteração SGF,contacto externo,bateria geral ou revisão visual completa executados nesta etapa.

Pendências de continuidade: encaminhamento de qualidade/identificação/libertação de lotes e execução dos fornecimentos;paginação das consultas gerais ainda limitadas100/históricos200;parametrização das regras opcionais de reservas;instalação comercial do serviço periódico e validações finais de capacidade/recuperação/ecrãs/impressão. Não declarar a aplicação inteira concluída nem confundir funções existentes sem ensaio completo com módulos inexistentes. Preservar alterações concorrentes de contas a pagar e demais módulos. As avaliações operacionais autorizadas já aplicadas não devem ser repetidas.

## 02/11/2026 — acompanhamento de fornecimentos e paginação da coordenação

Executado novo incremento de conclusão funcional a pedido do proprietário: reservas de necessidades e entregas confirmadas passam à caixa de tarefas de Fornecimentos/reposição pelas competências existentes supply_reserve/supply_delivery. A reserva tratada aqui é de planeamento,distinta da reserva física warehouse_reservations das requisições internas. A tarefa encaminha acompanhamento,actualização/cancelamento ou associação de uma saída efectiva já existente;não bloqueia stock físico,não recebe automaticamente,não repete movimentos,não selecciona fornecedor nem emite ordem. Prazo reutiliza needed_on/expected_on sem inferir prioridades ou expiração.

SupplyCoordination.canManage partilhado entre tarefas,página e comandos de coordenação: empresa,competência vigente,manutenção,última versão e estado actual. Tarefa de reserva só enquanto existe necessidade efectiva pendente;tarefa de entrega enquanto falta quantidade perante os recebimentos canónicos. Cancelamento encerra a pendência sem apagar a versão anterior. Estorno de saída torna a necessidade novamente pendente pelo cálculo nativo effectiveApplications,sem reabrir ou alterar o registo fulfilled histórico;uma nova saída autorizada pode satisfazer o saldo. Competência de acompanhamento não concede armazém,recepção ou autorização adicional. DTO de tarefa mínimo,liga ao foco/última versão existente e preserva o histórico,sem tabela paralela ou preenchimento repetido.

As consultas de coordenação alternativas/reservas/entregas deixaram o corte100:paginação25 com total,anterior/seguinte e parâmetro records_page validado. Foco record_id mantém acesso directo à versão actual,independentemente da página;nenhum formulário novo no foco. Fonte de ordem/requisição seleccionada no foco é consultada explicitamente para preservar a edição de origens antigas,sem depender dos últimos100documentos gerais. As listas gerais de escolha de origem/saídas ainda têm limites100;isso não equivale a todos os selectores/históricos paginados. Sem alterar os demais ecrãs de SupplyPlanning nem prometer paginação global concluída. Responsabilidades supply_reserve/supply_delivery descritas no catálogo dos perfis com as permissões existentes;texto da interface clarifica planeamento vs reserva física.

Validação final52testes/898verificações aprovados em SupplyCoordination,InventoryReversals,SupplyPlanning e WorkflowTaskInbox. Seis cenários de coordenação passaram também em PostgreSQL descartável107verificações,com base removida. Exercitados satisfação parcial/integral por saídas,recepção parcial/integral,cancelamento idempotente,estorno e nova satisfação,empresa,tipo de foco,manutenção/vigência,105pendências,paginação da caixa e consulta,foco antigo,consulta sem auditoria/movimento e preservação histórica. A primeira preparação dos105registos de teste omitia created_at ao replicar um modelo sem timestamps automáticos;corrigida apenas a fixture e reexecutadas as provas finais. A falha não corresponde a operação no piloto. PHPStan0erros,Pint,tipos,lint,build,diff e18hashes comuns aprovados. Não somar execuções intermédias ou os testes PG sobrepostos à regressão.

HTTP8005:administraçao consulta as três páginas com paginação,sem preparação operacional;armazém/Compras/Finanças sem competências específicas receberam403,conforme configuração actual preservada. Nenhuma tarefa nova de coordenação pendente nesses perfis:cenários operacionais exercitados só nas bases descartáveis. Não criar grants,previsões,reservas,recepções ou movimentos no piloto para forçar demonstração. Provas coordination-task-integration[-pg/-http].json e logs coordination-task-*. Sem migração,conta nova,contacto externo,alteração SGF,decisão comercial,bateria geral ou revisão visual completa.

Próximas lacunas:encaminhamento de identificação/retenção/libertação de lotes,paginação das restantes consultas gerais e selectores,instalação comercial resiliente do serviço periódico e validação final de capacidade/recuperação/ecrãs/impressão. Acompanhamento de acordos,execução contratual,importações e cobertura integral dos documentos base devem continuar confrontados com o código,sem declarar todos concluídos por esta integração. Preservar mudanças concorrentes de contas a pagar e demais módulos. As autorizações e avaliações de propostas anteriores continuam efectivas e não devem ser repetidas.


## Ciclo contabilistico comum sintetico - entrega autorizada

Adaptador SGC e interface comum implementados: reconhecimento60, afectacao20/saldo40, contabilizacao, reversao/saldo60, par correctivo imutavel e fecho QA. Demo proprio http://127.0.0.1:8051/qa/ledger-demo com tres funcoes e base nova, sem efeitos de negocio iniciais. Ver docs/contabilidade-ciclo-sintetico.md e relatorio conjunto SGF. Provas nativas:23 controlos de contrato revertidos,61HTTP,10finais e28de preparacao; fontes/stock/orcamento externos preservados. Concessoes apenas QA, destino desactivado, sem alterar piloto8005 ou candidatas. Revisao visual, carga de implantacao, uso/fiscalidade reais e aceitacao separados; sem publicacao/checkpoint presumidos.


## Composicao autonoma do nucleo financeiro - QA

Artefacto com25ficheiros de runtime, manifesto SHA256 fixado e verificacao antes do arranque, sem fallback quando alterado. FinanceBundle.configure e opt-in apenas em base/role nao elevada do cluster55439; sem root conserva composicao anterior e nao activa direitos/contabilidade. Demo nova8052, sem substituir8051/8005 ou pacote instalado. Provas:9contrato/escrita/replay,6integridade,4recusas no arranque e28preparacao do demo; PHPStan0erros nos2ficheiros novos. Ver SGF docs/COMMON_FINANCE_BUNDLE_DELIVERY.md. Sem dados/credenciais no artefacto, migracao no destino, publicacao ou checkpoint.

## 02/11/2026 — encaminhamento da identificação e qualidade dos lotes

Implementado acompanhamento na caixa de tarefas de Armazém sobre as configurações activas e o contexto canónico InventoryLots: identificação pendente para inventory_lot_prepare; conferência de lote retido elegível para inventory_lot_release independente dos contribuidores; conferência de retenção para inventory_lot_hold quando uma libertação anterior existe mas a validade actual é insuficiente. Não são atribuídas retenções a todos os lotes libertados saudáveis nem inventados prazos,prioridades,novos perfis ou decisões. O vencimento é lido pela data actual sem exigir movimento físico;criar/consultar tarefa não grava decisão nem aviso persistente.

canIdentify/canDecideLot partilham elegibilidade entre comandos nativos,interface e tarefas: empresa,competência vigente,manutenção,versão de identificação,saldo repartido conferido,quantidade positiva e independência/validade para libertar. Mantidas verificações finais de versão e state_version no comando sob bloqueio da empresa. Identificação de lote sem saldo continua possível no motor quando já era permitida;apenas não gera tarefa. A identificação corrigida invalida a libertação anterior conforme o motor existente,sem alterar a decisão histórica. A dispensa de quarentena na recepção continua dependente da configuração aprovada existente;as novas tarefas não impõem nova aprovação nesse percurso.

Novas ligações de foco lot_id+warehouse_id validam identidade inicial do lote,empresa,armazém,configuração activa e presença nesse local;abrem a identificação mais recente e a âncora estável lot-ARMAZEM-ID,mesmo com link antigo ou mais100pendências. Não misturar esse foco com record_id de configuração. Tipo numérico do identificador normalizado na resposta. Ligações antigas de configuração permanecem válidas;regra de exclusão corrigida para Rule::prohibitedIf suportada na versão instalada. Interface usa acções por lote da mesma autoridade;permite a retenção explícita de uma libertação já expirada,sem restaurar a disponibilidade pelo simples acesso. Descrições das tarefas de identificação,libertação e retenção acrescentadas aos perfis existentes,sem grants.

Validação funcional abrange identificação→conferência→libertação,contribuidores de recepção,expiração sem movimento e retenção explícita,correcção posterior/versão antiga,empresa e par de foco/manutenção/vigência,saldo não reconciliado,105lotes em100partições iniciais+5de recepção nativa,paginação da caixa,política aprovada de recepção e lotes sem saldo. O saldo não reconciliado é injectado na leitura no teste:os triggers recusaram correctamente a tentativa inicial de preparar uma repartição impossível,não foram desactivados ou contornados. Expectativas antigas passam a reconhecer tarefas distintas de conferência da configuração e qualidade do saldo activo,sem alterar o estado ou a aprovação do processo. A evidência final desta execução é registada a seguir após a conclusão da regressão.

No piloto8005 apenas consultas:administração continua só de leitura e os outros perfis sem competências específicas continuam403;nenhum lote/configuração/grant/decisão/movimento criado para demonstração. Prova HTTP lot-quality-task-integration-http.json. As validações operacionais permanecem nas bases descartáveis. Listagens gerais de configurações/histórico de lotes ainda conservam os limites anteriores100/200;foco e caixa paginada não equivalem a paginação integral desses históricos. Sem alteração SGF,selecção,adjudicação,encomenda ou contactos externos.

### Evidência final — qualidade de lotes, 02/11/2026

Regressão final aprovada:99testes/1578verificações em InventoryLots,InventoryLotPolicy,InventoryReversals,InventoryDispositions,WarehouseFulfilment e WorkflowTaskInbox. Oito cenários específicos passaram em PostgreSQL descartável106verificações,com remoção da base confirmada. Execuções intermédias falhadas e o ensaio8/105 são anteriores/não somar. Foram corrigidos o tipo numérico do foco,a regra de validação das ligações e as expectativas dos testes de configuração,que agora reconhecem também a tarefa separada de libertação do saldo existente. Nenhuma falha de teste foi apresentada como decisão operacional aplicada. O cenário de leitura não reconciliada injecta a condição no teste e conserva os triggers físicos efectivos.

Tipos,lint,build,Pint,PHPStan0erros,diff e18hashes comuns aprovados. O primeiro controlo de tipos detectou a âncora a usar warehouse_id fora de data;corrigido para a origem já usada na página e repetidos tipos/build. Provas lot-quality-task-integration[-pg/-http].json e logs lot-quality-task-*. Consulta HTTP com quatro perfis confirmou acesso de leitura administrativo,recusas operacionais sem competência e ausência de novas tarefas/lotes no piloto. As ligações e decisões com pendências foram testadas nas bases descartáveis. Não equivale a revisão visual completa,teste de carga,bateria geral de todos os módulos,aceitação real ou instalação SGF.

Próxima continuidade técnica:paginar as consultas gerais de configurações/histórico de lotes e as restantes consultas/seletores ainda limitados;consolidar o arranque e recuperação do serviço periódico para instalação comercial;confrontar a cobertura de acordos/importações/execução contratual com os documentos base;validar capacidade,recuperação,relatórios,impressões e percursos por perfil. As tarefas de identificação/libertação/retenção aqui descritas deixaram de ser uma lacuna de encaminhamento. Não criar automaticamente concessões ou decisões no piloto para as tornar visíveis. Preservar aprovações vigentes,os percursos distintos de Compras/Pessoas e alterações concorrentes. O desenvolvimento e a integração interna mantêm autorização;novas decisões operacionais continuam a exigir o seu âmbito próprio.

## 03/11/2026 — consultas de lotes paginadas, sem separar controlo activo da revisão

Retirados os limites fixos100configurações/200registos históricos da página /stock/lotes. As configurações paginam25identidades de controlo por página;para cada identidade são carregadas a última versão e a configuração activa. Assim a revisão pendente e o controlo em vigor não se separam na fronteira da página. A contagem corresponde a controlos, podendo existir até duas versões visíveis por controlo. O foco de configuração/lote mantém acesso directo sem paginação de controlos. A lista de lotes de cada contexto continua integral nesse detalhe,não é um paginador individual por lote.

Histórico paginado50registos,com total e navegação anterior/seguinte. controls_page/history_page independentes,validados e conservados nas ligações, juntamente com o foco. A segunda página do histórico abre o respectivo detalhe automaticamente. O histórico mantém o âmbito empresarial autorizado anterior;esta etapa não acrescenta pesquisa,filtros ou exportação. A leitura da página passou a transacção coerente e somente de leitura em PostgreSQL,sem bloqueio de escritor nem auditoria/movimento gerados em GET.

Validação final51testes/821verificações aprovados em InventoryLots,InventoryLotPolicy e WorkflowTaskInbox. Os três cenários novos passaram também em PostgreSQL descartável98verificações,com base removida. Cobrem210controlos/registos de histórico,alcance das páginas antigas,preservação de parâmetros,foco directo,par activo+revisão na fronteira,empresa,páginas inválidas e leitura sem alteração de dados. A expectativa antiga100registos foi ajustada para25por página com105no total e acesso à quinta página. Tipos,lint,build,Pint,PHPStan0erros,diff e18hashes comuns aprovados. Provas lot-pagination[-pg/-http].json e logs lot-pagination-*. HTTP confirmou paginação vazia administrativa e recusas403 dos perfis sem competências;nenhum novo dado/grant no piloto.

A regressão99/1578 e PG8/106 da etapa de qualidade imediatamente anterior continuam evidência própria dessa etapa,antes desta paginação;os51/821são a regressão final posterior da leitura alterada. Não somar provas sobrepostas nem declarar nova bateria integral dos módulos. Sem migração,aprovação de negócio,selecção,ordem,alteração SGF,contacto externo ou revisão visual completa.

Continuar pelos restantes selectores/consultas gerais ainda limitados,preparação comercial do serviço periódico e recuperação,confronto da execução contratual/acordos/importações com os documentos base e validação final de capacidade,relatórios,impressões e percursos. As consultas gerais de configurações/histórico de lotes e o encaminhamento de qualidade deixaram de estar pendentes. Preservar aprovações e separação dos módulos;novas competências ou decisões do piloto não são concedidas por inferência.

## 03/11/2026 — paginação de fornecimentos e preservação das origens escolhidas

Retirado o corte fixo100 das consultas de acordos,políticas/calendário,análises de consumo,sugestões e processos de importação. RecordPage partilhado apresenta25identidades/últimas versões,contagem,navegação anterior/seguinte e records_page validado. Record_id conserva foco directo na última versão,sem depender da página,nem reintroduzir dados das origens. Componente de paginação partilhado nas três páginas de fornecimentos,sem novo motor de tarefas ou permissões. Consultas de coordenação,que já tinham paginação,mantêm o percurso próprio existente. A página de fornecimentos passou a leitura coerente,somente de leitura em PostgreSQL;projecções e contagens usam o mesmo estado sem bloquear operações de stock.

As opções aprovadas de análise histórica/política passam a incluir as origens já usadas pelos registos visíveis,mesmo quando ficaram fora das100escolhas recentes. Só a última versão ainda aprovada é oferecida;uma suspensão remove a escolha e conserva a referência histórica no documento anterior. Nenhum GET altera snapshots,notas,pesos,aprovações,compras ou razão de stock. As100escolhas recentes continuam uma janela de apresentação,não uma promessa de selectores todos paginados. Acordos e catálogos ainda mantêm as capacidades/listas existentes. Não declarar toda a parametrização/escolha de origens concluída por esta etapa.

Preparação de importações ganhou pesquisa opcional da ordem pelo número ou parte do número,aplicada antes da janela100,com parâmetros de pesquisa vinculados e comparação sem distinguir maiúsculas. Mantém no conjunto a ordem actualmente seleccionada/as ordens dos processos visíveis. Só quem já pode preparar recebe as opções;selected_order_id é validado por empresa e os leitores não recebem o selector. A pesquisa actualiza apenas orders/orderSearch via Inertia,preserva dados do formulário,página de registos e posição;Enter na pesquisa não submete o processo. Continua a usar a ordem canónica e o comando nativo de importação,que impede duplicação e exige registo antes da primeira recepção.

Os testes incluem105registos por vista,quinta página/foco antigo,isolamento,páginas inválidas,vigência/manutenção,versões de importação,origens aprovadas fora da janela recente,retirada da opção quando suspensa,referências imutáveis,pesquisa/sem resultados/ordem seleccionada,entradas com apóstrofo,comprimento e empresa/leitura sem preparação. A primeira fixture de importação já tinha recepção completa e foi correctamente recusada pelo motor;substituída por uma fixture nova sem recepção,não se enfraqueceu essa regra. As expectativas antigas100registos passaram a25por página e contagens totais. Os resultados finais desta execução são registados após a conclusão das verificações.

Piloto8005 apenas consultado nos perfis existentes,sem grants,cadastros,importação,aprovação,selecção,ordem ou movimento novo. RootAGENTS recebeu noutro trabalho autorização do ciclo contabilístico sintético em8051;esse âmbito paralelo é preservado e não alterado por esta etapa,assim como o SGF real. Prova HTTP supply-pagination-http.json cobre as cinco vistas e acessos actuais;os cenários com volume e decisões de teste só nas bases descartáveis. Sem revisão visual completa,teste de carga ou nova execução geral de todos os módulos.

### Evidência final — consultas de fornecimentos e pesquisa de encomendas, 03/11/2026

Regressão final73testes/1378verificações aprovada em SupplyPagination,SupplyPlanning,SupplyHistory,SupplySuggestions,SupplyCoordination e SupplyTaskIntegration. Catorze cenários dirigidos passaram também em PostgreSQL descartável356verificações,com remoção da base confirmada. Incluem a suspensão posterior das origens:deixam de ser oferecidas para reutilização,mas os documentos preservam o identificador e os dados anteriores. As fases70/69aprovados,72/1329 e PG13/280ou307 são anteriores/sobrepostas,não somar nem declarar bateria geral. O único erro da preparação inicial de importação resultou de fixture já recebida;foi corrigida a fixture sem alterar a exigência nativa.

Pint,PHPStan0erros,lint,tipos,build,diff e18hashes comuns aprovados. O artefacto compilado confirmou que a pesquisa conserva records_page. HTTP com administração,Compras e Finanças confirmou as cinco vistas/paginação conforme os acessos actuais e que a pesquisa não concede opções de preparação ao leitor. Provas supply-pagination[-pg/-http].json e logs supply-pagination-*. As escolhas de processos antigos e os dados em volume foram ensaiados nas bases descartáveis. Nenhuma decisão/grant/cadastro/stock/SGF alterado por estes comandos de desenvolvimento;sem nova revisão visual completa,teste de carga ou aceitação real.

Próxima continuidade:demais selectores ainda limitados (por exemplo saídas efectivas para afectação de necessidades e novas escolhas de análises/políticas sem referência anterior),restantes consultas de ocorrências/estornos,preparação comercial do serviço periódico com recuperação e verificações de capacidade/relatórios/impressões. Confrontar acordos/importações/execução contratual com os documentos base antes de declarar a aplicação completa. A paginação principal de acordos,calendário,histórico,sugestões e importações e a pesquisa de ordens para importação deixaram de estar pendentes. Manter as decisões já autorizadas;não criar novas competências ou decisões no piloto por inferência. Preservar trabalhos paralelos,em particular o ciclo contabilístico autónomo e contas a pagar.

## 03/11/2026 — consultas de ocorrências e estornos consolidadas

Retirado o corte100processos em /stock/ocorrencias e /stock/estornos. InventoryCorrectionPage é uma projecção de leitura partilhada,sem novo motor ou permissões;os controladores mantêm a autoridade nativa e os comandos anteriores. Paginação25,contagem e filtros opcionais por referência/estado sobre as últimas versões. Pesquisa sem distinção de maiúsculas,parâmetros validados e conservados nas ligações. O foco directo ignora os filtros para apresentar a versão actual e o histórico integral desse processo,com as acções nativas de conferência/devolução/execução. Páginas em transacção coerente somente de leitura PostgreSQL,privadas e com história cifrada. Mantido o redireccionamento anterior para estornos quando só esse módulo está autorizado.

Componentes de paginação e filtros reutilizados;filtros recolhidos quando não usados,sem novos campos de negócio obrigatórios. As escolhas de recepções e operações passam a conservar as origens já seleccionadas dos processos visíveis,mesmo fora das200recentes. Origens efectivamente estornadas são excluídas antes de aplicar a janela de escolhas e não são reintroduzidas por estarem num documento anterior. Referências,snapshots,aceitação original e documentos continuam imutáveis;as quantidades e a execução dependem das verificações nativas actuais. A janela200de novas escolhas permanece;isto não constitui pesquisa/paginação universal de todas as origens.

Validação final55testes/1085verificações aprovados:InventoryCorrectionPagination,InventoryDispositions,InventoryReversals e WorkflowTaskInbox. Dez cenários específicos também aprovados em PostgreSQL descartável251verificações,com remoção da base confirmada. Cobertura:210processos por percurso,páginas antigas,filtros apenas sobre versão actual,foco antigo/histórico/acções independentes,empresa/tipo/páginas inválidas/manutenção/vigência,recepção e operação escolhidas fora das200recentes,estorno nativo e exclusão posterior das escolhas,consulta sem alterar stock,orçamento,auditoria ou decisões. As origens de volume foram criadas pelos comandos nativos em bases de teste;as correcções de teste usaram preparação,aprovação e execução independentes. Não somar provas sobrepostas nem declarar bateria geral.

Pint,PHPStan0erros,tipos,lint,build,diff e18hashes comuns aprovados. Provas inventory-pagination[-pg/-http].json e logs inventory-pagination-*. HTTP8005 confirmou administração em leitura,armazém com execução anterior sem preparação/conferência nova,Compras/Finanças sem essas competências403,paginação/filtros vazios e validação dos parâmetros. Nenhuma concessão,ocorrência,estorno ou movimento novo no piloto,nem alteração SGF/8051,contacto externo ou decisão comercial. Sem revisão visual completa ou teste de carga;preservadas alterações paralelas de contabilidade e contas a pagar.

Continuar pelos restantes selectores de origens ainda limitados,instalação comercial/recuperação do serviço periódico e validação de capacidade,relatórios,impressão e percursos por perfil. Consultas gerais de ocorrências/estornos deixam de ser uma lacuna de paginação;aprovações existentes não foram substituídas. Não reaplicar decisões ou autorizações anteriores nem declarar a aplicação inteira concluída por este incremento.
03/11/2026 — Consulta contabilística comum de ensaio concluída no âmbito de `docs/relatorios-contabilisticos-ensaio.md`: balancete e razão, sem novos efeitos ou direitos. Usar o núcleo canónico ou o artefacto QA novo de30 ficheiros; não substituir/activar o pacote congelado do destino ou8052. Preservar avaliações/autorização do piloto e trabalho paralelo. Revisão visual/carga sustentada/implantação e contabilização de stock/custos/salários continuam separadas.


## 03/11/2026 — autoridade das consultas partilhadas de correcções

InventoryCorrectionPage passou a obter o utilizador actual da base,confirmar a empresa e reutilizar as competências nativas dos módulos também nas chamadas internas. Consulta de processos exige uma capacidade de leitura/preparação/conferência/execução do percurso;escolhas de recepções exigem preparação de ocorrências ou estornos;escolhas de operações exigem preparação de estornos. A permissão de consulta não passa a conceder preparação. Revogação/vigência/manutenção são reavaliadas mesmo com uma instância de utilizador anteriormente carregada. Não se alteraram perfis,sequências,alçadas ou comandos de aprovação/execução.

Acrescentados quatro testes específicos de acesso para listas de origens e processos,com manutenção,expiração,leitor sem preparação e auditoria sem alterações. Regressão também cobre os cenários de paginação e correcções nativas anteriores. PHPStan sem erros e HTTP do piloto confirmado sem novos acessos ou decisões. Os resultados finais dos testes são registados após conclusão. Trabalho limitado à integração interna SGC;preservados SGF e o ciclo contabilístico paralelo.

Validação final desta etapa:14testes/263verificações aprovados em InventoryCorrectionAccess e InventoryCorrectionPagination;PHPStan0erros,Pint,diff e HTTP do piloto aprovados. Não houve alteração frontend,nova execução PostgreSQL,bateria geral ou revisão visual nesta etapa. Provas nos logs inventory-access-tests.txt/inventory-access-phpstan.txt e inventory-pagination-http.json;resultados PostgreSQL anteriores não são nova execução desta alteração.

## 03/11/2026 — pesquisa de saídas efectivas para necessidades planeadas

Acrescentada pesquisa opcional por referência na acção de associar saída de uma reserva de planeamento. A pesquisa filtra antes da janela100 e vincula-se à identidade da necessidade,artigo e armazém;identidades de necessidade e saída validadas por empresa/tipo. O servidor usa a última versão e a elegibilidade nativa canManage(fulfil),recusando necessidades encerradas/canceladas ou sem competência. Leitores não recebem operações de preparação. Saídas estornadas ficam excluídas mesmo quando selected_issue_id tenta conservá-las;origens de outro artigo/local também não entram no conjunto. Sem campos de negócio novos ou nova concessão de tarefas.

GET parcial actualiza operações,referência pesquisada e identidade de destino,preservando página,posicionamento,quantidade,justificação e selecção elegível. Enter no campo de pesquisa não submete a associação. Cada formulário mantém as próprias opções em memória,para uma pesquisa numa necessidade não apagar as escolhas de outra que esteja aberta. A saída escolhida fora dos resultados continua disponível apenas se pertence ao âmbito elegível. Continua a haver uma janela100 por pesquisa,sem alegar paginação universal do razão. Fonte e quantidade são novamente verificadas pelo comando nativo;associar não lança outra saída,não cria factura ou compra,não altera aprovações nem substitui a reserva física do armazém.

Validação final54testes/971verificações aprovados em SupplyCoordination,InventoryReversals,SupplyPlanning e WorkflowTaskInbox. Três cenários dirigidos passaram também em PostgreSQL descartável85verificações,base removida. Incluem saída com100movimentos posteriores,pesquisa sem distinguir maiúsculas,selecção sem resultados,reutilização sem duplicar movimento,artigo/armazém,estado corrente,leitor sem preparação,empresa,comprimento do filtro e saída estornada que não reaparece pela selecção. A regressão conserva os percursos nativos de correcção,necessidades e tarefas. Pint,PHPStan0erros,tipos,lint,build,diff e18hashes comuns aprovados.

HTTP8005 confirmou administração em leitura sem opções operacionais,recusas403 dos perfis sem acesso específico e validação do vínculo da pesquisa. Os casos positivos foram executados nas bases descartáveis;nenhum grant,reserva,associação,saída ou decisão novo no piloto. Provas reservation-source[-pg/-http].json e logs reservation-source-*. Sem migração,contactos externos,alteração SGF/8051,bateria geral ou revisão visual completa. Não somar execuções sobrepostas à regressão54.

Continuidade:restantes selectores de novas origens históricas/políticas e de recepções/operações,instalação comercial e recuperação do serviço periódico,verificações de capacidade,relatórios/impressões e cobertura dos percursos documentados. A pesquisa de saídas para associação à necessidade deixa de ser uma lacuna. Preservar os motores e aprovações existentes e os trabalhos paralelos de contabilidade/contas a pagar;novas decisões operacionais do piloto permanecem sujeitas ao respectivo âmbito de autorização.

## 03/11/2026 — pesquisa de análises aprovadas para políticas históricas

A preparação de políticas com previsão histórica ganhou pesquisa opcional por período,usando o artigo,armazém e finalidade já escolhidos. O filtro aplica-se antes da janela100 de origens recentes,permitindo localizar uma análise antiga por datas. Fontes limitadas às últimas versões aprovadas e à empresa;identidades,âmbito,datas e ordem dos limites são validados no servidor. A origem seleccionada continua incluída fora do período pesquisado apenas quando ainda aprovada e do mesmo âmbito. Suspensão exclui-a sem alterar a referência histórica dos documentos existentes.

GET parcial actualiza só as opções e a identidade do formulário,conservando dados,página e posição. Cada preparação/cópia mantém as próprias opções para uma pesquisa não apagar as escolhas de outra. Enter nos campos de pesquisa não submete a política. Não há novos campos de negócio obrigatórios,nem alteração da aprovação de análises/políticas. Qualidade,padrão,cobertura,assinatura do razão,actualidade e suspensão continuam a ser conferidos pelo motor nativo ao reutilizar a origem;encontrar uma opção não aprova a política nem altera a previsão de um documento já aprovado.

Validação final53testes/1011verificações aprovados em SupplyHistory,SupplyPlanning,SupplySuggestions e SupplyPagination. Dois cenários específicos passaram também em PostgreSQL descartável62verificações,base removida. Cobertura:período fora das100escolhas recentes,selecção preservada,finalidade diferente,suspensão,empresa,âmbito incompleto,datas invertidas e leitor sem preparação,sem auditoria ou movimento gerado pela consulta. Tipos,lint,build,Pint,PHPStan0erros,diff e18hashes comuns aprovados. Provas history-source[-pg/-http].json e logs history-source-*. Não somar execuções sobrepostas nem declarar bateria geral.

HTTP8005 confirmou pesquisa vinculada ao âmbito existente,preparação conforme o perfil e ausência de opções para quem só confere/consulta. Nenhuma análise,política,grant,decisão,stock,SGF ou ciclo contabilístico8051 alterado no piloto. Os casos positivos com períodos aprovados foram executados só em bases descartáveis. Sem revisão visual completa ou teste de carga. A janela100 de resultados por pesquisa permanece;isto não equivale a paginação universal de todos os selectores.

Continuar pelos restantes selectores de políticas e origens de correcções,preparação comercial/recuperação do serviço periódico e validação de capacidade,relatórios,impressões e percursos. Preservar motores,aprovações,perfis e trabalhos paralelos;novas decisões operacionais não são concedidas por inferência. A pesquisa de análises históricas para políticas deixa de ser uma lacuna de acesso às origens antigas.

## 03/11/2026 — pesquisa das políticas aprovadas para sugestões

Preparação de sugestões ganhou pesquisa opcional por código/descrição do artigo e nome do armazém registados no snapshot aprovado. Filtragem sem distinguir maiúsculas,antes da janela100;seleccionados elegíveis mantidos fora dos resultados,sem reintroduzir política suspensa ou de outra empresa. selected_policy_key validado por empresa/tipo,consulta de origens apenas para supply_suggest_prepare. Leitores/conferentes não recebem escolhas de preparação. A pesquisa não selecciona fornecedor,aprova política ou gera compra.

GET parcial actualiza só opções/texto/correlação do formulário,preservando página,posição,selecção e dados introduzidos. Cada preparação mantém as próprias opções para evitar interferência entre formulários;Enter na pesquisa não submete a sugestão. Origens aprovadas continuam sujeitas à basis nativa,à qualidade do histórico,à vigência,preço,tributação e revisão independente. Sem novos campos de negócio obrigatórios,sem alterar perfis,motores ou snapshots existentes. Janela100 de resultados por pesquisa permanece,não se declara paginação universal dos selectores.

Validação final55testes/1077verificações aprovados em SupplySuggestions,SupplyHistory,SupplyPlanning e SupplyPagination. Dois cenários dirigidos em PostgreSQL descartável66verificações,base removida. Incluem política antiga fora das100recentes,caso sem resultados,selecção preservada,suspensão,empresa,comprimento/entrada com apóstrofo e conferente sem preparação;consultas sem auditoria,stock ou requisição novos e documento aprovado imutável. Fonte de volume construída com100políticas de artigos distintos pelos comandos nativos nas bases de teste. Pint,PHPStan0erros,tipos,lint,build,diff e18hashes comuns aprovados.

HTTP8005 confirmou administração em leitura sem escolhas de preparação e recusas dos perfis sem acesso específico;cenários positivos só nas bases descartáveis. Provas policy-source[-pg/-http].json e logs policy-source-*. Sem grants,contas,sugestões,compras,movimentos ou decisões novos no piloto;SGF e demo contabilística8051 preservados. Sem nova bateria geral,revisão visual completa ou teste de carga. Não somar provas sobrepostas.

Continuar pelas novas escolhas de recepções/operações nos percursos de correcção e restantes origens ainda limitadas,instalação comercial/recuperação do serviço periódico,capacidade,relatórios,impressões e cobertura dos documentos base. A pesquisa das políticas para sugestões deixa de ser uma lacuna de acesso a origens antigas. Preservar aprovações e autorizações anteriores e alterações paralelas,não declarar a aplicação inteira concluída por este incremento.

## 03/11/2026 — pesquisa de novas origens de ocorrências e estornos

Formulários de preparação passaram a procurar recepções pelo número e operações pela referência. Filtro sem distinguir maiúsculas aplicado antes da janela200;mantém fontes elegíveis já seleccionadas e fontes dos processos visíveis. Operações/linhas estornadas,tipos sem correcção física ou fontes de outra empresa não são reintroduzidos pela selecção. Direitos de preparação verificados pelo serviço nativo existente,com utilizador actual;leitores continuam sem opções. Parâmetros e identidades validados por empresa.

Componente de pesquisa partilhado,opcional e recolhido,sem campos de negócio obrigatórios novos. GET parcial conserva dados,selecção elegível,página,filtros de processos e posição. Cada formulário mantém as suas opções para não interferir com outra preparação aberta. Enter não submete uma correcção. Seleccionar recepção continua a reutilizar artigo/armazém da origem;quantidades,saldo,unidades,lotes,independência e versão continuam a ser verificados nos comandos nativos. Nenhuma aprovação,saída ou correcção financeira executada pela pesquisa. Janela200por pesquisa continua;isto não é paginação universal das fontes.

Validação final60testes/1158verificações aprovados em InventoryCorrectionPagination,InventoryCorrectionAccess,InventoryDispositions,InventoryReversals e WorkflowTaskInbox. Três cenários dirigidos em PostgreSQL descartável98verificações,base removida. Cobrem origens com200registos posteriores,pesquisa directa no serviço sem seleccionados,selecção preservada,estorno nativo e exclusão posterior,empresa,comprimento/entrada com apóstrofo e leitura sem preparação;sem mutações durante consulta,sem reescrever a recepção ou operação original. Pint,PHPStan0erros,tipos,lint,build,diff e18hashes comuns aprovados. Mantidos no runner os tempos dos modos anteriores de coordenação e qualidade de lotes.

HTTP8005 confirmou os perfis existentes e ausência de novas escolhas operacionais para administração/armazém sem preparação;Compras/Finanças sem acesso específico403. Cenários positivos e decisões de correcção apenas em bases descartáveis. Provas correction-source[-pg/-http].json e logs correction-source-*. Sem grants,contas,correcções ou movimentos novos no piloto,sem alteração SGF/8051,contactos externos,bateria geral ou revisão visual completa. Não somar provas sobrepostas aos60testes.

Continuar pelos restantes selectores de encomendas/requisições de fornecimentos,preparação comercial/recuperação do serviço periódico,capacidade,relatórios,impressões e cobertura integral dos documentos base. A pesquisa de novas recepções/operações para correcções deixa de ser uma lacuna de acesso às fontes antigas. Preservar autorizações existentes e trabalhos paralelos,não declarar a aplicação inteira concluída por este incremento.

## 03/11/2026 — origens antigas no acompanhamento de fornecimentos

A preparação de reservas planeadas e confirmações de entrega permite procurar, pelo número, requisições aprovadas e encomendas emitidas antes da janela das 100 mais recentes. Mantém as linhas elegíveis já seleccionadas e as origens dos registos visíveis. Uma selecção explícita não reintroduz requisições em rascunho, encomendas não emitidas ou dados de outra empresa. A linha continua a fornecer os dados canónicos, sem repetir cadastros ou alterar aprovações.

Pesquisa opcional e recolhida, reutilizando o componente comum. Respostas parciais mantêm formulário, selecção, página e posição; cada preparação conserva as suas opções. Consultas não criam compras, recepções ou movimentos. Reservas planeadas e confirmações de entrega continuam distintas da reserva física e da recepção de stock. Mantém-se a janela de 100 fontes por pesquisa; não é paginação universal de selectores.

Validação: 49 testes/1.047 verificações na regressão de coordenação, planeamento, paginação e caixa de tarefas; 3 testes/89 verificações em PostgreSQL descartável, removido no final. Cobertura inclui origem fora das 100 mais recentes, pesquisa sem distinguir maiúsculas, selecção preservada, utilização nativa da linha, exclusão de rascunhos, isolamento por empresa, leitura sem preparação e consultas sem mutações. Pint, PHPStan sem erros, tipos, lint e build aprovados. HTTP no piloto confirmou administração em leitura e recusas dos perfis sem competência específica, sem conceder direitos.

Evidências: docs/proofs/supply-line-source.json, supply-line-source-pg.json e supply-line-source-http.json; logs supply-line-source-*. Nenhum comando de negócio no piloto, conta, grant, decisão de fornecedor ou alteração ao SGF. Sem nova bateria geral ou revisão visual completa. Não somar as provas sobrepostas. Permanecem a preparação comercial e recuperação do serviço periódico, capacidade, relatórios/impressões e conferência integral dos documentos base; este incremento não declara a aplicação concluída.

## 03/11/2026 — acompanhamento nativo da verificação periódica

sgc:replenishment-tick passou a gravar atomicamente o resultado técnico da própria execução em storage/framework/replenishment-command-status.json. Sucesso, trabalhos a recuperar e interrupção na descoberta/processamento ficam distinguíveis sem copiar pessoas, empresas, artigos, erros internos ou documentos. Falha ao escrever telemetria é reportada e avisada sem mascarar o resultado ou a excepção original. Limite inválido e composição não preparada não publicam sucesso.

ReplenishmentQueue.status lê a observação nativa também fora do ambiente de avaliação. O ficheiro antigo do auxiliar permanece como fallback apenas no piloto e apenas se não existir observação nativa; não pode substituir uma falha nativa por sucesso. Dados danificados não certificam execução. Conservam-se a janela de actualidade, verificação da instalação e consulta das pendências duráveis; uma passagem bem sucedida não oculta trabalhos a recuperar. Isto observa passagens e não garante que um serviço continue activo depois delas.

Validação final: 36 testes/406 verificações em ReplenishmentHeartbeat, WarehousePilotReadiness e AutomaticPurchases. Inclui sucesso, falha, excepção, limite inválido, ambiente comercial, prioridade sobre auxiliar, corrupção, obsolescência e recuperação existente. Ficheiros de teste isolados do piloto. Pint, PHPStan sem erros, diff e 18 hashes de execução aprovados. Prova docs/proofs/replenishment-heartbeat.json; logs replenishment-heartbeat-*. Não foi feita nova execução PostgreSQL, bateria geral ou revisão visual. Não há alteração de interface nesta etapa.

Sem migração, comando de negócio manual no piloto, conta/grant, decisão de compra ou alteração SGF/8051. Não instalado serviço de arranque Windows: instalação comercial, recuperação após reinício, capacidade, relatórios/impressões e cobertura integral dos documentos continuam pendentes. Preservar o auxiliar existente e as aprovações; este acompanhamento não aprova nem encomenda e não constitui aceitação comercial da aplicação.

## 03/11/2026 — exclusão local e recuperação do processo de reposição

O comando nativo de reposição passou a adquirir um bloqueio de processo comum antes da descoberta/processamento, incluindo chamadas pelo auxiliar, agendador e operador. Usa posse do sistema operativo sem prazo que possa expirar a meio do lote. Uma segunda chamada não processa trabalhos, não substitui a observação concluída e devolve insucesso para não publicar falso sucesso através do auxiliar. Libertação em sucesso, excepção e terminação do processo; o ficheiro de controlo persistente não é sinal de bloqueio e não deve ser apagado durante execução. Não substitui transacções/recibos/idempotência existentes nem cria competências humanas.

Regressão final 39 testes/425 verificações em ReplenishmentHeartbeat, WarehousePilotReadiness e AutomaticPurchases, mais 1 teste/5 verificações com processo PHP externo terminado pelo teste. Comprovadas recusa de concorrente, ausência de processamento/telemetria concorrente, libertação após erro e sucesso, destruição da instância e terminação externa sem apagar o ficheiro. Pint, PHPStan sem erros, diff e 18 hashes aprovados. Prova docs/proofs/replenishment-process-lock.json; logs replenishment-process-lock-* e replenishment-process-recovery-tests.txt. Sem nova execução PostgreSQL, bateria geral ou revisão visual; não somar estes resultados às regressões anteriores sobrepostas.

Preparado docs/operacao-reposicao.md com configuração de tarefa recorrente, identidade técnica escolhida na instalação, directório inicial, diagnóstico, recuperação e conferência após reinício. Nenhuma tarefa Windows foi instalada nem credenciais copiadas. Bloqueio validado localmente, não como exclusão distribuída entre servidores. Sem comando manual de negócio no piloto, contas/grants, aprovações, decisões de fornecedor, migração ou alteração SGF/8051. Continuam pendentes instalação/ensaio comercial após reinício, capacidade, relatórios/impressões e cobertura integral dos documentos base. Não declarar aplicação concluída ou aceite comercialmente por este incremento.

## 03/11/2026 — consulta filtrada do acompanhamento de fornecimentos

Reservas planeadas, confirmações de entrega e alternativas técnicas passaram a permitir pesquisa opcional por código/nome do artigo, nome do local, referência da necessidade ou número da encomenda existente, com filtro de estado próprio de cada percurso. A consulta aplica filtros depois de seleccionar a versão mais recente de cada chave e antes de paginar25. Não ressuscita versões antigas activas de processos cancelados. Pesquisa sem distinguir maiúsculas, parâmetros limitados/validados e condições agrupadas dentro do âmbito da empresa.

A interface mantém os filtros recolhidos quando vazios e não acrescenta campos de negócio obrigatórios. Nova filtragem reinicia a página; navegação conserva filtros. Pesquisas parciais de documentos/saídas continuam a preservar filtros, formulário e selecção. Ligação exacta de tarefa continua a apresentar a versão actual e histórico do processo, mesmo fora dos filtros. O estado é o registado; não deve ser confundido com pendência física calculada, especialmente nas reservas reabertas por estorno. Consultas não reservam/saem stock, recebem mercadoria ou alteram decisões.

Validação: 54 testes/1158 verificações em SupplyCoordination,SupplyPlanning,SupplyPagination e WorkflowTaskInbox; 5 testes/111 verificações em PostgreSQL descartável, removido. Abrange origem antiga após26registos, exclusão de estado anterior, histórico preservado, filtros na página seguinte, foco exacto, artigo/local/encomenda, entradas com apóstrofo, empresa e ausência de mutações. Pint, PHPStan sem erros, lint, tipos, build e18hashes aprovados. HTTP no piloto conferiu leitura administrativa, validação e recusas dos perfis sem acesso específico, sem grants. Provas coordination-filters[-pg/-http].json e logs coordination-filters-*.

Sem novas contas, decisões, comandos de negócio manuais no piloto ou alteração SGF/8051. Não houve revisão visual completa, ensaio de capacidade ou nova bateria geral; não somar provas sobrepostas. Continuam pendentes instalação/recuperação comercial após reinício, capacidade, relatórios/impressões e conferência integral dos documentos base. Este incremento melhora a consulta dos processos existentes; não declara novos relatórios ou conclusão integral da aplicação.

## 03/11/2026 — exportação integrada do acompanhamento de fornecimentos

Reservas planeadas, confirmações de entrega e alternativas técnicas passam a disponibilizar CSV a partir da responsabilidade da etapa. Exporta todos os resultados filtrados, sem limite da página25, ou apenas o processo em foco na sua versão actual. Reutiliza os mesmos direitos de leitura, filtros e consulta da página através de SupplyCoordinationRead, sem nova permissão ou segundo registo. Foco antigo resolve a chave e exporta a versão actual mesmo fora dos filtros, como a página; dados estrangeiros ou de outro tipo são recusados.

CSV inclui momento da consulta, filtros, chave/versão/estado registado, artigo/local preservados, referência/encomenda, quantidade/unidade/data, quantidade por satisfazer calculada pelos serviços nativos, substituto/aplicação/validade e ligação exacta ao processo. Alternativas não recebem quantidades pendentes inventadas. Quantidade por satisfazer deve ser interpretada com o estado: não reactiva canceladas e não é reserva física ou compromisso de compra. Textos iniciados por fórmulas, incluindo espaços/controlos anteriores, são exportados como texto; delimitadores/aspas seguem CSV. Resposta privada sem cache, processamento por lotes100, transacção de leitura consistente em PostgreSQL. Não exporta automaticamente todo o histórico ou evidências confidenciais adicionais.

Validação final58testes/1201verificações em SupplyCoordination,SupplyPlanning,SupplyPagination e WorkflowTaskInbox. Quatro testes/43verificações em PostgreSQL descartável, removido; cobrem todas as páginas, última versão, cancelamento, foco exacto, filtro, satisfação parcial, fórmula, empresa, manutenção/vigência e diferenças entre entrega/alternativa. Pint,PHPStan0erros,lint,tipos,build,diff e18hashes aprovados. HTTP no piloto confirmou exportações administrativas em leitura e recusas sem direitos específicos. Provas coordination-export[-pg/-http].json e logs coordination-export-*. Não somar regressões sobrepostas; não foi nova bateria geral, ensaio de capacidade ou revisão visual/impressão.

Sem migração, conta/grant, comando de negócio manual no piloto ou decisão de fornecedor; SGF/8051 preservados. Permanecem a instalação comercial/ensaio após reinício do serviço periódico, capacidade, outros relatórios/impressões e conferência integral dos documentos base. Não apresentar este CSV de acompanhamento como autorização, documento de saída ou comprovação da conclusão integral da aplicação.

## 03/11/2026 — prazos na caixa de tarefas integrada

As caixas de tarefas de Compras/Armazém/Fornecimentos/Finanças e Pessoas permitem consultar todos os prazos, ultrapassados, com vencimento hoje, futuros ou sem prazo registado. Classificação de leitura em WorkflowTaskInboxController a partir exclusivamente de due_on da projecção nativa e da data do servidor, apresentada explicitamente como referência. Não copia tarefas para tabela, inventa prazos ou altera aprovações/atribuições. Documentos antigos continuam primeiro; o prazo não concede competência nem define prioridade automática.

Contagens por prazo usam todas as tarefas autorizadas dentro do módulo e pesquisa, antes de filtrar prazo e paginar25. Cartões de módulos mantêm contagens globais anteriores. Formulário reinicia a página e paginação conserva filtros. Cada tarefa datada mostra a classificação, conservando ligação exacta à origem. A passagem do tempo actualiza a consulta sem novo movimento ou decisão; cancelamento nativo retira a tarefa sem reescrever histórico. Mantida projecção completa existente: este incremento não é ensaio ou optimização de capacidade.

Regressão final87testes/2431verificações em WorkflowTaskInbox,SupplyCoordination e PeopleHiring. Dois cenários dirigidos em PostgreSQL descartável114verificações,base removida: limites de hoje/amanhã/ontem/sem data,28pendências antes da paginação,escopo módulo/pesquisa,contagens,parâmetros,passagem de dia e cancelamento sem mutações de consulta. Pint,PHPStan0erros,lint,tipos,build,diff e18hashes aprovados. HTTP no piloto conferiu cinco opções de prazo nos quatro perfis sintéticos existentes e recusa de opção inválida. Provas task-deadlines[-pg/-http].json e logs task-deadlines-*.

Sem novos prazos configurados,contas/grants,decisões,comandos manuais de negócio no piloto,avisos externos ou alterações SGF/8051. Sem revisão visual completa,nova bateria geral ou ensaio de capacidade; não somar provas sobrepostas. Continuam pendentes instalação/ensaio comercial após reinício do serviço periódico,capacidade,outros relatórios/impressões e conferência integral dos documentos base. Esta consulta não aprova por silêncio nem constitui conclusão ou aceitação comercial integral do SGC.

## 03/11/2026 — consulta e leitura contextual dos avisos internos

Avisos de aprovação passam a ter pesquisa opcional pela referência da requisição, sem distinguir maiúsculas, sobre todos os avisos actualmente visíveis ao destinatário antes de paginar25. Mantidos filtros todos/por ler/intervenções/resultados e contador global de não lidos. Consulta usa transacção consistente somente de leitura em PostgreSQL, resposta privada sem cache e histórico Inertia encriptado. GET não cria nem lê avisos e não altera a elegibilidade nativa ou encaminhamento.

Marcar como lido conserva vista,pesquisa e página em redireccionamento local construído apenas com parâmetros validados. Contexto inválido é recusado antes da marcação. A página é limitada à última válida quando a leitura retira a última linha do filtro; pesquisa nova reinicia a página. Mantidos comando nativo,controlo de empresa/destinatário,verificação actual de acesso e auditoria idempotente. Ler não decide nem submete requisição e não altera orçamento,stock ou etapa de aprovação.

Regressão final24testes/757verificações em InternalRequisitionCandidate e WorkflowTaskInbox. Dois cenários dirigidos em PostgreSQL descartável142verificações,base removida. Cobertura de28avisos nativos,fonte antiga,pesquisa literal/entrada com apóstrofo,página/contexto preservados,contador global,consulta sem mutações,leitura repetida com uma auditoria e parâmetros inválidos sem leitura. Corrigidos no desenvolvimento a chamada encadeada do formulário e comparações do novo teste; só os resultados finais aprovados constituem esta prova. Pint,PHPStan0erros,lint,tipos finais,build,diff e18hashes aprovados. Artefacto compilado conferido sem chamada antiga encadeada. HTTP nos quatro perfis sintéticos existentes e quatro vistas,sem marcar avisos do piloto. Provas notice-consultation[-pg/-http].json e logs notice-consultation-*.

Sem migração,contas/grants,leituras ou decisões de negócio novas no piloto;SGF/8051 preservados. Sem revisão visual completa,bateria geral ou ensaio de capacidade. Não somar provas sobrepostas. Permanecem instalação/ensaio comercial após reinício do serviço periódico,capacidade,outros relatórios/impressões e confronto integral com os documentos base. A pesquisa/readaptação dos avisos não transforma avisos históricos em tarefas actuais nem constitui conclusão integral do produto.

## 03/11/2026 — confronto matriz/código/provas e pesquisa de acordos

Matriz histórica de compatibilidade confrontada com código e provas posteriores em docs/matriz-sgc-reconciliada.md. Acrescentada referência no início de compatibilidade.md,conservando o histórico e separando piloto8005/SGFreal0.1.1/QA. Reposição,relatórios de Pessoas e correcções físicas não devem continuar tratados como globalmente ausentes; capacidades comuns/devolução desligadas não são activadas pelo facto de terem código/provas. Lacunas confirmadas incluem MFA não activo em Fortify e propostas ainda gravadas em MZN; restantes itens sem encerramento comprovado ficam explicitamente como tal. Separados desenvolvimento,instalação/configuração,validação e decisões humanas. Prova documental matrix-reconciliation.json fixa hashes das fontes consultadas,sem declarar nova execução dos testes antigos ou cobertura integral.

Lacuna autorizada implementada: escolha de acordos no calendário deixava todos os acordos aprovados carregados integralmente e só filtrava artigo/local no navegador. Passou a pesquisa de referência/fornecedor no servidor,com âmbito artigo/armazém validado por empresa,100resultados recentes por pesquisa e preservação de fontes aprovadas utilizadas/seleccionadas. Suspensão e âmbito diferente não são contornados pela selecção. Mantido o conjunto de campos da resposta anterior,sem razões/auditoria adicionais. Validade,prazo conhecido,versão e aprovação da política continuam no motor nativo; a pesquisa não certifica elegibilidade contratual. Formulário conserva dados,página,foco e opções por preparação; pesquisa opcional recolhida,desactivada até escolher artigo/local,sem novos campos de negócio obrigatórios.

Regressão final62testes/1381verificações em SupplyPagination,SupplyPlanning,SupplyCoordination e WorkflowTaskInbox;2testes/66verificações em PostgreSQL descartável,base removida. Inclui acordo fora das100fontes recentes,selecção conservada,utilização nativa da origem,exclusão após suspensão,empresa/âmbito,parâmetros/entrada com apóstrofo e leitor sem escolhas. Corrigida a data de criação das cópias sintéticas na preparação do teste; só resultados finais aprovados constituem esta entrega. Pint,PHPStan0erros,lint,tipos,build,diff e18hashes aprovados. HTTP no piloto confirmou os acessos existentes e âmbito obrigatório. Provas agreement-source[-pg/-http].json e logs agreement-source-*.

Sem conta/grant,publicação de política,decisão comercial,comando manual de negócio no piloto ou alteração SGF/8051. Sem nova bateria geral,revisão visual ou ensaio de capacidade;não somar regressões sobrepostas. Próximas prioridades e limites estão na matriz reconciliada. Não declarar produto completo nem pedir nova autorização para decisões já autorizadas/aplicadas;seleccionar fornecedor/encomendar,activar capacidades ou instalar no destino continuam operações próprias.

## 03/11/2026 — base nativa de autenticação de dois factores

Confronto do código confirmou que a lacuna MFA ultrapassava configuração: User não usava TwoFactorAuthenticatable e o esquema não continha as três colunas mencionadas na documentação do modelo. Acrescentados trait/cast nativos e migração aditiva nullable para segredo cifrado,códigos de recuperação cifrados e confirmação. Não executada migração no piloto nem activada a feature. Nenhuma conta foi inscrita ou obrigatoriedade criada; roles/aprovações e política de acesso mantidas.

Ecrãs Inertia portugueses para desafio por aplicação autenticadora/código de recuperação e confirmação de palavra-passe,usando exclusivamente endpoints/acções do Fortify instalado. Histórico encriptado,resposta privada sem cache e nenhuma chave/código de recuperação em props. Campos do formulário limpos após erro/sucesso. Limitador nativo de5tentativas/minuto por identidade em desafio/IP,ligado à configuração Fortify sem activar MFA. O formulário de gestão de adesão/confirmação/recuperação/desactivação ainda tem de ser concluído antes de propor activação; isto é base técnica,não entrega comercial integral de MFA.

Regressão final25casos:23aprovados,2ignorados existentes por feature MFA desligada,426verificações. Os6cenários novos de base foram todos executados;6testes/60verificações em PostgreSQL descartável,base removida. Verificados segredo cifrado/omitido da serialização,feature desligada,conta confirmada em desafio,TOTP real do motor instalado,recuperação e recusa de reutilização sequencial,códigos inválidos/429,adesão não confirmada sem bloqueio de login e confirmação nativa da palavra-passe. Testes registam as rotas do próprio pacote apenas na aplicação descartável; corrigidas preparação do esquema e actualização dos nomes de rotas no teste antes dos resultados finais. Não é ensaio de recuperação concorrente,política obrigatória ou cobertura MFA completa de todas as rotas/composições.

Pint,PHPStan0erros,lint,tipos,build,diff e18hashes aprovados. HTTP nos perfis sintéticos de administração/armazém conferiu confirmação privada e desafio404 com MFA desligado,sem comandos de adesão ou mudança de palavra-passe. Provas mfa-foundation[-pg/-http].json e logs mfa-foundation-*. Sem SGF/8051,contas/grants,migração no piloto,decisões de compra,revisão visual completa,bateria geral ou aceitação comercial. A matriz reconciliada anterior conserva o seu instante/provas; agora há esta base técnica adicional,mas a pendência MFA não deve ser marcada como totalmente encerrada.

Próxima continuidade:concluir interface de adesão protegida por palavra-passe,confirmação explícita do autenticador,consulta/renovação de recuperação e desactivação nativas,testar percursos e só então preparar eventual activação com migração e recuperação verificáveis. Não transformar autorização genérica de desenvolvimento em inscrição/obrigatoriedade das contas existentes.

## 03/11/2026 — gestão voluntária MFA integrada na segurança da conta

Concluída interface de adesão/retoma por chave manual,confirmação TOTP,consulta/ocultação/renovação de recuperação e cancelamento/desactivação explícita. Usa endpoints/acções nativos Fortify e o titular autenticado,sem campos de identidade paralelos. Segurança da conta exige confirmação recente de palavra-passe apenas quando MFA está deliberadamente activo. Preparação não confirmada não activa login;GET da página não modifica a preparação. Segredos não entram em props/estado recordado;respostas MFA privadas sem cache e códigos excluídos dos dados conservados após erro. Envio usa cabeçalho X-XSRF-TOKEN do cookie cifrado. Quando expira a confirmação,nova operação é recusada e a interface encaminha para reabrir segurança e confirmar palavra-passe.

SGC_TWO_FACTOR_ENABLED documentado false em .env.example,configuração condicional com confirm/confirmPassword obrigatórios no mecanismo opcional. Não alterado .env,piloto ou SGF,nenhuma migração aplicada,conta inscrita,senha trocada ou grant. Obrigatoriedade por perfil e recuperação administrativa não foram introduzidas. Operação e limites em docs/mfa-adesao.md,com actualização da matriz reconciliada;não confundir código pronto com activação.

Regressão final29casos:28aprovados,1ignorado existente,505verificações em gestão/segurança/autenticação/baseMFA/caixa de tarefas. O cenário de segurança com feature activa deixou de ser ignorado e é testado explicitamente. PostgreSQL descartável4testes/68verificações,base removida:adesão,propriedades sem chaves,códigos renovados distintos,desactivação recusada sem senha recente,isolamento do titular,código inválido sem activação/oldinput e CSRF nativo efectivamente activo recusando419 sem token e aceitando o cookie cifrado no cabeçalho. Corrigidas inferência do titular web e asserção da bolsa de erros nativa antes dos resultados finais. Pint,PHPStan0erros,lint,tipos,build,diff e18hashes aprovados. HTTP somente de leitura confirmou página de segurança sem opções MFA e endpoints inexistentes no piloto desligado. Provas mfa-management[-pg/-http].json e logs mfa-management-*.

Sem revisão visual completa,ensaio de recuperação concorrente,bateria geral ou aceitação comercial;não somar provas sobrepostas à baseMFA anterior. Preparar operação concreta e salvaguarda/recuperação verificável antes de eventual pedido de activação;autorização de desenvolvimento não inscreve nem impõe MFA às contas existentes. Restantes lacunas da matriz e aprovações comerciais continuam separadas.

## 03/11/2026 — exportação por processo dos metadados de auditoria

Entregue CSV no painel Histórico da requisição,com metadados já visíveis:identidade,data,acção,utilizador e modo de execução. Página e exportação partilham RequisitionAuditTrail,sem segunda lista de eventos nem exportação do payload completo before/after. Consulta preserva empresa e Requisition.visibleTo,com actor web actual,manutenção/vigência verificadas antes de preparar e ao consumir a resposta. Não cria perfil de auditor global ou concede competências. Modo periódico conserva a atribuição técnica existente,sem inventar aprovação interactiva.

Exporta todos os eventos disponíveis por identidade em lotes100,resposta privada sem cache e transacção PostgreSQL consistente/somente de leitura. CSV com BOM,tratamento de aspas/delimitadores e textos de fórmula neutralizados. GET e exportação não geram auditoria/recibo de leitura nem alteram documentos,etapas,orçamento ou stock. Fonte original e eventos imutáveis preservados. Âmbito e pendências em docs/auditoria-metadados-requisicao.md e matriz reconciliada:exportação geral,retenção,certificação,protecção SQL administrativa,volume e histórico paginado no ecrã continuam fora deste incremento.

Regressão final35testes/1016verificações em InternalRequisitionCandidate,ProcurementReviewReport e WorkflowTaskInbox. PostgreSQL descartável2testes/139verificações,base removida. Testados105eventos adicionais ao evento nativo,sem corte na janela100,paridade com ecrã,ordem,exclusão de marcadores privados before/after,texto de fórmula,isolamento de requisitante/departamento/empresa,manutenção/vigência e comparação de registos antes/depois sem mutação. Corrigida referência ao identificador já desestruturado no componente antes da validação final de tipos/build. Pint,PHPStan0erros,lint,tipos,build,diff e18hashes aprovados. HTTP somente de leitura comparou detalhe/CSV da requisição sintética existente2 em quatro perfis e conferiu cabeçalhos/âmbito do conteúdo. Provas requisition-audit[-pg/-http].json e logs requisition-audit-*.

Sem migração,contas/grants,decisões ou comandos manuais de negócio no piloto;SGF/8051 preservados. MFA e respectiva migração continuam desligados/não aplicados como antes. Sem nova bateria geral,revisão visual/folha de cálculo ou ensaio de capacidade;não somar regressões sobrepostas. Não declarar auditoria geral ou aplicação integralmente concluídas por esta exportação de metadados.

## 03/11/2026 — histórico de requisições paginado e leitura coerente

Histórico do detalhe da requisição passou a paginar25eventos por audit_page,validado1..1000000,conservando todos os registos e a ordem dos mais antigos primeiro. Metadados de paginação separados da lista,sem duplicar o payload. Ligações Inertia pedem apenas audit/auditPagination,preservam estado e posição e incluem âncora do histórico;preparações/decisões abertas não são reiniciadas apenas por mudar a página. A navegação parcial não decide processos;os comandos continuam a revalidar competências,origens e versões no motor nativo.

Detalhe relê a requisição autorizada dentro de transacção consistente/somente de leitura em PostgreSQL,em vez de reutilizar apenas a fotografia do route binding obtida antes da transacção. Histórico Inertia encriptado. CSV existente continua integral e usa a projecção comum,sem herdar limite/página do ecrã. Sem novas competências,tabelas ou registos históricos.

Regressão final35testes/1044verificações em InternalRequisitionCandidate,ProcurementReviewReport e WorkflowTaskInbox. PostgreSQL descartável2testes/167verificações,base removida:105eventos sintéticos adicionais à criação nativa,primeira/segunda/última página de6linhas,contagem integral,parâmetros inválidos,CSV completo,conteúdos privados excluídos,âmbito e comparação de registos sem mutações. Pint,PHPStan0erros,lint,tipos,build,diff e18hashes aprovados. HTTP somente de leitura no piloto confirmou encryptHistory,resposta parcial sem a requisição completa,lista até25,contador,recusa de página inválida,CSV e perfis sem acesso. Provas audit-pagination[-pg/-http].json e logs audit-pagination-*. Provas anteriores de metadados preservadas,sem as reescrever ou somar números sobrepostos.

Sem migração,decisões,contas/grants,comandos manuais de negócio ou movimentos no piloto;SGF/8051 e activação MFA preservados. Matriz e documento de auditoria actualizados:paginação do histórico deixa de estar pendente,mas capacidade,visual/folha de cálculo,retenção,certificação e auditoria geral continuam sem encerramento por este incremento. Não houve bateria geral ou revisão visual completa e não foi declarada conclusão integral do SGC.

## 03/11/2026 — indicador de necessidades por aprovar ligado ao relatório e CSV

Relatórios de compras passaram a permitir attention=unapproved_needed,aberto directamente do indicador operacional ou pelo filtro opcional:estado draft/pending e data de necessidade anterior ao dia da consulta. Intersecta pesquisa,estado,departamento e período de criação existentes. Hoje/futuro e pedidos aprovados/rejeitados/cancelados não contam como necessidades por aprovar ultrapassadas. Data canónica apresentada na linha e acrescentada no fim do CSV,conservando as dez colunas anteriores. Não é prazo atribuído ao aprovador nem atraso comprovado do fornecedor e não cria tarefa/decisão por silêncio.

Consulta/indicadores capturam o mesmo instante na leitura consistente;lista25,contagens sobre todos os resultados e CSV integral. Ao consumir a exportação,revalidados titular web,empresa,manutenção e funções actuais,construindo novamente a consulta dentro da transacção própria de leitura. Projecção de ordens recebe esse mesmo titular explícito em vez de depender de request global. Mantidos dinheiro exacto,conteúdo privado,CSV protegido e competências nativas. Revogação após preparar a resposta é recusada antes de emitir linhas.

Regressão final29testes/726verificações em ProcurementReports,ProcurementReviewReport e WorkflowTaskInbox;PostgreSQL descartável2testes/71verificações,base removida. Testados27pedidos,duas páginas,CSV completo,hoje/futuro/estados fechados,parâmetros,passagem de dia,departamento e revogação no consumo do stream,sem mutações de consulta. Testes PostgreSQL confirmam fixtures apenas na base com nome guardado compras_receipts_test_<12hex> para exercitar a transacção própria;limpam schema temporário/funções entre casos,sem relaxar a salvaguarda da aplicação. Corrigida asserção da excepção encapsulada nativa do stream antes dos resultados finais. Pint,PHPStan0erros,lint,tipos,build,diff e18hashes aprovados. HTTP no piloto comparou contagem do indicador com lista/CSV nos perfis existentes. Provas needed-attention[-pg/-http].json e logs needed-attention-*.

Sem migração,contas/grants,comandos manuais de negócio,novas datas de aprovação,decisões ou movimentos no piloto;SGF/8051 e activação MFA preservados. Matriz e docs/relatorios-necessidades-por-aprovar.md actualizados. Sem bateria geral,revisão visual,impressão ou ensaio de capacidade;não somar provas sobrepostas nem declarar relatórios/aplicação integralmente concluídos.

## 03/11/2026 — contagens de aprovadas ligadas à consulta e exportação

Relatórios passaram a abrir indicadores de aprovadas sem propostas registadas e aprovadas sem ordem visível,por attention=approved_without_quotes/approved_without_order. Campo Acompanhamento reúne as duas opções e a necessidade ultrapassada por aprovar,sem novos dados obrigatórios. Indicadores conservam filtros e regressam à primeira página. Consulta usa predicados SQL antes da paginação25 e CSV integral. Registo de proposta e ordem visível passam a consultas auxiliares comuns usadas tanto nos predicados como nas projecções de contagem/ordem,sem segunda regra de elegibilidade ou cópia de documentos.

Mantidos acesso por empresa/departamento,actor explícito e controlo actual de competências/stream. Propostas expiradas continuam registadas para esta contagem;avaliação,elegibilidade,selecção e emissão permanecem nos motores/aprovações existentes. Os dois conjuntos sobrepõem-se e ausência de ordem visível não autoriza encomendar. Não foram criadas tarefas ou rascunhos pela leitura.

Regressão final31testes/840verificações em ProcurementReports,ProcurementReviewReport e WorkflowTaskInbox. PostgreSQL descartável2testes/114verificações,base removida. Testados27aprovados sem documentos,proposta expirada registada sem ordem,pendente excluído,duas páginas,CSV completo,intersecção de estados,empresa/departamento e ausência de mutações nas fontes/orçamento/stock/auditoria. Corrigida apenas a obtenção da proposta da fixture no novo teste antes dos resultados finais. Mantido o isolamento PostgreSQL com guardas e limpeza do esquema temporário. Pint,PHPStan0erros,lint,tipos,build,diff e18hashes aprovados. HTTP no piloto comparou cada indicador com a lista/CSV para os perfis existentes,sem decisões. Provas approved-attention[-pg/-http].json e logs approved-attention-*.

Matriz e docs/relatorios-aprovadas-sem-documentos.md actualizados. Sem migração,contas/grants,aprovações,escolha de fornecedor,emissão,movimentos ou comandos manuais de negócio no piloto;SGF/8051 e activação MFA preservados. Sem bateria geral,revisão visual,impressão ou capacidade;não somar provas sobrepostas nem declarar aplicação ou todos os relatórios completos.

## 03/11/2026 — verificação técnica de saúde da reposição sem executar compras

Entregue sgc:replenishment-health,com saída humana/--json e códigos0/1,sem descobrir origens,drenar fila,criar compras,aprovar ou actualizar heartbeat. Reutiliza observação e agregação de trabalhos de ReplenishmentQueue;consulta de consola sem identidade interactiva/sessão HTTP e transacção de leitura consistente em PostgreSQL quando própria. Resultado inclui somente instantes,motivos e contagens técnicas,não empresas/pessoas/artigos/erros privados. Falha de consulta produz indisponibilidade genérica e registo técnico.

Separação explícita entre agregação global técnica e consulta por empresa,conservando inclusive o âmbito vazio de utilizador sem empresa. Nova passagem nativa associa o resultado à instalação/composição/base por hash,sem guardar nomes,caminhos ou credenciais. Associação diferente é rejeitada;legado sem associação mantém compatibilidade de leitura na interface mas não permite sucesso no novo comando. A verificação de saúde não reescreve/actualiza a observação para simular execução. Resultado técnico não é certificação de configuração funcional,processo activo futuro,assinatura do servidor ou aceitação comercial.

Regressão final46testes/473verificações em ReplenishmentHealth,ReplenishmentHeartbeat,ReplenishmentProcessRecovery,WarehousePilotReadiness e AutomaticPurchases. PostgreSQL descartável6testes/43verificações,base removida. Cobrem leitura sem mutações de tabelas/telemetria,JSON/códigos de saída,passagem ausente/obsoleta/corrompida/falhada,pêndencias/falhas,duas empresas/sem empresa,composição diferente,recusa de identidade interactiva,excepção sem exposição e associação inválida/legada/correcta. Pint,PHPStan0erros,diff e18hashes aprovados. Sem alteração de frontend e sem alegar nova compilação ou revisão visual. HTTP só de leitura conferiu diagnóstico administrativo existente e recusa do perfil sem competência;comando de saúde executado apenas em bases descartáveis. Provas replenishment-health[-pg/-http].json e logs replenishment-health-*;provas históricas de heartbeat/processo preservadas,sem somar regressões sobrepostas.

Matriz e docs/operacao-reposicao.md actualizados. Sem migração,contas/grants,decisões,comandos manuais de negócio no piloto,monitor recorrente ou instalação Windows;SGF/8051 e activação MFA preservados. Operação comercial após reinício,capacidade e restantes pendências da matriz continuam separadas. Não transformar este comando de consulta em prova de instalação,monitor activado ou aplicação concluída.

## 03/11/2026 — entrega por bloco R1: recepção documental

Adoptado o plano docs/plano-entregas-sgc.md: construir blocos funcionais e validar em conjunto no fecho, mantendo verificações críticas dirigidas durante a implementação. R1 acrescenta evidências privadas à recepção confirmada, reutilizando origem e responsabilidades nativas, com repetição segura, integridade na descarga, auditoria e navegação para o processo. Não repete stock, aprovação ou recepção física.

Validação final: ReceiptDocumentBlockTest + ReceiptStockTest, 36 testes/271 verificações; PostgreSQL descartável 5/78, base removida. PHPStan sem erros, TypeScript, compilação de produção, Pint, diff e 18 hashes de execução conferidos. Prova docs/proofs/receipt-block.json e limites em docs/recepcao-documental.md. Sem revisão visual completa, carga ou instalação no piloto. Migração documental 2026_11_03_000002 pendente de autorização específica; não aplicar incidentalmente MFA. Sem novas contas, permissões ou decisões de negócio. R1 não declara todo o módulo Recepção concluído.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Filtro opcional na caixa de Pessoas por referências principal e adicionais do snapshot submetido, incluindo descendentes do território escolhido. Não consulta o perfil actual nem associa códigos a nomes manuais. Referências de outra edição e listas adicionais ausentes/antigas são tratadas sem remapear dados; retirar filtro conserva a caixa completa. SQL JSON parametrizado em SQLite/PostgreSQL; restantes motores mantêm caixa sem este filtro.

Autorização nativa CandidateTriage.canRead, empresa/processo, utilizador e competências actuais e vigência mantidos. Novo catálogo por processo no contexto Pessoas, sem exigir entrada em Compras ou conceder acesso ao catálogo operacional desse contexto. Resultados em ordem de recepção, vinte por página; paginação conserva filtros e foco submission. Ramo principal/adicionais agrupado dentro do âmbito de empresa/processo. Pendências de triagem continuam globais ao processo; nenhuma decisão, pontuação, selecção ou aprovação automática. Auditoria nativa de consulta conservada, sem exportação pessoal nova.

Validação integrada 45 testes/682 verificações de CandidateSubmissions e WorkContext; PostgreSQL descartável 8/135, base removida; baterias sobrepostas, não somar. Inclui principal/adicionais, nomes manuais iguais sem associação, perfil actual divergente, vinte+uma candidaturas/paginação, foco, isolamento, revogação, contexto, suspensão e outras edições. Fixtures respeitam chaves estrangeiras e não alteram submissões imutáveis existentes. PHPStan zero erros, Pint, lint/formatação, TypeScript, compilação e diff aprovados. Fonte/hash preservados; sem revisão visual completa.

Provas candidate-territory[-pg/-http/-pilot].json; docs/territorio-candidaturas-recebidas-sgc.md. HTTP do piloto confirmou Pessoas acessível, processo inexistente404 e catálogo de Compras403 no contexto Pessoas, sem caixas visíveis nessa conta. Percursos positivos de filtro só em bases descartáveis. Zero portais/contas/perfis de candidatos no piloto, acessos27, MFA desligado. Sem processos, migrações, classificações, permissões, triagem, aprovações, políticas, ordens ou SGF alterados. Geografia da sede/fornecedores continua activa; G3 permanece sem estrutura/activação e aguarda autorização própria.

## 03/11/2026 — G7: disponibilidade recebida na ficha e dossiê de Pessoas

ReceivedCandidateAvailability reutiliza a origem electrónica da triagem aceite por empresa/processo, acrescentando received_availability apenas à projecção de leitura PeopleProcessProjection. Página e dossiê partilham o campo e a redacção. Revalida utilizador actual e CandidateTriage.canRead; consultar ou avaliar o processo, por si só, não concede as fontes. Whitelist: referência de submissão, versão, disponibilidade principal/adicionais e respectivas referências; sem email, telefone, documentos, respostas ou conta de candidato.

Usa a fotografia da submissão e confere a versão registada na triagem. Não consulta perfil actual nem resolve nomes no catálogo novo. Texto manual mantém-se sem código inventado; desligar catálogo conserva o histórico. Candidatura interna manual sem origem e submissão recusada não recebem localização por inferência. Consulta em lote, sem novas gravações de cadastros ou triagem.

O campo NÃO integra PeopleHiring.matrix nem as linhas congeladas da selecção. Critérios, pontuações, contribuintes, selecção e aprovações preservados. Testes confirmaram equivalência página/dossiê, leitor sem fontes, revogação de âmbito e identidade actual, isolamento entre processos, referência principal/adicionais/manual, perfil posteriormente alterado, catálogo desligado, base de decisão intacta e tabelas de negócio/auditoria inalteradas pela consulta.

Validação integrada: 89 testes/2237 verificações de CandidateSubmissions e PeopleHiring; PostgreSQL descartável 7/97, base removida; baterias sobrepostas, não somar. PHPStan zero erros, Pint, lint/formatação, TypeScript, compilação e diff aprovados. Fonte/hash intactos. Provas received-availability[-pg/-http/-pilot].json e docs/disponibilidade-recebida-processo-sgc.md. Sem revisão visual completa ou aceitação empresarial.

Piloto consultado só em leitura, sem processos visíveis para comparar positivamente nessa conta e zero portais/contas/perfis de candidato; os casos positivos de disponibilidade electrónica ocorreram apenas em bases descartáveis. Acessos versão27, MFA desligado; sem migração, conta, perfil, aprovação, triagem, política, ordem ou SGF alterados. Geografia da sede/fornecedores continua activa e G3 permanece pendente da autorização própria, sem instalar estrutura ou activar a opção operacional por inferência.


G8 — 03/11/2026: relatório de medidas de melhoria segmentado pelo território actual da ficha do fornecedor, partilhando SupplierGeography com o cadastro. Totais, paginação e CSV respeitam os mesmos filtros e acessos. Sem migração, alteração de snapshots, decisões, perfis ou aprovações. MFA desligado; G3 operacional continua pendente. Documentação: docs/territorio-melhorias-fornecedores-sgc.md; prova: docs/proofs/supplier-territory.json. Validação dirigida SQLite: 50 testes/700 verificações; sem nova execução PostgreSQL ou revisão visual completa.


A2 — 03/11/2026: reprodução dedicada da requisição interna, reutilizando snapshot e WarehouseFulfilment.progress. Separação de pedido/reserva/entrega/saldo/cancelamento, histórico de autorização e recepção, ligações aos documentos individuais A1. Mesmos acessos da ficha, sem mutações ou factura. Sem migração; aprovações preservadas e MFA desligado. Docs/armazem-requisicao-impressao.md; provas warehouse-request-print.json e warehouse-request-print-pg.json. Não declara revisão visual ou aceitação comercial.


A3 — 03/11/2026: CSV integral de acompanhamento das requisições internas, com filtros aplicados e âmbito partilhado com a lista. Uma linha por artigo/unidade; quantidades e estados reutilizam progress nativo. Paginação não limita a exportação; protecção de células de folha de cálculo. Sem novas aprovações, campos, migrações ou movimentos; MFA desligado. Docs/armazem-requisicoes-exportacao.md; provas warehouse-request-export.json e warehouse-request-export-pg.json. Sem teste de carga ou revisão visual completa.


O2 — 03/11/2026: diagnóstico integrado de reposição e integridade documental pelo comando sgc:operations-check. Reutiliza verificadores nativos, consulta global só em consola sem identidade/sessão, saída agregada sem detalhes privados e continuação em falha parcial. Estado incompleto/indisponível nunca equivale a sucesso. Não instala serviços, recupera compras, corrige ficheiros ou grava telemetria. Sem migrações ou interface nova; aprovações preservadas e MFA desligado. Docs/operacao-diagnostico-integrado.md; provas operational-health.json e operational-health-pg.json. Instalação recorrente, restauro, capacidade e aceitação mantêm-se pendentes.


E2 — 03/11/2026: ficha de equipamento reúne também requisições internas ao armazém ainda pendentes, por ID nas linhas preservadas, sem associação por texto. Projecção só das linhas do equipamento, estado/reserva/entrega/saldo nativos, ligações aos processos e paginação independente de15. Acesso ao equipamento não concede acesso ao armazém; empresa/departamento/capacidades mantidos. Sem novos registos, movimentos, migração ou aprovações; MFA desligado. Docs/equipamentos-requisicoes-internas.md; provas equipment-warehouse.json e equipment-warehouse-pg.json. SQLite57testes/737verificações e PostgreSQL4/107 aprovados, sem somar a provas históricas; não declara revisão visual/carga. G3 continua pendente.