SGF/docs/SGF_MODULE_FLOW_PREPARATION.md

Preparação dos módulos e do fluxo integrado SGF

Compras concluído no percurso local acordado —04/11/2026: C01–C10 na instalação existente8085, entrada única /compras, fornecedor novo até obrigação100MZN, com decisões distintas e movimento1UN. Não criar novas demonstrações por continuação. As referências antigas de instalações abaixo são históricas. Esta conclusão funcional local não equivale a implantação empresarial, pagamentos/contabilidade dessa origem ou aceitação visual.

Stock valorizado sintético entregue: entrada100/saída50/devolução25 no mesmo núcleo e consulta SGF SELECT-only. Fonte física original, taxa/revisão distintas, sequência e guardas SQL, relatórios/fecho QA; sem duplicar custos ou instalar no destino. Revisão visual/carga sustentada/implantação permanecem separadas.

Conferência de03/11/2026: matriz × código × provas e pendências reais. As notas datadas abaixo são históricas: o primeiro motor contabilístico e os ciclos QA aprovados já foram entregues. A matriz reconciliada distingue esses percursos de composição operacional, revisão visual e implantação ainda pendentes.

Correcção industrial autorizada e entregue: par1800→1820, residual300 separado, relatórios e fecho conjunto. Guardas SQL dos três domínios correctivos preservadas, origens tipadas, versões/direitos/concorrência verificados. Demo8059 nova, sem correcção inicial;8058 intacta. Sem cadeias adicionais, período fechado/reabertura, stock/salários ou implantação validada.

Continuação de leitura financeira: perfilagem e captura validada por janela, sem novo efeito. Conteúdo financeiro equivalente em10.000 posições; melhoria local observada22,0→12,9s, ainda com gargalo. Comandos, permissões, provas/demos/seis registos/cache preservados; estatísticas alteradas apenas na cópia QA, sem índices ou destino.

Ligação industrial autorizada e implementada: resultado1800/10UN, residual300 separado, diário/relatórios/fecho conjunto. Mesmo escritor, origem tipada estável, versões/direitos e concorrência verificadas; demo8058 própria sem lançamento industrial inicial. Sem stock valorizado, salários, correcção industrial ou reabertura. Preservadas8057 e anteriores; revisão visual, carga sustentada e implantação separadas.

Composição financeira integrada entregue: vendas/recebíveis, fornecedor e correcção de custo no mesmo livro e período QA. Painéis paginados por origem, direitos próprios e fecho conjunto revalidado; demo8057 sem decisões iniciais consumidas. Provas e demos anteriores preservadas. Lote/CIF industrial contabilizado exige a decisão do recorte seguinte, ainda só proposto.

Correcção de custo seleccionada concluída no âmbito autorizado: par275→295, relatórios e fecho QA, núcleo único, quatro linhas atómicas e SQL contra partes isoladas. Provas de versões/concorrência e coexistência com correcções de fornecedor no mesmo livro; fontes/outbox preservadas. Demo8055 separada;8054 mantém o modo anterior. Não declara reabertura, cadeias adicionais de revalorização, stock/salários ou implantação concluídos.

Ligação de custo directo autorizada e implementada: oficina → custo directo275 → diário/relatórios/fecho QA. Mesmos workflows técnicos/custos e writer; identidade estável por ordem/perímetro, incompletude/versões/concorrência verificadas. Demo8054 própria, sem decisões contabilísticas iniciais. Não abrange valorização de stock, salários, correcção de custo já lançado ou uma instalação operacional completa dos seis módulos.

Continuação de consulta integrada concluída: balancete e razão por conta SGF/SGC, abertura/movimentos/fecho por datas, páginas25/100, saldo acumulado e fontes ligadas. Reconciliação só de leitura dos ciclos de vendas, reversão/correcção de fornecedor e coexistência cliente/fornecedor, sem repetir escritas. Não autoriza contabilidade de stock/custos/salários nem declara relatórios fiscais ou implantação concluídos.

