SGF/AGENTS.md

# SGF Tempo — instruções locais

- Continuação «prossiga», 29/10/2026, projecto Compras: desenvolvimento sintético de `PAYABLE-IMPORTED-DECISION-v1`, confirmação/rejeição de pagamentos originalmente pendentes após importação. Reutilizar conferência original e núcleo comum, transacção única, fotografia importada imutável, decisão append-only e abatimento único. Ver `C:/laragon/www/compras/docs/conferencia-pendentes-importados.md`. Substitui a exclusão de desenvolver esta conferência apenas neste incremento; preservar configurações/dados/demos existentes. Migração 000023 e activação não aplicadas por consequência do desenvolvimento. Sem novos pagamentos, transferências, contabilidade ou publicação; SGF continua sem adaptador histórico.

- Aplicação local posterior autorizada por «continue», 29/10/2026: 000022 aplicada em `compras_dev`, lote 23, e importação histórica activada, após backup/restauro de 72 tabelas e preservação verificada. Duas tabelas novas vazias, dois triggers, activação auditada sem contas/concessões novas ou incorporação automática. Ver `C:/laragon/www/compras/docs/passagem-historico-pagamentos.md`. Demos (incluindo 8005) e público preservados; SGF continua sem fornecedor histórico configurado. Este registo substitui apenas a pendência de aplicação local abaixo; não autoriza novos pagamentos/confirmação de pendentes ou publicação.

- Continuação autorizada no projecto Compras em 29/10/2026: `PAYABLE-HISTORY-IMPORT-v1`, passagem explícita de histórico original para o núcleo comum, com principal integral, dedução única de confirmados e pendentes/rejeitados preservados sem abatimento. Preparação/validação distintas, unicidade, idempotência, auditoria e append-only. Ver `C:/laragon/www/compras/docs/passagem-historico-pagamentos.md`. Provas em bases separadas; 000022 e activação histórica não aplicadas por consequência do desenvolvimento. Preservar demos, contas/dados reais e menus. Não executar novos pagamentos, confirmar pendentes, reconciliar, alterar stock/orçamento ou contabilizar por arrasto. O adaptador SGF anterior permanece sem fornecedor de histórico; não declarar ligação histórica SGF entregue. Substitui apenas a exclusão absoluta anterior de desenvolver uma passagem de pagamentos, mantendo a recusa no percurso antigo e enquanto a nova capacidade estiver desactivada.

- Implementação autorizada em 29/10/2026: `COMMON-PAYABLE-SOURCE-SIM-v1`, cenário aprovado 10 000+1 600=11 600 MZN, fonte única `packages/payables`, factura efectivamente conferida por Compras, preparação/validação distintas e consulta nas duas composições QA. Principal reconhecido com vencimento/dias nulos e atraso indeterminado. Ver `docs/SUPPLIER_PAYABLE_DELIVERY.md`. Pagamentos anteriores impedem incorporação integral; preservar originais/histórico e passagem de responsabilidade sem segundo saldo. Bases/roles próprias, sem alterar demos em 8002/8003 ou dados/acessos reais. Sem pagamentos/cobranças/afectações/stock/orçamento adicional/contabilidade, dependências novas, push/publicação, aceitação ou checkpoint presumidos.

- Orientação comum de produto da Tempo, 29/10/2026: oito regras de documento/dívida/liquidação, condições explícitas, afectações parciais, confirmação/reconciliação, idempotência, correcções, cobrança configurada e responsabilidade financeira única registadas em `docs/SUPPLIER_PAYABLE_SCOPE.md`, secção 14. São separadas da fiscalidade específica e não declaram capacidades futuras entregues. O recorte actual permanece só obrigação a fornecedor; sem pagamentos/cobranças/lançamentos por arrasto. Vencimento desconhecido é pendência documental visível, não data inventada, dívida apagada ou pré-condição universal de reconhecimento criada por escolha técnica. Preservar a avaliação orçamental em paralelo.

- Orientação de 29/10/2026 para a ligação seguinte: conferir/delimitar `COMMON-PAYABLE-SOURCE-SIM-v1`, factura de fornecedor conferida → obrigação a pagar única, MZN, vencimento/origem/revisão/histórico, sem redigitar dados válidos. Ver `docs/SUPPLIER_PAYABLE_SCOPE.md`. Preservar o saldo implícito já calculado por Compras: a nova capacidade não pode criar autoridade concorrente para a mesma dívida. Documento incompatível/incompleto fica pendente; correcções preservam original. Nesta passagem apenas leitura/desenho, sem implementação, pagamento, stock, lançamento, migração/concessão real ou novo checkpoint. Orçamento aceite e avaliação da equipa em paralelo, sem resets.

- Incremento autorizado em 29/10/2026: `SGF-BUDGET-WORKSPACE-SIM-v1`, interface orçamental SGF sobre o núcleo comum aceite, com quatro funções sintéticas e rastreabilidade. Ver `docs/SGF_BUDGET_WORKSPACE_DELIVERY.md`. Demonstração persistente isolada em loopback 8003 e base `budget_core_sgf_<12 hex>`/role QA própria restrita; provas descartáveis separadas em 8004. Preservar a demonstração anterior em 8002/`sgf_tempo_test`, dados/contas reais e orçamento industrial. Sem nova cópia do motor, migração/concessão real, uso real, obrigações/pagamentos/contabilidade ou aceitação/checkpoint presumidos. A interface está implementada; revisão visual da equipa permanece separada das provas HTTP/build.

