Preserva entrega A aceite de servicos em rascunho

docs/SERVICES_A_DELIVERY.md

@@ -0,0 +1,82 @@
+# Entrega A — serviços em rascunho
+
+25 de Outubro de 2026. Entrega A aceite pelo utilizador no âmbito demonstrado e com os limites documentados. O checkpoint `26b80df` foi preservado; versões, manifests e lockfiles não foram alterados.
+
+## Aceitação
+
+Em 25 de Outubro de 2026 (Africa/Johannesburg), o utilizador declarou: «Aceito a entrega A no âmbito demonstrado e com os limites documentados. Regista a aceitação e preserva um checkpoint Git local, sem credenciais ou dados locais. Não avances ainda para B/C nem publiques.»
+
+Esta aceitação encerra apenas A. O checkpoint contém código, migração, documentação e provas sintéticas; exclui configurações privadas, credenciais, bases, sessões, logs e o plano operacional específico de concessões locais. Não autoriza B/C ou publicação.
+
+## Percurso funcional
+
+Depois de entrar e seleccionar empresa/unidade autorizadas, estão disponíveis Clientes, Serviços, Prestações em rascunho e Rascunhos de facturação, conforme concessões explícitas.
+
+- Clientes e serviços pertencem à empresa e são reutilizados entre unidades. Nome é o único campo obrigatório do cliente.
+- Prestações e rascunhos de facturação pertencem à unidade autorizada. A facturação reutiliza cliente, linhas, moeda indicada e versão da prestação.
+- Consulta, criação, edição e gestão de concessões são separadas nas quatro áreas. Direitos de identidade não concedem automaticamente direitos de A. Gestores só delegam direitos que possuem no mesmo âmbito.
+- Alterações preservam versões, histórico, eventos duráveis, outbox, pendências e resultado idempotente na mesma transacção. Repetir o comando não duplica o registo ou evento; versões e contextos antigos são recusados.
+- Alterar a prestação gera uma pendência nos rascunhos de facturação associados. Actualizar explicitamente da prestação cria outra versão, preservando a anterior.
+
+Quantidades e preços são cadeias decimais não negativas, com até 16 algarismos inteiros e 8 decimais; quantidade preenchida deve ser positiva. Entradas excedentes são recusadas, sem arredondamento. Produtos e somas derivados usam aritmética decimal exacta, podendo exigir mais casas. A base aritmética não é total fiscal nem valor definitivo a pagar. Moeda não é presumida; imposto desconhecido não é zero. Mesmo com código de moeda preenchido permanece pendente a sua validação. Regras fiscais e contabilísticas continuam explicitamente pendentes.
+
+Não há confirmação financeira, emissão de factura, lançamento contabilístico, recebimento, correcção financeira, reconciliação ou fecho. O outbox fica em captura durável, sem processamento contabilístico. B/C dependem de regras e autorização próprias.
+
+## Migração e preservação de dados
+
+Aplicada em `sgf_tempo_dev`, pelo wrapper de migrações e proprietário separado, a migração aditiva `2026_10_25_030000_create_services_delivery_a` (batch 4). A aplicação conserva o papel `sgf_dev_app`, sem administração PostgreSQL.
+
+O delta cria nove tabelas: `a_clients`, `a_services`, `a_service_drafts`, `a_billing_drafts`, `a_history`, `a_events`, `a_outbox`, `a_pending` e `a_commands`. Amplia o catálogo permitido de concessões, sem conceder acessos automaticamente. Inclui relações de âmbito, protecção SQL contra transferências de pertença, validação de dados e protecção append-only. O escopo Eloquent não é a única fronteira de isolamento.
+
+Não foi executado reset/fresh/wipe em desenvolvimento. As duas contas, tenant, empresa, unidade e oito concessões de identidade foram preservados. Após a implementação, as nove tabelas de A estavam vazias em desenvolvimento: as demonstrações usaram exclusivamente `sgf_tempo_test`.
+
+## Concessões especificamente confirmadas
+
+As contas foram conferidas antes da aplicação; nenhuma foi criada ou associada por suposição. O utilizador confirmou exactamente estas contas e concessões:
+
+| Conta existente | Clientes / serviços — Tempo Lda, empresa 1 | Prestações / facturação em rascunho — SEGI, unidade 1 |
+| --- | --- | --- |
+| ID 1 — Osmane Nala, nala@tempo.co.mz | Consulta, criação, edição e gestão em cada área | Consulta, criação, edição e gestão em cada área |
+| ID 2 — Samira Nal, onala@me.com | Consulta em cada área | Consulta em cada área |
+
+Foram aplicadas e auditadas 16 concessões para Osmane e 4 para Samira, mantendo as oito anteriores (28 no total). Não há direitos implícitos noutras unidades ou poderes financeiros. Os emails apenas identificaram as contas nesta operação confirmada; não determinam privilégios durante a execução da aplicação.
+
+O plano operacional local `scripts/a-access-plan.php` conserva a pré-visualização e as verificações da operação, mas fica excluído do checkpoint por conter identificações locais. Não repetir `--apply` após alterações posteriores dos direitos sem nova confirmação específica. `scripts/a-status.php` permite verificar estado sem apresentar segredos.
+
+## Verificação realizada
+
+- Suite completa: **44 testes, 273 asserções, todos aprovados**, incluindo a fundação anterior.
+- Compilação Vite: aprovada. Nenhuma dependência ou versão foi substituída.
+- Testes de isolamento entre empresas, inclusive do mesmo tenant, e unidades; identificadores manipulados; consulta sem escrita; ausência de herança implícita; limites de delegação; versões/contextos antigos; alterações SQL em massa; histórico imutável; rollback integral com falha injectada no outbox.
+- Dois processos PHP concorrentes: criação repetida produziu um registo/evento; edição concorrente terminou em 200/409, com apenas uma nova versão/evento. [Resultado](proofs/a-concurrency.json).
+- HTTP com login real de contas sintéticas: leitura 200, alteração/gestão recusadas 403, concessão/revogação efectivas no pedido seguinte da mesma sessão, contexto/versão antigos 409, protecção CSRF 419 e cookie de sessão terminada 401. [Resultado](proofs/a-http-results.json).
+- Captura durável na prova: 9 versões, 9 eventos, 9 entradas de outbox, 9 resultados de comandos, sem eventos órfãos; estado apenas `captured`. [Métricas](proofs/a-durable-capture.json).
+- `verify-foundation.php` confirmou isolamento de papéis e ausência de contas sintéticas na base de desenvolvimento.
+
+A prova visual utilizou uma instância isolada na porta 8001, ligada apenas a `sgf_tempo_test`, com sessões/cache próprios, CSRF activo e utilizadores sintéticos equivalentes. Incluiu login pelo formulário, criação de cliente/serviço/prestação, recusa de precisão excessiva, preparação e edição de rascunho de facturação, histórico e gestão delimitada de acessos. O utilizador de consulta viu os registos sem botões de criação, edição ou gestão. Não se tratou apenas de `actingAs`.
+
+Provas: [precisão recusada](proofs/a-01-precision-refused.png), [rascunho](proofs/a-02-draft-pending.png), [histórico e pendências](proofs/a-03-history-and-pending.png), [consulta](proofs/a-04-read-only.png).
+
+A instância de prova foi parada e a suite executada novamente para limpar os dados sintéticos na base de testes. A aplicação normal permaneceu na porta 8000, sem alteração de ligação ou dados de demonstração na Tempo Lda/SEGI. Não foram terminados processos de outros projectos.
+
+## Ficheiros e utilização
+
+Implementação em `app/Modules/Services` (permissões, valores, workflow, acessos e controlador), migração acima, `resources/js/ServicesWorkspace.jsx`, integração em `app.jsx`, CSS e rotas. A fundação de identidade foi reutilizada; a auditoria recebeu metadados de A e a listagem antiga de acessos ficou delimitada ao seu catálogo.
+
+Testes em `tests/Feature/ServicesDeliveryATest.php` e `tests/Support/ServicesFixture.php`; procedimentos de prova em `scripts/a-concurrency-proof.php`, `a-concurrency-worker.php`, `a-http-proof.mjs` e `a-proof-metrics.php`, com preparação de fixtures sintéticas adaptada. README e especificação foram actualizados.
+
+Para utilizar, actualizar o navegador em http://127.0.0.1:8000, entrar normalmente e seleccionar Tempo Lda/SEGI. Seguir o percurso do [README](../README.md). Não executar os scripts de fixtures para criar dados reais. A recuperação local assistida da identidade mantém-se documentada em [IDENTITY_WORKFLOW.md](IDENTITY_WORKFLOW.md); não há recuperação por email.
+
+Comandos de verificação, a partir do projecto:
+
+```powershell
+powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\sgf.ps1 test
+powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\sgf.ps1 npm run build
+powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\sgf.ps1 php scripts/a-status.php
+```
+
+As provas destrutivas continuam bloqueadas fora de `sgf_tempo_test`. Parar a instância de navegador de testes antes de executar a suite que recria essa base. Os scripts de prova de concorrência e métricas têm também verificação própria do destino. Não mudar a aplicação normal para a base de testes.
+
+## Limites e próxima decisão
+
+A entrega A foi aceite com estes limites. Não define regime fiscal, numeração, moeda funcional, plano de contas, reconhecimento ou arredondamento fiscal. Não inclui emissão, processamento contabilístico ou processamento externo do outbox. Não foi publicada nem iniciado outro incremento. A especificação B/C permanece como proposta, sem autorização de execução.

