compras/docs/validacao-tecnica.md

# Validação técnica do SGC — 28 de Outubro de 2026

## Incremento: recomendação formal antes da adjudicação

O âmbito de `docs/proposta-recomendacao.md` foi validado pelo utilizador e
implementado. A Administração configura uma política própria de recomendação
em `/politica-recomendacao`, com perfis Finanças e/ou chefia do departamento,
quantidade de pessoas distintas, activação e fundamento expressos. Não há
perfis ou quantidade inicialmente seleccionados. O máximo de 50 confirmações
é um limite técnico e não define um quórum empresarial.

Compras adopta a versão activa em `/requisicoes/{requisition}/recomendacao`,
num pedido aprovado que já adoptou o regime de admissão, antes de adjudicar.
Sem essa adopção, mantém-se o circuito existente. Uma versão geral nova ou
desactivada não reescreve processos; a desactivação impede novas adopções.
Trocar a versão aplicável exige adopção expressa e novas tentativas e
conferências. Uma política de admissão não autoriza, por si, a recomendação.

A recomendação exige matriz pronta, admissões confirmadas na base actual,
três fornecedores distintos elegíveis e duas avaliações por proposta, sem
alteração do cálculo ponderado existente. Compras, diferente do solicitante,
escolhe expressamente entre as maiores pontuações e fundamenta, incluindo em
empate. Não há desempate automático, dispensa do mínimo, escolha abaixo da
maior pontuação ou autorização para corrigir preços.

Cada tentativa preserva matriz, propostas/linhas, avaliações, referências e
bases das admissões/requisitos/análises, conferências, política e proponente.
Os dados de contacto ou documentos privados dos fornecedores não entram na
matriz preservada. Uma nova tentativa é imutável e não herda confirmações.
Uma devolução encerra a tentativa sem excluir o concorrente ou cancelar o
processo. Conferências repetidas idênticas são idempotentes e contam uma vez.
Identidades, empresa, perfil, departamento, segregação e conflitos são
revalidados dentro da transacção, após o bloqueio da empresa. As confirmações
anteriores são revalidadas até concluir o quórum; a história concluída conserva
a elegibilidade verificada na sua data, sem autorizar futuras operações com
perfil revogado. Uma pessoa não conta duas vezes após mudar de perfil.

Nos processos com adopção, a adjudicação só selecciona a mesma proposta de
uma recomendação confirmada na base actual. A referência e a base ficam
preservadas na adjudicação e na ordem; são revalidadas antes de aprovar/emitir.
Uma alteração de avaliação ou uma nova admissão pode invalidar a recomendação
mesmo mantendo preços e pontuações. Não se reescrevem adjudicações/ordens
anteriores. Existindo adjudicação, a adopção e as tentativas/conferências
ficam fechadas; alterações exigem o circuito de revisão já suportado, quando
autorizado. A repetição de uma emissão concluída devolve a mesma ordem.
Recomendar não movimenta orçamento nem substitui as aprovações do valor final,
regras de investimento, conflitos, facturas ou pagamentos.

As páginas usam o cabeçalho, rodapé, menus e identificação Sistema de Gestão
de Compras (SGC). Comparação, adjudicação e processo completo ligam ao novo
circuito; o processo apresenta os eventos de auditoria. O relatório de
conferência assinala a adopção e remete para o relatório preservado da
recomendação. A impressão autenticada em `/recomendacoes/{attempt}/imprimir`
mostra matriz/base originais, candidata, fundamentos, conferências, devoluções
e tentativas anteriores da mesma adopção, distinguindo dados históricos da
situação actual. As restantes adopções são consultáveis na página do processo.
O conteúdo é escapado e a resposta é `private, no-store`. Em PostgreSQL, a
impressão usa `REPEATABLE READ, READ ONLY`, relendo o operador; não cria
auditoria nem outros registos. Não é uma assinatura digital ou certificação
das evidências. A revisão visual da paginação continua pendente.

Resultado da bateria completa: **498 testes aprovados, 2 ignorados, 4141
asserções**. Inclui **17 cenários de recomendação**, com percurso genuíno até
adjudicação/emissão, empate e escolha da proposta empatada, escolha abaixo
da maior pontuação, matriz incompleta, admissão pendente/nova, mudanças de
base, devolução, repetição, perfis/departamentos revogados, mesma identidade
em perfis diferentes, política preservada, circuito sem adopção, segregação,
isolamento, relatório histórico sem escrita, escape de conteúdo e rollback
de auditoria de tentativa/conferência.

Passaram **8 cenários PostgreSQL**, com processos PHP e ligações independentes
e dois bloqueios simultâneos observados em cada cenário: mesma pessoa,
pessoas distintas, respostas opostas, perfil revogado, avaliação alterada,
nova adopção durante a espera, tentativas concorrentes e nova recomendação
versus adjudicação. Conferiram-se quórum, versões, auditoria e vínculo à
tentativa; a base de teste foi eliminada. O resultado está em
`docs/recomendacao-concorrencia-postgresql.json`. Não se afirma que foram
observadas todas as ordens possíveis de escalonamento ou testada corrida de
impressão/emissão nesta bateria.

