11 KiB
Validação técnica do SGC — 28 de Outubro de 2026
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 |
| Stock e peças | 7 | Relatório |
| Reservas e compromissos | 5 | Relatório |
| Facturas e consumo | 3 | Relatório |
| Dados bancários | 3 | Relatório |
| Pagamentos externos | 3 | Relatório |
| Reforços | 3 | Relatório |
| Regras de investimento | 3 | Relatório |
| Perfil revogado durante espera | 1 | Relatório |
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.