# Ciclo contabilístico sintético integrado — entrega local

`COMMON-LEDGER-COMPLETE-CYCLE-SIM-v1`, autorizado expressamente por «Autorizar o ciclo sintético proposto». **Implementação funcional concluída no recorte autorizado**, com demonstrações SGF e SGC separadas. Não equivale a contabilidade geral/fiscal completa ou implantação aceite.

## Demonstrar o ciclo inteiro

| Composição | Entrada persistente | Estado inicial na entrega |
|---|---|---|
| SGF | **http://127.0.0.1:8050/qa/ledger-demo** | Uma obrigação60MZN, sem pagamento, afectação, proposta contabilística, lançamento ou fecho |
| SGC autónomo | **http://127.0.0.1:8051/qa/ledger-demo** | Factura efectivamente conferida no workflow nativo e uma obrigação60MZN, restantes efeitos vazios |

Escolher Preparar/aplicar, Rever com outra pessoa ou Consultar. Cada decisão exige fundamento. As duas instalações são **livros financeiros independentes**, não duas autoridades operacionais para a mesma dívida. O SGC usa o pacote comum local, sem serviço SGF remoto, facturação de vendas SGF ou cópia divergente do motor. O pacote instalado e a configuração operacional do SGC não foram activados/substituídos.

Guião, presente também nas entradas:

1. Capturar reconhecimento contabilístico60, conferir o impacto D `QA-CONTRAPARTIDA` / C `QA-FORNECEDOR`, rever com outra pessoa e aplicar.
2. Abrir liquidações financeiras pelo botão. Registar facto sintético20 com referências únicas `SIM-…`, data29/10/2026, confirmar com outra pessoa, preparar afectação20 e confirmá-la independentemente. Principal60, saldo40. Não há execução monetária.
3. Voltar pelo botão à contabilidade. Capturar a afectação confirmada, rever D fornecedor20 / C `QA-LIQUIDACAO`20 e aplicar. O lançamento **não volta a reduzir o saldo**.
4. Preparar e confirmar a reversão financeira integral da afectação; saldo volta a60. Conferir/contabilizar a reversão: D liquidação20 / C fornecedor20. O original fica conservado.
5. Capturar correcção técnica do lançamento original de reconhecimento: estorno integral60 e substituição integral60, ambos fotografados. Outra pessoa revê o par exacto. Preparador aplica os dois numa transacção, conservando o original e sem alterar dívida/imposto/moeda.
6. Capturar conferência do período `QA-2026-10`, rever com outra pessoa e fechar. Pendências financeiras/contabilísticas impedem fecho; mudança de factos/regras exige nova conferência. Depois de fechado, novas gravações nesse período recusam; consultas e recuperação de recibos existentes continuam disponíveis. **Não existe reabertura.**

Após o ciclo de prova há uma obrigação60, saldo60, cinco lançamentos/dez linhas, débito bruto220/crédito bruto220 e uma versão de período fechado, além da versão aberta original. O valor220 é soma bruta de movimentos incluindo compensações, não saldo financeiro ou nova dívida.

As bases da equipa são distintas das bases de regressão e conservam as decisões futuras. Não usar reset para repetir o guião. Os demos anteriores 8002/8003/8005/8039/8048/8049 e os respectivos dados não foram alterados por esta entrega. A fixture documental SGF continua a ser recibo sintético; só a origem SGC desta composição passa pelo workflow nativo efectivo. Na demonstração SGC, o relógio de preparação foi explicitamente fixado em29/10/2026 para produzir a factura QA dentro do período artificial. Isto não valida políticas temporais/fiscais reais.

## Núcleo único e guardas

O pacote canónico `packages/general-ledger` reutiliza `PayableJournal` para captura, revisão, aplicação, linhas, equilíbrio, unicidade, recibos e auditoria de todos os efeitos. `LedgerCycle` acrescenta a orquestração do par correctivo e do fecho; não contém um segundo writer de lançamentos. O principal original permanece no snapshot; `amount_minor` da afectação/reversão é distinto, evitando contabilizar60 quando foram afectados20.