Migração `000020`, lote **21**, aplicada em `compras_dev` após backup privado
de **326150 bytes**, verificado por restauro numa base separada e eliminada
depois da conferência. As **61 tabelas anteriores**, os registos de negócio
por projecção das colunas originais, restrições existentes, histórico de
migrações e `.env` foram preservados. São quatro tabelas novas e um campo
JSON anulável na adjudicação. As quatro tabelas reais de recomendação estão
vazias; não houve publicação de políticas, seeds ou compras reais. O relatório
sanitizado está em `docs/recomendacao-migracao-000020.json`; backup e manifesto
continuam privados e fora do Git. O rollback destrutivo automático é impedido.

Pint, PHPStan, TypeScript, build e lint/formatação do âmbito passaram. A
formatação global de `docs/compatibilidade.md`, alteração local alheia, continua
pendente e fora do commit, juntamente com as alterações de desenvolvimento e
continuidade preservadas. O navegador voltou a devolver `The browser access
host is unavailable`: permanecem pendentes revisão visual pública, autenticada,
de impressão e interacções no navegador. Validação operacional integral das
empresas, novas modalidades/métodos de avaliação, dispensas, comunicação
externa, cancelamento de ordens emitidas, estornos/devoluções e agregação por
projecto/fraccionamento não são declarados concluídos por esta entrega.

## Preparação: proposta de recomendação formal

Após `d020be5`, foi preparada `/proposta/recomendacao`, ligada ao menu
**Compras** apenas na consulta demonstrativa. Usa a navegação, cabeçalho e
rodapé partilhados do Sistema de Gestão de Compras (SGC), com dados fictícios
locais. Permite experimentar configuração de perfis/quantidade sem valores
iniciais, adopção explícita, matriz pronta/impedida, empate, escolha manual,
fundamento, conferências, devolução e histórico. A alteração de base ou de
política adoptada torna a tentativa anterior histórica. A impressão é
identificada como simulação. Não há persistência no navegador ou no servidor.

O circuito real proposto está em `docs/proposta-recomendacao.md`. A sua
implementação aguarda validação: política própria por empresa, adopção
opcional após regime de admissão, conferência independente e vínculo da
adjudicação à recomendação confirmada na mesma base. Não se publicaram
políticas, acrescentaram migrações ou alteraram regras de adjudicação,
orçamento, facturação ou pagamento. Os exemplos históricos não fornecem
parâmetros obrigatórios às aderentes.

Passaram **18 testes de entrada e consulta pública, com 290 asserções**,
incluindo as demonstrações de qualificação/admissão/recomendação, identidade
pública nula sem terminar a sessão existente e ausência de endpoint público
de escrita. PHPStan, Pint, TypeScript, build e lint/formatação do âmbito passaram.
Confirmado HTTP 200 com componente `preview/recommendation`, utilizador nulo,
apenas propriedades gerais da consulta pública e título inicial Sistema de
Gestão de Compras (SGC).
A bateria completa do negócio não foi repetida neste incremento de
interface; os resultados de 478 aprovados e 2 ignorados abaixo pertencem à
entrega anterior de admissão. As alterações locais dos três documentos de
continuidade foram preservadas; a formatação global de `docs/compatibilidade.md`
continua fora do âmbito desta entrega.

O controlo do navegador voltou a devolver `The browser access host is
unavailable`. A revisão visual e de interacção, incluindo impressão, continua
pendente e não é substituída pelos testes automatizados.

## Incremento: admissão e exclusão por adopção expressa

O utilizador validou `docs/proposta-admissao-exclusao.md`. A Administração da
empresa pode registar versões da política em `/politica-admissao`, indicando
expressamente perfis de conferência (Finanças e/ou chefia do departamento),
quantidade de pessoas distintas e fundamento. Não há quantidade nem perfis
pré-seleccionados. O máximo de 50 no formulário é um limite técnico, não uma
regra empresarial. A disponibilidade de pessoas elegíveis deve acompanhar a
configuração da empresa.

Compras adopta a política activa em `/requisicoes/{requisition}/admissao`,
num pedido aprovado e antes de adjudicar. Sem adopção, mantém-se o circuito
existente. A política adoptada fica preservada; desactivar a política geral
impede novas adopções e não reescreve processos existentes. Aplicar outra
versão exige nova adopção expressa e novas decisões/conferências. Não há
regresso implícito ao circuito sem admissão.

Compras propõe admitir, excluir ou pedir esclarecimento interno por proposta,
com fundamento e base preservada de requisitos, propostas e últimas análises
de cada analista. O proponente não pode ser o solicitante. Admitir exige
análise existente sem pendências, respostas em falta ou divergências e com
todos os requisitos obrigatórios cumpridos. Um requisito facultativo
uniformemente não cumprido ou não aplicável não constitui, por si, uma
dispensa de requisito obrigatório.

Os conferentes são pessoas distintas, da mesma empresa, com perfil e
departamento ainda elegíveis, diferentes do solicitante e do proponente,
sem conflito de interesses. Uma conferência repetida com conteúdo idêntico
é idempotente e conta uma vez; outra resposta não reescreve a assinatura.
Uma devolução termina a tentativa sem excluir automaticamente o concorrente.
Corrigir cria nova tentativa, sem copiar confirmações. Antes de concluir o
quórum, as confirmações anteriores são revalidadas; uma decisão concluída
conserva a elegibilidade verificada na sua data. Uma alteração de base,
tentativa ou adopção invalida a utilização de conferências antigas.