- Aceitação expressa de 29/10/2026: `COMMON-BUDGET-SYNTHETIC-v1` aceite como extracção técnica do núcleo comum e checkpoint exclusivamente local autorizado nos dois repositórios. Ver `docs/COMMON_BUDGET_ACCEPTANCE.md`. Preservar revisão visual de Compras pendente, SGF apenas pelo adaptador QA sem interface deste percurso e cobertura dos dois testes MFA pendente. Automação do navegador não bloqueia desenvolvimento. Próximo passo: percurso sintético integrado no SGF para a equipa, reutilizando o núcleo. Sem utilização real, migração/concessão real, push/publicação ou avanço para obrigações/pagamentos/contabilidade por arrasto.

- Autorização técnica de 29/10/2026: implementar `COMMON-BUDGET-SYNTHETIC-v1`, fonte única em `packages/budget-control`, adaptadores Compras/SGF e provas nos dois hosts isolados. Ver `docs/COMMON_BUDGET_DELIVERY.md`. Nenhuma actualização de dependências, migração/concessão/dado real, publicação, push ou checkpoint de encerramento. SGF mantém guarda QA do adaptador; `sgf_tempo_test` e demonstração da equipa preservados. Não avançar para obrigações/pagamentos/contabilidade. Verificação técnica não constitui revisão visual ou aceitação.

## Decisão expressa da Tempo — 29/10/2026: Compras e núcleo financeiro comum

Um módulo de Compras, um núcleo financeiro comum e duas composições comerciais: ERP SGF com Compras e Compras autónomo com as capacidades comuns necessárias, sem exigir facturação de vendas SGF ou SGF remoto. Substitui a proposta principal de duas aplicações ligadas por conector remoto. Preservar os percursos de `C:/laragon/www/compras`; extrair/adaptar o existente, sem segundo motor financeiro. Cada efeito tem um único serviço responsável. Ver `docs/PURCHASING_COMMON_CORE_PLAN.md`: percursos preservados, capacidades existentes/em falta, transição e primeiro incremento `COMMON-BUDGET-SYNTHETIC-v1`. Nesta passagem autoriza-se o registo/desenho; a reestruturação segue o incremento delimitado, sem alterações reais por arrasto. Manter instruções anteriores, dados, acessos e demonstração; desenvolvimento/provas com identidades e bases sintéticas isoladas.

## Decisão expressa da Tempo — 29/10/2026: produto, demonstração e implantação

Esta decisão prevalece sobre dependências anteriores de pessoas reais e aprovações de cada incremento técnico. Desenvolvimento e testes usam empresas, unidades, utilizadores e operações sintéticas, com permissões explícitas, isolamento e separação entre preparador, técnico, verificador e validador. Osmane, Samira e concessões na Tempo não são pré-condições para construir ou testar o produto. Referências anteriores a essas pessoas descrevem a implantação/configuração histórica da Tempo, não papéis fixos do SGF.

A próxima entrega é uma demonstração integrada estável para a equipa experimentar percursos completos com exemplos e propor correcções. Agrupar revisões em entregas funcionais; não pedir aprovação de cada pequeno passo técnico. Desenvolver módulos e ligações em falta no contexto sintético. As aceitações anteriores mantêm o seu âmbito; esta autorização não equivale à aceitação de funcionalidades ainda não demonstradas.

Pessoas reais, concessões efectivas, dados empresariais e configurações fiscais/contabilísticas aplicáveis pertencem à implantação no cliente. Preservar tudo o que já foi configurado na Tempo, sem novas concessões reais por consequência da demonstração. Conformidade de emissão fiscal é necessária antes do uso real e não bloqueia o restante desenvolvimento. Preservar originais, histórico, checkpoints, permissões e guardas contra utilização real. Ver `docs/PRODUCT_DEMO.md` para inventário, percursos e limitações.

- Autorização técnica de 28/10/2026: implementar `WORKSHOP-BILLING-CORRECTION-SIM-v1` conforme `docs/WORKSHOP_BILLING_CORRECTION_SCOPE.md`, só sintético em `sgf_tempo_test`. Substituição imutável 500→510 MZN sem imposto (material 80/UN, trabalho 200/H), revisão distinta, origens únicas; cancelamento sem libertar origens/reabrir cobrança. Bloquear destinos substituídos/cancelados em A/B1 e manter originais, decisões e fotografias. `130000` e cinco concessões reais apenas propostas, não aplicar sem confirmação específica. Preservar `3932b94`, `30029b9`, `d071bc0`, anteriores e alterações posteriores. Sem uso real, stock, emissão, lançamentos, publicação, aceitação presumida ou checkpoint de encerramento. Ver `docs/WORKSHOP_BILLING_CORRECTION_DELIVERY.md`.

