SGF/AGENTS.md

SGF Tempo — instruções locais

• 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.