compras/docs/proposta-desenvolvimento-sgf.md

# Proposta única — percurso completo no desenvolvimento isolado

02/11/2026. **Proposta para confirmação; nenhuma alteração de acesso executada.** Substitui como próximo passo a instalação técnica desactivada no SGF real. O objectivo é disponibilizar e deixar utilizável o percurso requisição → submissão → aprovação independente → consulta na instância sintética existente, sem criar outra instalação.

## Destino existente, confirmado por leitura

| Elemento | Valor |
| --- | --- |
| Pasta reutilizada | `C:\laragon\data\sgf-tempo\run\modular-regression-2576427d1939\development-app` |
| URL | `http://127.0.0.1:8039` |
| Cluster exclusivo | `sgf_modular_regression_2576427d1939`, loopback `127.0.0.1:55439` |
| Base persistente | `sgf_modules_dev_2576427d1939` |
| Ligação existente/proprietário da base | `sgf_modules_qa_2576427d1939` |
| Tenant sintético existente | `Cliente de demonstração` |
| Empresa sintética existente | `Empresa Horizonte — Demonstração` |
| Unidade sintética escolhida | `Unidade Central — Demonstração` |
| Contas existentes a reutilizar | Desenvolvimento — Preparador; Desenvolvimento — Revisor; Desenvolvimento — Consulta |

A leitura PostgreSQL em transacção READ ONLY confirmou base, role/proprietário, nomes sintéticos e ausência de tabelas `cb_*`, `ir_*`, `sgc_installations`. A documentação da navegação modular confirma a origem sintética das contas. Resolver os IDs exactos pelo registo privado de provisionamento e conferir tenant/empresa/unidade; não usar igualdade de nome para fundir entidades. Outras empresas/unidades e respectivos dados permanecem preservados e fora do âmbito da integração proposta. Não recriar a base de regressão nem reaplicar o provisionador destrutivo.

## Configuração sintética proposta — ainda não aplicada

Estes valores são deliberadamente **dados de demonstração**, sujeitos à confirmação desta proposta; não representam centros, dotações, pessoas, impostos ou políticas da Tempo.

| Parâmetro | Proposta concreta |
| --- | --- |
| Área/opção | Compras / Compras internas (`procurement.internal`) |
| Módulo | `purchasing`, activado exclusivamente no âmbito sintético acima |
| Centro | Código `SINTETICO-REPRO`, departamento/referência `OPER` |
| Dotação | Exercício **2026**, natureza operacional (`operating`), **10.000,00 MZN sintéticos**, inclui impostos; preparação e aprovação por identidades distintas |
| Política | Activa; orçamento obrigatório; cálculo de limites com impostos; primeiro limite 1.000.000 unidades mínimas (10.000,00), segundo 2.000.000 (20.000,00); centro e preparador/revisor vinculados a `OPER` |
| Recorte executável | Consumíveis, serviços e outros; equipamentos/peças rejeitados; sem contratação para terceiros |
| Exemplo manual | Requisição sintética de 100,00, sem imposto, inferior ao primeiro limite; não declara taxa fiscal aplicável à empresa |

Os valores retomam a configuração já exercitada na prova isolada. A dotação limita os pedidos deste exemplo ao primeiro nível; não se promete exercitar os níveis de compras/finanças sem identidades/direitos adicionais. A submissão reserva orçamento pelo motor existente, e as repetições não criam outra requisição/reserva. Nenhum valor é importado do SGF real. Criar centro/dotação pela interface/API existente, com autoria, motivo e chaves de idempotência.

## Identidades e acessos funcionais a confirmar

Reutilizar as três contas sintéticas existentes, suas credenciais privadas e permissões anteriores; acrescentar apenas os direitos abaixo no âmbito exacto escolhido, com auditoria. Não criar contas, publicar palavras-passe ou atribuir estes perfis a pessoas reais.

| Identidade existente | Responsabilidade proposta | Direitos adicionais da candidata |
| --- | --- | --- |
| Desenvolvimento — Preparador | Administrar/configurar este exemplo, criar centro, preparar dotação/requisição e submeter | `purchasing_requisitions.view`, `.prepare`, `.configure`, `.approve.department_head`; `purchasing_budget.view`, `.create`, `.approve`, `.record` |
| Desenvolvimento — Revisor | Aprovar a dotação e a requisição preparadas pela outra identidade; consultar | `purchasing_requisitions.view`, `.approve.department_head`; `purchasing_budget.view`, `.approve` |
| Desenvolvimento — Consulta | Consultar requisição e orçamento; sem escrita/aprovação/administração | `purchasing_requisitions.view`; `purchasing_budget.view` |