- Decisões validadas em 28/10/2026: correcção/cancelamento de rascunhos de oficina conforme `docs/WORKSHOP_BILLING_CORRECTION_SCOPE.md`, secção 8. Substituição imutável por novo par, originais preservados; mesmo cliente/moeda/origens/quantidades, correcções comerciais delimitadas; cancelamento sem libertar origens ou reabertura; Osmane prepara/aplica e Samira revê distintamente. Ensaio sintético: material 80 MZN/UN e trabalho 200 MZN/H, soma 510 sem imposto versus original 500. Apenas desenho validado; implementação, migrações/concessões, prova e aceitação futuras separadas. Preservar checkpoints e bloqueios, sem uso real/publicação.

- Autorização específica posterior de 28/10/2026 executada: apenas `110000` aplicada em `sgf_tempo_dev`, por caminho exclusivo com `sgf_dev_owner`, e sete concessões auditadas no tenant #1 / Tempo Lda #1 / SEGI #1: conta #1 `industrial_budgets.view/prepare`, `industrial_budget_comparisons.view/prepare`; conta #2 `industrial_budgets.view/validate`, `industrial_budget_comparisons.view`. Ver actualização de `docs/INDUSTRIAL_BUDGET_DELIVERY.md`. Preservadas 81 tabelas anteriores, acessos e instalação `120000`; seis tabelas novas vazias. Aplicação mantém `sgf_dev_app`; orçamento/conversão/oficinas/custos/recebimentos/emissão reais bloqueados, guardas SQL verificadas. Indicações anteriores de `110000`/sete concessões por aplicar são históricas. Sem utilização real ou publicação.

- Autorização específica posterior de 28/10/2026 executada: apenas `120000` aplicada em `sgf_tempo_dev`, por caminho exclusivo com `sgf_dev_owner`, e seis concessões auditadas no tenant #1 / Tempo Lda #1 / SEGI #1: conta #1 `workshop_billing.view/prepare/generate`; conta #2 `workshop_billing.view/review` e `workshop.view`. Ver actualização de `docs/WORKSHOP_BILLING_DELIVERY.md`. Preservadas 74 tabelas anteriores e acessos; sete tabelas novas vazias. Aplicação mantém `sgf_dev_app`; conversão/oficinas/custos/recebimentos/emissão reais bloqueados e guardas SQL verificadas. `110000` e sete concessões do orçamento permanecem pendentes; não aplicar por arrasto. Consulta de oficina da conta #2 não concede apontamento/verificação/supervisão. Indicações anteriores de `120000`/seis concessões por aplicar são históricas; sem utilização real ou publicação.

- Aceitação específica de 28/10/2026: utilizador aceitou `WORKSHOP-BILLING-DRAFT-SIM-v1` com limitação de capturas e autorizou checkpoint exclusivamente local, sem credenciais/dados privados. Ver `docs/WORKSHOP_BILLING_ACCEPTANCE.md`. Não transformar provas pendentes em realizadas; Edge não recuperado e capturas não recebidas permanecem limites. Substitui apenas a pendência de aceitação/encerramento deste ensaio. `120000`, seis concessões e utilização real continuam por autorizar; `110000` e sete concessões também pendentes. Sem aplicação, activação operacional ou publicação.

- Autorização técnica de 28/10/2026: implementar `WORKSHOP-BILLING-DRAFT-SIM-v1` conforme `docs/WORKSHOP_BILLING_DRAFT_SCOPE.md`, exclusivamente sintético em `sgf_tempo_test`. Ver `docs/WORKSHOP_BILLING_DELIVERY.md`. Reutilizar origens verificadas por ID/versão, sem consumo duplicado, preços comerciais sintéticos 200 MZN/H e 75 MZN/UN (350+150=500 sem imposto), revisão comercial distinta. Não derivar preço do custo interno ou atribuir verificação técnica à revisora. Sem edição directa de rascunhos gerados ou confirmação B1 automática. `120000` e seis concessões reais só propostas, não aplicar sem autorização específica; `110000` e sete concessões continuam pendentes. Preservar `04870f0`, `090b7da` e alterações posteriores; sem utilização real, stock, emissão, lançamentos, publicação ou aceitação presumida.

- Decisões confirmadas em 28/10/2026 para oficina → rascunho: ver secções 8/8.1 de `docs/WORKSHOP_BILLING_DRAFT_SCOPE.md`. Tempo verificado e material consumido da empresa; excluir material do cliente e dupla cobrança tarefa/tempo. Osmane prepara/gera; Samira revê versão comercial por identidade distinta, sem verificação técnica implícita. Uma ordem/rascunho, origens integrais, sem repartição. Tabela apenas sintética `WORKSHOP-SALES-SYNTHETIC-v1`, MZN sem imposto: 200/H × 105/60 H = 350; 75/UN × 2 = 150; soma 500. Sem custo interno convertido em preço. Apenas especificação nesta etapa; implementação, migrações/concessões e utilização real continuam separadas. Preservar `04870f0`, `090b7da` e bloqueios.

- Preservação autorizada em 28/10/2026: registar avaliação técnica da página inicial/menu e criar checkpoint local sem credenciais/dados privados; não presumir revisão visual ou aceitação visual. Encerramento do orçamento permanece em `04870f0` com limitações explícitas. Próximo passo autorizado apenas de especificação: oficina → rascunho de facturação; definir facturabilidade, revisão, preços e duplicações antes de implementar. `110000`, sete concessões e utilização real permanecem por autorizar.

