# Oficina → rascunho: correcção e cancelamento controlados

**Autorização técnica posterior de 28/10/2026:** o utilizador autorizou implementar e demonstrar `WORKSHOP-BILLING-CORRECTION-SIM-v1` exclusivamente em `sgf_tempo_test`, sem aplicar migrações/concessões em desenvolvimento, activar uso real ou publicar. Substitui apenas as restrições históricas de etapa documental, preservando decisões/limites. Ver [entrega e provas](WORKSHOP_BILLING_CORRECTION_DELIVERY.md); sem aceitação antecipada.

28/10/2026. Proposta `WORKSHOP-BILLING-CORRECTION-SIM-v1`. Autorizada nesta etapa apenas a especificação. Sem implementação, migrações, concessões, dados reais ou publicação. Preservar a entrega aceite `3932b94`, instalações técnicas `30029b9`/`d071bc0`, checkpoints anteriores, fotografias e limitações de prova. Uso real continua bloqueado.

## 1. Problema e fronteira

O primeiro recorte gera uma prestação e um rascunho ligados à proposta revista, e bloqueia a sua edição e a reutilização das origens. É necessário corrigir a preparação comercial sem apagar o original nem facturar duas vezes o mesmo recurso. Cancelar esta preparação não cancela a ordem, a execução técnica, um documento fiscal, uma dívida ou um lançamento.

Proposta mínima: mesma ordem/empresa/unidade, cliente e MZN; origens seleccionadas integralmente; apenas destinos ainda em rascunho, sem confirmação B1 e sem documento derivado. Correcção de preço, fonte comercial, descrição ou serviço compatível, mantendo quantidades técnicas, fica no primeiro recorte. Mudança de cliente, moeda, repartição parcial, inclusão/exclusão de origens e origem técnica corrigida ficam bloqueadas para revisão de âmbito própria. Assim não se altera implicitamente a ordem nem o vínculo comercial original.

Uma correcção técnica permanece no circuito de oficina e exige nova verificação técnica; a revisora comercial não edita apontamentos ou verifica execução. Se a origem/tarefa seleccionada ficar obsoleta, assinalar o destino como desactualizado e bloquear a aplicação da correcção comercial deste recorte. Não usar aprovação anterior para legitimar dados novos.

## 2. Modelo proposto: substituição, não edição

Preservar prestação/rascunho, proposta, decisão, geração e utilizações originais. Correcção cria pedido versionado que referencia a geração e versões exactas dos destinos, motivo e composição anterior/proposta. Submissão é imutável; qualquer mudança material cria sucessora explícita e nova decisão distinta.

Após revisão aprovada e nova conferência de elegibilidade, criar **nova prestação e novo rascunho**, com relação explícita «substitui/substituído por». Marcar o par antigo como comercialmente substituído por registo de estado append-only, sem alterar as suas linhas ou fotografias. Nunca apresentá-lo como destino actual ou elegível para confirmação por outro percurso. Manter consulta histórica, inclusive a partir das origens técnicas.

O registo de utilização canónica das origens continua único: não apagar `wb_claims` nem inserir o mesmo consumo como nova ocorrência. Propor cadeia própria de destinos comerciais sobre essa utilização, com no máximo um destino actual. Aplicar a substituição, o novo destino e a mudança de elegibilidade atomicamente; não pode existir janela com ambos activos ou com a origem livre.

Os triggers actuais continuam a proibir edição directa. Uma implementação futura precisará de um caminho de sucessão próprio, limitado e revisto, sem desligar triggers, usar flags de sessão como autorização ou permitir gerar novo rascunho pela edição normal de A. Não basta acrescentar um botão: a base e todos os percursos de confirmação devem reconhecer o destino substituído/cancelado.

## 3. Cancelamento proposto

Pedido de cancelamento identifica geração/destinos e versões, motivo, autor e revisão distinta. Aplicação aprovada acrescenta estado «Preparação comercial cancelada», preservando os dois rascunhos e as origens como histórico. Não apagar ou anular acontecimentos técnicos; sem nota de crédito, devolução de stock, reembolso ou comunicação externa.

**Recomendação para o primeiro recorte:** cancelar não liberta automaticamente origens para nova cobrança. Mantém-se a utilização canónica e bloqueiam-se novos destinos; reabertura exige novo pedido versionado com revisão distinta e âmbito próprio. Isto evita que cancelamento seja usado como forma de duplicar geração. Reabertura não será implementada por inferência.

Cancelamento de um destino já substituído, cancelado, confirmado ou com dependências é conflito. Não procurar e cancelar automaticamente a versão mais recente. Cancelar pedido ainda não aplicado é desistência da proposta, não cancelamento dos rascunhos.

## 4. Estados, dependências e acessos

Pedido: preparado/submetido → aprovado ou recusado → aplicado. Desistência antes da aplicação fica registada, sem apagar o pedido. Um pedido aprovado não muda o destino até aplicação transaccional. Fonte/destino/versão/condições alterados invalidam a actualidade da aprovação; aplicação exige nova conferência. Pedido concorrente não substitui silenciosamente outro.

Destino: actual, substituído ou preparação cancelada, com causa e ligação às decisões. Estado de rascunho comercial permanece distinto de confirmação B1, fiscalidade e execução da oficina. Uma função comum de elegibilidade deve ser usada por edição/recarregamento, nova geração a partir da prestação, confirmação/revisão B1 e restantes percursos derivados. Enquanto esse controlo não existir, não activar substituição/cancelamento.

Verificar dependências da prestação e do rascunho, não só ausência de confirmação no par conhecido: outros rascunhos/documentos derivados, versões de preparação documental e revisões em curso podem impedir aplicação. Não reescrever fotografias, propagar alterações silenciosamente ou limpar pendências fiscais. Herança documental para sucessores, se aplicável, exige captura explícita e referência à versão escolhida; não copiar valores privados para auditoria técnica ou prova.

