SGF/docs/SGF_RECEIPT_WORKFLOW_DELIVERY.md

# Recepção de mercadoria no SGF — entrega funcional QA

03/11/2026. Está implementado o percurso **ordem → conferência no SGF → confirmação → movimento único → histórico**. A configuração operacional permanece desactivada no destino.

## Demonstração utilizável

Nova composição isolada, com uma ordem de 2 cx, nenhuma recepção e nenhum movimento inicial:

- [Recebedor sintético](http://127.0.0.1:8064/qa/enter/actor?open=1): conferência e confirmação.
- [Leitor sintético](http://127.0.0.1:8064/qa/enter/validator?open=1): consulta sem capacidade de confirmar.
- [Emissor da ordem](http://127.0.0.1:8064/qa/enter/issuer?open=1): a política original impede receber a própria ordem.

Seleccionar a ordem, preencher guia/data, escolher armazém, marcar a linha e indicar quantidades recebida/aceite, qualidade e artigo. Conferir o impacto e confirmar. Aceitar integralmente 2 cx conclui a ordem; recepção parcial conserva os acumulados. Reservas/rejeições exigem evidência e não se tornam aceitação automaticamente. Abrir a recepção no histórico mostra o documento e o movimento original.

Se a resposta se perder, repetir a mesma confirmação recupera o registo original. O formulário conserva a chave preparada. Alterar campos exige nova prévia; uma origem entretanto alterada exige nova conferência. A prévia tem validade de dez minutos; o histórico permanece consultável sem repetir comandos.

As entradas automáticas acima pertencem apenas ao launcher privado em loopback, fora das rotas operacionais. Cookie, armazenamento e bases são novos; 8039, 8062/8063 e restantes demonstrações permanecem preservadas.

## Workflow e autoridade únicos

`ReceiptRuntime` compõe localmente o `ReceiptWorkflow` original de Compras, incluindo políticas, validação, conflitos, quantidades cumulativas, auditoria e hooks de lotes/reposição. Não usa um conector HTTP ou um novo algoritmo de recepção. O empacotamento transforma somente tokens PHP de namespace `App` para permitir coexistência com os modelos SGF. Expressões de negócio e strings não mudam; originais e pacote têm hashes fixados.

O writer físico continua a ser `inventory-write/releases/0.1.0`, manifesto `f0b99e591f9a4df135e685f64ceffad77bed259222debe0f34c20f95e3cad800`. Não existe cópia SGF concorrente de recepções ou movimentos. Documento, linhas, movimento, auditoria original e proveniência SGF pertencem à mesma transacção nativa. A proveniência regista contexto/operador SGF, versão da composição e recepção; falhar essa auditoria desfaz a confirmação inteira. Repetições não duplicam efeito ou proveniência.

Operador, tenant de origem, empresa/unidade SGF, ordens e armazéns são ligados explicitamente na fixture. Não se presume equivalência numérica entre identificadores nem se fazem associações automáticas. A prévia cifrada vincula operador, contexto, ordem, revisão, versão da composição e prazo. Na confirmação, o workflow original revalida a operação.

O host bloqueia e revalida os direitos/participação até terminar a transacção nativa; não escreve uma segunda cópia de negócio. Ligação, autenticação e ambiente temporários são restaurados no sucesso e na recusa. O contexto de execução de reposição conserva o singleton original.

Os direitos apresentados durante a implementação são `purchasing_receipts.view` e `purchasing_receipts.confirm`, ambos de unidade, apenas nas novas fixtures. Não foram adicionados ao catálogo público ou concedidos a contas reais. A política nativa permanece obrigatória, incluindo separação do emissor. O percurso pertence a Compras e usa sessão, CSRF e geração de contexto. A ligação na página de Compras depende da capacidade explícita e do direito na unidade.

Configuração desligada/produção recusam antes de aceder à fonte. Host, porta, bases/roles, cluster, localização e manifesto estão restringidos às composições QA novas. Não se instala ou activa a candidata de Compras no destino.

## Provas dirigidas e reutilização

[Manifesto com resultados e hashes](proofs/receipt-composition-20261103.json): **68 verificações de auxiliares**, não 68 percursos de negócio independentes.

| Grupo | Verificações | Resultado |
| --- | ---: | --- |
| Percurso HTTP SGF | 30 | Prévia sem efeitos, recepção parcial/qualidade, movimento único, histórico, repetição e recusas de contexto, versão, acesso e quantidade cumulativa |
| Concorrência/recuperação | 10 | Dois workers e sessões independentes: mesma chave201/200; intenções diferentes201/409; falha após inserção física, rollback e recuperação |
| Proveniência atómica | 6 | Falha da auditoria desfaz documento/movimento/auditoria original; recuperação sem duplicação; ordem integralmente aceite chega a `complete` |
| Contrato de composição | 4 | Desligado/produção sem SQL; contexto nativo e restauração do host |
| Entrada React | 6 | Capacidade/direito/unidade, desligado e preservação de requisições |
| Demonstração sem consumir decisões | 9 | Perfis, página/script e fingerprint de negócio inalterado |
| Assets compilados servidos | 3 | Página inicial e JS/CSS correspondem ao build privado |

Na regressão, uma ordem recebeu 1 cx/0,75 aceite e mais 1 cx/1 aceite: dois movimentos, 1,75 cx no total, com `quality_pending`. Outro cenário completou 2 cx por quatro recepções de 0,5 cx, incluindo concorrência e recuperação. Estes dados são de regressão; a demonstração continua sem recepções iniciais.

As primeiras21 e depois29 verificações válidas foram conservadas e reutilizadas após corrigir duas expectativas do auxiliar: o validador original devolve422 para armazém de outro tenant antes da verificação de ligação; a tabela nativa de facturas é `invoices`. Não se repetiram as confirmações já aprovadas nem se apagou a execução parcial. As suites gerais, a fila administrativa e a carga anterior não foram repetidas.

Durante a conferência detectou-se alteração paralela ao `GoodsReceiptController` de Compras. Foi preservada; esse controlador não é usado pelo adaptador, que chama directamente o workflow original. O pacote continua fixado na versão testada e o manifesto regista os dois hashes, sem adoptar ou sobrescrever o trabalho alheio.

## Estado, limites e próximo método de trabalho

**Funcionalidade tecnicamente encerrada em QA:** interface SGF até ao histórico com workflow e writer originais. A ordem de entrada é uma fixture emitida; não se declara criação/emissão de ordens pela interface SGF ou repetição de adjudicação/aprovação. A instalação geral de procurement continua separada.

O selector apresenta até100 artigos da origem; pesquisa completa de catálogos maiores permanece pendente. Ordens e histórico têm paginação no servidor. Não se validam carga sustentada, revisão visual, Octane com workers persistentes, separação owner/runtime ou capacidade de implantação. As roles novas são proprietárias somente das suas bases QA; o pacote com namespace próprio é uma composição delimitada.

Sem factura, obrigação, pagamento, lançamento ou ligação stock–custos por consequência da recepção. Seis registos protegidos, cache bloqueada, provas/demonstrações anteriores e configurações/direitos reais preservados. Sem publicação, activação no destino, aceitação presumida ou checkpoint.

Após a orientação do utilizador, as próximas entregas devem concluir conjuntos funcionais e reutilizar provas válidas. Definir contratos entre módulos durante a construção e testar as fronteiras alteradas/percurso completo na ligação. Não substituir conclusão de funcionalidades por novos ensaios de optimização.