Regista aceitacao funcional do primeiro incremento PGC-NIRF e preserva as dependencias documentais e tecnicas existentes. A validacao do calculo fiscal continua separada e pendente. Sem credenciais, bases operacionais ou publicacao.
34 lines
9.0 KiB
Markdown
34 lines
9.0 KiB
Markdown
# SGF Tempo — instruções locais
|
|
|
|
- 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.
|