SGF/docs/GENERAL_LEDGER_INDUSTRIAL_CORRECTION_DELIVERY.md

Correcção industrial1800→1820 — entrega local sintética

03/11/2026. COMMON-LEDGER-INDUSTRIAL-CORRECTION-SIM-v1. Autorização expressa: «Autorizar a correcção industrial sintética proposta». Implementado e testado o recorte aprovado, com o mesmo escritor contabilístico. Proposta original arquivada por hash antes de actualizar o seu estado; sem aceitação ou checkpoint presumidos.

Demonstração nova: http://127.0.0.1:8059/qa/cost-demo. Bases/roles próprias no cluster QA55439;8058 e anteriores preservadas. A demo começa com os originais directo275 e industrial1800 lançados, sucessores295 e1820 efectivamente validados e nenhum grupo correctivo ou fecho aplicado. As decisões da demonstração continuam individuais.

Percurso implementado

Os workflows industriais existentes criam/validam a taxa material sucessora51MZN/KG, mantendo20KG, trabalho500, conjunto/critério CIF e produção10UN. Resultado sucessor1020+500+300=1820,182/UN; residual300 separado, sem lançamento. Entradas, taxa anterior50, critério, resultados1800/1820, decisões e original contabilístico permanecem imutáveis.

O preparador captura original1800, nova origem1820, diferença20, contas/período e quatro linhas; outro utilizador/pessoa confere essa versão exacta. O mesmo serviço aplica numa transacção:

Parte	Débito	Crédito	Montante MZN
Estorno	QA-COMPENSACAO-INDUSTRIAL	QA-CUSTO-INDUSTRIAL	1800
Substituição	QA-CUSTO-INDUSTRIAL	QA-COMPENSACAO-INDUSTRIAL	1820

Os tipos industry.cost.reversal/replacement conservam lote, original, origem estável, versões e vínculo ao grupo. Não podem ser pedidos no effect-prepare público nem revistos/aplicados individualmente. O núcleo reutiliza capturas, revisão, escrita, eventos, comprovativos de repetição e autorizações existentes; não há segundo motor ou execução da outbox.

IndustrialCorrectionSchema instala apenas em livro SGF novo vazio. A guarda SQL diferida exige o resultado do grupo e as duas partes coerentes com original, âmbito, período, contas e montantes. Uma parte isolada equilibrada é recusada no commit. A delegação reconhece apenas o domínio industrial; mantém as validações SQL próprias de fornecedor e custo directo.

A confirmação revalida identidade/pessoa, direito, contexto, revisão, fonte industrial, resultado/taxas/critério, regra e período sob o bloqueio de empresa existente. Versão alterada, mesmo continuando1820, exige nova conferência. A substituição aplicada resolve a diferença com o original para a conferência do período. Uma alteração posterior torna a fonte pendente; não gera outra correcção ou reconhecimento automaticamente. Uma correcção por original neste recorte, sem cadeia adicional ou reabertura.

Integração e consulta

Página industrial mostra origem actual, diferença, fotografias das quatro linhas, decisões e autores, grupo, original, estorno e substituição. Grupos usam o mesmo ID/versão de comando, fundamentos obrigatórios e repetição estável para conteúdo igual. Captura superada permanece visível sem acção. As interfaces industrial, diário genérico e ciclo comum não expõem aplicação isolada das partes.

Filtros de lote, ordem e obrigação continuam tipados e aplicados antes de paginar. A janela de grupos industrial filtra o original industrial antes da paginação; não mistura o grupo directo com ID factual igual. O razão liga ao lote, e o fecho conjunto confere todas as origens, não só a página visível. Apenas direitos correct_prepare/validate/post existentes, mais direitos de origem/consulta/período já aprovados, nas fixtures novas. Não se concedeu direito real/público ou por nome/email.

Resultados e provas

Manifesto verificável: common-ledger-industrial-correction-20261103.json.