- Autorização posterior de 28/10/2026: implementar página inicial e navegação agrupada após a proposta `docs/HOME_NAVIGATION_PROPOSAL.md`. Ver `docs/HOME_NAVIGATION_DELIVERY.md`. Preservar `04870f0` e anteriores, direitos por contexto e bloqueios. Sem novos acessos, módulos financeiros, contagens/indicadores fictícios ou uso real; fontes agregadas de pendências não implementadas. Prova visual permanece separada, sem presumir aceitação ou checkpoint. `110000` e sete concessões continuam por autorizar.

- Aceitação específica de 28/10/2026: utilizador aceitou o ensaio de orçamento versus realizado com limitação das capturas documentada e autorizou checkpoint exclusivamente local, sem credenciais/dados privados. Ver `docs/INDUSTRIAL_BUDGET_ACCEPTANCE.md`. Não transformar provas pendentes em realizadas; automação Edge bloqueada e capturas não recebidas permanecem limitações. Substitui apenas a pendência de aceitação/encerramento. `110000`, sete concessões e utilização real continuam por autorizar; sem aplicação ou publicação. Próxima prioridade: página inicial e menus agrupados, preservando entregas e direitos existentes.

- Autorização de 28/10/2026: implementar o ensaio de orçamento versus realizado da secção 16 de `docs/INDUSTRIAL_COST_ACCOUNTING_SCOPE.md`, só sintético em `sgf_tempo_test`, preservando `cbdf2b4`, `4a94e8a` e alterações posteriores. Orçamento aprovado como hipótese: 900 material + 600 trabalho + 300 indirectos imputados; comparar versão validada de 1000/500/300, 10 UN, MZN, mesmo produto/lote/período, com desvios +100/−100/0 e total 0; residual 300 separado. Osmane prepara; Samira valida orçamento exacto por identidade distinta e consulta comparação. Direitos próprios, sem herança ou concessões reais. Sem taxa material: 800 conhecidos, comparação incompleta, nunca poupança. Preservar versões/origens e bloqueios SQL/aplicação. Migração `110000` e sete concessões apenas propostas, NÃO aplicar em desenvolvimento. Sem dependências novas, stock, lançamentos, facturação, publicação ou aceitação presumida; checkpoint de encerramento só após aceitação. Ver `docs/INDUSTRIAL_BUDGET_DELIVERY.md` para estado e provas.

- Autorização específica de 28/10/2026 executada: apenas `100000` aplicada em `sgf_tempo_dev`, por caminho explícito com `sgf_dev_owner`, e quatro concessões auditadas no tenant #1 / Tempo Lda #1 / SEGI #1: conta #1 `industrial_costs.view/prepare`; conta #2 `industrial_costs.view/validate`. Ver actualização de `docs/INDUSTRIAL_COST_DELIVERY.md`. Preservadas 66 tabelas anteriores e acessos; oito tabelas industriais vazias. Aplicação mantém `sgf_dev_app`; custeio industrial/directo, oficinas, recebimentos e emissão reais bloqueados, com guardas SQL verificadas. Sem utilização real ou publicação. Indicações anteriores de `100000`/concessões por autorizar são históricas; esta instalação não activa operações reais.

- Aceitação específica de 28/10/2026: o utilizador aceitou `INDUSTRIAL-COST-SIM-v1` e autorizou checkpoint Git exclusivamente local, sem credenciais ou dados reais. Ver `docs/INDUSTRIAL_COST_ACCEPTANCE.md`. Substitui apenas a pendência de aceitação/encerramento técnico do ensaio. Migração `100000`, quatro concessões e utilização real permanecem por autorizar; sem aplicação, activação operacional, publicação ou novo incremento.

- Autorização técnica de 27/10/2026: `INDUSTRIAL-COST-SIM-v1`, secções 15/15.5, só em `sgf_tempo_test`. Ver `docs/INDUSTRIAL_COST_DELIVERY.md`. Um lote/produto sintéticos, material 1000 + trabalho 500 + CIF 300 = 1800, 10 UN / 180 por UN; conjunto 600, capacidade 10 HM, uso 5 HM e residual 300 separado. Sem taxa material, 800 conhecidos, total/unitário indisponíveis. Critério é hipótese sintética, não método real aprovado. Preparação/validação industrial explícitas por identidades distintas; não herdar custo directo, transformar oficina em lote ou duplicar origens. `100000` e quatro concessões reais apenas propostas, NÃO aplicar sem confirmação específica. Preservar checkpoints/alterações/aprovações/bloqueios. Sem aceitação presumida, checkpoint de encerramento, stock, previsto/realizado, margens, lançamentos ou publicação.

- Autorização específica posterior de 27/10/2026 executada: apenas `090000` aplicada em `sgf_tempo_dev`, por caminho explícito e proprietário separado, e quatro concessões auditadas no tenant #1 / Tempo Lda #1 / SEGI #1: Osmane #1 `direct_costs.view/prepare`; Samira #2 `direct_costs.view/validate`. Ver actualização de `docs/WORKSHOP_DIRECT_COST_DELIVERY.md`. Preservadas 60 tabelas anteriores, dados/acessos e instalações `070000`/`080000`; seis tabelas de custo vazias. Aplicação mantém `sgf_dev_app`; custeio, oficinas, recebimentos e emissão reais bloqueados e guardas SQL verificadas. Sem taxas/cálculos reais, novas concessões técnicas ou publicação. As indicações anteriores de `090000`/quatro concessões pendentes são históricas; não activar uso operacional por consequência desta instalação.