docs/SERVICES_WORKFLOW_SPEC.md

@@ -19,7 +19,7 @@ O incremento de entrada, contexto e permissões tem implementação e provas té
 
 O utilizador aceitou e deu por concluído o incremento local de entrada, contexto e permissões em 25 de Outubro de 2026, no âmbito demonstrado e com os limites de IDENTITY_DELIVERY.md. Preservar essa entrega como base. Limites conhecidos: âmbito local, sem MFA/RLS de produção, sem criação geral de contas pela interface e com procedimentos locais assistidos de recuperação. A aceitação está registada separadamente do cenário de serviços.
 
-Nesta etapa está autorizada apenas a especificação de serviços. As entregas A/B/C abaixo são um plano para decisões posteriores, não uma ordem para as implementar agora.
+Na revisão inicial estava autorizada apenas a especificação. Posteriormente o utilizador autorizou executar exclusivamente A através do prompt de execução anexado, mantendo B/C fora do âmbito. A implementação de A e as provas estão documentadas em SERVICES_A_DELIVERY.md; isso não constitui aceitação automática de A nem autoriza B/C ou publicação.
 
 ## Resultado pretendido
 
@@ -108,6 +108,10 @@ Não acrescentar já contratos recorrentes, horas, equipas de projecto, custos,
 
 Identificadores de tenant, empresa e unidade vêm do contexto autorizado. Cliente e serviço devem pertencer à empresa da prestação. Uma escolha de cliente reutiliza o cadastro; documentos confirmados futuros preservam a fotografia histórica necessária em vez de dependerem do cadastro mutável.
 