Continuação de 03/11/2026 concluída no recorte autorizado: Comercial → Recebíveis → Contabilidade, emissão efectiva de teste1.000, reconhecimento de três linhas, afectações400/600, reversão400 e fecho QA. Fornecedores preservados no mesmo writer; IDs de origens de cliente/fornecedor explicitamente separados e fecho conjunto comprovado. Nova demonstração8053, sem efeitos financeiros iniciais. As descrições históricas de vendas/recebimentos ainda sem contabilização ficam superadas apenas neste ciclo sintético; outras origens, revisão visual, carga sustentada e implantação permanecem separadas.

Continuação posterior autorizada e concluída: ciclo contabilístico sintético nas duas composições, com afectação/reversão20, par correctivo integral e fecho QA sobre reconhecimento60. Demos próprias SGF8050/SGC8051, sem tocar instalações anteriores. Esta entrega substitui apenas as indicações históricas abaixo de composição nativa/correcção/fecho ainda não implementados no recorte sintético; uso real, outras origens, revisão visual e implantação continuam separados. Inventário estático actualizado: seis módulos,13etapas,29fontes,zero ciclos obrigatórios e nenhuma ligação à base; não constitui prova de integração operacional.

Continuação contabilística autorizada e implementada: primeiro lançamento sintético de obrigação reconhecida, núcleo único, duas contas/período artificiais, conferência distinta e aplicação única. Oito cenários/74 asserções, concorrência real e 23 verificações HTTP; não declara contabilidade operacional, composição nativa ou implantação.

Estado financeiro mais recente: consulta de liquidação SGF separada dos bloqueios de escrita, sobre o histórico de pagamentos/afectações paginado e a conferência ligada à origem. Preserva o motor de posição e a autoridade de escrita. As medições de documentos em 1.000/5.000/10.000 e de pagamentos em 1.000 são ensaios distintos; não declaram cutover operacional, Financeiro completo ou implantação.

Continuação financeira SGF: recibo histórico de Compras para o núcleo comum, implementado somente em bases novas de ensaio, com 10 cenários/56 asserções e 17 verificações HTTP. A fotografia histórica não constitui fonte viva, cutover operacional ou Financeiro completo; mantém paginação/carga financeira e implantação pendentes.

Continuação SGF mais recente: encerramento individual de propostas Oficina → Stock, com retirada/recusa sem efeito físico e protecção contra confirmação concorrente. Não encerra as etapas financeiras/contabilísticas ainda em falta ou as pendências de implantação/visuais.

Continuações locais sintéticas posteriores: recepção nativa no livro comum, saída por origem de Oficina, ligação a entrega existente, repartição e devolução verificadas e devolução nativa com observação SGF. Estes incrementos superam partes da preparação inicial abaixo; não declaram todos os módulos completos nem uma composição operacional instalada. A última entrega consolida 36/544 provas próprias, preservando revisão visual e implantação como pendências separadas.

Primeira execução posterior: leitor comum de Stock, API e interface SGF, funcional exclusivamente com bindings sintéticos de teste. Entrega parcial: sem movimentos, sem actualização de demos ou segunda composição HTTP de Compras. As restantes etapas deste plano permanecem por implementar/ligar.

02/11/2026 — SGF-MODULE-FLOW-PREPARATION-v1. Pedido: começar a preparar as capacidades em falta para ligar etapas sem duplicar efeitos, criar gargalos evitáveis ou perder evidência. Entrega desta passagem: inventário técnico verificável, mapa de ligações, contrato de evidência proposto e primeiro incremento delimitado. Não é a implementação dos motores operacionais em falta.

Reutiliza o plano de núcleo comum, a demonstração integrada, os percursos financeiros sintéticos existentes e a consolidação de carga/concorrência/HTTP. Não reabre aceitações nem apresenta menus como módulos operacionais completos.

1. Inventário actual e decisão de construção