- Encerramento por delegação de 27/10/2026: o utilizador autorizou aceitar a entrega isolada de custos directos após conferência técnica do percurso e preservar checkpoint local. Ver `docs/WORKSHOP_DIRECT_COST_ACCEPTANCE.md`. Não se atribui nova verificação pessoal no navegador ao utilizador. `090000` e quatro concessões continuam NÃO aplicados; custeio real, emissão e restantes operações reais bloqueados. Sem CIF/lote industrial ou publicação. Esta autorização substitui apenas a pendência de encerramento técnico deste ensaio.

- Autorização técnica de 27/10/2026: implementar apenas `WORKSHOP-DIRECT-COST-SIM-v1`, secção 14 de `docs/INDUSTRIAL_COST_ACCOUNTING_SCOPE.md`. Ver `docs/WORKSHOP_DIRECT_COST_DELIVERY.md`. Apenas sintético em `sgf_tempo_test`, origens de oficina verificadas por ID/versão, sem duplicar acontecimentos. 275 MZN conhecidos ou 175 incompletos sem taxa material; exactidão racional, nunca custo completo/margem. Preparação e validação de custos/taxas por identidades distintas, sem editar apontamentos. `090000` e quatro concessões reais apenas propostos, NÃO aplicados; confirmação específica antes de aplicação. Não activar custeio real ou publicar; preservar `7628645`, `ea9dcb3`, alterações posteriores, oficinas/recebimentos/fiscalidade e aprovações. Sem presumir aceitação, CIF ou lote industrial.

- Decisões de desenho confirmadas em 27/10/2026: primeiro ensaio de custo directo de uma ordem de oficina, reutilizando apontamentos verificados por ID/versão, sem duplicar origens. 2 UN × 50,00 + 105/60 H × 100,00 = 275,00 MZN de custo directo conhecido, nunca custo completo/margem; sem taxa material, 175,00 conhecidos e total incompleto. Osmane prepara; Samira valida versões de custos/taxas sem alterar apontamentos técnicos. Futuras provas sintéticas com identidades distintas, sem novas concessões reais. Ver secção 14 de `docs/INDUSTRIAL_COST_ACCOUNTING_SCOPE.md`. Apenas decisões registadas, sem ordem de implementação; lote industrial/CIF adiados. Preservar entregas aceites e bloqueios.

- Autorização específica posterior de 27/10/2026 executada: apenas `070000` aplicada em `sgf_tempo_dev`, por caminho explícito com `sgf_dev_owner`, e oito concessões auditadas no tenant #1 / Tempo Lda #1 / SEGI #1: conta #1 `service_receivables.view/prepare/allocate/correction_request`; conta #2 `service_receivables.view/confirm/reconcile/correction_approve`. Ver actualização de `docs/SERVICE_RECEIVABLES_DELIVERY.md`. Preservadas 54 tabelas anteriores, acessos e instalação de oficinas `080000`; seis tabelas novas vazias. Aplicação mantém `sgf_dev_app`; recebimentos, reconciliação, oficinas e emissão reais continuam bloqueados na aplicação/base. Nenhuma operação real ou concessão para técnico/verificador. As indicações anteriores de `070000`/oito concessões pendentes são históricas; esta instalação não activa uso real ou publicação.

- Encerramento de 27/10/2026: entrega isolada `SGF-RECEIVABLES-SIM-v1` aceite pelo utilizador, com registo e checkpoint exclusivamente local. Ver `docs/SERVICE_RECEIVABLES_ACCEPTANCE.md`. Esta aceitação substitui a pendência de aceitação funcional, mas NÃO aplica `070000` nem as oito concessões, não activa utilização real e mantém bloqueios operacionais/fiscais. Oficinas permanece aceite, com `080000` e os quatro direitos de abertura já aplicados tecnicamente; não repetir a sua aprovação. Sem custos industriais ou publicação.

- Autorização específica posterior de 27/10/2026 executada: apenas `080000` aplicada em `sgf_tempo_dev`, por caminho explícito e proprietário `sgf_dev_owner`; quatro concessões auditadas para conta #1, tenant #1 / Tempo Lda #1 / SEGI #1: `workshop.view/open/assign/authorize`. Ver actualização de `docs/WORKSHOP_RESOURCE_DELIVERY.md`. `070000` permanece pendente, sem aceitação de recebimentos implícita. Dados/acessos anteriores preservados; sete tabelas de oficina vazias. Aplicação mantém `sgf_dev_app`; guardas operacionais e de emissão real preservadas e verificadas. Técnico/verificador reais continuam por identificar, sem concessões. Esta instalação não activa utilização operacional; indicações anteriores de `080000`/quatro direitos pendentes são históricas.

- Aceitação específica de 27/10/2026: o utilizador aceitou a entrega isolada `WORKSHOP-RESOURCE-RECORD-v1` e autorizou o registo e checkpoint Git exclusivamente local, sem credenciais/dados reais. Ver `docs/WORKSHOP_RESOURCE_ACCEPTANCE.md`. Esta aceitação não aplica `080000`, não concede direitos, não activa uso operacional e não abrange a aceitação de recebimentos. `070000` permanece separada e pendente. Técnico/verificador reais continuam por identificar. Sem custos industriais, publicação ou novo incremento. Esta aceitação substitui apenas a anterior pendência de aceitação de oficinas.

