compras/docs/orientacoes-continuidade.md

# Continuidade do desenvolvimento do SGC

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## Próxima etapa após pagamentos externos

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

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

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

## Próximo incremento após facturas

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

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

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

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

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

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

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

## Entrada livre para revisão visual

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## Base única

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

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

## Estado conhecido na passagem

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

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

## Sequência de execução

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

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

## Protecção do trabalho existente

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

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

## Coordenação

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