commit4

docs/PRODUCT_DEMO.md

@@ -0,0 +1,73 @@
+# Demonstração integrada do produto SGF
+
+**Percurso orçamental acrescentado em 29/10/2026:** [interface SGF, contas por função e guião](SGF_BUDGET_WORKSPACE_DELIVERY.md), disponível em 8003 com base persistente separada. Reutiliza o núcleo aceite; a demonstração anterior em 8002 e os seus dados mantêm-se. A interface deixa de estar apenas no adaptador, mas a revisão visual da equipa continua pendente.
+
+**Orientação posterior sobre Compras:** [núcleo comum e duas composições comerciais](PURCHASING_COMMON_CORE_PLAN.md). Preservar esta demonstração e os seus dados; os ensaios destrutivos da futura extracção terão ambientes sintéticos separados. O plano delimita controlo orçamental comum, sem declarar Compras já incorporado ou exigir Sales no produto autónomo.
+
+Decisão expressa da Tempo, 29/10/2026: separar desenvolvimento sintético, validação pela equipa e implantação no cliente. Pessoas reais e concessões na Tempo deixam de ser dependências de desenvolvimento. Aprovações técnicas passam a ser agrupadas em entregas funcionais. Configurações já realizadas na Tempo são preservadas como configurações desse cliente.
+
+## Inventário anterior e âmbito desta consolidação
+
+Os relatórios existentes continuam a ser a evidência de cada entrega. Não se declarou perda de módulos nem se repetiu a regressão aceite. O delta desta entrega é a consolidação de exemplos no mesmo contexto sintético, a retoma persistente e este guião. A prova da correcção de oficina tinha servidor/manifesto próprios; os testes automáticos partilham a base de teste e não devem destruir os exemplos enquanto a equipa trabalha.
+
+| Percurso existente | Referência conservada | Papel na demonstração |
+| --- | --- | --- |
+| Entrada, contexto, permissões | IDENTITY_DELIVERY.md | Empresa Horizonte, unidade central; outras empresas/unidades para isolamento |
+| Clientes, serviços, prestações, rascunhos, B1 | SERVICES_A_DELIVERY.md; SERVICES_B1_DELIVERY.md | Preparação e confirmação interna, com fotografia e histórico |
+| Documentação e pré-visualização | DOCUMENT_PREPARATION_DELIVERY.md; DRAFT_INVOICE_PREVIEW_DELIVERY.md | Reutilizar cadastro e conferir pendências |
+| Cálculo e facturas de teste/PDF | SERVICE_INVOICE_TEST_DELIVERY.md | Documento de exemplo de 1 000 MZN, hipótese sintética; sem validade fiscal |
+| Recebimentos simulados | SERVICE_RECEIVABLES_DELIVERY.md | Preparar obrigação e recebimentos parciais, confirmar distintamente, afectar e conferir |
+| Oficina e custo directo | WORKSHOP_RESOURCE_DELIVERY.md; WORKSHOP_DIRECT_COST_DELIVERY.md | Ordem/apontamentos verificados; preparar/validar custo de 275 MZN |
+| Oficina → rascunho e correcção | WORKSHOP_BILLING_DELIVERY.md; WORKSHOP_BILLING_CORRECTION_DELIVERY.md | Original 500 MZN; experimentar substituição 510 e cancelamento |
+| Custo industrial e orçamento | INDUSTRIAL_COST_DELIVERY.md; INDUSTRIAL_BUDGET_DELIVERY.md | Resultado de 1 800 MZN; preparar orçamento e comparar desvios |
+| Classificação e fiscalidade transversal | CATALOGUE_ACCOUNTING_DELIVERY.md; SERVICE_INVOICE_CALCULATION_SPEC.md §§10–11 | Capacidades e lacunas conservadas; consolidação não declara modelos fiscais concluídos |
+
+Os exemplos de oficina, indústria e serviço facturado são cenários distintos na mesma empresa/unidade. A oficina ainda não está ligada à emissão fiscal ou a lançamentos; não apresentar a justaposição como integração contabilística completa. Compras, stocks, contabilidade geral, fecho, modelos e demais ligações em falta continuam trabalho de produto, autorizável no contexto sintético sem configurar pessoas reais. Reutilizar o conhecimento fiscal do InvesteMoz conforme os requisitos FIS-SGF existentes, sem refazer investigação aceite.
+
+## Preparar e retomar
+
+Escolha técnica: reutilizar a base isolada já protegida `sgf_tempo_test`/`sgf_test_runner`, loopback 55432, e o servidor de demonstração em loopback 8002. Não alterar `sgf_tempo_dev`, contas, concessões ou configurações da Tempo. Não executar migrações nem resets para preparar esta consolidação. Dados existentes sem manifesto reconhecido provocam recusa explícita, sem apagar nada.
+
+```powershell
+# Conferir a consolidação transaccional sem guardar os novos exemplos:
+powershell -NoProfile -ExecutionPolicy Bypass -File scripts/sgf.ps1 php scripts/product-demo.php --env=testing --verify
+# Consolidar exemplos no manifesto sintético existente:
+powershell -NoProfile -ExecutionPolicy Bypass -File scripts/sgf.ps1 php scripts/product-demo.php --env=testing
+# Retomar o servidor quando estiver parado:
+powershell -NoProfile -ExecutionPolicy Bypass -File scripts/browser-proof.ps1 start -Port 8002 -ProductDemo
+# Parar apenas o servidor próprio; conservar manifesto e exemplos:
+powershell -NoProfile -ExecutionPolicy Bypass -File scripts/browser-proof.ps1 stop
+```
+
+A base/cluster precisa de estar disponível. A execução repetida da consolidação reconhece o manifesto e não volta a criar exemplos ou concessões. `--verify` ensaia com rollback antes da primeira preparação; depois consulta o manifesto existente. `sgf.ps1 test` recusa testes destrutivos enquanto existir o manifesto integrado, mesmo com o servidor parado. Não invocar PHPUnit directamente na mesma base durante a avaliação da equipa. Separar a base de regressão da demonstração persistente é uma melhoria técnica pendente; este primeiro pacote mantém a limitação explícita.
+
+## Funções de teste
+
+| Função | Conta sintética | Trabalho |
+| --- | --- | --- |
+| Preparador | gestor@example.test | Preparar propostas, rascunhos, custos, orçamento e operações simuladas |
+| Validador | consulta@example.test | Rever versões comerciais, validar custos/orçamento e confirmar recebimentos |
+| Técnico | tecnico-oficina@example.test | Registar tarefas, tempos e materiais autorizados |
+| Verificador | verificador-oficina@example.test | Verificar apontamentos por identidade distinta |
+
+Estas contas têm direitos explícitos por contexto; não constituem perfis universais nem modelos obrigatórios para clientes. Credenciais aleatórias existentes só no manifesto local protegido `C:\laragon\data\sgf-tempo\secrets\browser-fixture.json`, campo `password`; não copiar para chat, relatórios, capturas ou repositório. Os ficheiros de entrada anteriores também podem ser usados enquanto correspondam ao manifesto. Não há credenciais reais necessárias para estes percursos.
+
+## Guião da equipa
+
+1. Entrar como preparador; seleccionar Empresa Horizonte / Unidade Central. Consultar clientes, serviços, prestação e rascunho. Conferir documentação, versões e pendências; criar outro caso para praticar B1 sem alterar o exemplo de correcção.
+2. Na oficina existente, consultar autorização e apontamentos; entrar como técnico/verificador para experimentar uma nova ordem. O verificador não pode verificar apontamento próprio; a revisão comercial não concede verificação técnica.
+3. Consultar a conversão original de 500 MZN. Em correcção/cancelamento, preparar preços 200/H e 80/UN, fonte sintética v2 e motivo. Validador revê a versão exacta; preparador aplica. Conferir 510, original conservado e origens únicas. Experimentar cancelamento e conferir histórico, sem reabrir consumo.
+4. Preparar custo directo a partir dos apontamentos existentes, validar distintamente. Conferir 275 conhecidos e experimentar falta de taxa: pendência, nunca zero ou custo completo presumido.
+5. Consultar lote industrial/resultado validado de 1 800 MZN. Preparar orçamento 900/600/300, validar, comparar com 1 000/500/300: desvios +100/−100/0 e total zero; residual 300 separado.
+6. Consultar factura de teste de 1 000 MZN e respectivo PDF. Em recebimentos simulados, preparar obrigação e dois pagamentos parciais; validador confirma versões, preparador afecta e validador confere. Conferir saldo/histórico e praticar correcção. Não é banco, recibo fiscal ou lançamento.
+7. Tentar consultar outra unidade sem direito e executar acção da outra função: a aplicação deve recusar. Não conceder novos direitos reais para resolver dificuldades da demonstração.
+
+Registar feedback por percurso, função, passos, resultado esperado/observado e referência sintética; agrupar correcções numa entrega funcional. Não solicitar aprovação de cada passo técnico. A equipa ainda não validou este pacote: preparação técnica não equivale a experiência visual ou aceitação.
+
+## Implantação
+
+Só na implantação entram pessoas e dados reais, concessões efectivas e enquadramentos fiscais/contabilísticos do cliente. Guardas de emissão e operações reais mantidas. As propostas anteriores para `130000`/cinco concessões na Tempo não são pré-requisitos desta demonstração nem foram aplicadas. Não há publicação ou activação operacional decorrente desta entrega.
+
+## Verificação desta consolidação — 29/10/2026
+
+Preparação transaccional com rollback aprovada antes de guardar; preparação efectiva só na base sintética; repetição/retoma reconheceu o manifesto sem recriar exemplos. Retoma em `http://127.0.0.1:8002`. Verificações HTTP em `scripts/product-demo-check.mjs`: entrada/contexto das quatro funções, consulta dos oito módulos de preparação/validação, oficina pelo técnico/verificador, recusa de módulo sem direito e de unidade reservada. Resultado em [prova HTTP](proofs/product-demo-http.json). Apenas sessão/contexto alterados pela prova HTTP, sem decisões ou operações de negócio. Não se executou suite destrutiva, não se declarou prova visual e não se atribuiu aceitação à equipa.

docs/PURCHASING_COMMON_CORE_PLAN.md

@@ -1,5 +1,11 @@
 # Compras e núcleo financeiro comum — desenho e transição
 