A comparação usa o cálculo ponderado existente. Nos processos que adoptaram
o regime, só propostas com admissão confirmada e actual são elegíveis.
Mantêm-se os mínimos existentes de três fornecedores elegíveis e duas
avaliações por proposta, sem dispensas novas. A base da admissão fica na
adjudicação e na ordem; é revalidada antes de aprovar/emitir. Não se aplicam
regras retroactivas a adjudicações/ordens existentes nem se reemitem ordens
já emitidas. A admissão, sozinha, não movimenta orçamento, facturas ou
pagamentos. O relatório de conferência identifica o regime adoptado; o
processo completo liga às decisões e apresenta os eventos de auditoria.

As novas páginas usam o cabeçalho, rodapé e navegação partilhados. O título
HTML inicial foi corrigido de `ProcuraFlow` para **Sistema de Gestão de
Compras (SGC)**, sem modificar `.env`. O nome visível das novas páginas
segue a mesma identificação.

Migração `000019`, lote **20**, aplicada em `compras_dev` após backup privado
de **306342 bytes**, verificado por restauro numa base separada e eliminada
após a conferência. Foram verificadas **57 tabelas anteriores**, registos de
negócio por projecção das colunas originais, restrições existentes, histórico
de migrações e integridade de `.env`. A migração acrescenta quatro tabelas e
um campo JSON anulável na adjudicação. As quatro tabelas reais estão vazias;
nenhuma política foi publicada por conta das aderentes. O relatório sanitizado
está em `docs/admissao-migracao-000019.json`; o backup/manifesto permanecem
privados, fora do Git. O rollback automático destrutivo está impedido.

Os seis cenários em `docs/admissao-concorrencia-postgresql.json` passaram
com ligações/processos PHP independentes e dois bloqueios simultâneos
observados no PostgreSQL: mesma pessoa, pessoas distintas, respostas
opostas, perfil revogado, base alterada e nova adopção durante a espera.
Conferências, quórum e auditoria foram conferidos; a base de teste foi
eliminada. Não se apresenta esta bateria como um teste de corrida de emissão.

Resultado final do servidor: **478 testes aprovados, 2 ignorados e 3887
asserções**. A bateria inclui os 13 cenários novos de admissão e quatro de
integração real com adjudicação/emissão: base preservada na ordem,
pontuações mantidas, exclusão e mínimo de fornecedores, alterações antes da
emissão, repetição de emissão e adjudicação anterior sem adopção retroactiva.
Os 94 testes dos módulos directamente relacionados também passaram após a
integração do histórico e do campo preservado na ordem. PHPStan e Pint
passaram. TypeScript, build e lint/formatação dos ficheiros deste âmbito
passaram; a verificação global continua limitada pela formatação alheia
indicada abaixo. HTTP 200 confirmado para início, demonstração de admissão
e login, todos com o título inicial Sistema de Gestão de Compras (SGC).

O navegador continua a devolver `The browser access host is unavailable`.
Permanecem pendentes a revisão visual pública, autenticada e de impressão e
as interacções no navegador. As verificações HTTP e automatizadas não a
substituem. Recomendação formal em etapas, excepções/dispensas, comunicação
externa e cancelamento de ordens emitidas ficam fora desta entrega.
Os três documentos locais de continuidade foram preservados sem os incluir
no commit. A formatação global de `docs/compatibilidade.md`, alteração alheia,
continua pendente; a verificação de âmbito exclui esse ficheiro.

## Incremento: relatório de conferência e impressão

As propostas e a visão única do processo incluem o acesso a
`/requisicoes/{requisition}/relatorio`. O relatório reúne identificação do
pedido, matriz comparativa actual, última versão dos requisitos documentais,
último registo de cada analista por proposta e referências à acta,
adjudicação e ordem existentes. Não é uma recomendação formal nem uma nova
etapa obrigatória da compra.

As pontuações, ponderações e impedimentos são devolvidos pelo método de
comparação existente, sem recalcular outro modelo ou classificar por menor
preço. Uma matriz incompleta não apresenta maior pontuação como recomendação;
empates da matriz pronta são identificados sem desempate automático. As
propostas são apresentadas na ordem de registo. Valores de adjudicação e
ordem preservados são mostrados separadamente dos preços actuais.

Os resultados documentais pertencem à base preservada na versão dos
requisitos. Se essa base divergir da actual, o relatório assinala-o e mantém
nomes, referências e análises da versão original. Respostas por analisar e
propostas sem registos não são apresentadas como análise concluída. Não há
consolidação por maioria, quórum presumido, dispensa automática de requisito,
admissão/exclusão ou autorização financeira.

Em PostgreSQL, o relatório é construído numa transacção própria de leitura,
`REPEATABLE READ, READ ONLY`, sem criar auditoria ou outros registos de
negócio. O operador é relido antes de consultar dados, respeitando empresa,
departamento e perfis autorizados para propostas. Não são devolvidos dados
bancários, contactos, beneficiários ou documentação privada dos fornecedores.
A resposta usa `private, no-store` e histórico Inertia cifrado.