Os sufixos da tabela pertencem ao prefixo da mesma célula. O Preparador conserva a administração sintética existente (`access.manage` na empresa). Os direitos de aprovação na conta administradora permitem a delegação nativa de direitos que detém; **não permitem aprovar a sua própria requisição ou dotação**. O Revisor não recebe preparação ou administração. A Consulta não recebe mutações. Manter os direitos nativos já existentes de consulta da empresa/unidade e pertenças; não ampliar o seu âmbito. A configuração inicial usa o mecanismo explícito e auditado da candidata; posteriores outorgas/revogações usam o catálogo nativo.

**Não é exigido um segundo administrador para esta demonstração isolada.** A orientação existente do proprietário, secção «Administração e entrega» do AGENTS.md, diz: «A configuração inicial/entrega exige dois administradores nominativos da empresa» e «Manter pelo menos dois administradores permanentes». Trata-se de requisito para a configuração/entrega empresarial; esta proposta não é essa entrega, não altera a administração real nem cria uma nova exigência para a demonstração. Preparador e Revisor continuam obrigatoriamente identidades diferentes para aprovar.

## SQL: direitos existentes e alterações propostas

**Nenhum novo GRANT, REVOKE, CREATE ROLE, ALTER ROLE ou transferência de ownership é proposto para este ambiente.** A role existente `sgf_modules_qa_2576427d1939` já é proprietária da base isolada e foi criada para esse desenvolvimento. Reutilizá-la para migração e execução evita alterar acessos ou criar outra instalação/role por arrasto. Isso mantém uma limitação explícita: este ambiente persistente não demonstra separação owner/runtime com privilégio mínimo; essa separação já foi ensaiada nas bases descartáveis da prova corrigida, não é atribuída retroactivamente a esta instância.

Não executar o plano `sgf-corrected-sql-plan.json`: ele é dirigido a `sgf_dev_app` da implantação real e **não pertence a esta proposta**. Não criar ou conceder acesso dessa role ao cluster 55439. As escritas funcionais em `permission_grants` da base sintética, discriminadas acima, também aguardam confirmação. A migração autorizada futura cria 16 tabelas e altera o catálogo de `permission_grants` somente nesta base sintética; DDL não equivale a conceder direitos. Caso a conferência mostre que a role existente não tem a autoridade necessária, parar e apresentar os comandos SQL exactos em falta para nova confirmação, sem os executar e sem promover a role.

## Candidata, execução e recuperação propostas

Reutilizar o ZIP existente `OPERATIONAL-CANDIDATE-401ce31ae5f2dd20`, SHA-256 `59dbdc64c4d9f14dfb4025a6177b829d136a4e2cb633ca036b10b5ae3197e703`, manifesto `a6478223e17a5430652f0fcbf31a44a931ae2a99cd90b151c98d2df5df43c10b`. Os planos/fingerprints do destino real **não se aplicam** a esta instância. Gerar os seus planos próprios; a normalização física de guardas para 55439 já documentada deve ser respeitada. Se os overlays exactos do ZIP recusarem diferenças dessa cópia, preparar variante de compatibilidade identificada e apresentar novo hash antes de aplicação; não desligar guardas nem assumir compatibilidade byte a byte.

Após confirmação da proposta completa: guardar backup privado desta base/configuração/código sintéticos; ensaiar recuperação sem sobrescrever a base; preparar schema e código com planos próprios, habilitar a composição só no âmbito acima, atribuir os direitos explicitados, preparar/aprovar a dotação, e deixar a instância acessível em 8039. Conferir o percurso por HTTP e reutilizar as provas aceites de concorrência/recuperação; não repetir navegador bloqueado ou suites integrais por rotina. Guardar configurações/credenciais privadas fora de Git/raiz web e fornecer o local existente de acesso, sem imprimir segredos.

Em falha, manter esta instância fechada, preservar journal e restaurar código ou recuperar dados/schema em base alternativa, conforme a natureza da falha; não recriar os perfis nem resetar a demonstração. Código e dados têm recuperação separada. O cluster/base 55432 e a configuração real da Tempo não participam em nenhuma dessas operações.

**Confirmação pendente:** reutilização desta instância, habilitação da candidata e configuração/acessos sintéticos acima. Não foi executada nenhuma alteração nesta proposta. Implantação real permanece etapa posterior separada; `sgf_tempo_dev` e o seu pacote **0.1.1** são preservados.