172 lines
28 KiB
Markdown
172 lines
28 KiB
Markdown
# 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](PURCHASING_COMPLETION.md), 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](GENERAL_LEDGER_STOCK_VALUATION_DELIVERY.md). 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](MODULE_IMPLEMENTATION_AUDIT.md). 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](GENERAL_LEDGER_INDUSTRIAL_CORRECTION_DELIVERY.md). 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](SGF_PAYABLE_REPORT_CAPTURE_DELIVERY.md), 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](GENERAL_LEDGER_INDUSTRIAL_DELIVERY.md). 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](GENERAL_LEDGER_COMPOSITION_DELIVERY.md). 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](GENERAL_LEDGER_INDUSTRIAL_SCOPE.md), ainda só proposto.
|
||
|
||
**Correcção de custo seleccionada concluída no âmbito autorizado:** [par275→295, relatórios e fecho QA](GENERAL_LEDGER_DIRECT_COST_CORRECTION_DELIVERY.md), 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](GENERAL_LEDGER_DIRECT_COST_DELIVERY.md). 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](GENERAL_LEDGER_REPORTS_DELIVERY.md), 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](GENERAL_LEDGER_SALES_RECEIVABLE_DELIVERY.md), 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](GENERAL_LEDGER_COMPLETE_CYCLE_DELIVERY.md), 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](proofs/module-flow-ledger-cycle-update-20261102.json): 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](GENERAL_LEDGER_DELIVERY.md), 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](SGF_SETTLEMENT_READ_ISOLATION_DELIVERY.md), sobre o [histórico de pagamentos/afectações paginado](SGF_SETTLEMENT_PAGED_READ_DELIVERY.md) e a [conferência ligada à origem](SGF_PAYABLE_EVIDENCE_FOCUS_DELIVERY.md). 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](SGF_PAYABLE_HISTORY_RECEIPT_DELIVERY.md), 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](WORKSHOP_STOCK_PROPOSAL_CLOSURE.md), 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](STOCK_RECEIPT_LINK_DELIVERY.md), [saída por origem de Oficina](WORKSHOP_STOCK_DELIVERY.md), [ligação a entrega existente](WORKSHOP_DELIVERY_LINK.md), [repartição e devolução verificadas](WORKSHOP_MATERIAL_CYCLE.md) e [devolução nativa com observação SGF](NATIVE_WAREHOUSE_RETURN_DELIVERY.md). 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](STOCK_READ_DELIVERY.md), 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](PURCHASING_COMMON_CORE_PLAN.md), a [demonstração integrada](PRODUCT_DEMO.md), os percursos financeiros sintéticos existentes e a [consolidação de carga/concorrência/HTTP](MODULE_ASSOCIATION_LOAD_CONSOLIDATION.md). 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](proofs/module-flow-preparation-20261102.json). 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](integration/sgf-flow-plan.json) 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.
|
||
|
||
```mermaid
|
||
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](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](NATIVE_PAYABLE_PAGED_READ_DELIVERY.md): 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](SGF_PAYABLE_EVIDENCE_FOCUS_DELIVERY.md) 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](SGF_SETTLEMENT_PAGED_READ_DELIVERY.md): 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](SGF_SETTLEMENT_READ_ISOLATION_DELIVERY.md): 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](SGF_PAYABLE_REPORT_DELIVERY.md) 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](GENERAL_LEDGER_FIRST_SYNTHETIC_SCOPE.md), 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.
|