# 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](proofs/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.