# Classificação contabilística do catálogo — entrega local

## Aceitação funcional e encerramento

Em 26/10/2026, o utilizador informou que entrou na aplicação e verificou o percurso. À pergunta de confirmação da aceitação funcional para registar o encerramento e criar o checkpoint Git local, respondeu **«sim»**. Fica aceite e encerrado este primeiro incremento, no âmbito entregue e com os limites documentados abaixo. O checkpoint preserva a implementação e as dependências locais necessárias, sem credenciais, bases ou dados operacionais locais.

A validação do cálculo fiscal permanece **separada e pendente**. A presença do seu código no checkpoint preserva a base técnica existente; não constitui aceitação fiscal, activação de perfil real, autorização de emissão ou de lançamentos. Nenhum avanço para outro incremento ou publicação foi autorizado.

O texto de entrega seguinte descreve o estado técnico anterior à aceitação; esta secção regista a confirmação posterior, sem alterar as provas.

26 de Outubro de 2026, Africa/Johannesburg. Implementado apenas o primeiro incremento autorizado, com as três salvaguardas de [CATALOGUE_ACCOUNTING_CLASSIFICATION_SPEC.md](CATALOGUE_ACCOUNTING_CLASSIFICATION_SPEC.md). Não constitui aceitação pelo utilizador; a validação do cálculo permanece separada e pendente.

## Funcionalidade entregue

- Propostas imutáveis e versionadas de plano PGC-NIRF, contas empresariais, categorias/regras-base, ligações de serviços a categorias e excepções explícitas por serviço. Reutiliza `a_services`; não criou outro catálogo de serviços.
- Guardar proposta em preparação, submeter uma versão fixa e validar ou recusar com motivo. Validação não edita conteúdo. Correcção gera outra versão, com referência à anterior, e exige nova submissão/decisão; não herda aprovação. Versão ultrapassada não pode ser submetida ou decidida como se fosse a actual.
- Vigência com início explícito e termo opcional inclusivo. Revisão futura ou pendente não substitui regra válida. Intervalos sobrepostos exigem substituição explícita da versão aprovada; conflitos não escolhem automaticamente o maior número de versão. Substituição aprovada termina o intervalo anterior desde o início da nova vigência, sem alterar a linha histórica; a versão substituída não reaparece silenciosamente quando a substituta termina.
- Categoria fornece regra-base. Só excepção aprovada, vigente e compatível a substitui. Uma excepção vigente com dependência incompatível mostra pendência/conflito, sem fallback silencioso. Ausência de excepção aplicável usa a categoria aprovada vigente. Mudança de categoria é proposta do tipo ligação, não campo editável pela API corrente de serviços.
- Consulta por serviço e data explícita, com origem, conta, versões e pendências. Plano ou conta incompatíveis/agregadores não produzem classificação pronta. Não presume data do computador, taxa de IVA ou reconhecimento.
- Resoluções append-only por operação autorizada, com serviço/versão, regra/categoria/conta/plano/decisão e data de referência preservados. A gravação exige a revisão da classificação consultada e a versão da operação; mudança entretanto gera `409`, sem substituir silenciosamente o resultado. Não altera rascunho, fotografia B1 ou cálculo.
- Histórico consultável apenas com consulta contabilística e acesso à operação/unidade actual. Não reconstrói classificação nos registos antigos; histórico vazio significa ausência de captura. Rascunho B1 confirmado recusa captura retroactiva.

Não há lançamentos, débitos/créditos, reconhecimento automático, contas de contrapartida, stock, compras, inventário ou fecho. Perfil/tratamento de IVA continua separado da classificação contabilística. Não foram alterados o núcleo de cálculo, a sua política ou a pré-visualização fiscal.

## Fonte e configuração inicial

Decreto n.º 70/2009, exemplar fornecido, cap. 1.5, PDF 134 / BR 372-(148), com hierarquia 7 — Rendimentos e ganhos → 7.2 — Prestação de serviços. Versão de referência: `Decreto70/2009-PGC-NIRF-PDF134-BR372(148)`; SHA-256 do PDF `45C38AED64DE43042ED048586ACCE2EC660B74FC3F8FBCE33D39AAB45C7529E3`.

Esse é o subconjunto documental inicial, apresentado como referência agregadora não movimentável. Não se importou o plano inteiro. Desdobramento empresarial só é proposto com código, designação, evidência e aprovação; o sistema não inventa uma conta para a Tempo Lda e recusa usar os códigos reservados 7.2/7.2.1/7.2.6 como novos desdobramentos empresariais. A versão do exemplar de 2009 não é apresentada como consolidação normativa actual verificada. A matriz original identifica também os fundamentos de separação de classificação, reconhecimento e IVA; não se repetiu investigação nem se consultou o portal nesta implementação.