Prova dirigida	Resultado
Regressão a3c69acf5a50	7 casos/31 checks em rollback: impacto assimétrico, partes públicas recusadas,6 fronteiras de falha, recuperação, SQL contra parte órfã, versão alterada, direitos/pessoa, flag desligada, período fechado e ausência de cadeia implícita
Segurança nessa base	7 checks de contextos e direitos revogados, preservando originais
Âmbito aprofundado em d55f5fc71dcb	4 checks: tenant/empresa/unidade estrangeiros com pertença, direitos contabilísticos e pessoa financeira efectivamente presentes; original inacessível por âmbito; rollback integral
HTTP real nessa base	51 checks: autenticação, CSRF/contexto, fonte/versão, prévia, revisão distinta, recusa de partes, repetição mesma/outra chave, três lançamentos/seis linhas industriais, nove eventos, razão1820, fonte intacta e fecho recusado enquanto outros domínios estão pendentes
Coexistência nessa base	6 checks em rollback: três domínios correctivos — fornecedor, directo e industrial — passam as guardas SQL e mantêm filtros/eventos/totais separados, mesmo com IDs factuais iguais
Percurso conjunto nessa base	33 checks: completar venda/recebíveis, fornecedor e correcção directa; revalidar origens/direitos industriais e directos; um fecho e relatórios reconciliados
Concorrência 5b49607829f9	6 processos reais: leitor termina antes da libertação; escritor aguarda lock de empresa observado; após sucessora51/resultado1820 versão3 confirmados, grupo antigo recusa409; dois pedidos do grupo novo recuperam um único par; dois fechos recuperam um único fecho
Demo 61b694d72ae4	23 checks de três perfis/links e formulário renderizado;5 deles em Node VM. Sem comandos de negócio; impressão digital original/outbox/direitos exacta antes/depois

155 checks dirigidos, incluindo5 de formulário simulado, mais a prova concorrente de6 processos. As provas válidas de anteriores incrementos e pacotes congelados são reutilizadas por hash; não se repetiram suites alheias ou benchmarks de carga.

Industrial:3 lançamentos/6 linhas, bruto5420 por lado, saldo1820, residual300 fora do diário. Composição completa: 11 lançamentos/23 linhas, débitos8725=créditos8725MZN e1 fecho. Mantém cliente400, directo295 e fornecedor financeiro60. Na concorrência ficam dois grupos industriais preparados — um superado e um aplicado — sem duplicar a correcção. A conferência SQL final verifica apenas grupos efectivamente aplicados.

As primeiras tentativas completas de composição encontraram um contador de teste que ainda esperava só um grupo correctivo. O produto já tinha correctamente o grupo industrial e o directo; ajustou-se o auxiliar e conservou-se o estado parcial, sem reset ou prova de sucesso presumida. A prova concorrente completa correu em base nova. O pós-teste SQL inicial tentou validar também o grupo superado não aplicado; foi corrigido para validar resultados aplicados. O HTTP inicial parou numa expectativa do estado antigo requires_correction; o estado industrial preservado é requires_future_correction. Não se contam estas saídas parciais como provas válidas.

Preservação e limites

Na8058 continuam flag de correcção desligada e schema novo ausente; fontes, outbox, direitos, contagem inicial do livro e pacote de três fornecedores de conferência mantêm os valores/hash anteriores. Não se actualizaram bases antigas. A nova configuração de correcção é false por omissão. Originais industriais1800/1820 e outbox anteriores permanecem exactos também na prova concorrente; a versão3 é acréscimo sintético explícito para provar recusa de revisão desactualizada.

Seis associações pendentes, cache bloqueada, demos anteriores, configurações/direitos reais e alterações alheias preservados. Credenciais/dados de acesso permanecem privados. Sem stock valorizado, folha salarial, residual contabilizado, pagamentos/recebimentos novos, correcção em período fechado, cadeia adicional, reabertura, instalação no destino, activação de Compras ou publicação.

Revisão visual continua pendente: HTTP e Node VM não são prova de navegador. Carga sustentada/concorrência em volume e capacidade de implantação continuam pendentes separadas. O ensaio local não demonstra aplicação completa ou operação real. Sem experiências de índices ou índices no destino; sem aceitação ou checkpoint de encerramento presumidos.