Área	Base a preservar/reutilizar	Preparação para completar
Compras	Requisições básicas em 8039; processos, recepção e conferência existentes em Compras	Transferir por incrementos completos, com contexto e direitos explícitos; não activar candidatas por arrasto
Stock	StockWorkflow, ReceiptWorkflow, InventoryLots, InventoryCounts, InventoryDispositions, InventoryReversals, WarehouseReservations em Compras	Leitura comum paginada primeiro; depois escritor único/adaptadores e ligação a consumidores SGF
Oficinas	Ordem/autorização, apontamentos verificados, custo e conversão comercial existentes	Ligar consumo físico por origem e versão, sem transformar observações anteriores em movimentos
Comercial	Cadastro, rascunhos, B1, cálculos e emissão/PDF de teste	Preservar revisão comercial e origens; completar ligações e validação fiscal própria antes de uso real
Financeiro	Núcleos comuns de orçamento e obrigações; recebimentos, pagamentos/afectações e reversões sintéticos	Compor os percursos, delimitar reconciliação e fontes históricas; não criar um segundo saldo
Contabilidade	Classificação/perfis/menus e primeiro núcleo de lançamento sintético por obrigação	Primeiro diário/extracto QA entregue; contas/reconhecimento reais, composição nativa, correcções, fecho e relatórios gerais continuam por delimitar/implementar

Actualização importante face ao menu antigo de Stock: a inspecção actual encontrou código de lotes, contagens, devoluções/abates, reservas e estornos em Compras. A ausência dessas ligações no SGF não significa ausência na origem. Os hashes e caminhos estão no inventário de preparação. São evidência de existência de fonte, não prova de execução, cobertura integral ou activação dessas capacidades. A extracção deverá seguir essas dependências, não copiar apenas StockWorkflow isoladamente ou reconstruir funcionalidades já existentes.

O manifesto do fluxo identifica seis módulos, treze etapas, um responsável por efeito, fontes, evidências de saída e lacunas. A verificação scripts/inspect-module-flow-plan.mjs confere caminhos/hashes, referências, responsáveis e ausência de ciclos nas dependências obrigatórias. Não carrega aplicações, não executa PHP nem consulta bases. Uma estrutura consistente não demonstra que a integração funcione.

2. Fluxo com ramos independentes

O desenho abaixo descreve o percurso sintético a construir, não ligações todas já activas. Os critérios específicos de cada documento permanecem nos serviços responsáveis.

flowchart LR
    R[Requisição e ordem aprovadas] --> Q[Recepção e aceitação física]
    Q --> S[Stock: movimento único]
    R --> F[Factura de fornecedor conferida]
    Q -. referências quando exigidas .-> F
    F --> O[Financeiro: obrigação única]
    O --> P[Pagamento confirmado e afectação]
    W[Oficina autorizada e apontamentos verificados] --> C[Consumo de material da empresa]
    S --> C
    W --> D[Rascunho comercial revisto]
    W --> K[Custo validado ou incompleto explícito]
    C -. origem futura de quantidade/custo .-> K
    D --> V[Factura de venda elegível]
    V --> A[Conta a receber e recebimentos]
    O -. efeito elegível .-> L[Contabilidade: lançamento e comprovativo]
    P -. liquidação distinta .-> L
    V -. efeito elegível .-> L
    A -. recebimento distinto .-> L
    S -. apenas com valorização definida .-> L

Regras para não criar dependências artificiais:

• A recepção aceite gera quantidade física; a factura não repete a entrada. Factura/obrigação não esperam pelo pagamento. Compras de serviços não passam obrigatoriamente pelo stock.
• Quantidade recebida e aceite são diferentes; as regras existentes de recepção parcial, rejeição, devolução e elegibilidade da factura são preservadas. A seta da recepção para a factura é condicional às regras existentes, não uma autorização para as omitir.
• A oficina não exige que um novo processo de compra seja aberto para usar stock já elegível. Material do cliente não é saída do stock da empresa. Apontamento técnico, consumo físico, custo e cobrança são efeitos separados.
• Custo incompleto fica incompleto; não bloqueia por decisão técnica toda a preparação comercial, nem é usado como preço de venda. A elegibilidade comercial continua explícita.
• A contabilidade consome cada efeito elegível individualmente. Não espera que toda a cadeia esteja liquidada, nem trata documento, dívida e pagamento como três reconhecimentos do mesmo principal. As regras de reconhecimento e contas ainda terão de ser delimitadas.
• Vencimento desconhecido é pendência documental visível; não é zero, data inventada ou bloqueio universal do reconhecimento. A fila de associações não atribui módulos automaticamente para desbloquear estas etapas.

3. Comprovativo exigido em cada passagem

