compras/docs/desenvolvimento.md

Desenvolvimento do SGC

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pessoas — acompanhamento dos esclarecimentos, 30 de Outubro de 2026

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Identidade adoptada — 30 de Outubro de 2026

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Verificações e problemas:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Menu horizontal com dropdowns — 30 de Outubro de 2026

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Regras de investimento por empresa

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

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

Vigência e integração

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

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

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

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

Verificações e aplicação

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

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

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

Limitações e continuidade

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

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

Reforços orçamentais por empresa

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

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

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

Verificação e aplicação

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

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

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

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

Próximo passo e limitações

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

Registo e conferência de pagamentos externos

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

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

Verificação e migração

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

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

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

Pendências e próximo incremento

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

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

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

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

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

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

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

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

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

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

Limitações e roteiro

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

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

Facturas, conferência e consumo orçamental

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

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

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

Verificação e aplicação

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

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

Limitações e próximo passo

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

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

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

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

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

Histórico do primeiro incremento de orçamento

Primeiro incremento de orçamento por empresa

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

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

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

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

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

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

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

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

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

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

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

Entregue

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Verificação efectuada neste incremento

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

Limitações e decisões necessárias

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

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

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

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

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

Resultados verificados

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

Limitações e próximo passo

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

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

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

Incremento actual de adjudicação e ordens de compra

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

Selecção e revalidação

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

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

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

Ordem emitida e consulta

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

Verificação e preservação

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

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

Limitações e próximo passo

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

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

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

Ficheiros deste incremento

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

Entrega anterior RF-AF-01

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

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

Implementado

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

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

Impedimentos no servidor

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

Verificações realizadas

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

Pendências e próximo passo

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

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

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

Ficheiros do RF-AF-01

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

Entrega anterior de fornecedores e anexos

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

Incremento de 28 de Outubro de 2026

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

Implementação

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

Ficheiros deste incremento

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

Verificação concluída

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

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

Limitações e próximo passo

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

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