A impressão usa os dados já carregados no ecrã, sem nova consulta ao servidor
ao imprimir. Apresenta instante da consulta, fuso Africa/Johannesburg (UTC+2),
utilizador e identificação do processo. Actualizar a página é uma consulta
nova. O relatório não fica guardado como versão assinada, decisão ou prova
de validação de evidências. A impressão está preparada em A4 horizontal,
com cabeçalhos de tabela repetíveis, mas a revisão visual continua pendente.

Resultado: **461 testes aprovados, 2 ignorados, 3698 asserções**. Sete testes
novos verificam ausência de decisões inventadas e de escritas, dados antigos
separados dos actuais, registos independentes por analista, restrições de
perfil/empresa/departamento, revalidação do operador, minimização de dados e
empates/valores preservados de ordens efectivamente emitidas pelo circuito.
PHPStan, Pint, TypeScript, build e lint dos ficheiros alterados passaram.

Três verificações PostgreSQL passaram numa base temporária exclusiva:
consistência da consulta enquanto outra ligação corrige análise, altera
proposta e cria requisitos novos; perfil revogado depois de carregar o
operador; departamento alterado antes de iniciar a leitura. Foi observada a
espera concorrente por bloqueio consultivo. O primeiro cenário verificou
explicitamente `repeatable read` e `read_only=on` e devolveu apenas o estado
original, sem misturar versões posteriores. Não foram criados eventos de
negócio pelo leitor e a base temporária foi eliminada. Ver
`relatorio-concorrencia-postgresql.json`.

Não houve migração nem escrita na base de negócio. As alterações locais de
`compatibilidade.md`, `desenvolvimento.md` e `orientacoes-continuidade.md`
foram preservadas e excluídas desta entrega. A formatação global desse
primeiro documento permanece fora do âmbito. Revisão visual, decisão formal
de admissão/exclusão, recomendação formal e cancelamento de ordens emitidas
continuam pendentes nos respectivos âmbitos.

O navegador voltou a devolver `The browser access host is unavailable` nesta
verificação. Testes HTTP, compilação e a opção de imprimir não substituem a
revisão visual pública, autenticada e de impressão.

## Incremento: qualificação documental validada

O responsável validou o primeiro âmbito documental de
`proposta-qualificacao-propostas.md`. Nas propostas existe o acesso
«Qualificação documental», em `/requisicoes/{requisition}/qualificacao`.
Compras define requisitos por processo com descrição, categoria e indicação
de obrigatoriedade segundo a regra desse processo. Não há certificados,
montantes mínimos ou requisitos predefinidos importados dos exemplos.

Ao guardar os requisitos fica preservada uma versão imutável e a base das
propostas. Uma alteração cria outra versão, conservando os dados anteriores.
Compras, Finanças e chefia autorizada analisam, desde que o analista seja
distinto do solicitante e cumpra o âmbito departamental e os conflitos
existentes. Administração consulta. Cada utilizador conserva o seu próprio
registo por proposta e versão dos requisitos; não substitui o de outro analista.

Cada registo contém uma resposta para todos os requisitos: por analisar,
cumprido, não cumprido ou não aplicável. Resultados preenchidos exigem
fundamento; cumprido/não cumprido exigem também referência de evidência.
Não aplicável exige justificação e não dispensa automaticamente um requisito
obrigatório. Uma correcção acrescenta uma versão da análise e exige o
identificador do último registo do próprio analista.

Bases alteradas ou requisitos ultrapassados não aceitam novas análises.
Os registos antigos continuam consultáveis com indicação histórica, sem
copiar respostas para outra base. Os requisitos e a base são conferidos
novamente dentro de uma transacção que bloqueia primeiro a empresa e
revalida o operador. Após adjudicação, ou fora do estado aprovado do pedido,
os registos anteriores permanecem em consulta, sem novas escritas.

O módulo não decide admissão/exclusão e não usa os resultados para alterar
elegibilidade, pontuações, ordenação ou emissão. O método de comparação
permanece intacto; continuam aplicáveis os conflitos existentes. Um teste
de integração regista «não cumprido» num requisito obrigatório e confirma
que a matriz é idêntica e que uma adjudicação antes elegível segue o circuito
normal até à emissão, sem criar uma regra automática adicional.

Consulta exige os mesmos perfis e visibilidade das propostas, respeitando
empresa e departamento. Solicitantes e Armazém não ganham acesso. Respostas
usam `private, no-store` e histórico Inertia cifrado. O histórico é paginado
e o último registo de cada analista/proposta é obtido separadamente, sem
confundir uma página histórica com a versão actual de trabalho. A visão única
inclui ligação e eventos conforme o perfil.

A migração aditiva 000018 foi aplicada no batch 19, após backup privado de
296378 bytes e restauro verificado de 55 tabelas. Dados anteriores, restrições
e `.env` foram preservados; as tabelas de requisitos e análises ficaram
vazias na base de negócio. Ver `qualificacao-migracao-000018.json`. Backup e
manifesto permanecem fora do Git.

Seis cenários PostgreSQL passaram com duas ligações e duas esperas simultâneas
de bloqueio: requisitos concorrentes, duas escritas do mesmo analista,
analistas distintos, base alterada, perfil revogado e requisitos novos em
disputa com uma análise da versão anterior. Não houve substituição de
analistas, mistura de bases ou duplicação de versões. A base exclusiva de
testes foi eliminada. Ver `qualificacao-concorrencia-postgresql.json`.

