SGF/docs/GENERAL_LEDGER_DIRECT_COST_DELIVERY.md

# Oficina → custo directo validado → Contabilidade

03/11/2026. `COMMON-LEDGER-DIRECT-COST-SIM-v1` implementado localmente após «Autorizar o ciclo sintético proposto», no [recorte aprovado](GENERAL_LEDGER_DIRECT_COST_SCOPE.md). Código, interface, provas e demonstração própria. Não declara aceitação, checkpoint ou conclusão operacional de toda a aplicação.

## Percurso funcional

As fixtures novas executam os workflows existentes de oficina, autorização, apontamento, verificação técnica, taxas e cálculo. Não inserem uma aprovação de custo por SQL. O caso seleccionado usa material da empresa **2UN×50=100 MZN** e trabalho efectivo **105MIN÷60×100=175 MZN**. A composição efectivamente validada é **275 MZN de custo directo conhecido do perímetro seleccionado**, sem afirmar custo completo, margem, valorização de inventário ou salário.

`DirectCosts::conference` reutiliza a validação de actualidade e a composição exacta do serviço proprietário, numa leitura sem bloqueio de escrita. O adaptador `CostLedgerSource` exige consulta da oficina e dos custos; junta a ordem, cálculo/decisão, origens/decisões técnicas e taxas/decisões seleccionadas. Não chama o writer técnico/financeiro nem processa a outbox.

O mesmo `PayableJournal` captura, revê e aplica duas linhas: **D `QA-CUSTO-DIRECTO`275 / C `QA-COMPENSACAO-ENSAIO`275**, MZN, regra/período QA explícitos. São contas artificiais para provar a ligação técnica, sem política real de capitalização/PGC. A aplicação não cria dívida, consumo, tempo, preço, movimento de stock ou folha salarial. O percurso comprovado termina com **um lançamento, duas linhas, balancete/razão reconciliados e um fecho QA revisto distintamente**.

A interface liga perímetro, conferência actual, fontes e versões → impacto/proposta → revisão → aplicação → diário/balancete/razão → conferência e fecho do período. O razão e o diário voltam à ordem de custo, distinguindo-a de uma obrigação financeira. Listas e histórico têm janelas de25; uma selecção fora da primeira página continua acessível por ID autorizado. Não se muda o contexto automaticamente para validar ou lançar. As chaves dos formulários mantêm-se nas repetições idênticas e mudam com o conteúdo; IDs são números e hashes de versão permanecem cadeias exactas.

## Actualidade, identidade e limitações deliberadas

`gl_cost_sources` declara explicitamente a ordem, os dois identificadores lógicos de origem e o período composto. O instalador só aceita um livro SGF QA novo e vazio. O mapeamento é append-only e um trigger confere o âmbito contra a ordem. Não há associação automática de ordens antigas ou dos seis registos protegidos.

A identidade do efeito usa **âmbito + tipo + ordem/perímetro**, não o ID da nova versão do cálculo. A nova versão muda a fotografia/revisão, mas não autoriza outro reconhecimento do mesmo custo. Fonte, direitos, pessoa, regra, contas, período, origens e versões são revalidados sob a serialização da empresa antes da primeira aplicação. A revisão contabilística exige outra identidade/pessoa; não concede verificação técnica. A confirmação de repetição revalida a autoridade antes de recuperar o resultado existente.

Os **175 MZN conhecidos com taxa material ausente** continuam visíveis como incompletos e são recusados como total contabilizável. Uma composição efectiva de **100,0175 MZN** também é recusada: não há arredondamento inventado para cêntimos. Origem sucessora sem verificação não herda a anterior; torna o cálculo/fonte pendente. Aritmética monetária é exacta; apresentação usa divisão inteira e resto.

O fecho inclui as fontes de custo explicitamente compostas no seu período. Custo incompleto, não lançado, alterado ou com lançamento desactualizado impede o fecho. Fotografias, versões, decisões e impactos entram no hash de conferência. Mudar o custo **depois** de o lançar não gera outro lançamento, estorno ou correcção automática: a correcção de custo já lançado está expressamente fora desta autorização. Não existe reabertura.