Distribuição **proposta, por confirmar**: Osmane prepara pedidos e aplica os aprovados; Samira consulta, aprova/recusa a versão exacta, sem editar ou aplicar o pedido por consequência da revisão. Auto-aprovação recusada mesmo com ambos os poderes. Revalidar identidade, contexto, pertenças, acesso às origens/destinos e acção no servidor em cada pedido e dentro da transacção.

Propor direitos de unidade próprios de consulta, pedido, revisão e aplicação de correcção/cancelamento. Não derivar de `workshop_billing.prepare/review/generate`, de custos ou do nome da conta. Nomes técnicos, contas e concessões exactas serão apresentados após confirmar o desenho, separadamente de qualquer migração ou instalação. Nenhuma concessão decorre deste documento.

## 5. Exemplo sintético proposto — não aprovado

Reutilizar referências verificadas do exemplo de 105 MIN e 2 UN, sem nova captura. Original: trabalho 1,75 H × 200 = 350; material 2 × 75 = 150; soma comercial 500 MZN sem imposto.

Proposta de correcção de preço para futura prova: trabalho mantém 200 MZN/H; material passa a **80 MZN/UN**, com fonte sintética sucessora explícita `WORKSHOP-SALES-SYNTHETIC-v2`. Novo material 160, soma 510; diferença comercial +10. Não é desvio de custo, margem, total fiscal ou quantia exigível. Original 500 continua intacto no histórico; sucessor 510 só fica actual após revisão/aplicação exactas.

Preço desconhecido impede aplicar; zero explícito exige revisão e não significa desconhecido. Aritmética exacta, respeitando contrato 16/8 das entradas e recusando representações incompatíveis sem arredondamento. Fiscalidade, moeda funcional e regras contabilísticas continuam pendentes; nenhuma aprovação comercial as resolve.

Cancelamento é cenário separado: seleccionar o destino actual elegível e aplicar decisão distinta; preservar 500/510 como história, não substituir montantes por zero. Não executar cenários sucessivos presumindo que cancelamento reabre a origem.

## 6. Provas e critérios para futura implementação

- Original 500 preservado, proposta/revisão distintas, sucessor 510 rastreável e único destino actual, sem novo consumo ou utilização duplicada.
- Recusa, desistência e proposta sucessora mantêm história; aprovação de versão anterior não se transfere. Cliente/moeda/quantidade/origem fora do recorte recusados.
- Cancelamento preserva origem/destino e bloqueia cobrança/reabertura automáticas; repetição não duplica estado ou liberta recursos.
- Destino confirmado B1, com documento derivado, já substituído/cancelado, dependência nova ou fonte técnica obsoleta não pode ser alterado/aplicado. Fotografias e decisões anteriores intocadas.
- Percursos alternativos de A/B1 não contornam o estado; não se retira `ServiceInvoicing::guard()` ou outra guarda para demonstrar o circuito.
- Contexto cruzado e permissão revogada recusados no pedido seguinte, incluindo replay; revisora não ganha verificação técnica, preparação ou aplicação implícitas.
- Idempotência por contexto/actor/acção/conteúdo, conflito de chave, recuperação após resposta perdida, rollback completo de destino/estado/auditoria/outbox e duas transacções sobrepostas: correcção versus correcção, correcção versus cancelamento, aplicação versus confirmação B1/dependência nova.
- Regressões relevantes de A/B1/oficina/conversão, build e prova exclusivamente sintética em `sgf_tempo_test`; sessões/cache isolados, CSRF activo e limitações visuais registadas sem aceitação presumida.

## 7. Decisões novas necessárias

1. Confirmar substituição imutável por novo par de rascunhos, em vez de edição do par já gerado.
2. Confirmar limites iniciais: mesmo cliente/moeda/origens/quantidades; corrigir preço, fonte, descrição e serviço compatível. Alterações técnicas/clientes/volume e repartição parcial ficam de fora.
3. Confirmar cancelamento sem libertação de origens e sem reabertura neste recorte.
4. Confirmar Osmane prepara/aplica e Samira revê por identidade distinta, com direitos próprios.
5. Confirmar ou substituir o exemplo de material 80 MZN/UN e soma 510, exclusivamente sintético, sem imposto.

Depois destas decisões, a implementação ainda requer autorização técnica delimitada. Não existe ordem de migração, concessão, uso real, emissão, stock, recebimento, lançamento, fecho ou publicação nesta etapa.

## 8. Validação das decisões pelo utilizador

Em 28/10/2026, o utilizador respondeu «valido» às cinco opções apresentadas. Ficam confirmadas: substituição imutável por novo par de rascunhos, preservando os originais; mesmo cliente/moeda/origens/quantidades, com correcções comerciais delimitadas na secção 7; cancelamento sem libertação de origens ou reabertura automática; Osmane prepara/aplica e Samira revê por identidade distinta, sem novos direitos reais por consequência; exemplo exclusivamente sintético de material a 80 MZN/UN, mantendo trabalho a 200 MZN/H, soma 510 MZN sem imposto versus original 500.

As referências anteriores a estas decisões por confirmar passam a históricas. Esta validação aprova o desenho e os pressupostos do ensaio, não uma proposta ou decisão no sistema. Permanecem separadas a autorização técnica de implementação, qualquer migração/concessão em desenvolvimento, demonstração, aceitação da futura entrega e checkpoint. Preservar `3932b94`, `30029b9`, `d071bc0`, anteriores e todas as alterações posteriores. Sem alteração de código ou retirada de bloqueios nesta etapa.