# Primeiro lançamento sintético — proposta concreta para autorização

**Autorização recebida em02/11/2026:** o utilizador respondeu «Autorizar o incremento sintético proposto». O recorte abaixo foi autorizado e implementado localmente; estado/provas em [GENERAL_LEDGER_DELIVERY.md](GENERAL_LEDGER_DELIVERY.md). A descrição de proposta/decisão pendente abaixo preserva a preparação histórica e não indica falta de autorização actual. Não constitui aceitação funcional, activação real ou autorização de checkpoint.

`COMMON-LEDGER-PAYABLE-SIM-v1` — proposta de 02/11/2026. **Apenas especificação; motor, schema, direitos e lançamentos desta proposta não implementados ou concedidos.** A entrega funcional feita nesta passagem é o relatório financeiro, descrito em [SGF_PAYABLE_REPORT_DELIVERY.md](SGF_PAYABLE_REPORT_DELIVERY.md).

## Limite que exige decisão

O [AGENTS.md](../AGENTS.md) regista: «O recorte actual permanece só obrigação a fornecedor; sem pagamentos/cobranças/lançamentos por arrasto.» Regista também o desenvolvimento dos módulos em falta com identidades e bases sintéticas, sem confirmações técnicas de cada pequeno passo. Esta proposta agrupa **um incremento funcional contabilístico novo**, para autorização expressa antes de criar o primeiro motor/escritor e seus direitos. Não é um pedido para repetir aceitações ou aplicar acessos reais.

A classificação existente do catálogo é de vendas, sem lançamentos. Não fornece automaticamente a contrapartida de uma factura de fornecedor. O relatório financeiro novo também não é uma origem contabilística nem uma autorização de reconhecimento: a origem proposta é o efeito imutável reconhecido no núcleo Payables, conferido novamente.

## Recorte proposto para aprovar integralmente

1. Um núcleo único em `packages/general-ledger`, primeiro adaptador SGF, desligado por defeito e limitado a uma base/role QA nova no cluster 55439. Composição autónoma nativa futura separada; não copiar um segundo motor, activar pacotes instalados ou exigir SGF remoto ao SGC.
2. Um efeito: **obrigação de fornecedor reconhecida → um lançamento sintético equilibrado**. Fonte por âmbito, identidade factual, ID do reconhecimento e revisão exacta, não por coincidência de IDs ou leitura do estado de uma factura. Não voltar a reconhecer o principal por chegada da factura ou posterior pagamento.
3. Cenário novo e explícito: principal 60,00 MZN, imposto documental 0, sem pagamentos nessa fixture inicial. Isto delimita o cenário e não cria uma pré-condição universal de dívida só ser reconhecida antes de pagamentos. Usa-se o principal reconhecido, nunca o saldo residual como principal do lançamento.
4. Regra imutável de ensaio `QA-PAYABLE-JOURNAL-v1`: **débito 60,00 em `QA-CONTRAPARTIDA` / crédito 60,00 em `QA-FORNECEDOR`**. Ambas contas de movimento artificiais. Não são contas PGC aprovadas, despesa/inventário/IVA inferidos, parametrização da Tempo ou classificação comercial reutilizada indevidamente.
5. Data explícita de lançamento 29/10/2026 e período artificial `QA-2026-10`, aberto de 01/10 a 31/10/2026. Data e período são hipóteses do ensaio, separados de vencimento, data de pagamento e enquadramento fiscal real. Sem fecho/reabertura operacional ou escolha automática da data do computador.
6. Preparador sintético propõe fonte, data, regra/versionamento e fundamento; validador sintético distinto revê a fotografia exacta; preparador aplica apenas a versão revista. Não há validação técnica/fiscal implícita, privilégio associado a nomes ou revisão pelo próprio autor. Mudança de fonte/regra/período desde a prévia exige nova conferência.
7. Aplicação numa transacção: revalidação de permissões/contexto, fonte/revisão, decisão independente, regra, período aberto/versionado, moeda e igualdade exacta de débitos/créditos; gravação de cabeçalho/linhas, recibo de repetição e auditoria append-only. Fundamento, autor/data e referências preservados. Montantes inteiros em unidades menores, sem arredondamento novo.
8. Unicidade por empresa/unidade, identidade factual do reconhecimento e tipo de efeito. Mudança de versão ou chave de pedido não autoriza segundo lançamento do mesmo efeito. Mesma chave/conteúdo recupera o recibo; conteúdo diferente recusa. A autorização actual é conferida antes de recuperar um resultado. Um lançamento já gravado permanece histórico mesmo se o período fechar depois; replay não cria nova gravação.
9. Consulta do lançamento e extracto/total apenas desse período/duas contas sintéticas, reconciliados com os próprios movimentos e a origem. Não declarar contabilidade geral, balancete legal, fiscalidade, reconhecimento de vendas, valorização de stock, pagamentos ou fecho completos.

## Direitos apresentados antes de qualquer concessão

Proposta de novos direitos **apenas para identidades da fixture QA**: `general_ledger.view`, `general_ledger.prepare`, `general_ledger.validate`, `general_ledger.post`. Não há herança de Administração, Compras, Financeiro, classificação ou nomes.

| Função sintética | Direitos propostos |
|---|---|
| Preparador/aplicador | view, prepare, post |
| Validador distinto | view, validate |
| Consulta | view |

Nenhuma concessão real, direito público ou competência para gerir estes direitos é incluída. A autorização do incremento autoriza construir e conceder estes direitos **na fixture isolada**, não na Tempo, nas demos existentes ou em dados comerciais.

## Provas previstas e exclusões

Testar fonte inexistente/incompatível, tenant/empresa/unidade indevidos, direitos revogados, actor/pessoa trocados, auto-revisão, regra/data/período/versão alterados, débitos/créditos incompatíveis, moeda, concorrência da mesma origem, repetição por mesma/outra chave, falha entre cabeçalho/linhas/recibo/auditoria e recuperação sem duplicação. Conferir montantes/origens/stock/orçamento/Payables antes/depois, fora dos novos registos de lançamento de ensaio. Não executar de novo suites válidas alheias.

A proposta não autoriza correcção de lançamento já aplicado, estorno, reabertura de período, reconciliação bancária, efeito de pagamento/recebimento, contas/impostos reais, importação histórica automática, emissão, instalação de migração no destino, publicação, aceitação ou checkpoint. Eventual correcção exige circuito append-only próprio posterior; os originais não serão editados/apagados por um percurso provisório.

Seis registos protegidos, cache bloqueada, demos, direitos/dados reais e trabalho em curso permanecem intactos. Revisão visual e capacidade de implantação continuam separadas. **Decisão pendente:** autorizar este recorte sintético, com estes quatro direitos exclusivamente QA, antes da implementação contabilística.