As alterações locais em `compatibilidade.md`, `desenvolvimento.md` e
`orientacoes-continuidade.md` foram preservadas e não fazem parte deste
incremento. A revisão visual permanece pendente: o navegador devolveu
`The browser access host is unavailable`. Admissão/exclusão formal, circuitos
de conferência/quórum, novos métodos de avaliação, certificação de evidências
e cancelamento de ordens emitidas continuam sem activação neste âmbito.

Resultado deste incremento: **454 testes aprovados, 2 ignorados e 3601
asserções**. São 11 testes novos: dez específicos do módulo e um de integração
com adjudicação/emissão. PHPStan, Pint, TypeScript, build e lint/formatação
dos ficheiros alterados passaram. A formatação global continua a assinalar
`compatibilidade.md`, já modificado fora desta entrega; não foi alterado nem
incluído no commit. Os dois testes ignorados continuam condicionados a MFA.

## Incremento: sessão de abertura e actas por versão

Nas propostas existe o acesso «Sessão de abertura e actas», em
`/requisicoes/{requisition}/abertura`. Compras pode registar uma sessão num
pedido aprovado, antes de existir adjudicação. O registo é opcional; não
introduz um concurso público obrigatório, um número mínimo de propostas,
um júri obrigatório ou um novo circuito financeiro em todas as empresas.

O operador declara referência, local, data/hora, fuso horário, intervenientes,
qualidade em que participam, observações e referências de anexos, selecciona
as propostas e confirma a conferência. As propostas seleccionadas são
copiadas no servidor com fornecedor, referência, valores e linhas; não se
aceitam valores de uma acta enviados pelo cliente. Uma impressão autenticada
usa a cópia preservada, incluindo nome da empresa e autor do registo.
Não contém pontuações ou uma recomendação de adjudicação.

As datas são interpretadas no fuso declarado, guardadas em UTC e apresentadas
nesse fuso. Este primeiro âmbito suporta Africa/Johannesburg, Africa/Maputo e
UTC; a interface começa pelo fuso do contexto local. Sessões futuras e prazo
de apresentação posterior à sessão são recusados. O prazo é declarado; não
se presume que a data de criação de uma cotação no SGC seja a sua data real
de entrega pelo concorrente.

Correcções criam versões novas, com fundamento e referência à versão anterior
na auditoria. As versões guardadas não são editadas ou eliminadas pela
aplicação. Uma base de propostas alterada desde a consulta ou uma versão
anterior desactualizada é recusada. A interface permite conferir a base
actualizada sem apagar os textos introduzidos. Propostas posteriormente
adicionadas ou alteradas não entram nas actas anteriores; uma divergência é
assinalada na consulta. Não se alterou a política de recepção de cotações.

Os nomes dos intervenientes são declarações, não assinaturas digitais
verificadas. A impressão disponibiliza espaço para assinaturas manuscritas.
As referências de anexos não representam carregamento ou validação de
ficheiros. Registar uma acta não avalia propostas, não certifica a realização
da sessão, não adjudica, não reserva orçamento e não autoriza compras.
Alterações documentais depois da adjudicação exigem um circuito futuro;
este incremento conserva as actas anteriores para consulta, sem as reescrever.

Administração, Compras, Finanças e chefias autorizadas consultam; apenas
Compras regista. Mantêm-se isolamento entre empresas, âmbito departamental,
verificação de conflitos e revalidação do operador dentro da transacção.
Solicitantes e Armazém não ganham acesso a preços ou actas. Consulta e
impressão usam `private, no-store`; o histórico Inertia é cifrado. Os registos
aparecem nos documentos e eventos da visão única conforme o perfil.

A migração aditiva 000017 foi aplicada no batch 18 após backup privado de
291397 bytes e restauro verificado de 54 tabelas. Dados anteriores,
restrições e `.env` foram preservados; não foram criadas actas fictícias na
base de negócio. Ver `abertura-migracao-000017.json`. Backup e manifesto
ficam fora do Git.

Resultado: **443 testes aprovados, 2 ignorados, 3431 asserções**, incluindo
11 testes novos de snapshots, versões, base desactualizada, impressão,
fuso horário, validação, segregação, empresas/departamentos, revogação de
perfil, rollback de auditoria, imutabilidade e escape de texto. Quatro
cenários PostgreSQL passaram, cada um com duas ligações e duas esperas de
bloqueio simultâneas: versões iniciais concorrentes, correcções concorrentes,
perfil revogado e base alterada durante a espera. A base temporária exclusiva
foi eliminada. Ver `abertura-concorrencia-postgresql.json`.

PHPStan, Pint, TypeScript e build passaram. A revisão visual da interface e
da impressão permanece pendente pela indisponibilidade do navegador. Não se
declara validação operacional de concursos, assinaturas, orçamentos ou regras
de cancelamento de ordens emitidas. Publicação de concursos, propostas
seladas, qualificação por etapas e novos métodos de avaliação continuam
pendentes; os exemplos locais não os tornam obrigações universais.

## Incremento: planeamento por empresa