`CycleSchema::install` é explícito e recusa ledger com propostas/lançamentos existentes. Só foi executado em bases/roles novas no cluster55439. Acrescenta cinco tabelas append-only de grupos/resultados correctivos e conferência/revisão/fecho de períodos. No schema **novo**, o equilíbrio compara o montante explícito do efeito; o schema das demos anteriores não é actualizado no arranque. Constraints diferidas exigem o par correctivo completo no commit; foreign keys incluem âmbito; fecho exige revisão independente e nova versão fechada. Os nove históricos anteriores continuam append-only.

As rotas individuais de revisão/aplicação recusam partes correctivas com409 e orientam para o par. A orquestração usa os mesmos métodos internos, mas grava ambos os lançamentos e o resultado do grupo numa transacção. Falha entre os dois ou depois do recibo faz rollback integral. Mesma chave/conteúdo recupera o resultado; outra chave não duplica o mesmo efeito; conteúdo conflitante é recusado. Direitos e pessoa/contexto actuais são conferidos antes de recuperar recibos.

Fecho captura origens reconhecidas, efeitos confirmados, propostas/decisões/configuração e totais. O hash é calculado por cursores, sem carregar todo o livro em arrays; verificações por origem ainda fazem consultas individuais. Este percurso de escrita **não foi ensaiado a10.000 origens** e não tem capacidade de implantação validada. O fecho não apaga pendências, não inventa lançamentos e não fecha enquanto houver efeitos necessários por conferir/contabilizar. O bloqueio de empresa serializa a revalidação/aplicação.

## Adaptadores, interface e acessos

- SGF: contexto Contabilidade e permissões existentes por tenant/empresa/unidade, com mudança explícita/auditada de módulo para liquidações. Geração anterior de contexto não autoriza comandos novos.
- SGC: organização nativa, funções/acessos financeiros actuais e concessões contabilísticas QA explícitas em `pa_access`. A composição nativa usa `company_id=0/unit_id=0` no contrato comum e isola por tenant; isso não declara suporte de unidades empresariais que o adaptador nativo não possui. Actualiza/verifica actor, pessoa e direitos antes de escrever, respeitando manutenção/contexto de trabalho nativos.
- UI comum em `packages/general-ledger/ui/cycle.php`, servida pelos dois adaptadores. Propostas, impactos, fontes financeiras confirmadas, correcções, conferências de período, linhas e histórico. Listas limitadas a25, totais sobre o conjunto correspondente. Navegação considera também páginas de eventos/propostas, mesmo quando já não há mais lançamentos. O par inclui as duas fotografias mesmo que uma proposta esteja fora da página do diário.
- A consulta do workspace completo usa uma transacção própria `REPEATABLE READ READ ONLY`, sem `FOR UPDATE`. Leituras iniciadas dentro de transacções participam nelas; os comandos conservam bloqueios e estado actual. O percurso financeiro legado do SGC mantém o seu contrato anterior de leitura; não se afirma que todas as suas páginas foram convertidas para o novo leitor sem bloqueios.

Os dez direitos contabilísticos são os quatro anteriores e os seis novos aprovados: `view/prepare/validate/post`, `correct_prepare/correct_validate/correct_post`, `period_prepare/period_validate/period_close`, todos com prefixo `general_ledger.`. **12 concessões por fixture nova**: preparador7, revisor4, consulta1. Direitos de liquidação existentes reutilizados apenas QA: `payments_view`, `payment_prepare/payment_confirm`, `allocation_prepare/allocation_confirm`, `reversal_prepare/reversal_confirm`; preparação e confirmação são distintas. Nenhum direito ou acesso real/público foi concedido.

Ambos os destinos mantêm flags de ciclo e uso sintético **false**; path nativo por defeito é null. A composição QA fornece o pacote explicitamente. Não foram criadas migrações no destino, dependências novas ou emissão/contas reais. O SGC recusa a capacidade se o pacote não estiver composto, em vez de recorrer a um motor alternativo.

## Provas e condições

[Manifesto, fontes e hashes](proofs/common-ledger-complete-cycle-20261102.json). As datas referem-se à autorização; a execução prolongou-se pela sessão local seguinte. Segredos, cookies, configurações e logs ficam apenas na área QA privada.

