# Correcção de custo directo275→295 — entrega sintética

03/11/2026. `COMMON-LEDGER-DIRECT-COST-CORRECTION-SIM-v1` implementado após «Autorizar a correcção sintética proposta», conforme o [recorte apresentado](GENERAL_LEDGER_DIRECT_COST_CORRECTION_SCOPE.md). Inclui código funcional, interface, testes e demonstração própria. Não equivale a aceitação, checkpoint, uso real ou conclusão operacional de toda a aplicação.

## Resultado

O cenário novo executa os workflows existentes: oficina/origens verificadas, taxas e composição100+175=275, revisão distinta e lançamento original275. Depois prepara/aprova taxa material sucessora60MZN/UN e cálculo **120+175=295**, preservando as versões anteriores. Não fabrica a decisão de custo por SQL.

O núcleo contabilístico comum captura, revê e aplica **um par indivisível**:

| Parte | Débito | Crédito |
|---|---|---|
| Estorno do original | QA-COMPENSACAO-ENSAIO275 | QA-CUSTO-DIRECTO275 |
| Substituição actual | QA-CUSTO-DIRECTO295 | QA-COMPENSACAO-ENSAIO295 |

O original permanece. O resultado comprovado é **três lançamentos/seis linhas**, movimentos brutos **845MZN por lado** e saldo do custo **295MZN**, diferença20. Balancete e razão reconciliam este mesmo livro e ligam à ordem/conferência. A validação do custo ou a outbox não desencadeiam contabilização automática.

## Núcleo, SQL e actualidade

Reutiliza `correct-prepare/validate/post`, tabelas de grupos/resultados, writer, recibos e histórico existentes. Os tipos `workshop.direct_cost.reversal/replacement` são distintos de `journal.reversal/replacement` dos fornecedores. Os filtros continuam tipados por `cost_order_id` ou obrigação de fornecedor; IDs inteiros coincidentes não juntam os domínios.

`CostCorrectionSchema` só instala em **livro SGF QA novo e vazio** com a composição de custos presente. Acrescenta marcador de capacidade e constraints diferidas para o par de custos. Confere original, âmbito, grupo, propostas, tipos de origem, período, datas, contas, ligação à mesma ordem/perímetro, revisão de substituição e reversão integral das linhas originais. O estorno deve igualar275 do original; a substituição deve corresponder ao295 capturado/revisto. Não exige igualdade entre os montantes das duas partes. A função antiga de integridade mantém a sua validação de fornecedores e delega apenas resultados explicitamente de custos à nova verificação. Demos/schemas anteriores não são actualizados.

A aplicação pública recusa revisão ou lançamento individual das partes. A base também recusa uma reversão isolada mesmo que equilibrada e com fotografia revista. Fonte/regra/período/âmbito/pessoa/direitos são revalidados sob o bloqueio de empresa antes de aplicar; recibo, dois lançamentos, linhas, histórico e resultado são uma transacção única. Uma falha depois da primeira parte ou depois do resultado desfaz a tentativa inteira.

A identidade do grupo liga ao lançamento original, com unicidade e repetição independente da chave. Uma nova versão de taxa/cálculo muda a fotografia mesmo quando o valor continua295: exige nova captura e conferência. Capturas anteriores ficam no histórico, assinaladas como superadas na interface. Uma correcção aplicada não pode ser repetida como outra correcção do mesmo original neste recorte.

A conferência do período resolve o original pela **substituição efectivamente aplicada no grupo**, comparando a sua revisão de fonte com o cálculo actual. Não basta que os totais coincidam. Uma fonte alterada depois do par volta a bloquear o fecho e não cria uma cadeia automática de revalorizações. Correcção anterior à data do original, noutro período ou em período fechado é recusada; não há reabertura.

## Interface e permissões

O percurso mostra original275, actual295 e diferença20, depois as quatro linhas, fotografias, revisões e fundamentos do grupo. A decisão é conjunta e distinta do preparador. A aplicação conjunta só aparece após aprovação das duas partes. Diário e interface de custos ocultam as acções individuais das partes; o backend mantém a recusa mesmo com pedido manual. Grupos de outras fontes são filtrados no servidor antes da paginação/contagem. Reviews/resultados/actualidade dos grupos visíveis são lidos em conjunto, sem pesquisa individual de todo o histórico por grupo.

Foram reutilizados os três direitos `general_ledger.correct_prepare/correct_validate/correct_post`, apenas nas fixtures novas: preparador prepara/aplica; validador revê. Com os anteriores são **dez direitos contabilísticos distintos / doze concessões contabilísticas por fixture padrão**. Não há direitos públicos/reais novos ou supervisão técnica implícita. A fixture de coexistência acrescenta apenas os direitos QA de fornecedor já existentes para o seu teste.

`SGF_COST_CORRECTION_QA` fica **false sem configuração**. Requer a opção sintética de custos já protegida, `testing`/`browser-testing`, destino efectivo exacto55439/cluster/base/role próprios e marcador de schema. O flag nas settings da nova fixture não altera configurações do destino. A demonstração8054 mantém flag false, schema ausente e os nove grants contabilísticos originais; a tentativa de usar a nova origem nesse modo é recusada. O SGC autónomo continua sem exigir oficina, provado também pela regressão do seu ciclo de fornecedores. Os artefactos financeiros congelados de25 e30 ficheiros não foram substituídos.

## Provas