O menu Compras inclui `/planeamento`. Administração e Compras registam itens
para bens, obras, serviços ou consultoria, seleccionam departamento e
responsável da própria empresa e definem marcos com nomes e datas próprios.
Estas naturezas são classificações de acompanhamento, não novas modalidades
de contratação. Não existem marcos obrigatórios ou valores financeiros
predefinidos, e o plano não cria reservas ou aprovações.

Uma compra pode ser planeada antes da requisição. Administração ou Compras
podem depois ligar uma requisição visível, do mesmo departamento, com
fundamento. A ligação é única e não substitui uma anterior. A visão única do
processo oferece um atalho para o item do plano quando o utilizador também
tem acesso a esse item; o filtro `?item=` conserva as mesmas permissões.

O responsável atribuído regista ou corrige datas realizadas e indica o
fundamento. Administração e Compras também podem rever datas previstas e
reatribuir responsáveis. Datas realizadas futuras são recusadas. Todas as
alterações guardam autor, valores anteriores, novos valores e fundamento,
com versão optimista e bloqueio da empresa para impedir sobrescrita silenciosa.
Uma data realizada é uma declaração de acompanhamento: não confirma entregas,
facturas, pagamentos ou execução integral da compra.

Administração, Compras e Finanças consultam o plano da empresa. Chefias
consultam o departamento ou itens de que são responsáveis; os restantes
perfis consultam apenas os itens atribuídos. Só Administração e Compras
definem o plano e consultam o histórico geral. Finanças não ganha permissão
de edição por ser leitor; um responsável pode registar datas realizadas no
seu item. Uma atribuição não dá acesso à requisição ou aos seus documentos
se as permissões normais não o permitirem. Dados de outras empresas, opções
de equipa e histórico geral não são expostos a utilizadores sem acesso.

A migração aditiva 000016 foi aplicada no batch 17 após backup privado de
281059 bytes e restauro verificado de 52 tabelas. Dados anteriores, restrições
e `.env` foram preservados. As duas tabelas novas ficaram vazias: não foram
criadas compras ou datas fictícias na base de negócio. Ver relatório
`planeamento-migracao-000016.json`; os ficheiros privados de recuperação
permanecem fora do Git.

Treze testes específicos verificam criação, marcos livres, datas realizadas,
reprogramação e versão, rejeição de datas futuras e ausência de fundamento,
perfis, empresas, departamentos, ligação única e posterior, reatribuição,
revogação de perfil, rollback de auditoria e acesso ao processo ligado.
Quatro cenários PostgreSQL com duas ligações e duas esperas simultâneas
passaram: datas concorrentes, responsáveis concorrentes, marcos duplicados e
perfil revogado enquanto os operadores aguardam o bloqueio. Cada escrita
aceite produz um único evento; a base temporária exclusiva foi eliminada.
Ver `planeamento-concorrencia-postgresql.json`.

O histórico apresenta os 50 eventos de planeamento mais recentes da empresa.
Título, natureza e departamento são definidos na criação; as revisões deste
âmbito abrangem responsável, ligação posterior e datas dos marcos. Não há
eliminação de itens ou marcos. Estimativas financeiras do plano, aprovações
do plano, importação dos exemplos, alertas automáticos, dependências entre
marcos, actas e novas modalidades continuam fora deste primeiro incremento.
A revisão visual continua pendente, devido à indisponibilidade do navegador.

Resultado deste incremento: **432 testes aprovados, 2 ignorados, 3336 asserções**;
**4 cenários concorrentes PostgreSQL aprovados**. PHPStan, Pint, TypeScript,
lint/formatação e build passaram. O navegador voltou a responder
`The browser access host is unavailable`. Não se declara revisão visual
concluída nem validação operacional de regras ou orçamentos das empresas.

## Incremento: visão única do processo de compra

O detalhe de uma requisição inclui o acesso «Ver processo completo», em
`/requisicoes/{requisition}/processo`. A página reúne as etapas já suportadas,
os responsáveis por função, decisões com autores e datas, atalhos para os
registos e o histórico permitido ao perfil. Inclui ligação entre processos
originais e revisões quando ambos são visíveis ao utilizador. O cabeçalho e
rodapé partilhados mantêm-se neste ecrã.

Esta é uma consulta dos registos existentes. Não cria etapas obrigatórias,
aprovações, documentos, reservas ou pagamentos. Planeamento, acta de abertura,
qualificação específica do concurso e relatório por etapas aparecem apenas
como funcionalidades futuras, sem se presumirem aplicáveis a todas as compras.
Os quatro exemplos locais continuam a ser referências, não regras impostas.

O estado da requisição é separado dos restantes estados. Existência de propostas
não significa elegibilidade; histórico técnico não garante validade da base
actual; existência de lançamentos não certifica o orçamento; recepções podem
ser parciais; registo de factura não equivale a validação; pagamentos externos
confirmados não comprovam liquidação integral nem executam transferências.

A rota exige autenticação, empresa configurada e visibilidade da requisição.
Solicitantes não obtêm detalhes de propostas, adjudicações, ordens ou finanças
por esta consulta. Chefias conservam o âmbito departamental; Finanças e
Administração consultam os resumos financeiros. O Armazém não obtém acesso a
requisições de terceiros por esta nova rota. Documentos e eventos são filtrados
no servidor, sem snapshots privados, anexos ou dados bancários. A resposta usa
`private, no-store` e histórico Inertia cifrado.

