compras/docs/desenvolvimento.md

Desenvolvimento do SGC

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.