+Na entrega A, clientes e serviços pertencem à empresa e são reutilizados entre as suas unidades. Não criar cópias por unidade nem exigir unit_id nesses cadastros. Prestações e rascunhos de facturação pertencem à empresa e à unidade autorizada: o vínculo à unidade não pode ser transferido por edição de um formulário.
+
+O nome será o único campo obrigatório introduzido pelo utilizador no cadastro de cliente nesta fase. Identificadores, empresa, papel de cliente e metadados de autoria/versão são controlados pelo servidor. Não exigir dados fiscais ou contactos para guardar esse cadastro mínimo; a ausência dos dados necessários a documentos futuros permanece uma pendência, não uma indicação de validade fiscal.
+
 ## Estados propostos
 
 - Prestação: rascunho, confirmada ou cancelada antes de confirmação. Uma correcção posterior referencia a prestação confirmada; não elimina a origem.
@@ -122,11 +126,11 @@ O primeiro incremento não deve apresentar os estados futuros como capacidades j
 ## Regras técnicas propostas
 
 1. Guardar preços, quantidades e montantes com precisão controlada; usar brick/math existente no servidor e cadeias decimais nas APIs. Não usar o JavaScript como autoridade financeira.
-2. Validar escala e arredondamento explicitamente. A política financeira/fiscal precisa de aprovação; não depender de coerção silenciosa da base.
+2. Validar escala explicitamente e rejeitar valores que excedam a precisão suportada antes de persistir, sem arredondamento silencioso. Não presumir moeda nem converter imposto desconhecido em zero. Guardar o rascunho incompleto com pendências explícitas quando necessário. A política financeira/fiscal de arredondamento continua por validar; não depender de coerção silenciosa da base.
 3. Negar por omissão cada acção e verificar empresa, unidade, registo e permissão no servidor. As concessões actuais de identidade não concedem acesso automático às novas áreas.
 4. Recusar um formulário com contexto ou versão desactualizados. Mudança de empresa/unidade não relocaliza registos nem reaproveita silenciosamente autorizações anteriores.
 5. Usar chaves de idempotência por empresa/operação/conteúdo para comandos repetíveis. Repetição idêntica recupera o resultado; conteúdo diferente com a mesma chave origina conflito.