O plano actualmente utilizado pela empresa foi confirmado como PGC-NIRF, mas datas de adopção, contas empresariais e enquadramentos concretos serão propostos por Osmane e validados/recusados por Samira no circuito. Não foram criadas propostas ou aprovações reais para preencher essas lacunas por suposição.

## Acessos confirmados e efectivamente aplicados

Após conferência das contas existentes e confirmação específica do utilizador, aplicadas exactamente quatro concessões na Tempo Lda, tenant 1/empresa 1, sem unidade:

| Conta existente | Direitos novos | Acções |
| --- | --- | --- |
| ID 1 — Osmane Nala | `catalogue_accounting.view`, `catalogue_accounting.propose` | Consultar, preparar novas versões, submeter e guardar resoluções nas operações de unidades já autorizadas |
| ID 2 — Samira Nal | `catalogue_accounting.view`, `catalogue_accounting.approve` | Consultar e validar/recusar versões submetidas, sem editar/preparar |

Nenhum `.approve` foi dado a Osmane, nenhum `.propose` a Samira; não se acrescentaram direitos de unidade, gestão de acessos, emissão ou reconhecimento. Todos os direitos anteriores permaneceram iguais. [Verificação posterior das concessões](proofs/accounting-access-results.json).

O código aplica permissões, não privilégios por nome/email. A ferramenta local de concessão recebe IDs explícitos e requer pertenças/direitos de consulta existentes; não cria contas ou pertenças. Novas concessões continuam a exigir apresentação e confirmação específicas. A gestão geral existente não ganhou automaticamente capacidade de delegar estes novos direitos.

## Migração e preservação

Delta apresentado antes de aplicar: `2026_10_26_040000_create_catalogue_accounting.php` cria `ca_proposals`, `ca_submissions`, `ca_decisions`, `ca_resolutions`, `ca_commands`, relações compostas, unicidades, checks e triggers. A restrição de âmbito de `permission_grants` foi alargada para aceitar os três identificadores empresariais, sem os conceder na migração.

Aplicada primeiro em `sgf_tempo_test`, depois em **sgf_tempo_dev** pelo wrapper e proprietário separados. Verificado que era a única migração pendente. Sem reset/fresh de desenvolvimento. Conteúdos existentes e ficheiros do cálculo foram comparados por hashes; permaneceram iguais. As cinco tabelas novas em desenvolvimento continuam com **zero linhas**, mesmo após os quatro acessos. [Preservação da migração](proofs/accounting-dev-preservation.json); [preservação após concessões](proofs/accounting-access-results.json).

Relações compostas e guardas de inserção recusam referências de outra empresa e capturas de outra unidade/operação. Triggers append-only impedem actualização, transferência em massa e apagamento de propostas, decisões, comandos e resoluções. Submissões/decisões também verificam versão e transição na base. Não se declara isso como RLS ou protecção contra administrador da base. Auditoria e comandos são transaccionais; alterações autorizadas são serializadas pelo bloqueio da empresa, com revalidação de contexto/permissões. O contexto do navegador não constitui autorização.

## Testes, compilação e navegador

Suite dirigida inicial: **61 testes / 783 asserções**, passada, cobrindo classificação, A, B1, identidade, isolamento e guardas. Após a protecção adicional da revisão consultada, repetidos apenas os testes afectados de classificação: **9 testes / 397 asserções**, passados. Compilação final Vite 8.3.5 passou. Não se alteraram ferramentas ou dependências, não se repetiu o cálculo fiscal como nova validação.

Cobertura nova inclui separação de funções; recusa e nova versão; submissão/decisão antigas; repetição de comandos com conflito de conteúdo; herança e excepções pendentes/recusadas/futuras; início de vigência; sobreposição e substituição explícita; mudança de categoria sem bypass pela edição do catálogo; conta agregadora; conta/plano incompatível; referências alheias; revogação no pedido seguinte; isolamento de unidades; transferência em massa e inserção directa cruzada; B1 preservado; data em falta; captura de classificação diferente da consultada recusada. Não houve implementação ou geração de lançamentos.

Prova concorrente adicional: **dois processos PHP sobrepostos**, um aprova e outro recusa a mesma versão. Um recebeu 200 e o outro 409; existe uma única decisão. [Recibo da concorrência](proofs/accounting-concurrency.json).

No Edge, instância `http://127.0.0.1:8001`, ligada apenas a `sgf_tempo_test`, sessão/cache isolados e CSRF activo. **Login real com duas identidades sintéticas distintas**, não actingAs como substituto da demonstração. Não se usaram contas reais ou operações fictícias na Tempo Lda. [Registo da observação](proofs/accounting-browser-results.json).

Percurso observado:

1. Login do preparador sintético → Empresa Horizonte — Demonstração → Unidade Central — Demonstração → **Classificação contabilística**.
2. Na categoria sintética aprovada, **Preparar nova versão** → alterar designação/condições → indicar início 01/11/2026 → seleccionar explicitamente a versão aprovada substituída → indicar fundamento → **Guardar proposta em preparação** → **Submeter versão**. Não havia controlos de validação para esse utilizador.
3. Consultar o serviço para 01/11/2026 enquanto a nova proposta aguardava validação: continuou a resolver a categoria v1 aprovada.
4. Sair; login da identidade sintética validadora → mesma empresa/unidade → consultar conteúdo fixo → motivo → **Validar esta versão**. Recusar outra proposta submetida com motivo. Não havia formulário de preparação, botão de correcção ou captura para a validadora. [Prova visual](proofs/accounting-validation.png).
5. Consultar o serviço em 31/10/2026: categoria v1. Em 01/11/2026: categoria v2 aprovada. Na secção de operações autorizadas, carregar a prestação sintética → **Consultar histórico preservado**: conservava a categoria v1 e referências originais, mesmo após a aprovação de v2. [Histórico preservado](proofs/accounting-history.png).
6. Sair. A instância de prova foi encerrada; os testes seguintes só recriaram `sgf_tempo_test`. A aplicação normal manteve a sua ligação.

A guarda final de revisão foi validada por testes HTTP de aplicação: consultar, aprovar outra regra, tentar guardar a revisão antiga → 409; consultar novamente e guardar → sucesso; repetir o comando → mesmo resultado sem duplicação. A prova visual anterior continua a documentar preparação/decisão/vigência/histórico; não se atribui ao navegador uma demonstração posterior de gravação com o novo token de revisão.

## Utilização normal

Actualizar a página/sessão após as concessões e seleccionar Tempo Lda. O menu **Classificação contabilística** aparece para ambos. Não é necessário seleccionar unidade para preparar/validar classificações empresariais; é necessária unidade autorizada para consultar ou guardar resoluções de operações.

Osmane prepara primeiro a versão documental/período do plano e submete; Samira confere e decide. Depois podem ser propostos e validados a conta empresarial documentada, categoria e ligação ao serviço. O sistema não resolve uma classificação por omissão enquanto faltarem aprovações compatíveis. Se a conta de movimento ou a aplicabilidade estiverem por confirmar, conservar pendência; não usar a referência 7.2 como substituto automático.

Para operação autorizada, escolher serviço e data → **Consultar classificação**. Para preservar a resolução, carregar operações da unidade, seleccionar a operação e **Guardar resolução na operação**. Se versão ou regras mudaram, consultar/rever antes de guardar; não tentar sobrescrever a história. Samira consulta resoluções sem receber poder de captura ou edição pela validação.

Ferramentas mantidas por caminhos explícitos no wrapper:

```powershell
powershell -NoProfile -ExecutionPolicy Bypass -File scripts/sgf.ps1 test --stop-on-failure --filter=CatalogueAccountingTest
powershell -NoProfile -ExecutionPolicy Bypass -File scripts/sgf.ps1 npm run build
```

Repetir a demonstração apenas por fluxo de testes: parar `scripts/browser-proof.ps1 stop` antes de recriar testes; partir de base de testes vazia produzida pelos testes; `scripts/browser-proof.ps1 start`, seguido de `sgf.ps1 php scripts/accounting-fixture.php --env=testing`. Preparadores recusam dados existentes e não os apagam para prosseguir. `sgf.ps1 php scripts/accounting-concurrency.php --env=testing` demonstra decisões concorrentes. As credenciais sintéticas ficam no ficheiro local protegido já usado pelo preparador e não são publicadas. A verificação de portas não termina processos de outro projecto. O uso de Bypass é apenas no processo PowerShell, sem alteração global.

## Ficheiros deste incremento e limites

- Núcleo: `app/Modules/Services/CatalogueAccounting.php`, `Http/CatalogueAccountingController.php` e rotas.
- Interface: `resources/js/CatalogueAccountingWorkspace.jsx`, integração/legendas em `app.jsx` e estilos próprios em `app.css`.
- Migração: `2026_10_26_040000_create_catalogue_accounting.php`.
- Testes: `tests/Feature/CatalogueAccountingTest.php`, `tests/Support/CatalogueAccountingFixture.php`.
- Ferramentas/provas: `scripts/accounting-fixture.php`, `accounting-concurrency.php`, `accounting-concurrency-worker.php`, `accounting-preservation.php`, `catalogue-accounting-access.php` e `docs/proofs/accounting-*`.
- Documentação: especificação, este relatório, AGENTS e README. Alterações preexistentes foram preservadas; nenhum checkpoint Git foi criado sem pedido.

Limites: referência histórica fornecida não comprova consolidação normativa actual; contas, datas e regras reais ainda precisam de propostas e validação de Samira. Apenas PGC-NIRF e o papel inicial de rendimento de serviço; sem motor de reconhecimento, diários, contrapartidas, stock/compras ou gestão geral de novas concessões. Sem lançamentos, alteração fiscal, publicação ou avanço para outro incremento. Este relatório não aceita entregas em nome do utilizador.