Passagem	Responsável único pelo efeito	Evidência necessária para o consumidor	Recusa/pendência que tem de ficar visível
Compra → recepção	Compras confere o documento físico	Origem/versão, linhas recebidas/aceites, qualidade, artigo/armazém explicitamente mapeados	Origem ou mapeamento ausente, quantidade incompatível, recepção parcial
Recepção → stock	Inventory grava uma vez; a fachada de recepção delega na mesma transacção	ID do movimento, origem única, quantidades/unidade, versão do livro, fotografia	Repetição incompatível, lote/âmbito inválido; sem segunda entrada por factura
Factura conferida → obrigação	Payables	Fotografia conferida, principal/moeda, origem e comprovativo de reconhecimento, responsabilidade histórica	Fonte incompleta/incompatível; ausência de vencimento sinalizada separadamente
Pagamento → afectação	Financeiro	Evidência factual, confirmação distinta, saldo disponível, comprovativo de afectação	Sem dinheiro inventado; afectação não equivale a execução bancária
Oficina → consumo	Inventory, a pedido da oficina	Ordem elegível, origem do material/versão, artigo/armazém, comprovativo de saída	Material do cliente, origem já consumida ou falta de stock/âmbito
Oficina → custo/rascunho	Custos valida custo; Comercial cria rascunho	Apontamentos verificados, versões de taxa/preço próprias, revisão exacta	Taxa ausente ≠ zero; custo ≠ preço; sem duplicar material/tempo
Documento/efeito → lançamento	GeneralLedger futuro	Origem elegível, regra de contas vigente, período aberto, débitos/créditos equilibrados	Classificação isolada não é lançamento; não usar menu/rascunho como prova de operação
Livro → relatório	Serviço de leitura do domínio	Âmbito, filtros/data de corte, versão da fonte, ligação aos comprovativos	Fonte indisponível não é saldo zero; relatório definido não é relatório gerado

O contrato proposto no manifesto exige contexto/actor, origem por sistema/tipo/ID/versão/hash, tipo de efeito, decisão/data/fundamento, chave de repetição, correlação, âmbito de autorização e estado anterior/posterior. Quantidades usam a representação exacta do domínio (milésimos no stock); moeda e política de arredondamento acompanham efeitos monetários. Evidência original é identificada por referência protegida, sem copiar documentos privados para logs/relatórios técnicos.

Este contrato ainda não está implementado como motor transversal. Os comprovativos e auditorias existentes continuam a ser autoridade nos seus percursos. O consumidor terá de conferir autenticidade/âmbito/origem/versão, não apenas confiar nos campos enviados pelo browser. Uma correlação facilita rastreio, mas não substitui unicidade: a chave de efeito deverá incluir empresa, origem factual estável e tipo de efeito. Uma alteração de versão não autoriza repetir a mesma entrada; correcção/compensação tem origem própria ligada ao original. Nenhum ID igual entre aplicações prova correspondência empresarial.

4. Continuidade, falha e concorrência

Cada comando deve terminar com comprovativo ou pendência explícita. Antes da execução mostra a origem/versão e o impacto; na confirmação revalida permissões, contexto, versões e dependências. Evidência insuficiente impede apenas a operação dependente, conservando o restante trabalho e permitindo consulta/correcção.

Na mesma base, efeito, recibo de repetição e auditoria têm de ficar na mesma transacção. Uma fachada não deve chamar dois escritores concorrentes. Se houver envio posterior a outro domínio, a intenção e o resultado têm de ser duráveis, com estado consultável e repetição idempotente; não acrescentar broker remoto ou executor global antes de existir necessidade concreta. Os registos/outbox já existentes não passam a executar contabilidade por esta preparação.

Perda de resposta: consulta por chave/origem recupera o resultado. Mesma chave com conteúdo diferente recusa. Versão antiga exige nova conferência. Falha entre efeitos não pode apresentar o próximo como concluído. Corrigir não apaga o original: acrescenta decisão/compensação e exige a revisão aplicável. Não prolongar transacção durante o tempo humano de leitura/confirmação; não chamar serviços externos mantendo locks.

5. Evitar repetir os gargalos observados