- Autorização de 27/10/2026: `WORKSHOP-RESOURCE-RECORD-v1`, ordem/autorização/tarefas/tempos/materiais/verificação, exclusivamente sintético em `sgf_tempo_test`. Ver `docs/WORKSHOP_RESOURCE_DELIVERY.md`. Início de trabalho exige autorização; relato de ocorrência passada fora do âmbito é permitido para auditoria, permanentemente sinalizado, sem autorização retroactiva ou verificação automática. Verificador distinto do autor. Migração `080000` e concessões reais NÃO aplicadas; confirmação específica antes de qualquer aplicação. `070000` de recebimentos continua pendente e não deve ser aplicada por arrasto. Técnico/verificador reais não identificados; não criar contas reais ou atribuir supervisão à Samira. Preservar entregas, sem presumir aceitação de recebimentos/oficina. Sem stock/custos/facturação/recebimentos/lançamentos ou publicação; guardas operacionais/fiscais mantidas.

- Autorização de 27/10/2026: implementar `SGF-RECEIVABLES-SIM-v1`, conforme `docs/SERVICE_RECEIVABLES_SCOPE.md`, secção 12, exclusivamente sintético em `sgf_tempo_test`. Ver `docs/SERVICE_RECEIVABLES_DELIVERY.md`. Preservar `4276aca` e alterações posteriores. Migração `2026_10_27_070000` NÃO aplicada em desenvolvimento e oito concessões reais NÃO aplicadas: exigem confirmação específica antes da aplicação. Manter guardas de ambiente/base, original imutável, montantes exactos, identidade distinta na confirmação/aprovação e revisão exacta. Sem recebimentos reais, recibo fiscal, ligação bancária, dinheiro, lançamento, fecho ou publicação. Não retirar bloqueio de emissão/configuração real. Não declarar aceitação automática desta entrega.