[Manifesto e hashes](proofs/common-ledger-direct-cost-correction-20261103.json). Bases exclusivas para regressão, concorrência, coexistência e demonstração; nenhuma prova destrutiva usa a base da equipa.

| Evidência | Resultado |
|---|---|
| Workflow efectivo |275 original e295 sucessor pelos workflows; um par aplicado, relatórios845/295 e fecho QA revisto; originais/fontes/outbox/direitos exactos |
| Serviço e integridade SQL |7 cenários /30 verificações: impactos assimétricos, recusa de partes isoladas, seis fronteiras de falha, SQL contra órfão, versões, pessoa/direitos, período fechado e ausência de cadeia implícita |
| Segurança de contexto |8 verificações: tenant/empresa/unidade estrangeiros mas elegíveis e quatro direitos correntes revogados; probes com rollback |
| Pós-verificação das interfaces |Captura superada continua visível no histórico; páginas de custo, diário genérico e ciclo legado ocultam aplicação isolada, mesmo para partes antigas revistas mas não aplicadas; só leitura |
| HTTP real |58 verificações: CSRF419, contexto antigo/errado, recusas403/409/422, quatro linhas, revisão/aplicação conjunta, proibição de partes, repetição e relatórios/fecho |
| Concorrência |6 processos reais: leitor antes da libertação, grupo desactualizado409 após commit de versão, um par e um fecho após nova conferência |
| Coexistência com fornecedor |Dois domínios de correcção no mesmo schema/livro; seis lançamentos/doze linhas, bruto1025 por lado, grupos/filtros separados e fecho conjunto |
| SGC autónomo |23 verificações actuais do ciclo original de fornecedor, com rollback, no núcleo generalizado |
| Modo275 anterior |Fonte actual exactamente igual à fotografia lançada; pacote do único adaptador de período preservado; flag/schema novos ausentes, nove grants e recusa403 |
| Demonstração nova e formulários |23 verificações, incluindo5 em VM do JavaScript renderizado; sem comandos de negócio, um original275 e nenhum grupo/fecho inicial |
| Demonstração8054 |Fingerprint exacto de fontes/outbox/direitos, flag desligado e schema novo ausente; só leitura |

As seis falhas injectadas foram `after_header`, `after_lines`, `after_event`, `after_correction_first`, `after_correction_result` e `after_receipt`. A tentativa de finalizar uma parte pelo writer interno, em probe adversarial, foi recusada pela constraint diferida `GL_COST_CORRECTION_PAIR_REQUIRED`; o rollback restaurou o livro. A aplicação recuperada criou só um resultado completo.

Na concorrência, o titular reteve o bloqueio de empresa e confirmou taxa/cálculo de versão3, **mantendo295**. O leitor terminou antes da libertação vendo apenas o original275 e nenhuma correcção aplicada. O aplicador que aguardava recusou409 após o commit. Nova captura/revisão gerou outro grupo imutável; dois aplicadores recuperaram o mesmo resultado e dois fechos a mesma versão2. São **dois grupos preparados e um aplicado**, não duplicação de aplicação. Foram observadas cadeias até ao titular e esperas `transactionid`/`tuple`. Original275, cálculos1/2 e registos anteriores da outbox permaneceram iguais; os novos registos de versão3 são os sucessores explícitos do ensaio, todos ainda `captured_no_accounting`.

Na coexistência, ordem de custo e obrigação de fornecedor partilharam o mesmo ID inteiro. O custo conserva três lançamentos/nove eventos e bruto845; o fornecedor, após a sua correcção técnica já autorizada60/60, conserva três lançamentos/nove eventos e bruto180. O foco da ordem devolve apenas um grupo de custos. Custo actual295, outbox e saldo financeiro de fornecedor60 ficaram intactos. A origem do fornecedor é recepção sintética controlada, **não importação viva SGF**. Esta prova também exercita a validação SQL antiga e a nova no mesmo livro.

Provas válidas anteriores são reutilizadas e conferidas por hash. Não foram repetidas suites de stock, fiscalidade ou demais módulos. Sintaxe PHP/JavaScript e `git diff --check` dos dois repositórios constam do manifesto. SGF não tem PHPStan/Pint instalados; código nativo de aplicação não mudou e a qualidade estática anterior não foi repetida. Não se acrescentaram dependências. Os formulários foram exercitados em VM/DOM/rede simulados e por HTTP; isso não constitui execução num navegador nem revisão visual.

## Demonstração e limites

**http://127.0.0.1:8055/qa/cost-demo**. Base/sessão/cookie/assets próprios, só loopback. Começa com original275 realmente lançado e custo sucessor295 validado, **sem grupo de correcção ou fecho inicial**. Preparar o par, rever noutra função, aplicar e consultar diário/balancete/razão; depois conferir e fechar QA. Não reiniciar o exemplo da equipa nem as demonstrações anteriores.

Mantêm-se pendentes e separados: revisão visual, carga sustentada e capacidade de implantação; contas/políticas reais e composição operacional integral dos seis módulos. Não houve novos ensaios de1.000/5.000/10.000, índices ou declaração de capacidade a partir destes casos.

Sem cadeias adicionais de revalorização por arrasto, correcção em período fechado/reabertura, stock valorizado/contabilizado, salários/CIF, operações fiscais/monetárias reais, concessões/migrações no destino, activação de Compras, publicação, push, aceitação ou checkpoint. Os seis registos, cache bloqueada, dados/acessos reais, checkpoints, provas e trabalho alheio foram preservados.