+**T2 sintético implementado, 29/10/2026:** [obrigação de fornecedor sobre factura conferida](SUPPLIER_PAYABLE_DELIVERY.md), fonte única, duas composições, sem pagamentos. Mantém orçamento entregue, demos e pendências da equipa; não equivale a migração ou implantação.
+
+**Orientação comum posterior:** as [oito regras de produto SGF/Compras](SUPPLIER_PAYABLE_SCOPE.md#14-orientação-comum-de-produto-da-tempo--29102026) distinguem documento, dívida, liquidação e contabilidade e orientam os contratos futuros. T2 continua limitado à obrigação a fornecedor; nenhuma ampliação automática a pagamentos/cobranças. Vencimento desconhecido mantém pendência explícita, sem apagar principal nem inventar data.
+
+**Delimitação T2, 29/10/2026:** [factura de fornecedor conferida → obrigação única](SUPPLIER_PAYABLE_SCOPE.md). Identificados saldo implícito existente em Compras, lacunas de vencimento/revisão e compatibilidade de leitura necessária. Ainda sem implementação; o orçamento entregue e a avaliação da equipa são preservados.
+
 **Actualização de execução, 29/10/2026:** primeiro incremento implementado e tecnicamente demonstrado em hosts sintéticos, conforme [entrega e limites](COMMON_BUDGET_DELIVERY.md). A marcação de desenho/não executado abaixo conserva o estado da proposta original. Não há aceitação, implantação ou extracção integral de Compras presumidas; T2 e seguintes não foram iniciados.
 
 29/10/2026. Estado: desenho técnico revisto e primeiro incremento delimitado; reestruturação e provas ainda não executadas. Referência principal para os dois projectos. Não substitui as matrizes de requisitos ou as aceitações existentes.

docs/SERVICE_INVOICE_CALCULATION_SPEC.md

@@ -210,3 +210,110 @@ Provas a exigir futuramente no recorte aprovado: casos exactos reutilizados IM-F
 **Incluído e consumidores futuros:** verificar a adequação do art. 34 à factura pretendida e, se aplicável, unidade, sequência e tratamento de empates com fundamento. Só depois definir extracção/reconciliação/apresentação. HALF_UP/HALF_EVEN e formatos M20/M22 não substituem essa validação. Procurar alterações regulamentares apenas para a disposição/consumidor que possa ser afectado, reutilizando o dossier e os exemplares já identificados.
 
 Não voltam a aprovação valores exactos, ausência de truncagem silenciosa, desconhecido diferente de zero ou história preservada. Não é necessário pedir de novo R1–R6. Nenhuma regra é activada nesta revisão. Não se alteraram código, bases, permissões, fotografias ou portal; não se copiaram implementações nem se executaram testes. Numeração, emissão, PDF, recebimentos, contabilização e publicação permanecem fora do âmbito.
+
+## 10. Auditoria de incorporação fiscal InvesteMoz → SGF — 29/10/2026
+
+Pedido expresso da Tempo nesta conversa: auditar os dois sistemas e identificar como incorporar no SGF as funcionalidades fiscais do InvesteMoz. Estado: auditoria de código e documentação concluída no âmbito abaixo; incorporação funcional proposta, não executada. As secções anteriores mantêm valor histórico; decisões posteriores aceites prevalecem no seu âmbito.
+
+### 10.1 Método e versões
+
+Inspecção local, sem consultas às bases, arranque de serviços, alterações de permissões, migrações ou publicação. Não foram lidos ficheiros de ambiente/credenciais. Não foram repetidos testes aceites nem feita nova prova HTTP ou visual. Os resultados de testes citados são evidências históricas, não execução desta auditoria. Não se avaliou vigência jurídica externa: as fontes e limitações são as documentadas no acervo, não um parecer fiscal novo.
+
+SGF: C:/laragon/www/sgf-tempo, HEAD d071bc0, com alterações posteriores de oficina em curso; preservadas. InvesteMoz: C:/laragon/www/portal-investidor, HEAD fde644af, com alterações documentais anteriores preservadas. Esta cópia principal não contém vários módulos IRPC referidos pelos recibos de instalação. Não se conclui perda no servidor. Para leitura de IRPC usaram-se também as cópias irpc-economic-qa-20261028 e fiscal-forms-qa-20261028.
+
+Conferência adicional: os 12 ficheiros de compatibility.runtime_delta do recibo docs/investmoz/simulations/irpc-l8-grouped-delivery-20261028.json coincidem por SHA-256 com a cópia C:/laragon/www/portal-investidor-fiscal-forms-qa-20261028. A versão de irpc-annual-settlement.ts na cópia economic difere; a versão correspondente ao recibo está na cópia fiscal-forms. Este resultado identifica uma origem verificável, sem afirmar igualdade de todo o projecto nem estado actual do servidor. Antes de extrair, fixar manifesto de todas as dependências transitivas e respectivos testes.
+
+### 10.2 Conclusões
+
+1. A reutilização já começou: ServiceCalculation::SOURCES cita a ficha IVA-GERAL-BASE-LIQUIDA do InvesteMoz. O SGF não parte do zero.
+2. O SGF tem cálculo condicionado aceite, perfil e decisão temporal versionados, activação local delimitada, precisão decimal, resultado imutável e repetição idempotente. Ver CONDITIONAL_CALCULATION_ACCEPTANCE.md. Não classificar todo o cálculo como apenas sintético. Exigibilidade pendente continua distinta de cálculo condicionado.
+3. ServiceInvoicing::guard mantém emissão real bloqueada fora do ambiente isolado. A emissão/PDF de teste não é emissão fiscal operacional. Não retirar esta guarda por copiar regras do portal.
+4. O portal tem cobertura maior de IVA, retenções, IRPC, créditos/reportes e ISPC; parte é preparação/projecção ligada ao dossier e parte é cálculo de operação. Não transformar automaticamente projecção em facto contabilístico ou imposto a pagar.
+5. Recomenda-se núcleo fiscal versionado reutilizável, com execução autoritativa no servidor do SGF e adaptadores próprios. Não partilhar a base de dados nem chamar o simulador público em cada factura.
+
+### 10.3 Correspondência de funcionalidades e actividades propostas
+
+Todos os IDs FIS-SGF-01 a 12: Planeado — não implementado por esta auditoria. Ordem abaixo é proposta técnica por dependências, não substitui prioridades aprovadas. Responsável nominal e prazo não atribuídos.
+
+| ID / ordem | Capacidade de origem | Estado SGF / adaptação necessária | Critério de aceitação |
+|---|---|---|---|
+| FIS-SGF-01 / 1 | Fontes, versões, vigência, parâmetros e expressão fiscal; SimulationTaxRuleExpression, SimulationTaxParameterResolver, SimulationFiscalSnapshot | Reutilizar fontes e casos aceites; adaptar resolução ao tenant/empresa/unidade e perfis existentes, sem importar permissões/publicação do portal. | Regra fixada por versão/hash; fronteiras temporais e conflito/ausência de parâmetros explícitos; histórico reproduzível. |
+| FIS-SGF-02 / 2 | IVA de operações, base líquida e enquadramentos; iva-operations, iva-service-location, iva-service-normal, iva-exclusion-base | Expandir gradualmente o recorte actual de uma linha, MZN e preço acrescido. Acrescentar múltiplas linhas/tratamentos e preço incluído somente com regra específica do consumidor. | Casos exactos comparados aos aceites; isenção, não sujeição e zero distintos; soma por linha/documento e diferenças de representação reconciliadas. |
+| FIS-SGF-03 / 2 | Facto gerador, exigibilidade e acontecimentos; fiscal-claim-events | Completar ServiceFiscal com acontecimentos efectivos, sem usar data de consulta, próxima facturação ou confirmação B1 como substituto. | Cenários pendente, factura, atraso e pagamento preservam datas e versão; período fiscal só determinado quando sustentado. |
+| FIS-SGF-04 / 3 | Retenções IRPC e respectivos fundamentos; irpc-withholdings, irpc-fx, irpc-relief-preparation | Não localizado motor equivalente no SGF. Integrar pagamentos/rendimentos e distinguir retenção efectuada de sofrida, por conta de definitiva. | Pagamento/comprovativo rastreável, contexto do beneficiário, natureza e vigência; sem duplicação nem abatimento automático de toda retenção à colecta. |
+| FIS-SGF-05 / 4 | Aquisições, dedução, afectação, regularizações e Modelo A; iva-acquisitions, iva-acquisition-allocation, iva-regularizations, iva-modelo-a | Criar livros fiscais a partir de documentos efectivos, despesas e correcções do SGF; módulos de compras/documentos necessários não presumidos existentes. | Documento→parcela→dedução→período→campo reconciliável; desconhecido não zero; bloqueio de dupla dedução, revisões e créditos conservados. |
+| FIS-SGF-06 / 5 | IRPC: resultado, custos, depreciações, base/colecta; irpc-normal e dependências | Substituir entradas projectadas por balancete e movimentos efectivos versionados. Custeio industrial e classificação de catálogo existentes não equivalem a razão contabilístico. | Ponte resultado contabilístico→ajustamentos→lucro tributável→base/colecta explicável; inventário de activos e encargos com origem; sem automatizar ramos não cobertos. |
+| FIS-SGF-07 / 6 | Retenções sofridas, PPC, PEC, créditos internacionais/económicos, reportes; irpc-annual-settlement e módulos relacionados | Adaptar ao mesmo contribuinte, exercício e comprovativos efectivos; usar fiscal-proof-parcel para não reutilizar a mesma parcela indevidamente. | Consumo agregado não excede comprovativo; deduções/reportes por origem/período; saldo aritmético separado de declaração, pagamento e reembolso. L8 permanece parcial. |
+| FIS-SGF-08 / 5, condicionado à aplicabilidade | Elegibilidade, trimestre e retenções ISPC; ispc-eligibility, ispc-quarter, ispc-withholding | Incorporar apenas para empresas/regimes aplicáveis, sem assumir enquadramento da Tempo nem activar IVA/IRPC/ISPC simultaneamente por omissão. | Elegibilidade explícita e histórico de enquadramento; volume do contribuinte completo; trimestre/ano e projecção/efectivo separados. |
+| FIS-SGF-09 / 4–6 | Preparação Modelo A e M20/M22, relatórios e recuperação | Reutilizar correspondências de campos, não tratar formulários manuais como motor integral. No portal, a entrega de formulários de 28/10 tem 27 campos IVA e 24 M22, sem persistência no servidor ou submissão AT. | Campos automáticos reconciliados com livros; campos manuais identificados; gravação/versionamento no servidor SGF; validação distinta de impressão/submissão. |
+| FIS-SGF-10 / transversal | Snapshots, históricos, não duplicação e diagnósticos | Manter contexto SGF, revisão distinta, auditoria transaccional, concessões explícitas e imutabilidade; adaptar snapshots por oportunidade para empresa/operação/período. | Tentativas entre empresas/unidades recusadas; replay, concorrência, alteração de versão e revogação testados; originais B1 preservados. |
+| FIS-SGF-11 / depois dos livros | Obrigações, calendário e integração operacional | Há pendências no próprio portal para calendário PPC/PEC, juros/guias e fecho integral. Desenvolver especificamente no SGF quando houver fontes e consumidores; não marcar como simples cópia. | Obrigação e prazo com fundamento/período; reconhecimento, apuramento, pagamento e submissão separados e reconciliados. |
+| FIS-SGF-12 / primeiro e transversal | Conjunto de casos e provas existentes | Fixar origens por commit/hash, extrair funções puras e comparar resultados com contratos SGF; portar os casos aceites, acrescentando apenas os testes da integração. | Paridade exacta para casos cobertos; diferenças justificadas por contrato; política monetária preservada; sem testes destrutivos fora de sgf_tempo_test. |
+
+### 10.4 Arquitectura recomendada
+
+Proposta, não estrutura já criada: módulo fiscal do SGF que usa CompanyContext, Permissions, Audit e a persistência existente. Separar (a) acervo/fontes e parâmetros por versão, (b) funções puras de classificação e cálculo, (c) adaptadores de operações efectivas, (d) livros/apuramentos, (e) representação documental. O InvesteMoz conserva o adaptador de projecções. Começar pela extracção controlada das funções PHP e portabilidade testada das funções TypeScript; só criar pacote partilhado após fixar contrato e manutenção de versões. Evitar dois motores divergentes mantidos por cópias manuais.
+
+Entrada mínima proposta: versão do contrato, tenant/empresa/unidade, contribuinte, operação/documento/linha e versões, natureza efectiva/projectada, regime/tratamento, moeda, montantes em strings decimais, datas do facto/exigibilidade, período, fonte/regra/versão e comprovativos. A identidade/autorização é resolvida pelo servidor, nunca confiada ao cliente. Resultado: determinado/indeterminado/não aplicável/condicionado, montante exacto, representação documental e diferença, pressupostos/pendências, passos, fontes e hash da entrada. Taxa ausente não é zero.
+
+Os módulos TS do portal dependem de acquisitionScope, modelo_a_snapshot, closureFingerprint e plano empresarial. São dependências do dossier, não a identidade fiscal do SGF. Transferir a lógica não autoriza copiar os snapshots de utilizadores. Resultado enviado pelo navegador deve ser recalculado/conferido no servidor antes de integrar documentos ou livros.
+
+### 10.5 Incompatibilidades e limites concretos
+
+- Precisão: SGF aceita quantidade/preço com até 16 inteiros e 8 decimais, usa BigDecimal e política documental TRUNCATE2, conservando a diferença. fiscal-rational aceita montantes até 18 inteiros/6 decimais e usa BigInt; apresentação aproxima a seis casas. Não reutilizar a apresentação como montante fiscal nem reduzir silenciosamente a precisão do SGF. Exemplo já aceite: base 1000,03, IVA exacto 160,0048, documental 160,00 e diferença 0,0048.
+- Consumidor publicado PHP do portal: SimulationPublishedFiscal está ligado a IVA-GERAL-BASE-LIQUIDA/MZN e cobertura técnica 2026. Essa cobertura não é prova de caducidade legal nem motor geral para todos os impostos/anos.
+- Fiscalidade versus contabilidade: classificação PGC-NIRF do catálogo e custeio/oficina não substituem reconhecimento contabilístico, activo fiscal, livro de compras, retenções e fecho. Esses adaptadores são trabalho SGF.
+- Formulários e L8 não são integrais. O recibo L8 mantém tributação autónoma, certos benefícios, calendários/guias, períodos especiais, outras moedas e transporte/submissão entre as pendências. Não prometer incorporação integral de IRPC.
+- IRPS/salários, direitos aduaneiros/ICE e submissão electrónica AT não foram demonstrados nesta amostra como módulos prontos a portar. Não incluir como entrega disponível só por aparecerem no selector fiscal.
+- Compatibilidade técnica: ambos usam Laravel 13 e React 19, mas SGF fixa PHP ~8.4 e brick/math 0.14.8; o portal usa Inertia/TypeScript e outras dependências. Reutilização de lógica é viável; transplante de páginas/controladores/esquema não é automático. Não actualizar dependências por arrasto.
+- Separação operacional: não partilhar credenciais, base, sessão ou perfis; eventual distribuição de regras deve usar pacote/contrato versionado com origem e compatibilidade, sem enviar clientes/movimentos do SGF ao portal.
+
+### 10.6 Sequência e evidências
+
+Primeiro FIS-SGF-12/01: fixar manifestos, fontes e casos; extrair núcleo e adaptador de cálculo sem emissão. Depois 02/03: consolidar IVA operacional, preservando o cálculo condicionado aceite. Seguir 04/05: retenções e livros de IVA quando as operações/documentos estiverem disponíveis. Depois 06/07/09: IRPC anual, créditos e declarações com integração contabilística. 08 apenas conforme o regime; 11 após cobertura dos apuramentos.
+
+Para cada lote: critérios da tabela, equivalência exacta, ausência de parâmetros, datas limítrofes, alteração de versão, dupla utilização de comprovativos, concorrência/idempotência, segregação tenant/empresa/unidade e preservação de fotografias. Ensaios novos apenas em sgf_tempo_test pelo wrapper scripts/sgf.ps1. Activação operacional é separada da incorporação técnica conforme as decisões já registadas; esta auditoria não executa nem solicita activação.
+
+Evidência SGF: app/Modules/Services/ServiceCalculation.php; ServiceFiscal.php; LocalFiscalActivation.php; ServiceInvoicing.php; CatalogueAccounting.php; docs/CONDITIONAL_CALCULATION_ACCEPTANCE.md; SERVICE_CALCULATION_DELIVERY.md; SERVICE_INVOICE_TEST_DELIVERY.md; tests/Feature/ServiceCalculationTest.php e ServiceFiscalTest.php. Evidência InvesteMoz: serviços SimulationTaxRuleExpression/ParameterResolver/FiscalSnapshot/PublishedFiscal; bibliotecas IVA/ISPC; módulos IRPC das cópias identificadas; recibos irpc-l5-delivery-20261025.json, irpc-l6-values-forms-delivery-20261026.json, irpc-l7-server-state-20261026.json, irpc-l8-grouped-delivery-20261028.json e fiscal-form-preparation-git-delivery-20261028.json.
+
+Próximo recorte recomendado: FIS-SGF-12/01, contrato e paridade de cálculo, preservando emissão, contabilização e recebimentos no seu estado actual. Não é necessário refazer o cálculo de IVA já aceite nem voltar a validar genericamente as fontes oficiais aceites.
+## 11. Orientação de produto da Tempo — conhecimento fiscal comum e capacidades próprias do SGF — 29/10/2026
+
+**Delta dirigido FIS-SGF-16:** [percurso orçamental sintético SGF](SGF_BUDGET_WORKSPACE_DELIVERY.md) disponibiliza interface, funções e rastreabilidade sobre o núcleo comum, em base QA própria. Não encerra o requisito nem acrescenta orçamento industrial, obrigações, pagamentos, lançamentos ou modelos. Teste pela equipa/aceitação mantêm estado independente da prova HTTP.
+
+**Cobertura dirigida FIS-SGF-16, 29/10/2026:** [controlo orçamental comum sintético](COMMON_BUDGET_DELIVERY.md), reutilizando dotações/reservas/compromissos/consumo de Compras nos dois hosts. Orçamento industrial permanece distinto. Não encerra FIS-SGF-16 nem implementa contas a pagar, caixa, lançamentos ou modelos; demais requisitos mantêm estado/critério.
+
+**Desenho de Compras confirmado posteriormente:** [um módulo, um núcleo financeiro comum e duas composições](PURCHASING_COMMON_CORE_PLAN.md). Para FIS-SGF-13/14/15/16, preservar procurement existente, extrair capacidades financeiras reutilizáveis de Compras/SGF e atribuir um único escritor a cada efeito; completar apenas lacunas. FIS-SGF-18/19 conservam consumidores e conhecimento versionados. Primeiro incremento: controlo orçamental sintético comum; esta referência não altera critérios/estados funcionais nem declara fiscalidade/contabilidade geral concluídas. Facturação de vendas não é dependência comercial obrigatória de Compras autónomo.
+
+**Decisão posterior de execução, na mesma data:** desenvolvimento e testes destes requisitos usam funções e organizações sintéticas, sem depender de pessoas/concessões na Tempo. Validação da equipa em entregas funcionais integradas; implantação real separada. A conformidade para emissão real não bloqueia desenvolver os restantes consumidores. Ver [demonstração do produto e inventário de capacidades/lacunas](PRODUCT_DEMO.md). Os requisitos FIS-SGF existentes mantêm os seus critérios e estados; esta referência não os encerra.
+
+Clarificação expressa do utilizador nesta conversa: o SGF é uma aplicação com forte componente fiscal transversal à classificação das vendas/compras, stocks, contabilidade geral e de custos, análises financeiras e preenchimento automático de modelos IVA, IRPS, IRPC, INSS e outros aplicáveis. A finalidade é enriquecer o SGF com o conhecimento já tratado no InvesteMoz, sem duplicar esse trabalho, e acrescentar as capacidades operacionais próprias do SGF.
+
+Esta orientação amplia o âmbito de produto da auditoria da secção 10; não limita a integração a cálculo de factura ou cópia de simuladores. A ausência de demonstração de IRPS/INSS na amostra anterior é uma tarefa de localização e correspondência do acervo, não uma exclusão do produto nem uma declaração de que o conhecimento não existe. Reutilizar fontes, interpretações, correspondências, regras, decisões e casos aceites; estudar/implementar apenas lacunas concretas ou diferenças do consumidor SGF. Não exigir nova validação genérica das fontes oficiais já aceites.
+
+### 11.1 Distribuição de responsabilidades
+
+- Conhecimento fiscal reutilizável: legislação e alterações por período, enquadramentos, classificações, condições, fórmulas, parâmetros, correspondências dos modelos, fontes e exemplos/testes documentados. Um registo de origem e versões permite actualizações coerentes, sem repetir a investigação nos dois sistemas. A tecnologia de distribuição é escolha de implementação, não dependência de uma chamada ao portal por operação.
+- InvesteMoz: mantém os seus percursos de orientação e preparação do investimento, cenários e simulações. Preservar entregas e acervo; não alterar o seu âmbito para acomodar o SGF.
+- SGF: aplica o conhecimento às operações efectivas, com contexto da empresa/unidade, documentos, movimentos, stocks, activos, trabalhadores/remunerações, contabilidade e fechos. Produz análises e modelos a partir dos registos, evitando reintrodução de informação já disponível.
+- O estado de uma fonte, a cobertura de uma regra, a implementação do consumidor e a disponibilidade operacional são registados separadamente. Conhecimento disponível não significa consumidor implementado; consumidor por completar não justifica refazer conhecimento já tratado.
+
+### 11.2 Actividades adicionais na execução
+
+IDs FIS-SGF-01 a 12 mantidos e ampliados por esta orientação. Novos recortes abaixo: planeados, não executados nesta actualização. Prioridade por dependências a reconciliar com as entregas em curso; sem atribuição fictícia de responsável/prazo.
+
+| ID | Capacidade SGF a completar | Reutilização / trabalho próprio | Critério de aceitação |
+|---|---|---|---|
+| FIS-SGF-13 | Classificação fiscal e contabilística de vendas/compras | Reutilizar enquadramentos, condições, vigência e fontes do portal; articular com catálogo e classificação SGF, contrapartes e natureza/localização da operação. | Uma operação alimenta documentos, livros e contabilidade com classificação fundamentada; categoria comercial/conta contabilística não determina automaticamente imposto; excepções e versões rastreáveis. |
+| FIS-SGF-14 | Stocks e articulação fiscal/contabilística | Acrescentar entradas, saídas, transferências, devoluções, inventários e valorização; reutilizar regras aplicáveis a bens e regularizações já tratadas. | Quantidade, custo, documento, movimento e consequências fiscais conciliáveis; sem dupla movimentação, origens perdidas ou IVA incorporado no custo indevidamente. Método de valorização identificado, não inventado pela integração. |
+| FIS-SGF-15 | Contabilidade geral, activos e fechos | Construir integração documental→lançamentos→razão/balancete→fecho; reutilizar conhecimento sobre depreciações, ajustamentos e apuramentos, preservando classificação existente. | Origem até lançamento e demonstração recuperável; débitos/créditos conciliados; períodos e correcções controlados; depreciação contabilística e tratamento fiscal distinguíveis. |
+| FIS-SGF-16 | Contabilidade de custos e análises financeiras | Preservar custeio directo/industrial e orçamento existentes; integrar centros de custo, produção/oficina, margens, tesouraria e indicadores com dados efectivos e projecções identificadas. | Custos/margens conciliam com movimentos e contabilidade; critérios de imputação explícitos; previsto/realizado e efeitos fiscais separados, sem duplicar custos ou caixa. |
+| FIS-SGF-17 | IRPS, remunerações e INSS | Localizar todo o conhecimento pertinente no acervo InvesteMoz e mapear cobertura; completar lacunas específicas; acrescentar cadastro laboral, processamento e obrigações próprios do SGF. | Por trabalhador e período, bases, exclusões, retenções e contribuições aplicáveis são explicáveis e conciliáveis com remunerações, contabilidade e modelos; parâmetros ausentes não se tornam zero. Dados pessoais limitados aos acessos próprios. |
+| FIS-SGF-18 | Preenchimento automático de modelos e obrigações | Ampliar FIS-SGF-09 para IVA, IRPS, IRPC, INSS e outros identificados como aplicáveis; reutilizar correspondências/formulários existentes e ligar campos às operações/livros do SGF. | Cada campo preenchido automaticamente mostra origem, período, versão e regra; totais reconciliam; lacunas ficam visíveis; correcção manual fundamentada/versionada; modelo recuperável e exportável no formato aplicável. Preparar, rever, entregar e guardar comprovativo são estados distintos; não presumir transmissão automática às autoridades. |
+| FIS-SGF-19 | Manutenção do conhecimento comum | Inventariar fontes/regras/casos já tratados, mapear aos consumidores SGF e distribuir versões com impacto identificado; reutilizar testes aceites e acrescentar testes de integração. | Alteração de regra identifica operações/modelos afectados, produz nova versão sem reescrever história e evita investigação duplicada. Pendência localiza o trecho/condição exactos em falta. |
+
+### 11.3 Percurso integrado e sequência
+
+Conhecimento fiscal versionado → classificação da operação → documentos e movimentos → stocks/custos/contabilidade/remunerações → apuramentos → preenchimento automático e reconciliação dos modelos → revisão/entrega/comprovativo. As análises financeiras consomem os dados conciliados deste percurso. Capturar a informação uma vez e reutilizar com origem, contexto, autorização e versão.
+
+Primeiro, correspondência do acervo existente aos consumidores (01/12/19), incluindo IRPS/INSS e modelos, sem refazer a investigação. Em paralelo lógico de planeamento, especificar operações e ligações necessárias (13–17), preservando incrementos aceites. Executar por recortes completos de operação até resultado, acrescentando 18 aos respectivos apuramentos; evitar um projecto isolado de formulários manuais ou uma cópia do simulador. Implementação e activação serão registadas por recorte; esta actualização documenta o âmbito e não declara as capacidades entregues.

docs/SGF_BUDGET_WORKSPACE_DELIVERY.md

@@ -0,0 +1,78 @@
+# Percurso orçamental sintético no SGF
+
+29/10/2026. `SGF-BUDGET-WORKSPACE-SIM-v1`. Implementação autorizada do passo seguinte à [aceitação técnica do núcleo comum](COMMON_BUDGET_ACCEPTANCE.md). **Disponível para teste da equipa, sem aceitação ou checkpoint de encerramento presumidos.**
+
+## Disponibilidade e preservação
+
+Entrada local: **http://127.0.0.1:8003**. É o SGF existente: mesmo bootstrap, entrada por sessão, selecção de empresa/unidade, navegação e componentes React. Depois de seleccionar o contexto, abrir **Compras → Controlo orçamental sintético** ou o atalho da página inicial.
+
+A instalação de demonstração tem base PostgreSQL própria `budget_core_sgf_<12 hex>`, uma conta técnica exclusiva sem superuser/CREATEDB/CREATEROLE, chave da aplicação, cookie, sessões e cache separados. Não usa `sgf_tempo_dev`, `sgf_tempo_test` ou `compras_dev`. A demonstração anterior em 8002 conserva contas/dados e não foi substituída. Esta composição demonstra o percurso orçamental no SGF; não reúne automaticamente todos os dados/módulos da demonstração anterior.
+
+O estado inicial mantém quatro contas, centros e origens sintéticos, **sem dotações, decisões ou movimentos pré-preenchidos**. A prova HTTP usa outra base/role descartável em 8004; não consome o cenário que a equipa vai experimentar. A [conferência da disponibilidade](proofs/budget-demo-availability.json) registou quatro utilizadores e zero dotações/movimentos/consumos/comandos antes da revisão da equipa.
+
+```powershell
+powershell -NoProfile -ExecutionPolicy Bypass -File scripts/budget-demo.ps1 status
+powershell -NoProfile -ExecutionPolicy Bypass -File scripts/budget-demo.ps1 start
+powershell -NoProfile -ExecutionPolicy Bypass -File scripts/budget-demo.ps1 stop
+```
+
+`start` recusa porta ocupada; o provisionamento repetido preserva a base, pessoas sintéticas, passwords e histórico. `stop` só termina o servidor próprio identificado e conserva os dados. Não há reset automático. Não executar testes destrutivos apontados para a base persistente da equipa. O servidor está limitado a loopback; não foi publicado ou disponibilizado remotamente.
+
+## Contas por função
+
+| Função | Conta sintética | Acções |
+| --- | --- | --- |
+| Preparação | `preparacao-orcamento@example.test` | Consultar, preparar dotação, propor reforço |
+| Validação | `validacao-orcamento@example.test` | Consultar, aprovar dotação, aprovar/recusar reforço |
+| Operação | `operacao-orcamento@example.test` | Consultar, reserva/adjudicação/compromisso/libertação e consumo simulado |
+| Consulta | `consulta-orcamento@example.test` | Ler saldos, referências, movimentos e histórico; sem escrita |
+
+As passwords aleatórias de cada conta estão exclusivamente no ficheiro local protegido `C:\laragon\data\sgf-tempo\secrets\budget-demo-access.json`, campo `accounts`. Consultá-lo localmente; não copiar passwords para chat, relatórios, capturas ou Git. As configurações de ligação/chave estão noutro ficheiro privado, `budget-demo.json`. Os ficheiros têm ACL do utilizador local/SYSTEM. Não foi alterada conta ou concessão real nem atribuída função a pessoas reais.
+
+Empresa: **Empresa Horizonte — Orçamento sintético**. Unidade: **Unidade Central — Orçamento sintético**. Centro do guião: **ORC-DEMO**. A unidade reservada e a empresa sem membership não são autorizadas. Tenant, empresa, unidade e centro continuam identificadores distintos, sem equiparação automática.
+
+## Guião funcional da equipa
+
+Usar entradas decimais com ponto. Para o exemplo sem imposto desta prova, indicar total e subtotal iguais; isto não configura uma taxa fiscal. Os valores e saldos abaixo são MZN.
+
+1. **Preparação:** entrar, seleccionar empresa/unidade e abrir Compras. Criar dotação de **1000.00** em ORC-DEMO, exercício actual, corrente, base com imposto indicado e fundamento sintético. O estado fica pendente e o total aprovado/disponível é zero, sem autorização presumida.
+2. **Validação:** sair/entrar com a conta de validação, seleccionar o contexto e aprovar. Conferir dotação aprovada **1000.00**, actor e data. A preparação não pode aprovar a sua proposta.
+3. **Operação:** seleccionar a dotação e a origem **SIM-COMPRA-001**. Reservar **300.00** (total e subtotal): reservado 300, disponível 700. Registar ajuste de adjudicação para **350.00**: reservado 350, disponível 650. Registar compromisso **350.00**: reserva zero, compromisso 350 e disponível 650.
+4. **Operação:** em consumo simulado, usar a mesma origem, referência **SIM-CONSUMO-001** e total/subtotal **100.00**. Conferir compromisso 250, consumo 100 e disponível 650. Repetir a mesma referência/valores: não surge segundo consumo. Não é criada factura, obrigação, pagamento ou lançamento.
+5. **Preparação:** propor reforço **200.00**, referência **SIM-REFORCO-001** e fundamento. Disponível continua 650 enquanto pendente. **Validação:** aprovar distintamente. Conferir total aprovado 1200 e disponível **850.00**, com dotação inicial 1000 preservada.
+6. **Operação:** na origem separada **SIM-COMPRA-LIBERTAR**, reservar 200 e libertar antes de compromisso. Disponível volta a 850. Repetição não duplica a libertação; compromisso posterior à libertação é recusado. Uma origem já comprometida não recebe nova libertação por este circuito.
+7. **Consulta:** conferir cartões de saldo, tabela dos deltas, origem, dotação, actor, data, referência do consumo e histórico expansível. Esta conta não mostra formulários de escrita; pedidos directos sem direito também são recusados.
+
+A dotação seleccionada determina os centros/origens apresentados nos formulários; campos de operação só aparecem para dotação aprovada do exercício actual e com origem no mesmo centro. Se o cenário já estiver usado, conservar o histórico: não se reabre ou apaga uma origem para repetir a demonstração. A equipa pode rever/repetir os comandos idempotentes; cenários adicionais devem ser acrescentados explicitamente em QA, sem reset do trabalho anterior.
+
+As alterações de contexto limpam os formulários e não aplicam respostas tardias de outro contexto aos dados apresentados. Em erro de rede, repetir o mesmo conteúdo recupera a mesma chave de comando do formulário; o servidor mantém chaves por actor/contexto/acção e recusa conteúdo divergente.
+
+## Implementação e fronteira do núcleo
+
+- `resources/js/PurchasingBudgetWorkspace.jsx`: interface; recebe saldos do servidor, formata centavos com BigInt e não calcula disponibilidade/impostos. Preparação, operação, validação e consulta filtradas por direitos.
+- `resources/js/app.jsx`, `WorkspaceNavigation.jsx`, `WorkspaceHome.jsx`: montagem incremental nos componentes existentes e atalhos por função/unidade.
+- `app/Modules/Purchasing/BudgetController.php`: GET e POST do percurso, sob sessão, `auth_version`, CSRF e token de contexto existentes.
+- `BudgetWorkspace.php`: valida/normaliza entradas monetárias exactas, referências, sequência do cenário e comandos idempotentes; apresenta movimentos e auditoria. Não calcula deltas ou saldos financeiros.
+- `BudgetAdapter.php` e `packages/budget-control`: reutilizados **sem alteração**. O hash do núcleo coincide com as provas da extracção aceite em `f77900e`. Reserva/compromisso/consumo/reforço/libertação continuam com um único motor financeiro.
+- Novas tabelas exclusivamente QA: `cb_ui_commands` (recuperação/idempotência de pedidos) e `cb_consumption_sources` (referências de consumo simulado). A coluna histórica `invoice_id` do núcleo aponta, neste ensaio, para a referência sintética; não representa factura emitida ou contas a pagar implementadas.
+- `scripts/budget-demo-*`: provisionamento, servidor, acesso e estado. O provisionador usa a ferramenta PostgreSQL local já disponível em Compras para criar base/role **novas**, através da base de manutenção `postgres`; a aplicação SGF usa depois apenas a sua role QA restrita. Não existe dependência de um SGF remoto nem comunicação entre aplicações para executar os movimentos.
+
+## Provas técnicas e limites da revisão visual
+
+Prova reproduzível:
+
+```powershell
+powershell -NoProfile -ExecutionPolicy Bypass -File scripts/budget-workspace-proof.ps1
+```
+
+[Prova HTTP](proofs/budget-workspace-http.json): quatro sessões reais, login/logout, contexto e funções; dotação/aprovação, sequência 300→350→compromisso→consumo100→reforço200, valores exactos 650/850 disponíveis; referência/consumo únicos; insuficiência de saldo; precisão não representável recusada sem arredondar; falha por consumo excessivo com rollback da referência e recuperação; replay igual e conflito de conteúdo; libertação única sem reabertura; proibição de escrita por consulta; origem de outro âmbito, unidade reservada e contexto antigo recusados; CSRF activo. Base/role da prova removidas no final e sem alterações ao cenário da equipa.
+
+`scripts/budget-workspace-render-check.mjs`: formatação exacta dos valores, deltas negativos, maior valor suportado, desconhecido como indisponível e navegação por unidade. O teste de início/menu existente também passou. Build SGF e sintaxe PHP/PowerShell passaram. Não se instalaram nem actualizaram dependências. A regressão destrutiva SGF não foi apontada para `sgf_tempo_test`; preservou-se a demonstração existente. As provas aceites de concorrência do núcleo mantêm-se; não se atribui concorrência de browsers a esta bateria HTTP sequencial.
+
+**A interface existe agora e está disponível para a equipa.** A validação foi técnica por HTTP, verificação de componentes/formatação e compilação; **não foi realizada nova revisão visual no navegador nem se presume aceitação da equipa**. O bloqueio anterior da automação não foi usado como dependência para implementar ou disponibilizar este percurso. A revisão visual de Compras e os dois testes MFA ignorados continuam pendências da entrega anterior; este incremento não os encerra.
+
+## Limites de implantação e continuação
+
+Sem migração em bases existentes, sem concessões reais, sem utilização real habilitada, sem novo motor e sem alterações ao orçamento industrial. O adaptador continua bloqueado fora do ambiente/base QA. O schema é preparado por scripts sintéticos, não por migrações registadas para aplicar em desenvolvimento/produção. Migração operacional, regras fiscais/contabilísticas e instalação completa de Compras permanecem fora desta entrega.
+
+Próximo passo: a equipa percorre o guião e regista função, referência sintética, passos e resultado observado/esperado. Corrigir dificuldades concretas preservando origens e histórico; decidir aceitação separadamente. Não houve novo commit/checkpoint de encerramento, push ou publicação.

docs/SUPPLIER_PAYABLE_DELIVERY.md

@@ -0,0 +1,105 @@
+# Obrigação a fornecedor — entrega técnica em verificação
+
+29/10/2026. `COMMON-PAYABLE-SOURCE-SIM-v1`, [especificação e regras aprovadas](SUPPLIER_PAYABLE_SCOPE.md). **Implementado apenas em QA, sem aceitação ou checkpoint de encerramento presumidos.** O exemplo executado é o aprovado mais recentemente: base **10 000 MZN**, imposto documental **1 600 MZN**, principal **11 600 MZN**. Exemplos anteriores de 1 160 MZN na especificação são históricos; não são os valores desta entrega.
+
+## Resultado e responsabilidade financeira
+
+Uma factura criada e conferida pelos serviços existentes de Compras origina uma proposta e, por identidade distinta, **uma obrigação reconhecida** no núcleo comum. A origem, fotografia, captura/revisão, decisão e histórico são recuperáveis. O principal é exactamente `total_minor=1160000`, sem recálculo de imposto ou presunção de aplicabilidade fiscal real.
+
+O vencimento continua nulo. A consulta apresenta **«Principal reconhecido — vencimento pendente»**, **«Atraso indeterminado»** e **«Dias de atraso: sem valor»**. A consulta com relógio em 2030 conserva estes valores: nenhuma classificação automática de vencida/não vencida ou zero dias de atraso.
+
+Compras já tinha dívida implícita em `ExternalPaymentWorkflow::outstanding` (total da factura menos pagamentos confirmados). A leitura de uma origem reconhecida neste ensaio passa a obter o principal canónico de Payables, revalidando versão/eligibilidade; não mantém outro principal editável. A factura permanece original documental. Para origens fora do ensaio, o percurso anterior mantém o cálculo existente. No ambiente normal a nova capacidade fica desactivada e não consulta tabelas Payables.
+
+Pagamentos do circuito antigo são recusados para a origem reconhecida do novo ensaio. Documentos com **qualquer histórico de pagamentos associado**, mesmo pendente, não entram como dívida integral nova; ficam pendentes/conflituosos. Se aparecer história/alteração incompatível após reconhecimento, o principal histórico é preservado e o saldo fica indeterminado/recusado, não recalculado ou liquidado automaticamente. A migração/reconciliação desses históricos e os novos pagamentos continuam fora do âmbito.
+
+## Fonte comum, adaptadores e interface
+
+| Localização | Responsabilidade |
+| --- | --- |
+| SGF `packages/payables/src/Payables.php` e `bootstrap.php` | Fonte única: origem estável, propostas/capturas, reconhecimento, unicidade, comandos, histórico e outbox transaccionais. Contexto/actor/pessoa e callbacks explícitos, sem sessão no motor |
+| SGF `packages/payables/src/Workspace.php`, `ui/page.php` | Interface HTML partilhada, com preparação, validação e consulta. Escapa conteúdo, usa sessão/CSRF/contexto do host e não permite editar fornecedor, montantes, imposto ou vencimento |
+| Compras `app/Services/SupplierPayables.php` | Lê factura, linhas, decisão e pagamentos reais **da base QA**; confere tenant/perfil/permissões sintéticas e fornece a fotografia; projecta a leitura financeira canónica |
+| Compras `app/Http/Controllers/SupplierPayablesController.php`, rotas e ligação na página de facturas | Interface/JSON no host autónomo, protegidos pela autenticação/empresa existentes e direitos de função explícitos |
+| SGF `app/Modules/Purchasing/SupplierPayables.php` e controlador correspondente | Revalida membership, empresa/unidade, direitos e identidade de pessoa; lê uma projecção do documento efectivamente conferido em Compras, mapeada explicitamente para o contexto SGF |
+| SGF `routes/web.php`, `resources/js/app.jsx`, `WorkspaceNavigation.jsx` | Entrada no SGF por **Compras → Obrigações a fornecedores — ensaio**, sem habilitar a função a contas reais |
+| Compras `config/common-payables.php` e providers dos dois hosts | Carregamento local do mesmo pacote. Compras aceita artefacto instalado em `packages/payables`/`COMMON_PAYABLES_PATH`; fallback para a fonte vizinha só fora de produção. Sem dependências instaladas/actualizadas |
+
+Não existe outro motor Payables em `App/Services`/`App/Modules`: os adaptadores só tratam origem, autorização e apresentação. O núcleo orçamental aceite não foi alterado. Não se reutilizou contas a receber de clientes como contas a pagar nem se exigiu facturação de vendas. As duas demonstrações são instalações isoladas da mesma capacidade, não duas aplicações a comunicar em cada operação.
+
+## Origem exacta, integridade e versões
+
+O cenário de origem usa fixture própria em `packages/payables/tests/ReceiptFixture.php` para os pressupostos fixos 10 000/1 600/11 600; os comportamentos são executados por `ReceiptWorkflow`, `BudgetWorkflow` e **`InvoiceWorkflow::register/validate` existentes**, não por um novo conferidor. A factura fica `validated`, com actor/data e evento `invoice.validated` recuperáveis. A preparação dessa origem cria os efeitos normais de recepção/conferência **antes** do baseline da prova; a ligação Payables não os repete.
+
+A identidade canónica combina instância de origem persistente, empresa de origem e ID estável da factura; o tipo de origem está delimitado pelo adaptador de facturas de fornecedor. A restrição comercial empresa/fornecedor/número normalizado já é assegurada pelo cadastro Compras. Não existe neste recorte outro importador público que aceite livremente esses identificadores ou monte documentos novos no browser. Importações gerais/aliases entre origens distintas exigirão validação de identidade própria antes de implantação.
+
+`source_revision` é hash canónico do documento/linhas/decisão, não uma coluna de versão nativa inventada. `capture_version` identifica propostas/capturas imutáveis; uma versão nova não é chave para criar outra dívida. IDs locais de apresentação e contagem de pagamentos não entram no hash material, mas o histórico de pagamentos é revalidado separadamente em todas as decisões/replays. O original e todas as propostas anteriores permanecem append-only.
+
+No SGF, o provisionamento importa privadamente uma projecção da mesma factura conferida, produzida pelo adaptador Compras e com recibo/hash de integridade. O hash não é assinatura digital nem uma nova validação de autenticidade; a proveniência desta prova é a execução local documentada dos serviços Compras. Não existe redigitação ou upload de factura no SGF. As provas de alterações de origem usam injecção adversarial em bases descartáveis, nunca nos exemplares da equipa ou em dados reais.
+
+## Atomicidade, estados e segurança
+
+- Um preparador propõe; o validador deve ter outro ID **e** outra identidade de pessoa. Direitos/contexto e o mapeamento de pessoa são revalidados dentro do bloqueio da organização, inclusive após espera e em repetição.
+- Origem sem fornecedor, moeda MZN, valores/linhas ou decisão sustentados fica pendente/conflituosa, sem principal zero presumido. Falta de vencimento é independente e não impede o reconhecimento aprovado do principal.
+- `pa_sources.source_key` é único globalmente no ledger; `pa_obligations.source_id` é único e não inclui revisão ou chave de comando. Pedidos com chaves diferentes não duplicam a obrigação. Mesmo comando/conteúdo recupera o resultado; conteúdo divergente com a mesma chave é conflito.
+- Proposta, obrigação, evento, outbox e resultado do comando são atómicos. Eventos são captura durável, sem publicar para contabilidade ou serviços externos. As tabelas de origem/histórico/obrigação/comando/outbox têm triggers append-only em QA.
+- Alteração de origem ou revisão desactualizada produz conflito registado com hash observado e preserva principal/decisão originais. Não altera total, reduz dívida ou substitui original automaticamente. Não há circuito de correcção monetária/anulação nesta entrega.
+- CSRF, autenticação e, no SGF, token de contexto mantêm-se activos. Os scripts de falhas/concorrência recusam as bases persistentes da equipa e só operam nas bases descartáveis de prova.
+
+## Demonstrações para a equipa
+
+**Compras autónomo:** http://127.0.0.1:8005/obrigacoes-fornecedores. Entrar normalmente em `/login`; a página de facturas também apresenta a ligação no contexto sintético elegível.
+
+**ERP SGF:** http://127.0.0.1:8006. Entrar, seleccionar **Horizonte Sintética — Obrigações / Unidade de obrigações**, abrir **Compras → Obrigações a fornecedores — ensaio** e a ligação de preparação/consulta. A página partilhada conserva autenticação e contexto; não se abre uma sessão remota no outro produto.
+
+| Função | Conta sintética nos dois hosts | Acções |
+| --- | --- | --- |
+| Preparação | `preparacao-obrigacoes@example.test` | Consultar origem e preparar proposta, sem redigitar montantes |
+| Validação | `validacao-obrigacoes@example.test` | Consultar e reconhecer a revisão exacta por identidade distinta |
+| Consulta | `consulta-obrigacoes@example.test` | Origem, principal, pendências, decisão e histórico; sem comandos de escrita |
+
+Passwords aleatórias próprias de cada instalação estão apenas nos ficheiros locais protegidos `C:\laragon\data\sgf-tempo\secrets\payables-demo-compras-access.json` e `payables-demo-sgf-access.json`, campo `accounts`. Consultar localmente; não copiar para chat, capturas ou repositório. Nenhuma conta/concessão real foi alterada.
+
+Guião: preparador selecciona **FT-SIM-11600** e fundamenta; validador consulta a fotografia/captura e reconhece; consulta confirma **11 600,00 MZN**, origem/versão e vencimento/dias nulos. Repetir a preparação/validação deve recuperar a mesma identidade. Não há formulário de pagamento, cobrança, data inventada, stock ou lançamento. O cenário foi preparado sem propostas/reconhecimentos pré-preenchidos; a revisão da equipa permanece por realizar.
+
+```powershell
+powershell -NoProfile -ExecutionPolicy Bypass -File scripts/payables-demo.ps1 status
+powershell -NoProfile -ExecutionPolicy Bypass -File scripts/payables-demo.ps1 start
+powershell -NoProfile -ExecutionPolicy Bypass -File scripts/payables-demo.ps1 stop
+```
+
+As duas bases/roles são próprias e restritas (sem superuser, CREATEDB ou CREATEROLE), com sessões/caches/cookies/chaves separados. O provisionamento usa a ligação local de manutenção `postgres` apenas para criar essas bases/roles novas; cada host executa com a sua role QA. `start` retém cenários existentes e recusa portas ocupadas; `stop` só termina os servidores próprios e mantém os dados. O orçamento da equipa em **8003** e a demonstração anterior em **8002** não foram parados, resetados ou usados para estas provas. Tudo está limitado a loopback; não houve publicação.
+
+## Provas técnicas
+
+```powershell
+powershell -NoProfile -ExecutionPolicy Bypass -File scripts/payables-demo.ps1 proof
+powershell -NoProfile -ExecutionPolicy Bypass -File scripts/payables-demo.ps1 proof -HistoryOnly
+```
+
+Evidências: [duas composições](proofs/payables-http.json) e [recusa de históricos liquidados](proofs/payables-history.json). Bases descartáveis e roles removidas no final. Os SHA-256 do motor e da fotografia inicial coincidem entre os hosts. Não foram copiadas contas/sessões/credenciais entre as aplicações.
+
+**Percurso HTTP real nos dois hosts:** login de três funções, origem conferida com base/imposto/total exactos, preparar, validar distintamente, consultar uma obrigação, repetir com a mesma/nova chave e verificar identidade/saldo únicos. HTML dos três perfis conferido por HTTP: preparação/validação onde autorizado, consulta sem formulários de escrita, principal e pendência apresentados. A origem incompleta não é reconhecida; a revisão antiga é recusada. Vencimento/dias continuam nulos com relógio em 2030.
+
+**Seis cenários PostgreSQL concorrentes**, três por host, com processos/ligação independentes e dois waits de bloqueio observados por cenário: preparação simultânea com chaves diferentes, validação com direito revogado durante a espera (duas recusas), reconhecimento simultâneo (uma obrigação/um evento de reconhecimento). Não se afirma teste de carga ou de todas as ordens de escalonamento.
+
+**Falhas e integridade:** falha SQL injectada antes do evento de reconhecimento reverte obrigação/outbox/comando; repetir a mesma chave após recuperação conclui uma vez. Contexto/unidade e actor de outra empresa, chave com outro conteúdo, ausência de CSRF e source hash/valor alterado são recusados ou sinalizados. Checksums das tabelas de factura/linhas/orçamento/stock/pagamentos antes/depois do percurso coincidiram em Compras. O ledger comum tem um evento durável por efeito, com outbox correspondente.
+
+**Históricos associados:** uma fixture de pagamento confirmado anterior de 300 MZN, exclusivamente na base descartável, deixa o saldo legado de 11 300 MZN preservado e impede constituir uma obrigação como se os 11 600 estivessem integralmente por pagar. A representação SGF usa a projecção desse histórico. O comando novo não altera esses registos, não os confirma outra vez nem os liquida. Esta é prova de recusa/preservação, **não** implementação de pagamentos ou migração de históricos. Também se testou a detecção de histórico incompatível após reconhecimento, preservando o principal e deixando o saldo indeterminado.
+
+**Regressões:** Compras **498 aprovados, 2 ignorados, 4 141 asserções**. PHPStan sem erros e Pint dos ficheiros de produção alterados aprovado. Builds Compras e SGF aprovados, sem actualizar manifests/lockfiles. Uma primeira execução concorrente com o build teve falha transitória do ficheiro de fonte no dashboard; depois de estabilizar os assets, a bateria completa voltou a passar. Não se mudou código para ocultar essa falha. A suite destrutiva SGF não foi executada sobre as demonstrações existentes; o delta foi provado pelo host SGF isolado e pelas verificações de sintaxe/compilação.
+
+Os dois ignorados continuam os testes MFA já documentados em `COMMON_BUDGET_ACCEPTANCE.md`: `users with two factor enabled are redirected to two factor challenge` e `security page is displayed`, dependentes da funcionalidade two-factor desactivada nesta configuração. Não cobrem o reconhecimento monetário deste incremento; a cobertura MFA permanece pendente. **Não foi feita revisão visual em navegador nem se atribui aceitação manual à equipa**: as provas de interface são HTTP/HTML e compilação. Não se contornou o bloqueio anterior de Computer Use. As pendências visuais de Compras/orçamento e MFA são preservadas.
+
+## Ficheiros e migrações
+
+Fonte comum: `packages/payables/{bootstrap.php,src/Payables.php,src/Workspace.php,ui/page.php,qa-schema.php,tests/ReceiptFixture.php,tests/seed.php}`. Adaptadores/controladores e providers acima. Compras: alterações delimitadas em `ExternalPaymentWorkflow.php`, `InvoiceController.php`, `resources/js/pages/invoices/index.tsx`, `routes/web.php`, `config/common-payables.php` e `.gitignore`. SGF: montagem de menu/rotas, `.gitignore` e scripts `payables-provision.php`, `payables-router.php`, `payables-demo.ps1`, `payables-http-proof.mjs`, `payables-probe.php`, `payables-status.php`. Relatórios/provas/instruções documentais actualizados sem encerrar requisitos globais.
+
+`qa-schema.php` não está registado nas migrações operacionais. Cria apenas em QA `pa_access`, `pa_sources`, `pa_proposals`, `pa_obligations`, `pa_commands`, `pa_events`, `pa_outbox`; no SGF acrescenta-se a projecção local `pa_imported_sources` e o direito de navegação QA. Não foram aplicadas migrações em `compras_dev`, `sgf_tempo_dev`, `sgf_tempo_test` ou produção; nem concedidos direitos reais.
+
+Uma futura migração operacional terá de resolver cadastros/IDs definitivos, constraints compostas de pertença e modelo de acessos, preservar origens/comercial identity/versões, ensaiar backup/restauro e reconciliar pagamentos históricos antes da passagem de autoridade. Não se apresenta este schema de fixture como migração pronta para clientes. A distribuição autónoma terá de incluir o artefacto local versionado do pacote; não se criou instalador comercial nesta entrega.
+
+## Limites e continuação
+
+Sem pagamentos, cobranças, afectações, devoluções, notas de crédito, redução/anulação financeira, lançamentos, efeitos adicionais de stock/orçamento ou activação real. Vencimento desconhecido é suportado; a revisão de uma data sustentada e planos de prestações ficam para recorte próprio. O importador SGF é um recibo de QA preparado pelos serviços, não um circuito geral de documentos em produção ou integração remota.
+
+Próximo passo: a equipa testa as duas interfaces e relata função, origem/captura, passos e resultado observado; corrigir deltas sem apagar originais. Aceitação e checkpoint exclusivamente local só depois da decisão do responsável. Sem commit de encerramento, push ou publicação nesta entrega.

docs/SUPPLIER_PAYABLE_SCOPE.md

@@ -0,0 +1,227 @@
+# Factura conferida → obrigação a pagar — primeiro recorte sintético
+
+**Execução posterior, 29/10/2026:** [primeiro percurso implementado e provas](SUPPLIER_PAYABLE_DELIVERY.md). Cenário aprovado de execução: **10 000 + 1 600 = 11 600 MZN**, vencimento desconhecido. A marcação de «não implementado» e exemplos 1 160 MZN abaixo conservam o estado da especificação original; não substituem o relatório de execução. Sem aceitação operacional ou migração real.
+
+29/10/2026. `COMMON-PAYABLE-SOURCE-SIM-v1`. **Conferência do existente e delimitação; não implementado nesta passagem.** Orientação expressa da Tempo: uma factura de fornecedor conferida origina uma obrigação, reutilizando os dados; sem pagamento, stock ou lançamento automático. O orçamento entregue e a avaliação da equipa continuam independentes.
+
+**Especificação completada na mesma data:** secções 9–13 detalham a matriz de reaproveitamento, transição com pagamentos históricos, funções, estados e exemplo para confirmação. A orientação comum posterior da Tempo consta da secção 14 e prevalece sobre escolhas técnicas anteriores: vencimento desconhecido gera pendência documental, sem inventar data, apagar dívida ou se tornar, por inferência, uma regra universal que impeça reconhecer o principal. A passagem de responsabilidade é atómica e sem dois saldos activos. Mantém-se exclusivamente documentação nesta actualização.
+
+## 1. O que já existe
+
+Referências Compras relativas a `C:/laragon/www/compras`:
+
+| Capacidade observada | Evidência | Consequência para o recorte |
+| --- | --- | --- |
+| Factura recebida por fornecedor/ordem, número normalizado e unicidade | `app/Services/InvoiceWorkflow.php::register`; `database/migrations/2026_10_28_000010_create_invoices.php`, unique tenant/fornecedor/número | Reutilizar o registo existente; não criar outro cadastro de factura ou redigitar fornecedor/montantes |
+| Conferência exacta de linhas, preços, unidade, imposto e recepções aceites; parcial cumulativa | `InvoiceWorkflow::lines` e `validate` | Reutilizar a conferência; não recalcular documento com a política de IVA de vendas do SGF |
+| Actor de validação distinto, revalidação transaccional e auditoria | `InvoiceWorkflow::validate`, `CurrentActor`, `ConflictGuard` | A origem deve identificar a decisão e a fotografia efectivamente conferidas |
+| Consumo do compromisso na validação | `InvoiceWorkflow::validate` → `CommonBudget` → núcleo comum | A criação da obrigação não volta a chamar `consume`, reservar orçamento ou gerar stock |
+| Factura/linhas preservadas | `app/Models/Invoice.php`, `InvoiceItem.php` | Não editar montantes/data/número da factura através da obrigação |
+| Saldo a pagar implícito já existente | `ExternalPaymentWorkflow::outstanding`: total da factura menos pagamentos externos confirmados | É uma dívida já representada implicitamente. Criar uma segunda base independente de saldo produziria concorrência contabilística/funcional |
+| Pagamentos externos, conferência, protecção por referência e validação bancária | `ExternalPaymentWorkflow.php` | Preservar; não refazer, executar ou ampliar pagamentos neste recorte |
+| Condições de pagamento congeladas como texto na ordem | `PurchaseWorkflow.php`, `snapshot.quotation.payment_terms` | Texto reutilizável como evidência; não é uma data de vencimento estruturada nem autoriza interpretar automaticamente «30 dias» |
+| Sem vencimento estruturado ou coluna de versão na factura inspeccionada | Migração 000010, `InvoiceController.php`, `Invoice.php` | Faltam complemento documental de vencimento e identificação explícita da revisão/fotografia da origem |
+| Correcções de facturas/notas de crédito ainda fora do circuito entregue | Imutabilidade de `Invoice.php`; limites de `docs/validacao-tecnica.md` | Não inventar um circuito de correcção fiscal/monetária através de uma edição de obrigação |
+
+No SGF, `ServiceReceivables` trata obrigações **a receber de clientes**, exclusivamente no âmbito demonstrado. Não é contas a pagar a fornecedores. `packages/budget-control` trata efeitos orçamentais e não cria dívidas. O novo serviço comum terá responsabilidade distinta, sem transformar estes módulos em outro motor de contas a pagar.
+
+Esta conclusão resulta de leitura de código/migrações/documentação. Não se consultaram bases, credenciais ou dados reais, nem se executaram testes ou migrações nesta delimitação.
+
+## 2. Capacidade comum e responsabilidade única
+
+Proposta técnica: `Finance/Payables`, fonte única versionada, consumida por adaptadores locais de Compras e SGF. Pode ser um pacote separado do controlo orçamental; não duplicar o seu motor em `App/Services` e `App/Modules`. Mantém o princípio de duas composições comerciais sem obrigar a facturação de vendas SGF ou SGF remoto.
+
+- **Compras:** conserva fornecedor, ordem, factura, linhas e decisão de conferência. O adaptador carrega esses dados da aplicação, revalida actor/organização/estado e prepara a origem normalizada. Não aceitar um total ou fornecedor alternativos enviados pelo browser.
+- **Payables comum:** é o único proprietário da obrigação, do principal reconhecido neste recorte, do vencimento associado, das revisões documentais e do histórico. Importar não equivale a efectuar pagamento ou lançamento contabilístico.
+- **Leitura de saldo em Compras:** para uma origem abrangida pelo novo núcleo, a base do saldo existente deve ser uma projecção da mesma obrigação. `outstanding()` não pode continuar a manter uma interpretação financeira independente dessa origem. Compatibilidade de leitura é parte da transição, sem desenvolver afectações/pagamentos novos.
+- **Origem não abrangida:** o percurso existente mantém o comportamento anterior, sem migração/importação em massa. A existência de histórico não autoriza criar ou liquidar retroactivamente obrigações.
+- **SGF:** adapta contexto tenant/empresa/unidade e permissões próprias. IDs de fornecedor/factura de Compras não são IDs de clientes, facturas de venda ou empresas SGF por igualdade numérica.
+
+Antes de disponibilizar a obrigação, provar que as consultas para o documento abrangido apontam à mesma identidade/principal. Se o adaptador de leitura de saldo ainda não existir, a capacidade permanece pendente, não se apresenta uma segunda lista de dívidas como funcionalidade concluída. Nenhum comando de pagamento será disponibilizado no cenário novo deste recorte; os circuitos reais existentes não serão alterados por arrasto.
+
+## 3. Dados reutilizados e dados efectivamente em falta
+
+| Origem reutilizada automaticamente | Complemento necessário |
+| --- | --- |
+| Empresa/contexto, fornecedor e sua referência documental preservada | Correspondência explícita de contexto no host SGF, sem inventar unidade a partir do departamento |
+| Identificador/número da factura, ordem, linhas, moeda, subtotal/imposto/total em centavos | Vencimento estruturado, evidência/base e revisão desse complemento |
+| Estado `validated`, actor/data da conferência e histórico | Identidade da fotografia validada, incluindo conteúdo material e decisão |
+| Condições textuais da ordem quando disponíveis | Confirmar a data sintética em falta; não deduzir calendário, tolerância ou prazo legal do texto livre |
+
+Para a primeira prova: fornecedor fictício, factura fictícia efectivamente conferida pelo circuito Compras, **MZN**, valor proveniente da factura e vencimento explícito no complemento sintético. Pedir só o vencimento/evidência que não existem; não solicitar nova introdução do valor ou do fornecedor.
+
+Não há coluna `invoice.version` entregue. Não atribuir silenciosamente «versão 1 validada» a um campo inexistente. Proposta: revisão de captura imutável no contrato de origem, com hash canónico do documento/linhas e referência da decisão de conferência. A revisão é do registo de origem do núcleo, com proveniência explícita; não simula versionamento nativo da factura. O adaptador deve detectar qualquer mudança material antes de reutilizar essa referência.
+
+## 4. Identidade, repetição e atomicidade
+
+Identidade canónica: organização explícita + namespace/instância da origem + tipo de documento + identificador estável da factura. Revisão/hash/decisão identificam a fotografia; **não** criar uma obrigação nova só porque apareceu outra revisão ou outro hash da mesma factura. Tenant/número da factura isolados não bastam como chave global; preservar também a unicidade comercial já existente em Compras.
+
+Contrato de origem proposto: identificadores de organização/fornecedor/documento/ordem, referência/edição de captura, hash, moeda, total inteiro, decisão/actor/data da conferência, vencimento/complemento/evidência e indicação de ambiente sintético. Chaves técnicas de comando e identidade de negócio são distintas: comandos novos sobre a mesma origem continuam a resolver a mesma obrigação.
+
+Uma transacção local deve revalidar permissões e a origem sob bloqueio, verificar estado/revisão, resolver unicidade e gravar obrigação/referências/histórico/resultado do comando atomicamente. A origem e a obrigação não dependem de publicação de eventos ou conector remoto para este recorte. Repetição idêntica devolve a mesma identidade; mesma chave com conteúdo diferente é conflito; resposta perdida é recuperável. Índices únicos e bloqueios devem impedir duas dívidas em pedidos concorrentes com chaves diferentes.
+
+O total permanece em centavos exactos e MZN. Não alterar precisão, arredondamento cumulativo da factura ou IVA; não usar câmbio, valor líquido em vez do total devido ou zero como substituto de dados ausentes. A regra de emissão de venda SGF não intervém.
+
+## 5. Pendências e correcções preservando o original
+
+- Factura não conferida, identidade/organização incompatível, moeda não suportada, montante indeterminado, decisão não recuperável ou vencimento em falta: registar motivo e origem da tentativa como **pendente**, sem abrir outra dívida nem reconhecer valor zero.
+- Repetir a mesma pendência não acumula dívidas. Completar o vencimento gera revisão do complemento e permite retomar a mesma origem; não revalidar genericamente a factura nem pedir os dados já válidos.
+- Corrigir vencimento/evidência: revisão documental sucessora, com motivo, autor, referência à anterior e histórico; mesma identidade de obrigação, sem reescrever a factura ou aumentar o principal.
+- Documento/hash materialmente diferente para a mesma identidade: conflito/pendência explícita. Não somar os dois totais nem substituir o principal por «última versão» automaticamente.
+- Correcção de valor, fornecedor ou moeda após constituição: fora da execução inicial. Preservar original e sinalizar necessidade de circuito próprio de documento correctivo/revisão. Um novo exemplar sintético não fica automaticamente conferido. Não implementar estorno, nota de crédito, anulação ou baixa financeira por interpretação desta orientação.
+
+As regras de autorização exactas para revisão documental serão explicitadas no contrato de implementação: reutilizar a elegibilidade de Finanças/consulta e os mecanismos de separação existentes; não acrescentar aprovadores empresariais universais. Para as provas, contas distintas de preparação/conferência/consulta, sem pessoas reais ou concessões reais.
+
+## 6. Primeiro recorte e pontos de integração
+
+1. Um fornecedor e uma factura MZN criados/conferidos pelas fixtures e serviços existentes de Compras, com histórico/orçamento necessários preparados em base QA isolada. Manter uma prova de que a nova ligação, depois da conferência, não acrescenta consumo orçamental ou stock.
+2. Adaptador de origem Compras carrega a fotografia; núcleo comum resolve pendências e cria **uma** obrigação com valor/vencimento/origem/histórico. Consulta mínima permite recuperar a obrigação e explicar a sua proveniência.
+3. Adaptador SGF demonstra a mesma capacidade comum em contexto sintético explicitamente mapeado. Não apresentar uma factura preenchida manualmente no SGF como demonstração da ligação à factura conferida de Compras.
+4. Compatibilidade da leitura do principal/saldo do documento abrangido, sem implementar pagamento. Não extrair ou activar todo o `ExternalPaymentWorkflow` neste passo.
+5. Tudo em bases QA novas/separadas das demonstrações da equipa. Sem alterar o núcleo orçamental aceite, as bases de desenvolvimento/produção, concessões ou dados reais. Migrações de implantação ficam propostas separadamente; sem importação automática de facturas antigas.
+
+O gatilho pretendido é a conferência da factura. O desenho de implementação deve assegurar que uma falha na ligação não é apresentada como obrigação constituída: transacção local ou pendência recuperável e visível, conforme o recorte adoptado. Não marcar «a pagar no núcleo» antes de a gravação estar demonstrada. A falta de vencimento não apaga a conferência anterior nem volta a consumir orçamento quando a pendência é resolvida.
+
+## 7. Provas a executar na implementação
+
+| Cenário sintético | Evidência exigida |
+| --- | --- |
+| Factura conferida → obrigação | Mesmo fornecedor/total/MZN, vencimento explícito, decisão e revisão/hash recuperáveis; nenhum dado material redigitado |
+| Repetição, chave diferente e dois pedidos simultâneos | Uma identidade de obrigação e um principal, com unicidade de origem reforçada na base |
+| Resposta perdida/falha de histórico | Recuperação idempotente ou rollback; nenhuma dívida órfã ou confirmação fictícia |
+| Factura pendente/incompleta ou vencimento ausente | Pendência explicada; sem dívida adicional/zero presumido; retomada conserva a conferência |
+| Vencimento corrigido | Revisão sucessora e original recuperáveis; mesmo principal, sem segunda obrigação |
+| Montante/hash/fornecedor/moeda incompatível | Conflito ou pendência, sem substituir/somar principal automaticamente |
+| Leitura anterior e nova para a mesma origem | Mesmo principal/saldo derivado; nenhuma autoridade financeira concorrente |
+| Outra empresa/unidade ou direito revogado | Recusa no servidor e na transacção, incluindo replay |
+| Conservação dos efeitos anteriores | Contagens e valores orçamentais/stock/pagamentos/lançamentos antes/depois da ligação inalterados |
+| Duas composições | Mesmo núcleo/contrato/resultados e origem comprovada; nenhum Sales obrigatório, motor duplicado ou SGF remoto |
+
+As provas ainda não foram executadas neste recorte. Não repetir suites aceites por rotina: reutilizar o orçamento entregue e verificar apenas o delta de integração e as regressões afectadas. A avaliação da equipa em 8003 prossegue em paralelo, sem reset, alteração de contas ou pré-preenchimento desta nova capacidade.
+
+## 8. Estado e continuação
+
+Conferência e desenho concluídos documentalmente. `Finance/Payables`, complemento de vencimento, referência de revisão e adaptação da leitura de saldo **ainda por implementar**, sem migração proposta como já aplicada. Nenhum pagamento, movimento de stock ou lançamento foi criado nesta passagem. Não há nova aceitação funcional ou checkpoint.
+
+Este documento delimita T2 no plano existente; não cria outra matriz global de requisitos. FIS-SGF-13/15/16 mantêm critérios/estados anteriores. A fronteira de correcção monetária e a ausência de vencimento/versionamento nativo são lacunas concretas identificadas, não motivo para reabrir o orçamento entregue ou depender de pessoas reais.
+
+## 9. Matriz consolidada: existente, reutilização e lacuna
+
+| Área | Existe hoje / ficheiros de origem | Reutilização no incremento | Falta / responsabilidade proposta |
+| --- | --- | --- | --- |
+| Documento de fornecedor | `InvoiceWorkflow::register`, `Invoice`, `InvoiceItem`, migração 000010 | Mesma factura, fornecedor, ordem, linhas e totais conferidos; sem novo cadastro | Adaptador de origem que entrega o documento normalizado a Finance/Payables |
+| Conferência | `InvoiceWorkflow::validate`, `CurrentActor`, `ConflictGuard` | Decisão efectiva distinta do autor, revalidada sob bloqueio, com auditoria | Referência estável à decisão/fotografia e distinção explícita face ao reconhecimento no núcleo |
+| Dívida e saldo | `ExternalPaymentWorkflow::outstanding` | Reaproveitar total da factura e pagamentos confirmados já associados; conservar resultado | Responsável financeiro explícito e leitor de compatibilidade; nenhuma segunda base de saldo |
+| Pagamentos associados | `ExternalPayment`, `ExternalPaymentWorkflow::review`, migração 000012 | Preservar IDs, estado, montante, moeda, actor e histórico; apenas confirmados reduzem o saldo actual | Reconciliação/bindings na futura migração, sem executar ou copiar pagamentos como acontecimentos novos |
+| Vencimento | Texto `snapshot.quotation.payment_terms` em `PurchaseWorkflow`; sem `due_on` na factura | Apresentar texto congelado como evidência, sem o reinterpretar | Complemento documental versionado com data explícita, origem/evidência e validação sintética |
+| Revisão do documento | Factura e linhas imutáveis pelo percurso entregue; sem coluna `version` | Preservar original e hash material da fotografia validada | Referência da captura no contrato comum, sem fingir versão nativa ou incrementar a dívida por revisão |
+| Autorizações | Perfil Finanças/empresa em Compras; memberships e acções empresa/unidade no SGF | Cada adaptador revalida as próprias permissões/contexto | Contrato de actor comum; correspondência explícita dos âmbitos, não equivalência automática |
+| Idempotência | Unicidade comercial da factura; pagamentos com referência/hash | Manter restrições existentes | Unicidade da obrigação por origem estável e deduplicação também com chaves de pedido diferentes |
+| Histórico | Auditoria Compras, imutabilidade dos modelos | Conservar evidência anterior e ligá-la, sem copiar dados bancários privados | Histórico append-only de tentativas, pendências, decisões e revisões do novo núcleo |
+| Orçamento | Núcleo comum aceite, consumo na conferência | Reutilizar prova anterior e manter valores/movimentos | Nenhum efeito adicional na ligação; verificar delta zero |
+| Stock e contabilidade | Stock já em Compras; lançamentos gerais não fazem parte desta ligação | Apenas verificar ausência de novos efeitos | Fora deste incremento, sem lançamento implícito nem duplicação de recepção |
+| Duas composições | Arquitectura comum aprovada; adaptadores de orçamento já demonstrados | Mesmo padrão de fonte única e contratos locais, sem Sales obrigatório | Implementar Payables e adaptadores num recorte posterior, com QA próprio |
+
+## 10. Origem exacta e contrato de reconhecimento
+
+**Origem elegível:** registo `invoices` da mesma empresa, `status=validated`, `validated_by`/`validated_at` recuperáveis e decisão de auditoria correspondente; ordem emitida MZN e fornecedor/linhas/valores pertencentes ao mesmo contexto. Usar o exemplar efectivamente conferido, incluindo snapshot da contraparte na ordem, não a ficha corrente para reescrever a história. O adaptador deve recusar uma linha preenchida manualmente no SGF que apenas afirme ser «factura conferida de Compras».
+
+O principal da obrigação é `invoices.total_minor`, com `subtotal_minor` e `tax_minor` preservados como componentes documentais. Não usar o subtotal de uma dotação sem IVA como valor devido ao fornecedor. Valores são inteiros em centavos MZN e vêm do servidor; não aceitar principal/fornecedor alternativo no comando de reconhecimento. Conservar arredondamento cumulativo da factura e não aplicar a política de IVA de vendas do SGF.
+
+**Referência estável proposta:** `source_namespace` + `source_instance_id` persistente + `source_company_id` + `document_type=supplier_invoice` + `document_id`. A instância conserva identidade através de backup/restauro; clonar uma base para QA exige namespace de teste explícito, não alterar a identidade para contornar unicidade. A revisão não integra a chave que cria outra dívida: é uma fotografia sucessora da mesma origem. Manter ainda a identidade comercial empresa/fornecedor/número normalizado e, futuramente quando aplicável, edição/série documental. Um segundo ID local com a mesma identidade comercial fica em conflito para conferência, não gera outra obrigação nem é fundido automaticamente.
+
+**Fotografia de origem:** número/data/ordem/fornecedor/empresa/moeda, componentes monetários e linhas materiais, referência da validação, actor/data e hash canónico. Ordenar campos/linhas por critérios estáveis; excluir token de sessão, chave de pedido, consulta actual, pagamentos posteriores e timestamps técnicos sem significado material do hash documental. Uma alteração desses campos técnicos não cria revisão material. A revisão de captura pertence ao núcleo; deve estar identificada como tal porque a factura actual não tem versão nativa.
+
+**Vencimento:** data `YYYY-MM-DD` explícita no complemento, associada à fotografia, com evidência/fundamento e revisão. Não derivar da data da factura, da data actual ou do texto livre por uma regra inventada. Na primeira prova, a data é um pressuposto sintético indicado para confirmação. Data desconhecida permanece `null`, nunca hoje/zero/«30 dias» por omissão. Não confundir vencimento com data de emissão, conferência, reconhecimento ou pagamento.
+
+**Quatro factos diferentes:** conferência valida a factura contra as origens; reconhecimento constitui a obrigação no núcleo e liga a origem; pagamento constitui/liquida um acontecimento financeiro distinto; lançamento reconhece um efeito contabilístico segundo regra própria. Este incremento só propõe o segundo a partir do primeiro. A data do reconhecimento é auditada como data da operação no núcleo e não se apresenta como data de competência contabilística/fiscal. Datas e decisões anteriores mantêm-se.
+
+## 11. Estados, funções e correcções
+
+| Estado proposto | Significado | Efeito sobre principal/saldo |
+| --- | --- | --- |
+| Origem pendente | Factura ainda não conferida, prova insuficiente ou contexto incompatível | Não constituir obrigação nova; conservar origem/motivos, sem valor zero presumido |
+| Complemento pendente | Factura conferida e valor conhecido, mas vencimento/evidência em falta | Guardar uma única candidatura de origem; não somar outro principal. O saldo implícito de Compras continua visível e autoritativo até à passagem |
+| Pronta para reconhecimento | Origem e complemento completos/compatíveis, preparados e ainda sem decisão no núcleo | Nenhum pagamento, baixa ou novo efeito orçamental |
+| Reconhecida | Decisão sobre a revisão exacta, obrigação única e responsabilidade financeira transferida atomicamente | Principal proveniente da factura; saldo lido exclusivamente pelo responsável comum para esta origem |
+| Revisão documental pendente | Proposta de correcção de vencimento/evidência | A revisão aprovada anterior continua aplicável; não alterar principal/data efectiva em silêncio |
+| Conflito | Mesma identidade com conteúdo material incompatível, pagamentos inconciliáveis ou associação ambígua | Não gerar segunda obrigação nem substituir/somar principal; sinalizar conflito sem apagar dívida anterior |
+
+«Vencida/não vencida» é uma classificação por data de consulta explícita, separada destes estados e não uma liquidação. Com vencimento desconhecido, classificação desconhecida. «Liquidada/anulada/reduzida» não são comandos deste recorte. Registos históricos já pagos podem conservar essa situação na futura reconciliação, sem a migração executar pagamento ou produzir novo evento de liquidação.
+
+| Função sintética | Preparação/consulta permitida | Separação exigida na prova |
+| --- | --- | --- |
+| Preparador | Seleccionar factura existente, preparar complemento de vencimento/evidência e submeter revisão exacta | Não aprova a sua preparação nem altera o documento original |
+| Validador | Conferir origem/complemento e reconhecer ou devolver fundamentadamente a revisão preparada | Identidade distinta do preparador; não editar a proposta para a aprovar |
+| Consulta | Consultar origem, valor, vencimento/pendência, decisão e histórico | Sem criação, alteração, redução, anulação ou pagamento |
+
+Estas são funções do ensaio, não novos cargos obrigatórios nos clientes. Reutilizar actores elegíveis de Finanças em Compras e direitos próprios no SGF; a autorização de validar uma factura não confere automaticamente poderes de gestão de acessos, pagamento ou lançamento. Revalidar membership, âmbito e direito dentro da transacção, mesmo em replay. Uma mesma pessoa representada nos dois hosts não conta como duas identidades para se auto-validar.
+
+Correcção documental cria sucessor com `previous_revision`, motivo, autor, conteúdo, decisão e data. Sem sobrescrita da factura, fotografia ou decisão anterior. Alterar vencimento exige nova revisão documental exacta; mudar o hash/valor/moeda/fornecedor não é mera correcção de vencimento. O primeiro recorte recusa substituição financeira/redução/anulação/baixa e mantém a obrigação anterior visível até existir circuito próprio aprovado. Um novo exemplar do promotor/utilizador não herda a conferência do anterior.
+
+## 12. Transição que preserva pagamentos associados
+
+O primeiro cenário de construção é novo e sintético, sem pagamento. A futura migração de históricos é especificada para impedir perda de dívida ou dupla dedução, **não será executada neste incremento**:
+
+1. Inventariar por factura a identidade comercial, total conferido, pagamentos associados e estados/revisões. Confirmar que não existe já binding da mesma origem à obrigação comum. Não transportar detalhes bancários cifrados para relatórios ou assumir que hash prova pagamento.
+2. Reconciliar o saldo anterior: total da factura menos a soma dos pagamentos `confirmed`, exactamente como `outstanding()` hoje. `pending`/`rejected` não reduzem esse saldo, mas mantêm histórico e ligações. Não marcar pendentes como confirmados por importação.
+3. Criar/recuperar a obrigação com o **principal original**, ligar os acontecimentos históricos confirmados uma única vez pela sua identidade estável e conservar os IDs/decisões existentes. Não criar obrigação apenas pelo saldo residual e depois deduzir novamente os mesmos pagamentos.
+4. Conferir igualdade exacta do saldo antes/depois, integridade da moeda/organização e ausência de pagamentos sem origem. Excesso de pagamentos, divergência monetária ou correspondência ambígua ficam em conflito; não limitar automaticamente a zero, inventar crédito ou pedir novo pagamento.
+5. Na mesma transacção de passagem, activar o binding de responsabilidade e fazer a leitura legada da origem delegar no núcleo. Antes da passagem, só o saldo legado é autoritativo; depois, só a projecção comum. O registo da factura continua como original documental, não como outro ledger concorrente. Não somar as duas representações em relatórios.
+6. Serializar passagem e qualquer escritor antigo de pagamento para não perder confirmação concorrente. Esta coordenação e o adaptador de leitura têm de ser demonstrados antes de ligar históricos com pagamentos; se faltarem, essa migração fica explicitamente pendente, sem afectar o âmbito sintético novo.
+
+Unicidade deve ser imposta pela base tanto em `organisation/source/document` como no binding do pagamento histórico. A repetição através de outra chave de comando recupera a mesma obrigação e os mesmos bindings. Conteúdo diferente na mesma identidade gera conflito. Em falha de histórico/resultado de comando, rollback da transacção; após perda de resposta, devolver a identidade já comprometida. Não criar dívida na primeira gravação e «corrigir duplicados depois».
+
+Critérios adicionais de aceitação propostos, a juntar aos da secção 7:
+
+- Vencimento desconhecido: uma pendência com `due_on=null`; não inventar data nem apagar o saldo anterior; completar/revalidar retoma a mesma origem.
+- Duas propostas/pedidos com chaves diferentes e a mesma factura: uma obrigação; decisões concorrentes não aprovam duas revisões incompatíveis.
+- Alteração de vencimento após preparação: decisão sobre revisão antiga é recusada; original permanece recuperável. Alteração material do documento não herda reconhecimento.
+- Mesmo número com espaços/caixa diferentes e mesmo fornecedor: respeitar normalização/unicidade comercial; não criar segunda dívida por outro caminho de importação.
+- Proponente/validador ou âmbito revogado durante espera: recusa após bloqueio; nenhum efeito parcial; replay também verifica autorização.
+- Falha antes/depois do commit e recuperação: apenas um principal, uma decisão efectiva e um binding por origem.
+- Reconstituição histórica proposta: pagamentos confirmados ligados uma vez, pendentes preservados sem dedução; valores antes/depois iguais. Esta prova pertence à preparação de futura migração, não a pagamentos executados no primeiro recorte.
+- Nas duas composições: mesma implementação e fotografia de origem verificável, sem sessão no núcleo ou dependência de Sales/SGF remoto; nenhum reset da demonstração orçamental e nenhum efeito adicional nos seus movimentos.
+
+## 13. Exemplo numérico para confirmação — não executado
+
+Empresa **Horizonte Sintética**, fornecedor **Fornecedor Alfa Sintético**, ordem **OC-SIM-001**, factura **FT-SIM-001** emitida em **29/10/2026** e conferida por actor sintético distinto. Base **1 000,00 MZN**, imposto documental **160,00 MZN**, total **1 160,00 MZN**. Os 160,00 são um valor já conferido nesta hipótese de documento, não uma conclusão sobre taxa/dedutibilidade fiscal ou uma operação a recalcular no SGF.
+
+| Passo proposto | Resultado esperado |
+| --- | --- |
+| Seleccionar a factura conferida | Reutilizar fornecedor, ordem, data, base/imposto/total, linhas e decisão; principal candidato 116000 centavos |
+| Vencimento inicialmente desconhecido | Pendência explícita, data nula, sem obrigação adicional/zero; dívida implícita de 116000 continua preservada |
+| Preparador indicar **28/11/2026**, evidência «Condição sintética acordada para o ensaio» | Criar revisão do complemento, sem alterar a factura. A data é fornecida explicitamente; não foi calculada por regra automática de 30 dias |
+| Validador distinto reconhecer a revisão exacta | Uma obrigação de **1 160,00 MZN**, saldo **1 160,00**, vencimento 28/11/2026; binding de responsabilidade único e histórico |
+| Repetir com a mesma ou outra chave | Recuperar a mesma obrigação; dívida continua **1 160,00**, nunca 2 320,00 |
+| Tentar outro total para FT-SIM-001 | Conflito; principal/original preservados, sem nova dívida |
+| Propor vencimento **30/11/2026** com fundamento e validar sucessor | Nova revisão documental; principal permanece **1 160,00** e a data/revisão anteriores continuam recuperáveis |
+
+**Exemplo apenas de futura reconciliação histórica:** se a mesma factura tiver pagamento associado **confirmado de 300,00 MZN** e outro **pendente de 100,00 MZN**, o saldo anterior e posterior deve ser **860,00 MZN**. O principal comum continua 1 160,00; os 300,00 são ligados uma vez; os 100,00 pendentes não são deduzidos. Não criar principal 860,00 e voltar a deduzir 300,00, nem importar como dívida nova de 1 160,00 ignorando o pagamento. Nenhum desses pagamentos será criado ou executado na primeira prova.
+
+**Para confirmação do recorte:** proposta de reconhecimento por validador sintético distinto da origem/revisão exacta, com vencimento explícito ou desconhecido sinalizado conforme a orientação posterior da secção 14; correcções apenas documentais de vencimento/evidência; alterações monetárias e migração de facturas com pagamentos ficam fora da execução inicial. Não se presume autorização de utilização real. Orçamento e avaliação da equipa mantêm-se inalterados.
+
+## 14. Orientação comum de produto da Tempo — 29/10/2026
+
+**Confirmação expressa posterior da Tempo, na mesma data:** no cenário sintético, principal reconhecido e vencimento pendente podem coexistir. Sem data de vencimento sustentada, `due_on=null`, situação de atraso **indeterminada** e `days_overdue=null`; não usar zero, data da factura, data de reconhecimento ou data actual como substitutos. A interface apresenta «Principal reconhecido — vencimento pendente» e «Atraso indeterminado». Não classificar automaticamente como vencida/não vencida, nem calcular dias de atraso. Este critério não activa pagamentos, cobranças, juros ou lembretes.
+
+**Critério de aceitação adicional:** reconhecer a obrigação sintética de 1 160,00 MZN com data desconhecida, avançar a data de consulta e recuperar o registo; principal e identidade mantêm-se, vencimento e dias de atraso continuam nulos e não surge classificação de vencida. Só após guardar uma revisão com data sustentada é possível classificar por uma data de consulta explícita, preservando a situação documental anterior. Trata-se de prova futura especificada, não executada nesta actualização.
+
+Origem: oito regras de produto propostas expressamente pela Tempo para SGF e Compras. São referência do desenho comum, separadas de obrigações fiscais específicas; não constituem prova de implementação, conformidade fiscal, aceitação funcional ou activação operacional. O incremento em preparação continua limitado à obrigação a fornecedor; pagamentos, recebimentos, cobranças e lançamentos não entram por consequência desta orientação.
+
+| Regra comum | Aplicação ao desenho | Âmbito de implementação |
+| --- | --- | --- |
+| 1. Documento, dívida e liquidação separados | Factura é origem documental; reconhecimento é facto próprio; comprovativo, encomenda e reserva não provam liquidação nem dívida reconhecida | Neste recorte: factura conferida → obrigação única. Não criar estado «paga» por constituição/importação |
+| 2. Condições explícitas | Guardar moeda, vencimento, condições e, quando aplicável, prestações; desconhecido visível e sem datas inventadas. Banco/instrução não é dinheiro | Neste recorte: MZN, complemento de vencimento/condições e pendências. Modelação completa de prestações fica futura; não inventar uma prestação ou plano por omissão |
+| 3. Liquidações e afectações parciais | Várias liquidações por documento e uma liquidação para vários documentos compatíveis; saldo deriva de afectações, sem edição directa. Excesso permanece não afectado | Evolução futura do núcleo; não implementar agora pagamentos/recebimentos, afectações, reembolsos ou créditos. Preservar a dívida/pagamentos históricos numa futura transição |
+| 4. Confirmação e reconciliação distintas | Registo proposto, confirmação com evidência e reconciliação com caixa/banco são factos diferentes; upload não marca factura paga | Preservar essas distinções no contrato/histórico; não acrescentar reconciliação neste recorte |
+| 5. Protecção contra duplicação | Repetição recupera o resultado; origens, referências e afectações têm identidade e unicidade inclusive em concorrência | Neste recorte: unicidade da obrigação por factura, independentemente da chave de pedido; conteúdo incompatível gera conflito |
+| 6. Correcções rastreáveis | Confirmados não são apagados; correcção/reversão explícita liga ao original e conserva motivo/autorização/histórico. Mercadoria, factura e dinheiro têm circuitos distintos | Neste recorte: revisões documentais e conflitos sem sobrescrita. Reversões monetárias, devoluções, anulações e baixas não são activadas |
+| 7. Cobrança e aprovação | Acompanhar vencidos, prestações e contestação; lembretes, juros, descontos e bloqueios exigem configuração; separar poderes quando o circuito exigir | Neste recorte: consulta de vencimento conhecido/desconhecido e funções sintéticas. Não enviar mensagens, cobrar encargos ou impor bloqueios por omissão. Circuito completo de contestação/cobrança fica futuro |
+| 8. Um núcleo e responsabilidades | Compras fornece a factura conferida; Vendas o documento do cliente; Finance gere obrigações/recebíveis/liquidações; contabilidade trata os acontecimentos próprios sem repetir stock/orçamento | Fonte única Payables, adaptadores locais e responsabilidade financeira única. Não copiar o motor nem ligar obrigatoriamente Sales ou SGF remoto |
+
+**Precisão sobre vencimento e estados:** a proposta técnica anterior que exigia completar o vencimento antes de constituir a obrigação não se transforma em regra de produto. Se a origem/valor/decisão forem suficientes para reconhecer o principal, o desenho deve suportar **obrigação reconhecida com vencimento desconhecido**, `due_on=null`, pendência visível e classificação de atraso desconhecida. A pendência não impede recuperar a mesma identidade nem autoriza inventar data, apagar dívida ou duplicar o principal. Incompletude material da origem, montante, moeda ou autorização continua pendência/conflito de reconhecimento, distinta da falta de data. O estado «complemento pendente» da secção 11 passa a ser dimensão documental independente; pode coexistir com reconhecimento, sem um segundo saldo.
+
+O exemplo de 1 160,00 MZN mantém principal e impostos do documento. Se reconhecido antes de se conhecer o vencimento, continua 1 160,00 com data nula/pendência; completar 28/11/2026 gera revisão documental da **mesma obrigação**. Não é uma nova dívida nem pagamento. Uma encomenda/reserva anterior permanece outro facto e não é promovida a obrigação por si só.
+
+Esta orientação não revoga dados, decisões, pagamentos ou provas já preservados. As limitações existentes — incluindo dívida implícita de Compras, falta de versão nativa e funcionalidades de liquidação ainda não comuns — continuam identificadas. As capacidades futuras serão demonstradas por incrementos próprios, sem ampliar já esta entrega.

docs/WORKSHOP_BILLING_CORRECTION_DELIVERY.md

@@ -0,0 +1,59 @@
+# Correcção e cancelamento de rascunhos de oficina — entrega em verificação
+
+**Verificação técnica concluída:** regressão completa **183 testes / 3 209 asserções, zero falhas/erros**, incluindo oito casos novos; seis cenários concorrentes e build aprovados. Ver [resumo de provas](proofs/workshop-corrections-tests.json). Referências abaixo a regressão em execução são históricas. Prova manual/capturas e aceitação permanecem pendentes.
+
+28/10/2026. `WORKSHOP-BILLING-CORRECTION-SIM-v1`, [âmbito e decisões validadas](WORKSHOP_BILLING_CORRECTION_SCOPE.md). Preservados `3932b94`, `30029b9`, `d071bc0` e anteriores. Autorizada só implementação/prova sintética, sem migração/concessões em desenvolvimento ou utilização real. **Sem aceitação presumida ou checkpoint de encerramento.**
+
+## Comportamento
+
+Pedidos imutáveis por geração, com predecessor explícito, versões exactas dos dois destinos, motivo, origens e composição comercial. Tipos: substituição, cancelamento e desistência do pedido anterior não aplicado. Osmane sintético prepara/aplica; Samira sintética aprova/recusa a versão exacta por identidade distinta, sem editar/aplicar ou verificar a oficina por consequência. Direitos próprios e contexto revalidados no servidor e na transacção; nenhum nome/email especial no código funcional.
+
+Substituição cria nova prestação e novo rascunho via `ServiceWorkflow`, com relação append-only ao par anterior, sem editar/apagar originais. Um destino actual por cadeia; a aplicação anterior consome a elegibilidade do destino antigo, não a origem técnica. `wb_claims` permanece com duas utilizações originais, sem novas linhas de consumo/tempo. Mesmo cliente, moeda MZN, origens e quantidades integrais; não se aceitam campos para os mudar. Preços, fonte, descrição e serviço comercial podem mudar com versão exacta e revisão. O catálogo actual não tem unidade comercial tipada: a unidade/quantidade física é conservada da origem e a adequação do serviço é matéria da revisão comercial, sem conversão implícita.
+
+Exemplo: original 1,75 H × 200 + 2 UN × 75 = 500 MZN sem imposto; substituto 1,75 H × 200 + 2 UN × 80 = 510. Fonte sintética sucessora `WORKSHOP-SALES-SYNTHETIC-v2`. Não é custo, margem, total fiscal ou quantia exigível. Zero explícito é distinto de preço ausente; exactidão decimal/racional herdada, sem float ou regra fiscal de arredondamento. Imposto/moeda funcional/classificação mantêm pendências.
+
+Cancelamento acrescenta estado de preparação cancelada e preserva origens, par actual e histórico; não cria novo par, não liberta origens e não admite reabertura neste recorte. Não anula ordem, apontamentos ou documentos fiscais. Desistência cria sucessor de pedido sem aplicar mudança aos destinos. Pedidos materiais novos não herdam decisões; referência antiga, nova dependência, cadastro ou origem alterados exigem nova revisão.
+
+## Elegibilidade e integrações
+
+`WorkshopCommercialState` centraliza ligação e estado para originais/sucessores. Edição directa e nova facturação da mesma prestação bloqueadas em A e no SQL; estados comerciais visíveis no detalhe. B1 recusa confirmar destinos substituídos/cancelados, antes de replay; trigger SQL reforça estado e serializa com o bloqueio da empresa. Se B1 vencer a aplicação da correcção é recusada; se a correcção/cancelamento vencer a confirmação antiga é recusada. Não se altera confirmação ou fotografia existente. Preparação documental não pode editar destinos históricos.
+
+Aplicação exige par ainda draft, sem B1 e sem outros rascunhos derivados; origem/tarefa verificada actual e cliente/moeda compatíveis. Limite conservador: se já existir preparação documental específica no par, a operação é recusada até circuito próprio de herança. Nenhum conteúdo privado de instruções documentais é copiado para pedidos, auditoria ou provas. IDs/versões dos registos documentais da empresa compõem a referência: mudança invalida aprovação mesmo que seja conservadoramente noutro registo. Casos com herança documental, documentos fiscais, repartição parcial e reabertura continuam fora do recorte.
+
+Chave idempotente por geração/actor/acção/conteúdo, replay com permissão revalidada, conflito de conteúdo e recuperação após resposta perdida. Bloqueio de empresa serializa comandos; pedido/decisão/aplicação, prestação/rascunho, auditoria/evento/outbox são atómicos. Falha de outbox desfaz sucessores e estado; SQL reforça ambiente, cadeia, identidade, referência aprovada, destino e imutabilidade. Não é RLS ou segundo motor comercial independente contra administrador de confiança. Não são desligados triggers nem usadas flags de sessão para autorizar correcções.
+
+## Provas e percurso
+
+Primeiros seis testes de correcção aprovados (89 asserções). Acrescentados testes de B1 posterior à revisão, preço zero/ausente e protecção SQL, com regressão completa em execução. Seis casos com processos sobrepostos aprovados: pedido repetido, substituição versus cancelamento concorrentes, decisão repetida, aplicação repetida, decisões concorrentes e cancelamento versus B1. Ver [concorrência](proofs/workshop-corrections-concurrency.json). Nesta execução concorrente resultaram uma substituição, um cancelamento, duas utilizações técnicas originais e nenhuma confirmação B1. Compilação aprovada com Vite 8.3.5, sem mudança de dependências.
+
+Novo destino **Oficinas → Correcção e cancelamento**, com consulta/preparação/revisão/aplicação filtradas por permissões. Origens/quantidades não editáveis; pedido mostra base anterior e nova soma, destinos exactos e histórico. Conversão original também identifica substituição/cancelamento e último sucessor; consulta do rascunho apresenta estado comercial. Não há decisão automática nem confirmação B1 automática.
+
+**Prova visual/manual ainda pendente.** Não repetida a automação bloqueada do Edge nem declaradas capturas. Preparação isolada, só com base de testes vazia e testes parados:
+
+```powershell
+powershell -NoProfile -ExecutionPolicy Bypass -File scripts/browser-proof.ps1 start -Port 8002
+powershell -NoProfile -ExecutionPolicy Bypass -File scripts/sgf.ps1 php scripts/workshop-corrections-fixture.php --env=testing
+```
+
+Fixture prepara apenas a conversão original de 500 pelos percursos existentes com identidades distintas, sem pedidos ou decisões de correcção predefinidos. Contas `gestor@example.test` e `consulta@example.test`; credenciais aleatórias só no manifesto/ficheiro local protegido `C:\laragon\data\sgf-tempo\secrets\workshop-corrections-manual-entry.txt`, nunca no relatório/capturas. Preparador escolhe geração, mantém trabalho 200 e altera material para 80, indica fonte v2 e motivo, submete; revisor aprova versão exacta; preparador aplica. Conferir original 500 histórico, novo 510 actual, linhas e origens preservadas. Depois preparar cancelamento do destino actual, rever distintamente e aplicar; conferir estado cancelado e ausência de reabertura. Não confirmar B1 na prova manual, nem executar testes destrutivos enquanto activa. Parar apenas a instância SGF com `scripts/browser-proof.ps1 stop`.
+
+Instância efectivamente arrancada em 8002 depois dos testes finais e fixture de suporte criada. Diagnóstico HTTP confirmou ambiente `browser-testing`, base `sgf_tempo_test`, papel `sgf_test_runner`, PostgreSQL 55432, sessão/cache em ficheiros isolados: [prova de ambiente](proofs/workshop-corrections-environment.json). Ficheiro de entrada e manifesto com ACL apenas do utilizador local/SYSTEM, fora do repositório. Credenciais anteriores de outros ensaios não devem ser reutilizadas. Nenhum login/fluxo visual de correcção é declarado executado por esta preparação.
+
+## Migração proposta — NÃO aplicada
+
+`2026_10_28_130000_create_workshop_billing_corrections.php`, SQL `database/sql/workshop-corrections.sql`. Destino futuro proposto `sgf_tempo_dev` / `127.0.0.1:55432`, por caminho exclusivo com `sgf_dev_owner`; aplicação mantém `sgf_dev_app`. Exige autorização específica separada. Cria seis tabelas `wc_requests`, `wc_reviews`, `wc_applications`, `wc_commands`, `wc_events`, `wc_outbox`, constraints/FKs/índices/triggers e funções próprias; amplia CHECK com quatro permissões de unidade, sem concessões automáticas. Reforça funções de protecção dos rascunhos ligados já existentes e acrescenta trigger de elegibilidade em B1; não altera linhas ou fotografias existentes. INSERT nas seis tabelas exige `sgf_tempo_test`/55432, guarda operacional exige ambiente isolado seguro. `down()` recusa destruir história; nenhum reset de desenvolvimento ou instalação de dependências.
+
+## Cinco concessões propostas — NÃO aplicadas
+
+Consulta read-only `scripts/workshop-corrections-permissions-preview.php` confirmou `130000` ausente, cinco concessões ausentes, pré-requisitos existentes e operação real bloqueada. Todas no **tenant #1 / Tempo Lda #1 / SEGI #1**:
+
+| Conta existente | Direitos exactos propostos |
+| --- | --- |
+| Osmane #1 | `workshop_corrections.view`, `workshop_corrections.request`, `workshop_corrections.apply` |
+| Samira #2 | `workshop_corrections.view`, `workshop_corrections.review` |
+
+Não herdar direitos da conversão, custos, contabilidade ou nomes. Não concede supervisão/verificação técnica, gestão de acessos, emissão, stock ou uso real. `110000`/`120000` instaladas anteriormente permanecem preservadas, sem reaplicação ou novas concessões por arrasto.
+
+## Ficheiros e limites
+
+Novos: módulo `WorkshopCorrections.php`, estado comum `WorkshopCommercialState.php`, controlador, migração/SQL, `WorkshopCorrectionsWorkspace.jsx`, testes e fixture, scripts de concorrência/worker/fixture/pré-visualização e relatório/provas. Integrações em `ServiceWorkflow`, `InternalConfirmation`, `DocumentPreparation`, consulta `WorkshopBilling`, router, navegação/início e vistas de rascunho/conversão. Sem nova operação real, confirmação automática, fiscalidade, stock, recebimentos, lançamentos, publicação, aceitação ou checkpoint.

docs/WORKSHOP_BILLING_CORRECTION_SCOPE.md

@@ -0,0 +1,80 @@
+# Oficina → rascunho: correcção e cancelamento controlados
+
+**Autorização técnica posterior de 28/10/2026:** o utilizador autorizou implementar e demonstrar `WORKSHOP-BILLING-CORRECTION-SIM-v1` exclusivamente em `sgf_tempo_test`, sem aplicar migrações/concessões em desenvolvimento, activar uso real ou publicar. Substitui apenas as restrições históricas de etapa documental, preservando decisões/limites. Ver [entrega e provas](WORKSHOP_BILLING_CORRECTION_DELIVERY.md); sem aceitação antecipada.
+
+28/10/2026. Proposta `WORKSHOP-BILLING-CORRECTION-SIM-v1`. Autorizada nesta etapa apenas a especificação. Sem implementação, migrações, concessões, dados reais ou publicação. Preservar a entrega aceite `3932b94`, instalações técnicas `30029b9`/`d071bc0`, checkpoints anteriores, fotografias e limitações de prova. Uso real continua bloqueado.
+
+## 1. Problema e fronteira
+
+O primeiro recorte gera uma prestação e um rascunho ligados à proposta revista, e bloqueia a sua edição e a reutilização das origens. É necessário corrigir a preparação comercial sem apagar o original nem facturar duas vezes o mesmo recurso. Cancelar esta preparação não cancela a ordem, a execução técnica, um documento fiscal, uma dívida ou um lançamento.
+
+Proposta mínima: mesma ordem/empresa/unidade, cliente e MZN; origens seleccionadas integralmente; apenas destinos ainda em rascunho, sem confirmação B1 e sem documento derivado. Correcção de preço, fonte comercial, descrição ou serviço compatível, mantendo quantidades técnicas, fica no primeiro recorte. Mudança de cliente, moeda, repartição parcial, inclusão/exclusão de origens e origem técnica corrigida ficam bloqueadas para revisão de âmbito própria. Assim não se altera implicitamente a ordem nem o vínculo comercial original.
+
+Uma correcção técnica permanece no circuito de oficina e exige nova verificação técnica; a revisora comercial não edita apontamentos ou verifica execução. Se a origem/tarefa seleccionada ficar obsoleta, assinalar o destino como desactualizado e bloquear a aplicação da correcção comercial deste recorte. Não usar aprovação anterior para legitimar dados novos.
+
+## 2. Modelo proposto: substituição, não edição
+
+Preservar prestação/rascunho, proposta, decisão, geração e utilizações originais. Correcção cria pedido versionado que referencia a geração e versões exactas dos destinos, motivo e composição anterior/proposta. Submissão é imutável; qualquer mudança material cria sucessora explícita e nova decisão distinta.
+
+Após revisão aprovada e nova conferência de elegibilidade, criar **nova prestação e novo rascunho**, com relação explícita «substitui/substituído por». Marcar o par antigo como comercialmente substituído por registo de estado append-only, sem alterar as suas linhas ou fotografias. Nunca apresentá-lo como destino actual ou elegível para confirmação por outro percurso. Manter consulta histórica, inclusive a partir das origens técnicas.
+
+O registo de utilização canónica das origens continua único: não apagar `wb_claims` nem inserir o mesmo consumo como nova ocorrência. Propor cadeia própria de destinos comerciais sobre essa utilização, com no máximo um destino actual. Aplicar a substituição, o novo destino e a mudança de elegibilidade atomicamente; não pode existir janela com ambos activos ou com a origem livre.
+
+Os triggers actuais continuam a proibir edição directa. Uma implementação futura precisará de um caminho de sucessão próprio, limitado e revisto, sem desligar triggers, usar flags de sessão como autorização ou permitir gerar novo rascunho pela edição normal de A. Não basta acrescentar um botão: a base e todos os percursos de confirmação devem reconhecer o destino substituído/cancelado.
+
+## 3. Cancelamento proposto
+
+Pedido de cancelamento identifica geração/destinos e versões, motivo, autor e revisão distinta. Aplicação aprovada acrescenta estado «Preparação comercial cancelada», preservando os dois rascunhos e as origens como histórico. Não apagar ou anular acontecimentos técnicos; sem nota de crédito, devolução de stock, reembolso ou comunicação externa.
+
+**Recomendação para o primeiro recorte:** cancelar não liberta automaticamente origens para nova cobrança. Mantém-se a utilização canónica e bloqueiam-se novos destinos; reabertura exige novo pedido versionado com revisão distinta e âmbito próprio. Isto evita que cancelamento seja usado como forma de duplicar geração. Reabertura não será implementada por inferência.
+
+Cancelamento de um destino já substituído, cancelado, confirmado ou com dependências é conflito. Não procurar e cancelar automaticamente a versão mais recente. Cancelar pedido ainda não aplicado é desistência da proposta, não cancelamento dos rascunhos.
+
+## 4. Estados, dependências e acessos
+
+Pedido: preparado/submetido → aprovado ou recusado → aplicado. Desistência antes da aplicação fica registada, sem apagar o pedido. Um pedido aprovado não muda o destino até aplicação transaccional. Fonte/destino/versão/condições alterados invalidam a actualidade da aprovação; aplicação exige nova conferência. Pedido concorrente não substitui silenciosamente outro.
+
+Destino: actual, substituído ou preparação cancelada, com causa e ligação às decisões. Estado de rascunho comercial permanece distinto de confirmação B1, fiscalidade e execução da oficina. Uma função comum de elegibilidade deve ser usada por edição/recarregamento, nova geração a partir da prestação, confirmação/revisão B1 e restantes percursos derivados. Enquanto esse controlo não existir, não activar substituição/cancelamento.
+
+Verificar dependências da prestação e do rascunho, não só ausência de confirmação no par conhecido: outros rascunhos/documentos derivados, versões de preparação documental e revisões em curso podem impedir aplicação. Não reescrever fotografias, propagar alterações silenciosamente ou limpar pendências fiscais. Herança documental para sucessores, se aplicável, exige captura explícita e referência à versão escolhida; não copiar valores privados para auditoria técnica ou prova.
+
+Distribuição **proposta, por confirmar**: Osmane prepara pedidos e aplica os aprovados; Samira consulta, aprova/recusa a versão exacta, sem editar ou aplicar o pedido por consequência da revisão. Auto-aprovação recusada mesmo com ambos os poderes. Revalidar identidade, contexto, pertenças, acesso às origens/destinos e acção no servidor em cada pedido e dentro da transacção.
+
+Propor direitos de unidade próprios de consulta, pedido, revisão e aplicação de correcção/cancelamento. Não derivar de `workshop_billing.prepare/review/generate`, de custos ou do nome da conta. Nomes técnicos, contas e concessões exactas serão apresentados após confirmar o desenho, separadamente de qualquer migração ou instalação. Nenhuma concessão decorre deste documento.
+
+## 5. Exemplo sintético proposto — não aprovado
+
+Reutilizar referências verificadas do exemplo de 105 MIN e 2 UN, sem nova captura. Original: trabalho 1,75 H × 200 = 350; material 2 × 75 = 150; soma comercial 500 MZN sem imposto.
+
+Proposta de correcção de preço para futura prova: trabalho mantém 200 MZN/H; material passa a **80 MZN/UN**, com fonte sintética sucessora explícita `WORKSHOP-SALES-SYNTHETIC-v2`. Novo material 160, soma 510; diferença comercial +10. Não é desvio de custo, margem, total fiscal ou quantia exigível. Original 500 continua intacto no histórico; sucessor 510 só fica actual após revisão/aplicação exactas.
+
+Preço desconhecido impede aplicar; zero explícito exige revisão e não significa desconhecido. Aritmética exacta, respeitando contrato 16/8 das entradas e recusando representações incompatíveis sem arredondamento. Fiscalidade, moeda funcional e regras contabilísticas continuam pendentes; nenhuma aprovação comercial as resolve.
+
+Cancelamento é cenário separado: seleccionar o destino actual elegível e aplicar decisão distinta; preservar 500/510 como história, não substituir montantes por zero. Não executar cenários sucessivos presumindo que cancelamento reabre a origem.
+
+## 6. Provas e critérios para futura implementação
+
+- Original 500 preservado, proposta/revisão distintas, sucessor 510 rastreável e único destino actual, sem novo consumo ou utilização duplicada.
+- Recusa, desistência e proposta sucessora mantêm história; aprovação de versão anterior não se transfere. Cliente/moeda/quantidade/origem fora do recorte recusados.
+- Cancelamento preserva origem/destino e bloqueia cobrança/reabertura automáticas; repetição não duplica estado ou liberta recursos.
+- Destino confirmado B1, com documento derivado, já substituído/cancelado, dependência nova ou fonte técnica obsoleta não pode ser alterado/aplicado. Fotografias e decisões anteriores intocadas.
+- Percursos alternativos de A/B1 não contornam o estado; não se retira `ServiceInvoicing::guard()` ou outra guarda para demonstrar o circuito.
+- Contexto cruzado e permissão revogada recusados no pedido seguinte, incluindo replay; revisora não ganha verificação técnica, preparação ou aplicação implícitas.
+- Idempotência por contexto/actor/acção/conteúdo, conflito de chave, recuperação após resposta perdida, rollback completo de destino/estado/auditoria/outbox e duas transacções sobrepostas: correcção versus correcção, correcção versus cancelamento, aplicação versus confirmação B1/dependência nova.
+- Regressões relevantes de A/B1/oficina/conversão, build e prova exclusivamente sintética em `sgf_tempo_test`; sessões/cache isolados, CSRF activo e limitações visuais registadas sem aceitação presumida.
+
+## 7. Decisões novas necessárias
+
+1. Confirmar substituição imutável por novo par de rascunhos, em vez de edição do par já gerado.
+2. Confirmar limites iniciais: mesmo cliente/moeda/origens/quantidades; corrigir preço, fonte, descrição e serviço compatível. Alterações técnicas/clientes/volume e repartição parcial ficam de fora.
+3. Confirmar cancelamento sem libertação de origens e sem reabertura neste recorte.
+4. Confirmar Osmane prepara/aplica e Samira revê por identidade distinta, com direitos próprios.
+5. Confirmar ou substituir o exemplo de material 80 MZN/UN e soma 510, exclusivamente sintético, sem imposto.
+
+Depois destas decisões, a implementação ainda requer autorização técnica delimitada. Não existe ordem de migração, concessão, uso real, emissão, stock, recebimento, lançamento, fecho ou publicação nesta etapa.
+
+## 8. Validação das decisões pelo utilizador
+
+Em 28/10/2026, o utilizador respondeu «valido» às cinco opções apresentadas. Ficam confirmadas: substituição imutável por novo par de rascunhos, preservando os originais; mesmo cliente/moeda/origens/quantidades, com correcções comerciais delimitadas na secção 7; cancelamento sem libertação de origens ou reabertura automática; Osmane prepara/aplica e Samira revê por identidade distinta, sem novos direitos reais por consequência; exemplo exclusivamente sintético de material a 80 MZN/UN, mantendo trabalho a 200 MZN/H, soma 510 MZN sem imposto versus original 500.
+
+As referências anteriores a estas decisões por confirmar passam a históricas. Esta validação aprova o desenho e os pressupostos do ensaio, não uma proposta ou decisão no sistema. Permanecem separadas a autorização técnica de implementação, qualquer migração/concessão em desenvolvimento, demonstração, aceitação da futura entrega e checkpoint. Preservar `3932b94`, `30029b9`, `d071bc0`, anteriores e todas as alterações posteriores. Sem alteração de código ou retirada de bloqueios nesta etapa.

docs/WORKSHOP_BILLING_DRAFT_SCOPE.md

@@ -1,5 +1,7 @@
 # Oficina → rascunho de facturação — especificação para decisão
 
+Evolução apenas proposta: [correcção e cancelamento controlados](WORKSHOP_BILLING_CORRECTION_SCOPE.md), em etapa documental separada. Não altera a entrega aceite ou habilita edição dos destinos gerados.
+
 **Autorização técnica posterior de 28/10/2026:** o utilizador autorizou implementar e demonstrar `WORKSHOP-BILLING-DRAFT-SIM-v1` exclusivamente em `sgf_tempo_test`, sem aplicar migrações/concessões em desenvolvimento, activar uso real ou publicar. A autorização substitui apenas as restrições anteriores de etapa documental; decisões comerciais e limites permanecem. Ver [entrega e estado das provas](WORKSHOP_BILLING_DELIVERY.md). Não presume aceitação ou checkpoint.
 
 28/10/2026. Próximo recorte proposto: `WORKSHOP-BILLING-DRAFT-SIM-v1`. Nesta etapa **apenas documentação**: sem implementação, migrações, concessões, alteração de operações reais ou publicação. Preservar `04870f0` (orçamento aceite com limitação de capturas), `090b7da` (página inicial/menu com revisão visual pendente) e anteriores. Sem reabrir as respectivas aprovações ou transformar provas pendentes em realizadas.

docs/proofs/budget-demo-availability.json

@@ -0,0 +1,16 @@
+{
+    "version": "SGF-BUDGET-WORKSPACE-SIM-v1",
+    "url": "http:\/\/127.0.0.1:8003",
+    "isolated_database": "budget_core_sgf_4abb58d1cabf",
+    "restricted_role": true,
+    "synthetic_only": true,
+    "counts": {
+        "users": 4,
+        "cb_budgets": 0,
+        "cb_budget_entries": 0,
+        "cb_budget_consumptions": 0,
+        "cb_ui_commands": 0
+    },
+    "core_sha256": "1349d1ab4ab58a83c9abbf43549ebe7e4ed77717ed5463a2defac748cf7b9a31",
+    "checked_at": "2026-10-29T11:43:33+00:00"
+}

docs/proofs/budget-workspace-http.json

@@ -0,0 +1,85 @@
+{
+  "version": "SGF-BUDGET-WORKSPACE-SIM-v1",
+  "checked_at": "2026-10-29T11:38:41.903Z",
+  "passed": true,
+  "core_sha256": "1349d1ab4ab58a83c9abbf43549ebe7e4ed77717ed5463a2defac748cf7b9a31",
+  "checks": [
+    "four_real_sessions_and_empty_initial_demo",
+    "allocation_distinct_approval",
+    "same_command_recovery",
+    "changed_key_conflict",
+    "reservation_award_commit_equivalent",
+    "insufficient_balance",
+    "committed_release_refused",
+    "decimal_precision_rejected",
+    "failed_consumption_rollback_and_recovery",
+    "single_consumption_per_reference",
+    "pending_reinforcement_no_effect",
+    "distinct_reinforcement_review",
+    "release_once_no_reopening",
+    "foreign_origin_refused",
+    "stale_context_refused",
+    "csrf_enabled",
+    "reserved_unit_refused",
+    "reader_cannot_write"
+  ],
+  "snapshots": [
+    {
+      "step": "reserve",
+      "balance": {
+        "approved_total_minor": 100000,
+        "reinforced_minor": 0,
+        "reserved_minor": 30000,
+        "committed_minor": 0,
+        "consumed_minor": 0,
+        "available_minor": 70000
+      }
+    },
+    {
+      "step": "award",
+      "balance": {
+        "approved_total_minor": 100000,
+        "reinforced_minor": 0,
+        "reserved_minor": 35000,
+        "committed_minor": 0,
+        "consumed_minor": 0,
+        "available_minor": 65000
+      }
+    },
+    {
+      "step": "commit",
+      "balance": {
+        "approved_total_minor": 100000,
+        "reinforced_minor": 0,
+        "reserved_minor": 0,
+        "committed_minor": 35000,
+        "consumed_minor": 0,
+        "available_minor": 65000
+      }
+    },
+    {
+      "step": "consume",
+      "balance": {
+        "approved_total_minor": 100000,
+        "reinforced_minor": 0,
+        "reserved_minor": 0,
+        "committed_minor": 25000,
+        "consumed_minor": 10000,
+        "available_minor": 65000
+      }
+    },
+    {
+      "step": "reinforcement",
+      "balance": {
+        "approved_total_minor": 120000,
+        "reinforced_minor": 20000,
+        "reserved_minor": 0,
+        "committed_minor": 25000,
+        "consumed_minor": 10000,
+        "available_minor": 85000
+      }
+    }
+  ],
+  "visual_review": false,
+  "team_demo_changed": false
+}

docs/proofs/payables-demo-compras.json

@@ -0,0 +1,14 @@
+{
+    "host": "compras",
+    "isolated": true,
+    "restricted_role": true,
+    "counts": {
+        "sources": 0,
+        "proposals": 0,
+        "obligations": 0,
+        "events": 0,
+        "outbox": 0
+    },
+    "core_sha256": "5ec2a8c0b55b2982b41faaa6870243834a3b2f894795a5ef13c7406f87286962",
+    "checked_at": "2026-10-29T12:50:46+00:00"
+}

docs/proofs/payables-demo-sgf.json

@@ -0,0 +1,14 @@
+{
+    "host": "sgf",
+    "isolated": true,
+    "restricted_role": true,
+    "counts": {
+        "sources": 0,
+        "proposals": 0,
+        "obligations": 0,
+        "events": 0,
+        "outbox": 0
+    },
+    "core_sha256": "5ec2a8c0b55b2982b41faaa6870243834a3b2f894795a5ef13c7406f87286962",
+    "checked_at": "2026-10-29T12:50:46+00:00"
+}

docs/proofs/payables-history.json

@@ -0,0 +1,34 @@
+{
+  "version": "COMMON-PAYABLE-SOURCE-SIM-v1",
+  "passed": true,
+  "checked_at": "2026-10-29T12:47:50.740Z",
+  "team_budget_preserved": true,
+  "hosts": [
+    {
+      "host": "compras",
+      "passed": true,
+      "core_sha256": "5ec2a8c0b55b2982b41faaa6870243834a3b2f894795a5ef13c7406f87286962",
+      "source_revision": "4a34d4256cf35402f407d4cb8d1f4a26441f8aa2be1a7b30312fdb2d631a22eb",
+      "recognised_obligations": 0,
+      "checks": [
+        "previous_settlement_blocks_recognition",
+        "history_unchanged",
+        "no_full_unpaid_import"
+      ],
+      "visual_review": false
+    },
+    {
+      "host": "sgf",
+      "passed": true,
+      "core_sha256": "5ec2a8c0b55b2982b41faaa6870243834a3b2f894795a5ef13c7406f87286962",
+      "source_revision": "4a34d4256cf35402f407d4cb8d1f4a26441f8aa2be1a7b30312fdb2d631a22eb",
+      "recognised_obligations": 0,
+      "checks": [
+        "previous_settlement_blocks_recognition",
+        "history_unchanged",
+        "no_full_unpaid_import"
+      ],
+      "visual_review": false
+    }
+  ]
+}

docs/proofs/payables-http.json

@@ -0,0 +1,154 @@
+{
+  "version": "COMMON-PAYABLE-SOURCE-SIM-v1",
+  "passed": true,
+  "checked_at": "2026-10-29T12:47:37.052Z",
+  "team_budget_preserved": true,
+  "hosts": [
+    {
+      "host": "compras",
+      "passed": true,
+      "core_sha256": "5ec2a8c0b55b2982b41faaa6870243834a3b2f894795a5ef13c7406f87286962",
+      "source_revision": "9ca4ac29a4720d6c4885101fd1485c58fb2dab3dcc2d5d975cb919679df58f54",
+      "principal_minor": 1160000,
+      "due_on": null,
+      "days_overdue": null,
+      "races": [
+        {
+          "waits": 2,
+          "results": [
+            {
+              "status": 200,
+              "state": "prepared",
+              "pid": 6472
+            },
+            {
+              "status": 200,
+              "state": "prepared",
+              "pid": 14488
+            }
+          ]
+        },
+        {
+          "waits": 2,
+          "results": [
+            {
+              "status": 403,
+              "pid": 18912
+            },
+            {
+              "status": 403,
+              "pid": 3488
+            }
+          ]
+        },
+        {
+          "waits": 2,
+          "results": [
+            {
+              "status": 200,
+              "state": "recognised",
+              "pid": 8112
+            },
+            {
+              "status": 200,
+              "state": "recognised",
+              "pid": 804
+            }
+          ]
+        }
+      ],
+      "checks": [
+        "genuine_conferred_invoice",
+        "no_duplicate_new_keys",
+        "conflicting_payload",
+        "distinct_person",
+        "incomplete_source_pending",
+        "source_revision_conflict",
+        "revocation_while_waiting",
+        "event_fault_atomic_rollback",
+        "retry_after_failure",
+        "unknown_due_even_future",
+        "foreign_scope_refused",
+        "no_stock_budget_payment_effect",
+        "existing_settlement_history_refused_and_preserved",
+        "durable_events_outbox",
+        "read_only_ui",
+        "csrf_active"
+      ],
+      "visual_review": false
+    },
+    {
+      "host": "sgf",
+      "passed": true,
+      "core_sha256": "5ec2a8c0b55b2982b41faaa6870243834a3b2f894795a5ef13c7406f87286962",
+      "source_revision": "9ca4ac29a4720d6c4885101fd1485c58fb2dab3dcc2d5d975cb919679df58f54",
+      "principal_minor": 1160000,
+      "due_on": null,
+      "days_overdue": null,
+      "races": [
+        {
+          "waits": 2,
+          "results": [
+            {
+              "status": 200,
+              "state": "prepared",
+              "pid": 6892
+            },
+            {
+              "status": 200,
+              "state": "prepared",
+              "pid": 11424
+            }
+          ]
+        },
+        {
+          "waits": 2,
+          "results": [
+            {
+              "status": 403,
+              "pid": 804
+            },
+            {
+              "status": 403,
+              "pid": 20804
+            }
+          ]
+        },
+        {
+          "waits": 2,
+          "results": [
+            {
+              "status": 200,
+              "state": "recognised",
+              "pid": 20576
+            },
+            {
+              "status": 200,
+              "state": "recognised",
+              "pid": 11332
+            }
+          ]
+        }
+      ],
+      "checks": [
+        "genuine_conferred_invoice",
+        "no_duplicate_new_keys",
+        "conflicting_payload",
+        "distinct_person",
+        "incomplete_source_pending",
+        "source_revision_conflict",
+        "revocation_while_waiting",
+        "event_fault_atomic_rollback",
+        "retry_after_failure",
+        "unknown_due_even_future",
+        "foreign_scope_refused",
+        "no_stock_budget_payment_effect",
+        "existing_settlement_history_refused_and_preserved",
+        "durable_events_outbox",
+        "read_only_ui",
+        "csrf_active"
+      ],
+      "visual_review": false
+    }
+  ]
+}

docs/proofs/product-demo-http.json

@@ -0,0 +1,52 @@
+{
+  "demo": "SGF-PRODUCT-DEMO-v1",
+  "checked_at": "2026-10-29T08:50:35.350Z",
+  "type": "HTTP integration, not visual acceptance",
+  "business_operations_changed": false,
+  "results": [
+    {
+      "role": "preparador",
+      "modules": [
+        "workshop",
+        "workshop-billing",
+        "workshop-corrections",
+        "direct-costs",
+        "industrial-costs",
+        "industrial-budgets",
+        "service-invoices",
+        "service-receivables"
+      ],
+      "unauthorised_unit_refused": true
+    },
+    {
+      "role": "validador",
+      "modules": [
+        "workshop",
+        "workshop-billing",
+        "workshop-corrections",
+        "direct-costs",
+        "industrial-costs",
+        "industrial-budgets",
+        "service-invoices",
+        "service-receivables"
+      ],
+      "unauthorised_unit_refused": true
+    },
+    {
+      "role": "tecnico",
+      "modules": [
+        "workshop"
+      ],
+      "unauthorised_unit_refused": true,
+      "unauthorised_module_refused": "industrial-costs"
+    },
+    {
+      "role": "verificador",
+      "modules": [
+        "workshop"
+      ],
+      "unauthorised_unit_refused": true,
+      "unauthorised_module_refused": "service-receivables"
+    }
+  ]
+}

docs/proofs/workshop-corrections-concurrency.json

@@ -0,0 +1,16 @@
+{
+    "policy": "WORKSHOP-BILLING-CORRECTION-SIM-v1",
+    "database": "sgf_tempo_test",
+    "processes_per_case": 2,
+    "checks": {
+        "request_replay_one_version": true,
+        "replacement_vs_cancellation_one_request_successor": true,
+        "review_replay_one_decision": true,
+        "apply_replay_one_successor_pair": true,
+        "competing_reviews_one_decision": true,
+        "cancellation_blocks_overlapping_b1": true
+    },
+    "source_claims_unchanged": 2,
+    "applications": 2,
+    "b1_created": false
+}

docs/proofs/workshop-corrections-environment.json

@@ -0,0 +1,10 @@
+{
+    "environment":  "browser-testing",
+    "database":  "sgf_tempo_test",
+    "role":  "sgf_test_runner",
+    "database_port":  55432,
+    "session_driver":  "file",
+    "session_cookie":  "sgf_browser_proof",
+    "cache_store":  "file",
+    "synthetic_only":  true
+}

docs/proofs/workshop-corrections-tests.json

@@ -0,0 +1,15 @@
+{
+ "policy":"WORKSHOP-BILLING-CORRECTION-SIM-v1",
+ "date":"2026-10-28",
+ "database":"sgf_tempo_test",
+ "full_regression":{"tests":183,"assertions":3209,"failures":0,"errors":0},
+ "new_correction_cases":8,
+ "overlapping_process_cases":6,
+ "build":{"vite":"8.3.5","passed":true,"dependencies_changed":false},
+ "manual_browser":{"port":8002,"fixture_prepared":true,"environment_checked_by_http":true,"user_path_completed":false,"screenshots_received":false,"automatic_edge_retried":false},
+ "development_migration_130000_applied":false,
+ "new_real_grants_applied":false,
+ "real_corrections_guard_refused":true,
+ "user_acceptance":false,
+ "closing_checkpoint_created":false
+}