Cinco testes específicos cobrem registos e estados parciais, ocultação de
compras/finanças ao solicitante, propriedade e departamento, isolamento entre
empresas e convidados, actualização da validação de factura e leitura sem
novos eventos de auditoria. Não há migração nem alteração de dados de negócio.
TypeScript, lint/formatação, build, PHPStan e Pint passaram.

Bateria completa deste incremento: **419 testes aprovados, 2 ignorados,
3180 asserções**. Os testes ignorados continuam condicionados à activação de
MFA; não são apresentados como aprovados. Os seis cenários concorrentes do
incremento anterior não foram repetidos, pois esta entrega não altera as
operações transaccionais que verificam.

O navegador voltou a devolver `The browser access host is unavailable`.
A revisão visual pública, autenticada e de impressão continua pendente;
testes HTTP e compilação não a substituem. O cancelamento de ordens emitidas
continua sujeito à proposta de regras ainda não validada.

## Incremento: navegação partilhada e revisão sem ordem emitida

O cabeçalho e rodapé do SGC são partilhados pelo acesso autenticado e pela
consulta pública, incluindo a proposta `/proposta/principal`. Os dropdowns
agrupam Compras, Finanças, Armazém e Gestão; preservam os acessos anteriores,
o menu da conta e a localização do ecrã. As opções autenticadas respeitam o
perfil; a autorização continua a ser verificada no servidor. A referência
visual foi consultada apenas em leitura no InvesteMoz: preto `#090909`,
vermelho `#ed1c24`, menus brancos. O projecto InvesteMoz não foi alterado.

Em `/revisao-compras`, cada empresa pode propor uma política datada para
cancelar adjudicações sem ordem emitida. Não existe activação por defeito.
A implementação usa duas assinaturas administrativas distintas do proponente
para publicar a regra e uma decisão Financeira independente para cada
cancelamento pedido por Compras. Estas são opções deste circuito implementado;
não constituem valores financeiros predefinidos para as empresas.

Um cancelamento pendente bloqueia novas decisões finais e emissão. Aprovação
encerra a adjudicação e requisição originais, mantendo cotações e decisões;
liberta apenas reserva não comprometida. Repetições idênticas não duplicam
lançamentos. Rejeição mantém a compra original. Uma decisão é imutável e,
neste primeiro âmbito, existe no máximo um pedido de cancelamento por
adjudicação, incluindo pedidos rejeitados. Uma alteração da política bloqueia
a aprovação de pedidos antigos; a rejeição continua disponível para retomar
o processo. Ordens emitidas e compromissos financeiros impedem este circuito.

Só o solicitante original, ainda no mesmo departamento, pode preparar um
único novo rascunho ligado ao cancelamento aprovado, com nova data e
justificação. Copiam-se artigos e estimativas, sem decisões, cotações,
validações técnicas ou reserva automática. O novo pedido segue o circuito
normal, incluindo validação técnica quando aplicável. As restrições únicas
de adjudicação e ordem por requisição foram conservadas.

A migração aditiva 000015 foi aplicada no batch 16 após backup privado de
259925 bytes e restauro verificado de 48 tabelas numa base temporária.
Dados de negócio anteriores, restrições e `.env` foram preservados; não foram
criadas políticas ou operações fictícias na base real. Ver relatório
`revisao-migracao-000015.json`. O backup e o manifesto ficam fora do Git.

Sete cenários novos verificam política obrigatória, bloqueio pendente,
rejeição e retoma, histórico e rascunho único, recusa após emissão,
segregação após mudança de perfil, libertação única da reserva e rollback
conjunto quando falha a auditoria. A validação concorrente deste circuito
foi acrescentada numa base PostgreSQL temporária: **6 cenários aprovados**,
cada um com duas ligações independentes e duas esperas de bloqueio simultâneas.
Abrange decisão repetida, decisões opostas, revisão repetida, emissão com
cancelamento pendente, emissão repetida e emissão em disputa com um pedido
de cancelamento. Nos três cenários de emissão, a adjudicação é seleccionada
e aprovada pelos serviços reais da aplicação. O controlo positivo emite uma
única ordem e um único compromisso; na disputa, apenas uma operação avança.
Os quatro primeiros cenários verificam também reserva e revisão únicas.
O relatório é `revisao-concorrencia-postgresql.json`; a base exclusiva de
testes foi eliminada no fim. Não houve alterações à base de negócio.

Resultado do incremento: **414 testes aprovados, 2 ignorados, 3099 asserções**.
PHPStan e Pint passaram; TypeScript, lint/formatação e build passaram.
As quatro verificações HTTP da proposta, requisições públicas, reforços e
aparência responderam 200. Estes pedidos HTTP não constituem revisão visual.

A revisão visual pública, autenticada e de impressão continua pendente:
o acesso ao navegador permanece indisponível. Compilação e testes não a
substituem. Ordens emitidas, estornos, notas de crédito, devoluções e
validação operacional das regras de cada empresa continuam fora deste âmbito.

Esta revisão cobre os módulos implementados e as pendências documentadas no
repositório. Não equivale a validação operacional integral ou certificação de
todos os requisitos do sistema. Valores e políticas reais continuam a pertencer
a cada empresa; nenhum foi criado nesta revisão.

## Correcções verificadas

