# Percurso orçamental sintético no SGF

29/10/2026. `SGF-BUDGET-WORKSPACE-SIM-v1`. Implementação autorizada do passo seguinte à [aceitação técnica do núcleo comum](COMMON_BUDGET_ACCEPTANCE.md). **Disponível para teste da equipa, sem aceitação ou checkpoint de encerramento presumidos.**

## Disponibilidade e preservação

Entrada local: **http://127.0.0.1:8003**. É o SGF existente: mesmo bootstrap, entrada por sessão, selecção de empresa/unidade, navegação e componentes React. Depois de seleccionar o contexto, abrir **Compras → Controlo orçamental sintético** ou o atalho da página inicial.

A instalação de demonstração tem base PostgreSQL própria `budget_core_sgf_<12 hex>`, uma conta técnica exclusiva sem superuser/CREATEDB/CREATEROLE, chave da aplicação, cookie, sessões e cache separados. Não usa `sgf_tempo_dev`, `sgf_tempo_test` ou `compras_dev`. A demonstração anterior em 8002 conserva contas/dados e não foi substituída. Esta composição demonstra o percurso orçamental no SGF; não reúne automaticamente todos os dados/módulos da demonstração anterior.

O estado inicial mantém quatro contas, centros e origens sintéticos, **sem dotações, decisões ou movimentos pré-preenchidos**. A prova HTTP usa outra base/role descartável em 8004; não consome o cenário que a equipa vai experimentar. A [conferência da disponibilidade](proofs/budget-demo-availability.json) registou quatro utilizadores e zero dotações/movimentos/consumos/comandos antes da revisão da equipa.

```powershell
powershell -NoProfile -ExecutionPolicy Bypass -File scripts/budget-demo.ps1 status
powershell -NoProfile -ExecutionPolicy Bypass -File scripts/budget-demo.ps1 start
powershell -NoProfile -ExecutionPolicy Bypass -File scripts/budget-demo.ps1 stop
```

`start` recusa porta ocupada; o provisionamento repetido preserva a base, pessoas sintéticas, passwords e histórico. `stop` só termina o servidor próprio identificado e conserva os dados. Não há reset automático. Não executar testes destrutivos apontados para a base persistente da equipa. O servidor está limitado a loopback; não foi publicado ou disponibilizado remotamente.

## Contas por função

| Função | Conta sintética | Acções |
| --- | --- | --- |
| Preparação | `preparacao-orcamento@example.test` | Consultar, preparar dotação, propor reforço |
| Validação | `validacao-orcamento@example.test` | Consultar, aprovar dotação, aprovar/recusar reforço |
| Operação | `operacao-orcamento@example.test` | Consultar, reserva/adjudicação/compromisso/libertação e consumo simulado |
| Consulta | `consulta-orcamento@example.test` | Ler saldos, referências, movimentos e histórico; sem escrita |

As passwords aleatórias de cada conta estão exclusivamente no ficheiro local protegido `C:\laragon\data\sgf-tempo\secrets\budget-demo-access.json`, campo `accounts`. Consultá-lo localmente; não copiar passwords para chat, relatórios, capturas ou Git. As configurações de ligação/chave estão noutro ficheiro privado, `budget-demo.json`. Os ficheiros têm ACL do utilizador local/SYSTEM. Não foi alterada conta ou concessão real nem atribuída função a pessoas reais.

Empresa: **Empresa Horizonte — Orçamento sintético**. Unidade: **Unidade Central — Orçamento sintético**. Centro do guião: **ORC-DEMO**. A unidade reservada e a empresa sem membership não são autorizadas. Tenant, empresa, unidade e centro continuam identificadores distintos, sem equiparação automática.

## Guião funcional da equipa

Usar entradas decimais com ponto. Para o exemplo sem imposto desta prova, indicar total e subtotal iguais; isto não configura uma taxa fiscal. Os valores e saldos abaixo são MZN.

1. **Preparação:** entrar, seleccionar empresa/unidade e abrir Compras. Criar dotação de **1000.00** em ORC-DEMO, exercício actual, corrente, base com imposto indicado e fundamento sintético. O estado fica pendente e o total aprovado/disponível é zero, sem autorização presumida.
2. **Validação:** sair/entrar com a conta de validação, seleccionar o contexto e aprovar. Conferir dotação aprovada **1000.00**, actor e data. A preparação não pode aprovar a sua proposta.
3. **Operação:** seleccionar a dotação e a origem **SIM-COMPRA-001**. Reservar **300.00** (total e subtotal): reservado 300, disponível 700. Registar ajuste de adjudicação para **350.00**: reservado 350, disponível 650. Registar compromisso **350.00**: reserva zero, compromisso 350 e disponível 650.
4. **Operação:** em consumo simulado, usar a mesma origem, referência **SIM-CONSUMO-001** e total/subtotal **100.00**. Conferir compromisso 250, consumo 100 e disponível 650. Repetir a mesma referência/valores: não surge segundo consumo. Não é criada factura, obrigação, pagamento ou lançamento.
5. **Preparação:** propor reforço **200.00**, referência **SIM-REFORCO-001** e fundamento. Disponível continua 650 enquanto pendente. **Validação:** aprovar distintamente. Conferir total aprovado 1200 e disponível **850.00**, com dotação inicial 1000 preservada.
6. **Operação:** na origem separada **SIM-COMPRA-LIBERTAR**, reservar 200 e libertar antes de compromisso. Disponível volta a 850. Repetição não duplica a libertação; compromisso posterior à libertação é recusado. Uma origem já comprometida não recebe nova libertação por este circuito.
7. **Consulta:** conferir cartões de saldo, tabela dos deltas, origem, dotação, actor, data, referência do consumo e histórico expansível. Esta conta não mostra formulários de escrita; pedidos directos sem direito também são recusados.