O StockController de origem pagina movimentos, mas também lê todos os artigos/armazéns/saldos e consulta resumo de lotes por par. Isso é um risco encontrado no código, não uma medição nova de lentidão. A futura consulta SGF não deve copiar esse padrão integral para cada página.

• Paginar/filtar no servidor com ordenação estável; carregar metadados e referências necessárias, sem corpos documentais ou catálogos completos em cada resposta.
• Agregar movimentos/saldos/lotes para os pares da página em conjunto, sem uma consulta por linha. Filtros por saldo têm de ser aplicados antes de paginar, sem alterar os totais.
• Usar uma fotografia de leitura coerente e limitar o tempo de transacção. Revisão do livro e critérios de corte explícitos; versões por par não são substituídas por uma versão global arbitrária.
• Conservar por enquanto a ordem de locks e a protecção de saldo vazio da origem. A experiência da fila mostrou serialização por empresa; não remover esse lock apenas para melhorar um benchmark. Medir depois por tipo de escrita e dependência real.
• Medir tempo, consultas e memória por página; separar fonte, adaptador e renderização. Índices só na base sintética durante o ensaio e com ganho identificado separadamente. Não transportar automaticamente o índice da auditoria para o livro de stock.

Não se garante ausência de gargalos antes das medições. Estes são critérios de construção/verificação para os encontrar cedo, sem confundir provas locais com capacidade de implantação.

6. Ordem de entrega preparada

Incremento	Resultado a demonstrar	Condição de avanço
I1 — SGF-STOCK-READ-SIM-v1	Fonte comum/adaptador de consulta de artigos, armazéns, existências e movimentos	Âmbito delimitado em STOCK_READ_SCOPE.md; fonte ausente, recusas, totais e paginação comprovados
I2 — recepção → stock	Mesmo escritor e origens de Compras nas duas composições	Paridade, atomicidade, idempotência e concorrência; sem migração de dados antigos por replay
I3 — oficina → consumo	Ligação explícita por origem/versão, com comprovativo físico	Sem saída duplicada; cliente/empresa separados; falta de saldo e correcção comprovadas
I4 — composição financeira	Reutilizar obrigação, liquidação e recebimentos existentes	Um responsável pelo saldo; histórico e evidências recuperáveis sem conciliação bancária presumida
I5 — primeiro lançamento sintético	Uma classe de efeito, regra de contas e período delimitados	Motor com equilíbrio, versão, unicidade, compensação e histórico; sem declarar contabilidade geral completa
I6 — relatórios e fecho	Leituras reconciliadas e depois fecho/reabertura delimitados	Relatórios rastreáveis ao livro; política de período/correcção antes de fechar

O desenvolvimento destas capacidades pode correr por etapas com fontes sintéticas explícitas; não precisa de esperar por pessoas/dados reais, revisão visual pendente ou publicação. Uma etapa seguinte não deve usar uma simulação oculta como se fosse efeito operacional da anterior. A implementação de I1 é o próximo trabalho delimitado; esta passagem não a declara executada.

7. Prova e preservação desta preparação

Executar com o Node fixado: C:/laragon/tools/sgf-tempo/node-v24.22.1-win-arm64/node.exe scripts/inspect-module-flow-plan.mjs. O resultado é um inventário estático de fontes e consistência do desenho, não teste funcional ou ensaio de carga. Nenhuma suite válida anterior precisa de repetição nesta passagem documental.

Não se alteraram rotas, navegação, motores, configurações, dependências, schema ou direitos. Não se consultaram bases, manifestos privados ou credenciais. Os seis registos protegidos, a cache bloqueada, 8039 e outras demonstrações foram preservados. Compras foi lido apenas como fonte; sem alteração/activação de candidata. Sem publicação, push, checkpoint ou aceitação presumidos.

Pendências independentes: implementação das ligações delimitadas; provas funcionais por incremento; revisão visual; validação de capacidade/implantação; decisões individuais das seis associações. O inventário de fontes não encerra nenhuma delas.

02/11/2026 — consulta financeira nativa ligada em QA

Consulta paginada SGC: facturas/pagamentos/auditorias nativos, dependências conjuntas por página e motor financeiro comum.9testes/113asserções,26casos afectados/183asserções e18verificaçõesHTTP; medições1.000/5.000/10.000 disponíveis. Fonte histórica viva somente nativa QA; SGF mantém recibo de ensaio. Flag nativa false e pacote instalado preservado. Sem activação/cutover, aceitação presumida, publicação ou alteração dos seis registos/cache. Revisão visual, carga sustentada e implantação separadas.

