compras/docs/orientacoes-continuidade.md

Continuidade do desenvolvimento do SGC

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, 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, 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. 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, artefactos e prova SGF.

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

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. 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. 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 de pagamentos históricos implementada em testes, 29/10/2026: âmbito, arquitectura e provas, 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. 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. 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. 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. 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. 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. 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. 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, 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. 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. 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. 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, 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.

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

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

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

Fornecimento/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.