A dotação seleccionada determina os centros/origens apresentados nos formulários; campos de operação só aparecem para dotação aprovada do exercício actual e com origem no mesmo centro. Se o cenário já estiver usado, conservar o histórico: não se reabre ou apaga uma origem para repetir a demonstração. A equipa pode rever/repetir os comandos idempotentes; cenários adicionais devem ser acrescentados explicitamente em QA, sem reset do trabalho anterior.

As alterações de contexto limpam os formulários e não aplicam respostas tardias de outro contexto aos dados apresentados. Em erro de rede, repetir o mesmo conteúdo recupera a mesma chave de comando do formulário; o servidor mantém chaves por actor/contexto/acção e recusa conteúdo divergente.

## Implementação e fronteira do núcleo

- `resources/js/PurchasingBudgetWorkspace.jsx`: interface; recebe saldos do servidor, formata centavos com BigInt e não calcula disponibilidade/impostos. Preparação, operação, validação e consulta filtradas por direitos.
- `resources/js/app.jsx`, `WorkspaceNavigation.jsx`, `WorkspaceHome.jsx`: montagem incremental nos componentes existentes e atalhos por função/unidade.
- `app/Modules/Purchasing/BudgetController.php`: GET e POST do percurso, sob sessão, `auth_version`, CSRF e token de contexto existentes.
- `BudgetWorkspace.php`: valida/normaliza entradas monetárias exactas, referências, sequência do cenário e comandos idempotentes; apresenta movimentos e auditoria. Não calcula deltas ou saldos financeiros.
- `BudgetAdapter.php` e `packages/budget-control`: reutilizados **sem alteração**. O hash do núcleo coincide com as provas da extracção aceite em `f77900e`. Reserva/compromisso/consumo/reforço/libertação continuam com um único motor financeiro.
- Novas tabelas exclusivamente QA: `cb_ui_commands` (recuperação/idempotência de pedidos) e `cb_consumption_sources` (referências de consumo simulado). A coluna histórica `invoice_id` do núcleo aponta, neste ensaio, para a referência sintética; não representa factura emitida ou contas a pagar implementadas.
- `scripts/budget-demo-*`: provisionamento, servidor, acesso e estado. O provisionador usa a ferramenta PostgreSQL local já disponível em Compras para criar base/role **novas**, através da base de manutenção `postgres`; a aplicação SGF usa depois apenas a sua role QA restrita. Não existe dependência de um SGF remoto nem comunicação entre aplicações para executar os movimentos.

## Provas técnicas e limites da revisão visual

Prova reproduzível:

```powershell
powershell -NoProfile -ExecutionPolicy Bypass -File scripts/budget-workspace-proof.ps1
```

[Prova HTTP](proofs/budget-workspace-http.json): quatro sessões reais, login/logout, contexto e funções; dotação/aprovação, sequência 300→350→compromisso→consumo100→reforço200, valores exactos 650/850 disponíveis; referência/consumo únicos; insuficiência de saldo; precisão não representável recusada sem arredondar; falha por consumo excessivo com rollback da referência e recuperação; replay igual e conflito de conteúdo; libertação única sem reabertura; proibição de escrita por consulta; origem de outro âmbito, unidade reservada e contexto antigo recusados; CSRF activo. Base/role da prova removidas no final e sem alterações ao cenário da equipa.

`scripts/budget-workspace-render-check.mjs`: formatação exacta dos valores, deltas negativos, maior valor suportado, desconhecido como indisponível e navegação por unidade. O teste de início/menu existente também passou. Build SGF e sintaxe PHP/PowerShell passaram. Não se instalaram nem actualizaram dependências. A regressão destrutiva SGF não foi apontada para `sgf_tempo_test`; preservou-se a demonstração existente. As provas aceites de concorrência do núcleo mantêm-se; não se atribui concorrência de browsers a esta bateria HTTP sequencial.

**A interface existe agora e está disponível para a equipa.** A validação foi técnica por HTTP, verificação de componentes/formatação e compilação; **não foi realizada nova revisão visual no navegador nem se presume aceitação da equipa**. O bloqueio anterior da automação não foi usado como dependência para implementar ou disponibilizar este percurso. A revisão visual de Compras e os dois testes MFA ignorados continuam pendências da entrega anterior; este incremento não os encerra.

## Limites de implantação e continuação

Sem migração em bases existentes, sem concessões reais, sem utilização real habilitada, sem novo motor e sem alterações ao orçamento industrial. O adaptador continua bloqueado fora do ambiente/base QA. O schema é preparado por scripts sintéticos, não por migrações registadas para aplicar em desenvolvimento/produção. Migração operacional, regras fiscais/contabilísticas e instalação completa de Compras permanecem fora desta entrega.

Próximo passo: a equipa percorre o guião e regista função, referência sintética, passos e resultado observado/esperado. Corrigir dificuldades concretas preservando origens e histórico; decidir aceitação separadamente. Não houve novo commit/checkpoint de encerramento, push ou publicação.