- Autorização específica posterior de 27/10/2026 executada: migração `2026_10_26_060000_create_test_invoice_issuance.php` aplicada em `sgf_tempo_dev` e oito concessões exactamente propostas aplicadas/auditadas (conta #1: série view/propose na empresa #1, documento view/issue/correction_request só unidade #1; conta #2: série view/approve na empresa #1, documento view só unidade #1). Ver secção de aplicação em `docs/SERVICE_INVOICE_TEST_DELIVERY.md` e provas `invoice-dev-preservation*.json`. Preservadas 31 tabelas preexistentes e acessos anteriores; oito tabelas novas vazias. Nenhuma série real ou documento criado. `ServiceInvoicing::guard()` permanece inalterado e as entradas de emissão/configuração real recusam com 403 mesmo com concessões. A autorização não retira o bloqueio, não resolve conformidade e não autoriza emissão, recebimentos, lançamentos ou publicação. As indicações anteriores de migração/concessões pendentes são históricas.

- Em 27/10/2026, o utilizador confirmou **«Aceitar a entrega técnica e criar checkpoint local»** para navegador + PDF, após verificar a demonstração. Entrega técnica encerrada no âmbito de `docs/SERVICE_INVOICE_TEST_DELIVERY.md`, exclusivamente de teste. Registar/preservar checkpoint local sem credenciais/dados reais; não repetir validações aceites sem alteração/falha relevante. Esta aceitação não aplica a migração `060000`, oito concessões ou série real, não resolve conformidade/exigibilidade/apuramento e não autoriza retirar o bloqueio de emissão real, emitir, receber, contabilizar ou publicar.

- Autorização posterior de 26/10/2026: incremento técnico de emissão/reprodução no navegador e PDF, **exclusivamente demonstrável em sgf_tempo_test**, com bloqueio incondicional de emissão real. Ver `docs/SERVICE_INVOICE_TEST_DELIVERY.md` e `docs/SERVICE_INVOICE_ISSUANCE_SCOPE.md`. Série real será nova; proponente prepara/emite e pede correcções, validador fiscal aprova séries e regra temporal. Migração `2026_10_26_060000_create_test_invoice_issuance.php`, código/número inicial reais e oito concessões propostas permanecem sem aplicação e exigem confirmação específica. Não retirar `ServiceInvoicing::guard`, não criar documentos fictícios em desenvolvimento, não confundir pressupostos temporais sintéticos com pendências resolvidas do caso real. Preservar `9f48004`, B1 e aprovações existentes; sem recebimentos, lançamentos, comunicação externa ou publicação.

- Em 26/10/2026, o utilizador aceitou o cálculo condicionado e autorizou o registo e checkpoint Git exclusivamente local, sem credenciais/dados locais. Ver `docs/CONDITIONAL_CALCULATION_ACCEPTANCE.md`. Perfil, concessões e activação local foram objecto de confirmações específicas; os detalhes nominativos permanecem na ficha local não versionada. Exigibilidade e período de apuramento permanecem pendentes; aprovação temporal não os determina. Preservar versões/âmbito exactos, separação de proponente/validador, B1 e aprovações contabilísticas. Calcular não altera decisão temporal validada. Sem avançar para emissão documental, recebimentos, lançamentos ou publicação.

- Em 26/10/2026, o utilizador aceitou expressamente o cálculo de ensaio demonstrado (base 1000,03; IVA exacto 160,0048; IVA proposto 160,00; diferença preservada 0,0048; total proposto 1160,03) e autorizou registo e checkpoint Git apenas local. Ver `docs/SERVICE_CALCULATION_SEPARATE_REVIEW.md`. Esta confirmação substitui apenas a pendência de aceitação do ensaio: a aplicabilidade fiscal real permanece separada e pendente, sem autorização para activar perfil fiscal real, emitir, contabilizar ou publicar.

- Em 26/10/2026, após informar que entrou e verificou, o utilizador confirmou a aceitação funcional do primeiro incremento de classificação contabilística e autorizou o encerramento e checkpoint Git exclusivamente local, sem credenciais ou dados locais. Preservar a entrega e os limites de `docs/CATALOGUE_ACCOUNTING_DELIVERY.md`. Esta aceitação não abrange a validação do cálculo fiscal, que continua separada e pendente; não autoriza lançamentos, publicação ou outro incremento.

- Autorização posterior: primeiro incremento de classificação contabilística do catálogo, PGC-NIRF, sem lançamentos e sem alterar o cálculo fiscal. Categoria é regra-base; só excepção aprovada, vigente e compatível a substitui. Mudança de categoria que afecte classificação exige nova proposta, vigência e validação; não usar edição de serviços para contornar o circuito. Propostas/submissões/decisões/resoluções são imutáveis; correcção gera nova versão e a substituição de uma versão aprovada é explícita. Data de referência é explícita, não reconhecimento/IVA. Conta agregadora não é conta de movimento; subconjunto documental inicial apenas 7/7.2, sem inventar desdobramentos. Fonte e versão preservadas.
- As quatro concessões contabilísticas iniciais foram especificamente confirmadas e aplicadas em 26/10/2026, após conferência: conta 1, empresa 1, `catalogue_accounting.view/propose`; conta 2, empresa 1, `catalogue_accounting.view/approve`. Osmane prepara; Samira valida/recusa, sem edição/administração implícita. Nenhuma concessão de unidade ou de gestão destes direitos foi acrescentada. Novas concessões exigem confirmação concreta; não associar privilégios a nomes/emails no código. Ver `docs/CATALOGUE_ACCOUNTING_DELIVERY.md`. A validação do cálculo continua separada e pendente.

- Autorização posterior: primeiro cálculo delimitado sobre preço sem imposto, uma linha, apenas ensaios sintéticos isolados em `sgf_tempo_test`. Política `SGF-SERVICE-NET-VAT-TRUNCATE2-v1`: base/IVA exactos, IVA documental proposto truncado a duas casas e diferença preservada; total proposto apenas se base for exactamente representável a duas casas. É decisão operacional do utilizador, não obrigação fiscal demonstrada. Nenhum perfil real activado, nenhum direito fiscal derivado de configuração visual, nenhuma fotografia B1 alterada. Ver `docs/SERVICE_CALCULATION_DELIVERY.md`; instruções históricas abaixo não revogam este âmbito posterior.

- Projecto exclusivo em `C:\laragon\www\sgf-tempo`; não alterar InvesteMoz, os seus dados, configurações, ferramentas ou serviços.
- Base de requisitos: SGF_TEMPO_Roteiro_v0_9.docx. Distinguir decisões acordadas de propostas técnicas e autorização de execução.
- Usar `scripts/sgf.ps1` para ferramentas e arranque. Não usar o PHP/Composer do PATH por omissão nem alterar o PATH global.
- Versões directas fixadas nos manifests; dependências completas nos lockfiles. Qualquer substituição de versão exige apresentação prévia ao utilizador; não instalar ferramentas adicionais automaticamente.
- Monólito modular em `app/Modules`, contexto comum em `app/Shared/Context`. Separar tenant, empresa fiscal e unidade desde o primeiro modelo empresarial.
- Testes apenas na base `sgf_tempo_test`, cluster próprio 127.0.0.1:55432. Manter TestingDatabaseGuard e usar dados sintéticos.
- Aplicação usa sgf_dev_app; migrações de desenvolvimento usam wrapper e proprietário separado. Nunca usar o administrador PostgreSQL na aplicação.
- Nunca apresentar segredos, ler configurações privadas do portal ou versionar .env/.env.testing. .env.example deve permanecer sem segredos.
- Verificar portas antes de iniciar; não parar processos de outros projectos. Não publicar nem implementar módulos financeiros sem nova autorização de âmbito.
- PostGIS e Python adiados até haver função concreta. Não instalar Laravel Boost, IA, serviços externos ou módulos adicionais como preparação automática.
- Validar mudanças da fundação com `sgf.ps1 test`; mudanças React com `sgf.ps1 npm run build`. Documentar limites e comandos de arranque no README.
- Primeiro percurso: login/logout por sessão, contexto de empresa/unidade, nomes e concessões explícitas. Não criar tenants/empresas pela interface nem conceder todas as unidades implicitamente.
- Não criar contas reais ou primeiros acessos sem pré-visualização concreta e confirmação do utilizador. Palavras-passe apenas em entrada oculta no terminal local, nunca no chat, argumentos, logs ou documentação.
- As alterações usam o token do contexto revisto, validação de permissões no servidor e auditoria na mesma transacção. Não remover os triggers de imutabilidade ou de auditoria append-only.
- Provas de navegador usam browser-testing na porta 8001 e apenas sgf_tempo_test, com sessões/cache isolados e CSRF activo. Parar a prova antes de executar testes que recriam a base de testes.
- Em 25 de Outubro de 2026, o utilizador aceitou e deu por concluído o incremento local de entrada, contexto e permissões no âmbito demonstrado e com os limites de docs/IDENTITY_DELIVERY.md. Preservar essa entrega como base. Serviços permanece apenas em especificação; não há autorização para implementação financeira ou publicação.
- Autorização posterior: implementar exclusivamente a entrega A de docs/SERVICES_WORKFLOW_SPEC.md. Clientes/serviços são da empresa; prestações e facturação permanecem rascunhos da unidade. A autorização não abrange B/C, emissão fiscal, confirmação de operações, lançamentos, recebimentos, reconciliação, fecho ou publicação.
- As novas concessões de A foram especificamente confirmadas para as contas existentes ID 1 e ID 2, na empresa ID 1 / unidade ID 1, após conferência. Não inferir direitos dos emails, nomes ou concessões de identidade; qualquer nova aplicação inicial exige confirmação específica.
- Em A, quantidades/preços são cadeias decimais exactas com até 16 algarismos inteiros e 8 decimais. Não usar float, moeda por omissão, imposto desconhecido como zero ou arredondamentos silenciosos. Histórico/eventos/outbox/pendências são transaccionais; não processar contabilidade nesta entrega.
- Em 25 de Outubro de 2026, o utilizador aceitou a entrega A no âmbito demonstrado e com os limites de docs/SERVICES_A_DELIVERY.md e autorizou um checkpoint Git exclusivamente local, sem credenciais ou dados locais. Preservar esta base aceite. Não avançar para B/C nem publicar.
- Autorização posterior delimitada: B1, apenas confirmação interna dos rascunhos de facturação, fotografia imutável e captura transaccional de eventos/pendências. Mostrar «Confirmado internamente — sem validade fiscal». Não emitir documentos comerciais/fiscais, reconhecer receita, produzir lançamentos, receber, reconciliar, fechar ou publicar. A nova concessão billing_drafts.confirm_internal foi especificamente confirmada para a conta existente ID 1, empresa 1/unidade 1; não implica gestão de novas concessões nem altera a consulta da conta ID 2. B1 não conclui B integralmente; ver docs/SERVICES_B1_DELIVERY.md.
- Em 25 de Outubro de 2026, o utilizador aceitou B1 no âmbito demonstrado de confirmação interna, sem validade fiscal nem lançamentos contabilísticos, e autorizou um checkpoint Git local sem credenciais ou dados locais. Preservar B1 e os checkpoints anteriores. Não avançar para os restantes incrementos nem publicar.
- Autorização posterior de 26 de Outubro de 2026: preparação documental de emitente/clientes/rascunhos e instruções de pagamento reutilizáveis do emitente, sem emissão, recebimento ou contabilização. Preservar B1 `8fcd52c`; não reinterpretar preços antigos ou modificar fotografias existentes. Esquema 2 apenas em novas confirmações que utilizem preparação documental. Novos direitos issuer_documents/client_documents view/edit na empresa e draft_documents view/edit na unidade são explícitos; as nove concessões para contas existentes 1 (consulta/edição) e 2 (consulta), empresa 1/unidade 1, foram especificamente confirmadas. Não inferir poderes de gestão desses direitos. Nunca incluir valores completos das instruções em logs técnicos, relatórios de provas ou repositório. Ver docs/DOCUMENT_PREPARATION_DELIVERY.md.
- Autorização posterior: primeira pré-visualização apenas no navegador, aviso fixo «RASCUNHO — SEM VALIDADE FISCAL», configuração delimitada e história B1 exclusivamente da fotografia. Não implementar emissão, cálculos fiscais, PDF/exportação/impressão documental ou operações financeiras. Consultas de pré-visualização são coerentes e read-only; mudanças geram aviso e actualização explícita. Novo direito document_preview.configure requer confirmação específica antes de concessão real; a operação para conta 1/empresa 1 foi especificamente confirmada e aplicada em 26 de Outubro de 2026. Samira permanece apenas em consulta. Novas operações não podem ser aplicadas por inferência. Ver docs/DRAFT_INVOICE_PREVIEW_DELIVERY.md.

- Orientação expressa da Tempo, 29/10/2026: o SGF tem fiscalidade transversal a vendas/compras, stocks, contabilidade geral/custos, análises financeiras e preenchimento automático de modelos IVA/IRPS/IRPC/INSS e outros aplicáveis. Reutilizar o conhecimento já tratado no InvesteMoz (fontes, regras, decisões, correspondências e casos) sem duplicar investigação, acrescentando as capacidades operacionais próprias do SGF. Ausência de prova na auditoria inicial não exclui conhecimento existente nem o requisito. Ver docs/SERVICE_INVOICE_CALCULATION_SPEC.md, secção 11, FIS-SGF-13 a 19. Esta orientação regista âmbito de produto; não declara implementação ou activação operacional e preserva entregas e dados anteriores.