- Operações que verificavam o perfil antes de esperar pelo bloqueio da empresa
  passam a recarregar e bloquear o utilizador dentro da transacção. Abrange
  facturas, dados bancários, stock, recepções, requisições, adjudicação, emissão,
  validação técnica e dotação inicial. Mudança de perfil ou de empresa durante
  a espera não é autorizada pelo perfil antigo em memória.
- Requisição volta a verificar departamento e centro de custo ao guardar e o
  departamento do solicitante ao submeter. Decisões departamentais usam o perfil
  actual; revisão técnica e aprovadores finais são bloqueados durante as
  verificações transaccionais.
- Dotação pendente mostra **zero disponível e zero aprovado**, preservando o
  valor proposto e o histórico. O servidor já bloqueava a reserva; a interface
  deixou de apresentar verba proposta como disponível.
- Teste da página de segurança com MFA desligado deixou de ser indevidamente
  ignorado. Textos dessa página e confirmação de alteração de palavra-passe
  traduzidos para português. Nenhuma palavra-passe real foi alterada.
- Configuração de fontes passou a declarar desactivada a optimização opcional
  que já não era gerada por ausência de `fontaine`. Mantém Instrument Sans e
  elimina o aviso de dependência opcional sem instalar pacotes novos.

## Resultados

**407 testes aprovados, 2 ignorados, 2.964 asserções** na suite completa SQLite
em memória. Os dois ignorados dependem de MFA activado, actualmente desligado;
não são apresentados como funcionalidades validadas. PHPStan, Pint, TypeScript,
compilação e formatação/lint frontend verificados no fecho.

**32 cenários concorrentes PostgreSQL aprovados**, todos em bases exclusivas
de teste, eliminadas no final:

| Área                           | Cenários | Evidência                                              |
| ------------------------------ | -------: | ------------------------------------------------------ |
| Recepções                      |        4 | [Relatório](recepcao-concorrencia-postgresql.json)     |
| Stock e peças                  |        7 | [Relatório](stock-concorrencia-postgresql.json)        |
| Reservas e compromissos        |        5 | [Relatório](orcamento-concorrencia-postgresql.json)    |
| Facturas e consumo             |        3 | [Relatório](facturas-concorrencia-postgresql.json)     |
| Dados bancários                |        3 | [Relatório](bancos-concorrencia-postgresql.json)       |
| Pagamentos externos            |        3 | [Relatório](pagamentos-concorrencia-postgresql.json)   |
| Reforços                       |        3 | [Relatório](reforcos-concorrencia-postgresql.json)     |
| Regras de investimento         |        3 | [Relatório](investimento-concorrencia-postgresql.json) |
| Perfil revogado durante espera |        1 | [Relatório](autorizacao-concorrencia-postgresql.json)  |

O último ensaio bloqueia a empresa, observa duas ligações simultaneamente à
espera e revoga os dois perfis de Armazém antes de libertar o bloqueio. Os dois
pedidos pelo kernel HTTP retornam **403**; não criam recepções nem movimentos.
Os restantes ensaios verificam saldos, duplicações e integridade conforme os
respectivos relatórios. Não são testes de carga ou uma validação de todos os
possíveis cruzamentos concorrentes do sistema.

Sem migrações, seeds, criação de contas, alteração de configuração de ambiente
ou escritas de negócio na base real nesta revisão. Acesso HTTP pode actualizar
sessões. Nenhuma autorização de compra ou transferência bancária foi emitida.

## O que permanece por tratar

| Pendência                                          | Situação                                                                                                                                    |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| Revisão visual pública, autenticada e impressão    | Bloqueada pelo acesso ao navegador; testes HTTP não a substituem.                                                                           |
| MFA obrigatório e ciclo completo de acessos        | Não implementados/activados; dois testes condicionais continuam ignorados.                                                                  |
| Revisão/cancelamento de adjudicações e ordens      | Cancelamento de adjudicações sem ordem implementado no incremento abaixo; cancelamento de ordens emitidas continua ausente.                 |
| Reversões, estornos, notas de crédito e devoluções | Funcionalidades ainda não implementadas; não se apagam lançamentos existentes.                                                              |
| Regras empresariais                                | Escalões provisórios, regras fiscais, validade/levantamento de conflitos e excepções exigem decisão da empresa.                             |
| Investimento agregado e fraccionamento             | Apenas tecto por processo suportado; sem agregação/detecção automática.                                                                     |
| Outras etapas do roteiro                           | Multimoeda, reposição, tolerâncias/investigação de inventários, manutenção/activos e requisitos de subscrição/hosting continuam no roteiro. |
| Controlos operacionais                             | Carga, permissões contra SQL administrativo, retenção e recuperação por empresa ainda exigem validação própria.                             |

Estas pendências não foram marcadas como concluídas por compilação ou testes
funcionais. O próximo incremento de revisão/cancelamento deve definir e guardar
uma política explícita por empresa, conservar o passado e exigir novas decisões
para processos revistos; não pode autorizar por omissão a alteração de ordens
emitidas ou a libertação de compromissos já consumidos.

Verificação HTTP local no fecho: **18 páginas públicas responderam 200** e
**13 rotas protegidas responderam 302 sem sessão**. O navegador voltou a devolver
`The browser access host is unavailable`; a revisão visual continua pendente.