Os adaptadores adicionais conservam a resposta/hash anterior quando existe apenas a fonte Sales: a nova composição de custos não envolve silenciosamente o pacote de conferência de vendas noutro hash. Os filtros de custo usam `cost_order_id`, separados de `sales_invoice_id` e do `obligation_id` de fornecedores. O SGC autónomo continua sem exigir oficina e recusa a origem de custo não composta. Os artefactos autónomos anteriores de25 e30 ficheiros não foram substituídos.

Uma prova adicional compôs **custo275 + fornecedor60 no mesmo livro**, usando uma recepção sintética controlada de fornecedor do recorte já autorizado, sem importação viva. A ordem e a obrigação financeira tiveram o mesmo ID inteiro: os filtros conservaram um lançamento/três eventos de cada tipo, sem misturar os montantes. O resultado conjunto foi dois lançamentos/quatro linhas,335MZN por lado e um fecho QA. Custo/outbox ficaram iguais e a posição de fornecedor permaneceu60; não se criou pagamento ou stock. A guarda de obrigações admite também esta composição Cost-QA, com a mesma validação efectiva de base/role/cluster; direitos de consulta/decisão de fornecedor foram acrescentados apenas nessa fixture de integração. Isto não demonstra a composição completa de Compras ou todos os seis módulos.

## Guardas e direitos

`SGF_COST_LEDGER_QA` fica **false sem configuração**. A extensão da guarda aceita apenas `testing`/`browser-testing` com opção explícita, PG loopback55439, cluster esperado, base `payable_sgf_<12hex>` e role não elevada `payable_history_sgf_<mesmo id>`, sem redireccionamento de ligação e com destino efectivo conferido. As regras anteriores de `sgf_tempo_test` ficam preservadas; não se utilizou essa base para estes testes.

Só as bases novas recebem as funções SQL `sgf_wo_environment`/`sgf_dc_environment` vinculadas ao seu próprio nome/role/cluster. Os ficheiros SQL/migrações originais e os destinos existentes não foram alterados por esta instalação. O arranque não instala `CostSchema`, não migra nem concede acessos.

| Perfil sintético | Direitos reutilizados |
|---|---|
| Preparação | workshop.view; direct_costs.view/prepare; general_ledger.view/prepare/post/period_prepare/period_close |
| Validação | workshop.view; direct_costs.view/validate; general_ledger.view/validate/period_validate |
| Consulta | workshop.view; direct_costs.view; general_ledger.view |
| Técnico / verificador | Direitos técnicos existentes, separados; sem Contabilidade implícita |

São **sete direitos contabilísticos distintos / nove concessões contabilísticas**, apenas nas novas fixtures. Direitos de contexto empresa/unidade são explícitos. Cinco actores sintéticos declarados; o utilizador auxiliar do construtor fica sem grants. Não há nomes de pessoas reais no código funcional ou novos direitos públicos/reais.

## Provas

[Manifesto e hashes](proofs/common-ledger-direct-cost-20261103.json). Bases de prova e demonstração da equipa são distintas.

| Prova | Resultado |
|---|---|
| Percurso efectivo completo |275 validado pelos workflows → um lançamento/duas linhas → relatórios → fecho QA; repetição com a mesma e outra chave sem duplicação |
| Regressão de custos |9 cenários /27 verificações, com rollback: parcial175, valor sem cêntimo exacto, versões/direitos/pessoa, quatro fronteiras de falha e identidade estável |
| HTTP real |51 verificações: CSRF419, recusas403/409/422, contextos, proposta/impacto, revisão, repetição, diário/razão e fecho |
| Isolamento e verificação técnica |10 verificações: contextos estrangeiros elegíveis de tenant/empresa/unidade, três direitos revogados e sucessor técnico efectivamente criado pelo workflow mas não verificado; tudo revertido |
| Concorrência |6 processos reais; detalhes abaixo |
| Compatibilidade de fornecedores |8 cenários /74 asserções do writer numa base nova; provas anteriores preservadas |
| Coexistência custo + fornecedor |IDs coincidentes, filtros/eventos separados,275+60=335MZN no mesmo writer e fecho conjunto; custo/outbox e saldo financeiro preservados |
| Compatibilidade Sales |Fonte actual comparada exactamente à fotografia comercial lançada; resultado/hash da conferência de período apenas com Sales igual ao anterior; balancete existente continua2400MZN por lado; só leitura |
| SGC autónomo |Recusa explícita do custo sem origem composta, sem schema de oficina exigido ou proposta criada |
| Demonstração e formulários |22 verificações HTTP/VM, incluindo4 dos formulários renderizados; zero comandos de negócio; prova privada de preservação da fixture |
| Pós-verificação de apresentação |Diário identifica ordem de custo, filtro retém1lançamento/3eventos, razão conserva origem e links; só leitura |