-6. Confirmar alteração, evento durável e trabalho pendente na mesma transacção. A outbox é uma proposta técnica a implementar no núcleo, sem exigir Redis ou novo fornecedor.
+6. Confirmar alteração, histórico, evento durável e trabalho pendente na mesma transacção desde a entrega A. A outbox integra a proposta de captura inicial, sem exigir Redis ou novo fornecedor. B acrescenta processamento contabilístico sobre essa base, sem reconstruir eventos históricos ou inferir acontecimentos a partir do último estado de um rascunho.
 7. Não duplicar efeitos contabilísticos quando um evento é repetido ou uma interface comercial é activada posteriormente.
 8. Sem plano de contas, classificação, imposto, moeda ou reconhecimento aprovados, criar pendências explícitas. Não escolher contas transitórias para ocultar lacunas.
 9. Manter auditoria das alterações relevantes, sem palavras-passe, tokens ou raciocínio interno da IA.
@@ -151,21 +155,37 @@ Separar consulta e alteração de cadastros, criação/edição/confirmação de
 
 As concessões serão dados parametrizados, mas o catálogo cobre apenas acções suportadas. Gestão de acessos não implica capacidade financeira. Não ampliar automaticamente os direitos de Osmane ou Samira. A matriz concreta e a autoridade inicial de concessão das novas acções precisam de aprovação antes da disponibilização.
 
+### Matriz delimitada para a entrega A
+
+| Área | Âmbito dos registos e das concessões | Osmane | Samira |
+| --- | --- | --- | --- |
+| Clientes | Tempo Lda, cadastro partilhado pelas unidades | Consultar, criar, editar e gerir estas concessões | Apenas consultar |
+| Serviços | Tempo Lda, catálogo partilhado pelas unidades | Consultar, criar, editar e gerir estas concessões | Apenas consultar |
+| Prestações em rascunho | Tempo Lda / SEGI | Consultar, criar, editar e gerir estas concessões | Apenas consultar |
+| Rascunhos de facturação | Tempo Lda / SEGI | Consultar, criar, editar e gerir estas concessões | Apenas consultar |
+
+Separar consulta, criação, edição e gestão de concessões em cada área; não introduzir um papel universal. A autoridade sobre os cadastros de empresa não concede autoridade sobre prestações/rascunhos de outras unidades. Os clientes e serviços, sendo cadastros de empresa, não ficam artificialmente privados da SEGI.
+
+Estas são novas concessões, cuja atribuição inicial deve ser explícita e auditada. Não as derivar dos actuais company.edit/access.manage ou da identidade/email das pessoas. O gestor só pode delegar direitos que possui, no mesmo âmbito. Não incluir confirmação financeira/documental, recebimentos, correcções, reconciliação, lançamentos ou fecho. Após conferir as contas existentes e obter confirmação específica, foram aplicadas 16 concessões à conta ID 1 (Osmane Nala) e 4 de consulta à conta ID 2 (Samira Nal), sem criar ou associar outra conta por suposição. Ver SERVICES_A_DELIVERY.md para âmbitos e evidências.
+
 ## Entregas verificáveis
 
 ### A Cadastros e preparação operacional
 
-Proposta para a primeira implementação:
+Âmbito delimitado para a primeira implementação, sujeito à autorização de execução:
 
-- Contraparte/cliente e serviço mínimos.
-- Prestação em rascunho, reutilizando esses cadastros e o contexto existente.
-- Rascunho de facturação ligado à prestação, sem emissão fiscal ou numeração definitiva.
-- Captura durável dos acontecimentos abrangidos e pendências explícitas de classificação, sem inventar lançamentos.
+- Contraparte/cliente e serviço mínimos, partilhados pela empresa; nome como único campo obrigatório do cliente.
+- Prestação em rascunho na unidade autorizada, reutilizando esses cadastros e o contexto existente.
+- Rascunho de facturação na mesma unidade, ligado à prestação, sem emissão fiscal ou numeração definitiva.
+- Histórico, captura durável dos acontecimentos abrangidos e pendências explícitas de classificação desde A, sem inventar lançamentos. B reutiliza essa base e acrescenta o processamento contabilístico.
+- Valores de precisão controlada, sem arredondamentos silenciosos, moeda presumida ou imposto desconhecido convertido em zero.
 - Permissões, auditoria, controlo de versão/contexto e repetição segura desde estes primeiros comandos.
 - Dados sintéticos e provas apenas na base de testes; nenhuma factura ou recebimento real em desenvolvimento.
 
 Critério: percurso cliente → serviço → prestação → rascunho reproduzível, com origem preservada, acessos indevidos recusados e informação insuficiente assinalada. Isto não é ainda o circuito financeiro completo.
 