02/11/2026 — conferência da origem e selecção financeira ligadas

A conferência financeira por origem permite abrir documento/posição/propostas/eventos fora da primeira página e conservar o foco na ligação à selecção para pagamentos. Corrigida a selecção de obrigações que ficava limitada à primeira página, e a evidência documental passou a usar a proposta exacta do reconhecimento, independentemente das versões visíveis. Cinco cenários/34 asserções, integração dirigida/18 asserções e 20 verificações HTTP da conferência por origem. Nenhum pagamento ou afectação criado; fingerprint financeiro anterior integralmente preservado. O livro de pagamentos mantém a consulta própria, ainda sem paginação; não confundir este incremento com ligação histórica SGF viva, cutover, contabilidade ou implantação. Revisão visual e carga sustentada continuam separadas. Seis registos e cache preservados.

02/11/2026 — histórico de liquidação SGF paginado

Pagamentos e afectações paginados: quatro janelas para pagamentos/propostas/afectações/eventos, filtros pelos pagamentos antes da contagem e leitura conjunta de decisões/reversões. Montantes por afectar consideram todo o histórico, independentemente da janela. Filhos ligam ao pagamento e à origem reconhecida; filtros de documentos e de pagamentos permanecem distintos. Seis cenários/53 asserções, 29 verificações HTTP e complemento de navegação. Em 1.000 pagamentos sintéticos: 3.038 → 35 consultas, sem índices novos. Não substitui os ensaios de 1.000/5.000/10.000 documentos. Bloqueios de autorização existentes mantidos; concorrência sustentada, revisão visual e implantação não validadas. Fonte histórica SGF viva/cutover, banco/reconciliação e contabilidade continuam separados. Demos, seis registos/cache e direitos reais preservados; composição nativa instalada não activada.

02/11/2026 — consulta de liquidação com autorização própria de leitura

Leitura financeira SGF sem bloquear empresa/actor: callback exclusivo para consulta paginada, fotografia REPEATABLE READ READ ONLY por pedido, comandos e construtores antigos conservados. Quatro cenários/23 asserções e 11 verificações HTTP dirigidas. Três processos comprovaram: leitor conclui antes da libertação, leitura antiga e confirmação aguardam em companies FOR UPDATE (cadeia directa ou pela fila), confirmação posterior/repetição com um único efeito; todas as alterações revertidas. Fingerprint financeiro e artefactos das provas anteriores preservados. Não repetir benchmarks válidos nem confundir esta espera com medição de throughput/capacidade. Composição nativa instalada, seis registos/cache e demos intactos. Revisão visual, implantação e capacidades financeiras ainda não entregues continuam separadas.

02/11/2026 — livro financeiro ligado ao relatório e fronteira contabilística

Relatório de obrigações reconhecidas implementado: filtros/âmbito comuns, captura coerente, todas as posições em janelas de 100, componentes reconciliados e saldo global indeterminado quando existe evidência divergente. Primeiro percurso completo de relatório do domínio financeiro; não razão/balancete. 10.000 posições com conteúdo igual antes/depois da optimização, 6.607 → 2.313 consultas, 19,1 → 12,6 s, 34 → 32 MiB. Tempo residual continua limitação e requer perfilagem; sem índices novos ou capacidade de implantação declarada. Três cenários finais/17 asserções, livro de afectações reconciliado e 17 verificações HTTP; provas e fingerprints anteriores preservados.

O primeiro lançamento exige decisão própria: COMMON-LEDGER-PAYABLE-SIM-v1, principal 60 MZN, duas contas e período artificiais, preparação/revisão distintas, aplicação atómica/única, quatro direitos exclusivamente na fixture QA. Está apenas especificado, sem motor/schema/direitos/lançamentos implementados, por preservar a exclusão de lançamentos por arrasto do AGENTS.md. Não antecipar autorização, aceitação, checkpoint, activação de Compras ou publicação. Seis registos/cache/demos intactos; revisão visual e implantação separadas.