Na concorrência, a transacção titular reteve o bloqueio da empresa e preparou/aprovou uma **taxa sucessora com o mesmo valor50**, mas versão2. Um leitor terminou antes da libertação, vendo o estado confirmado de275 e nenhum lançamento. O aplicador aguardou no bloqueio real; após o commit da nova versão respondeu **409**. O valor igual não dispensou nova conferência. O ensaio criou e validou cálculo2 e nova captura/revisão contabilística. Dois aplicadores concorrentes recuperaram **o mesmo lançamento**, e dois fechos concorrentes recuperaram **o mesmo fecho/versão2**. Foram observadas as cadeias de bloqueio até ao titular e esperas `transactionid`/`tuple`. Originais técnicos, cálculo1 e registos anteriores da outbox ficaram iguais; os novos registos de custo são os sucessores explícitos do ensaio, todos ainda `captured_no_accounting`.

As quatro falhas injectadas (`after_header`, `after_lines`, `after_event`, `after_receipt`) desfizeram lançamento, linhas, histórico e recibo da tentativa; a repetição posterior concluiu sem duplicação. Os fingerprints antes/depois do percurso integral e HTTP conferem ordens, entradas/verificações, comandos de oficina, taxas/cálculos/decisões/comandos/eventos/outbox de custos, direitos e autoridade de obrigações. O mapeamento também tem prova específica de imutabilidade.

Tentativas de preparação dos helpers que falharam antes de comandos de negócio — chave de ordenação da outbox e import de uma classe no harness — foram corrigidas e preservadas como diagnóstico, sem reset; não são contadas como provas aprovadas. O primeiro probe da demonstração omitiu a geração de contexto e recebeu409; o cliente de teste passou a enviar o token, sem alterar guardas da aplicação. Uma correcção posterior dos rótulos do diário teve pós-verificação só de leitura.

Os formulários usam VM/DOM e rede simulados sobre o JavaScript efectivamente renderizado; isso não é execução num navegador. Sintaxe PHP/JavaScript e `git diff --check` constam do manifesto. Não se acrescentaram dependências. SGF não tem PHPStan/Pint instalados; não se declara execução dessas ferramentas. A análise estática nativa válida anterior é reutilizada no seu âmbito, sem repetir ficheiros nativos de aplicação que não mudaram.

## Demonstração e pendências

**http://127.0.0.1:8054/qa/cost-demo**, base/sessão/cookie/assets privados próprios, só loopback. Parte de oficina, taxas e custo275 realmente validados; **sem proposta contabilística, lançamento ou fecho iniciais**, para decisões individuais da equipa. Não reiniciar ou consumir este exemplo em testes destrutivos. Os perfis de Contabilidade consultam evidência técnica, sem adquirir poderes de técnico/verificador.

Continuam separados: revisão visual, carga sustentada e capacidade de implantação; contas/políticas reais e composição operacional completa entre módulos. Não se mediram novos volumes1.000/5.000/10.000, criaram índices ou validou capacidade a partir deste cenário. As demonstrações existentes continuam independentes; esta entrega não prova uma única instalação operacional com todos os seis módulos.

Sem valorização/lançamentos de stock, salários/CIF/lote industrial, preço de venda derivado do custo, operação fiscal/monetária real, correcção de custo já lançado, reabertura, migração/concessão no destino, activação de Compras, publicação, push, aceitação ou checkpoint. Seis registos, cache bloqueada, provas/checkpoints anteriores e trabalho alheio preservados.