+A não emite facturas nem produz lançamentos contabilísticos. Documentos confirmados, recebimentos, correcções, reconciliação e fecho permanecem exclusivamente em B/C.
+
 ### B Documentos e contabilidade permanente
 
 Após validar campos/regras aplicáveis: confirmação documental, fotografia histórica, eventos/outbox, consumidor repetível, regras de contabilização e pendências. Demonstrar contabilidade permanente mesmo sem interface comercial de Contabilidade contratada.
@@ -196,7 +216,7 @@ Estas entregas partilham o mesmo núcleo. Não criam três produtos ou versões
 
 ## Decisões pendentes antes das entregas correspondentes
 
-Para A: aprovar esta delimitação e a matriz de permissões/autoridade inicial; confirmar quais dados mínimos do cliente são indispensáveis para um rascunho (a proposta inicial exige apenas nome).
+Para A: o utilizador autorizou a execução e confirmou especificamente a aplicação das novas concessões após conferência das contas. A implementação usa nome como único campo obrigatório do cliente, cadeias decimais até 16 algarismos inteiros/8 decimais, validação anterior à persistência e protecção também na base, sem arredondamento silencioso. O delta aditivo e os resultados constam de SERVICES_A_DELIVERY.md. A aceitação deste incremento é distinta da aceitação anterior de identidade.
 
 Para B/C: responsáveis de validação contabilística/fiscal, documentos e numeração, regime/impostos aplicáveis, moeda funcional, plano de contas, reconhecimento, arredondamento, evidências de recebimento/reconciliação, corte e regras de fecho/correcção. O exemplo de teste não decide estas matérias.
 
@@ -204,4 +224,4 @@ Não seleccionar fornecedor, API bancária ou integração de pagamento. Não co
 
 ## Estado desta etapa
 
-Especificação proposta para revisão. Nenhuma migração, cadastro, documento, evento financeiro ou lançamento foi criado nesta etapa. O incremento de identidade está aceite e concluído; qualquer implementação posterior exige autorização sobre uma entrega concreta. O utilizador manteve expressamente serviços apenas em especificação e não autorizou implementação financeira ou publicação. Não implementar a entrega A nesta revisão documental.
+Entrega A implementada após autorização concreta e aceite pelo utilizador em 25 de Outubro de 2026, no âmbito demonstrado e com os limites do relatório SERVICES_A_DELIVERY.md. A base de identidade aceite foi preservada. B/C permanecem apenas em especificação: não foram implementados documentos confirmados, emissão fiscal, lançamentos, recebimentos, correcções, reconciliação ou fecho. Não há autorização para avançar para B/C ou publicar.

docs/proofs/a-concurrency.json

@@ -0,0 +1,16 @@
+{
+    "environment": "sgf_tempo_test only",
+    "parallel_php_processes": true,
+    "company_lock_overlap": true,
+    "identical_create": {
+        "same_record": true,
+        "second_replayed": true,
+        "events_created": 1
+    },
+    "concurrent_edit": {
+        "first_status": 200,
+        "second_status": 409,
+        "version_after": 2,
+        "events_created": 1
+    }
+}

docs/proofs/a-durable-capture.json

@@ -0,0 +1,18 @@
+{
+    "database": "sgf_tempo_test",
+    "counts": {
+        "a_clients": 3,
+        "a_services": 1,
+        "a_service_drafts": 1,
+        "a_billing_drafts": 1,
+        "a_history": 9,
+        "a_events": 9,
+        "a_outbox": 9,
+        "a_pending": 9,
+        "a_commands": 9
+    },
+    "events_without_outbox": 0,
+    "outbox_states": [
+        "captured"
+    ]
+}

docs/proofs/a-http-results.json

@@ -0,0 +1,10 @@
+{
+  "environment": "browser-testing / sgf_tempo_test only",
+  "results": [
+    "Criação repetida recupera o mesmo registo/evento; conteúdo diferente com a mesma chave é recusado (409).",
+    "Consulta por credenciais reais sintéticas: leitura 200, edição e gestão 403.",
+    "Concessão/revogação de edição têm efeito no pedido seguinte, mantendo a mesma sessão.",
+    "Versão antiga e contexto antigo recusados (409); alteração sem protecção CSRF/origem recusada (419).",
+    "Cookie anterior à saída não recupera acesso aos dados de A (401)."
+  ]
+}