| Prova | Resultado |
|---|---|
| Ciclo SGF com falhas/versões/revogação, todo revertido | 23 verificações |
| Mesmo contrato pelo adaptador SGC, todo revertido | 23 verificações |
| Segurança adicional: própria pessoa, direito correctivo revogado, bypass individual, par órfão no commit, falha depois do recibo, append-only nas cinco tabelas | 18 verificações, revertidas |
| HTTP SGF, decisões financeiras e contabilísticas reais no kernel | 70 verificações; um ciclo completo conservado |
| HTTP SGC, mesmo percurso no host nativo | 61 verificações; um ciclo completo conservado |
| Pós-verificação de leitura, conservação, guardas individuais e navegação longa | 10 SGF +10 SGC; sondagens novas revertidas |
| Preparação das duas demonstrações, sem comandos de negócio | 28 SGF +28 SGC |
| Regressão do primeiro efeito, afectado pela generalização do writer | 8 cenários/74 asserções, numa base nova, sem reset das provas anteriores |

As contagens acima identificam execuções e não devem ser somadas como testes únicos independentes: há verificações sobrepostas dos mesmos contratos. Uma execução adicional persistente do contrato SGC tem16 verificações e conserva o livro fechado; não acrescenta cobertura única à tabela.

Análise estática nativa dirigida aos quatro ficheiros alterados: PHPStan nível7, **zero erros**, com bootstrap do pacote comum e cache exclusivamente privada. Foram corrigidos tipos de retorno/arrays e a verificação explícita de utilizador interno, impedindo que uma conta de candidatura seja passada ao adaptador. Formatação dirigida com Pint; verificação de sintaxe dos ficheiros afectados registada no manifesto. Não se executou o script geral Composer que limpa configuração/cache.

Complemento após essa correcção: **cinco verificações** dos controladores confirmaram recusa403 de conta de candidatura nas três entradas e na ligação financeira, consulta200 com utilizador interno e fingerprint financeiro igual. Não se repetiram as sequências HTTP de negócio válidas.

**Concorrência real: cinco trabalhadores, ligações distintas.** Dois correctores aguardaram em `companies FOR UPDATE`, com cadeia de bloqueio observada por `pg_blocking_pids`; após libertação ambos receberam o mesmo resultado, com um par e cinco lançamentos totais. Um fecho aguardou enquanto o pai acrescentava uma versão de regra; após commit recebeu409 por evidência desactualizada, sem fechar. Nova captura e revisão permitiram dois fechos concorrentes: ambos recuperaram o mesmo fecho, exactamente uma versão fechada e um recibo factual. Não se atribuiu a espera a gargalo de auditoria nem se resolveu a divergência aumentando apenas o timeout.

As falhas injectadas existem só em callbacks CLI de teste, não em parâmetros HTTP. Foi comprovado rollback após o primeiro lançamento do par, após o recibo e após acrescentar a versão fechada. O teste do par órfão exerceu a constraint SQL; a guarda pública posterior409 foi comprovada nas verificações finais. Diagnósticos do auxiliar de preparação do demo corrigiram expectativas de texto e de formulário do revisor sem propostas; não houve decisão de negócio ou reset nessas tentativas.

No SGC, fingerprints dos documentos/itens/pagamentos externos/stock/orçamento originais mantiveram-se. No SGF, dívida e direitos foram conservados pelas consultas e sondagens revertidas. As seis associações protegidas e a cache bloqueada não foram consultadas para decisão, alteradas ou limpas. Provas válidas de carga, fila e liquidações anteriores foram reutilizadas por hash; não se repetiram matrizes/suites alheias.

## Limitações que continuam separadas

Este recorte só suporta MZN, imposto0, três contas artificiais, reconhecimento60, afectação/reversão20 e correcção técnica integral do reconhecimento, sem mudança comercial. Não há reabertura, plano PGC real aprovado, contabilidade de vendas/IVA/stock/salários, correcção comercial do principal, execução monetária, reconciliação bancária ou fecho legal geral.

O reconhecimento/fecho sintético não valida fiscalidade, exigibilidade, data contabilística real, adopção de pacote instalado ou passagem operacional de responsabilidade. Revisão visual pela equipa, feedback, aceitação e avaliação de carga/implantação permanecem pendências próprias. Nenhum benchmark novo ou índice foi criado. A leitura financeira anterior de páginas25/100 nos volumes1.000/5.000/10.000 conserva as provas existentes; o relatório integral ainda tem a limitação observada de cerca de12,6s para10.000 posições.

Sem publicação/push, activação de Compras, novo checkpoint ou aceitação presumida. A autorização funcional foi usada para concluir este ciclo conjuntamente, sem pedir confirmação de cada passo técnico.